業務改善提案書「解決策」の書き方｜差し戻される5つのNG類型と仕組みとして書く原則

工場設備のメンテナンス部門に業務改善コンサルとして入ったとき、担当者に「解決策を考えてきてください」と依頼したことがある。

翌週、担当者が持ってきた提案書の「解決策」欄には、こう書いてあった。

「現場のコミュニケーションを強化する」

「スキルアップに努める」

内容が間違っているわけではない。でも、これは解決策ではなく、願望だ。

誰がいつどこで何をするのか、どのルールやフローを変えるのか——何も書かれていない。部長が「これじゃ解決にならない」と差し戻すのも、無理はなかった。

解決策の欄を埋めようとして、何度も差し戻される。何が足りないのか分からない。そういう経験は、業務改善の現場で繰り返し聞いてきた話だ。

担当者の顔には焦りと疲弊が滲んでいた。「ちゃんと考えたのに、また違うと言われた」という落胆は、繰り返されるほど深くなる。でも、これは担当者の考える力が足りないのではない。解決策の「設計思想」に問題があるだけだ。

「業務改善提案書 書き方」で調べれば、ECRS原則（排除・結合・交換・簡素化）で整理する、改善前後のフロー（As-Is/To-Be）を対比させる、フェーズに分けて手順を書く、といった丁寧な解説がいくらでも出てくる。どれも正しい。ただ、それらが教えてくれるのは解決策のフォーマットであって、中身ではない。形式を整えても差し戻されるのは、中身が次の5つのNG類型に当てはまっているからだ。

業務改善提案書の全体像を把握したい場合は業務改善提案書の書き方を参照してほしい。本記事は「解決策」セクションに絞った解説だ。課題の書き方については業務改善提案書「課題」の書き方で詳しく解説している。

業務改善提案書の「解決策」で差し戻される5つのNG類型

業務改善の現場で「解決策」として出てくる内容は、驚くほど似ている。コンサルに入った現場で「課題に対する解決策を考えてください」と依頼すると、ほぼ毎回、次の5類型のどれかが出てくる。Web上の解決策の記載例を見ても、多くがこのいずれかに当てはまる。

①意識・努力型——「徹底する」「気をつける」「頑張る」

チェックリストを活用する、ダブルチェックを徹底する、注意喚起を掲示する、残業でカバーする、ベテランが後輩を指導する。現場が真剣に考えた結果として辿り着く答えだ。

NGサンプル：

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

誰が・いつ・どの手順で実施するかが書かれていない。「意識を高める」は方針の表明であって、行動の設計ではない。そして現場はすでに意識し、努力している。それでも課題が残っているから提案書を書いているのだ。

②ツール・DX型——「システムを導入する」「AIを活用する」

「AIを使えばよい」「デジタル化すれば解決する」。技術に期待する発想は自然だが、手段が目的になっている。

NGサンプル：

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

導入した後に、誰が何をどう変えるのかが書かれていない。「検討する」という表現のとおり、解決策として確定もしていない。部長には導入コストだけが見え、業務フローの何が変わるかが見えない。

③人・採用型——「即戦力を採用する」「育成を強化する」

即戦力を採用する、経験を積んでスキルを向上させる、役割分担を再設定する。中長期的には正しい方向でも、今の課題の解決策にはならない。

NGサンプル：

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

属人化した環境を変えないまま人を入れても、同じ属人化を繰り返す。ベテランのノウハウ共有はベテランがいることが前提で、離職すれば元に戻る。採用コストもかかるので、部長はその費用に見合うのかを問う。

④方針スローガン型——「フローを見直す」「標準化を進める」

一見具体的で、業務改善らしい言葉が並ぶので、最もやっかいな類型だ。

NGサンプル：

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

「見直す」「整備する」「再設定する」には、何をどう変えるかが書かれていない。部長が「これを見て担当者が何をすればいいか分かるか？」と問うと、答えに詰まる。手順がないので、個人の解釈でバラバラに動くことになる。

⑤アンケート型——「現場の意見を集める」

