記事を書いてる人：あまみ るい
ある現場の推進担当者が、2日間かけてスイムレーン形式のフロー図を仕上げた。
担当者・課長・システムの3レーンに作業を丁寧に整理し、矢印が整然と並ぶ。見た目は完成度が高く、誰もが「よくできている」と感じるような資料だった。
それを部長に見せたとき、返ってきた言葉は「で、何が問題なの？」だった。
僕がコンサルとして現場に入ったとき、この光景を何度も目にした。「正しいやり方で書いたはずなのに、なぜ伝わらないのか」と困惑している担当者の顔を、今でもよく覚えている。
問題は書き方のスキルではない。Webで調べて「正しいアドバイス」を実践した結果として、提案書に適さないフロー図ができあがってしまう——この構造的な落とし穴にある。
- 現状の業務フローの目的は「部長との承認（縦）」と「関係者との共通認識（横）」の2つであり、投資判断のためではない。この目的を誤解すると、どれだけ丁寧に書いても「伝わらないフロー図」になる。
- Web上でよく語られる「スイムレーン」「担当者ヒアリング」「ECRS分析」は、業務改善提案書の現状フロー作成では逆効果になる4つのアンチパターンの元になっている。
- ✗（アクセス不可・機能していない）と△（協力しているが負担あり）の2記号と注記を組み合わせると、「課題が一目でわかるフロー図」を形式を問わず作れる。
業務改善提案書の「現状の業務フロー」でよくある4つのNGパターン
まず前提として押さえておきたいことがある。
現状の業務フローを作る目的は2つだ。①部長・責任者との承認（縦方向の合意）、②プロジェクト関係者との共通認識（横方向の共有）。この段階では、投資判断は目的ではない。予算の是非を問うのは「改善案・効果試算・コスト」の項目で行う。
また、現状フローは「事実の記録フェーズ」だ。良否の判断や評価は次の「課題」の項目で行う。
この前提を踏まえたうえで、よく見る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つの目的と図解のルールで詳しく解説している。
4つのNGを正す——現状の業務フロー「書き方」の軌道修正
ここで一度、軸を確認しておきたい。
現状フローを作るとき、最初に問うべきは「この図は誰に何を伝えるために作るか」だ。答えは「部長の承認（縦）」と「関係者との共通認識（横）」。投資判断はまだ不要で、「課題が一目でわかるかどうか」が唯一の完成基準だ。
スイムレーンを使うかどうか、JIS記号を使うかどうか、ページ数が何枚になるかは、この基準に比べれば二次的な問題に過ぎない。
NG1の軌道修正は、フォーマットへのこだわりを手放すことだ。スイムレーンを使っても使わなくても、「課題が一目でわかる」なら合格。逆に、どれだけきれいなスイムレーン図でも、課題の場所が伝わらなければ不合格だ。
NG2の軌道修正は、ヒアリングを出発点にとどめることだ。「大体」「通常は」という言葉が出てきたら、必ず実測する。シャドーイング（現場で業務を直接観察し、ストップウォッチで計測する）を行い、システムログやERPデータで裏付けを取る。
NG3の軌道修正は、「こうなっているはず（規程）」ではなく「こうなっている（実態）」を書くことだ。非公式な問い合わせルート、アクセスできないシステム、属人的な判断——これらを全てそのまま記録する。
NG4の軌道修正は、現状フローに良否判断を混ぜないことだ。記号（✗・△）で問題箇所を示すのは「事実の見える化」であり、評価ではない。ECRS・QCD分析は「課題」欄に移してから行う。
実際にどう書くか、工場設備メンテナンス部門の事例で示す。
【OKサンプル：工場設備メンテナンス部門の現状フロー（抜粋）】
フィールドエンジニア
→✗ 営業管理 顧客データベース
※アクセス権限不足でフィールドエンジニアは参照不可
→✗ メンテナンス部門管理 ファイルサーバー
※アクセスはできるが、必要ファイルの場所が不明
フィールドエンジニア（解決のために社内コネに問い合わせ）
→ メンテナンスサポート
→ 営業 △（本来は不要のはず）
→ 開発 △（本来は不要のはず）
✗ ＝ アクセス不可・機能していない接続
△ ＝ 協力はしてくれているが、間接業務が増えて本業が削られている状態このOKサンプルには3つの特徴がある。
- 形式（スイムレーン）ではなくテキストでも「課題」は十分に伝わる
- ✗と△の2記号と注記で「何が問題か」が一目で分かる
- 「本来は不要のはず」という注記で、実態と規程の乖離が明示されている
スイムレーンで完璧に描く必要はない。「課題が一目でわかる」ことが目的なら、テキストと2つの記号で十分に達成できる。
現状フロー図と次項の課題を1対1で対応させる方法については、業務改善提案書の「問題点」はQCDで書くで解説している。
現状の業務フローを提出前に確認する3つの基準
提案書を提出する前に、次の3つの問いに「Yes」と答えられるか確認してほしい。
基準1：「このフロー図を見た部長（責任者）が、課題の場所を1分以内に指差せるか」
指差せなければ、課題の可視化が不十分だ。✗や△の記号、あるいは注記の追加で改善できることが多い。部長が初めて見る目線で、自分のフロー図を確認してみるといい。
基準2：「このフロー図に書かれた内容は、実測・観察・ログデータで裏付けられているか」
「大体」「たぶん」「通常は」という言葉が残っていれば、その箇所はまだポエムAs-Isのままだ。数値・観察記録・システムログに置き換えるか、「ヒアリングのみ・要確認」と明記する。
基準3：「このフロー図で✗または△として示した問題は、次項の『課題』に1対1で対応しているか」
フロー図と課題欄が連動していないと、提案書全体の論理が崩れる。先ほどのOKサンプルでいえば、「✗が2箇所、△が2箇所、問い合わせ分散が1件」という構造に対し、課題欄に「情報アクセス権限の整備」「メンテナンスサポート以外への負担集中」が対応して記載されている状態が理想だ。
この3つが全て「Yes」になったとき、現状フローは完成している。フォーマット（スイムレーン・JIS記号・ページ数）の完成度ではなく、この3つが判断基準だ。
まとめ——現状フローは「課題の合意を取るための図」である
この記事で示した4つのNGパターン——スイムレーン目的化・ポエムAs-Is・建前フロー・評価混在——は、全て同じ根本原因から来ている。現状フローの目的を誤解していることだ。
正しい流れは4ステップだ。
- 目的（承認・共通認識）を先に確認する
- 実測・実態を記録する
- ✗と△で課題を可視化する
- 次項の「課題」と1対1で対応させる
「このフロー図を見れば課題が分かる」状態になれば、部長の承認と関係者の共通認識は同時に取れる。そこが整えば、提案書の核心部分（課題・改善案）を書くための土台ができあがる。
業務改善提案書の他の項目の書き方については、業務改善提案書の書き方【構成と通し方を完全解説】にまとめている。