業務改善提案書「必要なリソース」でやりがちな5つのミス｜書き方NG→OK解説

業務改善コンサルタントとして300社以上の企業に関わってきた中で、「リソース欄を書いたのに差し戻された」という相談を何度も受けてきた。

「費用もちゃんと書いた。人数も書いた。なのに上司から『内容が薄い』『もっとヒアリングして』と言われた」

その言葉を聞くたびに、僕は同じことを思う。書き方に問題があるだけだ、と。

リソース欄が差し戻されるのは、書いた内容の量が少ないからではない。「誰に何を伝えるために書いているか」という設計が抜け落ちているからだ。

推進者がリソース欄に費やした時間も労力も、間違っていない。問題は書き方のパターンだ。300社以上の現場で繰り返し確認してきた経験から言えば、差し戻しの原因はほぼ5つのパターンに絞られる。このパターンを知っていれば、今日中に修正できる。

業務改善提案書全体の構成については業務改善提案書の書き方【構成と通し方を完全解説】もあわせて確認してほしい。

業務改善提案書「必要なリソース」に多い5つの書き方ミス

業務改善提案書のリソース欄が差し戻される原因は、ほぼ5つの書き方パターンに絞られる。合計時間のみの記載・社内工数の省略・根拠なし見積もり・抽象的な作業内容・担当部署漏れ——この5つを事前につぶせば、差し戻しの大半は防げる。

コンサルタントとして製造業・工場設備メンテナンス・サービス業など300社以上のプロジェクトに関わる中で、リソース欄が差し戻される原因はほぼ5つのパターンに絞られることを確認してきた。

以下、各パターンをNGサンプルとOKサンプルで対比する。

ミス1：全フェーズを合算して「合計〇時間」で書く

「プロジェクト全体で合計100時間必要です」という書き方は、部門長に何も伝えていない。

部門長が承認時に最も確認したいのは、本業インパクトだ。自分の部署が「最も忙しい週に何時間取られるか」が読めないと、本業が回るかどうかを判断できない。

実際にこういう場面があった。担当者が合計時間のみ記載したリソース欄を持ってきた案件で、部門長が「本業がどれだけ影響を受けるかわからない」と承認を保留にした。フェーズごとに週あたり時間を書き直したら、その日のうちに承認が下りた。違いは書いた量ではなく、部門長が判断できる情報があったかどうかだけだった。

NG

OK（工場設備メンテナンス部門の実例）

「最も忙しいフェーズ2でも週5時間で済む」という判断が、この形式で初めてできる。

ミス2：社内メンバーの工数を書かない

「自分たちが頑張ればタダ」という思い込みで、社内の工数をリソース欄に書かないケースがある。

これは後から問題になる。承認後に現場が「こんなに時間を取られるとは聞いていない」と反発する原因になるからだ。内部工数は立派なコストだ。プロジェクトに関わるメンバーの工数（人数×時間）を書かないと、計画が現実から乖離したものになる。

NG

（社内メンバーの工数は一切記載なし）

OK

社内工数は金額換算しなくていい。人数×時間で記載するだけで、「現実的な計画」として信頼度が上がる。

ミス3：根拠のない「だいたい〇時間」で見積もる

担当者の体感値をそのまま書くのは危険だ。

製造業（工場設備メンテナンス部門）の現場に入り、担当者立ち会いのもとでストップウォッチを使って作業時間を実際に計測したことがある。「体感で3時間くらい」と言っていた作業が、実測では5.5時間かかっていた。これは1件の例外ではない。製造業・サービス業を含む複数の案件で体感値と実測値を比較してきたが、体感より実測が長くなるケースが大半だった。

人間の体感と実測値にはズレがある。担当者が嘘をついているわけではない。そういうものだ。

問題は、その体感値をそのまま提案書に書いたとき、後から「やっぱりもっとかかります」と言い出すことになる点だ。そう言い出した瞬間、部門長と担当者双方の信頼を失う。承認後に追加稼働を認めてもらうのは、最初に正直に書くより何倍も難しい。

NG

「新システム設計：だいたい週3〜4時間くらい（担当者の感覚）」

OK

「新システム設計：週3時間（過去の類似作業の実績時間＋バッファ1割）」

近い業務の実績から算出し、1〜2割多めにバッファを積む。「根拠はどこから？」と聞かれたときに答えられる状態にしておくことが重要だ。

ミス4：作業内容が抽象的（「打ち合わせ」「作業」「参加」）

「打ち合わせ：週3時間」と書かれても、担当者は「どんな打ち合わせか」がわからない。「作業」では何をするのかゼロ情報だ。担当者が自分の関わり方をイメージできないと、協力を得にくくなる。

