WSJF

1つのことしか定量化できない場合、遅延のコストを定量化せよ。

– Don Reinertsen

「重みづけされた最短作業から着手」(WSJF)の概要

SAFeは、複数のアジャイルリリース列車(ART)が進行中で、継続的な開発に従事している状況における利用状況を想定している。この継続的開発、すなわちプロダクト、アプリケーション、サービスなどのフローにより、企業の価値のストリームを作り上げる。従来では、プログラムとその経済性を制御するために、各種の承認やフェーズの入り口が利用される。SAFeでは、従来プロジェクトとプログラムの「開始-停止-開始」のような切り替えに発生するオーバヘッドや遅延を避ける。

この継続的なフローモデルは遅延の低減に役に立ち、システムがリーンの状態を保つことを助ける。その一方で、我々はプログラムから得た価値はビジネスに最大の経済的成果を提供するために、プログラムの優先順位が常に更新されることを保証しなければならない。フローの中では、最大の経済的成果を促進するのは、論理的に個々の作業のROIというより、むしろ作業の順序付けである。そのため、「WSJF」アイコンは、「重みづけされた最短作業から着手(WSJF)」を用いてどのようにART、ソリューション及びポートフォリオバックログの優先順位が再調整されるかを示す。WSJFは遅延のコスト作業の規模(期間の代理として)で計算される。このアルゴリズムを利用して、PIの区切りで現在のビジネス背景、価値、時間、開発実績、リスクと労力の考慮に基づきプログラムの優先順位は継続的に更新される。便利上、自動的に既に費やした費用を無視する– これもリーン経済学のもう一つ重要な原則である。

詳細

Reinertsen [2]は「重みづけされた最短作業から着手(WSJF)」と呼ばれ、プロダクト開発フローの経済学に基づく作業の優先順位付けのための包括的なモデルを説明した。WSJFは遅延のコストを作業の規模で割ると計算される。最も短い時間で最も大きな価値が提供できる作業が先に実装のために選ばれる。SAFeにこのモデルを適用する場合、以下を含むプロダクト開発フローの他のいくつかの重要原則をサポートする。

  • 経済的な観点を採用する
  • 既に費やした費用を無視する
  • 1つのことしか定量化できない場合、遅延のコストを定量化する
  • 経済的な選択は継続的に行わなければならない
  • 経済的な制御を分散するため、意思決定ルールを使用する

WSJFが適切に適用される場合の影響が図1に示す(参考文献[2]と[3]では全面な議論がある)。各状況における遅延のコストが曲線の下の領域に示される。「重みづけされた最短作業から着手」を実施すると、最大な経済性を提供する。

Figure 1. The economic effect of doing the Weighted Shortest Job First (WSJF); cost of delay for work
図1.「重みづけされた最短作業から着手」の経済効果、及びフィーチャーの遅延のコスト

遅延のコストを計算する

SAFeでは、我々の「作業」は開発しなければならない「エピック」及び「フィーチャーとシステム能力であるため、個々の作業の遅延のコストと期間を計算する必要がある。以下3つの主要要素が遅延のコストに影響を与える。

ユーザー-ビジネス価値。「我々のユーザーはそれより、こっちの方が好むか」、「ビジネス上の収益への影響は何かがあるか」、「遅延の場合、潜在的なペナルティや好ましくない影響があるか」。

時間価値。「ユーザー/ビジネス価値は時間とともにどのように減衰するか」、「固定の締め切りがあるか」、「顧客が我々を待ってくれるか、ほかのソリューションを導入に移るか」、「影響するクリティカルパス上のマイルストーンがあるか」。

リスクの低減/機会をもたらす価値。「我々のビジネスにほかにどのように役立つか」、「今回または将来の納品のリスクを軽減するか」、「得られるだろう情報に価値があるか」、「このフィーチャーは新しいビジネス機会をもたらすか」。

また、我々は継続的な開発のフローにいるし、選択するために十分大きなバックログを持っているので、絶対的な数値を気にする必要はない。むしろ、見積もりポーカーにある変更されたフィボナッチ数を利用し 相対的にバックログ項目をお互いに比較するだけである。そして、フィーチャーの遅延コストは以下である。

遅延コスト = ユーザー-ビジネス価値 + 時間価値 + RR-OE価値

期間

次は作業の期間を理解しなければならない。初期段階では、誰がその作業を行うか、その作業にどのくらい容量を割り当てられるか分からないので、期間の見積もりはかなり難しいかもしれない。本当は分からないかもしれない。幸いに、作業の規模を代わり利用できる。固定のリソースを持っているシステムの場合、作業の規模は期間の良い代理である(もし、私は草刈機を利用し草刈をする唯一の人であれば、前の庭は後ろの庭と比べ3倍広い場合、前の庭の草刈時間は後ろと比べ、3倍かかるだろう)。また、我々はすでにストーリーポイントで作業を見積もる方法を理解している(フィーチャーを参照)。そして最後に、以下図2で示すように我々はWSJFを用いてフィーチャーを比べるために、合理的な簡単な計算方法を得られる。

Figure 2. A formula for calculating WSJF
図2.「重みづけされた最短作業から着手」を計算するための計算式

そして、作業(例では、3つの作業がある)を比較するために、例えば、図3で示すように、簡単なスプレドシートを作成することができる。

Figure 3. A sample spreadsheet for calculating WSJF
図3.WSJFを計算するスプレドシートのサンプル

スプレッドシートを利用する場合、チームが3つのパラメータに関して、単に各作業が他の作業との相対値を評価し(相対的見積もりを利用する。各列において、一番小さい項目を「1」として設定し、他の項目はこの項目との相対値を決定する)、そして、作業の規模(チームバックログに含まれている見積もりに基づいて、相対的な見積もりも絶対的な数値も共に利用できる)で割る。このように、作業の優先順位を決めるためのWSJFの値を計算する。

1つの作業はWSJF値が大きいほど重要である。

このモデルの1つの結果は、お金を稼ぐより簡単な方法(例えば、顧客が今喜んでお金を支払う、小さく低リスクのフィーチャー)に切り込むために、本当に大きくて重要な作業(アーキテクチャーやビジネスエピック)をより小さく相当重要な作業(フィーチャー)に分割しなければならないことである。これは現場でのアジャイルである。実装はインクリメンタルなので、もしずっと継続してきた1つの作業が他の作業と比べてランク付けが低くなる場合には、おそらく特定の要求を十分に満たしているので次の作業に移ることができる。

すでに説明したが、このモデルのもう1つの利点は、これらの数値の絶対値を決定する必要がないことである。というのは、無駄足だからである。むしろ、同じバックログの、1つの作業を他の作業とそのパラメータで評価するだけである。

そして最後に、バックログ見積もりは作業の残規模を含まれなければならないので、頻繁な優先順位の再調整はシステムが自動的に既に費やした費用を無視することになる。

作業の規模を期間の代わりに使う場合に関する注意

しかしながら、期間の代わりに規模を利用することを決めた場合、気を付けなければならない。もし、リソースの利用可能性はより大きな作業が、他の同価値の作業よりも早く納品されるということを意味する場合、より正確な結果を得るため、作業の期間を利用することを十分理解できるだろう(私は後ろの庭の草刈をする。一方、3人を雇って前の庭の草刈をする。この場合、草刈の作業時間は同じであるが、コストは違う)。しかし、価値のフローでは、これは稀なケースである。 もし選択時に小さな間違いがある場合、次の重要な作業が十分迅速に利用できる。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update: 24 August 2015