概要
デュアル・トラック・アジャイルを実践する認証グループが、チームパフォーマンスを評価するための新しい指標体系を導入した経緯とその内容について詳述します。
従来のFour Keysがデリバリーに偏っている問題を解決するため、ディスカバリーとデリバリーの両方を評価できる指標運用を開発しました。
具体的には、まず、スプリントバックログに、デリバリーのワークに限らず、ディスカバリーのワークを表すチケットも積む様にします。これでチームの全活動のトラッキングを可能とします。スプリントゴールには、デリバリーとディスカバリーの二つのゴールを設定します。
その上で、「ディスカバリーとデリバリーの合計の消化ストーリーポイント推移」、「ディスカバリーとデリバリーのワーク量比率」、「案件毎のディスカバリー開始からデリバリー完了までの総リードタイム」、これらを注視し、フルサイクル開発プロセスの全体最適を目指します。
【目次】
- はじめに
- 認証グループにおけるデュアル・トラック体制のおさらい
- デュアル・トラック体制の下では、Four Keysだけではチームパフォーマンスを可視化できない
- チームの全活動をトラッキングすることを狙ったチケット種別編成
- デュアル・トラックに拡張されたスプリント
- 全活動トラッキングから導出できるチームパフォーマンス指標
- ◆追補◆ 現状のチームパフォーマンス指標運用状況を、広木大地氏の言う「開発生産性の3階層」に照らして考察してみる
- 謝辞
はじめに
kubellで認証グループのエンジニアをやっている田中浩一（@Tanaka9230）と申します。認証グループは、「Chatwork」の認証系＋一部セキュリティ系、およびアカウント管理系を担当領域としたフィーチャー・チームです。認証系の中核には「Auth0」というIDaaSを導入していて、その運用も担っています。
◇
認証グループは、現在、デュアル・トラック・アジャイルを実践していると言って良い様な成熟度でチーム運営されています。現在の体制に至るまでの経緯を紹介した下記記事もご参照ください。
本記事はその続編となります。デュアル・トラック体制を実現している現在、どういったチームパフォーマンス指標をどのように運用しているか、そこに至る過程で考えたことを交えながら、詳しく述べたいと思います。
認証グループにおけるデュアル・トラック体制のおさらい
認証グループは、「デリバリーすること」を中核的役割とする開発チームではありますが、プロダクトマネージャー（以降、PM）と協業して、ディスカバリーのワークも担っています。ディスカバリーとデリバリーの両輪を一体的に回す様なスタイルは「デュアル・トラック・アジャイル」と称して良いでしょう。
下図は、認証グループの現在の開発プロセスを表しています。
このような開発プロセスを形作るに至るまでに、次の二つの工夫をしました。
まずは、リファインメント〜スプリントレビューまでの既存のスプリントの流れの"上流"に、プロダクトオーナー（以降、PO）チーム（後述）のワークとして行なっていた「POチームMTG」と「PM部内レビュー会」を置いて、フェーズ進行的に接続してみました。「POチームMTG」とは、PM以下全員参加の、いわば認証グループの最高意思決定機関です。「PM部内レビュー会」とは、案件の”やるやら”および優先度を、PMがVPoPと合意形成する会議体で、プロダクト組織としての最重要意思決定機関となっています。
次に、この”やるやら”が決定される「PM部内レビュー会」を境として、えいっとディスカバリー・トラックとデリバリー・トラックとに分けて捉えることとしました。つまり、
- ディスカバリーとは、ある案件について、「プロダクト要求仕様書（PRD）」を作って「PM部内レビュー会」へ持ち込むためにあれこれワークすること、
- デリバリーとは、「PM部内レビュー会」で"Go"となった案件について、リリースまでもっていくためにあれこれワークすること、
・・・こういう捉え方をすることとしました。
「POチーム」とは、スクラムのPOの役割を、一人では無くて複数人で担おう、というスクラムのプラクティスです。認証グループでは、メンバー全員がPOチームと開発チームの両方を担っていこう、という取り組みをしています。この取り組みが、デュアル・トラック体制実現の土台となっています。
開発チームの立場からは、PO（チーム）としてのワークの中では「リファインメント」が重要な一つに見えてるかもしれません。認証グループの開発プロセスを前提にすると、「リファインメント」は、"やるやら"決定後のワークなので、デリバリーのワークに位置付けられます。つまり、「PO（チーム）のワーク、イコール、ディスカバリーのワーク」、という訳ではありません。PO（チーム）としてのワークは、ディスカバリーからデリバリーに跨っているのです。この点のこの認識は、ちょっとしたことですが、案外大事かもしれません。
デュアル・トラック体制の下では、Four Keysだけではチームパフォーマンスを可視化できない
認証グループも発足当初は、デュアル・トラック体制を意識していない、"ふつう"の開発チームでした。（こちらの記事で言う「第I期」の頃のことです。）その当時、開発パフォーマンス指標として、Four Keysを導入していました。
- Change lead time (変更のリードタイム)
- Deployment frequency (デプロイの頻度)
- Change fail percentage (変更障害率)
- Failed deployment recovery time (サービス復元時間)
前半二つはThroughput、後二つはStabilityについての指標とされています。Throughputは、まさにチームのパフォーマンス指標と言えるでしょう。Stabilityの方もチームの練度を示しているとは言えますが、「プロダクトの品質」を表しているという側面もあります。Stabilityの方は、QA (Quality Assurance)の文脈で回収しています。また別の機会にQA面の取り組みをご紹介できるかもしれません。ここではThroughputに注目します。
最も活用していた指標は「デプロイの頻度」で、いわゆるd/d/dを見てきました。良くも悪くも、認証グループのd/d/dは、短期変動はあるものの、トレンドとしてはずっと安定していました。別に上がるわけでもないですが、下がるわけでもない。
その後認証グループは、ディスカバリーのワークも担う様に体制移行しました。（こちらの記事で言う「第II期」の頃です。）すると、このd/d/dがじわじわと下がってきました。デリバリーでは無い、ディスカバリーに関わるワークを積極的に担う様に移行していったのですから、d/d/dが下がることは想定内ではありました。
しかしここで、d/d/dが下がったのは、「それに見合う分量のディスカバリーのワークが行われていたので問題ない」のか、「実はデリバリーのワーク自体に何か問題が起きている」のか、判別が付かない、という問題が生じました。ディスカバリーに関するワークも可視化する必要がある、という事に気付きました。
つまるところ、
- Four Keysという指標体系はデリバリーについてのものであり、
- デュアル・トラック体制の下、ディスカバリーもチームの活動に含めるのであれば、チームパフォーマンス指標のあり方として、何か別のアプローチが必要なのだ、
・・・という理解に至りました。
チームの全活動をトラッキングすることを狙ったチケット種別編成
そこで、デリバリーか否かに関わらず、なんであれチーム活動の全てをトラッキングできる状態をつくろう、と考えました。そのため、まずは、認証グループの行っている開発プロセスを再定義しました。
メンバーみんなで今までの活動を振り返って、実態的な活動内容を分析的に洗い出して、活動の依存関係を整理、最終的に図2の様なプロセスモデルに到達しました。図1の様なフェーズ的推移を表したものではなく、実態的な活動内容をどのように認識、分類できるか、という点に注目して表現したプロセスモデルです。「チームの実態的な活動内容の全て」というのであれば、「ディスカバリー」、「デリバリー」のみならず、「運用」に関わるワークもやっているので、それも含めます。また、「PM部内レビュー会」がディスカバリーとデリバリーを分けるフェーズゲートに、「リリース」がデリバリーと運用を分けるフェーズゲートとなることを、その理解のために示しました。
どうして「PM部内レビュー会」、「リリース」がフェーズゲートになるかというと、《認証グループにおけるデュアル・トラック体制のおさらい》セクションに示した通り、ディスカバリーの目的は「PM部内レビュー会」、デリバリーの目的は「リリース」だと定めているからです。
そして、プロセスを構成する活動一つ一つと対応する様に、チケット種別（Jira作業タイプ）を定義しました。デリバリーフェーズの活動だけでなく、ディスカバリーフェーズの活動を表すチケット種別、運用フェーズの活動を表すチケット種別も定義しました。
認証グループの行なっているフルサイクル開発プロセスが図2の通りであるならば、上の表のチケットで、チーム活動の全てを、漏れなくトラッキングできるはずです。
また、これらの全てのチケット種別に、ストーリーポイントを付与するようにしました。ストーリーチケットのストーリーポイントは、従来通りプランニングポーカーで見積もりします。ストーリーチケット以外のワークは、タイムボックスで見るしか無いだろう、ということで、ストーリーポイントは、1時間から2時間のタイムボックスに対して1ポイント、という換算で割り振ることとしました。
この換算は、過去実績的にスプリント当たり概ね15ストーリーポイントの消化というベロシティだったので、1スプリントの時間枠を30時間だとして、概ね2時間で1ストーリーポイント、という割合で換算しようという計算となってます。
デュアル・トラックに拡張されたスプリント
もはやJiraのスプリントバックログは、デリバリーに関わるバックログアイテムを含むが、それに限られない、包括的なチーム活動バックログを表すもの、となりました。
それって単なる「カンバンボード」なのではないか？という疑問があるかもしれません。いいえ、デリバリー以外のバックログアイテムを含んでいても、スプリント（1週間）のタイムボックスと、スプリントゴールの運用は維持しています。ただし、スプリントゴールは、デリバリー・トラックのゴールとディスカバリー・トラックのゴールを、それぞれ設定できるものとして拡張しました。
上図は、あるスプリントのスプリントレビュー資料からの抜粋です。デリバリー・トラックのスプリントゴールとディスカバリー・トラックのスプリントゴールが設定されていて、デリバリー・トラックのゴールは残念ながら未達、ディスカバリー・トラックのゴールは達成していることを表しています。
この様に、一つのスプリントに於いて、デリバリー・トラックのゴールとディスカバリー・トラックのゴールの二つを追う、という運用を行うに至りました。まさに「デュアル・トラック」を具現化した運用と言えるでしょう。
複数のゴールを追うというのは、スクラムのプラクティス的にアンチパターンではないのか？と問われれば、それはその通りです。しかし、「デュアル・トラック」に挑戦するという事は、性質の異なる2種類の活動群を同時になんとかやっていく、という、そもそもそういう試みですし、チームがそれができるだけの成熟度に達しているという前提の話です。
実践的には、スプリントプランニング時に、ディスカバリー・トラックとデリバリー・トラックのチケット、それぞれをどれだけスプリントに積み込むかを、キャパシティ見合いで調整したり、スプリントによっては、ディスカバリー・トラックのゴールのみとしたり、デリバリー・トラックのゴールのみとしたり、そういうアレンジは行なっています。
全活動トラッキングから導出できるチームパフォーマンス指標
以上で、チームの全活動トラッキングを行う基盤を確立することができました。そこからどんなパフォーマンス指標を見る事ができるでしょうか。
(1) スプリント毎、消化ストーリーポイント合計（の推移）
そもそものきっかけは、デリバリーについての指標であるFour Keys（具体的にはd/d/d）だけでは、ディスカバリーも担うデュアル・トラック体制下のチームパフォーマンスを測ることができない、という問題が生じたことでした。そもそもの狙いはディスカバリーも含めた総ての活動の、スプリント当たりの量を可視化することでした。
その狙いは、「スプリント毎の消化チケットのストーリーポイント合計（の推移）」を見ればわかるようになった事で達成されています。シンプルに、スプリント当たりの消化ストーリーポイント数が多ければ、そのスプリントの総パフォーマンスは良かった、少なければ悪かった、と判断します。
この指標は、Four Keysの「Deployment frequency (デプロイの頻度)」の代替となります。
(2) 案件について、ディスカバリー開始からデリバリー完了までの総リードタイム
通常のデリバリー特化の開発チームであれば、Four Keysの「Change lead time (変更のリードタイム)」が、"所要時間"指標として妥当でしょう。「Change lead time (変更のリードタイム)」は、コードの修正着手からデプロイ完了までの所要時間、と定義されています。
しかし、デュアル・トラック体制下では、デリバリー・トラックだけの"所要時間"を見ていても片手落ちです。そうではなくて、「ディスカバリーからデリバリーまでの総リードタイム」に対してこそ責任を置くべきです。
「サイクルタイム」と「リードタイム」という用語を使い分けるのであれば、「Change lead time (変更のリードタイム)」は、その定義より、「開発（デリバリー）のサイクルタイム」と言う方が妥当でしょう。デュアル・トラック体制下では、開発（デリバリー）のサイクルタイムよりも、ディスカバリーからデリバリーまでのトータルのリードタイムの方を注視すべきです。
いくら開発（デリバリー）のサイクルタイムが短縮されても、その一方でディスカバリーの"所要時間"が間延びしていたのでは、案件単位で見たとき、起案されてからリリースされるまでの総リードタイムが短縮されたことにはなりません。
認証グループのJira運用では、案件は「エピック」で表しています。エピックには、当該案件についてのディスカバリーのチケットも、デリバリーのチケットも含まれます。「エピック内の最初のディスカバリーチケット起票日〜最後のデリバリーチケット完了日」が、エピック＝案件の総リードタイムとなります。
(3) スプリントにおける、ディスカバリー、デリバリーのストーリーポイント比率
デュアル・トラック体制下で注視すべき指標が、ディスカバリーからデリバリーまでの総リードタイムであるならば、それを向上させるためには、ディスカバリーのワークとデリバリーのワークのバランスが大事となります。
デリバリーのバックログアイテムの供給は、チーム自らのディスカバリーの成果に依ることとなります。ここでディスカバリー過多ですと、デリバリーで消化するべきバックログアイテムの"在庫"が過剰となります。デュアル・トラック体制であっても、最終的にデリバリーすることが目的であることには変わり無いのですから、バックログアイテムばかり蓄積しても意味は無く、開発スループットに寄与しません。逆にデリバリー過多ですと、いずれデリバリーバックログアイテムの"在庫"が尽きます。デリバリーバックログアイテムが尽きてしまっては、結局開発スループットを向上させることができません。
つまり、デリバリーバックログアイテムの"在庫"量が"適正"となる様に、ディスカバリーのワークとデリバリーのワークのバランスをコントロールする必要があります。
そのために、スプリント毎の、ディスカバリーワークの量とデリバリーワークの量の比率を注視していくことが肝要となります。
◇
以上が、認証グループがデュアル・トラック体制下で運用しているチームパフォーマンス指標となります。
スプリント毎の消化ストーリーポイント合計や、ディスカバリーワークとデリバリーワークの比率を可視化するためのJira運用の工夫について、下記記事で紹介されていますので、合わせてご参照ください。 creators-note.chatwork.com
◆追補◆ 現状のチームパフォーマンス指標運用状況を、広木大地氏の言う「開発生産性の3階層」に照らして考察してみる
広木大地氏による下記記事によると、
「開発生産性」を考える上での観点には三つのレイヤーがあるとされています。次の図は広木氏の記事より引用したものです。
(広木大地 (2022) 「開発生産性について議論する前に知っておきたいこと」)
広木氏は、「レベル1：仕事量の生産性」を次の様に説明しています。
“作業量としてどの程度の仕事をこなすことができたのかを評価する生産性です。仕事量の生産性が十分高くても、レベル2以降の生産性が高いとは言えませんが、少なくとも作業の効率が悪いというわけではないことを評価するために使います。これは、一開発者やエンジニアリングチームでも改善がしやすいため、まずはこういった生産性に注目することが多いです。”
デリバリーを役割とする開発チームが、Four Keysをパフォーマンス指標として運用している様な状態とは、まさにこの3レイヤーモデルにおける「レベル1生産性」に注目している状態だと言えそうです。
「レベル2：期待付加価値の生産性」は次の様に説明されています。
“仕事量だけではなく個々の施策がどの程度プロダクトにとって価値があることなのかを踏まえて評価したい場合に使います。”・・・（略）・・・“プロダクトチーム全体で価値があると「期待している」施策がどの程度リリースできたのかに注目することで、プロダクト開発に関する効率の良さやコストパフォーマンスの良さを評価する為に使います。”“この点は、施策を考え決めていくプロダクト開発組織全体のアウトプットを評価することに用いることができます。”
認証グループが実現しているデュアル・トラック体制の現状に照らし合わせてみると、以下の様に評価できそうです。
- デュアル・トラック体制とは、デリバリーに閉じず、PMと協業してディスカバリーまでを役割として捉えている状況を言う。そこで「開発チーム」に閉じず「プロダクト開発組織」全体を視野に置き、施策（＝案件）についての総リードタイムに注目している、といった点で、「レベル2生産性」に手を掛けるための足場は作られている。
- しかし、現状運用されているストーリーポイントなどのメトリクスは「レベル1生産性」についての評価値であり、「期待付加価値」スコアといったメトリクスの運用は行われていない。
認証グループが次に進むべき方向性も見えた様です。
謝辞
認証グループは、チームとして一つの到達点に達することができたと思っています。現在の成熟度へ到達できたのは、ひとえにメンバー全員の取り組みの成果の賜物です。特に、tasuku43さんは、フルサイクル開発プロセスの初期案を出すことに貢献いただきました。そこから一気に「デュアル・トラック」へ向けて会話が進みました。erin_the_blackさんは、Jiraの使いこなしに具体的な改善を適用していただきました。いくらコンセプトが良くても、日々のプロセスが重いと実践できません。今の運用が実現できているのはToolingの支援あってこそです。louvre2489さんは、チーム発足当時の"Tech-サブPO"として、認証グループの最初の形を整えていただきました。受け入れテストの定着は、その後に「POチーム」を成立させるときのアンカーになりました。もちろんメンバー全員が、「POチーム」といったその当時としては少々無謀だったかもしれないTryにチャレンジし、それぞれモノにしていただいた事が最大の功績です。
