知っておきたいソフトウェア開発と鉄の三角形の話

鉄の三角形とは

ソフトウェア開発における『鉄の三角形』とは、ソフトウェア開発のプロジェクトにおける管理成約をモデル化したものです。

この制約モデルは、三角形と名が付けられているように「スコープ(scope)」「リソース(resource)」「時間(time)」の3つの成約が定義されています。

スコープ(scope)

「スコープ(scope)」は、ソフトウェアで実装すべき機能。またはそれに必要な作業を指します。

リソース(resource)

「リソース」(resource)は、開発するチームメンバー。または予算(お金)を指します。

時間(time)

「時間(time)」は、ソフトウェアがリリースされるまでの時間。スケジュールを指します。

この３つの制約がなぜ三角形になっているかというと、これらの成約はお互いに依存していて「いずれかの成約を変更すると他の2つの制約に影響を与える」ことを示しています。

具体例

具体的な例でみてみましょう。
次のような成約で計画されているアプリケーションを開発することを考えます。

【プロジェクトの成約例】
・スコープ(つくりたい機能): チャットSNSアプリケーション
・リソース(何人で開発するか): 10人
・時間(いつまでにリリースするか): 半年

この計画は、いずれかの成約に変更があった場合に破綻します。

■ スコープに変更があった場合

例えば「チャット機能以外にライブ配信機能を付けたい」といった要望が出た場合、開発はおそらく半年でリリースできなくなります。
また、半年でリリースする計画で進める場合はメンバー10人では足りなくなるでしょう。

■ リソースに変更があった場合

「10人で開発を計画していたが、メンバーを確保できず5人で作業しなければならなくなった」となった場合、スコープの変更と同様に半年でリリースするのは難しいでしょう。
半年でリリースすることは変えれないとなれば、こんどは計画していた機能を全て実装することは難しくなります。

■ 時間に変更があった場合

「半年の計画だったが、ビジネスの都合で3ヶ月で作らなくてはいけなくなった」という場合、スコープとリソースの変更と同様にメンバーが足りないか、全ての機能が実装できなくなります。

このようにソフトウェア開発のプロジェクトというのは、「スコープ(scope)」「リソース(resource)」「時間(time)」の成約によって成り立っているという考え方が「鉄の三角形」というモデルです。

鉄の三角形の目的

鉄の三角形の目的は、『プロジェクト管理で発生する問題に対して、トレードオフの判断基準を提供すること』です。

先程と同じ例で考えてみます。

【プロジェクトの成約例】
・スコープ(つくりたい機能): チャットSNSアプリケーション
・リソース(何人で開発するか): 10人
・時間(いつまでにリリースするか): 半年

このプロジェクトが実際に開始されて3ヶ月が経ち、製造工程で遅延していることが判明したケースを考えます。
このプロジェクトをマネジメントするとき、なんとかして計画どおりリリースを行なうために改善案を考えなくてはなりません。

■ つくりたい機能は変えられない場合(スコープがロックされている状態)

「開発は遅延しているが、つくりたい機能はどうしても変えられない」

こういうケースでは、「開発メンバーの人数を増やす(リソースの変更)」または「リリース日を延期する(時間の変更)」という選択肢が考えられます。

■ 開発メンバーの人数を増やすことが難しい場合(リソースがロックされている状態)

「開発は遅延しているが、開発人数のメンバーを増やすことができない」

こういうケースでは、「開発機能を減らすまたは変更する(スコープの変更)」または「リリース日を延期する(時間の変更)」という選択肢が考えられます。

■ リリース日を延長することが難しい場合(時間がロックされている状態)

「開発は遅延しているが、リリース日を延長することが難しい」

こういうケースでは、「開発機能を減らすまたは変更する(スコープの変更)」または「リリース日を延期する(時間の変更)」という選択肢が考えられます。

ビジネスとしてソフトウェアを開発していると上記のケースのような『何かの成約がロックされている』という状態は必ず発生します。

このような問題が発生した場合に、適切なトレードオフの判断ができるようにモデル化されたものが「鉄の三角形」なのです。

ソフトウェア開発のプロセスモデルと鉄の三角形

ソフトウェア開発には、プロジェクトを管理するためのプロセスモデルがいくつも存在します。
代表的なものとしては、「ウォーターフォールモデル」「プロトタイプモデル」「アジャイルモデル」などが有名です。

これらのプロセスモデルと鉄の三角形がどのように関係しているのかをみていきます。

※ ここでは各プロセスモデルの詳細については割愛します。

■ ウォーターフォールモデルと鉄の三角形

ウォーターフォールモデルというのは、要件定義、設計、製造など各工程を順番に進んでいくモデルで、基本的に前工程へ戻ることはありません。
全ての機能に対して詳細に設計まで行なった後に製造、テストまで実行するため、プロジェクト計画完了時点で開発全体の大枠が見えているというのが特徴でありメリットでもあるモデルです。

ウォーターフォールモデルで開発を行う場合は、その特徴から鉄の三角形における、『スコープ(どんな機能を作るか)が固定されている』といえます。

つまり、プロジェクトで何か問題が発生した場合は、「開発人数を増員する(リソースの変更)」か「リリース日を延期する(時間の変更)」という選択ができることになります。

■ アジャイルモデル(スクラム)と鉄の三角形

最近は内製のソフトウェアでは、アジャイルな手法でソフトウェア開発を行うことが主流になっています。
ここでは、アジャイルソフトウェア開発の手法の一つである「スクラム」を使った場合を見ていきます。

スクラムとは、基本的に1つのチームを組んでソフトウェアを開発していくフレームワークで、特徴として固定された期間(スプリント)を固定された人数で繰り返してソフトウェアを開発します。

