アジャイル開発のインパクトを定量化する

　本記事では、アジャイル開発の生産性を効果的に把握するための指針を専門家の視点から解説する。

　アジャイル開発手法はIT業界にしっかりと根を下ろしている。このプラクティスは当初、ウォーターフォール型の開発手法を置き換える斬新な開発方法論として世に登場した。その後、製品化までの期間の短縮や、開発費の低減、顧客の期待に沿える高品質なソフトウェアの構築が可能になる点を買われ、従来手法に取って代わるようになった。そして、ソフトウェア需要の増加とともに、規模の小さい新興企業から大企業に至るまでの多種多様な企業で、数多くの開発チームがアジャイル開発手法を採用するようになってきている。

　アジャイル開発手法は、社内におけるさまざまな規模のソフトウェア開発プロジェクトに適用できる一方で、そういったプロジェクトの可視性を得るために、マネジメントはいまだに最適な方法を模索し続けている。しかし大企業の場合、実際にプロジェクトに携わる人々による主観的な事例証拠に頼った方法を採るわけにはいかない。業務上の意思決定の基準となり得る定量的な洞察が必要なのだ。

　以下では、アジャイル開発手法への移行中、そして移行後に下す選択によってもたらされる影響を定量化するためのティップスを解説する。

＃1：把握しやすさという観点からではなく、望ましい成果という観点から手を付ける

　ものごとをより的確に把握することで、より深い洞察が得られるとともに、より優れた意思決定が可能となり、最終的により満足のいく成果を達成できる。ほとんどの人は把握しやすい部分から評価を始めてしまうが、把握しやすい部分から手を付けると、誤った結論に向かってしまう場合もある。ここで全米プロバスケットボール協会（NBA）の選手2名の例を見てみることにしよう。

　Golden State WarriorsのMonta Ellis選手は、NBAの2010年得点ランキングにおいて9位であった。また、Denver NuggetsのCarmelo Anthony選手は同ランキングにおいて8位であった。個人の総得点数に目を向けるのは簡単だ。この点を見た場合、得点数の多いこういった選手がいれば、チームは試合に勝利できると考えるはずだ。

　しかし現実には、彼らがプレイしている時の方がチームは弱かったのである。得点とは、（1）放ったシュートの数、および（2）バスケットに入ったシュートの割合という2つの評価から作り出される値である。しかし実際のところは、2人の「スター選手」は（2）、すなわちシュートの成功率がそれほど高くなかった。彼らが高得点選手としてランキング入りしているのは、単に多くのシュートを放っていたからでしかない。彼らは得点を上げるチャンスの高いチームメートから文字通りボールを奪ってシュートしていたというわけだ。

　つまり、状況の評価というものは、状況の把握から始まり、それがもたらす成果に進んでいくわけであるが、その際にはまず成果という観点から見ていくべきなのだ。これがODIMと筆者が呼んでいるものだ。

　ODIMとは「より満足のいく成果（better Outcomes）←より優れた意思決定（better Decisions）←より深い洞察（better Insights）←より的確な把握（better Measures）」の頭文字である。先ほどのNBA選手は、自らの得点数を増やすことよりも、試合で勝利するという成果に焦点を当てるべきなのである。彼らがこういった事実をフィードバックとして捉え、さまざまな条件下でのチームの得点可能性について包括的に考えるのであれば、勝利という究極の成果を達成するためのより優れた意思決定を試合中に行えるようになるはずだ。ここに2つ目のティップスが隠されている。

＃2：把握した事実はテコ入れ材料ではなく、フィードバックであると捉える

　ウォーターフォール開発とアジャイル開発を分ける大きな違いに、頻繁なフィードバックというものがある。健全なアジャイルプロジェクトでは、短期間でのイテレーションと顧客からの迅速なフィードバックが組み込まれている。このため、アジャイル開発において把握した事実を効果的に活用するには、把握した内容を旧来のように動機付けを与えるためのテコ入れ材料と捉えるのではなく、フィードバックとして捉えることが鍵となる。テコ入れ材料として捉えてしまうと、上述した例のように、得点を得続けるのが目的になってしまいやすくなる。こういった暗黒面に落ちるようであってはいけない。

　「フィードバック」と「テコ入れ材料」の間には、わずかであるもののの重要な違いがある。フィードバックは、自らのパフォーマンスを改善するうえで探し求めるべきものだ。しかし、テコ入れ材料は他者に影響を与えるために用いるものである。この違いは、把握した事実自体ではなく、把握した事実をどのように活用するかという点にある。

　例えば、バーンダウンチャート（訳注：縦軸に作業量、横軸に時間を割り当てる右肩下がりの折れ線グラフ）を正しく使用すれば、進捗が目標通りであるかどうかがひと目で分かるため、適切なタイミングでの調整が可能になる。その一方で、火が吹いているプロジェクトに対してダメを出すためにバーンダウンチャートを使うマネージャーもいる。これでも生産性は改善されるかもしれないが、ダメを出されたいと思っている人間などいないため、現状がどうであっても問題がないかのように取り繕われる傾向がある。

　洞察を得るための指標が現状を正確に反映していない場合、しっかりした決断など下せないはずだ（「＃1：把握しやすい部分からではなく、望ましい成果から手を付ける」を参照してほしい）。このためマネージャーは、チーム自らがパフォーマンスの改善に乗り出せるような手段を提供する方向にチームを導いていくのがよいだろう。この違いはちょっとしたもののようだが、とても大きい。