スケジュール作成の1/3の法則 初心者におススメのスケジュール作成のアイデア

2020年3月27日

スケジュールを作る上での基本思想

1/3の法則とは、ITプロジェクトのスケジュールを作成する際に設計・実装(開発)・テストに対してプロジェクト全体の期間を三等分した期間を割り当てるという手法です。
『アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法』の中で紹介されている手法で、確立されたスケジュール作成の手法ではないものの、スケジュールを作っていく中で一つの目安となる法則です。

1/3の法則の利用

ITプロジェクトの大まかな流れ

スケジュール作成の1/3の法則のイメージ図

Webサイト制作やソフトウェア開発などのITプロジェクトは大まかに設計・実装(開発)・テストの3つの段階に分かれています。
設計では、「必要な機能は何か?」そしてそれを「どのように実現していくのか?」ということを話し合いながら要件定義を進め、仕様書など開発のための設計書を作成していきます。
そして、実装の段階では、実際に求められている機能を開発していきます。
最後に開発したものをテストし、バグの修正を行いながら最終的な成果物を完成させていきます。
スケジュールの1/3の法則では、これら設計・実装・テストの各段階の期間を等しくし、全体スケジュールを三等分するものです。
安易な手法のように見えますが、綿密に計画・設計をし、十分な開発期間とテスト期間を設けようとすると、意図せずとも設計・実装・テストの期間は似たようなスケジュールになっていきます。
逆に言うと、作成したスケジュールが1/3の法則に従っていない場合は、スケジュールの作成の仕方に何か問題があるのかもしれません。

三等分にならない場合は要注意

では設計・実装・テストで全体スケジュールが三等分されていない場合は、どのような問題を抱えているのでしょうか。
よくあるのは、実装、つまり開発の期間は十分にとっているものの、設計やテストに時間が適切に割り振られていないことです。
多くの場合こうした状況は「全体スケジュールが短いから、設計やテストは短めにとって、開発には十分に時間を使おう」という発想から生まれるのですが、いざそれでプロジェクトを進めてみると、考えていた通りには進みません。
設計が十分に考えられていないと、開発に着手しても手直しや仕様変更が発生し、見積もっていた期間以上の開発期間がかかってしまいます。さらにあれこれ手直しをしたプログラムは質が低く、テストにも時間がかかってしまいます。
その結果、一番長く時間を確保した開発の期間を3倍したようなスケジュールでようやくプロジェクトが完了することになります。
もちろん、この話は開発する内容が完全に明らかな場合にはあてはまりませんが、進行とともに詳細がわかってくるプロジェクトでは多くの場合に該当する話です。
そのため、全体スケジュールを三等分した開発期間で求められている内容が作れないと予想されるのであれば、全体スケジュールの見直しや開発内容の削減をするほうが健全でしょう。
このように、設計・実装・テストの各段階で予定されている期間が均一でない場合は、 「なぜ設計・実装・テストの期間に乖離があるのか」を確認していくことによって、プロジェクトの失敗の原因を未然に取り除くことができます。

プロジェクトの振り返りの尺度にもなる

1/3の法則はプロジェクトの振り返りや反省会にも使えます。
どういうことかというと、完了したプロジェクトを振り返る際に、設計・実装・テストにかかった期間がだいたい均一になっていたかどうかをチェックします。
例えば設計の期間に比べて実装やテストの期間が長ければ、それは要件の漏れがあって開発の手直しがあったことを意味しているかもしれません。
あるいは設計や実装の期間は同じくらいなのに、テストの期間が長くなってしまっていれば、開発した成果物の品質がよくなかったのかもしれません。
このように、設計・実装・テストの期間を見比べてみることで、プロジェクトの反省点、ひいてはプロジェクトマネジメントの課題が浮かび上がります。

参考

  • Scott Berkun (著)、村上 雅章 (訳)『アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法』オライリー・ジャパン、2006年