スケジュールは後ろから組み立てる

Reverse-Engineering Your Project Schedule

「今日から何を始めるか」でスケジュールを組み始めると、後半になるほど無理が重なっていきます。逆に、納品日に何が完成していなければならないかから逆向きに設計すると、無理のない進行を組みやすくなります。今回は、この逆算思考によるプロジェクト設計の考え方を解説します。

目 次

1. なぜ「積み上げ式」のスケジュールは崩れるのか
2. 逆算思考の基本的な考え方
3. 逆算で設計する際に決めるべき3つのポイント
4. バッファの持たせ方
5. 逆算スケジュールが崩れたときの対処
6. 実際の設計手順を、簡単な例で見る
7. 逆算思考が特に効く案件、そうでない案件
8. まとめ

読了目安: 約7分 / 約3,300字

なぜ「積み上げ式」のスケジュールは崩れるのか

多くのプロジェクトは、着手日を起点にタスクを一つずつ積み上げる形でスケジュールが組まれます。この組み方は直感的でわかりやすい一方、想定外の遅延が起きたときに弱いという弱点があります。

一つの工程が数日遅れただけでも、その遅れはそのまま後ろの工程に引き継がれます。積み上げ式では、遅延を吸収する仕組みが最初から用意されていません。そのため、しわ寄せは常に納品直前に集中します。

結果として、最終盤になるほど余裕がなくなります。品質チェックや最終確認といった、本来欠かせない工程から真っ先に削られてしまうのです。

逆算思考の基本的な考え方

「逆算思考」は、この構造を反転させる考え方です。まず最終的な納品日を起点に置きます。そこから「公開の1週間前には何が完成していなければならないか」を考えます。さらに「そのためには2週間前には何が終わっている必要があるか」というように、ゴールから逆向きにマイルストーンを配置していきます。

この組み方の利点は、各工程の期限が最初から明確になる点です。着手日から積み上げる場合、期限は成り行きで決まりがちです。逆算思考では、期限そのものが設計の起点になります。

たとえば公開日が4週間後だとします。まず「公開1週間前:最終確認完了」「2週間前:実装完了」「3週間前:デザイン確定」「4週間前(今週):要件確定」というように逆向きに区切っていきます。こうして区切ると、各工程に使える日数が視覚的にはっきりします。

逆算で設計する際に決めるべき3つのポイント

動かせない期日を先に洗い出す

クライアント側の広報解禁日や、法的な届出期限など、絶対に動かせない日付をまず洗い出します。逆算の起点はこの動かせない期日です。ここが曖昧なままでは、以降のマイルストーンもすべて曖昧になってしまいます。

各工程の「最低限必要な日数」を把握する

デザイン、コーディング、確認、修正といった各工程について、余裕を含めない実質的な稼働日数を把握しておきます。ここを希望的観測で短く見積もってしまうと、逆算した結果のスケジュールそのものが非現実的になります。

工程間の依存関係を整理する

デザインが確定する前には、コーディングに着手できません。こうした工程同士の依存関係を整理しておきます。依存関係を無視して逆算すると、並行できない工程を並行させてしまいます。結果として、机上のスケジュールと実際の作業が食い違う原因になります。

バッファの持たせ方

逆算だけでスケジュールを組むと、各工程がぴったりと隙間なく並びます。余白がまったくない状態になりがちです。これでは、想定外の事態が一つでも起きた瞬間に、後ろの工程すべてがずれてしまいます。

バッファの持たせ方には、大きく2つの考え方があります。一つは、各工程に少しずつ余裕を薄く広く持たせる方法です。もう一つは、特定の要所、たとえばクライアント確認のタイミングなどに、まとめてバッファを集中させる方法です。

薄く広く持たせる方法は、日々の小さな遅延を吸収しやすいという特徴があります。要所に集中させる方法は「ここまでは絶対にずらせない」という緊張感を保ちやすい特徴があります。プロジェクトの性質に応じて、どちらか、あるいは両方を組み合わせて設計します。

