ソフトウェア開発ライフサイクルのデータテンプレート
ソフトウェア開発ライフサイクルのデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- ServiceNow DevOpsからの抽出方法
ソフトウェア開発ライフサイクルの属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 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の本番稼働 | |||
ソフトウェア開発ライフサイクルのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 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 | |||
抽出ガイド
ステップ
- 状態モデルを理解する:レポートを作成する前に、開発項目の状態フィールド(Story
[rm_story]テーブルやDefect[rm_defect]テーブルなど)で使用されている値のうち、必要なアクティビティに対応する値を文書化します。たとえば、「In Progress」という状態値を「Development Started」アクティビティに対応付ける場合があります。 - レポート作成画面に移動する:ServiceNowインスタンスにログインします。フィルターナビゲーターで
Reports > View / Runに移動し、Create a reportボタンをクリックします。 - 状態変更用のレポートを作成する:状態に基づくアクティビティを取得する最初のレポートを作成します。次のように設定します:
- レポート名:
ProcessMind - State Change Events - ソースの種類:
Table - テーブル:
Audit [sys_audit] - 種類:
List - 列を設定:
Document key、Created on、Table name、Field name、Old value、New valueを追加します。 - フィルター:
Table nameを開発項目のテーブル(例:Story)のいずれかに設定し、Field nameを状態フィールド(例:State)に設定します。Created onフィールドに対象期間の日付フィルターを追加します。
- レポート名:
- 項目作成用のレポートを作成する:初回作成イベント用の新しいレポートを作成します。
- レポート名:
ProcessMind - Item Creation Events - ソースの種類:
Table - テーブル:
Story [rm_story](または主要な開発項目テーブル) - 種類:
List - 列を設定:
数値、Created on、Assigned to、Priority、Stateなど、必要な属性の列を追加します。 - フィルター:
Created onフィールドに日付フィルターを適用します。
- レポート名:
- コードコミット用のレポートを作成する:コミットに関連する明示的なDevOpsイベント用のレポートを作成します。
- レポート名:
ProcessMind - Commit Events - ソースの種類:
Table - テーブル:
Commit [sn_devops_commit] - 種類:
List - 列を設定:
Work item、Commit time、Authorなどの列を追加します。 - フィルター:
Commit timeフィールドに日付フィルターを適用します。
- レポート名:
- ビルドとデプロイ用のレポートを作成する:前の手順を繰り返し、
Build [sn_devops_build]テーブルとDeployment [sn_devops_deployment]テーブルのレポートを作成します。これらのテーブルには、Build Triggered、Deployment to Production Started、Deployed to Production、Deployment Failedのアクティビティに対応するレコードが含まれています。 - すべてのレポートをエクスポートする:作成した各レポートを個別に実行します。各レポートでコンテキストメニューのアイコン(3つの点または下向き矢印)をクリックし、
Export > CSVまたはExport > Excelを選択します。すべてのファイルを保存します。 - データを結合して変換する:エクスポートしたファイルを表計算ソフトで開くか、データ準備ツールを使用します。すべてのファイルのデータを1つのシートに手動で結合します。必要なイベントログ列(
DevelopmentItem、ActivityName、EventTimeなど)を作成し、ソース列のデータをマッピングします。たとえば、監査レポートのDocument keyとStoryレポートの数値をDevelopmentItem列にマッピングします。 - アクティビティ名をマッピングする:ソースデータを翻訳して
ActivityName列を作成します。状態変更レポートでは、文書化した状態モデルを使い、New valueの値をアクティビティ名に対応付けます。例:「Testing」という状態を「QA Testing Started」に対応付けます。その他のレポートでは、各行に固定のアクティビティ名を割り当てます。例:コミットのエクスポートに含まれるすべての行を「Code Committed」にします。 - 仕上げて保存する:すべての行に固定値を設定した
SourceSystem列とLastDataUpdate列を追加します。すべてのタイムスタンプが統一された形式になっていることを確認します。完成した結合ファイルを1つのCSVとして保存すると、ProcessMindにアップロードできる状態になります。
設定
- 必須テーブル:この抽出に必要な主要テーブルは、推定イベント用の
Audit [sys_audit]、開発項目に対応するテーブル(例:Story [rm_story]、Defect [rm_defect])、およびServiceNow DevOpsの中核テーブルであるCommit [sn_devops_commit]、Build [sn_devops_build]、Deployment [sn_devops_deployment]です。 - 主なフィルター:最も重要なフィルターは日付範囲です。
Created on、Commit time、開始時刻などのタイムスタンプフィールドに対して、すべてのレポートで一貫して適用してください。sys_auditレポートでは、Table name(例:rm_story)とField name(例:state)で絞り込み、関連する状態変更だけにデータを限定することが重要です。 - 日付範囲の推奨:代表性のあるデータセットを確保しながらパフォーマンスへの影響を抑えるため、3~6か月分のデータを抽出することを推奨します。大規模なシステムでは、月単位で抽出することを検討してください。
- 状態モデルの定義:組織の作業項目における状態モデルを明確に把握しておく必要があります。
sys_auditテーブルで取得した状態値を、「QA Testing Started」や「UAT Approved」などの対応する業務アクティビティに正しくマッピングするために必要です。 - 前提条件:抽出を実行するユーザーには、レポートを作成・実行するための
report_userロールまたは同等の権限が必要です。また、前述のDevOpsおよびアプリケーション開発用テーブルへの読み取りアクセス権も必要です。ServiceNow DevOpsプラグインをインストールし、SCMおよびCI/CDツールと連携しておく必要があります。
a サンプルクエリ sql
/*
This extraction method uses the ServiceNow report builder UI. The following sections describe the configuration for each report that must be created and exported.
The exported data must then be manually combined and transformed into a single event log file.
*/
---
-- REPORT 1: Item Creation Events
---
Report_Name: ProcessMind - Item Creation Events
Source_Table: rm_story
Report_Type: List
Columns:
- Number (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- 'Development Item Created' (create a formula or static column for ActivityName)
- Assigned to (maps to AssignedDeveloper)
- Priority (maps to DevelopmentItemPriority)
- State (maps to DevelopmentItemState)
- cmdb_ci (maps to ModuleComponentAffected)
- Type (maps to DevelopmentItemType)
- Assignment group (maps to AssignmentGroup)
Filters:
- sys_created_on ON Last 6 months
---
-- REPORT 2: Inferred State Change Events
---
Report_Name: ProcessMind - State Change Events
Source_Table: sys_audit
Report_Type: List
Columns:
- documentkey (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- newvalue (maps to ActivityName, requires translation)
- user (maps to AssignedDeveloper)
ActivityName_Mapping_Logic (Example):
- WHEN newvalue IS '[Your Design State]' THEN 'Design Started'
- WHEN newvalue IS '[Your In Progress State]' THEN 'Development Started'
- WHEN newvalue IS '[Your QA State]' THEN 'QA Testing Started'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your In Progress State]' THEN 'Rework Identified'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your UAT State]' THEN 'QA Testing Completed'
- WHEN newvalue IS '[Your UAT State]' THEN 'UAT Started'
- WHEN newvalue IS '[Your UAT Approved State]' THEN 'UAT Approved'
- WHEN newvalue IS '[Your Release Ready State]' THEN 'Prepared For Release'
- WHEN newvalue IS '[Your Cancelled State]' THEN 'Development Item Cancelled'
Filters:
- tablename = 'rm_story'
- fieldname = 'state'
- sys_created_on ON Last 6 months
---
-- REPORT 3: Code Commit Events
---
Report_Name: ProcessMind - Commit Events
Source_Table: sn_devops_commit
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- commit_time (maps to EventTime)
- 'Code Committed' (create a formula or static column for ActivityName)
- author.name (maps to AssignedDeveloper)
Filters:
- commit_time ON Last 6 months
---
-- REPORT 4: Build Events
---
Report_Name: ProcessMind - Build Events
Source_Table: sn_devops_build
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime)
- 'Build Triggered' (create a formula or static column for ActivityName)
Filters:
- start_time ON Last 6 months
---
-- REPORT 5: Deployment Events
---
Report_Name: ProcessMind - Deployment Events
Source_Table: sn_devops_deployment
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime for 'Started' activities)
- end_time (maps to EventTime for 'Completed' or 'Failed' activities)
- state (maps to ActivityName, requires translation)
ActivityName_Mapping_Logic:
- WHEN state IS 'in_progress' THEN 'Deployment to Production Started'
- WHEN state IS 'successful' THEN 'Deployed to Production'
- WHEN state IS 'failed' THEN 'Deployment Failed'
Filters:
- start_time ON Last 6 months
- [Filter for production deployments based on your environment configuration]
---
-- Additional events like 'Code Review Performed' may require a separate report
-- on a table like `sn_devops_pull_request` if available and configured.
--- ステップ
- 前提条件:ServiceNowインスタンスへのネットワークアクセスがあり、読み取り権限を持つ専用サービスアカウント(
itilおよびsn_devops.viewerロールが出発点として適しています)が提供されていることを確認します。このユーザーには、rm_story、sys_audit、sn_devops_*スキーマなどのテーブルへのアクセスが必要です。 - ServiceNow ODBCドライバーをインストールする:ServiceNowサポートポータルから、使用するOSに適したServiceNow ODBCドライバーをダウンロードします。提供されているインストール手順に従ってください。
- DSNを設定する:クエリを実行するマシンで、新しいシステムDSN(Data Source Name)を設定します。ODBCデータソースアドミニストレーターでServiceNowドライバーを追加し、インスタンスURL(例:
yourinstance.service-now.com)、ユーザー名、パスワードを設定します。 - SQLクライアントで接続する:DBeaver、Microsoft SQL Server Management Studio(リンクサーバーを使用)、またはODBCライブラリを備えたPythonなどのスクリプト言語を使い、設定したDSN経由でServiceNowに接続します。
- 状態モデルを特定する:クエリを実行する前に、開発項目テーブル(例:
rm_story、rm_defect)のstateフィールドで組織が使用している正確な値を特定する必要があります。提供されているクエリには「In Progress」や「In QA」などの一般的な例が使われているため、実際の値に置き換えてください。 - SQLクエリをカスタマイズする:提供されたSQLクエリをクライアントにコピーします。クエリ冒頭の抽出開始日や、開発ライフサイクルのアクティビティに対応する状態値などのプレースホルダーを変更します。
- クエリを実行する:ODBC接続経由でServiceNowデータベースに対して、完全なSQLクエリを実行します。日付範囲とデータ量によっては、完了までに時間がかかる場合があります。
- データを確認する:クエリが完了したら、返されたデータセットを簡単に確認します。さまざまなアクティビティが含まれていること、
DevelopmentItem、ActivityName、EventTimeなどの主要列に想定どおり値が入っていることを確認してください。 - CSVにエクスポートする:結果セット全体をCSVファイルにエクスポートします。UTF-8でエンコードし、列見出しがProcessMindで必要な属性名(例:
DevelopmentItem、ActivityName、EventTime)と一致していることを確認します。 - アップロードの準備をする:最終CSVファイルの末尾に空の行がなく、
EventTimeとLastDataUpdateの日付形式がProcessMindでサポートされる統一形式(例:YYYY-MM-DD HH:MM:SS)になっていることを確認します。
設定
- 前提条件:DevOpsモジュールが有効なServiceNowインスタンスへのアクセスが必要です。必要なテーブルへの読み取り権限を持つ専用ユーザーアカウントを用意してください。ServiceNow ODBCドライバーをクライアントマシンにインストールし、設定する必要があります。
- ODBCドライバーの設定:接続には、インスタンスURL、ユーザー名、パスワードまたはOAuthトークンが必要です。複雑なクエリを実行する前に、DSN接続をテストしてください。
- 日付範囲のフィルタリング:提供されたクエリには、抽出量を制限するためのプレースホルダー
s.sys_created_on >= '2023-01-01'が含まれています。クエリの実行時間を管理しやすくするため、直近6~12か月など、対象期間を定めて抽出することを強く推奨します。 - 状態モデルのカスタマイズ:推定イベントの精度は、状態モデルに完全に依存します。プレースホルダーの状態値(例:
[Your 'In Progress' State Value]、[Your 'In QA' State Value])を、ServiceNow設定で使用している正確な値に置き換えてください。大文字と小文字は区別されます。 - 作業項目テーブル:このクエリはStoryテーブル(
rm_story)向けに作成されています。組織でDefect(rm_defect)、Enhancement(rm_enhancement)、その他のタスクタイプも使用している場合は、UNION ALLを使って最初のDevItems共通テーブル式(CTE)に追加してください。 - 性能:本番ServiceNowインスタンスに対する直接クエリは、性能に影響する可能性があります。大規模な抽出は、利用の少ない時間帯に実行してください。非常に大きなデータセットでは、
sys_updated_onフィールドに基づく増分抽出を検討してください。
a サンプルクエリ sql
WITH DevItems AS (
-- This CTE selects the base set of development items to analyze.
-- Add other tables like rm_defect or rm_enhancement here using UNION ALL if needed.
SELECT
s.sys_id,
s.number,
s.sys_created_on,
s.sys_updated_on,
s.assigned_to,
s.priority,
s.state,
s.cmdb_ci, -- Module/Component Affected
s.sys_class_name, -- Development Item Type
s.assignment_group,
DATEDIFF(second, s.sys_created_on, s.closed_at) AS cycle_time_seconds
FROM rm_story s
WHERE s.sys_created_on >= '2023-01-01' -- *** Placeholder: Set your desired start date ***
),
StateChanges AS (
-- This CTE unnests the audit trail for state changes, which are used for inferred activities.
SELECT
a.documentkey AS item_sys_id,
a.sys_created_on AS change_time,
a.oldvalue,
a.newvalue,
-- *** Placeholder: Define the numeric order of your states to detect rework. Adjust values and names. ***
CASE a.oldvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS old_state_order,
CASE a.newvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS new_state_order
FROM sys_audit a
WHERE a.tablename = 'rm_story' AND a.fieldname = 'state'
)
-- 1. Development Item Created
SELECT
i.number AS DevelopmentItem,
'Development Item Created' AS ActivityName,
i.sys_created_on AS EventTime,
'ServiceNow DevOps' AS SourceSystem,
GETDATE() AS LastDataUpdate,
us.name AS AssignedDeveloper,
i.priority AS DevelopmentItemPriority,
i.state AS DevelopmentItemState,
ci.name AS ModuleComponentAffected,
i.sys_class_name AS DevelopmentItemType,
grp.name AS AssignmentGroup,
i.cycle_time_seconds AS DevelopmentItemCycleTime,
CAST(0 AS BIT) AS IsRework
FROM DevItems i
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id
LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id
LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 2. Design Started
SELECT i.number, 'Design Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Design'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 3. Development Started
SELECT i.number, 'Development Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In Progress'' State Value]' AND sc.old_state_order < 3 -- *** Placeholder: Adjust state value and order ***
UNION ALL
-- 4. Code Committed
SELECT i.number, 'Code Committed', c.committed_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_commit c JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 5. Build Triggered
SELECT i.number, 'Build Triggered', b.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_build b JOIN sn_devops_commit_build cb ON b.sys_id = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 6. Code Review Performed
SELECT i.number, 'Code Review Performed', pr.closed_at, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_pull_request pr JOIN DevItems i ON pr.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE pr.state = 'merged' -- Or 'closed', depending on process
UNION ALL
-- 7. QA Testing Started
SELECT i.number, 'QA Testing Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In QA'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 8. Rework Identified
SELECT i.number, 'Rework Identified', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(1 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.new_state_order < sc.old_state_order AND sc.new_state_order > 1 -- Moved to an earlier state
UNION ALL
-- 9. QA Testing Completed
SELECT i.number, 'QA Testing Completed', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In QA'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 10. UAT Started
SELECT i.number, 'UAT Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In UAT'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 11. UAT Approved
SELECT i.number, 'UAT Approved', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In UAT'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 12. Prepared For Release
SELECT i.number, 'Prepared For Release', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Ready for Release'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 13. Deployment to Production Started
SELECT i.number, 'Deployment to Production Started', se.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' -- *** Placeholder: Adjust stage name ***
UNION ALL
-- 14. Deployed to Production
SELECT i.number, 'Deployed to Production', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'SUCCESS' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 15. Deployment Failed
SELECT i.number, 'Deployment Failed', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'FAILURE' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 16. Development Item Cancelled
SELECT i.number, 'Development Item Cancelled', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Cancelled'' State Value]'; -- *** Placeholder: Adjust state value *** 今すぐ始めませんか?
本日からソフトウェア開発ライフサイクルの変革を始めてください。このデータテンプレートで、見えにくい非効率を見つけ出し、継続的な改善につなげられます。
先延ばしにせず、今日からソフトウェア開発ライフサイクルを最適化
非効率な箇所を特定し、SDLCのサイクルタイムを30%以上短縮できます。
クレジットカード不要で、今日から最適化を始められます