アジャイルと生産性・４ - アジャイル導入効果を測定する成果指標の実運用・前編

4年以上前

執行役員

浅木麗子

前回エントリーでは、OKRを応用して開発チームの成果指標を設計するモデルケースを紹介しました。
実際に設計した指標は、下図のようなものです（詳細は前回エントリー「アジャイルと生産性（３） - アジャイル導入効果を測定する成果指標のモデルケース」を参照）。

成果指標の設計例

今回と次回は、同じモデルケースを使って、実務上の注意点を解説して行きます。
前編となる今回は、PDCAサイクルの「P」と「D」についてです。以下、目標設定（工数配分）の考え方、具体的な目標値の決め方、測定と評価の進め方の順で説明します。

目標設定（工数配分）の考え方

モデルケースでは「PBIを『新機能』と『それ以外』に分ける」と説明してきました。が、私が多くのチームに提案する分類は、実は三つあります。

グループA：新機能や仮説検証など「価値につながる」PBIの開発
グループB：調査、保守、競合に追随するための改善など「守り」のPBIの開発
グループC：障害対応など「後ろ向き」なPBIの開発

この三分類です。

「価値につながる作業」以外を、さらに二つに分ける理由は、グループBとグループCとでは管理のアプローチが異なるからです。

グループC（障害対応など「後ろ向き」な作業）は、総量を減らす方向へコントロールすべきものです。一方、グループB（調査、保守など「守り」の作業）は、「少ないほど良い」といった性質のものではなく、常に一定量が存在することを前提に計画する必要があります。

また、グループC（「後ろ向き」な作業）は、すべてのスプリントで必ず発生するものではないので、ここに割り当てる工数は、スプリントのリスクバッファと考えることができます。その意味でも、グループB（「守り」の作業）とは、分けておいた方が管理がしやすいのです。

つまり、工数配分（指標の目標値）の設定は、以下の順で考えて行くことになります。

グループC作業が発生した場合に備えて確保しておく工数を決める（この分はリスクバッファとする）
残った工数のうち、グループAに使う比率を決める（ここが本当にやりたいこと＝チームの意思）
最後に残った工数をグループBに割り当てる（やりたいこととのバランスを考え「やらなければならないこと」も実施）

工数配分（目標設定）の考え方

ファクトベースで目標値を決める

続いて、具体的な目標値の決め方です。
「グループA（価値につながる作業）に割り振る工数は、全体の何パーセントが適正か」という質問をよく受けるのですが、残念ながら、この問いに正解はありません。チームの意思で決めるしかないのです。
とはいえ、それを決めるヒントはあります。

これまでチームが実施してきた工数配分の実績
プロダクトやサービスの望ましい成長スピード（成長を加速したいなら、グループAへの配分を増やす必要がある、ということ）

の二つです。
たとえば、モデルケースでは「６５％」という目標値を設定していますが、これは、直近３ヶ月の工数配分実績を分析し、決定した値です。

もう少し詳しく説明して行きましょう。
このチームは２週間スプリントを運用しており、分析対象としたのは６スプリント分の実作業時間です。
数値の詳細は割愛しますが、下図が集計結果をグラフ化したものです。

過去実績集計の例

チームは、集計結果をもとに以下のような議論を行いました。

直近３ヶ月（６スプリント）のグループAへの作業配分の平均値は５２％だった
期間中の最小値は１３％（スプリント２０）、最大値は７５％（スプリント１７）と幅が大きい（安定していない）
スプリント２０では大きな障害対応が発生したため、グループAへの作業配分が極端に低くなっている
（作業時間自体も突出して多く、緊急対応に追われた様子が見て取れる）
そこで、スプリント２０は「外れ値」と考え、集計対象から除外する
スプリント２０を除く５スプリントの平均値を取り直すと、グループAへの作業配分は６３％だった
従って、緊急対応を要する大規模障害の発生を抑えることができれば、グループAへの作業配分を６５％とすることは実現可能な目標と考えられる

こうした議論を経て、チームはグループAへの作業配分を６５％とする目標を設定しました。

また、チームは、議論の過程で「重大障害の発生頻度」という、重要なKRを見落としていたことに気付き、指標設計を手直しすることになります。
（その結果、業務委託先に任せていたテストチームの内製化を含め、テストプロセスの抜本的な見直しが進行中なのですが、この話については、稿を改めたいと思います）

過去実績集計の単位と範囲

モデルケースでは、過去実績の集計に「作業時間」（実時間）を用いています。
あなたのチームが、実時間以外の単位（ストーリーポイント等）でベロシティをトラッキングしているのであれば、もちろん、そちらを使っても構いません。
ただし、その場合は、分析対象期間を通じて、ベロシティ計測の単位が安定して運用されていることが前提となります。たとえば、「ストーリーポイント見積もりを始めたばかりで、見積もり精度が十分でなかったスプリント」のデータが集計に含まれていると、正確な分析ができなくなる惧れがありますので、注意が必要です。

また「過去実績は、どこまで遡って集計すべきか」という質問も多いのですが、私は３ヶ月から１２ヶ月の範囲で集計対象期間を設定しています。チームの成熟度やプロダクトの品質レベルなどを勘案して、適切な期間を判断するのですが、「よくわからない」という場合は、ひとまず直近３ヶ月分を集計してみることをお勧めします。この範囲でスプリント間のばらつきが極端に大きいようなら、もう少し集計範囲を広げてみるとよいでしょう。

なお、過去の実績データがまったくない（チケット単位の作業時間を記録していないし、それ以外の相対見積もりも実施していない）というケースでは、残念ながら、具体的な目標値設定は困難です。まずは作業実績を記録する運用を始め、最初の四半期を使って現状を定量的に把握することをお勧めします。

計測は毎スプリント、評価は四半期単位

目標値を設定したら、実際の運用を始めます。
実運用にあたっては、すべてのスプリントで一律に工数配分を守る必要はない（むしろ守るべきではない）という点に注意してください。
あまり厳格に工数配分ルールを適用しようとすると、かえって開発の柔軟性を損ない、弊害の方が大きくなります。

タイムボックス型開発の本質は、内外の変化に迅速に対応して時点最適の判断を繰り返す点にあります。このメリットは維持しながら、一方で、過度の「スプリント最適化」によって場当たり的な意思決定に陥ることを防ぎ、プロダクトの中期目標に向かってチームをナビゲートしてくれるのが「価値につながる作業の比率」という成果指標です。

短期目標と中期目標のバランスを取るためには、四半期（３ヶ月）単位で達成状況を評価して行くのが妥当でしょう。
モデルケースに当てはめるならば、６スプリント分の平均値を評価対象とする運用になります。

四半期単位で評価する

ただし、指標の計測と計測結果の記録は、すべてのスプリントで欠かさず実施してください。
細かすぎる評価には意味がありませんが、計測と記録はできるだけ小まめに行うのがコツです。

お勧めの運用は、指標値の確認をスプリントレトロスペクティブのアジェンダに入れることです。

こうすると、スプリントが終了するたびに、自然と四半期目標を再確認することになり、ゴールに向けた軌道修正が容易になります。また、小まめな計測によって自分たちの作業を定量化する習慣が身に付くというメリットも期待できます。

計測はスプリントごとに

今回は、モデルケースに沿って、目標設定（工数配分）の考え方、具体的な目標値の決め方、測定と評価の進め方を紹介しました。
次回エントリーでは、四半期評価を受けてPDCAサイクルを回し、開発チームの定量評価をビジネス成果につなげる流れを解説して行きます。