逆算スケジュールが崩れたときの対処

逆算思考で組んだスケジュールも、進行の途中で崩れることはあります。ここで大切なのは、崩れた事実に慌てるのではなく、動かせない期日から逆算し直すという発想を保ち続けることです。

遅延が発生した場合は、まず「動かせない期日」と「バッファの残量」を確認します。バッファで吸収できる範囲であれば、そのまま進行を続けます。

バッファで吸収できない場合は、対応の選択肢を検討します。どの工程を圧縮できるか。あるいは、どの工程を分割して一部を後ろに回せるか。依存関係の整理表に立ち返って、この2つを検討します。

積み上げ式のスケジュールでは「とにかく急ぐ」という対処になりがちです。一方、逆算思考であれば「どこを削れば動かせない期日に間に合うか」という判断基準を保ったまま、冷静に対処しやすくなります。

実際の設計手順を、簡単な例で見る

考え方だけでは掴みにくいので、簡単な例で流れを追ってみます。あるコーポレートサイトのリニューアル案件で、公開日が8週間後に決まっているとします。

まず、公開日を起点に置きます。公開の前週には「本番環境での最終確認」が完了していなければなりません。そのためには、その1週間前までに「実装・コーディング完了」が必要です。さらにその前には「デザイン確定」、その前には「ワイヤーフレーム確定」、そして起点となる今週には「要件確定」を置きます。

こうして逆向きに並べると、各工程に使える日数がそのまま見えてきます。デザインに使える期間が想定より短いとわかれば、その時点で「範囲を絞るか」「人員を増やすか」といった判断を、着手前に済ませておけます。積み上げ式であれば、この判断は往々にして工程の途中、しかも手遅れに近いタイミングで初めて発生します。逆算思考は、こうした判断を前倒しできる点に最大の価値があります。

逆算思考が特に効く案件、そうでない案件

逆算思考は、あらゆる案件に等しく効くわけではありません。特に効果を発揮するのは、公開日やリリース日が固定されている案件です。イベント告知サイトやキャンペーンページのように、動かせない日付が最初から決まっている場合、逆算の起点がはっきりしています。そのため、設計そのものがスムーズに進みます。

一方、要件が流動的で、そもそも「何を作るか」自体が確定していない初期フェーズの案件では、逆算思考だけに頼るのは危険です。ゴールが固まっていない状態で逆算しても、前提が変わるたびにスケジュール全体を組み直すことになりかねません。こうした案件では、まず要件を固める期間そのものを、動かせない期日の一つとして先に確保しておく発想が必要になります。

まとめ

積み上げ式のスケジュールは、想定外の遅延に弱く、しわ寄せが納品直前に集中しやすい組み方です。一方、逆算思考によるプロジェクト設計は、動かせない期日を起点に、各工程の必要日数と依存関係を踏まえて設計する考え方です。

バッファの持たせ方まで含めて事前に設計しておくことで、遅延が起きた際にも冷静に対処しやすくなります。着手日からではなく、納品日から考える。この視点の転換だけでも、スケジュールの組み方は大きく変わっていきます。

逆算思考は、特別なツールや高度な手法を必要とするものではありません。ゴールを先に決め、そこから必要な工程を数え上げるという、考え方の順序を変えるだけの取り組みです。次の案件のキックオフで、着手日からではなく納品日から話を始めてみると、それだけでチーム全体のスケジュール感が変わっていくはずです。

もしスケジュールが毎回ぎりぎりになってしまう、あるいは終盤にしわ寄せが集中しがちだと感じているなら、見直しのタイミングかもしれません。ゲツコーギルドでは、ディレクション業務やWeb制作の請け負い、こうしたプロジェクト設計やスケジューリングの仕組みづくりについてのご相談も承っています。

> お問い合わせ
> ギルドに所属する

あわせて読みたいツキヨミ