プロジェクト概要

プロジェクトとは、「独自のプロダクトやサービスなどを創造するための有期性のある業務である」と定義されている。プロジェクトには、期間やコストなどの制約条件がつきもので、そのような制約条件を満たすように顧客価値を最大化することを目指す。

プロジェクトでは顧客価値を最大化することを主要な目的とする。そこで、プロジェクトの失敗は「顧客に満足してもらえないこと」と定義する。顧客満足度低下の要因には、主に以下のようなものが考えられる。

これらの失敗要因は、システム開発の評価指標であるQCDSによって評価できる。

プロジェクト完了条件や要求される品質レベルをあいまいなままにしておくと、完成したシステムにはユーザーが求めるものとずれがあるかもしれない。そのため、計画を立てる前にしっかりとプロジェクトの完了条件を定義し、ユーザーの合意を得ておかなくてはならない。

プロジェクト完了のチェックリストの例として、以下のものが挙げられる。なお、単体テストではどのような振る舞いをテストするのか、非機能要件ではどのくらいの応答速度は許容できるのかなど、さらなる具体化が必要である。

エンジニアの間に限っても、「完了」と表現するものに以下のようにばらつきがあるのでプロジェクトを進めるうえで注意が必要である。

プロジェクトでは様々なトレードオフが発生する。例えば、計算リソースを増やして処理時間を短縮する代わりに費用が高くなったり、機能を追加する代わりに開発期間が長くなったりする。このようなトレードオフを考える上で、前述のQCDSを利用する。

まず大前提として、顧客価値を大きく損なうことになるため、「品質」を犠牲にすることはできない。そこで、（品質以外の）「コスト」、「期間」、「スコープ」を頂点として三角形を作り、制約条件のトレードオフを可視化する。この三角形は「鉄のトライアングル」と呼ばれていて、各頂点が相互に影響し合う。

「スコープ」と「期間」、「スコープ」と「コスト」には正の相関、「期間」と「コスト」には負の相関がある。以下はそのイメージ図で、この関係はプロジェクトによって異なる。例えば、「スコープ」が大きくなると、「期間」か「コスト」を大きくして調整する必要がある。「期間」が短くなると、「スコープ」を小さくするあるいは「コスト」を大きくして調整する必要がある。

なお、「スコープ」、「期間」、「コスト」が変わっても、一定以上の「品質」が担保されている必要がある。

「スコープ」、「期間」、「コスト」すべてをビジネス上の目標から固定してしまった場合、「品質」が犠牲になりプロジェクトの失敗につながる可能性が高い。そのため、一般的に「スコープ」あるいは「期間」を可変にして、可変の要素を他の要素から見積もってプロジェクト計画を立てる。

プロジェクトは初めて取り組むことも多く、不確実性を多分に含んでいる。綿密に計画を立てたとしても、計画通りに進まず、プロジェクトが失敗に終わることもある。

特に、プロジェクト初期には不確実性が大きく、プロジェクト初期に立てた計画は実際との乖離が大きくなる。そして、プロジェクトが進むにつれて、この不確実性は減少していく。これを端的に表したのが「不確実性コーン」と呼ばれるグラフである。

「初期コンセプト」の段階の見積もりは、最大で4倍、最小で0.25倍と現実との乖離が大きい。このような不確実性になんとか対処する必要がある。不確実性への３つの対処法を以下に示す。

初期段階で詳細設計まで実施することで不確実性を最小化する。初期段階の知識で詳細を決めてしまうので、プロジェクト進行に伴って得られたフィードバックを活かすことができない。また、より良い解決策を探索できない、計画を立てるのに時間がかかりすぎるなどのデメリットがある。

プロジェクトを段階に分けることで不確実性の影響を減らす。例えば、プロジェクト初期では、コンセプトを決めることを目標に計画を立て、中盤では、基本設計や詳細設計を実施することを目標に計画を立てる。そして、終盤では、詳細設計をもとに実装することを目標に計画を立てる。これによって、不確実性を含む範囲を限定でき、不確実性を段階的に減らしていくことができる。ただし、契約などの関係で最初に全体の計画を立てる必要があり、プロジェクトを段階に分けられないこともある。

