プロジェクトの制約条件とアジャイル


こんにちは、ライトパスの建守です。
今回は、プロジェクトにおける「制約条件」について、従来型のシステム開発プロジェクト(ウォーターフォール開発手法など「重量級」プロセスを採用したプロジェクト)とアジャイルプロジェクト(アジャイルソフトウェア開発手法を取り入れたプロジェクト)での扱いの違いについて考えてみたいと思います。

プロジェクトの制約条件とは

まず、そもそも「プロジェクト」とは何でしょうか。PMBOK(Project Management Body Of Knowledge、プロジェクトマネジメント知識体系)には

独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務である。プロジェクトの有期性とは、プロジェクトには明確な始まりと終わりがあることを示すものである。プロジェクトが終わりとなるのは、プロジェクト目標が達成されたとき、もしくはプロジェクト中止されたときである。

と書かれています。要は、プロジェクトとは、ある一定の期日までに特定の目標を達成するために行われる業務、ということですかね。

で、そのプロジェクトを実行するうえで、一般にいくつかの制約条件が「スポンサー」(プロジェクトの実行にお金を出す人)をはじめとするステークホルダー(関係者)から課されます。代表例としてPMBOKには、

  • スコープ
  • 品質
  • スケジュール
  • 予算
  • 資源
  • リスク

が挙げられています。

 

制約条件のトレードオフ

上で例示したプロジェクトの制約条件は、互いに影響しあっていて、トレードオフの関係になることがあります。例えば、品質をアップさせるならスケジュールを延ばし予算を増やさなければならない、といったようなことです。

一般的に、システム開発プロジェクトにおける制約条件のトレードオフを考える場合、「QCD」あるいは「QCDS」に注目することが多いかと思います。

「QCD」は「Quality(品質)」「Cost(予算)」「Delivery(スケジュール)」の頭文字です。製造業における生産管理の重要ポイントを指す言葉ですが、プロジェクトにおいてもこれらは重要な要素であると考えられています。

「QCDS」の前半の「QCD」は上述と同じ3つの要素を指します。最後の「S」が何を指すかは状況によってまちまちですが、システム開発プロジェクトに限って言えば、「Scope(スコープ)」を指すことが多いでしょう。

プロジェクトを成功させるためには的確なプロジェクトマネジメントが行われる必要がありますが、プロジェクトマネジメントとはすなわち、「QCD(S)」のバランスを取ることである、などと言われたりもします。

 

制約条件の扱い方のパターン

さて、ではこれらの制約条件に対して、システム開発プロジェクトにおいてどのように対処していくことが可能かを考えてみましょう。

・・・と言いながら、これまで述べた内容をひっくり返すようなことを言いますと、「QCD(S)」の「Q(品質)」については考慮から外します。なぜなら、「コストを減らすから、その分、品質を下げてもいいよ」とか、「機能を増やしてくれたら品質についてはオマケしてあげる」ということは、常識的に考えてありえない(あってはならない)からです。「Q(品質)」はシステムの使われ方その他の要素によって決まるもので、「C(コスト)」「D(納期)」「S(スコープ)」に左右されるものではない、ということですね。

ということで、あらためて、「QCDS」の「C(コスト)」「D(納期)」「S(スコープ)」のバランスのとり方について見てみましょう。ここでは、『エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド 』(Kenneth Rubin、翔泳社)という本の内容に沿って考えてみます。

概要 C(コスト) D(納期) S(スコープ)
①すべてを固定 固定 固定 固定
②D(納期)とS(スコープ)を固定 可変 固定 固定
③S(スコープ)を固定 固定(可変) 可変 固定
④D(納期)を固定 固定 固定 可変

 

  1.  「C(コスト)」「D(納期)」「S(スコープ)」のすべてを固定する
    最初に決めたコスト、納期、スコープを最後まで守り抜くタイプです。
  2. 「C(コスト)」を可変とし、「D(納期)」と「S(スコープ)」は変えない
    もしも作業が見積もりより遅れて納期に間に合わなそうになったら、追加コストを払って要員を増やして対応する、というタイプです。
  3. 「D(納期)」を可変とし、「S(スコープ)」は変えない
    もしも作業が見積もりより遅れて納期に間に合わなそうになったら、納期をずらして対応する、というタイプです。この場合、基本的にはコスト増につながるため、「C(コスト)」も可変とならざるをえません。
  4. 「S(スコープ)」を可変とし、「C(コスト)」と「D(納期)」は変えない
    もしも作業が見積もりより遅れて納期に間に合わなそうになったら、スコープを縮小して対応する、というタイプです。

 

