業務改善提案書のスケジュールの書き方｜WBSを使ってはいけない3つの理由と、4つの合意ラインで書く実例

工場の設備をメンテナンスする企業に、業務改善コンサルタントとして入ったときのことだ。

メンテナンス部門の担当者が作った提案書を見せてもらった。

スケジュール欄には、WBS形式で「現状調査」「課題整理」「システム選定」「試験導入」「本番稼働」と、タスクとマイルストーンが丁寧に記されていた。

部長への説明に同席したとき、部長はそのスケジュールを一目見てこう言った。

「で、私はいつ何を確認すればいい？」

担当者は言葉に詰まった。

スケジュールはきちんと書いた。形式的には正しい。

WBSもガントチャートも、業務改善提案書の書き方を調べると必ず出てくる定番の方法だ。

なのに何かが足りなかった。

業務改善提案書にWBSやガントチャートを貼るのは、当たり前の選択だ。

多くの解説サイトや書き方テンプレートにも「スケジュールはガントチャートで視覚化すると分かりやすい」と書かれている。

事実、Web上で確認できる提案書テンプレートの多数がこの形式を推奨している。

でも、それが承認を遠ざけている。

WBSで丁寧に書いたのに承認者の反応が鈍い。

いつも同じような質問で止まる。

そういう経験が、300社以上に関わる中で何度もあった。

業務改善提案書の全体構成については業務改善提案書の書き方【構成と通し方を完全解説】で詳しく解説している。

この記事では、スケジュール欄の設計に絞って話す。

業務改善提案書のスケジュール書き方でよくある3つのNGパターン

結論：業務改善提案書のスケジュールには、タスク一覧型・ガントチャート型・フェーズ分割型という3種類のNGパターンが存在する。いずれも「推進担当者の作業管理」視点で設計されており、「承認者が自分の出番を確認できる」設計になっていないため、承認が止まる。

「スケジュール欄はガントチャートで」という助言は正しい。

作業の期間と重なりが一目でわかるし、進捗管理もしやすい。

問題は、誰のための「わかりやすさ」なのかだ。

以下の3種類のスケジュールを見てほしい。

いずれもWeb上の提案書テンプレートで広く推奨されている標準的な書き方だ。

NG①：タスク一覧（箇条書き）型

最もシンプルな形で、A4一枚の提案書によく使われる。

マイルストーンと日付を列挙するだけで完成するため、手軽に書ける。

提案書テンプレートのほとんどに掲載されている形式だ。

【スケジュール】
11/1（水）  部長承認
11/6（月）  マニュアル完成
11/7〜10   説明・教育
11/13（月） 運用開始

部長の視点で見ると、「11/1に承認する」という1行があるだけだ。

「何を確認して承認するのか」「自分はどこまで事前に把握しておけばいいのか」が何も書かれていない。

部長にとって、このスケジュールは「突然ハンコを求められる予定表」でしかない。

NG②：ガントチャート（工程表）型

詳細な提案書で推奨されている形式だ。

横軸に時間、縦軸にタスクを配置し、作業期間を棒グラフで示す。

視覚的に整っており、複数の作業が並行する場合に力を発揮する。

縦軸が「タスク」であり「立場（承認者別）」ではない。

部長は自分の名前も出番もどこにも見えない。

「こういう作業が順番に進む」という事実はわかるが、「私はどこで何を判断するのか」が見えないまま。

承認者が感じるのは「見せられた」ではなく「置いてきぼりにされた」感覚だ。

NG③：フェーズ分割型

プロジェクトを大きな段階に分けて整理する形式だ。

「フェーズ1：準備・設計」「フェーズ2：試行」「フェーズ3：評価・定着」という構成は、プロジェクト管理の教科書にも登場する標準的な枠組みだ。

フェーズ1に「承認」が含まれているが、誰が何を承認するのかが書かれていない。

「フェーズ2で検証する」とあるが、部長は「その検証結果を自分に誰が報告してくれるのか」「予算はいつ動くのか」がわからない。

このスケジュールを見た部長が次に言うのは「もう少し詳しく説明してもらえる？」だ。

3種類すべてに共通していること。

推進担当者の視点で設計されており、承認者の視点が入っていない。

WBSが業務改善提案書のスケジュールに向かない、構造的な3つの理由

結論：WBSが業務改善提案書のスケジュールに向かない理由は3つある。①縦軸が「タスク」であり「承認者別の立場」でない、②日本の稟議制度では承認者が事前に確認タイミングを把握していることが前提だがWBSにはその設計がない、③情シスや予算申請というボトルネックが時間軸に入っていない、の3点だ。