NG

OK

作業内容は「動詞＋目的語」の形で書く。「何をやるか」が一言でわかる粒度が正解だ。

ミス5：関係部署が1つしか書かれていない

複数部署が関わるプロジェクトなのに1部署しか記載がないと、後から「あの部署は何時間使うのか」という疑問が出て差し戻される。また、漏れた部署から後でクレームが発生することもある。

NG

メンテナンス部のみ記載（情報システム部・品質管理部が関わるにもかかわらず）

OK

メンテナンス部 / 情報システム部 / 品質管理部をそれぞれフェーズ別に記載

プロジェクトに関わる可能性のある部署をすべてリストアップしてから記入する。「体制」欄と連動させると漏れを防ぎやすい。体制欄の設計については業務改善提案書の「体制」で名前を書くべき理由も参照してほしい。

業務改善提案書「必要なリソース」の正しい書き方｜2者への合意取得から逆算する

リソース欄の正しい書き方は、「部門長と担当者の2者への合意取得」という目的から逆算して設計することだ。部門長にはフェーズ別×週あたり時間で本業インパクトを、担当者には動詞＋目的語の作業内容で自分の関わり方を伝える。

5つのミスを並べると、共通点が見えてくる。

「誰に、何を合意させるためにこの欄を書いているか」という目的が抜け落ちているということだ。

リソース欄の本来の目的は、2者への合意取得ツールとして機能させることだ。この「2者」とは、部門長と実務担当者を指す。

部門長が知りたいのは「自分の部署の本業がどれだけ影響を受けるか」だ。だからフェーズ別×週あたり時間で書く必要がある。合計時間では判断できない。

担当者が知りたいのは「自分はいつ、何をやるのか」だ。だから作業内容を動詞＋目的語で書く必要がある。「打ち合わせ」では何も伝わらない。

この目的から逆算すると、5つのNGがなぜNGなのかが一気に整理できる。

• 合計時間のみ → 部門長が本業への影響を判断できない
• 社内工数ゼロ → 計画の現実感が伝わらない
• 根拠なし見積もり → 後から信頼を損なうリスクがある
• 抽象的な作業内容 → 担当者が自分の動き方をイメージできない
• 担当部署漏れ → 後から「あの部署は？」となる

書き方の設計原理を整理するとこうなる。

• フェーズ別×週あたり時間：部門長が本業との両立を判断できる
• 動詞＋目的語の作業内容：担当者が自分の関わり方をイメージできる
• バッファ1〜2割：後から「もっとかかる」と言い出せない状況を事前に防ぐ
• 個人名は書かない：個別の人事議論が始まるのを避け、承認の焦点をずらさない

必要なリソース欄のテンプレートとコピペ用サンプルは【コピペOK】業務改善提案書の書き方——必要なリソース欄のテンプレートと記入ガイドで公開している。

提出前チェックリスト——「必要なリソース」欄はこれで完成

提出前に5項目を確認すれば、リソース欄の差し戻しはほぼ防げる。フェーズ分割・社内工数・見積もり根拠・作業内容の具体性・部署の網羅——この5点が揃っていれば提出できる。

リソース欄を書き終えたら、提出前に以下の5項目を確認してほしい。

• [ ] フェーズごとに分けて週あたり時間を記載しているか
• [ ] 社内メンバーの工数（人数×時間）が記載されているか
• [ ] 各項目の時間に根拠（実績・計測値＋バッファ）があるか
• [ ] 作業内容が「動詞＋目的語」の具体的な形になっているか
• [ ] 関係する部署がすべて網羅されているか

5項目すべてにチェックが入れば、差し戻しの可能性は大幅に下がる。

1つでもチェックが入らない項目があれば、本文の該当ミスのセクションに戻って修正してほしい。

まとめ——リソース欄の差し戻しはパターンで防げる

5つのミスは「合計時間のみ」「社内工数ゼロ」「根拠なし見積もり」「抽象的な作業内容」「担当部署漏れ」だ。このパターンを知っていれば、差し戻しの原因を事前につぶせる。

リソース欄の本来の目的は、部門長と担当者への2者への合意取得だ。部門長には本業インパクトを、担当者には自分の関わり方を見せることが設計の軸になる。

今日中に修正できる。提出前チェックリストを使えば、漏れなく確認できるはずだ。

業務改善提案書の全体構成・各項目の書き方については業務改善提案書の書き方【構成と通し方を完全解説】で解説している。リソース欄以外の項目も、同じように「誰に何を合意させるか」という目的から設計することが、承認への近道だ。