業務改善提案書「解決策」の書き方——差し戻される4つのアンチパターンと通る設計の原則

業務改善を担当することになったある課長の顔に、苦さと疲れがにじんでいた。

「書き方を調べて、ちゃんと書いたんです。ECRS原則で整理して、フローも描いて。でも部長に見せたら『なんか違う』って。何が違うのか教えてもらえないんです。」

差し戻しは3回目だった。

この光景を、僕はコンサルとして入った現場で何度も見てきた。担当者は怠けているわけじゃない。調べ方が足りないわけでもない。「業務改善提案書 書き方」で検索すれば、丁寧な記事はいくらでも出てくる。

ECRS原則で分類する。改善前後のフローを対比させる。フェーズに分けてステップを書く。どれも正しい。

でも、差し戻される。

理由は一つだ。Webで学べる「書き方」は、解決策のフォーマットを教えてくれる。でも解決策の中身については、何も教えていない。

中身の問題には共通する4つのパターンがある。Web上で実際に掲載されている解決策の記載例を見ると、このいずれかに当てはまっていることが多い。

業務改善コンサルタントとして300社以上に提案してきた経験から、それぞれのNGサンプルとOKサンプルを対比しながら解説する。

業務改善提案書の全体構成については業務改善提案書の書き方を参照してほしい。本記事は「解決策」セクションに絞った解説だ。

業務改善提案書の解決策の書き方をWebで調べると何が出てくるのか

Webで調べられる「書き方」はフォーマットを教えるが、解決策の中身については何も教えていない。これが差し戻しの本当の原因だ。

経済産業省の「DX推進指標」では、業務改善・DXプロジェクトの多くが「何を変えるか」の定義不足により成果に結びつかないことが指摘されている。実際の業務改善の現場でも、解決策の記載が「意図」にとどまり「設計」に至っていないケースが繰り返し見られる。

「解決策をどう書けばいいか」を調べると、Web上には丁寧な答えが並んでいる。業務改善関連の主要サイト・テンプレート記事を複数横断して確認すると、以下のアドバイスが共通して登場する。

「誰が、何を、どのように取り組むかを具体的に書く」「既存のやり方との違いを明記する」「実施手順をステップで書く」——フレームワークとしてはECRS原則（排除・結合・交換・簡素化）が紹介されることが多い。改善前後のフロー（As-Is/To-Be）を対比させる書き方、フェーズに分けた実施計画を時系列で示す方法もある。

これらはどれも正しい。フォーマットとして有効だ。

しかし同じサイト上に掲載されている「解決策の記載例」を見ると、別の問題が見えてくる。

• 「電子文書管理システムを導入し、手作業による書類処理を削減する」
• 「業務フローの見直しとマニュアルの整備を行う」
• 「担当者の役割分担を再設定する」

形式は整っている。でも部長の立場から読んだとき、「それで誰が何をするのか」が見えない。300社以上への提案経験と、こうした実際のWeb上の記載例を照合すると、差し戻しを生む4つのパターンに分類できる。

アンチパターン①「意識・努力型」——「徹底する」「意識を高める」は解決策ではない

「意識を高める」「徹底する」が差し戻される理由は、個人の意識・努力に依存しており、担当者が替われば元に戻るからだ。

最も頻繁に出てくるアンチパターンだ。

Webの記載例には、こういった文章が並んでいる。「スタッフのコミュニケーション意識を高め、情報共有を徹底する」「スキルアップ研修を実施する」「経験豊富な担当者がノウハウを共有する機会を設ける」——読んだ瞬間は問題なく見える。でも立ち止まると、何か変だ。

現場のスタッフはすでに意識して働いている。すでに努力している。それでも課題が残っているから、提案書を書いている。努力で解決できるなら、とっくに解決していたはずだ。

NGサンプル

問い合わせ対応の品質を向上させるため、スタッフのコミュニケーション意識を高める。定期ミーティングを設け、情報共有を徹底する。

なぜ差し戻されるのか。三つの理由がある。

