# GitHub Copilotの影響を伝える

Copilot利用状況、コスト、エンジニアリングの成果を明確に説明して、更新、ロールアウト、トレーニングの決定をサポートします。

Copilotロールアウトを管理する場合は、使用量が増加していることを示す以上のことをリーダーシップ レポートで行う必要があります。 エンジニアリングの目標に対する証拠の意味を説明し、推奨事項を示す必要があります。

このチュートリアルでは、メトリックと開発者のフィードバックを短いレポートにまとめるのに役立ちます。 次の例は、Copilot が観察されたすべての改善を引き起こしたと主張せずに、限られた拡張を推奨する方法を示しています。

## Prerequisites

Copilotの使用状況データ、支出レコード、エンジニアリング結果の測定、開発者のフィードバックを収集します。 これらのソースにアクセスできない場合は、メトリックと課金を担当する担当者と連携してください。

必要なアクセス許可を含め、使用状況と支出データにアクセスする手順については、次を参照してください。

* [Copilot 使用状況メトリック ダッシュボードの表示](/ja/copilot/how-tos/administer-copilot/view-usage-and-adoption)
* [GitHub Copilot に対する会社の支出の管理](/ja/copilot/how-tos/manage-and-track-spending/manage-company-spending)

レポートを準備する前に、ロールアウトの目標に一致する成果指標を選択します。 「[GitHub Copilot を使って会社のエンジニアリング目標を達成する](/ja/copilot/tutorials/roll-out-at-scale/drive-downstream-impact/achieve-company-goals)」を参照してください。

## 手順 1: 決定を定義する

レポートでサポートする決定事項と、それを決定する人を書き留めてください。 たとえば、ライセンスを更新するか、ロールアウトを展開するか、トレーニングに投資するかを決定します。

意思決定者の質問に答える証拠を選択してください：

* エグゼクティブ レビューでは、導入をリーダーシップにとって重要なエンジニアリング目標に結び付けます。 進行状況、コスト、および残りのリスクを要約します。
* 更新については、支出と共に持続的な使用と確認された価値について説明します。 導入ギャップと、それらに対処する計画を特定します。
* 投資要求については、次にサポートするチームまたはワークフローについて説明してください。 提案された予算、予想される結果、および投資効果をどのように評価するかを示します。

これらの会話には同じ基になる証拠を使用しますが、判断に重要な所見を最初に提示します。

## 手順 2: 比較を設定する

レポートのスコープを明示的に設定して、変更内容を閲覧者が理解できるようにします。

1. 含まれている組織、チーム、リポジトリを記録します。
2. レポートの日付と比較対象のベースラインを指定してください。 同等の期間を使用し、その長さの違いを説明してください。
3. 各指標の背後にある母集団を記録します。 たとえば、割り当てられたライセンス、アクティブなユーザー、アンケート回答者を区別します。
4. 結果に影響を与える可能性があるスタッフ配置、プロジェクトの複雑さ、リリース スケジュール、またはエンジニアリングプラクティスの変更に注意してください。

ロールアウト前のベースラインがない場合は、その旨を記載してください。 最も早い信頼性の高い期間を使用して傾向の追跡を開始し、それを導入の前後比較として説明せずにしてください。

ダッシュボードと API の合計が同一視できると想定しないでください。 組み合わせる前に、それらのレポート ウィンドウと母集団を確認します。 「[ダッシュボード、API、レポート全体での Copilot の使用状況メトリックの調整](/ja/copilot/reference/copilot-usage-metrics/reconciling-usage-metrics)」を参照してください。

## 手順 3: 証拠をまとめる

意思決定の質問に答えるのに役立つシグナルの小さなセットを選択します。 各所見について、そのソース、期間、スコープ、および不足しているデータを記録します。

次の種類の証拠からレポートを作成します。

* **採用:** アクティブ ユーザーの傾向、継続的な使用状況、採用コーホートを使用して、Copilot を使用しているユーザーと使用状況がどのように変化しているかを説明します。
* **コスト:** 使用レコードを使用して、ライセンス費用と追加利用料金の説明に使用します。 課金された支出とは別に AI credits 消費を報告します。 投資評価にトレーニングまたは管理コストを含め、見積もりとして明示します。
* **コード生成:** コード生成とコード行数の傾向を使用して、アクティビティを記述します。 生成されたコードを、生産性の向上、品質の向上、または実際に提供された価値の証明として扱わないでください。
* **デリバリー:** pull request のスループットとマージする時間を、選択したデリバリー目標と比較します。
* **品質:** 迅速な配信が単独で評価されないように、関連するテスト カバレッジ、欠陥、セキュリティ結果、またはインシデントを含めます。
* **開発者からのフィードバック:** 役に立つ支援、追加のレビュー作業、またはワークフローの障壁について、開発者が報告している点を要約します。 回答者の数を含め、フィードバックを収集した方法を説明してください。

