ソフトウェア開発ライフサイクルのデータテンプレート

ServiceNow DevOps
ソフトウェア開発ライフサイクルのデータテンプレート

ソフトウェア開発ライフサイクルのデータテンプレート

このテンプレートでは、ソフトウェア開発ライフサイクルを最適化するために必要なデータの収集方法を詳しく説明します。収集すべき属性、追跡すべき主要なアクティビティ、ServiceNow DevOpsからデータを抽出する方法をまとめています。このリソースを使って、プロセス分析に適したイベントログを作成してください。
  • 収集を推奨する属性
  • 追跡すべき主要なアクティビティ
  • ServiceNow DevOpsからの抽出方法
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

ソフトウェア開発ライフサイクルの属性

ソフトウェア開発ライフサイクルを詳細に分析するために、イベントログに含めることを推奨するデータ項目です。
5 必須 8 推奨 5 任意
名前 説明
アクティビティ名
ActivityName
発生した特定の開発ライフサイクルイベントの名称です。Development StartedやCode Review Performedなどが該当します。
説明

ソフトウェア開発ライフサイクル内で完了した各マイルストーンまたはタスクの名称を記録する属性です。これらのアクティビティが、作成からデプロイまでのプロセスを構成する一連のステップとなります。

これらのアクティビティの順序と発生頻度を分析することが、プロセスマイニングの主な役割です。プロセスマップの作成、ステップ間のボトルネックの特定、コンプライアンスに反する、または非効率なプロセスバリアントの把握に役立ちます。定義されたアクティビティには、設計、開発、テスト、デプロイなどの主要な段階が含まれます。

重要な理由

プロセスマップ上のステップを定義し、プロセスフローの分析、ボトルネックの特定、標準的なSDLCからの逸脱の把握を可能にします。

入手先

通常は、ステータス変更、イベントレコード、監査証跡のエントリを標準化されたアクティビティ名の一覧にマッピングして生成します。たとえば、stateフィールドがIn Progressに変わった場合、Development Startedにマッピングできます。

開発を開始コードをコミットQAテストを完了本番環境にデプロイ
開始時刻
EventTime
特定のアクティビティまたはイベントが発生した時点を示す正確なタイムスタンプです。
説明

開発ライフサイクル内の各アクティビティが記録された日付と時刻を示す属性です。イベントを時系列に並べるため、また時間に基づくすべての分析を行うために欠かせません。

プロセスマイニングでは、アクティビティ間の所要時間、待機時間、プロセス全体のサイクルタイムを算出するために開始時刻を使います。SDLC End-to-End Cycle Time Analysisなど、パフォーマンスを分析するダッシュボードや、Code Review Lead Timeなどの主要業績評価指標を算出するうえでも重要な要素です。

重要な理由

イベントを正しい順序に並べ、サイクルタイム、所要時間、待機時間など、すべてのパフォーマンス指標を算出するために欠かせないタイムスタンプです。

入手先

通常は、監査証跡またはタスクテーブルにあるsys_updated_onやsys_created_onなど、システムが生成するタイムスタンプフィールドに記録されています。

2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
開発項目
DevelopmentItem
機能、バグ、タスクなど、開発ライフサイクルを通じて進行する1つの作業単位を識別する一意の識別子です。
説明

Development Itemは、追跡対象となる個別の作業単位を表す主要なケース識別子です。該当するアイテムについて、初期構想と計画から開発、テスト、デプロイまで、すべてのアクティビティを関連付けます。

プロセスマイニング分析では、この属性が各作業アイテムのエンドツーエンドの流れを再構築する基盤となります。プロセスフローの可視化、総サイクルタイムの算出、個々の機能やバグ修正におけるプロセスバリアントの特定が可能になります。整合性のあるプロセスマップを作成するには、イベントログ内のすべてのイベントをDevelopment Itemに関連付ける必要があります。

重要な理由

関連するすべての開発アクティビティを1つのプロセスインスタンスに結び付ける中核的な識別子です。これにより、各作業アイテムのライフサイクル全体を分析できます。

入手先

通常は、ストーリー、バグ、タスクを管理するテーブルの主キーです。ServiceNowでは、rm_story、rm_bug、taskなどのテーブルが該当します。

STRY0010015BUG0034092TASK0050118
ソースシステム
SourceSystem
データの抽出元となるシステムを識別します。この場合はServiceNow DevOpsです。
説明

