記事を書いてる人：あまみ るい
工場の設備を開発・メンテナンスする企業に、業務改善コンサルタントとして入ったときのことだ。
メンテナンス部門の担当者が作った提案書を見せてもらった。
スケジュール欄には、WBS形式で「現状調査」「課題整理」「システム選定」「試験導入」「本番稼働」と、タスクとマイルストーンが丁寧に記されていた。
一緒に部長への説明に同席したとき、部長はそのスケジュールを一目見て、こう言った。
「で、私はいつ何を確認すればいい？」
担当者は言葉に詰まった。
スケジュールは書いた。でも、何かが足りなかった。
業務改善提案書を作るとき、スケジュール欄にWBSやガントチャートを貼り付けるのは自然な選択だ。
形式上は整っている。でも、承認者の反応が鈍い。「いつ報告が来るの？」と聞かれる。
そういうことが、現場ではよく起きる。
スケジュールを「タスクの進捗管理表」として設計している限り、この違和感は消えない。
業務改善提案書のスケジュール欄に何を入れるべきか。
答えは、タスクではなく「合意ライン」だ。
業務改善提案書の全体構成については、業務改善提案書の書き方【構成と通し方を完全解説】で詳しく解説している。
この記事では、スケジュール欄の設計に絞って説明する。
- 業務改善提案書のスケジュールは「タスクの進捗管理表」ではなく「各立場が自分の合意タイミングを確認できる地図」として設計する
- スケジュール欄に入れるべきは「決裁者・責任者・実務メンバー・社内申請」の4つの合意ラインであり、立場ごとに行を分けて横軸（時間）上に並べる
- 情報システム部門への申請・来期予算申請などのボトルネックは、スケジュールに明記して先手を打たないとプロジェクト全体が停止する
業務改善提案書のスケジュール欄で承認が止まる本当の理由
タスクベースのスケジュールが通りにくい理由は、書き方の問題ではない。
設計の目的がずれているからだ。
日本の稟議制度では、複数の承認者が必要になる。
承認者が不在だったり多忙だったりすると、最終承認まで数週間待ちになることは珍しくない。
さらに、事前の根回しなしに突然書類を回すと、承認者は「何かリスクがあるのではないか」と警戒する。
差し戻しが発生するケースは多い。
これは承認者が意地悪なわけではない。
承認者がスケジュールを見て確認したいのは、次の3点だ。
- ①「自分がいつ何を判断・承認するのか」（報告タイミングの可視化）
- ②「自分がこのプロジェクトをコントロールできるか」（管理可能性の確認）
- ③「このプロジェクトが予算申請・稟議のスケジュールに間に合うか」（社内フローとの整合性）
タスクベースのスケジュールは、この3点に一切答えていない。
「現状調査→課題整理→システム選定→本番稼働」という流れを見せられても、承認者には「自分がどこで何を判断するのか」が見えない。
見えないから、「なんとなく不安」な感覚が残る。
その不安が、承認を先送りにさせる。
メンテナンス部門の案件でも、これが起きていた。
担当者はタスクをきれいに並べていた。でも部長が欲しかったのは「自分の出番が見える地図」だった。
スケジュールを「部長が承認を求められるタイミング」が一目でわかる形に組み替えた。
すると部長の反応が変わった。「これなら任せられる」と。
書き方の問題ではなかった。設計の問題だったのだ。
業務改善提案書のスケジュール欄に入れるべき4つの合意ライン
スケジュールの設計思想を変える。
横軸は時間、縦軸は「立場ごとの合意ライン」だ。
タスクを並べるのではなく、誰がいつ何に合意するかを一覧で見せる。
それがスケジュール欄の本来の目的だ。
具体的には、4つのラインを設ける。
合意ライン①：決裁者との合意ライン
記載内容の流れ：
目的・問題点合意 → 全体の進め方合意 → 検証内容・予算合意 → 来期予算申請 → 承認 → 執行稟議 → 承認
決裁者の合意ステップは、大きなポイントのみに絞る。
細かいタスクは一切書かない。
「このタイミングで自分が判断する」と明確にわかるよう、承認・稟議のステップを明示することだけ意識する。
決裁者は、全体のスケジュール感と自分の出番さえわかれば動ける。
報告タイミングが可視化されることで、「任せられる」という安心感が生まれる。
合意ライン②：責任者（部長）との合意ライン
記載内容の流れ：
目的・問題点合意 → スケジュール合意 → 範囲・業務フロー・課題・解決策合意 → 各部門の部門長と合意 → 体制合意 → 検証内容合意 → 検証結果合意 → 来期予算申請 → 承認 → 執行稟議 → 承認
責任者（部長）は、合意ステップが最も多い。
「自分がいつどのような報告を受けるか」の全体像が見えることで、プロジェクトを自分で管理できると判断し、安心して承認してくれる。
部長にとって最大のリスクは「知らないうちにプロジェクトが進んでいた」ことだ。
報告タイミングが網羅されていることが、「管理できる」という確信につながる。
合意ライン③：実務メンバー＋部門長との合意ライン
記載内容の流れ：
範囲・業務フロー・課題・解決策合意 → 体制・スケジュール合意 → 検証実施
実務メンバーへの説明は「1回」では足りない。
メンバーが揃わない、理解が中途半端になる、腑に落ちずやらされ感が出る——こういった問題が起きやすい。
スケジュール上でも「実務メンバーとの合意」を複数フェーズに分けて記載しておくことが重要だ。
そして、実務メンバーだけでなく、その上司（部門長）にも早い段階で声をかけることが必要だ。
「総論賛成・各論反対」という状況がある。
全体的な方向性には賛成するが、いざ自分の部署が関わる話になると反対が出る、あのパターンだ。
進んでから部門長に反対されると、軌道修正のコストが大きい。
声がけが遅れて「仲間外れ感」が生じると、敵対化するリスクが生まれる。
合意ライン④：社内申請（情報システム部門・予算）との合意ライン
記載内容の流れ：
新システム導入の申請 → 調査 → 承認
情報システム部門への申請や来期予算申請は、社内の他のプロジェクトを優先して後回しにされやすい。
スケジュールの早い段階に明記し、担当者に前もって調整しておくことが必須だ。
ここがボトルネックになると、実務メンバーは動けない状態になるだけではない。
「推進担当者の都合に振り回されている感覚」が生まれ、協力する意欲が失われていく。
ボトルネックは「発生してから対処」では遅い。
スケジュールに明記することで、「そこが詰まったらプロジェクト全体が止まる」という認識を関係者全員で共有できる。
社内システム導入の承認がなかなか進まない背景については、システム導入が進まない会社に共通していた問題も参考にしてほしい。
スケジュールを4つのラインで設計するときの3つのポイント
4つのラインを実際に設計するとき、気をつけるべき点が3つある。
ポイント①：各ラインの「合意頻度」は立場によって変える
決裁者は大きな合意ポイントのみ、多くて5〜7点に絞る。
責任者（部長）は詳細まで、10点前後を想定する。
実務メンバーは参加が必要なフェーズのみ。
情シスや予算は「申請→調査→承認」の流れを時間軸に乗せる。
WBS形式でもガントチャート形式でも構わない。
ただし、縦軸が「立場ごとのライン」で分かれていることが重要だ。
ここを外すと、スケジュールはまたタスク表に戻ってしまう。
ポイント②：部門長への声がけはプロジェクト開始直後が鉄則
実務メンバーの上司（部門長）への説明が遅れると、「うちの部署は関係ない」という認識が固まってしまう。
そうなると「総論賛成・各論反対」が発生しやすくなる。
スケジュールの「責任者との合意ライン」に「各部門の部門長と合意」が明記されていると、推進担当者が早期に動かざるを得ない仕組みになる。
スケジュールは、推進担当者自身の行動を促す設計にもなる。
ポイント③：ボトルネックになりやすい申請フローは時間的バッファを多めに取る
情報システム部門の調査は「他のプロジェクトが優先」されやすい。
予算申請は社内の申請サイクル（年度・半期）に合わせないと、次のサイクルまで待つことになる。
スケジュールには余裕を持って「申請開始」のタイミングを前倒しで設定することをおすすめする。
「余裕があるから後でいい」と思っていたら、ある日突然プロジェクト全体が止まる——そういう現場を何度も見てきた。
まとめ
業務改善提案書のスケジュール欄は、「何をいつやるか」のタスク管理表ではない。
「誰がいつ何に合意するか」を立場ごとに整理した、合意の設計図だ。
4つの合意ライン（決裁者・責任者・実務メンバー・社内申請）を横軸（時間）上に並べるだけで、承認者が「自分の出番」を把握できる。
プロジェクトが前に進みやすくなる。
まず自分の提案書を開いて、縦軸に4つのラインを書き込んでみてほしい。
それだけでスケジュールの設計思想が変わる。
業務改善提案書の全体の構成と書き方については、業務改善提案書の書き方【構成と通し方を完全解説】を参照してほしい。