業務改善提案書の「解決策」はこう書く——通る提案と通らない提案の構造的違い

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

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

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

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

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

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

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

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

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

「解決策」に書きがちな、5つのNG類型

業務改善の現場で「解決策」として出てくる内容は、驚くほど似ている。

コンサルに入った現場で「課題に対する解決策を考えてください」と依頼すると、ほぼ毎回、以下の5パターンのどれかが出てくる。

①「気をつける」という意識づけ

チェックリストを活用する、ダブルチェックを徹底する、注意喚起を掲示する。現場が真剣に考えた結果として辿り着く答えだ。

②「努力する」

残業でカバーする、個人のスキルアップで対応する、ベテランが後輩を指導する。誠実な発想だが、これも解決策ではない。

③方法論としてのAI・DX

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

④「人」が解決策

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

⑤自由記入アンケート

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

冒頭のメンテナンス部門の担当者も、同じだった。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「気をつける」は方針だ。担当者が変われば気の使い方も変わる。「努力する」も方針だ。努力の量も質も個人に依存する。一方、「問い合わせ先はメンテナンスサポートのみとし、経由しない問い合わせは受け付けない」はルールとしての仕組みだ。担当者が誰であっても、ルールが存在する限り機能する。

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

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

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

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

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

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

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

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

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

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

仕組みとしての解決策:

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

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

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

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

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

仕組みとしての解決策:

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

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

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

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

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

仕組みとしての解決策:

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

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

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

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

課題と解決策の対応関係については業務改善提案書「課題」の書き方を参照してほしい。解決策の実施後に提出する効果測定については業務改善提案書「効果測定」の書き方で詳述している。

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

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

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

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

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

意識・努力・人・ツール・アンケートがNG類型に当てはまるなら、フロー・ルール・システムのいずれかで設計し直す。

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

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

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