イベントデータの発生元となるシステムを指定する属性です。このプロセスでは、常にServiceNow DevOpsとなります。

静的な値に見える場合でも、ソースシステムを明示的に含めることは、データガバナンスや、Jira、Azure DevOpsなど複数のシステムからデータを統合する環境で重要です。データの出所を明確にし、データ品質や抽出に関する問題の診断にも役立ちます。

重要な理由

データの追跡可能性を確保し、複数の開発ツールからデータを統合する場合に、データの完全性を維持するために欠かせません。

入手先

データの抽出および変換処理中に追加する静的な値です。

ServiceNow DevOps
最終データ更新日時
LastDataUpdate
このイベントログのデータがソースシステムから最後に更新された時点を示すタイムスタンプです。
説明

ServiceNow DevOpsからデータセットが最後に抽出または更新された日時を記録する属性です。個々のイベントではなく、データセット全体に適用されます。

このタイムスタンプは、分析対象データの鮮度を把握するうえで重要です。プロセス分析の結果がどの時点の情報に基づくものかを利用者に伝え、データ更新のスケジュール設定にも役立ちます。ダッシュボードに表示すれば、すべての指標と可視化結果に適切な背景情報を加え、最新のデータに基づく意思決定を支援できます。

重要な理由

データの適時性に関する重要な背景情報を提供し、プロセス分析がどの程度最新の状態かを利用者が把握できるようにします。

入手先

データ抽出処理中に生成および追加され、抽出が実行された日時を記録するタイムスタンプです。

2023-11-15T08:00:00Z
優先度
DevelopmentItemPriority
開発アイテムに割り当てられた優先度です。High、Medium、Lowなどがあります。
説明

ビジネス上の緊急度に基づいて開発アイテムを分類する属性です。優先度を設定すると、チームは重要度の高いタスクに集中しやすくなり、SLAや関係者の期待値の管理にも役立ちます。

プロセスマイニングでは、優先度は比較分析の重要な軸です。プロセスマップを絞り込み、高優先度のアイテムがより速い、または異なる経路をたどっているかを確認できます。High-Priority Feature Delivery TimeダッシュボードとKPIに欠かせず、重要なアイテムが実際に優先処理されているかを検証できます。

重要な理由

優先度ごとにプロセスを絞り込み、比較できます。高優先度のアイテムがより速く、効率的に処理されているかの検証に役立ちます。

入手先

通常は、ServiceNowのタスク関連テーブルにあるpriorityという標準フィールドです。

1 - 重大2 - 高3 - 中4 - 低
割り当てグループ
AssignmentGroup
アクティビティの実行時点で、開発アイテムを担当するチームまたはグループです。
説明

作業アイテムに割り当てられたチームを識別する属性です。Frontend Developers、Backend Services、QA Teamなどがあります。作業アイテムの進行に伴い、異なる割り当てグループ間で引き継がれることがよくあります。

割り当てグループを追跡することは、部門横断の連携と引き継ぎを把握するうえで重要です。作業が別のチームに移る際に発生する構造的な遅延の特定に役立ちます。チーム単位のパフォーマンスや作業負荷の分析、全体のフローでボトルネックとなっているチームの特定にも利用できます。

重要な理由

作業を担当するチームを追跡し、チームのパフォーマンス、作業負荷の平準化、チーム間の引き継ぎ効率を分析できます。

入手先

通常は、ServiceNowのタスク関連テーブルにある標準フィールドassignment_groupに保存されています。

プラットフォームエンジニアリングモバイルアプリチーム品質保証DevOps
影響を受けるモジュール/コンポーネント
ModuleComponentAffected
開発アイテムが関係する特定のソフトウェアモジュール、アプリケーション、またはコンポーネントです。
説明

システム内のどの部分に影響する開発作業かを分類する属性です。特定のマイクロサービス、UIコンポーネント、バックエンドアプリケーションなどが該当します。

モジュールまたはコンポーネントごとにプロセスを分けて分析することは、局所的なボトルネックを特定するうえで重要です。Component-Specific Bottleneck InsightsダッシュボードとAvg Stage Duration by Component KPIでは、この属性を使って、コードベースの特定部分が長い開発サイクル、高い手戻り率、または頻繁なデプロイ失敗と継続的に関連しているかを特定します。改善が必要な箇所に取り組みを集中させるのに役立ちます。

重要な理由

アプリケーションまたはコンポーネントごとに分析を分け、システムの特定部分に固有のボトルネックや品質上の問題を切り分けられます。

