業務フローの例外を拾えるIT職へ──標準化でこぼれる現場の見方

業務フローを整理していると、きれいに線が引けた瞬間に、少し安心することがある。

申請する。承認する。登録する。確認する。通知する。完了する。

流れとしては間違っていない。資料としても見やすい。会議でも説明しやすい。システム化の対象としても扱いやすい。

けれど、現場の業務は、そのきれいな線の上だけで動いているわけではない。

月末だけ違う処理がある。特定の顧客だけ例外対応がある。ベテランだけが知っている確認がある。承認者が不在のときだけ別ルートになる。システム上は同じ処理でも、現場では緊急度によって扱いが変わる。

こういうものは、業務フロー図の中では小さく見える。

しかし、プロジェクトが始まってから問題になるのは、だいたいこの小さく見えた部分だったりする。

標準化は大事だ。

業務改善でも、ERP導入でも、パッケージ導入でも、AI活用でも、最初から例外ばかりを拾っていたら設計は前に進まない。現場ごとの違いをすべて個別対応にしてしまえば、システムは複雑になり、運用も重くなり、保守もつらくなる。

だから、標準化する力は必要である。

ただし、標準化できる人と、業務を本当に見られる人は、同じではない。

標準化できる人は、ばらばらな業務を共通の流れにまとめられる。業務を本当に見られる人は、その共通化の中で何が消えたのかまで見ている。

この差は、上流SE、業務コンサル、パッケージ導入コンサル、PMOの仕事でかなり大きい。

標準化で消えるものがある

業務フローを描くとき、多くの人は正常系から入る。

通常の申請ルート。通常の承認者。通常の入力項目。通常の締め処理。通常の例外なしパターン。

もちろん、それでよい。最初からすべての例外を並べると、全体像が見えなくなるからだ。

問題は、そのあとである。

正常系を描いたあとに、例外を邪魔なものとして扱うか、業務の条件を教えてくれるものとして扱うかで、仕事の質が変わる。

例外は、単なるわがままではない。
そこには、現場が守っている制約がある。

顧客との契約条件かもしれない。法令や監査の都合かもしれない。月次締めの制約かもしれない。過去の障害対応から生まれた安全策かもしれない。システムには載っていないが、現場が事故を防ぐために続けている確認かもしれない。

もちろん、すべての例外に意味があるわけではない。

昔の担当者が決めたまま残っているだけの処理もある。誰も理由を説明できない慣習もある。やめても困らないのに、なんとなく続いている作業もある。

だからこそ、例外は残すべきか、捨てるべきか、標準に吸収すべきかを見極める必要がある。

この見極めができないと、標準化はただの圧縮になる。

現場の違いを理解しないまま、全部同じですとまとめてしまう。すると、設計段階ではきれいに見えるが、テスト、移行、教育、本番運用のどこかで現場から止められる。

それは現場が抵抗しているのではなく、こちらが業務条件を拾えていなかっただけかもしれない。

例外を見るときの最初の問い

例外を拾うときに、いきなり対応要否を決めないほうがいい。

この例外は必要ですか。
この例外はなくせますか。
この例外は標準に合わせられますか。

こう聞きたくなる気持ちは分かる。プロジェクトでは時間が限られているし、例外が増えるほど設計も見積も重くなる。

けれど、最初に聞くべきなのは、必要かどうかではない。

まず見るべきなのは、この例外は何を守っているのかである。
売上計上のタイミングを守っているのか。顧客との約束を守っているのか。

ミスの再発を防いでいるのか。現場の負荷を逃がしているのか。部門間の責任分界を曖昧なまま成立させているのか。

例外は、業務の弱点を隠していることがある。

たとえば、ある部門だけがExcelで二重管理しているとする。表面的には非効率に見える。システム化の文脈では、やめましょうと言いたくなる。

でも、なぜ二重管理しているのかを聞くと、基幹システムの更新タイミングが遅いからかもしれない。営業が見る数字と経理が確定する数字の意味が違うからかもしれない。現場が本当に知りたい単位でデータが取れないからかもしれない。

この場合、二重管理をやめることが正解とは限らない。

本当の論点は、Excelをなくすことではなく、どの時点の、どの粒度の、どの責任を持った数字が必要なのかである。

例外を作業として見ると、削減対象に見える。
例外を業務条件として見ると、設計の入口に変わる。

例外には三種類ある

僕は、業務フローを見るとき、例外を大きく三つに分けて考える。

一つ目は、守るべき例外である。
契約、法令、監査、内部統制、重要顧客との合意、業界特有の制約など、簡単に消してはいけないものがある。これは現場都合ではなく、事業上の条件である。
この例外を標準化の名で雑に消すと、あとで大きな手戻りになる。要件定義で拾えなかった場合、本番直前に発覚しやすい。そうなると、追加開発、運用回避、手作業、責任分界の再調整が一気に発生する。

