Value Stream ManagementとDevOpsの実現～後編～
前回（第一回）では、Value Streamという考え方に関して説明を行い、そこで使用される品質の数値化に関してご紹介しました。今回は工数の可視化に使用される数値と、工数見積もりに使用される手法をお話します。
～ システム開発における数値化 ～
前回も使用した以下の図において、システム開発における数値化の代表的なものを示してあります。今回は【工数の可視化】に関してお話していきます。
～工数目線での数値化～
プロジェクトマネージャは、プロジェクト開始時に要件を分析してシステム開発の工数を概算します。システム開発を計画期間内に終了させるために、作業要員のスキルや必要な作業工数を見極める必要があるためです。
現実問題として、例えば私がSEとして働いていたころは開発プロジェクトの予算、納期が既に決められた状態で開発チームに話が来ることが多く、納期に間に合わせる形で逆算してスケジュールを設定していました。
逆算で作成したスケジュールは予定通りにいかず、恥ずかしながらプロジェクト後半は残業の山ということが非常に多い状態でした。
私の苦い経験談はさておき、要件から開発要員の工数を見積もるためには経験を元にしたおおよその数値化とスケジューリングが行われますが、根拠の少ない数値化では最終的に工数がオーバーしてしまうことが少なくありません。その見積りの失敗を防ぐため、要件の複雑度を数値化して工数にあてはめるFunction Point法（FP法）を使用することが可能です。 これは機能要件のデータとトランザクションを分析して数値化するものであり、すなわちデータファイルや項目の数や外部入出力のトランザクション数などから機能の作成にかかる数字を計算させることで、開発に必要な工数をなるべく現実に近い形で事前に算出しようとするものです。
要件の優先度付け
要件を数値化出来たとしても、開発プロジェクトにはスケジュール管理が必要ですので、同じくらいの数値の要件が複数ある場合などには優先度をつけて作業する必要があり、いわゆる要件の順位付けとスコーピングが重要になってきます。 たとえば、優先度を決めるには以下のような方法も存在します。
◆$100テスト
以下の5つの要件があったとします
- 都心に緑を増やす
- 少子化対策
- 犯罪を減らし安全な街を作る
- 減税
- 地震（防災）対策
関係者が各自で＄１００ドルずつ持っており、その全てを使いきる形で５つの要件に異なる金額を割り振ります。
全員の割り振った金額を要件ごとに集計し、合計金額が多い順から優先度が高いものとします。
実際のプロジェクトでこのような方法で見積もるのは難しいかもしれませんが、練習としてチーム内で行うことで見積りの経験を積みながらプロジェクトの理解も進み、認識を共有できるというメリットはあるはずです。
バックログの優先度づけ
FP法はウォーターフォール型の開発で良く使用されていましたが、Agile開発においてはまた別のアプローチが存在します。チームでバックログの比重を数値化するために使用する「ストーリーポイント」と呼ばれる数値があり、以下のように使用されます。
- バックログ毎のストーリーポイントを設定
- スプリントのベロシティを確認、調整
- 振り返りによる再調整
- ダッシュボードによるプロジェクト状況確認
Agile開発においては、プロダクトバックログの複雑度や必要な工数を見極めるのは責任者だけの役割ではなく、プロダクトチームの全員が参加してストーリーポイントを決めていきます。 ストーリーポイントの値を決めるための「プランニングポーカー」というものが存在しますのでご紹介します。
Planning Pokerには１、２、３、５、８、１３、２０、４０、１００ の数字`などが書かれたものが、赤、黄色など複数の色のセットで用意されています。ストーリーポイントを見積もる人（グループ）毎に色を決めて配って使用します。
◆Planning Pokerの手順
- プロダクトバックログを選択
- 基準となるバックログを選択
- Planning Pokerを配る
- Planning Pokerを使用してポイントを決める
- チームで話し合ってストーリーポイントを修正する
例えば、以下のバックログ（機能要件）があったとします
タイトル：目玉焼きを作る
- 卵を用意する
- フライパンに油をひく
- 卵を割ってフライパンで焼く
- 目玉焼きを器に盛る
上記の目玉焼きバックログのストーリーポイントを１とした場合に、以下のバックログのストーリーポイントはどれくらいになるか各自（各チーム）でポイントを考えてみましょう。
タイトル：カルボナーラを作る
- パスタ、ベーコン、卵、チーズ、塩、オリーブオイルを用意する
- パスタを茹でる
- チーズをすり下ろす
- フライパンでベーコンをオリーブオイルで炒め、ベーコンは取り除く
- フライパンにパスタを入れ卵黄とチーズを混ぜる
- パスタとベーコンを器に盛る
各自が数値を選んだら、全員の数字を見せ合ってそれぞれの数値の根拠を聞きながら調整を行い、全員の合意を得ることが出来る数字が出たら決定とします。
実際にカルボナーラを作ったことがある人がいたら、“卵を入れたらソースが固まってしまった”などの失敗談から注意点を指摘し、問題を回避するための手順を提示できるかもしれません。
イテレーション単位のバックログのストーリーポイントでベロシティを調整するには、チームバックログ画面においてスプリントのチームとそのキャパシティを確認し、担当者アサインの可否判断やスプリントの見直しを行います。
Value Stream Managementではプロジェクトの価値を考えるため、価値とはどういうものを指すのかを以下のように定義しています。
～Value Stream ManagementのValue～
| ＜価値（Value）の種類＞ | |
|---|---|
| Customer value | どのように顧客のニーズにインパクトを与えるかを表す数値です |
| Commercial value | どれくらいの収益を生むのかを表す数値です |
| Market value | 顧客を維持するために、どのように差別化を図るのか。あるいはどのように製品のギャップに対処するのかを表す数値です |
| Efficiency value | どれだけの時間、労力、お金を節約できるかを表す数値です |
| Future Value | 将来、どのように時間、労力、お金を節約し、無駄を省くのかを表す数値です |
| ＜価値（Value）の数値化＞ | |
|---|---|
| Perceived Value(PV) （認識された値） | 特定の機能によって提供されると思われる価値を表す数値です。（複数の価値タイプ（顧客、商業など）からのインプットに基づいた重み付けされたスコア） |
| Perceived Actual Value(PAV) | 特定の機能が生産現場や顧客向けシステムで稼働しているときに、その機能によって提供されたと考えられる価値を表す数値です。（複数の価値タイプ（顧客、商業など）からのインプットに基づいた重み付けされたスコア） |
| Actual Value(AV) （実際の値） | 機能に具体的な測定可能な成果があり、実際に提供された価値と認識された価値を表す数値です |
| Value Gap | PVとPAVの差分(PAV-PV) |
これらの数値はOpenText™ Core Software Delivery PlatformというAgileプロジェクト管理のトータルソリューションサーバに登録することが出来るもので、Value Streamにおける品質の管理が可能となります。この詳細はまた後日のこのブログでご紹介させていただきます。
今回のまとめ
プロジェクトの管理には数値による見える化が重要であり、そのために使用する品質と工数の面での様々な数値化の方法に関して代表的なものを紹介しました。
次回は、Value Stream Managementで使用するもう一つの重要な数値であるリードタイムに関してお話します。
