Program and Value Stream Backlog

なぜ仕事をするかに重きを置くべきである。

– W・エドワーズ・デミング

プログラムバックログと価値のストリームバックログの概要

プログラムバックログと価値のストリームバックログは、ソリューションを進めるために予定されている今後のすべての作業のための唯一の決定的なリポジトリである。これらのバックログは、主にユーザーのニーズに対処し、ビジネス上の利点を提供することを目的とする、今後のフィーチャー(プログラムバックログ)やシステム能力(価値のストリームバックログ)によって構成される。また、学習を進めるため、アーキテクチャー滑走路を構築するために必要なイネイブラーも含まれる。

バックログにある各バクログ項目は顧客、ビジネス責任者、プロダクト管理、プロダクトオーナー及びアーキテクト等の利害関係者から由来する。プロダクト管理はプログラムバックログを管理する。ソリューション管理は価値のストリームバックログを管理する。効果的にバックログ項目を識別し、手入れし、「重みづけされた最短作業から着手」(WSJF)による順序と優先順位を付けるのは、ソリューションを経済的に成功させるための重要ポイントである。

バックログには、新しいビジネス機能性及びアーキテクチャー滑走路を拡張するために必要なイネイブラーが含まれているため、キャパシティ割り当てが利用できる。キャパシティ割り当ては、直近及び長期なベロシティー及び品質を確保できるように役に立つ。

詳細

プログラムバックログと価値のストリームバックログは、ソリューションの振る舞いに影響を与えるすべての今後の作業のリポジトリであり、それぞれはプロダクトとソリューション管理によって作成、維持、優先順位付される。プログラムバックログは、プログラムと価値のストリームカンバンを通って実装のために承認されたフィーチャーとシステム能力を短期的に保有する場所である。図1に示すように、これらのバックログ項目は「ストーリーポイント」で見積もらなければならない。

Figure 1. Exploded view of program backlog, with story point size estimates
図1.プログラムバックログの分解図。ストーリーポイントで見積もる

バックログの手入れ

価値のストリーム (VS)アジャイルリリース列車 (ART)は、安定した8~10週間の「計画> 実行> デモ> 検査と適応」のプログラムインクリメントリズムで運行している。この安定したリズムは脈であり、これによりバックログの準備も促進される。

バックログをよく推敲せずにPI計画前ミーティング PI計画策定に参加することは、今後のPIに受け入れられないリスクを加えることである。そのため、PI計画策定イベントの間はプロダクト管理とソリューション管理たちにとっても忙しい時期である。なぜかというと、次のPI計画策定に向けて、彼らはずっとバックログを手入れし続けているからである。このプロセスを可視化し、また、今後のPIのために「バックログの準備」を達成することは、ARTとソリューションカンバンの主な目的である。通常、バックログの手入れでは以下を行う。

  • バックログの定義レビューと更新、及び受け入れ基準の作成
  • チームと協力して、技術の実現可能性とスコープの見積もりを確立する
  • バックログ項目を小さなインクリメンタルな価値のかたまりに分割する方法を分析する
  • 新しいフィーチャーやシステム能力によって生じたイネイブラーを決定し、また、キャパシティの割り当てを確立する

バックログの優先順位付け

バックログに優先順位を付けることは、プログラムの経済面での主要原動力である。そのため、プロダクト管理者及びソリューション管理者は、「重みづけされた最短作業から着手」の優先順位付け法を用いて作業の順番を決定する。要約すると、WSJFは最終的に以下の簡潔な公式に変換される。

figure

 

この公式を適用するには、分子の各項目をそれぞれ相対的にランク付けする必要がある。分母は作業規模であり、相対的な測定や絶対的なストーリーポイント見積もりを利用できる。(注意:WSJFを計算時に、本当の分母は作業期間である。我々は作業規模を作業期間の代りとして利用している。初期段階では、誰がその作業を行うか、その作業にどのくらいキャパシティを割り当てられるか分からないので、期間の見積もりはほとんどできない。一般的に、大きな作業はより長い期間が必要となるため、作業規模は合理的な近似代理である。)

作業規模に関しては、すでに進行中のバックログ項目の場合、分母には、残作業規模だけを含めるべきである。もし、バックログ項目に関する残作業がバックログ内の他のフィーチャーより優先度が低いと判断されれば、このバックログ項目を「十分によい」ものとして、チームは優先順位の高い他の作業に移ることができる。これは暗黙のうちにReinertsenの主要経済原則E17(参考文献[2])を実践している。E17は「サンクコスト原則:すでに使った金を考えるな」である。

PI計画策定の準備

PI計画策定の1~2週間前もとても忙しい時期である。プロダクト管理者とソリューション管理者は最終のバックログ準備を行い、ビジョンの概要説明を更新し、プロダクトオーナーと協力して、イベントの前にバックログについて知らせておく。システムとソリューションアーキテクト/エンジニアリング は、モデルやアーキテクチャーフィーチャーの定義を更新し、エンドユーザーの価値を提供するためにフィーチャーやシステム能力がどのように連携するかを示すユースケースを開発し、PI計画策定時の概要説明を準備する。