二つ目は、見直すべき例外である。
昔のシステム制約、前任者の判断、過去の暫定対応、部門ごとの独自運用がそのまま残っているものだ。これは、なくせる可能性がある。
ただし、ここでもすぐに廃止と言い切らないほうがいい。廃止するなら、誰が困らなくなるのかだけでなく、誰が困るのかまで確認する必要がある。

三つ目は、標準に昇格すべき例外である。
最初は一部門の工夫だったものが、実は全社にも必要な観点だったということがある。ある現場だけがやっていた確認が、品質事故を防ぐ重要なチェックだった。ある拠点だけが持っていた管理項目が、全社の分析に必要な軸だった。
この場合、例外は捨てるものではない。
むしろ、標準業務へ取り込むべき知恵である。

業務を見る力は、例外を全部救うことではない。例外を、守るもの、見直すもの、標準に上げるものに分ける力である。

フロー図の外側にある業務を見る

業務フロー図には、矢印で表しやすい仕事と、表しにくい仕事がある。

申請、承認、登録、出力のような処理は描きやすい。

一方で、迷ったときの相談、確認の順番、誰に先に根回しするか、どこまで進めたら止めるか、どの状態なら上長に上げるか、といった判断は描きにくい。

しかし、実務で差が出るのは、この描きにくい部分である。
パッケージ導入でFit & Gapをやるときも、機能があるかないかだけを見ていると危ない。機能はある。でも現場の判断順序と合っていない。項目はある。でも承認前に見たい情報が足りない。ワークフローは組める。でも例外時の戻し方が現場運用と合わない。

こういうズレは、機能一覧だけでは見えにくい。

だから、業務フローを見るときは、処理の流れだけでなく、判断の流れを見る必要がある。

誰が、どの情報を見て、何を判断しているのか。
その判断が間違ったとき、誰が気づけるのか。
差し戻しになったとき、どこまで戻るのか。
緊急時だけ飛ばしている手順はないか。

本当はシステムではなく、人の経験で成立している箇所はないか。
こうした問いを置くと、フロー図の外側にある業務が見えてくる。

例外を拾える人は、現場の味方ではなく、設計の味方である

例外を拾うというと、現場寄りの人に見えるかもしれない。

たしかに、現場の声を丁寧に聞くことは大事だ。けれど、例外を拾えるIT職は、ただ現場の要望を代弁する人ではない。

現場が言ったことを全部残すなら、それは要件整理ではなく要望の転記である。

逆に、標準化を理由に全部切るなら、それは業務理解ではなく整理した気分である。

必要なのは、現場の言葉を聞きながら、設計として扱える形に変えることだ。

この例外は、業務条件なのか。
この違いは、部門固有なのか、全社共通にすべきなのか。
この手作業は、廃止できるのか、システムで吸収するのか、運用で残すのか。
この判断は、誰の責任として残すのか。

ここまで変換して初めて、例外は設計材料になる。
上流SEや業務コンサルの価値は、現場を分かっていますと言うことではない。
現場の複雑さを、意思決定できる形に整理することにある。

例外を拾うための小さなメモ

実務で使うなら、難しいフレームワークはいらない。

業務ヒアリングやフロー整理の横に、例外メモを一つ置くだけでも変わる。

項目はシンプルでいい。
どんなときに起きるか。
誰が判断しているか。
なぜ通常フローでは足りないか。
なくすと何が困るか。残すなら、システム、運用、ルールのどこで受けるか。

この五つを書くだけで、例外は雑談から論点に変わる。
特に大事なのは、なくすと何が困るかである。
現場は、やりたいから例外を残しているとは限らない。困るから残していることが多い。

その困りごとを見ないまま、標準化だけを進めると、現場はあとで別の回避策を作る。すると、システムは標準化されたのに、業務は裏側でまた分岐していく。

これが、標準化プロジェクトでよく起きる失敗だと思う。

標準化の目的は、違いを消すことではない

標準化とは、すべてを同じにすることではない。

本当に同じでよいものを同じにし、違いとして残すべきものを見極めることだ。

だから、業務フローの例外を拾える人は、プロジェクトにとって厄介な人ではない。むしろ、後工程の手戻りを減らす人である。

現場の言葉をそのまま信じすぎない。
標準化の言葉で現場を押し切らない。
例外の奥にある条件を見て、設計に変える。
この力は、AIが普及しても残ると思う。

フロー図をきれいに描くことは、これからもっと簡単になる。議事録を整理することも、仕様のたたきを作ることも、以前より速くなる。

それでも、どの例外を守り、どの例外を捨て、どの例外を標準に上げるのかは、業務と責任を理解している人が判断しなければならない。

業務フローを描くとき、線のきれいさだけを見ていないだろうか。

その線からこぼれた例外の中に、現場が本当に守ってきた業務条件が残っているかもしれない。

あなたは次のヒアリングで、標準から外れた処理を、面倒な例外として見るだろうか。
それとも、業務の本質が少し顔を出した場所として見るだろうか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！