第2章 ← 目次にもどる
プロジェクトは、どういう順で進んでいくのか
プロジェクトには、性質の違う4つの区間があります。立ち上げ・計画・実行・終結です。順番に並んではいますが、大事なのは順番そのものではありません。区切りごとに「このまま進めてよいか」を判断できることが、この分け方の目的です。
この記事の要点
- 4つの区間は、立ち上げ・計画・実行・終結です。それぞれ「決めること」がまったく違います。
- 「フェーズ」と「工程」は別の話です。要件定義・基本設計・製造・テストは工程で、管理の区間とは軸が違います。
- 区切りの価値は、そこで止める判断ができることにあります。通過儀礼にすると、ただの日付になります。
- 実際には計画と実行を何度も行き来します。行き来すること自体は失敗ではありません。
- いちばん飛ばされやすいのは終結です。誰も困らないので、静かに飛ばされます。
4つの区間と、それぞれが薄いときに起きること
この4つは、作業の種類ではなく判断の種類で分かれています。立ち上げは「やるかどうか」、計画は「どうやるか」、実行は「ずれをどう直すか」、終結は「渡しきれたか」を扱います。
「フェーズ」と「工程」は別のものです
ここは日本の現場でとくに混乱しやすいところなので、先に整理しておきます。
要件定義・基本設計・詳細設計・製造・テスト——これは工程です。何をつくるかという作業の中身で分けたもので、システム開発の進め方（ウォーターフォール）の話です。
立ち上げ・計画・実行・終結——これは管理のフェーズです。プロジェクトをどう運ぶかという判断の中身で分けたもので、システム開発かどうかとは関係ありません。事務所の移転にも、新商品の発売にも、同じ4つがあります。
この2つは軸が違うので、重なります。たとえば「要件定義」という工程は、管理から見ると計画フェーズと実行フェーズにまたがります。アジャイルで進める場合、工程の並びは大きく変わりますが、管理の4つの区間はなくなりません。やり方が変わっても、決めなければならないことは変わらないからです。
区切りは、止められるから意味があります
フェーズを分ける実務上の理由はひとつです。そこで止める判断ができるからです。
計画が終わった時点で、見えているものは立ち上げのときとは違います。工数の見込みが倍になっているかもしれない。前提だった連携先が使えないと分かったかもしれない。この時点でやめれば、失うのは計画にかけた工数だけです。同じことに製造の途中で気づけば、失うものは桁が変わります。
ところが実際には、区切りが判断の場になっていないことが多くあります。フェーズ完了の報告会は開かれるが、そこで「やめる」という選択肢は最初から議題に入っていない。稟議が通っている以上やるものだ、という前提で進む。これは日本の組織に限った話ではありませんが、いったん決裁がおりたものを止めにくいという性質は、稟議という仕組みと相性が悪い方向に働きます。
実務的な折衷案としては、止めるかどうかではなく「規模を変えるかどうか」を議題にするやり方があります。全部やめる提案は通りませんが、「今回はここまでにして、残りは次期に回す」は通ります。これは3.1 スコープの決め方で扱います。
行き来するのは、失敗ではありません
図では4つが一直線に並んでいますが、実際のプロジェクトはそう進みません。実行の途中で前提が変わり、計画に戻る。戻った結果、スコープが変わり、立ち上げで決めた目的の言い方を直す。これは普通のことです。
問題になるのは、行き来すること自体ではなく、行き来したことが記録に残らないことです。計画を変えたのに、変えた理由も、変えた事実も、どこにも書かれていない。すると三か月後、当初の計画を見た人が「遅れている」と判断します。実際には遅れていなくても、記録がなければ説明できません。
だから、計画を変えたときは変更として残してください。「変更管理」という言葉は堅苦しく聞こえますが、やることはいつ・何を・なぜ変えたかを一行書くだけです。詳しくは6.2で扱います。
飛ばされるのは、いつも終結です
4つのうち、実務でいちばん扱いが雑になるのは終結です。理由ははっきりしていて、飛ばしても今日は誰も困らないからです。
納品が終われば、次の案件がもう始まっています。検収の依頼、運用する人への引き継ぎ、残った課題の引き取り先、ふりかえり——どれも「あとで」になり、そのまま消えます。そして次のプロジェクトで、前回とまったく同じところでつまずきます。
この構造は1.3で説明した力学とまったく同じです。今日困らないことは後回しになり、数か月後にまとめて表に出ます。
ABではこう見えます
AB Projectsでは、フェーズをそのままプロジェクト内の区切りとして持てます。区切りごとに「ここまで終わったら次に進む」という条件をタスクとして置いておけば、区切りが自動的に判断の場になります。何も置かなければ、区切りは資料の見出しにしかなりません。
行き来の記録は、プロジェクトWikiに1ページ持つのが簡単です。「変えたこと」だけを日付順に追記していく形にしておけば、あとから経緯を説明する場面で、記憶ではなく記録で話せます。
このページで使った言葉
- フェーズ
- プロジェクトを判断の種類で分けた区間です。立ち上げ・計画・実行・終結の4つが基本形で、進め方が変わってもこの4つはなくなりません。くわしく →
- 工程
- 作業の中身で分けた区間です。要件定義・基本設計・詳細設計・製造・テストという並びが、日本のシステム開発では標準になっています。くわしく →
- ウォーターフォール
- 工程を上流から下流へ順に進める進め方です。前の工程が固まっていることを前提にするため、後から戻ると手戻りになります。くわしく →
- 検収
- 納めたものを相手が確認し、正式に受け取ることです。社外案件では支払いの起点になります。くわしく →
- 変更管理
- 決まっていたことを変えるときの手順です。変更を止める仕組みではなく、変更の影響を決める人に見せる仕組みです。くわしく →
- ふりかえり
- 区切りごとに、進め方そのものを見直す場です。人ではなく進め方を対象にし、次に変える1つを決めて終わります。くわしく →
あわせて読みたい
2.1 立ち上げ
決裁がおりた直後に、A4一枚で埋めておく5つの欄。
5.4 アジャイルとウォーターフォール
工程の並べ方が違うだけで、管理の4区間は共通です。
3.0 計画の基本
計画フェーズで具体的に何を決めるのか、その全体像。