
業務改善プロジェクトは、提案書の質で通るかどうかが決まる。
私はこれまで300社以上の社内プロジェクトに関わってきた。予算規模は500万円から2,000万円以上、期間は6ヶ月から2年以上に及ぶものも多い。その経験から言えることは一つだ。決済者が「投資する」と判断できる提案書を書けるかどうかが、プロジェクト推進の最初の壁になる。
ハードルは予算だけではない。人的リソースの確保、関係部門の巻き込み、社内政治。これらを乗り越えるための武器として、業務改善提案書を設計する必要がある。
この記事では、提案書の目的・構成・各項目の書き方から、実際に承認を得るためのポイントまでを体系的に解説する。
業務改善提案書の目的を正しく理解する

提案書を書く前に、この2つの目的を明確にしておく。
業務改善そのものの目的
業務改善は手段であって、ゴールではない。提案書に書くべき目的は、会社のミッションや事業計画の達成に直結するものでなければならない。「作業を楽にしたい」は目的ではない。「売上目標の達成に必要な受注処理能力を確保する」が目的になる。
業務改善提案書の目的
提案書には2つの役割がある。
① 決済者の投資判断を引き出す
決済者は複数のプロジェクト候補の中から予算と人員を配分する。提案書は、「なぜ今、このプロジェクトを最優先にすべきか」を論理的に示す文書だ。
② 関係者の協力を得る
プロジェクト推進者だけでは何も動かない。関係部門の担当者が「自分にも関係がある」「協力しないと損する」と感じる設計が必要になる。
提案書の標準構成と全項目

以下が業務改善提案書の標準構成だ。すべての項目に記載する理由がある。
| # | 項目 | 主な目的 |
|---|---|---|
| 1 | タイトル | プロジェクトの方向性を一言で示す |
| 2 | 日付 | 最新版であることを示す |
| 3 | 推進者 | 誰が責任を持つかを示す |
| 4 | 業務改善の目的 | ミッション・事業計画との接続 |
| 5 | 対象の範囲 | 今回扱う業務・部門の境界線を引く |
| 6 | 問題点 | 現状のコスト・リスクを数値化する |
| 7 | 現状の業務フロー | 課題が見える形で現状を可視化する |
| 8 | 課題 | ボトルネックの特定 |
| 9 | 解決策 | ボトルネックへの対処方法 |
| 10 | 改善後の業務フロー | 改善後の姿を示す |
| 11 | 期待する効果 | 問題点が解消される根拠 |
| 12 | 検証内容 | 本運用前に小さく確認する計画 |
| 13 | 検証結果 | 検証で得られた数値の記録 |
| 14 | 必要な予算 | 外部支出の明細 |
| 15 | 必要なリソース | 社内工数の明示 |
| 16 | スケジュール | 合意・作業・検証・本運用の流れ |
| 17 | 進め方 | ミーティング頻度・作業時間の確保 |
| 18 | 体制 | 役割と責任の明確化 |
| 19 | リスク | 想定される遅延・障害の開示 |
構成ごとの書き方【詳細解説】

