すべてのアジャイルソフトウェアプロジェクトには、プロジェクトの成果物、締め切り、予算などの目標が設定されています。ただし、これら 3 つの制約を管理するのは思っているほど簡単ではありません。そこで、数十年の実績があるプランニングの「鉄のトライアングル」を参考にしながら、異なる変数の間でバランスを取ってアジャイルソフトウェアチームをアジャイルプロジェクト管理の極致へと導く方法を見ていきましょう。
従来の鉄のトライアングル
鉄のトライアングルのプロジェクト管理では、ある制約を他の制約に影響を与えずに変えることはできないので、「鉄」とみなされる制約があります。Martin Barnes 博士が 1969 年に提案した最初の鉄のトライアングルのプロジェクト管理は、プロダクト開発におけるウォーターフォール型のアプローチに従うものでした。つまり、スコープがあらかじめ決まっていてリソースと時間は変更可能です。ソフトウェアチームにとっては、プロジェクトのスコープ (作業項目の一覧) を決めるプロダクト要件を定義してプロジェクトを始めることになります。リソースとスケジュールは可変であり、固定されたスコープによって見積もられます。
- スコープとは、機能や機能性など、実際に動くプロダクトをデリバリーするのに必要な作業のことです。
- リソースは、予算、そしてデリバリーと実行に関わるチームメンバーを指します。
- 時間は、リリースやマイルストーンなどのプロダクトをチームが市場にデリバリーする時間のことです。
鉄のトライアングルのプロジェクト管理の目的は、ビジネスに役立つトレードオフの実行に必要な情報をプロダクト チームに提供することです。たとえば、スコープが決まっていて、リリース日に間に合わないことにプロジェクトの折り返し地点で気付いたとします。ここで変更可能なのは次の要素です: 1) 時間 - リリース日を遅らせる。2) リソース - プロジェクトの人員を増やす (コストも増加する)。ソフトウェア開発は 21 世紀に進化を遂げ、コラボレーションの強化と顧客のフィードバックへの素早い対応が重要になっています。その声に応える形でアジャイル手法が生まれました。
鉄のトライアングルのアジャイルへのマッピング
チームがウォーターフォール型のプロジェクト管理 を実施している場合、またはアジャイル管理に慣れていない場合、覚えておくべき重要なことは固定されたものと見積もられたものの違いです。ウォーターフォール型の開発と異なり、アジャイル プロジェクトでは、スケジュールとリソースが固定されている一方で、スコープが変化します。アジャイル開発では、プロジェクトのスコープが変わる可能性がありますが、チームはあらかじめ決められたイテレーション作業に取り組みます。それは、スクラム フレームワークの場合はスプリント、カンバン フレームワークを使用している場合は WIP 制限になります。チームは、開発プロセスを通じて変更を加えないことをお勧めします。プロダクトまたはプロジェクトを同じチームでやり抜くことで信頼が生まれるとともに、知識が蓄積されてチームの効率性も上がります。
どのようなソフトウェアをビルドしてデリバリーするかというスコープの考え方はアジャイル開発でも同じです。ただし、アジャイルでは密な細かい要件を前もって決めるのではなく、より大局的な要件に集中します。製品マネージャーは Jira などのツールで定期的にプロジェクトのスコープの管理と調整 (優先順位付け) を行います。製品マネージャーは、さまざまな方面 (市場の状況、顧客からのフィードバック、競合など) からあがってくるアジャイルの定性的および定量的なフィードバックに基づいて次のスプリントで達成すべき作業を決定します。リソースと時間はあらかじめ決まっているため、開発チームは市場の変化に対応しやすくなり、より早く顧客に価値を提供できます。制約が見える化されているため、チームに一貫性が生まれてリリース サイクルが短くなります。これはアジャイル開発に欠かせない要件です。また、鉄のトライアングルを通してプロジェクトを見ることで、計画を諦めることなくアジャイルに対応できます。
長期的なアジャイル計画と鉄のトライアングルのプロジェクト管理
プロジェクトが大きくなるにつれ、必要なチームの数が増えて期間も長くなります。つまり、スコープが変わるのに、リソースと時間を固定するという考え方が通用するアジャイルプロジェクトはないのです。長期間のアジャイルプランニングでは、より柔軟性のある鉄のトライアングルを使って将来の計画を立て、それが組織の目的とも合致するようにします。たとえばリーンスタートアップの流行や実用最小限の製品 (MVP) のコンセプトを思い浮かべてみてください。MVP は定義上は顧客に価値をもたらす機能 (スコープ) の小さな集まりです。このような MVP を実現するには、固定されたスコープ (フィーチャーの数) に沿って、時間のみを変数として作業を進める必要があります (特定の機能なしではリリースできないためリリース日が遅れるなど)。MVP をローンチした後に初めて、チームは変更可能なスコープに切り替えることになるのです。
ウォーターフォール型かアジャイル型かに関係なく、開発で鉄のトライアングルを使うときに正解や不正解はありません。鉄のトライアングルは最良の決断とトレードオフを行い、ビジネスの目標を達成するために使うものです。タイムラインなどのツールでは、スコープ、人材、時間といった計画の構成要素を視覚化することで、チームがリアルタイムに計画を立てられるようになります。Jira にあるチームの既存データを使えば、スコープ、チーム、時間をシンプルな操作で配置して次回の製品リリースを容易に計画できます。