入手先

カスタムフィールド、またはConfiguration Management Database(CMDB)への参照であることが多く、作業アイテムをcmdb_ciレコードに関連付けます。ServiceNow DevOpsのドキュメントを確認してください。

請求サービスユーザー認証UIレポーティングデータベースAPIゲートウェイ
手戻りかどうか
IsRework
アクティビティが手戻りループの一部である場合にtrueとなるブール型フラグです。テスト後に開発へ戻るケースなどが該当します。
説明

プロセスが以前の段階へ戻った後に発生したアクティビティを識別する派生属性です。たとえば、同じアイテムでQA Testing Completedの後にDevelopment Startedが発生した場合、そのアクティビティを手戻りとしてフラグ付けします。

手戻りの定量化と可視化に欠かせません。Rework and Rejection Flow Analysisダッシュボードを直接支援し、Rework Rate after Testing KPIの算出にも使われます。これらのイベントにフラグを付けることで、手戻りの頻度、原因、総サイクルタイムへの影響を簡単に絞り込んで分析できます。

重要な理由

手戻りを簡単に定量化・分析できるため、プロセス品質の測定や、作業の繰り返しが発生する根本原因の特定に役立ちます。

入手先

各ケースのアクティビティの順序を分析し、プロセスフロー上の後戻りを検出することで、プロセスマイニングツール内で算出されます。

truefalse
担当開発者
AssignedDeveloper
アクティビティの実行時点で、開発アイテムに割り当てられていた開発者またはユーザーの氏名もしくはIDです。
説明

特定のタスクまたはアクティビティの実行責任者を識別する属性です。開発アイテムが異なる段階やチームに移ると、担当者も変わる可能性があります。

リソース配分、作業負荷、引き継ぎを分析するうえで重要です。Developer Workload and HandoffsダッシュボードやActivity Volume per Developer KPIを直接支援します。このフィールドの変更を追跡することで、引き継ぎ時間を測定し、開発者間、または開発チームとQAチーム間の連携上のボトルネックを特定できます。

重要な理由

作業負荷の分配、引き継ぎの効率、チームごとのパフォーマンス傾向など、リソースに基づく分析に欠かせません。

入手先

通常は、ServiceNowのタスク関連テーブルにあるassigned_toフィールドに保存されています。

David MillerAnna WilliamsJames Brown
開発アイテムのサイクルタイム
DevelopmentItemCycleTime
開発アイテムの作成から最終的なクローズまたはデプロイまでに経過した総時間です。
説明

1つの開発アイテムにかかるエンドツーエンドの所要時間を表す計算指標です。各ケースについて、最初のアクティビティのタイムスタンプと最後のアクティビティのタイムスタンプの差を求めて算出します。

SDLC全体に対する主要なKPIであり、Average SDLC Cycle Time KPIを直接支援します。プロセスの速度と効率を高レベルで測定できます。時間の推移や、優先度、チームなどの切り口で分析すると、プロセス改善施策の効果を追跡できます。

重要な理由

作業アイテムのエンドツーエンドの総所要時間を表し、プロセス全体の効率と速度を測定する重要な指標です。

入手先

ソースシステムのフィールドではありません。プロセスマイニングツールで、各CaseIdについて最小のStartTimeから最大のStartTimeを引いて算出します。

15日4時間3日12時間32日8時間
開発アイテムの状態
DevelopmentItemState
イベント発生時点における開発アイテムのステータスまたは状態です。Open、In Progress、Closedなどがあります。
説明

ServiceNow上での開発アイテムの正式なステータスを示す属性です。アクティビティがプロセスから導出されるステップであるのに対し、状態はシステムのワークフロー上の正式な段階を表します。

状態は、アクティビティを導出する元の情報になることがよくあります。データ検証や、プロセスを簡略化した高レベルのビューの作成にも利用できます。たとえば、各状態に滞在した時間を分析すると、アクティビティ間の時間を分析する場合とは異なる観点でボトルネックを把握できます。停滞しているアイテムや解決済みのアイテムの特定にも役立ちます。

重要な理由

作業アイテムの正式なシステム上の状態を提供します。アクティビティの導出元になることが多く、検証や高レベルのステータス分析にも利用できます。

入手先

通常は、ServiceNowのタスク関連テーブルにあるstateまたはstageという標準フィールドです。