タイトル
ミッション達成との接続が読み取れるタイトルにする。表現はポジティブに保つ。
悪い例:「経理部門の残業削減について」
良い例:「月次決算の精度向上と処理効率化による財務基盤強化」
ネガティブな言葉(削減・廃止・排除)は決済者の印象を下げる。「強化・向上・確立」に置き換えるだけで受け取られ方が変わる。
タイトルの具体的な組み立て方は、業務改善提案書のタイトルの書き方|中期経営計画と連動させる3ステップで詳しく解説している。
日付
作成日と改訂日を併記する。提案書が複数バージョン出回ることは珍しくない。最新版が明確でないと、古い内容で議論が始まるリスクがある。
推進者
推進者の名前のみ記載する。「責任者」「決済者」「各部門担当者」は後述の「体制」に記載する。ここでは誰が動かすのかを一点で示す。
業務改善の目的
タイトルと一貫性を持たせる。「〇〇事業の売上目標XXX億円達成に必要な処理能力の確保」のように、事業数値と接続させるほど意思決定者には刺さる。
目的の設定を中期経営計画と紐づける具体的な方法は、業務改善提案書「目的」の書き方|中期経営計画と連動させる実践ガイドで解説している。
対象の範囲
最も軽視されやすく、最も重要な項目の一つだ。
対象を明確にする理由は2つある。
- 課題・解決策・効果の議論がブレなくなる
- 「あれもやれ、これもやれ」という追加要求を論理的に断れる
書き方のポイントは、部門名・業務名だけでなく「何を達成するための業務か」を明記すること。例:「受注処理部門(月次売上XXX億円の受注処理を担う)」
記載項目と実例については、業務改善提案書「対象の範囲」の書き方【記載項目と実例】に詳しくまとめている。
問題点
「なんとなく非効率」では予算は下りない。数値で語ることが必須だ。
- 目に見えるコスト:残業代、外注費、システム費用など
- 目に見えないコスト:対応遅延による機会損失、ミスによる再作業時間、属人化リスクなど
目に見えないコストは特に重要だ。「月に〇時間×〇人×時給換算=年間〇〇万円相当の非効率」という形で数値化する。ここで具体性が出ると提案全体の信頼度が上がる。
QCDの視点を使った数値化の5ステップは、業務改善提案書の「問題点」はQCDで書く|投資を通す数値化5ステップで詳しく解説している。
現状の業務フロー
フロー図(スイムレーン形式が推奨)で、部門・担当者の役割とフローを可視化する。この図は次項「課題」の根拠になるため、課題として指摘したいポイントが図の中で自然に読み取れるように作る。
ツールはLucidchart、draw.io、PowerPoint、Excelのいずれでも構わない。重要なのは「誰が見ても同じ理解になること」だ。
現状フロー図を設計するときに押さえるべき3つの目的と図解のルールは、業務改善提案書「現状の業務フロー」で押さえるべき3つの目的と図解のルールで詳しく解説している。
課題
ボトルネックを明記する。フレームワークを使うと抜け漏れが防げる。
よく使われるフレームワーク:
- 4M分析(Man・Machine・Method・Material):製造・業務プロセス系
- なぜなぜ分析:根本原因の掘り下げ
- フィッシュボーン(特性要因図):複数の要因を整理する場合
- バリューチェーン分析:業務全体の付加価値を整理する場合
フレームワークを使う利点は「視点の網羅性」だ。「言い忘れた」「別の課題もある」という指摘が出にくくなる。
QCDとルール視点で課題を整理する具体的な方法は、業務改善提案書の「課題」の書き方:QCDとルール視点で整理するコンサルタント直伝のフレームワークにまとめている。
解決策
課題(ボトルネック)に対して、一対一で解決策を示す。課題が3つあれば、解決策も3つ示す構成が基本だ。
解決策には複数の選択肢を示し、採用する選択肢の理由を添えると説得力が増す。「A案・B案を検討した結果、コストと実現可能性でA案を選択」という形だ。
改善後の業務フロー
現状フロー図と同じ形式・同じ視点で作成する。比較が容易になり、「何がどう変わるか」が一目で伝わる。
フロー図の変更点(削除・追加・変更した工程)は色分けや注記で明示する。改善後フローの作成で承認が通らない本質的な落とし穴については、業務改善提案書「解決後の業務フロー」の書き方|承認が通らない人が気づいていない本質的な問題で詳しく解説している。
期待する効果
「問題点」で挙げた課題に対応する形で記載する。
- 一次効果:直接解決するもの(例:月次残業XX時間削減)
- 二次効果:副次的に改善するもの(例:ミス率低下、引継ぎコスト削減)
数値で示せるものは必ず数値にする。「改善される」ではなく「年間XX万円相当の工数が削減される」が正しい書き方だ。
なお「期待する効果」は、決裁者向けKPI(コスト削減・ROI)と実務担当者向けKPI(時間・件数・人日)の2種類に分けて設計しないと、承認は取れても現場が動かない事態が起きる。2種類の設計方法は業務改善提案書「期待する効果」の書き方——決裁者用と実務担当者用を分けないと承認されないで解説している。
検証内容
大規模な業務改善は、いきなり全社展開しない。小さく検証してから本運用に入るのが鉄則だ。
検証設計の3原則:
- 短期間・少予算で完結できる範囲に絞る
- 仮説(解決策)がボトルネックを解消するか確認できる内容にする
- 判断軸(合格基準)を数値で決めておく(例:「処理時間が現状比30%以上削減されれば本運用に進む」)
判断軸を事前に決めておかないと、検証後に「これで十分か」という定性的な議論が発生する。数値基準を先に合意しておくことで、結果の判断が速くなる。
検証結果
検証後に追記する。仮説どおりだったか、想定外はあったか、本運用に向けた修正点はあるかを記録する。
数値で結果を示すことが最優先だ。「うまくいった」ではなく「処理時間がXX%削減、ミス件数がXX件→XX件に減少」と書く。
必要な予算
機器導入・システム導入・外注費など、外部への支出を明細形式で記載する。
| 項目 | 内容 | 費用(税抜) |
|---|---|---|
| システム導入 | ○○ツール初期費用 | XXX万円 |
| 外注作業 | データ移行作業 | XXX万円 |
| 合計 | — | XXX万円 |
社内人件費(工数)は「必要なリソース」に分けて書くことで、外部支出の規模が明確になる。
必要なリソース
社内の工数を見える化する。決済者は外部費用だけでなく、「社内の誰が何時間取られるか」も判断材料にする。
| 担当者/部門 | 役割 | 想定工数 |
|---|---|---|
| 推進者 | 全体管理・関係者調整 | 週XX時間×XX週 |
| IT部門 | システム設定・テスト | XX時間 |
| 現場担当者 | 検証・操作確認 | XX時間 |
スケジュール
ガントチャート形式が読みやすい。最低限含めるべき項目:
- 責任者・決済者への説明と合意
- 関係者への説明と巻き込み
- 検証期間
- 本運用開始
- 検収・支払い
決算期をまたぐかどうかは必ず確認する。期中で予算が消化できなければ、翌年度に持ち越しになるケースは多い。
進め方
定例ミーティングの頻度と、業務改善専用の作業時間の確保を明記する。「進捗会議を週1回、毎週火曜15:00〜16:00で実施」のように具体化することで、関係者に時間拘束の見通しを持たせられる。
体制
役割と責任者を一覧化する。
| 役割 | 担当者 | 部門 |
|---|---|---|
| 決済者 | ○○部長 | 経営管理部 |
| 責任者 | ○○課長 | ○○部 |
| 推進者 | 氏名 | ○○部 |
| 現場担当(A部門) | 氏名 | A部門 |
| 現場担当(B部門) | 氏名 | B部門 |
リスク
想定されるリスクを事前に開示することで、プロジェクトへの信頼性が上がる。隠すのではなく、先に出すのが正しい使い方だ。
主なリスクの例:
- 検証が想定通りの結果にならない場合、スケジュールが延長する可能性がある
- 決算期をまたぐと予算確保が翌年度になる可能性がある
- 人事異動によるメンバー交代が生じた場合、調整工数が増える可能性がある
なお、事前に対処・予防できる大きなリスクは、リスク項目に書く前に対策を打つ。リスク欄は「発生しうるが事前制御が難しい不確実性」を書く場所だ。
承認を取り付けるためのポイント

