ソフトウェア開発ライフサイクルのデータテンプレート
ソフトウェア開発ライフサイクルのデータテンプレート
- 収集を推奨する属性
- 記録すべき主要なアクティビティ
- データ抽出の手順
ソフトウェア開発ライフサイクルの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
ソフトウェア開発ライフサイクルで発生した特定のイベントまたはタスクの名前です。 | ||
|
説明
アクティビティ名は、「Issueの作成」「PRへのコードのプッシュ」「プルリクエストの承認」「デプロイの成功」など、開発プロセスの個々のステップを表します。これらのイベントが連なり、開発項目のエンドツーエンドのプロセスを構成します。 この属性は、プロセスマップの作成に使われるため、プロセスマイニングの基本となります。アクティビティの順序、頻度、所要時間を分析すると、実際のプロセスフローやよくある経路が分かり、逸脱やボトルネックを特定できます。
重要な理由
この属性はプロセスマップの基盤となり、開発ライフサイクルにおけるイベントの順序を可視化して分析できます。
入手先
Webhookイベントのペイロードにある「action」フィールド(Issueの「opened」「closed」など)、またはイベントタイプ(「PushEvent」「PullRequestReviewEvent」など)から取得します。
例
Issueの作成プルリクエストの作成PRへのコードのプッシュレビューの依頼プルリクエストのマージ
|
|||
|
開始時刻
EventTimestamp
|
特定の開発アクティビティまたはイベントが発生した正確な日時です。 | ||
|
説明
このタイムスタンプは、アクティビティの開始時刻を示します。開発項目ごとのプロセスフローを再構成するために、イベントを時系列に並べるうえで欠かせません。タイムスタンプの順序と時間差を使って、プロセスのパフォーマンスを分析します。 分析では、サイクルタイム、処理時間、待機時間など、時間に関するすべての指標の算出に必要です。ステップ間の遅延を特定できるほか、ボトルネック分析やパフォーマンス監視用のダッシュボードに必要なデータを提供します。
重要な理由
イベントを正しい順序に並べ、サイクルタイムやボトルネックの継続時間など、すべてのパフォーマンス指標を算出するうえで重要なタイムスタンプです。
入手先
Issue、プルリクエスト、コミットなどのオブジェクトについて、GitHub APIやWebhookのJSONペイロードにある「created_at」または「updated_at」フィールドから取得できます。
例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
開発項目
DevelopmentItemId
|
機能、バグ修正、タスクなど、個々の開発作業を識別する一意のIDです。ケースを識別する主なIDとして使われます。 | ||
|
説明
開発項目IDは、作業項目の作成から最終的なデプロイまでを追跡します。ブランチの作成、コミット、プルリクエスト、レビュー、デプロイなど、関連するすべてのアクティビティを結び付け、1つの一貫したプロセスインスタンスとして扱います。 分析では、このIDを使って開発タスクのエンドツーエンドのサイクルタイムを算出します。機能やバグ修正の全過程を再構成できるため、個々の作業項目について、ボトルネック、手戻り、プロセスのばらつきを詳しく分析できます。
重要な理由
プロセスマイニングに欠かせないキーです。関連する開発イベントを1つのケースに結び付け、ソフトウェア開発ライフサイクル全体を正確に可視化して分析できます。
入手先
通常は、GitHubのIssue番号またはプルリクエスト番号です。Issueやプルリクエストに関連するWebhookイベントまたはAPIレスポンスのペイロードにある「number」フィールドから取得できます。
例
101PR-2345TASK-812
|
|||
|
リポジトリ
RepositoryName
|
開発アクティビティが行われているコードリポジトリの名前です。 | ||
|
説明
リポジトリはプロジェクトや製品を識別するもので、特定のアプリケーションやコンポーネントのコード、Issue、プルリクエストが含まれます。製品やチームごとに開発プロセスを分類し、比較するために使えます。 分析では、この属性を使ってプロジェクトごとのプロセスパフォーマンスを絞り込み、比較できます。「サイクルタイムが最も長いプロジェクトはどれか」「プロジェクトAとプロジェクトBでバグ修正のプロセスにどのような違いがあるか」といった問いに答えるのに役立ちます。「プロジェクト・タイプ別スループット」ダッシュボードにも欠かせません。
重要な理由
プロジェクト、製品、チームごとに開発プロセスを分類して比較できるため、対象を絞った分析に役立ちます。
入手先
ほぼすべてのGitHub WebhookおよびAPIペイロードにある「repository」オブジェクトから取得できます。該当するフィールドは通常、「repository.full_name」または「repository.name」です。
例
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
優先度
Priority
|
開発項目に割り当てられる優先度。例:「高」「中」「低」。 | ||
|
説明
優先度は、作業項目の緊急度やビジネス上の重要性を示します。GitHubには優先度を表す標準フィールドがないため、通常はラベル(例:「P1-高」「P2-中」)で管理します。この情報を正確に抽出するには、一貫したラベル付けルールが必要です。 この属性は「優先度別フロー分析」に欠かせません。優先度の高い項目が低い項目より実際に速く処理されているかを確認し、優先度ごとのサイクルタイムの差を測定できます。また、優先順位付けの有効性を評価する際にも役立ちます。
重要な理由
優先度の高い項目が低い項目より速く処理されているかを分析し、優先順位付けの方針が有効かどうかを確認できます。
入手先
Issueまたはプルリクエストに付けられたGitHubラベルから取得します。優先度ラベルの標準ルールが必要です。
例
高中低重大
|
|||
|
割り当て先ユーザー
Assignee
|
開発項目や、プルリクエストのレビューなど特定のタスクを担当するユーザーまたは開発者です。 | ||
|
説明
この属性は、各段階で作業を担当する人を示します。Issueの担当者、プルリクエストの作成者、コードレビューを依頼されたレビュアーなどが該当します。担当者を追跡することで、リソース配分や作業負荷を把握できます。 分析では、開発者の作業負荷の監視、リソース面のボトルネックの特定、チームメンバー間の引き継ぎ効率の分析に使います。ダッシュボードを担当者で絞り込むと、個人やチームのパフォーマンスを確認し、作業が適切に配分されているかを把握できます。
重要な理由
開発者の作業負荷、チームのパフォーマンス、チームメンバー間の引き継ぎ効率を分析するうえで重要です。
入手先
GitHub APIから取得するIssue、プルリクエスト、レビューイベントのJSONペイロードにある「assignee」または「user」オブジェクトで確認できます。
例
john.doejane.smithdev-team-lead
|
|||
|
終了時刻
EndTimestamp
|
特定の開発アクティビティまたはイベントが完了した正確な日時です。 | ||
|
説明
終了タイムスタンプは、アクティビティの完了時刻を示します。GitHubのイベントの多くは「Issueの作成」のように瞬時に発生しますが、CIチェックの実行など、所要時間を測定できるアクティビティもあります。終了時刻から開始時刻を引くと、アクティビティの処理時間を算出できます。 この属性は「ProcessingTime」指標の算出に使われます。コードレビューや自動チェックなど、各タスクに実際にかかった時間を把握するうえで重要です。処理時間を分析すると、時間がかかりすぎている非効率なアクティビティを特定できます。
重要な理由
アクティビティの処理時間を正確に算出できるため、実作業の時間と待機時間を区別するのに役立ちます。
入手先
チェック実行オブジェクトの「completed_at」から取得するか、後続の論理的な完了イベントのタイムスタンプから算出できます。
例
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
開発項目のタイプ
DevelopmentItemType
|
機能、バグ、タスク、エピックなど、開発作業項目の分類です。 | ||
|
説明
この属性は、作業の種類を分類します。通常、GitHubのラベルや専用のIssueテンプレートで管理します。作業の種類を把握することは、適切なパフォーマンス目標を設定するうえで重要です。たとえば、バグ修正に期待されるサイクルタイムは、新機能の開発より大幅に短い場合があります。 この属性を使うと、作業の種類ごとに比較分析できます。バグ修正が新機能より早く処理されているか、技術的負債への対応と新規開発にリソースがどう配分されているかを分析できます。「プロジェクト・タイプ別スループット」ダッシュボードの重要な分析軸です。
重要な理由
作業項目を分類し、パフォーマンスを比較できます。バグと機能など、作業の種類ごとにプロセスの進み方を分析するのに役立ちます。
入手先
通常、Issueまたはプルリクエストに付けられたGitHubラベルから取得します。「type:bug」「type:feature」など、一貫したラベルの命名規則が必要です。
例
バグ機能タスク技術的負債
|
|||
|
CIチェック状態
CiCheckStatus
|
継続的インテグレーション(CI)の自動チェックの状態。例:「成功」「失敗」。 | ||
|
説明
この属性には、プルリクエストのコード変更に対して実行される自動ビルド、テスト、スキャンの結果が記録されます。CIチェックは、現在の開発ワークフローにおける重要な品質ゲートです。 この属性を分析すると、自動テストの有効性を把握できます。失敗率が高い場合、コードの安定性、テストスイート、または開発環境に問題がある可能性があります。「CIチェック成功」と「CIチェック失敗」のアクティビティを確認でき、ビルドの失敗による遅延の分析にも役立ちます。
重要な理由
自動化された品質ゲートの成功・失敗を示し、コード品質やCIパイプラインの有効性を把握できます。
入手先
GitHub Checks APIまたはStatuses APIを通じて、チェック実行オブジェクトまたはステータスオブジェクトの「state」フィールドや「conclusion」フィールドから取得します。
例
成功失敗保留中エラー
|
|||
|
コミットハッシュ
CommitHash
|
特定のコードコミットを一意に識別する値(SHA)です。 | ||
|
説明
コミットハッシュは、Gitのコミットを一意に識別する40文字のSHA-1ハッシュです。コードの特定バージョンを示す恒久的なIDとして機能します。コミットは、開発プロセスにおける変更の最小単位です。 コミットハッシュを使うと、プロセスイベントを実際に行われたコード変更まで追跡できます。監査やコンプライアンス、本番環境のインシデントに関する詳細な根本原因分析に役立ちます。
重要な理由
プロセスの各ステップと実際のコード変更を最も細かい単位で結び付け、監査やデバッグに必要な追跡性を確保できます。
入手先
プッシュイベントのペイロード(「head_commit.id」)から取得できます。また、プルリクエストやブランチに関するCommits APIからも取得できます。
例
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
ソースシステム
SourceSystem
|
開発プロセスのデータを抽出したシステムです。 | ||
|
説明
この属性は、イベントデータの発生元を示します。このプロセスでは、値は常に「GitHub」です。開発アクティビティが複数のシステム(計画管理のJira、コード管理のGitHub、デプロイのJenkinsなど)にまたがる環境では、各イベントのソースを区別するために使います。 分析では、データの検証や問題の調査のために、データを発生元までたどるのに役立ちます。また、複数のプラットフォームにまたがるプロセスを分析し、各アクティビティのコンテキストを明確にできます。
重要な理由
データの発生元を特定します。データの検証や、複数の連携システムにまたがるプロセスの分析に欠かせません。
入手先
通常、レコードのソースを示す固定値として、データの抽出、変換、読み込み(ETL)の処理中に追加します。
例
GitHubGitHub Enterprise
|
|||
|
デプロイ環境
DeploymentEnvironment
|
デプロイ先の環境。例:「ステージング」「本番」。 | ||
|
説明
この属性は、コードのデプロイ先を示します。開発から本番リリースまでのライフサイクル全体を把握するには、環境ごとのデプロイを追跡することが重要です。 デプロイのサブプロセスを分析する際に利用できます。ステージングから本番へコードを昇格させるまでの時間や、環境ごとのデプロイ成功率を測定できます。また、開発項目が実際に完了し、ユーザーに納品されたタイミングを把握するうえでも欠かせません。
重要な理由
本番前のリリースと本番リリースを区別できるため、実際の市場投入までの時間を測定し、デプロイのパターンを分析できます。
入手先
この情報はGitHub Deployments APIから取得します。多くの場合、CI/CDパイプラインなどの自動化処理によって呼び出されます。
例
開発ステージング本番
|
|||
|
ブランチ名
BranchName
|
開発項目に関するコード変更を行ったGitブランチの名前です。 | ||
|
説明
ブランチは、新機能の開発やバグ修正をメインのコードベースに影響を与えずに進めるための、独立した開発ラインです。ブランチ名には、Issue番号や作業内容の簡単な説明など、有用な情報が含まれていることがあります。 ブランチ名を分析すると、ブランチ戦略や開発ルールの遵守状況を把握できます。また、特定のコードコミットを開発項目に関連付け、コーディング作業の全体像を確認するのにも役立ちます。
重要な理由
開発ラインの内容を把握しやすくなり、ブランチ戦略や命名ルールの適用状況を確認できます。
入手先
プッシュイベントの「ref」フィールド、またはプルリクエストAPIレスポンス内の「head」オブジェクトと「base」オブジェクトから取得できます。
例
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
プルリクエスト番号
PullRequestNumber
|
開発項目に関連付けられたプルリクエストを一意に識別する番号です。 | ||
|
説明
プルリクエスト(PR)は、コード変更を特定のブランチにマージするための提案です。プルリクエスト番号を使うと、コードのプッシュやレビューなどの開発アクティビティを、元となる開発項目やIssueに関連付けられます。 このIDは、開発ライフサイクル全体におけるコード統合とレビューのサブプロセスを追跡するうえで重要です。レビューにかかった時間、レビュー中に発生した手戻り、マージ率など、コードレビューの詳細な分析に役立ちます。また、計画段階のIssueと実装段階のPRを結び付けます。
重要な理由
Issueを具体的なコード変更やレビューのプロセスに結び付け、コードレビューのサイクルと全体の納期への影響を詳しく分析できます。
入手先
多くのGitHub APIレスポンスでは、「pull_request」オブジェクト内の「number」フィールドから取得できます。また、Pull Requests APIの主要な識別子としても利用できます。
例
12345678910
|
|||
|
ラベル
Labels
|
Issueやプルリクエストの分類に使われるタグまたはラベルの一覧です。 | ||
|
説明
GitHubのラベルは、Issueやプルリクエストにメタデータを追加する柔軟な方法です。優先度、作業の種類、コンポーネント、チーム、状態などを示すために使えます。ラベルの一覧には、構造化されていない豊富なコンテキストが含まれています。 優先度や種類などの属性はラベルから取得できますが、ラベル全体を保持しておくと、個別の分析やほかのプロセスパターンの発見に役立ちます。ラベルを自由に組み合わせて、ケースを絞り込んだり分類したりできます。
重要な理由
作業項目を分類するための柔軟で豊富なメタデータを提供し、多様な切り口で詳しく分析できます。
入手先
GitHub APIから取得するIssueおよびプルリクエストのJSONペイロード内にある「labels」配列から取得できます。配列内の各項目は「name」フィールドを持つオブジェクトです。
例
バグ、UI、高優先度機能、バックエンド、文書が必要技術的負債、リファクタリング
|
|||
|
レビュー状態
ReviewState
|
プルリクエストのコードレビュー結果。例:「承認済み」「変更をリクエスト」。 | ||
|
説明
この属性には、レビュアーの判断が記録されます。一般的な状態には、コードをマージできることを示す「APPROVED」と、手戻りが必要であることを示す「CHANGES_REQUESTED」があります。そのほか、「COMMENTED」や「PENDING」などの状態もあります。 手戻りや品質を分析するうえで重要な属性です。「CHANGES_REQUESTED」の発生頻度が高い場合、最初のコードの品質や要件の明確さに問題がある可能性があります。「手戻りと回帰ループ」ダッシュボードでは、開発項目が修正のために差し戻されたタイミングを特定できます。
重要な理由
コードレビュー中の手戻りや品質ゲートを直接把握できるため、非効率や品質上の問題の発生源を特定できます。
入手先
GitHub APIのプルリクエストレビューオブジェクトにある「state」フィールドから取得できます。たとえば、「PullRequestReviewEvent」のペイロードに含まれます。
例
承認済み変更をリクエストコメント済み
|
|||
|
レビュアー
Reviewer
|
プルリクエストのコードレビューを依頼されたユーザーです。 | ||
|
説明
レビュアーは、プルリクエストのコード変更について、品質、正確性、標準への準拠を確認する開発者またはチームメンバーです。1つのプルリクエストに複数のレビュアーを割り当てることもできます。 この属性は、コードレビューのプロセスを分析するうえで欠かせません。特定のレビュアーに関連するボトルネックの特定、レビュー作業の分担状況の把握、レビュー依頼への応答時間の測定に役立ちます。「平均コードレビューサイクルタイム」の重要業績評価指標(KPI)の算出にも使われます。
重要な理由
品質確認に関わる担当者を特定し、レビュー作業の負荷や遅延、コードレビュー全体の効率を分析できます。
入手先
GitHub APIの「requested_reviewers」配列、またはプルリクエストのレビューイベントに含まれる「user」オブジェクトから取得できます。
例
alex.chenmaria.garciasenior-dev-team
|
|||
|
作成者
Author
|
Issue、プルリクエスト、またはコミットを作成したユーザーです。 | ||
|
説明
作成者は、開発プロセスにおける特定の成果物を作成した人です。たとえば、Issueの作成者はバグを報告した人や機能をリクエストした人、プルリクエストの作成者はコードを書いた開発者です。 分析では、作成者を使って作業の発生源を把握できます。たとえば、バグ報告の作成者を分析すると、特定のチームや機能に関連する傾向が見つかることがあります。また、担当者と組み合わせて分析すれば、引き継ぎのパターンも把握できます。
重要な理由
作業項目やコード変更の起点となった人を特定できます。手戻り、バグ報告、機能リクエストの発生源を分析する際に役立ちます。
入手先
Issue、プルリクエスト、コミットに関するAPIレスポンスでは、メインオブジェクト内の「user」オブジェクトから取得できます。フィールド名は通常「user.login」です。
例
sara.jonesmike.leeautomation-bot
|
|||
|
最終データ更新日時
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性には、データを最後に抽出または更新した日時が記録されます。分析対象データの鮮度を示すメタデータです。ビジネスイベントの発生日時を記録するイベントタイムスタンプとは異なります。 分析では、プロセスの状況をどの時点のデータで確認しているかを把握するうえで重要です。リアルタイムのデータか、特定時点のスナップショットかを確認できるため、業務用ダッシュボードや監視に役立ちます。
重要な理由
データの鮮度を示します。分析やダッシュボードを最新の情報に基づいて確認するうえで重要です。
入手先
このタイムスタンプは、データの抽出、変換、読み込み(ETL)の処理中に生成して追加します。
例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
引き継ぎ待ち時間
HandoffWaitingTime
|
異なる担当者が行うアクティビティの間に、開発項目が待機する時間です。 | ||
|
説明
あるアクティビティの完了から次のアクティビティの開始までの時間を測定します。ただし、担当者が変わる場合に限ります。たとえば、「レビュー依頼」イベントから、別のユーザーによる「レビューで変更をリクエスト」イベントまでの時間です。 コミュニケーションの行き違いや調整上の問題を特定するための重要な指標です。「重要な引き継ぎの効率」ダッシュボードと「平均引き継ぎ待ち時間」指標を支えます。引き継ぎ時の待ち時間が長い場合、リソース不足や通知プロセスの非効率が原因である可能性があります。
重要な理由
チームやロール間の引き継ぎで、調整不足やリソースの不足によって生じる遅延を特定できます。こうした遅延は、非効率の主な原因となることがよくあります。
入手先
「担当者」または「ユーザー」属性が変わる連続したアクティビティを特定し、その間の時間差を測定して算出します。
例
PT1H15MP2DT4HPT25M
|
|||
|
手戻りかどうか
IsRework
|
アクティビティが前のプロセス段階に戻ることを示す場合にtrueとなるブール値フラグです。 | ||
|
説明
開発項目がプロセス上で後戻りした場合に、このフラグをtrueに設定します。たとえば、プルリクエストのレビューで「変更をリクエスト」された場合や、クローズ後にIssueが再オープンされた場合です。アクティビティの順序を分析して判定します。 この属性は、無駄や非効率を定量化するうえで欠かせません。「手戻りと回帰ループ」ダッシュボードと「手戻り率」指標を支えます。「IsRework = true」で絞り込むと、手戻りの原因を特定して調査できます。
重要な理由
手戻りに該当するアクティビティを明示し、プロセスの非効率の原因を簡単に定量化、可視化、分析できます。
入手先
派生属性です。標準的なプロセスフローを定義し、前の論理段階に戻るアクティビティを特定することで設定します。
例
truefalse
|
|||
|
開発サイクルタイム
DevelopmentCycleTime
|
開発項目の作成から最終的なデプロイまたはクローズまでにかかった時間です。 | ||
|
説明
1つの開発項目について、最初のイベント(例:「Issue作成」)から最後のイベント(例:「デプロイ成功」または「Issueクローズ」)までの時間差を算出する、ケース単位の指標です。 開発プロセス全体の効率を測るうえで、特に重要な重要業績評価指標(KPI)の1つです。「開発サイクルタイム全体」ダッシュボードと「平均開発サイクルタイム」指標を支えます。プロセス改善の取り組みでは、この指標の短縮が主な目標となることがよくあります。
重要な理由
開発項目の市場投入までの時間を示すため、プロセス全体の速度と効率を測る重要業績評価指標(KPI)となります。
入手先
ケース単位で、最初のアクティビティのタイムスタンプから最後のアクティビティのタイムスタンプを差し引いて算出します。
例
P5DT6H30MP14DT12HP1DT2H
|
|||
|
項目の状態
State
|
「open」「closed」「merged」など、Issueまたはプルリクエストの現在の状態です。 | ||
|
説明
この属性は、開発項目の大まかな状態を示します。Issueの一般的な状態は「open」と「closed」です。プルリクエストには「open」「closed」「merged」があります。これにより、項目の進捗状況を把握できます。 分析では、進行中の作業と完了した作業を区別するために使います。進行中の作業を監視する「開発進捗」などのダッシュボードに欠かせません。また、プロセスの終了を定義する際にも使います。たとえば、「merged」または「closed」の状態をケースの完了と見なすことができます。
重要な理由
作業項目が進行中か完了しているかを明確に示します。ライフサイクルの分析や進行中の作業の監視に欠かせません。
入手先
GitHub APIから取得するIssueおよびプルリクエストのJSONペイロードにある「state」フィールドで確認できます。
例
オープンクローズマージ済み
|
|||
ソフトウェア開発ライフサイクルのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
CIチェックの成功
|
プルリクエストのコードに対して実行されたビルド、単体テスト、静的解析などの自動チェックが正常に完了したことを示します。GitHub Actionsなどのシステムが報告するチェックのステータスから推定されるイベントです。 | ||
|
重要な理由
この自動品質ゲートは、コードの安定性を確保するうえで重要です。チェックの失敗や実行時間の長さが、リリース工程の大きなボトルネックになることがあります。
入手先
GitHub Checks APIまたはStatuses APIから推定します。チェック実行またはステータス更新で「success」が報告されるか、「completed」と「success」の結論が報告されます。
記録
Checks APIを監視し、該当するチェック群で「success」の結論が報告されたことを確認します。
イベントタイプ
inferred
|
|||
|
Issueのクローズ
|
開発項目が完了したと見なされ、対応するIssueが正式にクローズされます。関連するプルリクエストのマージ時に自動でクローズされる場合と、チームメンバーが手動でクローズする場合があります。 | ||
|
重要な理由
このアクティビティは、開発項目のプロセスが完了したことを示します。エンドツーエンドのサイクルタイムを算出するうえで重要です。
入手先
GitHub Issues APIのイベントストリームから明示的に取得できるイベントです。イベントタイプは「closed」です。
記録
WebhookまたはAPIのポーリングで、Issueの「closed」イベントを取得します。
イベントタイプ
explicit
|
|||
|
Issueの作成
|
開発項目のライフサイクルの開始を示します。タスク、バグ、機能リクエストが正式に作成された時点です。GitHubリポジトリでユーザーが新しいIssueを作成すると、このイベントが明示的に記録されます。 | ||
|
重要な理由
プロセスの主な開始アクティビティです。開発サイクル全体の所要時間を測定し、作業がどこから始まったかを把握するうえで欠かせません。
入手先
GitHub Issues APIのイベントストリームから明示的に取得できるイベントです。特定のIssue番号に対するイベントタイプは、通常「opened」です。
記録
WebhookまたはAPIのポーリングで、Issueの「opened」イベントを取得します。
イベントタイプ
explicit
|
|||
|
プルリクエストのマージ
|
承認されたプルリクエストのコード変更が、mainやdevelopなどの対象ブランチに正式に統合されます。新しいコードを取り込む、プルリクエスト上の明示的な最終操作です。 | ||
|
重要な理由
開発とレビューの完了を示す重要な節目です。多くのチームでは、自動デプロイの直前に行う最後のステップです。
入手先
GitHub Pull Request APIのイベントストリームまたはWebhookから取得します。イベントアクションが「closed」で、プルリクエストのペイロードにある「merged」属性がtrueの場合です。
記録
プルリクエストの「closed」アクションを取得し、「merged」フラグがtrueかどうかを確認します。
イベントタイプ
explicit
|
|||
|
プルリクエストの作成
|
最初のコードがレビューと統合に進める状態になったことを示します。開発者がプルリクエスト(PR)を作成し、機能ブランチの変更をメインブランチに反映するよう提案します。これはGitHubで明示的に記録されるイベントです。 | ||
|
重要な理由
初期開発の終了と、レビューおよび統合の開始を示す重要な節目です。開発とレビューのサイクルタイムを分けて分析するうえで重要です。
入手先
GitHub Pull Request APIのイベントストリームまたはWebhookから取得します。イベントアクションは「opened」です。
記録
WebhookまたはAPIのポーリングで、プルリクエストの「opened」アクションを取得します。
イベントタイプ
explicit
|
|||
|
プルリクエストの承認
|
レビュアーがプルリクエストの変更を正式に承認し、品質と機能の基準を満たしていることを示します。レビュアーが「approve」ステータスでレビューを提出すると記録されます。 | ||
|
重要な理由
マージ前の重要な品質ゲートであり、大きな節目です。PRの作成からこの状態に至るまでの時間は、レビュー工程の効率を測る重要業績評価指標(KPI)です。
入手先
レビューが「APPROVED」状態で提出された際に、GitHub Pull Request APIまたはWebhookから取得します。
記録
プルリクエストのレビュー提出イベントを、「APPROVED」状態で絞り込みます。
イベントタイプ
explicit
|
|||
|
CIチェックの失敗
|
プルリクエストのコードに対して実行されたビルドエラーや単体テストの失敗など、自動チェックが失敗したことを示します。GitHub Actionsなどのシステムが報告する失敗ステータスから推定されるイベントです。 | ||
|
重要な理由
このアクティビティは、開発者の対応が必要な技術的な品質問題を示し、手戻りにつながります。失敗の頻度を分析すると、ローカルテストやコード品質の改善に役立ちます。
入手先
GitHub Checks APIまたはStatuses APIから推定します。チェック実行またはステータス更新で「failure」が報告されるか、「completed」と「failure」の結論が報告されます。
記録
Checks APIを監視し、該当するチェック群で「failure」の結論が報告されたことを確認します。
イベントタイプ
inferred
|
|||
|
Issueの再オープン
|
以前クローズされたIssueが再び有効になります。通常、修正が不十分だった場合や、リグレッションが見つかった場合に発生します。開発項目のライフサイクルを再開する明示的なイベントです。 | ||
|
重要な理由
大きな手戻りの発生を示し、本番環境への不具合流出や修正の不完全さが疑われます。発生頻度は、ソフトウェア全体の品質を測る重要な指標です。
入手先
GitHub Issues APIのイベントストリームから明示的に取得できるイベントです。イベントタイプは「reopened」です。
記録
WebhookまたはAPIのポーリングで、Issueの「reopened」イベントを取得します。
イベントタイプ
explicit
|
|||
|
PRへのコードのプッシュ
|
最初のPR、またはレビューのフィードバックへの対応として、レビュー対象のコードが更新されたことを示します。オープン中のプルリクエストに関連付けられたブランチに新しいコミットがプッシュされるたびに、このイベントが記録されます。 | ||
|
重要な理由
手戻りの発生を特定するには、これらのイベントを追跡することが重要です。レビュー後に複数回プッシュされている場合、変更が必要だったことを示し、サイクルタイム全体に影響します。
入手先
プルリクエストのタイムラインに明示的に記録されるイベントで、多くの場合、コミットの追加として表示されます。「push」Webhookから取得するか、PRに関連付けられたコミットを監視して取得できます。
記録
オープン中のプルリクエストに関連付けられたブランチの「push」イベントを追跡します。
イベントタイプ
explicit
|
|||
|
デプロイの成功
|
ステージング環境や本番環境など、特定の環境へのコード変更のデプロイが成功したことを示します。通常はGitHub Deployments APIから取得し、マージ後にGitHub Actionがイベントを発生させることもあります。 | ||
|
重要な理由
コードがリポジトリから稼働環境に移行したことを示します。アイデアから本番環境までのリードタイム全体を測るうえで、追跡が欠かせません。
入手先
Deployments APIから取得します。外部サービスまたはGitHub Actionがデプロイを作成し、そのステータスを「success」に更新します。
記録
Webhookでデプロイのステータスイベントを監視し、状態が「success」になったことを確認します。
イベントタイプ
inferred
|
|||
|
ブランチの作成
|
Issueに対する開発作業の開始を示します。開発者がメインのコードベースから新しいブランチを作成した時点です。リポジトリに新しいブランチがプッシュされると明示的に記録され、多くの場合、ブランチ名にIssue番号が含まれます。 | ||
|
重要な理由
計画段階から実際のコーディングへの移行を示します。Issueの作成からこのイベントまでの時間を測ることで、開発者が作業に着手するまでの時間や、初期バックログによる遅延を分析できます。
入手先
GitHub Git APIから取得するか、「branch」タイプの「create」イベントを監視するWebhookで取得します。「feature/issue-123」のような命名規則を使い、ブランチ名とIssueを関連付ける必要がある場合もあります。
記録
新しいブランチの「create」Webhookイベントを解析し、Issueと関連付けます。
イベントタイプ
explicit
|
|||
|
レビューで変更を依頼
|
レビュアーがコードレビューを完了し、プルリクエストを承認する前に修正が必要だと判断しました。レビュアーは「request_changes」ステータスでレビューを正式に提出します。 | ||
|
重要な理由
このイベントは手戻りの発生を明確に示します。発生頻度を分析することで、品質上の問題、要件の不明確さ、開発者向けトレーニングが必要な領域を特定できます。
入手先
レビューが「CHANGES_REQUESTED」状態で提出された際に、GitHub Pull Request APIまたはWebhookから取得します。
記録
プルリクエストのレビュー提出イベントを、「CHANGES_REQUESTED」状態で絞り込みます。
イベントタイプ
explicit
|
|||
|
レビューの依頼
|
プルリクエストの作成者が、特定のチームメンバーまたはチームにコードレビューを正式に依頼します。GitHubのUIまたはAPIでこの操作を行うと、依頼されたレビュアーに通知が送られます。 | ||
|
重要な理由
コードレビューへの引き継ぎが正式に始まったことを示すアクティビティです。この時点からレビューの提出までの時間を測ることで、レビュアーの対応速度やボトルネックの可能性を把握できます。
入手先
GitHub Pull Request APIのイベントストリームまたはWebhookから取得します。イベントアクションは「review_requested」です。
記録
プルリクエストの「review_requested」アクションを取得します。
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使ってデータを準備し、ソフトウェア開発ライフサイクルの改善を始めましょう。非効率な部分を見つけ、より迅速でスムーズなリリースにつなげてください。
SDLCを改善:非効率な部分をすばやく特定
サイクルタイムを30%短縮し、GitHubでの開発プロセスを効率化します。
クレジットカードは不要です。数分で設定できます。