保留中作業中テスト待ち完了してクローズ
開発アイテムの種類
DevelopmentItemType
作業アイテムの分類です。Feature、Bug、Technical Debt、Taskなどがあります。
説明

SDLCプロセスを通過するさまざまな作業の種類を区別する属性です。たとえば、重大なバグを修正するプロセスは、新機能を開発するプロセスとは異なり、より速く進む場合があります。

作業アイテムの種類に基づいてプロセスを分析すると、パフォーマンスをより細かく把握できます。バグは新機能より手戻り率が高いか、技術的負債の削減にかかるサイクルタイムは許容範囲か、といった問いに答えられます。この分類により、すべての作業を一律に扱うプロセスビューよりも深い分析が可能になります。

重要な理由

機能やバグなど、異なる種類の作業を区別します。作業の種類によって、プロセス経路、優先度、想定所要時間が異なる場合があります。

入手先

レコードのソーステーブル(rm_storyとrm_bugなど)や、汎用タスクテーブルのtypeフィールドから判定できます。

機能バグTask調査
コミットID
CommitId
開発作業に関連付けられたソースコードコミットの一意の識別子です。
説明

開発アイテムを、Gitなどのソースコードリポジトリ内にある特定のコード変更へ直接結び付ける属性です。Code Committedアクティビティの発生時に記録されます。

プロセスマイニングでは、Commit IDによってプロセスデータとエンジニアリングデータを関連付け、分析を深められます。問題のあるデプロイを正確なコード変更まで追跡したり、コードの複雑度指標と開発サイクルタイムを関連付けたりできます。根本原因分析に、より技術的で詳細な視点を加えられます。

重要な理由

プロセスイベントを特定のコード変更に関連付け、プロセス指標とコードレベルの詳細を相関させた、より深い根本原因分析を可能にします。

入手先

GitやSVNなどのソースコード管理システムとServiceNow DevOpsを連携することで取得されます。データは、開発アイテムに関連付けられた関連テーブルに保存されます。

a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
デプロイステータス
DeploymentStatus
デプロイアクティビティの結果を示します。通常はSuccessまたはFailureです。
説明

特定の環境へのデプロイ結果を記録する属性です。リリースプロセスの信頼性と安定性を把握するうえで重要な情報です。

Deployment Success and Failure TrendsダッシュボードとDeployment Failure Rate KPIに欠かせません。デプロイ失敗の頻度や傾向を分析することで、テスト、インフラ、リリース調整に潜む問題を特定できます。ソフトウェア提供の品質と信頼性を高める取り組みを、必要な箇所に集中させるのに役立ちます。

重要な理由

デプロイアクティビティの成否を直接測定し、デプロイ失敗率の算出やリリースの安定性分析に役立ちます。

入手先

通常は、ServiceNow DevOpsと連携したデプロイ追跡タスクまたはCI/CDパイプラインの実行レコードに記録されます。

成功失敗警告ありで完了
手戻り理由
ReworkReason
テスト後に開発アイテムで手戻りが必要になった理由の分類または説明です。
説明

アイテムがQAまたはUATに失敗した場合に、その理由を記録する属性です。特定のバグ分類、要件の認識違い、環境上の問題などが該当します。

Rework and Rejection Flow Analysisダッシュボードに重要な背景情報を提供します。手戻りが発生したという事実だけでなく、その理由まで把握できます。要件定義の改善、単体テストの強化、テスト環境の安定化など、手戻り率を下げるための具体的な改善につなげられます。

重要な理由

手戻りが発生する理由を定性的に把握し、品質向上と手戻りの繰り返し削減に向けた、対象を絞ったプロセス改善を可能にします。

入手先

テスト失敗時にclose_notesフィールドへ記録するか、専用のrework_reasonカスタムフィールドに保存する場合があります。ServiceNow DevOpsのドキュメントを確認してください。

要件の誤解釈リグレッションバグパフォーマンステスト失敗UI/UXの問題
終了時刻
EventEndTime
アクティビティが完了した時点を示す正確なタイムスタンプです。瞬時に完了するイベントでは、開始時刻と同じ値になります。
説明

開発ライフサイクル内の各アクティビティが完了した日付と時刻を示す属性です。Code Review PerformedやQA Testingなど、所要時間を測定できるアクティビティで特に役立ちます。

