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