WBSやガントチャートを使うこと自体は間違っていない。

問題は、その設計思想が「推進担当者がプロジェクトを管理するためのツール」だということだ。

承認者に見せるための書類ではなく、推進担当者が自分のために使うツールを、そのまま提案書に貼っている。ここにずれがある。

理由①：縦軸が「タスク」であり「立場」でない

WBSもガントチャートも、縦軸には「現状調査」「システム選定」「試験導入」といった作業が並ぶ。

これは推進担当者にとって意味のある分類だ。「何をいつやるか」が明確になる。

しかし承認者（部長・決裁者）にとって必要な情報は「自分がいつ何を判断・承認するのか」だ。

縦軸が「タスク」である限り、承認者は自分の出番を探さなければならない。

探しても見つからない。

だから「いつ何をすればいい？」という質問が出る。

業務改善提案書の書き方を解説したWebサイトでは、スケジュール欄に「ガントチャートで作業期間を視覚化すると分かりやすい」と記載されている（複数ソースで確認）。

縦軸は「タスク」が標準として推奨されており、「承認者別の確認タイミング」を縦軸に置く設計は、市販テンプレートにほぼ存在しない。

承認者が知りたいのは「作業の進み方」ではなく「自分の確認タイミング」だ。

この視点が、既存のテンプレートには抜け落ちている。

理由②：稟議の仕組みが「事前の合意」を前提にしている

Web上の提案書解説には「事前の根回しが重要」と書かれているものが多い。

これは正しい。

だが「なぜ根回しが必要なのか」を考えると、スケジュールに承認者の確認タイミングが書かれていないからだ。

「自分が聞いていない案件がいきなり稟議書で回ってくると、何かリスクがあるに違いないと警戒される。事前に根回しすることで通過率は劇的に変わる」——これは稟議書の書き方を解説した複数のソースで共通して指摘されている。

また「承認者が不在・出張の場合、承認が完全にストップする」という物理的な停滞問題も起きる。

根回しとは、スケジュールで設計すべき「事前の合意」を、非公式な形で補っている行為にすぎない。

WBSにはこの合意設計が入っていないため、根回しが必要になる。

根回しをなくしたければ、スケジュールに承認者の確認タイミングを設計すればいい。

理由③：情シス・予算申請というボトルネックが「見えない」

多くの業務改善プロジェクトでは、情報システム部門への申請や来期予算申請が必要になる。

これらは社内の他のプロジェクトが優先されて後回しにされやすい。

「承認者や関係者が多すぎてフローが複雑化すると、誰が何をすべきかが曖昧になり滞留が起こりやすく、承認までの時間が長くなる」——これも現場で繰り返し起きている問題だ。

WBSやガントチャートでは「システム選定」「試験導入」という作業タスクは書かれる。

しかし「情シスへの申請→調査→承認」という社内申請フローの時間が考慮されていないことが多い。

また来期予算申請は、社内の申請サイクル（年度・半期）に合わせないと次のサイクルまで待つことになる。

この制約がスケジュールに書かれていないと、担当者は「まだ余裕がある」と思って先送りにしてしまう。

300社以上に関わる中で何度も見てきた。

「一旦これで進めよう」と言われたのに、予算の話や決裁者への説明の段階になると他のプロジェクトを優先されて、この業務改善プロジェクトが止まる。

情シスの申請が後回しにされ、プロジェクト全体が数ヶ月停滞した事例は一度や二度ではない。

WBSが悪いのではない。

WBSを承認者が読む書類に貼っていることが問題なのだ。設計の目的が違う。

業務改善提案書のスケジュール書き方を変える：「合意設計図」への書き直し方

結論：スケジュール欄の縦軸を「タスク」から「立場（決裁者・責任者・実務メンバー・社内申請）」に変えるだけでいい。横軸は時間のまま。各立場の合意タイミングを時間軸上に並べた「合意設計図」にすることで、承認者が自分の出番を一目で確認できる設計になる。

スケジュールの設計思想を変える。

横軸は時間、縦軸は「立場ごとの合意ライン」だ。

タスクを並べるのではなく、誰がいつ何に合意するかを一覧で見せる。

それがスケジュール欄の本来の目的だ。

具体的なOKサンプルを見てほしい。

このスケジュールを見ると、部長は「自分は11月に5回合意のタイミングがある」とわかる。

決裁者は「10月と12月と1月の3回だけ確認すればいい」とわかる。

情シスへの申請が10月から始まることも見える。

誰でも自分の出番を確認できる。

縦軸を「タスク」から「立場」に変えるだけだ。

ガントチャート形式のままでも構わない。それだけでスケジュールの設計思想が根本から変わる。