プロセスマイニングで開始時刻と終了時刻の両方を使うと、アクティビティの処理時間を正確に算出し、アクティビティ間の待機時間と区別できます。遅延の原因がタスク自体の長時間化なのか、リソース待ちなのかを特定するのに役立ちます。Build Triggeredなど瞬時に発生するイベントでは、終了時刻を開始時刻と同じ値にできます。

重要な理由

アクティビティの処理時間を正確に算出できるため、作業に費やした時間と待機に費やした時間を区別できます。

入手先

別途算出が必要になる場合があります。次のアクティビティの開始時刻を使うことも、ソースシステムにend dateフィールドがあれば、その値を使うこともできます。

2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
計画リリースバージョン
PlannedReleaseVersion
開発アイテムの提供を予定しているソフトウェアリリースまたはバージョンです。
説明

開発アイテムをVersion 2.3やQ4 2023 Releaseなど、特定の計画済みリリースに関連付ける属性です。プロジェクト管理とリリース計画における重要な要素です。

プロセスマイニングでは、Release Plan Adherence Monitoringダッシュボードに欠かせません。実際の完了日と計画上のリリース日を比較することで、スケジュール遵守状況を測定し、リリースに間に合わないリスクのあるアイテムを特定し、リリース遅延の原因を分析できます。詳細な開発プロセスと上位のビジネス目標を直接結び付けます。

重要な理由

開発作業を特定のリリースに結び付け、スケジュール遵守状況や、プロセス遅延がリリース日程に与える影響を分析できます。

入手先

通常はreleaseまたはplanned_releaseフィールドに保存され、ServiceNowのリリース管理テーブルを参照します。ServiceNow DevOpsのドキュメントを確認してください。

v3.4.12024年第1四半期リリースProject Phoenixの本番稼働
必須 推奨 任意

ソフトウェア開発ライフサイクルのアクティビティ

正確なプロセス発見と最適化のために、イベントログに記録する主要なプロセス手順とマイルストーンです。
7 推奨 9 任意
アクティビティ 説明
QAテストを完了
品質保証チームが開発項目のテストを正常に完了したことを示します。通常は、項目の状態がテストフェーズから「Ready for UAT」や「Done」などのステータスに移った時点で推定します。
重要な理由

主要な品質ゲートの完了を示すマイルストーンです。ユーザー受け入れテストやリリース準備など、後続ステージの前提となります。

入手先

テスト中のステータス(例:「In QA」)から、テスト後のステータス(例:「Ready for UAT」または「Resolved」)へ状態が変更された時刻から推定します。

取得

状態が「Testing」から後続の状態に変更された時刻に基づきます。

イベントタイプ inferred
UATを承認
ユーザー受け入れテスト後、ビジネス関係者が開発項目を正式に承認したことを示します。「In UAT」から「Ready for Release」または「Approved」へ移るなど、ステータス変更から推定される重要なマイルストーンです。
重要な理由

項目を本番環境へのデプロイに進める前の、最終的なビジネス承認です。品質とガバナンスに関わる重要なチェックポイントです。

入手先

UATの正常な完了を示す開発項目レコードの状態遷移から推定します。項目のアクティビティ履歴に記録されます。

取得

「UAT」から承認済みまたはリリース可能な状態への変更から推定します。

イベントタイプ inferred
コードレビューを実施
通常はPull RequestまたはMerge Requestに関連付けられた、ピアコードレビューの完了を示します。DevOps連携を通じて明示的に取得するか、関連レコードのステータス変更から推定できます。
重要な理由

重要な品質ゲートです。所要時間を分析することで、SDLCで遅延の原因になりやすいレビュー工程のボトルネックを特定できます。

入手先

ServiceNowのGit連携におけるPull Requestレコードの「Merged」または「Completed」イベントから取得できます。または、開発項目のステータスが「Code Review Complete」に変更されたことから推定できます。

取得

作業項目に関連付けられたPull Requestがマージされた時点で記録されます。

イベントタイプ explicit
デプロイに失敗
開発項目の本番環境へのデプロイが失敗したことを示します。CI/CDパイプラインが失敗を報告した時点で、ServiceNow DevOpsが明示的に取得します。
重要な理由

重大な失敗終了点です。頻度と原因を分析することは、リリースの安定性を高め、デプロイ失敗率を下げるうえで重要です。

入手先

Pipeline Execution [sn_devops_pipeline_execution]レコードの「completion_status」から取得します。終了時刻の「Failed」ステータスがこのイベントを示します。

取得

本番環境へのデプロイパイプラインが失敗ステータスを報告した時点で記録されます。

