一般的な見積もり(estimation)のアプローチでは、我々の望む予測可能性を得られないことが多々ある。予想は、一定範囲の起こり得る結果と、結果が現実になる可能性を答えるものだ。"いつ完了するのか？"、"xxまでに何を提供できるのか？"といった類の疑問に、確信を持って回答することができる。
Mattia Battiston氏はAginext.io 2020で、将来を予測するためのアジャイルメトリクスについて講演した。
ストーリのサイズによる見積もりによって必要期間が予測できることはほとんどない — 進行中の大量の作業、アクティビティ間にキュー内で費やされた時間、予期しなかったイベント、といったファクタの方がリードタイムに与える影響は大きいのだ、とBattiston氏は説明する。
予想(forecasting)では、チームの履歴データを使用して、将来的に起きるであろうことをシミュレーションする。予測(prediction)は起こり得る結果の範囲として表現される。結果とその実現可能性を合わせて表現することによって、我々の思考法を決定論から確率論に変えることができる、とBattiston氏は言う。そうすることで、なぜ期間が長引くのか、リードタイムに影響するのは何か、デリバリに影響するリスクは何か、といった会話をすることが可能になる。
Tascoのソフトウェア開発者でチームリーダのMattia Battiston氏に、履歴データとメトリクスを使用した将来予想について話を聞いた。
InfoQ: 一般的な見積もりのアプローチでは、私たちの望む予測可能性が得られないことが多い理由は何なのでしょうか？
Mattia Battiston: 最も一般的な見積もりテクニックであるストーリポイントを例にしてみましょう(ただし、Tシャツサイズ( t-shirt sizes)や理想時間( ideal hours)、その他の最善を提供するようにメンバに依頼するテクニックにも、同じ理由が適用されます)。ストーリの見積もりサイズ(ストーリポイント数)とストーリ完了まで実際に要する時間(リードタイム)の間に相関関係がほとんどないことは、多くのチームが経験しています。私が参加したチームでも、同じポイントに見積もられたストーリが数日で完了したり、数週間を要したりしたことがありました。
Mattiaチームにおけるストーリポイントとリードタイムの相関関係
ストーリサイズよりもリードタイムに影響を与える重要なファクタが3つあります。それらを管理しなければ、チームを予測可能にすることはできません。
まず、進行中(Work in Progress、WIP)の作業が大量にあるか、ということです。あまりに多くのことを同時に開始すると、すでに進行中のタスクの終了に注目することができなくなります。コンテキストの切り替えに時間が浪費されることで、作業の品質が低下し、単純に見えたストーリでさえ予想より長くかかるようになるのです。
第2は、アクティビティの間に、作業がどれだけの時間をキュー内で過ごしたか、という点です。私たちのプロセスでは、アクティビティと次のアクティビティの間に多少の待ち時間があります(開発者がフリーになって次のストーリを開始できるまでの待機時間、次リリースの待ち時間、など)。このようなキューは目に見えなかったり、ボード上に現れていなかったりすることが少なくありません。また見積もりでは、このような時間は無視して、何らかの作業を行っている時間のみを考慮するのが一般的です。これらのキューが管理されていなければ、多数の進行中作業が一旦停止されて、結果的に非予測性が高くなるのです。
プロセス内におけるキューの例
第3は、予期しなかったイベントは頻繁にあるか、ということです。テスト環境の棄損によるブロックなどのイベント、不明確な要件、あるいは製品の不具合のような緊急の問題、といったものは、私たちの作業を中断し、すでに開始したアクティビティを足止めします。
このような問題がひとつ以上ある — 私が関係したチームのほとんどがそうでした — 場合、これらは作業を完了するために実際に要する時間との関連性が低いため、見積もりの予測可能性は高くなりません。
自身の見積もりの予測可能性がどの程度か興味があるならば、私たちのスプレッドシートの"Are my story points predictable?"を参照してください。
InfoQ: 将来を予測するために、どのような見積もりアプローチを採用しているのですか？
Battiston: 不確実性の高いイベントに関して、作業完了までの時間などを高い精度で予測しようとする場合には、予想手法(forcasting technique)を使用するように指導しています。
一般的にはチームの履歴データを使用して、将来的に発生することをシミュレーションします。その予測結果は、特定の結果が現実になる確率と、考えられる結果の範囲という形で表現されます。
例: プロジェクトの予想(イテレーション"1334"から)
アジャイルのメトリクスに関するグル(guru)のひとりであるTroy Magnnis氏が以前、予想の隠された本当の力と言えるものを私に教えてくれました — "予想はコミュニケーションの分野である"。つまり重要なのは、予測の伝達方法を改善することなのです。
結果をこのように表現することで、"将来を予測できる"という決定論から、"考えられる結果はこれらで、この可能性が他より高い"という確率論へと、私たちの考え方が変わるのです。これによって、"プロジェクトにこれだけの時間がかかった場合はどうなるのか？その影響は何か？このリスクを低減するために何ができるのか？"といった、有意義な議論を交わすことができるようになります。
InfoQ: どうすれば予想できるのでしょう？
Battiston: メカニズムは、回答の対象となるビジネスの質問が何であるかによって異なりますが、原則としては、履歴データを使用して結果を確率論的に表現する、ということです。いくつか例を挙げましょう。
"このストーリにはどれ位かかるのか？" — 過去のストーリのリードタイムを収集して、50、80、90というようなパーセンタイル値を計算します。
その結果、答は次のようなものになるでしょう。"80パーセントの確信を持って、9日以内に終了します。4日で完了する可能性もありますが、その確率は50パーセントなので、確約することはできません。最悪のシナリオでは10日を要しますが、これが発生する可能性は10パーセントに過ぎません。"
このようにして、チームとステークホルダの両方が確信を持てる期待値を設定するのです。最も確信の持てる数値を拾い上げて"9日"と答えたくなるかも知れませんが、ステークホルダとの明確性を優先して、現実的な回答は可能性の範囲のみであることを説明した方がよいと思います。
"次のスプリントではどれだけの進捗が可能か？" — 上記と同じように、チームの過去のスループット(各スプリントで完了したストーリの数)を集めて、同様な統計値を計算することが可能です。
その上で、次のように回答します。"80パーセントの確信を持って、少なくとも5つのストーリを完了することができます。過去、80パーセントのスプリントで、少なくともその数のストーリを完了しているというのがその理由です。最大では8つですが、その確率は50パーセントに過ぎないので、それを確約するのは差し控えるべきでしょう。"
他の例や詳細については、Chris Young氏と私の共著である">Team Guide to Metrics for Business Decisions"を参照して頂ければと思います。こちらもスプレッドシートを公開していますので、これらのアイデアを実際に試してみてください: Public resources for the book Team Guide to Metrics for Business Decisions
InfoQ: どのようなデータを収集していて、その必要度はどの程度ですか？
Battiston: 最初は単純に、各ストーリの開始日と終了日の記録から始めるとよいでしょう。リードタイムを計算し、一定期間内に完了したストーリを数える(いわゆる"スループット"と"デリバリ率")には、これで十分です。
最初から多数のデータは必要ありません。５つのサンプルで"最低限"、７～11のサンプルがあれば十分な精度が得られます。