合意ライン①：決裁者との合意ライン

大きなポイントのみに絞る（5〜7点程度）。

「目的・問題点合意 → 全体の進め方合意 → 検証内容・予算合意 → 来期予算申請 → 承認 → 執行稟議 → 承認」の流れだ。

細かいタスクは一切書かない。

「このタイミングで自分が判断する」と一目でわかるよう、承認・稟議のステップだけを明示する。

決裁者は全体のスケジュール感と自分の出番がわかれば動ける。

合意ライン②：責任者（部長）との合意ライン

合意ステップが最も多い（10点前後）。

「目的合意 → スケジュール合意 → 範囲・業務フロー・課題・解決策合意 → 各部門の部門長と合意 → 体制合意 → 検証内容合意 → 検証結果合意 → 来期予算申請 → 承認 → 執行稟議 → 承認」という流れだ。

部長にとって最大のリスクは「知らないうちにプロジェクトが進んでいた」ことだ。

報告タイミングが網羅されていることが「管理できる」という確信につながる。

合意ライン③：実務メンバー＋部門長との合意ライン

「範囲・業務フロー・課題・解決策合意 → 体制・スケジュール合意 → 検証実施」のシンプルな構成だ。

ここで重要なのは部門長への声がけのタイミングだ。

プロジェクト開始直後に声をかけないと、総論賛成・各論反対が発生する。

全体的な方向性には賛成するが、いざ自分の部署が関わる話になると反対が出るパターンだ。

スケジュールに「各部門長と合意」を明記することで、推進担当者が早期に動かざるを得ない仕組みになる。

合意ライン④：社内申請（情シス・予算）との合意ライン

「新システム導入の申請 → 調査 → 承認」の3ステップを時間軸に乗せる。

情シスや予算申請は「他のプロジェクトが優先」されて後回しにされやすい。

スケジュールの早い段階に明記し、担当者に前もって調整しておかないとボトルネックになる。

ここが止まるとプロジェクト全体が止まる。

WBSは推進担当者が内部管理に使えばいい。

提案書のスケジュール欄には合意設計図を貼る。この使い分けが大切だ。

4つの合意ラインで設計するときの3つのポイント

合意設計図は、承認者がスケジュールで確かめたい3点に答えるためのものだ。①自分がいつ何を判断・承認するのか（報告タイミング）、②自分がこのプロジェクトをコントロールできるか（管理可能性）、③予算申請・稟議のスケジュールに間に合うか（社内フローとの整合）。4つのラインを実際に引くときは、次の3点に気をつける。

ポイント①：合意の回数は立場によって変える

決裁者は大きな合意ポイントのみ、多くて5〜7点。責任者（部長）は詳細まで10点前後。実務メンバーは参加が必要なフェーズのみ。情シスや予算は「申請→調査→承認」の流れを時間軸に乗せる。実務メンバーへの説明は1回では足りないので、合意を複数のフェーズに分けて書いておく。

ポイント②：部門長への声がけはプロジェクト開始直後にする

実務メンバーの上司（部門長）への説明が遅れると、「うちの部署は関係ない」という認識が固まり、総論賛成・各論反対が起きやすくなる。声がけが遅れて「仲間外れ感」が生じると、敵対化することもある。責任者の合意ラインに「各部門の部門長と合意」を早い時期に書いておくと、推進担当者自身が早く動かざるを得なくなる。

ポイント③：詰まりやすい申請フローはバッファを多めに取る

情報システム部門の調査は他のプロジェクトが優先されやすく、予算申請は社内の申請サイクル（年度・半期）を逃すと次のサイクルまで待つことになる。「申請開始」のタイミングは前倒しで設定する。ここが止まると実務メンバーは動けず、「推進担当者の都合に振り回されている」という感覚が生まれて協力する意欲も落ちていく。

社内システム導入の承認がなかなか進まない背景については、システム導入が進まない会社に共通していた問題も参考にしてほしい。

まとめ

業務改善提案書のスケジュール欄は、推進担当者の作業管理表ではない。

「決裁者・責任者・実務メンバー・社内申請」という4つの立場が、それぞれいつ何に合意するかを見える化した「合意設計図」だ。

WBSを使ってはいけないのではない。

推進担当者が内部管理に使うツールとして活用すればいい。

提案書のスケジュール欄は別だ。

まず今の提案書を開いて、スケジュールの縦軸に「決裁者・責任者（部長）・実務メンバー・社内申請」の4行を書き込んでみてほしい。

それだけでスケジュールの設計思想が変わる。

業務改善提案書の全体の構成と書き方については業務改善提案書の書き方【構成と通し方を完全解説】を参照してほしい。