28日。GitHubのCopilot impact dashboardは、アクティブユーザーがどの機能を使ったかを、この期間で表示するようになった。企業・組織向けのレポートAPIからも同じ種類のデータを取得できる。さらにAI adoption phaseには、各段階にいる利用者の28日間の全体数を示す項目が加わった。従来の日ごとのアクティブ利用者だけを見る画面から、導入の動きを期間で追う画面へ一歩進んだ。
Copilotの導入評価はDAUで終わらせない――28日・機能別で見てから席を増やす
28日単位で、使った機能まで見えるようになった
判定：席を増やす前に使う。ただし生産性の証明には使わない
私の判定は、Copilotの契約席を増やす前にこの指標を使う、だ。日次のアクティブ利用者だけでは、たまたま一度開いた人と、複数の機能を仕事に組み込んだ人を同じ「利用」に寄せやすい。28日間の人数と機能別の利用を並べれば、少なくとも導入が一つの機能で止まっているのか、別の作業へ広がっているのかを問い直せる。
ただし、ここで測れるのは利用であって成果ではない。使った人数が増えても、レビュー時間、手戻り、障害、納期がどう変わったかは、この材料にはない。利用率の上昇をそのまま生産性向上と呼ぶのはやめたほうがいい。ダッシュボードは契約の入口を判断する道具で、効果の結論ではない。
日本の導入担当者には、月次の説明に使える粒度だ
日本の企業でAIツールを広げるとき、導入担当者が必要なのは派手な成功例より、次の契約判断に耐える数字だと思う。28日という窓は、月次の利用確認に近い。機能別のエンゲージメントと導入段階の人数を同じ期間で見れば、席を配っただけの状態と、実際の作業へ入った状態を分けて説明しやすくなる。
一方で、閲覧には専用の権限が必要で、Copilot usage metricsのポリシーも有効でなければならない。画面が空なら利用がないと決める前に、権限とポリシーを確認する。数字が見えない状態で契約評価を始めないことが先だ。
今週やること
- Copilot metricsを閲覧できる担当者と、usage metricsポリシーの有効化状況を確認する。
- 直近28日の機能別エンゲージメントと、各導入段階の人数を保存する。日次のアクティブ数だけで報告しない。
- 契約席の追加判断は、少なくとも次の28日分と比較してから行う。
- 利用指標とは別に、レビュー時間、手戻り、障害など、自社が成果と呼ぶ指標を一つ決める。
- 利用が増えても成果指標が動かなければ、席を増やす前に対象業務と使い方を見直す。