第一に、誰が・いつ・どの手順で実施するかが書かれていない。「意識を高める」は方針の表明であって、行動の設計ではない。第二に、担当者が替われば元に戻る。気をつける人が変われば、気のつけ方も変わる。第三に、「徹底する」という言葉は実現を保証しない。現場がすでに徹底しようとして、できていないから課題なのだ。

OKサンプル

フィールドエンジニアからの問い合わせ先をメンテナンスサポートに一本化するルールを業務フローに明記する。メンテナンスサポートを経由しない問い合わせは、各部門が受け付けない運用とする。この取り決めを関係部門の部長間で合意し、フロー図に明示する。

「受け付けない運用とする」という表現がポイントだ。やりたくてもできない状態を設計している。ルールが存在する限り、担当者が誰であっても同じように機能する。

アンチパターン②「ツール・DX型」——「システムを導入する」だけでは何も解決しない

「システムを導入する」が差し戻される理由は、ツール導入自体が解決策になっており、導入後に誰が何をどう変えるかが書かれていないからだ。

二つ目のアンチパターンは、ツールや技術を解決策とするパターンだ。

Web上の記載例には、「電子文書管理システムを導入する」「データ入力の自動化ソフトウェアの導入を検討する」「AIを活用する」「RPAを導入する」といった文章がある。ツール導入自体は間違いではない。問題は、それが解決策の全体になっているときだ。

NGサンプル

手作業による書類処理を削減するため、電子文書管理システムを導入する。データ入力の自動化ソフトウェアの導入も検討する。

部長が「それで何が変わるのか」と問い返す理由が分かるだろうか。

システムを導入した後、誰が何をどう変えるのかが書かれていない。「検討する」という表現が示す通り、解決策として確定もしていない。導入コストだけが見え、業務フローの何がどう変わるかが見えない。手段が目的になってしまっている。

OKサンプル

顧客情報・設備情報・対応履歴を組織として再活用できるデータベースに一元登録する。個人フォルダやチャットによる個人管理を廃止し、メンテナンス準備時に担当者が参照するステップを業務フローの必須ステップとして組み込む。

「個人管理を廃止する」という具体的なルール変更が含まれている。「必須ステップとして組み込む」ことで、やらないことができない仕組みになる。ツールは目的ではなく、仕組みを動かす手段として位置づけられている。

アンチパターン③「人・採用型」——「担当者を増やす」「育成する」は課題の先送りになる

「採用する」「育成する」が差し戻される理由は、属人化した環境を変えないまま人を入れ替えても、同じ属人化を繰り返すからだ。

三つ目のアンチパターンは、人の問題として解決しようとするパターンだ。

Webの記載例には、「即戦力を採用する」「スキルアップ研修を実施する」「担当者の役割分担を再設定する」といった解決策が紹介されている。中長期的には正しい方向かもしれない。でも業務改善提案書の解決策として書くと、部長に刺さらない。

NGサンプル

スキル不足を補うため、即戦力となる経験者を採用する。ベテランによるノウハウ共有の機会を設け、若手の育成を強化する。

なぜ差し戻されるのか。

属人化している環境を変えないまま新しい人を入れても、同じ属人化を繰り返す。「ベテランのノウハウ共有」はベテランが存在し続けることに依存しており、離職すれば元に戻る。採用コストが発生するため、部長はROIを問う。「育成を強化する」は方針であって、何をどう変えるかが書かれていない。

OKサンプル

メンテナンス完了後、フィールドエンジニアは設備名・トラブル症状・対応内容を所定フォーマットに記録する。次回の同設備メンテナンス準備時に、担当者は過去の記録を参照することを業務フローに組み込む。

「担当者が誰であっても同じ手順で動く」ことを前提に設計されている。特定の人物のスキルや記憶に依存しない。記録というフロー変更によって、新しい担当者も同じ情報にアクセスできる。

アンチパターン④「方針スローガン型」——「フローを見直す」「標準化を進める」は宣言であって実行計画ではない

