ソフトウェア開発ライフサイクルデータ``テンプレート
ソフトウェア開発ライフサイクルデータ``テンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
ソフトウェア開発ライフサイクル属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
ソフトウェア開発ライフサイクル内で発生した特定のイベントまたはタスクの名前。 | ||
|
説明
アクティビティ名とは、「イシュー作成」、「PRへのコードプッシュ」、「プルリクエスト承認」、「デプロイメント成功」など、開発プロセスにおける単一のステップを記述します。これらのイベントは、開発アイテムのエンドツーエンドのプロセスを構成するステップのシーケンスを形成します。 この属性はプロセスマイニングにおいて、プロセスマップを構築するために使用されるため、非常に重要です。これらのアクティビティのシーケンス、頻度、期間を分析することで、実際のプロセスフローが明らかになり、共通パスの特定、逸脱の強調表示、ボトルネックの特定が可能になります。
その重要性
この属性はプロセスマップの根幹をなし、開発ライフサイクルにおけるイベントのシーケンスの可視化と分析を可能にします。
取得元
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
|
機能、バグ修正、タスクなど、開発作業の単一単位の一意な識別子です。これは主要なケース識別子として機能します。 | ||
|
説明
開発アイテムIDは、作業アイテムの作成から最終デプロイメントまでを追跡します。ブランチ作成、コミット、プルリクエスト、レビュー、デプロイメントなど、関連するすべてのアクティビティを単一のまとまりのあるプロセスインスタンスにリンクします。 分析では、このIDは開発タスクのエンドツーエンドのサイクルタイムを計算するために使用されます。これにより、機能やバグ修正の全ジャーニーを再構築でき、個々の作業アイテムにおけるボトルネック、手戻りループ、プロセス変動の詳細な分析が可能になります。
その重要性
プロセスマイニングにとって不可欠なキーであり、関連するすべての開発イベントを単一のケースに接続し、エンドツーエンドのソフトウェア開発ライフサイクルを正確に可視化および分析するために使用されます。
取得元
これは通常、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
|
開発アイテムに割り当てられた優先度レベル(例:「高」、「中」、「低」)。 | ||
|
説明
優先度とは、作業アイテムの緊急性またはビジネス上の重要性を示します。GitHubでは、優先度はネイティブなフィールドではなく、通常ラベル(例:「P1-High」、「P2-Medium」)を使用して管理されます。この情報を確実に抽出するには、一貫したラベリングスキームが必要です。 この属性は「優先度ベースのフロー分析」に不可欠です。アナリストは、高優先度アイテムが実際に低優先度アイテムよりも迅速に処理されているかを確認し、優先度に基づいたサイクルタイムのばらつきを測定できます。これは優先度付けプロセスの有効性を評価するのに役立ちます。
その重要性
高優先度のアイテムが低優先度のアイテムよりも速く処理されるかどうかを分析し、優先順位付け戦略の有効性を検証することを可能にします。
取得元
イシューまたはプルリクエストに適用されたGitHubラベルから派生します。優先度ラベルには標準化された規則が必要です。
例
高中低クリティカル
|
|||
|
担当ユーザー
Assignee
|
開発アイテムまたはプルリクエストレビューのような特定のタスクを担当するために割り当てられたユーザーまたは開発者。 | ||
|
説明
この属性は、特定のステージで作業を担当する個人を特定します。これは、イシューのアサインee、プルリクエストの作成者、またはコードレビューを依頼されたレビュー担当者である可能性があります。アサインeeを追跡することは、リソース割り当てとワークロードを理解する上で重要です。 この属性は、分析において開発者のワークロードを監視し、リソースのボトルネックを特定し、異なるチームメンバー間の引き継ぎ効率を分析するために使用されます。ダッシュボードはアサインeeでフィルタリングでき、個人またはチームのパフォーマンスを評価し、作業のバランスの取れた分散を確保するために役立ちます。
その重要性
開発者の作業負荷、チームのパフォーマンス、および異なるチームメンバー間の引き継ぎの効率を分析するために重要です。
取得元
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内のラベルまたは特定のイシューテンプレートを通じて管理されます。バグ修正は新機能よりも期待されるサイクルタイムがはるかに短い可能性があるため、作業の種類を理解することは、適切なパフォーマンス期待値を設定する上で不可欠です。 この属性は、異なる作業タイプ間の比較分析を可能にします。バグ修正が新機能よりも迅速に処理されているかを分析したり、技術的負債と新規開発へのリソース割り当てを理解したりするのに役立ちます。「プロジェクトとタイプ別のスループット」ダッシュボードの主要な次元です。
その重要性
作業アイテムを分類し、異なる種類の作業(例: バグと機能)がプロセスをどのように流れるかのパフォーマンス比較と分析を可能にします。
取得元
通常、GitHubのイシューまたはプルリクエストに適用されるラベルから派生します。一貫したラベリング規則(例:「type:bug」、「type:feature」)が必要です。
例
バグ機能タスク技術的負債
|
|||
|
CIチェックステータス
CiCheckStatus
|
自動化された継続的インテグレーション(CI)チェックのステータス(例:「合格」または「失敗」)。 | ||
|
説明
この属性は、プルリクエスト内のコード変更に対して実行される自動ビルド、テスト、スキャンンの結果を反映します。CIチェックは、最新の開発ワークフローにおける重要な品質ゲートです。 この属性を分析することで、自動テストの有効性を理解するのに役立ちます。高い失敗率は、コードの安定性、テストスイート、または開発環境に問題があることを示唆する可能性があります。「CIチェック合格」および「CIチェック失敗」のアクティビティをサポートし、ビルドの破損によって引き起こされる遅延の分析に役立ちます。
その重要性
自動化された品質ゲートの成否を示し、コード品質とCIパイプラインの有効性に関する洞察を提供します。
取得元
GitHub ChecksまたはStatuses APIを通じて、チェック実行またはステータスオブジェクトの「state」または「conclusion」フィールドから取得されます。
例
successfailure待機中error
|
|||
|
アイテムの状態
State
|
イシューまたはプルリクエストの現在のステータス(例:「オープン」、「クローズ」、「マージ済み」)。 | ||
|
説明
この属性は、開発アイテムの上位レベルのステータスを示します。イシューの場合、一般的な状態は「オープン」と「クローズ」です。プルリクエストの場合、状態には「オープン」、「クローズ」、「マージ済み」が含まれます。これはアイテムの進捗状況のスナップショットを提供します。 分析では、状態は進行中の作業と完了した作業を識別するために使用されます。進行中の作業を監視する「アクティブな開発進捗」のようなダッシュボードに不可欠です。また、プロセスの終了を定義するためにも使用され、例えば「マージ済み」または「クローズ」の状態はケースの完了を示す場合があります。
その重要性
作業アイテムが現在進行中か完了済みかを明確に示し、ライフサイクル分析とアクティブな作業の監視に不可欠な情報を提供します。
取得元
GitHub APIからのイシューおよびプルリクエストのJSONペイロード内の「state」フィールドとして直接利用可能です。
例
オープンクローズ済みmerged
|
|||
|
コミットハッシュ
CommitHash
|
特定のコードコミットの一意な識別子(SHA)。 | ||
|
説明
コミットハッシュは、Gitでコミットを一意に識別する40文字のSHA-1ハッシュです。これはコードの特定のバージョンに対する永続的なIDとして機能します。コミットは、開発プロセスにおける変更の最小単位です。 非常に粒度が細かいコミットハッシュは、究極のトレーサビリティを提供します。これにより、アナリストはプロセスイベントを、行われた正確なコード変更に直接リンクさせることができます。これは、監査、コンプライアンス、または本番環境でのインシデントの詳細な根本原因分析にとって非常に貴重です。
その重要性
プロセスステップと正確なコード変更との間で最も詳細なリンクを提供し、監査やデバッグのための完全なトレーサビリティを可能にします。
取得元
プッシュイベントペイロード('head_commit.id')またはプルリクエストやブランチのコミットAPIを通じて利用可能です。
例
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
ソースシステム
SourceSystem
|
開発プロセスデータが抽出されたシステム。 | ||
|
説明
この属性は、イベントデータの発生源を特定します。このプロセスの場合、値は常に「GitHub」となります。開発アクティビティが複数のシステム(例:計画にJira、コードにGitHub、デプロイメントにJenkins)にまたがるより複雑な環境では、このフィールドは各イベントのソースを区別するために使用されます。 分析では、データの妥当性確認とトラブルシューティングのために、データをその発生源まで追跡するのに役立ちます。また、異なるプラットフォームを横断するプロセスを分析することも可能にし、各アクティビティに明確なコンテキストを提供します。
その重要性
データの発生源を特定します。これは、データ検証や、複数の統合システムにまたがるプロセスを分析するために不可欠です。
取得元
これは通常、レコードのソースをラベル付けするために、データ抽出、変換、ロード(ETL)プロセス中に加えられる静的な値です。
例
GitHubGitHub Enterprise
|
|||
|
デプロイ環境
DeploymentEnvironment
|
デプロイメントのターゲット環境(例:「Staging」または「Production」)。 | ||
|
説明
この属性は、コードがどこにデプロイされているかを指定します。異なる環境へのデプロイメントを追跡することは、開発から本稼働リリースまでの完全なライフサイクルを理解する上で重要です。 この属性により、デプロイメントサブプロセスの分析が可能になります。stagingから本稼働へコードを昇格させるのにかかる時間を測定し、異なる環境へのデプロイメントの成功率を追跡するために使用できます。開発アイテムが真に「完了」し、ユーザーに届けられた時期を知るために不可欠です。
その重要性
本番前リリースと本番リリースを区別することは、真の「市場投入までの時間」を測定し、デプロイパターンを分析するために不可欠です。
取得元
この情報は、GitHub Deployments APIから取得されます。このAPIは、多くの場合、CI/CDパイプラインやその他の自動化によってトリガーされます。
例
開発stagingproduction
|
|||
|
ブランチ名
BranchName
|
開発アイテムのコード変更が行われたGitブランチの名前。 | ||
|
説明
ブランチは、メインのコードベースに影響を与えることなく、新しい機能やバグ修正に取り組むために作成される独立した開発ラインです。ブランチ名には、イシュー番号や作業の簡単な説明など、有用な情報が含まれていることがよくあります。 ブランチ名を分析することは、ブランチ戦略と開発規則への順守を理解するのに役立ちます。また、特定のコードコミットを開発アイテムにリンクさせ、コーディング活動の全体像を把握するのにも役立ちます。
その重要性
特定の開発ラインに関するコンテキストを提供し、ブランチ戦略と命名規則の適用および分析を支援します。
取得元
プッシュイベントの「ref」フィールド、またはプルリクエストAPIレスポンス内の「head」および「base」オブジェクトで利用可能です。
例
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
プルリクエスト番号
PullRequestNumber
|
開発アイテムに関連付けられたプルリクエストの一意な識別子。 | ||
|
説明
プルリクエスト(PR)は、一連のコード変更を特定のブランチにマージするための提案です。プルリクエスト番号は、コードプッシュやレビューなどの開発活動を、主要な開発アイテムまたはイシューにリンクさせます。 このIDは、より広範な開発ライフサイクルにおけるコード統合およびレビューのサブプロセスを追跡するために不可欠です。これにより、レビュー時間、レビュー中に特定された手戻りサイクル、マージ率など、コードレビュープロセスの詳細な分析が可能になります。これは、計画フェーズ(イシュー)と実装フェーズ(PR)を結びつけます。
その重要性
イシューを特定のコード変更やレビュープロセスにリンクさせ、コードレビューサイクルとそれが全体的なデリバリー時間に与える影響の詳細な分析を可能にします。
取得元
多くのGitHub APIレスポンス内の「pull_request」オブジェクト内の「number」フィールドとして、またはプルリクエストAPIのメイン識別子として利用可能です。
例
12345678910
|
|||
|
ラベル
Labels
|
分類のためにイシューまたはプルリクエストに適用されるタグまたはラベルのリストです。 | ||
|
説明
GitHubのラベルは、イシューやプルリクエストにメタデータを追加するための柔軟な方法です。これらは優先度、作業タイプ、コンポーネント、チーム、またはステータスを示すために使用できます。生のラベルリストは、豊富で非構造化されたコンテキストを提供します。 優先度やタイプのような特定の属性はラベルから派生しますが、完全なリストを保持することは、アドホック分析や他のプロセスパターンを発見するのに役立ちます。これにより、任意のラベルの組み合わせに基づいてケースを柔軟にフィルタリングおよびセグメント化できます。
その重要性
作業アイテムを分類するための柔軟で豊富なメタデータソースを提供し、深く多様な多次元分析を可能にします。
取得元
GitHub APIからのイシューおよびプルリクエストのJSONペイロード内の「labels」配列として利用可能です。配列内の各アイテムは、「name」フィールドを持つオブジェクトです。
例
バグ、UI、高優先度機能、バックエンド、ドキュメント必要tech-debt, refactor
|
|||
|
レビュー担当者
Reviewer
|
プルリクエストでコードレビューの実施を依頼されたユーザー。 | ||
|
説明
レビュアーは、プルリクエスト内のコード変更が品質、正確性、および標準への準拠を検査するために割り当てられた開発者またはチームメンバーです。1つのプルリクエストに複数のレビュアーがいる場合があります。 この属性は、コードレビュープロセスを分析するために不可欠です。特定のレビュアーに関連するボトルネックを特定し、レビューの作業負荷の分布を理解し、レビュアーがリクエストに応答するのにかかる時間を測定するのに役立ちます。これは、「平均コードレビューサイクルタイム」KPIを計算するための重要な要素です。
その重要性
品質保証プロセスに関与する個人を特定し、レビューの作業負荷、遅延、およびコードレビュー全体の効率の分析を可能にします。
取得元
GitHub APIからのプルリクエストレビューイベントの「requested_reviewers」配列または「user」オブジェクトで利用可能です。
例
alex.chenmaria.garciasenior-dev-team
|
|||
|
レビュー状態
ReviewState
|
プルリクエストのコードレビューの結果(例:「承認済み」または「変更要求あり」)。 | ||
|
説明
この属性は、レビュー担当者によって下された決定を捕捉します。一般的な状態には、コードがマージ可能であることを示す「承認済み(APPROVED)」と、手戻りが必要であることを示す「変更要求あり(CHANGES_REQUESTED)」が含まれます。その他の状態としては、「コメントあり(COMMENTED)」や「保留中(PENDING)」などがあります。 これは手戻りや品質を分析するための重要な属性です。「変更要求あり」イベントの頻度が高い場合、初期のコード品質や要件の不明確さに問題があることを示唆する可能性があります。「手戻りおよびリグレッションループ」ダッシュボードを直接サポートし、開発アイテムが修正のために差し戻された時期を特定します。
その重要性
コードレビュープロセス内の手戻りループと品質ゲートを直接示し、非効率性や品質問題の原因を特定するのに役立ちます。
取得元
GitHub APIからのプルリクエストレビューオブジェクト内の「state」フィールドとして利用可能です。例えば、「PullRequestReviewEvent」ペイロード内。
例
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
作成者
Author
|
イシュー、プルリクエスト、またはコミットを作成したユーザー。 | ||
|
説明
作成者は、開発プロセスにおける特定の成果物の発信者です。例えば、イシューの作成者はバグを報告した人、または機能をリクエストした人です。プルリクエストの作成者はコードを書いた開発者です。 分析では、作成者を用いて作業の出所を理解できます。例えば、バグレポートの作成者を分析することで、特定のチームや機能に関連するパターンが明らかになる場合があります。また、アサインeeと組み合わせて引き継ぎパターンを分析することも可能です。
その重要性
作業アイテムまたはコード変更の起票者を特定します。これは、手戻り、バグ報告、または機能リクエストの発生源を分析するのに役立ちます。
取得元
イシュー、プルリクエスト、コミットのAPIレスポンスのメインオブジェクト内の「user」オブジェクトで利用可能です。フィールドは通常、「user.login」です。
例
sara.jonesmike.leeautomation-bot
|
|||
|
最終データ更新
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。 | ||
|
説明
この属性は、最新のデータ抽出または更新の日時を記録します。これにより、分析対象データの鮮度に関するメタデータが提供されます。これは、ビジネスイベントが発生した時点を記録するイベントタイムスタンプとは異なります。 分析において、このフィールドはプロセスビューの適時性を理解する上で不可欠です。ユーザーがリアルタイムデータを見ているのか、特定の時点のスナップショットを見ているのかを知るのに役立ち、運用ダッシュボードや監視にとって重要です。
その重要性
データの鮮度を示します。これは、分析とダッシュボードが最新の情報に基づいていることを確認するために不可欠です。
取得元
この
例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
処理時間
ProcessingTime
|
アクティビティの計算された期間であり、実作業時間を表します。 | ||
|
説明
処理時間とは、アクティビティの開始から終了までの経過時間です。「EndTimestamp」から「EventTimestamp」を引くことで計算されます。この指標は、タスクの開始を待つ時間を除き、タスクを完了するのにかかる時間を測定します。 処理時間を分析することで、実作業の観点から最も時間のかかるアクティビティを特定できます。これは待機時間を含むサイクルタイムとは異なります。例えば、コードレビューのサイクルタイムが長くても処理時間が短い場合、レビュー担当者が多忙でPRがキューで待機していることを示唆します。
その重要性
実作業の期間を測定し、タスクへの作業時間と待機時間を区別するのに役立ちます。これは、具体的な効率改善を行う上で重要です。
取得元
単一のアクティビティレコードについて、「EventTimestamp」を「EndTimestamp」から減算することで計算されます。
例
PT5M15SPT2H30MP1DT12H
|
|||
|
引き継ぎ待機時間
HandoffWaitingTime
|
開発アイテムが異なる担当者によって実行されるアクティビティ間で待機する計算されたアイドル時間。 | ||
|
説明
このメトリックは、あるアクティビティの完了から次のアクティビティの開始までの時間を測定しますが、担当者が変更される場合に限ります。例えば、「レビュー要求済み」イベントと、異なるユーザーによる「レビューで変更要求あり」イベントの間の時間です。 これは、コミュニケーションギャップや連携問題を特定するための重要なメトリックです。「クリティカルな引き継ぎ効率」ダッシュボードと「平均引き継ぎ待機時間」KPIをサポートします。引き継ぎポイントでの長い待機時間は、しばしばリソース制約や非効率な通知プロセスの兆候です。
その重要性
異なるチームやロール間の引き継ぎにおいて、連携不足やリソース不足が原因で発生する遅延を特定します。これらは非効率の主な原因となることがよくあります。
取得元
「Assignee」または「User」属性が変更される連続したアクティビティを特定し、それらの間の時間差を測定することで計算されます。
例
PT1H15MP2DT4HPT25M
|
|||
|
手戻り
IsRework
|
アクティビティが前のプロセスステージへの回帰を示す場合にtrueとなるブール値のフラグです。 | ||
|
説明
このフラグは、開発アイテムがプロセス内で後退する際、例えばプルリクエストが「変更要求あり」レビューを受けたり、クローズ後にイシューが再オープンされたりした場合に この属性は無駄と非効率を定量化するために不可欠です。「手戻りおよびリグレッションループ」ダッシュボードと「手戻り率」KPIを直接サポートします。「IsRework = true」でフィルタリングすることで、アナリストは手戻りの原因を特定し、調査できます。
その重要性
手戻りを構成するアクティビティを明示的にマークし、プロセス非効率性の原因を定量化、視覚化、分析することを容易にします。
取得元
これは派生属性です。ロジックには、標準的なプロセスフローを定義し、以前の論理ステージに戻ることで逸脱するアクティビティにフラグを立てることが含まれます。
例
truefalse
|
|||
|
開発サイクルタイム
DevelopmentCycleTime
|
開発アイテムの作成から最終デプロイメントまたはクローズまでの経過時間の合計。 | ||
|
説明
これは、単一の開発アイテムにおける最初のイベント(例:「イシュー作成」)と最終イベント(例:「デプロイメント成功」または「イシュークローズ」)との時間差として計算されるケースレベルのメトリックです。 これは開発プロセス全体の効率を測定するための最も重要なKPIの1つです。「全体開発サイクルタイム」ダッシュボードおよび「平均開発サイクルタイム」KPIを直接サポートします。このメトリックを削減することは、プロセス改善イニシアチブの主要な目標となることがよくあります。
その重要性
開発アイテムの「エンドツーエンドの市場投入時間」を表し、プロセス全体の速度と効率を測定するための重要なKPIとなります。
取得元
ケースレベルで、最初のアクティビティのタイムスタンプを最後のアクティビティのタイムスタンプから減算することで計算されます。
例
P5DT6H30MP14DT12HP1DT2H
|
|||
ソフトウェア開発ライフサイクルアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
CIチェック合格
|
プルリクエスト内のコードに対して実行された、ビルド、ユニットテスト、静的解析などの自動チェックの成功を表します。このイベントはGitHub Actionsのようなシステムによって報告されるチェックのステータスから推測されます。 | ||
|
その重要性
この自動化された品質ゲートは、コードの安定性を確保するために不可欠です。失敗や実行時間の長さは、デリバリーパイプラインにおける重大なボトルネックとなる可能性があります。
取得元
GitHub Checks APIまたはStatuses APIから推測されます。チェックランまたはステータス更新は、「success」または「completed」かつ「success」の結論を報告します。
取得
関連するチェック スイートで「成功」の結果がないか、Checks APIを監視します。
イベントタイプ
inferred
|
|||
|
プルリクエストマージ済み
|
プルリクエストからの承認されたコード変更は、mainやdevelopのようなターゲットブランチに正式に統合されます。これは、新しいコードを組み込むプルリクエストに対する明示的かつ最終的なアクションです。 | ||
|
その重要性
これは、開発とレビューの完了を示す重要なマイルストーンです。多くのチームにとって、これは自動デプロイメント前の最終ステップです。
取得元
GitHubプルリクエストAPIイベントストリームまたはWebhookから取得されます。イベントアクションは「closed」であり、プルリクエストペイロードの「merged」属性はtrueです。
取得
プルリクエストの「クローズ」アクションを監視し、「マージ済み」フラグが
イベントタイプ
explicit
|
|||
|
プルリクエスト承認済み
|
レビュアーはプルリクエストの変更を正式に承認し、品質および機能基準を満たしていることを示します。これはレビュアーが「approve」ステータスでレビューを提出したときに記録されます。 | ||
|
その重要性
これは、マージ前の重要な品質ゲートであり、主要なマイルストーンです。PR作成からこの状態に達するまでの時間は、レビュープロセスの効率性を示す重要なKPIです。
取得元
GitHubプルリクエストAPIまたはWebhookから、レビューが「APPROVED」状態で提出されたときに取得されます。
取得
プルリクエストレビュー提出イベントを「APPROVED」ステータスでフィルタリングします。
イベントタイプ
explicit
|
|||
|
プルリクエスト開始
|
コードの最初のブロックがレビューと統合の準備ができたことを示します。開発者は、フィーチャーブランチからメインブランチへの変更を提案するためにプルリクエスト(PR)を作成します。これはGitHubにおける明示的なイベントです。 | ||
|
その重要性
これは、初期開発フェーズの終了と、レビューおよび統合パイプラインの開始を示す重要なマイルストーンです。開発とレビューのサイクルタイムを個別に分析する上で重要です。
取得元
GitHubプルリクエストAPIイベントストリームまたはWebhookから取得されます。イベントアクションは「opened」です。
取得
プルリクエストの「オープン」アクションを、WebhookまたはAPIポーリングを通じて監視します。
イベントタイプ
explicit
|
|||
|
問題作成
|
開発アイテムのライフサイクルの始まりを示し、タスク、バグ、機能リクエストの正式な作成を表します。このイベントは、ユーザーがGitHubリポジトリで新しいイシューを作成した際に明示的に捕捉されます。 | ||
|
その重要性
これはプロセスの主要な開始アクティビティであり、総開発サイクルタイムを測定し、初期の作業源を理解するために不可欠です。
取得元
これは、GitHub Issues APIイベントストリームから捕捉される明示的なイベントです。イベントタイプは通常、指定されたイシュー番号に対して「opened」です。
取得
イシューの「オープン」イベントを、WebhookまたはAPIポーリングを通じて監視します。
イベントタイプ
explicit
|
|||
|
課題クローズ済み
|
開発アイテムが完了したと見なされ、対応するイシューが正式にクローズされます。これは、リンクされたプルリクエストがマージされたときに自動的に発生する場合と、チームメンバーによって手動で実行される場合があります。 | ||
|
その重要性
このアクティビティは、開発アイテムのプロセスの明確な終了点として機能します。エンドツーエンドのサイクルタイムを計算するために不可欠です。
取得元
これは、GitHub Issues APIイベントストリームから捕捉される明示的なイベントです。イベントタイプは「closed」です。
取得
イシューの「クローズ」イベントを、WebhookまたはAPIポーリングを通じて監視します。
イベントタイプ
explicit
|
|||
|
CIチェック失敗
|
プルリクエスト内のコードに対して実行された、ビルドエラーやユニットテストの失敗などの自動チェックの失敗を表します。これはGitHub Actionsのようなシステムによって報告される失敗ステータスから推測されます。 | ||
|
その重要性
このアクティビティは、開発者の介入を必要とする技術的な品質問題を浮き彫りにし、手戻りループを生み出します。失敗頻度を分析することで、ローカルテストやコード品質の改善に役立ちます。
取得元
GitHub Checks APIまたはStatuses APIから推測されます。チェックランまたはステータス更新は、「failure」または「completed」かつ「failure」の結論を報告します。
取得
関連するチェック スイートで「失敗」の結果がないか、Checks APIを監視します。
イベントタイプ
inferred
|
|||
|
PRにコードプッシュ
|
最初期PRの一部として、またはレビューフィードバックに応じて、レビューのために提出されたコードへの更新を表します。このイベントは、オープンなプルリクエストに関連付けられたブランチに新しいコミットがプッシュされるたびに捕捉されます。 | ||
|
その重要性
これらのイベントを追跡することは、手戻りループを特定するために不可欠です。レビュー後に複数回プッシュされた場合、変更が必要であったことを示し、全体のサイクルタイムに影響を与えます。
取得元
これはプルリクエストのタイムラインにおける明示的なイベントであり、しばしばコミットの追加としてラベル付けされます。「プッシュ」Webhookから、またはPRに関連付けられたコミットを監視することによって捕捉できます。
取得
オープンなプルリクエストに関連付けられたブランチでの「プッシュ」イベントを追跡します。
イベントタイプ
explicit
|
|||
|
イシュー再オープン
|
以前にクローズされたイシューが再アクティブ化されるのは、通常、修正が不十分だったか、回帰が見つかったためです。これは開発アイテムのライフサイクルを再開する明示的なイベントです。 | ||
|
その重要性
これは重大な手戻りループを示し、潜在的な「本稼働欠陥流出」または不完全な修正を示唆します。その頻度を追跡することは、ソフトウェア全体の品質を測る主要な指標となります。
取得元
これは、GitHub Issues APIイベントストリームから捕捉される明示的なイベントです。イベントタイプは「reopened」です。
取得
イシューの「再オープン」イベントを、WebhookまたはAPIポーリングを通じて監視します。
イベントタイプ
explicit
|
|||
|
デプロイ成功
|
コード変更がstagingやproductionなどの特定の環境に正常にデプロイされました。このイベントは通常、GitHub Deployments APIを通じて捕捉され、多くの場合、マージ後にGitHub Actionによってトリガーされます。 | ||
|
その重要性
コードがリポジトリから本稼働環境へ移行したことを示します。これを追跡することは、アイデアから本稼働までのリードタイム全体を測定する上で不可欠です。
取得元
Deployments APIを通じて取得されます。外部サービスまたはGitHubアクションがデプロイメントを作成し、そのステータスを「success」に更新します。
取得
デプロイメントステータスイベントをWebhookで監視し、「成功」の状態を確認します。
イベントタイプ
inferred
|
|||
|
ブランチ作成
|
イシューに対するアクティブな開発作業の開始を表します。開発者がメインコードベースから新しいブランチを作成する時点です。これは、新しいブランチがリポジトリにプッシュされたときに明示的に捕捉されるイベントであり、ブランチ名にイシュー番号が含まれることがよくあります。 | ||
|
その重要性
計画からアクティブなコーディングへの移行を示します。イシュー作成からこのイベントまでの時間を測定することは、開発者の作業開始時間と初期バックログ遅延を分析するのに役立ちます。
取得元
GitHub Git APIまたは「branch」タイプの「create」イベントをリッスンするWebhookを通じて取得されます。多くの場合、「feature/issue-123」のような命名規則を介して、ブランチ名をイシューにリンクする必要があります。
取得
新しいブランチの「作成」Webhookイベントを解析し、イシューと関連付けます。
イベントタイプ
explicit
|
|||
|
レビューで変更要求
|
レビュアーはコードレビューを完了し、プルリクエストが承認される前に修正が必要であると判断しました。レビュアーは「request_changes」ステータスで正式にレビューを提出します。 | ||
|
その重要性
このイベントは、手戻りループを明示的に示します。その頻度を分析することは、品質問題、不明確な要件、または開発者トレーニングの領域を特定するのに役立ちます。
取得元
GitHubプルリクエストAPIまたはWebhookから、レビューが「CHANGES_REQUESTED」状態で提出されたときに取得されます。
取得
プルリクエストレビュー提出イベントを「CHANGES_REQUESTED」ステータスでフィルタリングします。
イベントタイプ
explicit
|
|||
|
レビュー依頼済み
|
プルリクエストの作成者は、特定のチームメンバーまたはチームにコードレビューを正式に依頼します。これはGitHub UIまたはAPI内で行われる明示的なアクションであり、リクエストされたレビュー担当者への通知をトリガーします。 | ||
|
その重要性
このアクティビティは、コードレビュープロセスへの正式な引き継ぎの開始を示します。これとレビュー提出までの時間は、レビュー担当者の応答性と潜在的なボトルネックを測定するのに役立ちます。
取得元
GitHubプルリクエストAPIイベントストリームまたはWebhookから取得されます。イベントアクションは「review_requested」です。
取得
プルリクエストの「レビューリクエスト」アクションを監視します。
イベントタイプ
explicit
|
|||