提案書の目的は「判断材料の提供」
すべての項目は「決済者が投資を判断できるか」「関係者が協力する気になるか」の2軸で設計する。情報の網羅が目的ではなく、判断を促すことが目的だ。
決済者視点で重要なのは、このプロジェクトが他の候補と比べて最優先である理由だ。「問題点」での数値化と「期待する効果」でのROI提示が、その判断材料になる。
関係者への訴求で重要なのは、協力しないことのデメリットを間接的に示すことだ。「このプロジェクトが進まないと、現場の作業量は増え、評価にも影響しうる」という文脈を設計する。
定量化を徹底する
「改善できる」「効率が上がる」は意思決定の根拠にならない。数値・金額・時間に変換することで初めて投資判断の土台になる。
フレームワークで網羅性を担保する
フレームワークを使わず書いた課題分析は、「他にも課題があるのではないか」という疑念を生む。4M分析・フィッシュボーン・バリューチェーンなどを使うことで、網羅性を示し、指摘を減らせる。
社内プロジェクトの進め方で押さえること

提案書は、社内プロジェクト推進において合意形成の手段の一つとして機能する。
縦(決済ライン)と横(関係部門)の双方の合意がなければ、どれだけ良い提案書でも動かない。特に横の合意形成——関係部門が「自分も関係がある、協力したほうが得だ」と判断する設計——は提案書の外で行う必要がある。
合意形成の具体的な進め方については、別の記事で詳しく解説する。