「どのようにしたいですか？」と現場に聞き、意見を集める。参加を促すのは良いことだが、アンケートは解決策ではなく課題の収集にしかならない。

NGサンプル：

業務改善の方向性を決めるため、全担当者に自由記入のアンケートを実施し、意見を反映した改善策を検討する。

「どうしたいですか？」という問いには要望しか集まらない。それぞれの立場からバラバラの希望が出てきて、どれを採るかの判断は結局先送りになる。要望は解決策ではない。

④だけは書き直しの例もここで示しておく。④を仕組みとして書くと、次のようになる。

OKサンプル：

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

「廃止する」「必須とする」という動詞が、何を変えるかを示している。実行者・タイミング・アウトプットを定義しているので、誰が読んでも何をすべきか分かる。①〜③のOKサンプルは、後半の品質・コスト・納期の実例で示す。

冒頭のメンテナンス部門の担当者も、同じだった。「問い合わせが多くて困っている」という課題に対して、「問い合わせ対応のスキルを向上させる」という解決策を持ってきた。言いたいことは分かる。間違ってもいない。ただ、それは解決策ではなく、現状への諦めに近い。

なぜそれは解決策にならないのか——「仕組みのない解決策」が形骸化する構造

この5つのNG類型には、共通する構造がある。

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

「気をつける」「努力する」は、すでに現場が実行している。もし努力で解決できるなら、今頃解決しているはずだ。それでも課題が残っているのは、努力が足りないからではなく、仕組みがないからだ。

人は忘れる。楽な方に流れる。忙しければルールを後回しにする。仕組みがなければ、どれだけ優秀な人材が揃っていても、同じことを繰り返す。

「仕組み化」とは、個人のスキル・努力・意識に依存せず、誰がやっても同じ結果を出せる再現性のある状態を構築することだ。

「AI・DX」の問題は、技術を導入すること自体を解決策と見なしていることにある。「なぜAIを使うのか」「どのプロセスの何を解決するのか」が書かれていなければ、部長は「それで何が変わるのか」と問い返す。

「人（採用・育成）」の問題は、「属人化」した環境を変えないまま新しい人を入れることにある。記録ルールがなければ、新人も同じ属人化を繰り返す。離職すれば元に戻る。

「方針スローガン」の問題は、方針を自分で解釈して動ける人がいることを前提にしていることだ。解釈は人によって違うので、同じ方針から違う行動が生まれる。

「アンケート」の問題は、「どうしたいですか？」という問いには要望しか集まらないことだ。「今後はどのように働きたいですか？」と聞けば、それぞれの観点からバラバラな希望が出てくる。要望は解決策ではない。

メンテナンス部門で「問い合わせが多い」という課題に対して「コミュニケーションを改善する」という解決策が出たとき、僕はこう聞いた。「誰が、いつ、どのような手順でコミュニケーションを改善するのですか？」

担当者は答えられなかった。手順がなければ、個人の解釈でバラバラに動くだけだ。これが「形骸化」の正体だ。立派な解決策に見えても、仕組みになっていなければ、時間が経てば元に戻る。

「解決策」の設計原則——仕組みとして書くための判断軸

解決策が「仕組みになっているか」を判断する問いは一つだ。

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

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

先のNG5類型をこの問いで評価してみる。

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

一方、「問い合わせ先はメンテナンスサポートのみとし、経由しない問い合わせは受け付けない」はルールとしての仕組みだ。担当者が誰であっても、ルールが存在する限り機能する。

業務改善提案書の「解決策」セクションには2つの目的がある。

ひとつは部長との課題合意（縦）。解決策の方向性を上位者に承認してもらうこと。もうひとつは関係者との共通認識（横）。実務メンバー全員が同じ解決イメージを持てること。

この2つを同時に達成できるのは、「誰がやっても同じ結果になる仕組みとして書かれた解決策」だけだ。

ひとつ補足しておく。すべての業務を仕組み化する必要はない。経験と判断に依存する「感覚型」の業務はあえて対象外にする。単純型・選択型の業務を仕組み化し、感覚型は属人性を残す。この線引きを提案書に明示すると「現場の実態を理解した提案」として評価される。