ウォーターフォールモデルでは、設計→製造→リリースなど各工程が1度しか行われないのに対して、スクラムではスプリントを回すサイクルの中で各工程が繰り返し行われます。
※ リリースはスプリントごとに行なうわけではなく、スプリント内で計画され実行されるのが一般的です。

これらの特徴から、鉄の三角形における「リソース(何人で開発するか)」「※時間(スプリントの期間)」が固定されているのがスクラムです。
※ スプリントの期間はリリース日とは関連していませんが、マイルストンという意味で固定されているといえます。

つまり、スクラムモデルでプロジェクトで問題が発生した場合は、「スコープ(開発する機能)を変更する」という選択ができることになります。

まとめ

このように鉄の三角形モデルに落とし込むことで、プロジェクト計画について正しい選択がしやすくなります。

プロジェクトに遅延が発生しているときに「人数は増やせないし、機能も減らせない」となった場合は「リリース日を調整」するために動くという合理的な選択肢ができるわけです。

鉄の三角形が示す成約は、よく考えると当たり前なのですが意外と言語化できていないことがある重要なモデルだと思います。

知らなかった人は是非頭にいれておいてもらえるとどこかで役に立つと思います。

【余談】 受託開発とウォーターフォールモデルの現実

受託開発を行う場合、開発のプロセスモデルとしてウォーターフォールモデルが良く使われます。

ウォーターフォールモデルは、実際の開発が始まる前に全体像が把握できることから「開発の金額が見積もりやすい」「リリーススケジュールが立てやすい」などのメリットがあるためです。

発注側としては、「いくらで作れるのか」「いつまでにできるのか」は非常に重要であり、ソフトウェアをサービスとしてリリースした後の企業の売上計画にも影響してきます。
なにより、発注側にはビジネスとしてやりたいことのビジョンが明確にありますから、「どんな機能を作りたいか」もある程度は決まっています。

アジャイルな開発プロセスを選んだ場合、変更に柔軟なのは「スコープ(どんな機能を作るか)」ですので、「つくりたい機能が決まった時期までに完成しない可能性がある」プロセスはなかなか発注側に受け入れられにくいという現状があります。
※ 個人的な見解ではありますが、特に日本ではその傾向が強いと思います。

受託開発のウォーターフォールモデルと鉄の三角形

ここではウォーターフォールモデルで受託開発を行なったときの、鉄の三角形モデルについて考えてみます。

受託開発では、企業が受け取る『売上金額』が鉄の三角形における「リソース」にあたります。
売上の金額によって、開発チームの人数が確定するからです。
(開発はほとんどが人件費のため、売上を上回る人数を稼働させることはできません)

リリーススケジュールは当然「時間」に該当します。

そして、今までの説明のとおりウォーターフォールモデルは、「スコープ」をロックするモデルです。

つまり、受託開発のウォーターフォールモデルにおいて、開発人数とリリーススケジュールが確定しているプロジェクトがあるとした場合、それは『鉄の三角形におけるスコープ、リソース、時間の全てがロックされている』状態ということです。

このようなプロジェクトでは、問題が発生したときにどの成約も変更することができないため非常に危険な状態です。

この状態で、プロジェクトに遅延が発生すると何が起こるか？
それが『プロジェクトの炎上』です。

プロジェクト遅延時の選択肢

本来であれば、「時間」または「リソース」を変更可能としているウォーターフォールモデルですが、前述のように全ての成約がロックされてしまっている開発プロジェクトで遅延が発生した場合はどんな選択肢があるかを考えてみます。

僕が考える選択肢は主に次の３つです。

■ ①メンバーを増員する

受託会社は自社の利益を減らすことにはなりますが、メンバーを増員して問題を解決します。
これは、鉄の三角形における「リソースの変更」にあたります。

■ ② リリース日を延期する

発注元の計画を見直して、リリース日を延長してもらえるように調整します。
これは、鉄の三角形における「時間の変更」にあたります。

■ ③ 開発メンバーの一日の作業時間を延長する

これは、鉄の三角形モデルには存在しない第４の選択肢です。
一日の作業時間を増加して生産性をあげることで遅れを取り戻そうという選択です。
受託会社は残業代を支払うことで売上は減りますが、①、②の選択肢よりはリーズナブルにみえてくる選択です。

個人的な主観としては、炎上するプロジェクトでは、これらの選択肢の中で③が取られることが多いと感じています。
理由は、ビジネス的な観点から①、②の選択肢を一番初めに選択できる企業が少ないと考えるからです。

③の選択をすることで何が起きるか

炎上しているプロジェクトで、③のように鉄の三角形モデルに当てはまらない選択を行なった場合は、大体のケースで犠牲になるのは「プロダクトの品質」です。

人間は機械ではないので、作業時間を増やしたところで一日の生産性はほとんど上がりません。
残業を増やしたプロジェクトは多くは、仮に製造工程をなんとか切り抜けてたとしても、評価工程で想定よりも多くのバグを出し、さらなる炎上に発展していきます。

そして、最悪の結果、さらなる増員またはスケジュール延期というパターンも起こりえます。

品質が悪いソフトウェアというのは、それほどプロジェクトに与える影響が大きいのです。
見かけ上の進捗を出したところで、計画自体を見直さない限りは最終的にはどこかで破綻するのです。

余談のまとめ

この余談で伝えたかったのは『なぜプロジェクト計画が破綻するのか(=炎上するのか)を正しく理解することが重要』ということです。
※「受託でウォーターフォールモデルは破綻するからやめようね」ということではありません。

鉄の三角形は一つのモデルに過ぎませんが、このように物事をシンプルに解釈できる良いものだと個人的には感じています。

実際に開発を行うメンバーだけでなく、プロジェクトマネージャー、営業、経営の方にもぜひ活用していただければ幸いです。