イベントタイプ explicit
本番環境にデプロイ
本番環境へのデプロイが正常に完了したことを示します。CI/CDツールがパイプラインの正常終了を報告した時点で、ServiceNow DevOpsが明示的に取得します。
重要な理由

SDLCプロセスにおける主な成功終了点です。バリューストリームを完了し、総サイクル時間を計算するうえで欠かせません。

入手先

Pipeline Execution [sn_devops_pipeline_execution]レコードまたは関連するStage Execution Runの「completion_status」から取得します。終了時刻の「Success」ステータスがこのイベントを示します。

取得

本番環境へのデプロイパイプラインが正常に完了した時点で記録されます。

イベントタイプ explicit
開発を開始
開発者が開発項目のコーディングまたは実装を実際に開始した時点を示します。通常は、項目のステータスが「In Progress」、「Development」、「Coding」などに変更されたことから推定します。
重要な理由

価値を生み出す構築フェーズの開始を示す重要なマイルストーンです。開発者のリードタイムやコードレビューのサイクル時間を測定するうえで欠かせません。

入手先

開発項目レコード(例:Story [rm_story])の「State」フィールドが「In Progress」または同等のステータスに更新された時刻から推定します。

取得

状態が「In Progress」または同様の値に変更された時刻に基づきます。

イベントタイプ inferred
開発項目を作成
このアクティビティは、ServiceNow内でストーリー、バグ、エピックなどの新しい開発項目が作成されたことを示します。通常は、Story [rm_story]テーブルなどの該当テーブルに新しいレコードが挿入された時点で、イベントとして明示的に記録されます。
重要な理由

SDLCプロセスの主な開始イベントです。エンドツーエンドの総サイクル時間を測定し、初期の需要受付を追跡できます。

入手先

Story [rm_story]、Epic [rm_epic]、Defect [rm_defect]など、開発関連テーブルにレコードが作成された時点で、sys_auditまたはsys_history_lineテーブルに記録されます。作成時刻は通常、レコード自体に保存されています。

取得

開発項目レコードの作成時刻から取得します。

イベントタイプ explicit
QAテストを開始
正式な品質保証テストフェーズの開始を示します。ほとんどの場合、開発項目の状態が「In QA」、「Testing」、「Ready for Test」などに変更されたことから推定します。
重要な理由

開発チームからQAチームへの引き継ぎを示すアクティビティです。テストフェーズの所要時間を測定し、テストキャパシティのボトルネックを特定できます。

入手先

開発項目レコード(例:Story、Defect)の「State」フィールドがQA固有のステータスに更新された時刻から推定します。

取得

状態が「Testing」または同等の値に変更された時刻に基づきます。

イベントタイプ inferred
UATを開始
ビジネス関係者が機能を検証するユーザー受け入れテストの開始を示します。ステータスが「UAT」、「In UAT」、「User Acceptance Testing」などに変更されたことから推定します。
重要な理由

開発した機能がビジネス要件を満たしていることを確認する重要なフェーズです。所要時間を分析することで、ユーザーの関与や要件との不一致に関する問題を明らかにできます。

入手先

開発項目レコードの状態遷移から推定します。顧客の状態モデルにUAT専用のステータスが含まれていることが前提です。

取得

状態が「UAT」ステータスに変更されたことから推定します。

イベントタイプ inferred
コードをコミット
開発者が、開発項目に関連付けられたバージョン管理システムのリポジトリにコードをコミットしたことを示します。ServiceNow DevOpsは、GitやGitHubなどの連携済みSCMツールから、これらのイベントを明示的に取得します。
重要な理由

コミットを追跡することで、開発の進捗とアクティビティの頻度を詳細に把握できます。個々のコード変更を親開発項目と関連付ける際にも役立ちます。

入手先

連携されたソースコード管理システムからのWebhookによって登録される、ServiceNow DevOpsのCommits [sn_devops_commit]テーブルの明示的なイベントとして取得します。

取得

SCMツールからコミットのWebhookを受信した時点で記録されます。

イベントタイプ explicit
ビルドを開始
通常はコードコミットをきっかけに開始されるCI/CDパイプラインのビルド開始を示すイベントです。ServiceNow DevOpsは、発生元の開発項目に関連付けたパイプライン実行として記録します。
重要な理由

このアクティビティは、開発と自動テストまたはデプロイの間をつなぎます。コミットからビルド開始までの時間を分析することで、CI/CDプロセスの遅延を明らかにできます。