「フローを見直す」「標準化を進める」が差し戻される理由は、誰がいつ何をするかが一切定義されておらず、個人の解釈でバラバラに動くからだ。

四つ目のアンチパターンが、最もやっかいだ。一見具体的に見えるが、実質的には空虚な宣言になっている。

Webで出てくる記載例には、「業務フローの見直しとマニュアル整備」「情報共有を徹底する」「標準化を進める」「担当者の役割分担を再設定する」などがある。業務改善らしい言葉が並んでいる。でも部長が「これを見て担当者が何をすればいいか分かるか？」と問うと、答えに詰まる。

NGサンプル

業務フローの見直しとマニュアルの整備を行い、担当者の役割分担を再設定する。情報共有を強化し、属人化を解消する。

「見直す」「整備する」「再設定する」という言葉には、何をどう変えるかが書かれていない。方針の表明にとどまっており、誰がいつ何をするかが一切定義されていない。「情報共有を強化」は①の意識・努力型と同じ問題を抱えている。手順がないため、個人の解釈でバラバラに動く。形骸化の典型だ。

OKサンプル

現状フローの月次報告書提出工程を廃止し、代わりに管理システムへのリアルタイム入力を必須とする業務ルールを設定する。変更後のフローをスイムレーン図として作成し、各ステップの実行者・タイミング・アウトプットを定義して部長承認を得る。

「廃止する」「必須とする」という動詞が、変更を実行する意思を示している。スイムレーン図を作成し、実行者・タイミング・アウトプットを定義することで、誰が見ても何をすべきか分かる状態になっている。

業務改善提案書の解決策の書き方を変える設計原則——「担当者が替わっても機能するか」という一問

差し戻しを防ぐ解決策とは、フロー・ルール・システムのいずれかで定義され、「誰がやっても同じ結果になる」仕組みとして設計されたものだ。

4つのアンチパターンに共通する欠陥は何か。

個人の意識・能力・努力・存在に依存していることだ。

意識・努力型は「気をつける人」に依存する。ツール・DX型は「ツールを正しく使う人」に依存する。人・採用型は「特定のスキルを持つ人」に依存する。方針スローガン型は「方針を自力で解釈して動ける人」に依存する。

担当者が替われば、どれも崩れる。

仕組みとして設計するとはどういうことか。フロー・ルール・システムのいずれかで定義し、「誰がやっても同じ結果になる」状態を作ることだ。

判断の問いは一つだ。

「この解決策は、担当者が入れ替わっても同じように機能するか？」

意識・努力型はNoだ。気をつける人が変われば変わる。ツール・DX型は条件付きだ。ツール導入後の運用ルールが定義されていればYesになる。人・採用型はNoだ。特定の人の能力に依存している。方針スローガン型もNoだ。手順がないため個人の解釈に委ねられる。

この問いにYesと答えられる解決策だけが、提案書に書く価値がある。

もう一つ補足しておく。業務改善提案書の「解決策」セクションには二つの目的がある。一つは部長との課題合意（縦の承認）だ。解決策の方向性を上位者に承認してもらうこと。もう一つは関係者との共通認識（横の合意）だ。実務メンバー全員が同じ解決イメージを持てること。仕組みとして設計された解決策だけが、この二つを同時に達成できる。

まとめ——業務改善提案書「解決策」の書き方を変える3つの確認ステップ

4つのアンチパターンを整理する。

解決策を書く前の確認ステップは三つだ。

1. この解決策はフロー・ルール・システムのどれで定義されているか
2. 誰が・いつ・何を・どこで・どのように、が書かれているか
3. 担当者が替わっても同じように機能するか

この三つにすべてYesと答えられたとき、初めて「解決策」として提案書に書く価値がある。

業務改善提案書の全体像については業務改善提案書の書き方を参照してほしい。解決策をさらに詳しく設計する方法については業務改善提案書の「解決策」はこう書くで解説している。課題の書き方については業務改善提案書「課題」の書き方も参考にしてほしい。