業務改善提案書の中で、「現状の業務フロー」は最も書き方に迷う項目のひとつだと思っている。
フロー図を丁寧に作ったのに、「で、何が問題なの？」と言われた経験がある方も多いはずだ。
僕がコンサルタントとして現場に入ったとき、担当者が何時間もかけて作ったフロー図を見た。きれいにまとまっていた。でも部長にも同僚にも「何を直せばいいかわからない」と言われていた。その図に描かれていたのは、規程通りの理想のフローだったからだ。
「フロー図を作る時間がない」「どこまで詳しく書けばいいかわからない」「どこに課題を書けばいいか迷う」——この3つの迷いは、実は全て同じ根本原因から来ている。フロー図の目的を誤解していることだ。
目的を理解すると、書くべき内容が自然に決まる。この記事では、よくある4つのNGパターンと、目的から逆算した3つの図解ルールを、NG・OKのサンプルつきで解説する。
- 現状の業務フローの目的は「部長との承認（縦）」と「関係者との共通認識（横）」の2つであり、投資判断のために書くものではない
- Webでよく語られる「スイムレーンで美しく描く」「担当者ヒアリングだけで書く」「規程通りに書く」「ECRSの評価を混ぜる」は、提案書の現状フローでは逆効果になる4つのNGパターン
- 実態を書く・✗と△の記号で課題を可視化する・次項の「課題」と1対1で対応させる、の3ルールで、形式を問わず「課題が一目でわかるフロー図」になる
なぜ「伝わらないフロー図」が生まれるのか
まず、現状の業務フローが何のために存在するかを整理したい。
目的は2つある。
ひとつ目は部長と課題を合意すること（縦・承認）。ふたつ目は関係者と課題を共通認識すること（横・実務）だ。
重要なのは、この段階では投資判断は目的ではないということだ。投資の是非を問うのは、改善案・効果試算・コストを記載する後の項目で行う。現状の業務フローの仕事は、「今、何が起きているか」を関係者全員に正しく見せることだけだ。
この前提を知らないまま書くと、「伝わらないフロー図」が生まれる。原因は3つある。
1つ目は、「こうなっているはず（規程通りの理想）」を書いていて、実態を書いていないこと。2つ目は、課題がどこにあるか読み手が分からない書き方になっていること。3つ目は、次項の「課題」に書く内容とフロー図の内容が一致していないことだ。
ある製造業のプロジェクトで、担当者が「この工程は大体3時間くらいです」と言っていた。実際に計測してみると、5時間半かかっていた。担当者は嘘をついていたわけではない。体感と事実がズレていただけだ。人間の認知には必ずバイアスがかかる。
これが「ポエムAs-Is」と呼ばれる失敗だ。感覚で書いたフローからは、感覚レベルの課題しか出てこない。
業務改善提案書全体の構成を先に把握したい方は、業務改善提案書の書き方【構成と通し方を完全解説】も参照してほしい。
業務改善提案書の「現状の業務フロー」でよくある4つのNGパターン
目的を踏まえたうえで、よく見るNGパターンを4つ紹介する。どれもWebで「正しいアドバイス」として語られているものが、提案書の文脈では逆効果になってしまうケースだ。
この前提を踏まえたうえで、よく見るNGパターンを4つ紹介する。どれもWebで「正しいアドバイス」として語られているものが、提案書の文脈では逆効果になってしまうケースだ。
NGパターン1：スイムレーン形式で「美しいフロー図」を作る
スイムレーンは、担当者・部署ごとにレーンを分け、引き継ぎのタイミングや責任の所在を明確にするためのフォーマットだ。業務マニュアルの標準化や属人化の解消には非常に有効で、Webでも広く推奨されている。
ただし、業務改善提案書の現状フローとして使うと、「全体を正しく整理しよう」という意識が先行し、「課題がどこにあるかを一目で示す」という目的が後回しになりやすい。形式の完成度が上がるほど、中身の問題が見えにくくなる。
【NGサンプル：スイムレーン形式のフロー図（概略）】
担当者 ：[開始]→[受注確認]→[データ入力]→[上長へ回付]
課長 ： →[承認]→[システム登録依頼]
社内システム： →[登録処理]→[完了]
※矢印が整然と並び、正常系のみを描いた一本道のフロー。
どこに問題があるか、一目では分からない。部長がこの図を見ても、「課題の場所」が分からない。見た目の完成度と、伝える力は別物だ。
NGパターン2：担当者ヒアリングだけで「現状」を把握する（ポエムAs-Is）
人間の認知には必ずバイアスがかかる。「自分の業務はそこまで非効率ではない」と思いたい心理が働くため、体感と事実がズレやすい。
あるプロジェクトで、製造部門の担当者Aさんが「この工程は大体3時間くらいです」と言っていた。実際にストップウォッチで計測すると、5時間半かかっていた。Aさんは嘘をついていたわけではない。体感と事実がズレていただけだ。
感覚で書いたフローからは、感覚レベルの課題しか出てこない。こうした主観フローを「ポエムAs-Is」と呼ぶ。
さらに深刻なのが、管理職（課長・部長）へのヒアリングだけで作成するケースだ。このとき記録されるのは「規程通りのあるべき手順（建前）」であり、現場で実際に行われている非公式ルートや例外処理は全て消える。
【NGサンプル：ポエムAs-Is】
○○工程：大体3時間程度（担当者Aさん談）
△△工程：通常は課長承認後に実施
※「大体」「通常は」という言葉が残っている段階で、実態ではなく印象が書かれている。NGパターン3：規程通りの「あるべきフロー」を現状フローとして書く（建前フロー）
ISO規程に基づいた作業手順書が存在するが、設備変更や手順の微調整に文書更新が追いつかず、実態と乖離しているケースは製造現場を中心に多く見る。その「規程上の手順」を現状フローとして書いてしまうと、本当の課題が隠れてしまう。
これを「建前フロー」と呼ぶ。
たとえば、「フィールドエンジニアはメンテナンスサポートだけに問い合わせるはず」という規程があったとする。しかし現場では、速く解決するために営業・開発にも直接問い合わせている。規程通りに書けば一本道になり、「問い合わせが社内に分散している」という実態が丸ごと消える。
【NGサンプル：建前フロー】
フィールドエンジニア → メンテナンスサポート → 顧客対応完了
※問い合わせ分散・アクセス不可・負担集中が一切記載されていない。
課題が見えないフロー図になっている。NGパターン4：ECRS・As-Is/To-Beギャップ洗い出しを現状フロー段階に混在させる
現状フローは「事実の記録」フェーズだ。この段階で「排除できないか（E）」「結合できないか（C）」という改善評価を書き込むと、事実と評価が混在し、読み手が「今どうなっているのか」を把握できなくなる。
また、As-IsとTo-Beのギャップを洗い出して「終わり」にするパターンも同じ問題を抱えている。ギャップの列挙で満足してしまい、課題の構造化（どのギャップが最重要か、なぜそのギャップが存在するのか）が抜ける。
【NGサンプル：評価が混在したフロー図】
フィールドエンジニア
→ メンテナンスサポート（←ここが排除できる？E）
→ 課長承認（←ここを結合すべき？C）
→ システム入力（←これは不要プロセス・削除候補）
※「現状どうなっているか」ではなく「どう改善すべきか」が混ざっている。このパターンに陥りやすいのは、「現状フローを書いたら、そのままどこを直すか考えた」という流れで作業を進めたときだ。誰でも陥る罠で、書き方が悪いのではなく、作業の順番の問題だ。
では、どう書けばよいか。次の章で、目的から逆算した3つのルールを説明する。
目的から逆算した3つの図解ルール
「承認」と「共通認識」という2つの目的を果たすために、フロー図を書くときに守るべきルールが3つある。
ルール1：実態を書く──規程ではなく現場で起きていることを
フロー図に書くべきは「数字で語れる、言い訳のない現実」だ。
ここで大事な注意点がある。「良い・悪い」のジャッジをこの段階で入れてはいけない。良否の評価は次の「課題」の項目で行う。現状フローの段階では、事実を淡々と記録することだけに集中する。
規程通りのフローを「現状」として書いてしまうと、課題が隠れる。実際に起きていること——非公式の問い合わせルート、アクセスできないシステム、属人的な判断——を書くことで初めて課題が浮かび上がる。
例えば、「フィールドエンジニアはメンテナンスサポートにだけ問い合わせするはずだが、速く解決するために営業・開発にも直接問い合わせている」という実態があるなら、それをそのまま書く。規程通りに「フィールドエンジニア→メンテナンスサポート」とだけ書くのではなく、実際に複数ルートに問い合わせが飛び散っている状況を正直に記載する。
ルール2：課題を記号で可視化する──✗と△の使い方
フロー図に「課題がどこにあるか」を示す視覚的な工夫を加えることで、読み手が一目で問題を把握できるようになる。
形式（スイムレーン・BPMNなど）へのこだわりより、「課題が見えるか」が優先基準だ。
僕が実際に使っていた記法では、2つの記号を使い分けた。
- ✗：アクセス不可・機能していない接続を表す
- △：協力はされているが、負担が生じている状態を表す
工場設備のメンテナンス部門での提案書では、こう記載した。
フィールドエンジニア
→✗ 営業管理顧客データベース
→✗ メンテナンス部門管理ファイルサーバー
※フィールドエンジニアは顧客データベースに権限不足でアクセスできない。
ファイルサーバーにはアクセスできるが、必要なファイルを探せない。
✗で「つながっていない・機能していない」を表現。
フィールドエンジニア
→メンテナンスサポート
→営業（本来は不要のはず）
→開発（本来は不要のはず）
※速く解決するために社内のコネに問い合わせが飛び散っている実態。
営業 △
開発 △
※協力はしてくれているが、間接業務が増えて本業が削られている様子。
△で「協力しているが負担が生じている」を表現。記号と注記をセットで書くことで、図を見た瞬間に問題の構造が分かる。スイムレーンで美しく描かなくても、これで十分だ。
ルール3：次項の「課題」と対応させる
現状の業務フローに書いた内容と、次項「課題」に書く内容が一致していないと、提案書全体の論理が崩れる。
✗で示したアクセス不可の問題→課題「情報アクセスに関する権限・整備の不備」、△で示した間接業務の増加→課題「メンテナンスサポート以外の部門への負担集中」という形で、フロー図と課題が1対1で対応している状態が理想だ。
上の例でいえば、フロー図に「✗」が2箇所、「問い合わせの分散」が1件、「△」が2箇所ある。課題もこの3つの構造に対応して整理するべきだ。
課題の数値化と記述ルールについては、業務改善提案書「問題点」の書き方｜NG5パターンとQCDで損失額を数値化する5ステップで詳しく解説している。
4つのNGパターンをこう直す
NG1の軌道修正は、フォーマットへのこだわりを手放すことだ。スイムレーンを使っても使わなくても、「課題が一目でわかる」なら合格。逆に、どれだけきれいなスイムレーン図でも、課題の場所が伝わらなければ不合格だ。
NG2の軌道修正は、ヒアリングを出発点にとどめることだ。「大体」「通常は」という言葉が出てきたら、必ず実測する。シャドーイング（現場で業務を直接観察し、ストップウォッチで計測する）を行い、システムログやERPデータで裏付けを取る。
NG3の軌道修正は、「こうなっているはず（規程）」ではなく「こうなっている（実態）」を書くことだ。非公式な問い合わせルート、アクセスできないシステム、属人的な判断——これらを全てそのまま記録する。
NG4の軌道修正は、現状フローに良否判断を混ぜないことだ。記号（✗・△）で問題箇所を示すのは「事実の見える化」であり、評価ではない。ECRS・QCD分析は「課題」欄に移してから行う。
現状の業務フローを提出前に確認する3つの基準
提案書を提出する前に、次の3つの問いに「Yes」と答えられるか確認してほしい。
基準1：「このフロー図を見た部長（責任者）が、課題の場所を1分以内に指差せるか」
指差せなければ、課題の可視化が不十分だ。✗や△の記号、あるいは注記の追加で改善できることが多い。部長が初めて見る目線で、自分のフロー図を確認してみるといい。
基準2：「このフロー図に書かれた内容は、実測・観察・ログデータで裏付けられているか」
「大体」「たぶん」「通常は」という言葉が残っていれば、その箇所はまだポエムAs-Isのままだ。数値・観察記録・システムログに置き換えるか、「ヒアリングのみ・要確認」と明記する。
基準3：「このフロー図で✗または△として示した問題は、次項の『課題』に1対1で対応しているか」
フロー図と課題欄が連動していないと、提案書全体の論理が崩れる。先ほどのOKサンプルでいえば、「✗が2箇所、△が2箇所、問い合わせ分散が1件」という構造に対し、課題欄に「情報アクセス権限の整備」「メンテナンスサポート以外への負担集中」が対応して記載されている状態が理想だ。
この3つが全て「Yes」になったとき、現状フローは完成している。フォーマット（スイムレーン・JIS記号・ページ数）の完成度ではなく、この3つが判断基準だ。
まとめ──フロー図は「課題の合意を取るための図」である
現状の業務フローは、投資判断のためではなく、「部長との承認（縦）」と「関係者との共通認識（横）」のために書く。
スイムレーン目的化・ポエムAs-Is・建前フロー・評価混在という4つのNGパターンは、すべてこの目的を誤解していることから生まれる。目的を理解すると、3つのルールが自然に導かれる。
- ①実態を書く：規程ではなく現場で実際に起きていることを記録する
- ②課題を記号で可視化する：✗と△を使い、注記をセットで添える
- ③次項「課題」と対応させる：フロー図の問題点と課題の記述を1対1で整合させる
「このフロー図を見れば課題が分かる」状態になれば、部長の承認と関係者の共通認識は同時に取れる。それが提案書の核心部分（課題・改善案）を書くための土台になる。
業務改善提案書の他の項目の書き方は、業務改善提案書の書き方【構成と通し方を完全解説】にまとめている。