キャパシティの割り当てによって価値提供とソリューションの統一性を最適化する

アーキテクチャー滑走路の構築によって、今後のPIのために必要な要求や設計を調査する時間を提供し、問題領域の可視化を強化するためのプロトタイプやモデルを作成する。すべてのARTと価値のストリームが直面する課題に、ビジネスフィーチャーとシステム能力のバックログと、アーキテクチャー滑走路への継続的な投資ニーズとのバランスをどう取るかという問題がある。

ベロシティーの低下を避けたり、技術が時代遅れになってシステム全体をリプレースしなければならなくなる時期を先に延ばせるよう、ARTはソリューションのイネイブラーの進化に絶えず投資しなければならない。その結果、図2に示すように、時折、異なる人がチームを異なる方向に引っ張ることができるので、作業の優先順位付けは複雑になる。

Figure 2. Business vs. enabler backlog items dilemma
図2.ビジネスとイネイブラーバックログ項目のジレンマ

この課題を対処するために、チームはキャパシティの割り当てを利用する。キャパシティの割り当てにより、チームは、まず、次のPIでチームの全体工数を活動の種類ごとにどのくらい適用できるかという方針を決定する。次に、種類ごとに作業をどのように実施するかを決定するための方針を確立する。図3および表1にその結果を示す。

Figure 3. Capacity allocation for architecture in an ART backlog for a single PI
図3.1つのPIのARTバックログにおけるアーキテクチャーへのキャパシティの割り当て

 

  1. 各区切りで新フィーチャーやシステム能力の開発とイネイブラーとに、どのような割合でリソースを配分するかに同意する
  2. システムとソリューションアーキテクト/エンジニアリングがイネイブラーに関する権限を持ち、その部分の作業の優先順位を付けることに同意する
  3. プロダクト管理とソリューション管理がビジネスバックログ項目の優先順位をつけることに同意する
  4. 経済面を考慮して、共同で作業の優先順位をつけることに同意する
  5. 顧客価値を最大化するよう、協力して作業の順序をつけることに同意する

表1 イネイブラーや、フィーチャーとシステム能力のキャパシティの割り当てを管理するためのポリシー例

同意したポリシーはしばらく続けて使用することができるが、割り当てられるキャパシティの量はコンテキストにより変化させなければならない。ARTのコンテキストでは、この決定は、各PIの準備のためにバックログを手入れする作業の一環として見直すことができる。ソリューションのPI計画策定前に、ソリューション管理やソリューションアーキテクト/エンジニアリングは、価値のストリーム全体について同様な決定を行う。

バックログ、待ち行列、リトルの法則、待ち時間

バックログ、待ち時間及びフローの関係について、別途議論することは重要である。待ち行列の長さを管理する原則では、この関係を詳細に議論したため、完全に理解するためにはそちらを参考してほしい。ただし、プログラムバックログと価値のストリームは納品の時間とスループットに大いに影響しかねない重要な「バックログ」であるため、ここでは、その重要な議論を要約しておきたい。

  1. リトルの法則は、待ち行列内の項目の平均待ち時間が、待ち行列の平均の長さを待ち行列内の項目の平均処理速度で割ったものに等しいことを立証している。待ち行列が長ければ長いほど、待ち時間が長くなり、ばらつきが大きくなる。(スターバックスで並んでいるとしよう。もし、自分の前にトールコーヒーを注文する人が10人がいるなら、数分後には自分の番になるだろう。しかし、その人たちが全員、特別熱いバニララテと温めたベーグルを注文するなら、ミーティングに遅刻してしまうかもしれない!)
  2. 長い待ち行列はよいことがない。モチベーションの低下、品質の悪化、より長いサイクル時間、大きなばらつき(スターバックスを考えて)およびリスクの増加を引き起こす。(参考文献[2])
  3. プログラム及び価値のストリームバックログは1つの待ち行列ではない。各項目は素早く納品できるよう他の項目を飛び越すことができるからである。また、常にバックログのすべてに対し、対応しないことを選択できる。(これらはどちらも、スターバックスの例には当てはまらない。)
  4. しかし、バックログの項目を利害関係者に確約している場合、バックログは待ち行列と同様に動作し、長くなればなるほど、利害関係者が対応をより長く待たなければならない。そして、長く待たせすぎると、彼らは、別のコーヒーショップを探しにいってしまう。この店では、彼らの急速に変化する市場のニーズを満たすことができないからである。

開発プログラムのスピードを上げ、素早い対応を可能にするには:チームは積極的にバックログを管理し、そして、短くしておく。また、チームは長期的な作業に対する確約を制限しなければならない。なぜならば、前の確約よりも重要な項目が現れるかもしれないからである。

もし、バックログにあまりにも多くの固定され、確約された要求がある場合、チームはいくら効率的なチームであっても、迅速に対応できなくなる。

積極的にバックログを管理し、そして、短くする。こうすることにより、チームは信頼性と迅速さの両方を手に入ることができる。


さらに知りたい場合

[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: 12 October 2015