Adadotの指数が下がったとき、振り返りで見直すべきマージリクエストは？

スプリントの序盤は順調だったのに、終盤になるとレビュー待ちのコードがたまっている。開発責任者が知るべきなのは、チームの「速度」が落ちたということだけでなく、仕事がどのように詰まったかです。Adadotは開発活動と協働のデータをまとめて分析するため、こうした振り返りの手掛かりを得るのに向いています。ただし、何を変えるかを決めるには、具体的なタスクとチームの話し合いに戻る必要があります。

この記事は公式の製品説明とベンダーが公開した過去の利用事例を基に、この場面を分析したものです。チームのアカウントへの接続や、モデルの予測性能の検証は行っていません。

Adadotの公式サイトは、レビュー待ち時間とレビューコメント数の関係や、「What if」のシナリオ分析を製品の用途として挙げています。これを使えば、責任者はより具体的な問いを立てられます。マージリクエストがもっと早くレビューされていれば、現在の停滞は緩和できたのか、という問いです。これは検証すべき仮説であり、モデルがすでにチームに代わって原因を証明したという意味ではありません。

次の振り返りを小さな実験として設計してみましょう。同じチーム、同種のプロジェクト、同じ長さの観察期間を定め、何が変わったかを記録したうえで、その期間にスプリント末尾まで持ち越されたマージリクエストを選びます。元の開発ツールで、提出とレビューの時刻、変更範囲、議論の記録、関連要件が急に変わっていなかったかを確認します。AdadotのFAQも、日常のツールの上に置く分析レイヤーとして製品を位置付け、タスク単位の情報は引き続きJiraやGitlabで確認すべきだと説明しています。

こうすることで、対応の方向を分けられます。要件の範囲が繰り返し変わっているなら、レビューを催促するだけでは解決しません。変更が大きすぎて誰もすぐに理解できないなら、分割方法を話し合えます。レビュアーが最後になって初めて参加したのなら、協働を早めに段取りする必要があります。これは振り返りのための分類であり、Adadotが各リクエストに自動でこうしたラベルを付けるという主張ではありません。

Adadotが2022年8月に公開した自社チームの事例では、マージリクエストごとの変更規模に応じて仕事を小さく分けたとされています。また、スプリント後半にマージが遅くなる理由を話し合う中で、チームが簡単なタスクを先に進め、詰まりやすい難題を後回しにしていたことに気付きました。その後は難しい仕事を早い段階で扱うようにしています。

この資料はベンダーによる自社チームの振り返りです。別のチームでも同じ処理量の向上が得られるとは約束できません。それでも、振り返りの有用な出発点は示しています。グラフが変化を示し、チームが背景を説明し、そのうえでタスクの分け方や処理順序を変える、という流れです。途中の話し合いを飛ばし、一度のスコア変動をそのまま従業員の業績に関する結論にしてはいけません。

最初は一つだけ調整を選びます。例えば、外部への依存があるタスクを早めに議論に上げる方法です。次の比較可能な期間には、待ち時間が減ったかに加え、手戻りが増えていないか、難しい仕事を単に観察期間の外へ押し出しただけではないかも確認します。完了件数が増えても、デリバリー上の問題が減っていないなら、まだ改善に成功したとは言えません。

FAQによると、指数はデータを1–10の範囲に正規化し、重み付けを行います。そのため、指数は注目すべき場所を知らせるものとしては有用でも、作業時間、事業価値、個人の貢献と直接同一視はできません。背景の異なるタスクを、一つのスコアだけで順位付けするべきでもありません。

製品ページは、個人の指標をチーム単位で集計・匿名化し、チーム指標には少なくとも3人のメンバーが必要だとしています。また、コードを処理も保存もしないと表明しています。本格的に接続する前に、責任者は実際のアカウントで見える項目、データソース、アクセス権をチームと確認し、組織が認める利用範囲も確かめる必要があります。製品側の説明はこの確認の代わりにはならず、振り返りで個人の生の記録を自由に見せてよいという意味でもありません。

問題が「今日、このリクエストを誰が引き継ぐか」だけなら、既存のタスク管理ツールで直接調整するほうが適切です。複数のタスクにまたがる詰まりが繰り返し発生し、チームがデータを使って一緒にプロセスを変える意思を持っているときにこそ、Adadotの分析レイヤーを試す価値が高まります。試用の成果は、明確に説明でき、後から検証できるプロセスの変化であるべきです。個人ランキングを見栄えよくすることではありません。