計画にバッファを設けることで不確実性に備える。どれだけ時間をかけて計画を立てても、プロジェクトの不確実性を完全に取り除くことはできないため、最終的にはバッファを設けて不確実性に備えることになる。どのくらいバッファを設けるかを決めるためには、一点見積もりではなく幅のある確率的な見積もりが必要になる。

現在、プロジェクトの不確実性に対処するため、多くの企業でアジャイル開発が採用されている。アジャイル開発には、スクラム、カンバン、XP、FDDなど、多くの種類があるが、より広く使われているスクラムあたりから実行してみると良い。典型的なスクラムでは、2週間ごとに期間を区切り、計画、実行、評価、改善のサイクルを回し、イテレーティブに開発を進めていく。

ただし、これらのプロセスを真に受けないでほしい。真のゴールは「プロセスどおりに実行すること」ではなく「ユーザーが求めるソフトウェアを提供すること」である。現在のコンテキストに対してアプローチ方法が合致しているか注意深く観察し、状況に応じて変化し続ける必要がある。

リスク管理のやり方は組織によって異なるが、以下の要素がなければリスク管理しているとはいえない。

プロジェクトが内包するリスクは多岐にわたるが、その中でも、あらゆるプロジェクトに共通する５大リスクを以下に示す。

後になって不要だと分かる作業より、必要だった作業を無視してしまうことのほうが多い。そのため、スケジュールは過小に見積もられる傾向がある。過去のプロジェクトのデータから、どの程度過小に見積もられていたか調べて調整しなければならない。また、そもそも製品サイズを考慮せず、希望的観測に基づいて設定されることさえあるので注意が必要である。

システムは業務ドメインに合わせて作られる。開発中も、ドメインは変化し続けるため、その変化に対応するため要求は増大していく。動く的を射るように、増大する要求に対応できるように計画を立てる必要がある。

プロジェクトの途中で人が辞めていくことがある。代わりの人員を投下しても最初はプロジェクトの理解に時間を使い、情報を得るために他のメンバーの時間を消費するため、一時的にチームの生産性は低下する。

製品の仕様書があいまいで関係者間の対立が隠されていたために、プロジェクトの初期に要求定義の核となる交渉プロセスが破綻することがある。このリスクが実際に起こった場合、そのプロジェクトは破綻する。あいまいな仕様によって対立が隠されないように、システムに入出力するすべてのデータフローを明確にして合意を得ておく必要がある。

個人の能力にはばらつきがあるが、チーム全体でみると安定していることが多い。だが、１人、あるいは少人数チームの場合は能力を考慮して計画を立てる必要がある。

上記の５大リスク以外にもプロジェクトに共通のリスクや固有のリスクがあり、随時考慮しなければならない。リスク発見には死亡前死因分析（「計画を実行したら悪いことが起きてしまった」という仮説のもと原因を洗い出す思考法）なども役に立つ。

ユーザーとコミュニケーションが上手く取れていないと、ユーザーが真に求めるシステムを作ることはできない。ユーザーがよくわかっていない点や不安に感じている点、開発者側の理解が怪しい点などを追加で資料にまとめて残しておくことで、認識の共有ができ、後に「言った言わない」のトラブルになるのを防ぐことができる。

プロジェクトの進行に伴って、ユーザーのシステムに対するイメージが明確になり、要望に追加や変更が生じることがある。これら全てに応えようとすると、前述のトレードオフによりプロジェクトの失敗につながり、結果としてユーザーの信頼を失ってしまう。一方で、すべて突っぱねてしまうとユーザーからの不信を買ってしまう。

そのため、トレードオフはユーザーに押し付ける方が安全である。ユーザーが機能の追加を依頼してきた場合、他の機能を削るか、納期を伸ばす必要があることをユーザーに伝え、追加したい機能の優先順位を考慮して判断するように促す。

見積もり、ターゲット、計画、コミットメントは明確に区別しておく必要がある。以下にそれぞれの説明を示す。