入手先

連携されたCI/CDツール(例:Jenkins、Azure DevOps)でビルドが開始された時点に、Pipeline Execution [sn_devops_pipeline_execution]テーブルへ明示的に記録されます。

取得

Pipeline Executionテーブルのレコードの開始時刻から取得します。

イベントタイプ explicit
リリースに向けて準備完了
開発項目がすべての品質ゲートを通過し、特定のリリースに組み込まれたことを示します。項目がReleaseレコードに関連付けられた時点、またはステータスが「Ready for Deployment」に変更された時点から推定できます。
重要な理由

項目が技術面と機能面の両方で完了したことを示すステップです。この状態にとどまった時間は、予定されたデプロイ時間帯までのキュー時間を表す場合があります。

入手先

「State」フィールドが「Ready for Release」に変更されたこと、または開発項目レコードの「Release」フィールドが入力・更新された時点を追跡して推定します。

取得

ステータスの変更、またはReleaseレコードとの関連付けから推定します。

イベントタイプ inferred
手戻りを特定
テスト中に問題が見つかり、項目を開発に戻す必要が生じたことを示します。たとえば、ステータスが「In QA」から「In Progress」に戻るなど、プロセスフローが後戻りしたことから推定します。
重要な理由

手戻りを追跡することは、品質上の問題とプロセスの非効率を把握するうえで欠かせません。このアクティビティの頻度が高い場合、開発または要件の明確さに問題がある可能性があります。

入手先

sys_auditまたはsys_history_lineテーブルにある「State」フィールドの履歴を分析して推定します。後のステージのステータス(例:「Testing」)から前のステージ(例:「In Progress」)への変更は、手戻りを示します。

取得

「Testing」→「In Progress」など、ステータスが後戻りした遷移から推定します。

イベントタイプ inferred
本番環境へのデプロイを開始
本番環境へのデプロイパイプラインが開始されたことを示します。ServiceNow DevOpsは、CI/CDパイプラインの本番ステージが実行を開始した時点で、明示的なイベントとして取得します。
重要な理由

ライフサイクルの最終段階で、多くの場合最も重要なフェーズの開始を示します。追跡することで、デプロイ時間を分析し、自動化の機会を特定できます。

入手先

本番環境に関連するステージに絞り込み、Stage Execution Run [sn_devops_stage_execution]テーブルに明示的に記録されます。

取得

Pipeline Executionにおける本番デプロイステージの開始時刻から取得します。

イベントタイプ explicit
設計を開始
開発項目の技術設計またはソリューションアーキテクチャを作成するフェーズを示します。通常は、開発項目レコードのステータスまたは状態フィールドが「Design」や「Solutioning」などの値に変わったことから推定します。
重要な理由

設計フェーズの所要時間を分析することで、開発作業の開始前に、要件の設計への落とし込みやソリューション計画におけるボトルネックを特定できます。

入手先

開発項目レコード(例:Story [rm_story])の状態遷移から推定します。「State」またはカスタムの「Stage」フィールドが、設計に関連する値へ変更された箇所を確認します。

取得

ステータスが「Design」または同様の状態に変更されたことから推定します。

イベントタイプ inferred
開発項目をキャンセル
開発項目が完了前に終了したことを示します。通常は、項目の状態が「Cancelled」または「Closed Incomplete」に設定されたことから推定される、別の終了状態です。
重要な理由

キャンセルを追跡することで、無駄になった作業を特定し、スコープ変更や優先順位の見直しの理由を把握できます。プロセスで起こり得るすべての結果を、より正確に把握できます。

入手先

開発項目レコードの「State」フィールドが「Cancelled」など、完了を示さない終端ステータスに更新された時刻から推定します。

取得

状態が「Cancelled」または同等の終端状態に変更されたことから推定します。

イベントタイプ inferred
推奨 任意

抽出ガイド

ServiceNow DevOpsからデータを取得する方法

今すぐ始めませんか?

本日からソフトウェア開発ライフサイクルの変革を始めてください。このデータテンプレートで、見えにくい非効率を見つけ出し、継続的な改善につなげられます。

先延ばしにせず、今日からソフトウェア開発ライフサイクルを最適化

非効率な箇所を特定し、SDLCのサイクルタイムを30%以上短縮できます。

無料トライアルを開始

クレジットカード不要で、今日から最適化を始められます