業務改善提案書「現状の業務フロー」で押さえるべき3つの目的と図解のルール

業務改善提案書の中で、「現状の業務フロー」は最も書き方に迷う項目のひとつだと思っている。

フロー図を丁寧に作ったのに、「で、何が問題なの？」と言われた経験がある方も多いはずだ。

僕がコンサルタントとして現場に入ったとき、担当者が何時間もかけて作ったフロー図を見た。きれいにまとまっていた。でも部長にも同僚にも「何を直せばいいかわからない」と言われていた。その図に描かれていたのは、規程通りの理想のフローだったからだ。

「フロー図を作る時間がない」「どこまで詳しく書けばいいかわからない」「どこに課題を書けばいいか迷う」——この3つの迷いは、実は全て同じ根本原因から来ている。フロー図の目的を誤解していることだ。

目的を理解すると、書くべき内容が自然に決まる。この記事ではその逆算の仕方を3つのルールにまとめて解説する。

なぜ「伝わらないフロー図」が生まれるのか

まず、現状の業務フローが何のために存在するかを整理したい。

目的は2つある。

ひとつ目は部長と課題を合意すること（縦・承認）。ふたつ目は関係者と課題を共通認識すること（横・実務）だ。

重要なのは、この段階では投資判断は目的ではないということだ。投資の是非を問うのは、改善案・効果試算・コストを記載する後の項目で行う。現状の業務フローの仕事は、「今、何が起きているか」を関係者全員に正しく見せることだけだ。

この前提を知らないまま書くと、「伝わらないフロー図」が生まれる。原因は3つある。

1つ目は、「こうなっているはず（規程通りの理想）」を書いていて、実態を書いていないこと。2つ目は、課題がどこにあるか読み手が分からない書き方になっていること。3つ目は、次項の「課題」に書く内容とフロー図の内容が一致していないことだ。

ある製造業のプロジェクトで、担当者が「この工程は大体3時間くらいです」と言っていた。実際に計測してみると、5時間半かかっていた。担当者は嘘をついていたわけではない。体感と事実がズレていただけだ。人間の認知には必ずバイアスがかかる。

これが「ポエムAs-Is」と呼ばれる失敗だ。感覚で書いたフローからは、感覚レベルの課題しか出てこない。

業務改善提案書全体の構成を先に把握したい方は、業務改善提案書の書き方【構成と通し方を完全解説】も参照してほしい。

目的から逆算した3つの図解ルール

「承認」と「共通認識」という2つの目的を果たすために、フロー図を書くときに守るべきルールが3つある。

ルール1：実態を書く──規程ではなく現場で起きていることを

フロー図に書くべきは「数字で語れる、言い訳のない現実」だ。

ここで大事な注意点がある。「良い・悪い」のジャッジをこの段階で入れてはいけない。良否の評価は次の「課題」の項目で行う。現状フローの段階では、事実を淡々と記録することだけに集中する。

規程通りのフローを「現状」として書いてしまうと、課題が隠れる。実際に起きていること——非公式の問い合わせルート、アクセスできないシステム、属人的な判断——を書くことで初めて課題が浮かび上がる。

例えば、「フィールドエンジニアはメンテナンスサポートにだけ問い合わせするはずだが、速く解決するために営業・開発にも直接問い合わせている」という実態があるなら、それをそのまま書く。規程通りに「フィールドエンジニア→メンテナンスサポート」とだけ書くのではなく、実際に複数ルートに問い合わせが飛び散っている状況を正直に記載する。

ルール2：課題を記号で可視化する──✗と△の使い方

フロー図に「課題がどこにあるか」を示す視覚的な工夫を加えることで、読み手が一目で問題を把握できるようになる。

形式（スイムレーン・BPMNなど）へのこだわりより、「課題が見えるか」が優先基準だ。

僕が実際に使っていた記法では、2つの記号を使い分けた。

• ✗：アクセス不可・機能していない接続を表す
• △：協力はされているが、負担が生じている状態を表す

工場設備のメンテナンス部門での提案書では、こう記載した。

フィールドエンジニア
　→✗　営業管理顧客データベース
　→✗　メンテナンス部門管理ファイルサーバー

※フィールドエンジニアは顧客データベースに権限不足でアクセスできない。
　ファイルサーバーにはアクセスできるが、必要なファイルを探せない。
　✗で「つながっていない・機能していない」を表現。

フィールドエンジニア
　→メンテナンスサポート
　→営業（本来は不要のはず）
　→開発（本来は不要のはず）

※速く解決するために社内のコネに問い合わせが飛び散っている実態。

営業　△
開発　△

※協力はしてくれているが、間接業務が増えて本業が削られている様子。
　△で「協力しているが負担が生じている」を表現。

記号と注記をセットで書くことで、図を見た瞬間に問題の構造が分かる。スイムレーンで美しく描かなくても、これで十分だ。

ルール3：次項の「課題」と対応させる

現状の業務フローに書いた内容と、次項「課題」に書く内容が一致していないと、提案書全体の論理が崩れる。

✗で示したアクセス不可の問題→課題「情報アクセスに関する権限・整備の不備」、△で示した間接業務の増加→課題「メンテナンスサポート以外の部門への負担集中」という形で、フロー図と課題が1対1で対応している状態が理想だ。

上の例でいえば、フロー図に「✗」が2箇所、「問い合わせの分散」が1件、「△」が2箇所ある。課題もこの3つの構造に対応して整理するべきだ。

課題の数値化と記述ルールについては、業務改善提案書の「問題点」はQCDで書く｜投資を通す数値化5ステップで詳しく解説している。

まとめ──フロー図は「課題の合意を取るための図」である

現状の業務フローは、投資判断のためではなく、「部長との承認（縦）」と「関係者との共通認識（横）」のために書く。

この目的を理解すると、3つのルールが自然に導かれる。

• ①実態を書く：規程ではなく現場で実際に起きていることを記録する
• ②課題を記号で可視化する：✗と△を使い、注記をセットで添える
• ③次項「課題」と対応させる：フロー図の問題点と課題の記述を1対1で整合させる

「このフロー図を見れば課題が分かる」状態になれば、部長の承認と関係者の共通認識は同時に取れる。それが提案書の核心部分（課題・改善案）を書くための土台になる。

業務改善提案書の他の項目の書き方は、業務改善提案書の書き方【構成と通し方を完全解説】にまとめている。