nav-portfolio-metrics

最も大切なことが測れない。最も重要な、長期的な問題が事前に測れない。
W. Edwards Deming

動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル宣言

ポートフォリオメトリックスの概要

人は、システムを測定しパフォーマンスを評価するためのメトリックスによって行動を変える。そのため、企業が設定した測定値を改善できるよう、自然に柔軟な努力がなされる。ただし、我々が理解しているように、ほとんどの測定基準が、本当の、そして多くの場合はとらえどころのない、結果の代用品でしかないため、何を要求するかを決める際には注意が必要である。アジャイルでは、物理的な作業、時間枠(タイムボックス)、すばやいフィードバックを採用しているため、これまでのドキュメントを重視した間接的なウォーターフォールベースの進捗測定よりも、本質的に測定は容易である。もちろん、間違いなく最善である測定基準は、動くソフトウェアから直接もたらされる。プログラムレベルでは、チームは主にその重要な目的に注力し、補助として追加のSAFeメトリックスを使用する。これについては、姉妹ページのARTメトリックスで説明する。このページでは、上記の点をふまえて、特定のプログラムポートフォリオのパフォーマンスを企業が理解するのに役立つさまざまな測定基準を取り上げる。

詳細

図1は、全体像(ビッグピクチャー)のポートフォリオレベルにおいて、測定が役立つ5つの箇所を示したものである。それぞれの箇所は、後の説明の対応するセクションへのリンクになっている。

図1. 全体像のポーロフォリオレベル

M1: Lean Portfolio Metrics M2: Portfolio Kanban Board M3: Measuring Epics M4: Portfolio Management Self-Assessment M5: Enterprise Balanced Scorecard

M1: リーンなポートフォリオメトリックス

企業によっては、ポートフォリオ全体の社内と社外両方の進捗を評価できる、包括的だけれどもリーンな一連のメトリックスを利用できる場合がある。「うまくいきそうな中でもっとも単純な測定基準のセット」として、図2に例を示す。これは、あるリーン-アジャイルな企業が、アジャイルへの移行時に総合的なパフォーマンスの評価に使用して効果的だったものである。

図2. 事業単位のリーンなメトリックス

図2. 事業単位のリーンなメトリックス

M2: ポートフォリオカンバンボード

ポートフォリオカンバンボード(図3)は、プログラム横断的なビジネスの取り組み(エピック)を可視化するものである。ボードの縦の列は、エピックのワークフロー内での状態を表す。「ゴー」と判断されたエピックは、「ポートフォリオバックログ」状態に進められる。アジャイルリリース列車の処理能力に十分な空きができると、次に優先順位の高いエピックがポートフォリオバックログから「プル」され、「実装中」状態に移行する。エピックはそこでエピック測定レポートを使って追跡される(後の「M3: エピックの測定」を参照)。図3に示すような目に見えるボードを使用すると、エピックが1つの列に積み上がったり、WIP(仕掛かり作業)制限を超えたりすることで、視覚的にボトルネックを特定しやすくなる。この例では、並べて確認しやすいよう、アーキテクチャーエピックビジネスエピックが1つのポートフォリオカンバンボードを使って管理されている。ただし、処理能力の異なる別のグループの人々によって分析が行われるため、エピックの種類ごとに別の「スイムレーン」とWIP制限が決まっている。

Figure 3. Portfolio Kanban Board

図3. ポートフォリオカンバンボード

M3: エピックの測定

通常、ポートフォリオエピックは複数のアジャイルリリース列車リリースにまたがって実施されるため、フィーチャーの開発がどの程度進捗しているかを評価するのは困難な場合が多い。フィーチャーは複数のストーリーに分解され、そのストーリーはたいてい複数の異なるチームによってスプリントの境界をまたがって開発されるため、複雑さはさらに増す。

エピック消化レポート(バーンアップ)

図4のエピック消化レポートは、エピックの予算、実際に完了したストーリーポイント数、それまでに完了した累積ストーリーポイント数を示している。これにより、プログラム、チーム、および時間(スプリント)をまたがって、どれだけの工数がエピックに費やされたかを可視化できる。完了した実際のストーリーポイント数と累積ストーリーポイント数は、エピックの子であるフィーチャーおよびストーリーから集計したものである。ほとんどのレポートに言えることだが、このレポートの場合も、管理のオーバーヘッドが過剰にならないよう、アジャイルな管理ツールが必要である。

Figure 4. Epic Burn-up Chart

図4. エピック消化レポート(バーンアップ)

エピック進捗レポートにより、特定のプログラムポートフォリオのすべてのエピックの進捗が一目で見えるようになる。棒の長さは、1つのエピックの子であるフィーチャーやストーリーの現在の見積もりストーリーポイント数を合計したものを表す。濃い緑の部分は実際に完了したストーリーポイント数を、薄い緑の部分は「仕掛かり中」状態のストーリーポイントの総数を、それぞれ表す。初期見積もりは、エピックの軽量ビジネスケースで承認されたストーリーポイント数であり、赤い縦棒で示される。

Figure 5 - Epic Progress Report

図5. エピック進捗レポート

エピックの成功基準

どのようなリリース列車であっても、エピックは列車を進めるための主要な経済的要因となる。エピックはアーキテクチャーカンバンまたはポートフォリオカンバンで作成される軽量ビジネス企画の一部なので、範囲を確定し、フィーチャーをさらに詳細化するのに役立つ成功基準を、エピックごとに持たせる必要がある。アーキテクチャーエピックの例を図6に示す。

図6. アーキテクチャーエピックの成功基準例

図6. アーキテクチャーエピックの成功基準例

M4: ポートフォリオ管理の自己評価

プログラムポートフォリオ管理チームは、自分の進捗を継続的に評価し、改善する。多くの場合、これは構造化された定期的な自己評価として行われる。プログラムポートフォリオ管理チームがスプレッドシートに必要事項を入力すると、自動的に図7のようなレーダーチャートが作成される。これにより、相対的な強みと弱みが明らかになる。

Figure 7. Portfolio Self-Assessment Radar Chart

図7. ポートフォリオの自己評価レーダーチャート

M5: エンタープライズバランススコアカード

企業の規模が大きく、総合的な測定基準を重視している場合には、事業部門ごとに一連の「バランススコアカード」の測定値を収集し、それを経営ダッシュボードにマッピングすることができる。例を図8および図9に示す。

図8. 測定基準を4つの関心分野に分ける「バランススコアボード」の方法

図8. 測定基準を4つの関心分野に分ける「バランススコアボード」の方法

図9. 上記のメトリックスをアルファベット採点に変換して集計すると、企業のビッグピクチャーを可視化できる

図9. 上記のメトリックスをアルファベット採点に変換して集計すると、企業のビッグピクチャーを可視化できる

このアプローチの詳細について、書籍Scaling Software Agility(邦訳:「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス」)の第22章を参照する。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise. Addison-Wesley, 2011. (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.(邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

Last update: 24 July, 2014

Leffingwell et al. © 2011-2014 Scaled Agile, Inc.

Information on this page is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.