従来型のシステム開発プロジェクトにおける制約条件の扱い

従来型のプロジェクトでは、上で上げた4つのパターンのうち、1のパターンを取ります。つまり「C(コスト)」も「D(納期)」も「S(スコープ)」も変えません。なぜなら、従来型のプロジェクトでは、プロジェクト開始時点でこれら3つを正確に定義・見積もりしているので、変える必要がないのです。

・・・という建前になっています。

さて、従来型のシステム開発プロジェクトがどの程度成功に終わったかご存知でしょうか?調査方法や成否を判断するタイミングなどにもよるでしょうが、一般的には約3割程度と言われています。つまり7割のプロジェクトが失敗とみなされているわけです。プロジェクトが失敗した、というのはつまり、制約条件を満たすことができなかった、ということですから、「C(コスト)」「D(納期)」「S(スコープ)」のいずれか(もしくは複数、全部)が予定通りにいかなかった、ということです。

つまりは、プロジェクトの開始時点で「C(コスト)」「D(納期)」「S(スコープ)」を正確に予期することはそれほどに難しいのです。考えてみれば当たり前の話ですよね。現代は不確定要素に満ちています。すさまじい早さで環境が変わり、人の望むもの、社会の制度、組織の在り方などもどんどん変化していくのに、その変化のすべてを予測して織り込んだ計画を立てるなど、並の人間にできることではありません。

そこで、建前としてはパターン1をとりつつ、実際にはパターン3(「S(スコープ)」を固定)を取ることになります。その結果として「D(納期)」が遅れ「C(コスト)」も増大することから、「このプロジェクトは失敗だ」と思う人が7割にも達する状況になるわけです。

 

アジャイルプロジェクトにおける制約条件の扱い

いっぽう、アジャイルプロジェクトでは、変化は必ず起こるものであり、事前にその変化のすべてを予測することは不可能と考えるので、上記のパターン1はとりません。何らかの変化を許容するパターン2~4のどれかを取るのですが、実際にはパターン4、つまり「C(コスト)」と「D(納期)」を固定して「S(スコープ)」を変える、という方法を取ることがほとんどです。

まず、パターン2(「C(コスト)」のみ可変)を取らない理由を考えてみましょう。およそ組織というものは、いったん立てた予算を増額するのには非常に高いハードルを設けるものです。「納期に間に合わなさそうだからお金をもっとちょうだい」などといっても雷を落とされるだけです。また、仮に首尾よくお金を引き出して要員を追加したとしても、プロジェクトの進行がスピードアップするとは限りません。新しく加わったメンバーがプロジェクトの内容を理解し、ほかのメンバーと同等のパフォーマンスを発揮できるまでには相応の時間が必要です。よって、追加投資が期待する効果を上げる見込みは薄く、このパターンを取るメリットは少ない、ということになります。

次にパターン3(「D(納期)」のみ可変)はどうでしょうか。最初に決めたスコープはすべて満たさないとプロジェクトは完了させられないという事情がある場合、このパターンを取ることになります。ただし、納期を延ばすということは、予定より長くリソースを維持しなければならないということになるので、結果として「C(コスト)」も増大します。パターン2のところでも述べたように、一般に追加コストを獲得するのは非常に難しいので、その点もよく考慮したうえで、本当に「S(スコープ)」を変えてはだめなのかを慎重に判断すべきでしょう。

最後にパターン4(「S(スコープ)」のみ可変)についてです。アジャイルプロジェクトでこれを合理的と考えるのは、先ほども述べたように、変化は必ず起きるもの、すべての変化を予測するのは不可能、という前提があるからです。最初に決めた「S(スコープ)」が時間の経過とともに変質するのであれば、そこに対応することこそアジャイルが最も重視する「顧客価値の最大化」につながるはずです。とはいえ、無節操にスコープを広げた結果、「D(納期)」が遅れ、それに伴って「C(コスト)」が増えてしまえば、せっかく大きくした顧客価値がまた下がってしまいます。そこで、あえて「C(コスト)」「D(納期)」を固定することで、「S(スコープ)」の中身は変えても総量は変えずに顧客価値の最適化を図る、という手段を取るわけです。

 

さいごに

ここまで見てきたような、従来型のシステム開発プロジェクトとアジャイルプロジェクトにおける制約条件の扱い方の違いについて、下のような2つの三角形を組み合わせた図で説明されることがよくあります。

アジャイルソフトウェア開発手法をシステム開発プロジェクトに取り入れるときには、従来の手法とのこの違いを肝に銘じてプロジェクトを進めることが肝要です。