また、「解決策」セクションは投資判断の場ではない。「いくらかかるか」ではなく「何を変えるか」を合意する場だ。この区別を明確にすることで、部長との合意が取りやすくなる。

実例で見る「仕組みとして設計された解決策」の書き方——品質・コスト・納期の3課題

工場設備のメンテナンス部門で、品質・コスト・納期の3つの課題に対して、どう解決策を設計したかを実際に見ていく。

品質課題——知識の属人化と再発防止

課題の要約: 複数の工場・設備で同じ問題が繰り返し発生している。知識が属人化しており、担当者が毎回1から調査して対処している。対応にヌケモレが生じ、トラブルが再発している。

NG解決策の例とその理由: 「スキルアップ研修を実施する」「経験豊富な担当者がノウハウを共有する機会を設ける」——いずれも人に依存した解決策であり、担当者が変わると形骸化する。

仕組みとしての解決策:

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

「誰が・いつ・何を・どのフォーマットで」が明記されている。担当者が入れ替わっても同じ手順で動く。記録する義務がフローに組み込まれているため、やらない選択ができない。

コスト課題——情報管理の個人依存と問い合わせ多発

課題の要約: 準備時に顧客情報・設備情報・技術情報を探すのに時間がかかる。フィールドエンジニア・メンテナンスサポートの情報が個人管理され、組織内で再活用できない。現地での問い合わせが多発している。

NG解決策の例とその理由: 「情報共有を徹底する」——方針であり、仕組みではない。「AIを活用する」——何のAIを、どのプロセスにどう使うのかが書かれておらず、方法論にとどまっている。

仕組みとしての解決策:

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

「個人管理を廃止する」という具体的なルール変更が含まれている。「必須ステップとして組み込む」ことで、やらないことができない仕組みになっている。

納期課題——問い合わせ経路の混乱と営業・開発部門への負荷

課題の要約: フィールドエンジニアからの問い合わせ先はメンテナンスサポートのみというルールがあるが、徹底されていない。返信が少しでも遅いと営業部門や開発部門に直接問い合わせており、不要な業務負荷が発生している。

NG解決策の例とその理由: 「コミュニケーションを改善する」——方針であり、誰が何をするかが分からない。「担当者の意識を変える」——意識づけは仕組みではない。ルールを知っていても守れない環境が問題だ。

仕組みとしての解決策:

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

「受け付けない運用とする」という言葉が、「やりたくてもできない」仕組みを作っている。部長間の合意を取り込んでいるため、提案書に書いてある通りに現場が動くことが保証される。

これら3つの解決策に共通しているのは「意識・努力・人・ツールに依存していない」という点だ。

ルール変更・記録義務化・システムによる一元管理・部門間の合意による経路固定——いずれも仕組みとして設計されているため、担当者が入れ替わっても同じように機能する。

課題と解決策の対応関係については業務改善提案書「課題」の書き方を参照してほしい。解決策によって得られる効果の書き方については業務改善提案書「期待する効果」の書き方で詳述している。

まとめ——解決策は「仕組み」として書く

業務改善提案書の「解決策」が差し戻される理由は、能力や努力の差ではない。

解決策が「仕組みとして設計されているか」という設計思想の差だ。

自分の書いた解決策を見直すときは、この一問を使えばいい。

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

解決策を書き終えたら、次の3つを確認する。

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

1つでもNoがあれば、フロー・ルール・システムのいずれかで設計し直す。

品質・コスト・納期の3課題に対応した解決策は、いずれも「フローのルール変更」「情報DBの設計」「問い合わせ経路の明文化」だった。難しい技術は何も使っていない。仕組みとして設計しただけだ。

解決策セクションには2つの目的がある——部長との課題合意（縦）と、関係者との共通認識（横）。この両方を達成できる解決策は、仕組みとして設計された解決策だけだ。

業務改善提案書の全体的な承認プロセスについては承認を通す提案書の戦略も参照してほしい。