使用量テレメトリを請求書の合計として表示するのではなく、課金ツールを使用して支出額を設定します。

## 手順 4: 観察と結論を分ける

各発見について、それが何を意味すると思うかを説明する前に、観察したことを書いてください。 たとえば、"より深い導入を持つ Teams では、ユーザーごとにより多くのプル要求がマージされました" と、関連が記述されます。 「Copilot によってそれらのチームの生産性が向上した」は、比較だけでは確立されない因果関係を主張しています。

ダッシュボードの比較と見積もりの解釈に関するガイダンスについては、[GitHub Copilot の使用状況と導入メトリックの解釈](/ja/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics)を参照してください。

使用量の増加や受け入れ率をそれだけで成功事例として提示することは避けてください。 それらが選択した成果にどのように関連しているかを説明し、改善されなかった結果を含めます。

生成されたコード行や報告された時間節約を財務リターンに直接変換しないでください。 節約額の見積もりを含める場合は、前提条件を文書化し、財務チームと検証します。 他の作業で使用できる時間と、実際の支出の削減を区別します。

## 手順 5: 説明文を書く

メイン レポートを短くし、詳細を必要とする読者がサポート ソースを利用できるようにします。

1. **決定と目標を示してください。** 承認したい内容と、それが対処するエンジニアリング上の問題について説明してください。

2. **証拠を要約してください。** 導入、支出、およびその目標に最も関連する成果について説明します。

3. **制限事項を説明してください。** 何が不確実か、他に何が変わったのか、証拠が何を確立できないかを示します。

4. **操作を提案する。** 証拠が、より広範なコミットメントではなく、その措置を裏づける理由を説明します。

   * 導入が不均等な場合は、低使用率を価値の欠如として解釈する前に、セットアップまたはトレーニングの障壁に対処します。
   * 導入が持続しているが、結果の証拠が限られている場合は、より大きなコミットメントを行う前にベースラインを基準に測定を継続します。
   * 結果とフィードバックが拡大を後押しする場合は、予算とレビュー基準を使用して段階的なロールアウトを提案します。
   * コストや品質面の成果が許容できない場合は、調査中に影響を受けるロールアウトを調整または一時停止することをお勧めします。

5. **次のレビューを定義します。** 合意したアクションに担当者を割り当て、成功の状態を指定し、次のレビューをスケジュールします。 次のレポートでアクションが役立ったかどうかを示すことができるように、報告範囲と定義の一貫性を保ちます。

たとえば、架空のロールアウト所有者は、次のように報告できます。

> 10月中にライセンス、使用、トレーニングに2,000ドルの予算を提案し、15人の開発者からなる追加の1チームにロールアウトを拡大することをお勧めします。 私たちの目標は、品質を下げることなく、プルリクエストがマージされるまでの時間を短縮することです。
>
> 9 月には、50 人のライセンスを持つ開発者のうち 40 人が Copilotを使用しました。ベースライン月の 8 月の 50 人中 30 人に対してです。 プルリクエストがマージされるまでの時間の中央値が 3 日から 2 日半に減少しました。 チーム調査では、35人中28人の回答者がテストの作成に関する支援を受けたと回答しましたが、テストカバレッジは変更されていませんでした。
>
> 支出はロールアウト予算内に留まった。 チームもレビュー プロセスを変更したため、配信の変更は Copilot だけが原因とはできません。
>
> ロールアウト所有者は、テスト作成トレーニングを追加し、10月末に導入、支出、カバレッジ、開発者からのフィードバックを確認します。 さらなる拡張は、マージまでの中央値時間が 2 日半以下であること、テスト カバレッジが増加すること、そして支出が予算内に収まることに依存します。

例の数値と推奨事項を、ご自身の根拠に基づく内容に置き換えます。 レポートで更新が妥当と判断された場合は、更新に関する推奨事項を明示的にします。 投資の申請の場合は、観察された傾向が将来のリターンを保証することを意味するのではなく、必要なリソースを指定します。