業務プロセスの分析とは、顧客の仕事そのものの流れを見て、どこで時間が失われているかを突き止める作業です。手順は決まっています。まず現状（As-Is）を「誰が・何を・どの順で・どこへ渡すか」で描き、次にあるべき姿（To-Be）を描く。その差分がそのまま施策になります。そして差分を見つける物差しがリードタイムで、その中身を作業時間と待ち時間に割ると、止まっている場所＝ボトルネックが浮かび上がります。個々の画面や機能ではなく流れ全体を見るのが、この分析の要です。
リードタイムは「依頼を受けてから相手に届くまで」の暦の上での経過時間です。これに対し実作業時間（正味作業時間）は、担当者が実際に手を動かしていた時間だけ。両者の差が待ち時間（滞留）です。そして手戻りは、後の工程で不備が見つかって前の工程へ差し戻される動きで、やり直しの作業時間と、差し戻し・再提出の待ち時間を二重に積み増します。「作業が遅い」のか「待たされている」のか「やり直している」のかを分けて数えるところから、分析は始まります。
現状（As-Is）を可視化する
可視化で書き出すのは4つだけです。誰が（担当・部門）／何を（作業と入力・出力）／どの順で（順序と分岐）／どこへ渡すか（受け渡し）。とくに部門をまたぐ受け渡しは要注意で、業務が止まるのはたいてい工程の中ではなく工程と工程のあいだです。担当を縦の列（レーン）に分けて描くと、線が列をまたぐ回数がそのまま「渡した回数」になり、往復が多い箇所が目で分かります。
この図から読み取るのは3点です。再入力（同じ情報を2回打つ）、差し戻し（手戻りの発生点）、まとめ処理（週次＝そこで必ず滞留する）。いずれも「作業が下手だから遅い」のではなく、流れの組み方が生んでいる遅れである点が重要です。
リードタイムを分解してボトルネックを見つける
各工程を実作業時間と待ち時間に割って横に並べると、どこが長いかではなくどこで止まっているかが見えます。上の流れを1件の注文について測ると、次のようになったとします。
実作業時間待ち時間（滞留）手戻りによる増分
待ち時間の合計＝4＋3＋40＋2＝49時間、手戻りによる増分＝8時間
リードタイム＝3＋49＋8＝60時間 → 実作業は全体の5%しかない
結論は明快です。この業務のボトルネックは管理部門の与信・在庫確認そのもの（0.5時間）ではなく、そこで週次処理を待つ40時間です。担当者を増やしても、処理を速くしても、リードタイムはほとんど縮みません。効くのはまとめ処理をやめて都度処理に変える、あるいは一定条件の注文は自動判定にして待ち行列に入れないという、流れの組み替えのほうです。
数え方で必ず外すのが2つあります。1つめは待ち時間の数え落とし。各工程の作業時間だけを足して「合計3時間だから1日で終わるはず」と結論してしまう誤りで、実際のリードタイムは60時間です。リードタイムは経過時間であって、作業時間の合計ではありません。承認待ち・まとめ処理待ち・部門をまたぐ受け渡し待ちは、誰の作業時間にも計上されないまま暦を消費します。2つめは全体最適と部分最適の取り違え。ある工程だけを速くしても、後工程が詰まっていればリードタイムは1分も縮みません。前工程を速くすれば、詰まっている場所に仕掛りが積み上がるだけです。改善はまず最も待ちの長い1か所に当て、そこが解けたら次に長くなった場所へ移る——この順序を外すと、投資しても効果が出ない施策になります。
あるべき姿（To-Be）と、その差分
To-Be は「理想の業務」を白紙から描くものではありません。As-Is のどの制約を外すかを決めた結果として描かれます。だから両者は必ず同じ粒度・同じ範囲で並べ、差分が読み取れる形にします。
| 見る点 | 現状（As-Is） | あるべき姿（To-Be） | 差分＝施策 |
|---|---|---|---|
| 入力 | 営業が作成した注文書を、受注管理が見ながら再入力する | 営業が入力した時点で1件のデータになり、以降は転記しない | 入力の一元化 （再入力の廃止） |
| 判定 | 与信・在庫を人が週次でまとめて確認する | 条件を満たす注文は受付時に自動判定し、例外だけ人が見る | 判定の自動化と 例外処理への切り分け |
| 受け渡し | 部門ごとに書類を送り、届いた順に処理する | 同じデータを各部門が同時に参照し、状態で進捗が分かる | 情報の共有化 （受け渡しの削減） |
| 不備 | 後工程で不備が見つかり、前工程へ差し戻す | 入力時点で必須項目と整合をチェックし、不備を通さない | 検査を前倒しし 手戻りをなくす |
表の右端の列が、そのまま施策の一覧になります。ここまで揃えて初めて「なぜこの投資が必要か」を数字で言えます。効果は必ずリードタイムの短縮量で示すのが定石で、たとえば上の例なら「週次のまとめ処理を都度処理にすることで40時間の待ちが解消し、リードタイムは60時間から20時間へ」と書けます。施策の並べ方も同じ物差しで決まり、待ちが長い順＝短縮効果の大きい順に優先度を付けます。
「要望」と「真因」の距離
現場から上がってくるのは、たいてい部分的な改修要望です。「注文入力画面に項目を追加してほしい」「一覧の検索を速くしてほしい」。これらは症状の訴えであって、原因の指摘ではありません。要望どおりに直すと、症状はいったん引っ込みますが、リードタイムは変わらないということが起こります。
要望をそのまま実装すると
- 症状だけが動く：画面は使いやすくなったが、次の工程の待ちが変わらずリードタイムは同じ。
- 部分最適が積み上がる：部門ごとの要望を個別に叶えた結果、全体の流れはむしろ複雑になる。
- 回避策が固定化する：現場が編み出した二重管理（手元の台帳）を、そのまま機能として作り込んでしまう。
- 効果を測る物差しがない：何が良くなったのか説明できず、次の投資の根拠も作れない。
真因まで届く進め方
- 要望の前後を聞く：その項目を「誰に渡すために」「次に何をするために」必要かを追い、流れ上の位置を特定する。
- 流れ全体で測り直す：要望が出た工程だけでなく、前後の待ち時間まで並べて長い場所を確かめる。
- なぜを繰り返す：「項目が足りない」→「他部門に電話で確認している」→「渡す情報が決まっていない」と、原因は受け渡しの取り決めにあると分かる。
- 手戻りの発生点まで遡る：不備が見つかった工程ではなく、不備を作った工程を直す。
要望と真因が離れているとき、両者はたいてい別の部門にあります。困っているのは後工程、原因を作っているのは前工程。だから真因は、1部門の中を深く掘っても出てこず、受け渡しをまたいで流れを見たときにだけ見つかります。
核は「症状（要望）と原因（流れの詰まり）を切り離して読む」ことです。論述でも記述でも、問題文には現場の不満と、業務量・所要日数などの数字が別々に置かれています。両者を突き合わせ、不満が出ている工程ではなく、待ちが最も長い工程を原因として名指しするのが答えの筋です。設問が「どのような課題があるか」と聞いてきたらAs-Isの滞留・手戻り・再入力を、「どう実現したか」と聞いてきたらTo-Beとの差分＝施策を、「なぜその効果があるか」と聞いてきたらリードタイムのどの部分が消えるかを書く。この3つの問い方に対して、答える材料はすべて同じ1枚の分解図から取り出せます。
可視化の粒度は、「担当が変わるところ」で区切るのが実務的です。細かく分けすぎると受け渡しが見えなくなり、粗すぎると滞留がどこにあるか分かりません。また、測る対象は平均だけでなくばらつきも見ます。平均が同じでも、月末だけ極端に長い業務は、まとめ処理か人手の集中が原因である可能性が高くなります。