スクラムマスターのAI活用を考える - 透明性

アジャイルグループの石田です。

スクラムマスターのAI活用を考える - 導入の続編です。前回は、スクラムガイド拡張パックを参考に、AIがスクラムを強化する可能性の一つとして「経験的プロセス制御」の強化について触れました。

スクラムマスターとして、スクラムというプロセスにAIを活用することで、チームが実践するスクラムの三本柱「透明性・検査・適応」をより強化することができます。

本記事では、三本柱の第一歩である「透明性」に着目します。ここでいう透明性とは、単に見えるようにすることではなく、チームが正しい判断（検査・適応）を行うための材料を揃えることに他なりません。

今回はAIにデータの分析そのものを依頼するのではなく、「可視化のためのツール作成（コーディング）をAIに任せる」というアプローチを紹介します。
具体的には、JiraのデータをGoogle Apps Script (GAS)で取得・加工し、可視化するプロセスをAIと共に実装した事例をご紹介します。

スクラムマスターがチームの状態を正しく観測するために、またチームメンバー自身が自分たちを客観視するために、定量的なデータは不可欠です。

Jiraなどのプロジェクト管理ツールには標準的なレポート機能が備わっていますが、現場では「もう少しこの切り口で見たい」「外部スプレッドシートの情報と突き合わせたい」といった、標準機能ではカバーしきれないニーズが頻繁に発生します。
Jiraには強力なAPIが用意されており、データを自由に扱うことが可能ですが、開発専任ではないスクラムマスターにとって、ゼロからツールを開発するのは学習コストや時間の面でハードルが高いのが現実です。

そこで活用したいのが、生成AIにコードを書かせ、「スクラムマスター専属のエンジニア」として振る舞わせる方法です。これにより、技術的な壁を取り払い、スクラムマスターとしての機動力を劇的に高めることができます。

実際のプロダクトコードにAI生成コードをそのまま使うことには保守性の観点から慎重な議論が必要ですが、チーム内部で使う一時的なツールやダッシュボードを作るという観点では、積極的に活用してこそ価値が発揮される領域だと考えます。

ここから先は、実際に業務で行った生成AIでのチーム可視化の実例をご紹介します。

まずは、今回可視化の対象とした「Four Keys」について簡単に触れておきます。
Four Keysは、GoogleのDevOps Research and Assessment（DORA）チームが提唱した、ソフトウェア開発チームのパフォーマンス（デリバリー能力）を測定するための4つの指標です。

1. デプロイの頻度 (Deployment Frequency): 本番環境へのリリースの頻度。
2. 変更のリードタイム (Lead Time for Changes): コードがコミットされてから本番環境で稼働するまでの時間。
3. 変更障害率 (Change Failure Rate): デプロイが原因で障害が発生した割合。
4. サービス復元時間 (Time to Restore Service): 障害発生から復旧までの時間。

これらは、開発の「スピード（1と2）」と「安定性（3と4）」を示す指標です。
これらの指標を計測することで、チームが速く、かつ安定して価値を届けられているかを客観的に把握できます。

指標の定義は明確ですが、いざ自分たちの環境で計測しようとすると、いくつかの壁にぶつかりました。

まず、変更のリードタイム（開発着手からリリースまでの時間）はJiraのステータス遷移履歴から計算可能ですが、標準のレポート機能だけで算出するのは難しく、APIによるデータ取得と計算処理が必要になります。
また変更障害率については、今回のプロジェクトでは商用障害をGoogleスプレッドシートで管理しているため、そのデータとJiraのリリース情報を突き合わせて計算する必要がありました。

このように散在するデータを集計し、Four Keysダッシュボードを構築するためにGoogle Apps Script (GAS)を採用しました。そして前述の通り、そのコード作成は生成AIに任せました。

1. Jiraから「スピード」を抽出する

まず、Jira APIを通じてチケットデータを取得するスクリプトをAIに作成させました。
プロンプトのポイントは、「ステータスの遷移履歴」に着目させたことです。

プロンプトのイメージ:
「Jiraの特定のプロジェクトから、完了したチケット情報を取得したい。各チケットが『In Progress』になった日時と、そのチケットを含むリリースが完了になった日時を抽出し、その差分をリードタイムとして計算するGASの関数を書いてください。」

これにより、チケットごとのリードタイムと、月ごとのリリース回数（デプロイ頻度）が自動集計できるようになりました。

2. スプレッドシートから「安定性」を計算する

次に、障害管理をしているスプレッドシートへのアクセスです。
こちらは、月ごとの障害発生件数をカウントし、先ほど算出したデプロイ回数と突き合わせることで「変更障害率」を算出させます。

これらを最終的に一つのスプレッドシート上のグラフとして描画することで、チームの「Four Keys」が日次で更新されるダッシュボードが完成しました。

こうして最新のFour Keysをチーム全員がいつでも見られる状態にしたことで、自分たちのリリース頻度や、それに伴う品質への影響（障害）がひと目でわかるようになり、チームの「スピード」と「安定性」が透明化されました。

2つ目は、少しスクラムの枠を超えた対応についてです。
プロジェクトの特性上、リリース日が固定されている「必達案件」があり、その対応に追われていました。本来のスクラムであれば、ベロシティの実績に基づいてスコープを調整すべきですが、この案件ではスコープも固定されており、従来のベロシティのままではリリースに間に合わないことが判明しました。

そこで現実的な対応として、開発者の稼働（人数や時間）を一時的に増やし、ペースアップを図るという決断をしました。

しかし、単に稼働を増やしたといっても、それによって開発スピードがどれだけ上がったのか、今のペースで本当に期日に着地できるのかは、従来のバーンダウンチャートだけでは直感的に分かりづらい状態でした。
「頑張ってはいるが、間に合うかどうかわからない」という不安な状態は、チームの士気を下げてしまいます。

そこで、ここでもAIを活用しました。
Jira APIから取得した「日々の消化ポイント数（実績）」をベースに、残作業を消化するのにあと何日かかるかを計算し、「予測完了日」の推移をプロットするスクリプトをAIに作成させました。

これにより、稼働を上げたあとにグラフの傾きが急になり（消化ペースが上がり）、予測完了日がリリース日手前まで近づいてくる様子が可視化されました（下の図はイメージです）。チームとステークホルダーに対し「現在の加速具合なら○日に終わる」という明確な見通しを提示できたことで、漠然とした不安を払拭し、開発メンバーが自信をもって仕事を進める手助けをすることができました。

これまで「こういうデータがあったらいいな」と思っても、技術的なスキル不足や時間の制約で諦めていた可視化が、AIペアプログラミングによって数時間で実現可能になりました。

透明性は、鮮度が命です。
問題が起きそうだと感じた時、すぐにその状況を可視化するツールを自分自身の手で作れることは、チームを守るスクラムマスターにとって強力な武器になります。
「見えない不安」を即座に「見える課題」に変えられる機動力こそが、AIを活用する最大のメリットかもしれません。

本記事では、AIを活用してGASを書くことで、Jiraやスプレッドシートに眠るデータを掘り起こし、チームに必要な透明性を素早く、低コストで実現した事例を紹介しました。
これは、スクラムガイド拡張パックで示唆されている「AIによる経験的プロセス制御の強化」を実践するための第一歩です。

しかし、透明性はゴールではありません。見えたデータを元にどう判断し、行動を変えるかが重要です。
次回の第3回「検査・適応」では、透明性とはまた違った視点、あるいは可視化された情報を元にした意思決定の場面でのAI活用についてご紹介します。