鉄の三角形とは

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

この制約モデルは、三角形と名が付けられているように「スコープ(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度しか行われないのに対して、スクラムではスプリントを回すサイクルの中で各工程が繰り返し行われます。
※ リリースはスプリントに依存していませんが、スプリント内で計画されスケジュールされるのが一般的です

鉄の三角形における、「リソース(何人で開発するか)」「時間※」が固定されているといえます。
※ リリース日では無いがスプリント期間は固定されているため

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

まとめ

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

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

考えれば当たり前なのですが、以外に言語化はできなかったりするので、知らなかった人は是非頭にいれておいてもらえるとどこかで役に立つと思います。

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

受託開発を行う場合、開発のプロセスモデルとしてはウォーターフォールモデルを選択されることが良くあります。
理由は、ウォーターフォールモデルは計画前に全行程の概要が決定されるため「開発の金額見積もり」や「リリーススケジュール」が立てやすいというビジネス的な背景があります。

発注側としては、いくらで開発してくれるのかは事前にわかっていた方が嬉しいですし、開発するソフトウェアのリリース後の売上計画もあるため、いつまでにリリースできるかも事前に知っておきたいのは当然だと思います。

このような事情もあり、スコープが柔軟に変更されてしまう可能性があるスクラムモデルで受託開発を行うことは日本ではあまりないように感じます。

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

ここでは鉄の三角形モデルをもとウォーターフォールモデルでの受託開発について考えて見ましょう。

受託開発における開発金額というのは鉄の三角形における「リソース」にあたります。
受託会社は契約した金額によって、利益が出る範囲でエンジニアをアサインし開発するためです。

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

つまり、受託開発において「いくらで開発するか」「リリースは大体どのくらいになるか」が決まっている場合、鉄の三角形における「スコープ、リソース、時間の全てがロックされている」ことになります。

これは問題が発生したときにどの成約も変更することができないという非常に危険な状態です。

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

プロジェクトの炎上と第４の選択肢の話

本来であれば、「時間」または「リソース」を変更可能としているウォーターフォールモデルですが、前述のように全ての成約がロックされてしまっている開発プロジェクトは世の中に沢山存在しています。

では全てがロックされている状態でプロジェクトをリカバリーするにはどうすればよいか？
受託会社の開発チームが取れる選択肢は主に３つあります。

①メンバーを増員する

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

② リリース日を延期する

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

※ 結果プロジェクト期間を延ばすため、ほとんどのケースでリソースも増加します

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

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

炎上するプロジェクトにおいて、これらの選択肢の中で③が取られることが多いと感じています。
ビジネス的な観点から①、②の選択肢を一番初めに選択できる企業が少ないというのが印象としてあります。

※ 僕の主観なので①、②を行なっている企業も当然あります。
※ ①、②、③を全て行うスーパー炎上プロジェクトもあります（泣）

③の選択をすることによる犠牲

炎上しているプロジェクトで、鉄の三角形モデルに当てはまらない選択を行なった場合、犠牲になるのは「プロダクトの品質」になると僕は考えています。

人間は、機械ではないので時間を増やしたところで一日の生産性はほとんど上がりません。
このような選択をしたプロジェクトは多くの場合、製造工程をなんとか切り抜けても、評価工程で想定よりも多くのバグを出し、さらなる炎上に発展しているケースを何度も見て(体験して)きました。
※ 結果、さらなる増員、スケジュール延期という最悪のケースも良く起こります。

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

言いたいこと

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

この理解のために鉄の三角形というモデルは非常に有効な考え方だと思っています。
実際に開発を行うメンバーだけでなく、プロジェクトマネージャー、営業、経営の方にもぜひ知っていただきたいです。

Discussion