ソフトウェア開発ライフサイクルのデータテンプレート
ソフトウェア開発ライフサイクルのデータテンプレート
- 収集を推奨する属性
- 追跡する主なアクティビティ
- ServiceNow DevOpsからのデータ抽出手順
ソフトウェア開発ライフサイクルの属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 「Development Started」や「Code Review Performed」など、発生した開発ライフサイクル上のイベント名です。 | ||
| 説明 ソフトウェア開発ライフサイクルで完了した各節目やTaskの名前を記録する属性です。作成からデプロイまで、これらのアクティビティがプロセスの順序を構成します。 アクティビティの順序や頻度の分析は、プロセスマイニングの主な機能です。プロセスマップの作成、工程間のボトルネックの特定、標準に準拠しないプロセスや非効率なプロセスのバリアントの発見に役立ちます。定義済みのアクティビティには、設計、開発、テスト、デプロイなどの主要な工程が含まれます。 重要な理由 プロセスマップの各工程を定義します。プロセスの流れを分析し、ボトルネックや標準SDLCからの逸脱を特定できます。 入手先 通常、ステータスの変更、イベントレコード、監査証跡の記録を、標準化されたアクティビティ名に対応付けて導出します。たとえば、「state」フィールドが「In Progress」に変わった場合、「Development Started」に対応付けられます。 例 開発の開始コードのコミットQAテストの完了本番環境へのデプロイ完了 | |||
| 開始時刻 EventTime | 特定のアクティビティやイベントが発生した時刻を示す、正確なタイムスタンプです。 | ||
| 説明 開発ライフサイクルの各アクティビティが記録された日時を示す属性です。イベントを時系列に並べ、時間に基づく分析を行うために欠かせません。 プロセスマイニングでは、開始時刻を使ってアクティビティ間の所要時間を算出し、待ち時間を特定し、プロセス全体のサイクルタイムを測定します。SDLCのエンドツーエンド・サイクルタイム分析など、パフォーマンスを分析するダッシュボードや、コードレビューのリードタイムなどの重要業績評価指標の算出にも欠かせない項目です。 重要な理由 イベントを正しい順序に並べ、サイクルタイム、所要時間、待ち時間など、すべてのパフォーマンス指標を算出するために必要なタイムスタンプです。 入手先 通常、監査証跡やTaskテーブルにある「sys_updated_on」や「sys_created_on」など、システムが生成するタイムスタンプフィールドに記録されています。 例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z | |||
| 開発項目 DevelopmentItem | 機能、バグ、Taskなど、開発ライフサイクルを通じて進行する個々の作業を識別する一意のIDです。 | ||
| 説明 開発項目は、追跡対象となる個々の作業を表す主要なケース識別子です。構想や計画の開始から開発、テスト、デプロイまで、その項目に関するすべてのアクティビティを関連付けます。 プロセスマイニング分析では、この属性を使って各作業項目のエンドツーエンドの進行状況を再構成します。プロセスフローの可視化、サイクルタイム全体の算出、個々の機能やバグ修正におけるプロセスのバリアントの特定が可能になります。一貫性のあるプロセスマップを作成するには、ログ内のすべてのイベントを開発項目に関連付ける必要があります。 重要な理由 関連するすべての開発アクティビティを1つのプロセスインスタンスに結び付ける基本の識別子です。これにより、各作業項目のライフサイクル全体を分析できます。 入手先 通常、ストーリー、バグ、Taskを管理するテーブルの主キーです。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」などがあります。 | ||
| 説明 事業上の緊急度に基づいて開発項目を分類する属性です。優先度を設定すると、チームは重要度の高いTaskに集中しやすくなります。また、SLAや関係者の期待を管理する際にもよく使われます。 プロセスマイニングでは、優先度を比較分析の軸として使います。プロセスマップを絞り込み、優先度の高い項目がより速い経路や異なる経路をたどるかを確認できます。「優先度の高い機能の納品時間」ダッシュボードや重要業績評価指標にも欠かせません。重要な項目の処理が実際に速められているかを検証できます。 重要な理由 優先度別にプロセスを絞り込んで比較し、優先度の高い項目がより速く効率的に処理されているかを確認できます。 入手先 ServiceNowのタスク関連テーブルにある標準フィールドで、多くの場合「priority」という名前が付いています。 例 1 - 重大2 - 高3 - 中4 - 低 | |||
| 影響を受けるモジュール／コンポーネント ModuleComponentAffected | 開発項目に関連する特定のソフトウェアモジュール、アプリケーション、またはコンポーネントです。 | ||
| 説明 この属性は、システムのどの部分に影響するかに基づいて開発作業を分類します。特定のマイクロサービス、UIコンポーネント、バックエンドアプリケーションなどが該当します。 モジュールやコンポーネントごとにプロセスを分けて分析することは、局所的なボトルネックの特定に欠かせません。「コンポーネント別のボトルネック分析」ダッシュボードと「コンポーネント別の平均ステージ所要時間」KPIでは、この属性を使って、コードベースの特定の部分が開発サイクルの長期化、手戻り率の上昇、デプロイ失敗の増加と継続的に関連しているかを特定します。これにより、改善が必要な箇所に取り組みを集中できます。 重要な理由 アプリケーションやコンポーネントごとに分析を分け、システムの特定部分に固有のボトルネックや品質上の問題を特定できます。 入手先 カスタムフィールド、または構成管理データベース（CMDB）への参照であることが多く、作業項目を「cmdb_ci」レコードに関連付けます。ServiceNow DevOpsの文書をご確認ください。 例 請求サービスユーザー認証UIレポーティングデータベースAPIゲートウェイ | |||
| 手戻りかどうか IsRework | アクティビティが手戻りのループに含まれる場合にtrueとなる真偽値フラグです。テスト後に開発へ戻る場合などが該当します。 | ||
| 説明 この派生属性は、プロセスが前の段階に戻った後に発生したアクティビティを特定します。たとえば、同じ項目で「QAテスト完了」の後に「開発開始」が発生した場合、手戻りとしてフラグが設定されます。 このフラグは、手戻りの定量化と可視化に欠かせません。「手戻りと差し戻しのフロー分析」ダッシュボードを支え、「テスト後の手戻り率」KPIの算出にも使われます。イベントにフラグを付けることで、手戻りの頻度や原因、サイクルタイム全体への影響を簡単に絞り込んで分析できます。 重要な理由 このフラグを使うと手戻りを定量化して分析しやすくなり、プロセスの品質測定や、作業が繰り返される根本原因の特定に役立ちます。 入手先 この属性は、各ケースのアクティビティの順序を分析し、プロセスフローの逆戻りを検出することで、プロセスマイニングツール内で算出されます。 例 truefalse | |||
| 担当グループ AssignmentGroup | アクティビティ発生時点で開発項目を担当しているチームまたはグループです。 | ||
| 説明 この属性は、作業項目に割り当てられたチームを示します。「フロントエンド開発」「バックエンドサービス」「QAチーム」などが該当します。作業項目の進行に伴い、担当グループ間で引き継がれることもよくあります。 担当グループを追跡すると、部門をまたぐ連携や引き継ぎの状況を把握できます。作業がチーム間を移る際に発生する、組織的な遅延の特定にも役立ちます。この属性を使って、チームごとのパフォーマンスや作業負荷を分析し、全体の流れを滞らせているチームを特定できます。 重要な理由 作業の担当チームを追跡し、チームのパフォーマンスや作業負荷の配分、チーム間の引き継ぎの効率を分析できます。 入手先 この情報は「assignment_group」フィールドに保存されます。ServiceNowのタスク関連テーブルにある標準フィールドです。 例 プラットフォームエンジニアリングモバイルアプリチーム品質保証DevOps | |||
| 担当開発者 AssignedDeveloper | アクティビティの発生時点で開発項目を担当していた開発者またはユーザーの名前やIDです。 | ||
| 説明 特定のTaskやアクティビティの実行を担当する個人を示す属性です。開発項目が異なる工程やチームに移ると、担当者も変わることがあります。 リソースの割り当て、作業負荷、引き継ぎを分析するうえで重要な属性です。「開発者の作業負荷と引き継ぎ」ダッシュボードや「開発者ごとのアクティビティ件数」の重要業績評価指標に利用できます。このフィールドの変更を追跡すると、引き継ぎにかかる時間を測定し、開発者間や開発チームとQAチーム間の連携におけるボトルネックを特定できます。 重要な理由 作業負荷の分布や引き継ぎの効率を分析し、チームごとのパフォーマンス傾向を特定するなど、リソースに基づく分析に欠かせません。 入手先 通常、ServiceNowのTask関連テーブルにある「assigned_to」フィールドに保存されています。 例 デビッド・ミラーアンナ・ウィリアムズジェームズ・ブラウン | |||
| 開発項目のサイクルタイム DevelopmentItemCycleTime | 開発項目の作成から最終的なクローズまたはデプロイまでにかかった合計時間です。 | ||
| 説明 この属性は、1つの開発項目にかかった開始から終了までの時間を表す計算指標です。各ケースの最初のアクティビティと最後のアクティビティのタイムスタンプの差から算出します。 SDLCプロセス全体を測る主要な重要業績評価指標であり、「SDLCの平均サイクルタイム」KPIに直接利用されます。プロセス全体の速度と効率を把握できます。この指標を時間の経過や、優先度、チームなどの切り口で分析すると、プロセス改善の取り組みがもたらした変化を追跡できます。 重要な理由 作業項目の開始から終了までにかかった合計時間を示します。プロセス全体の効率と速度を測る主要な指標です。 入手先 ソースシステムのフィールドではありません。プロセスマイニングツールで、各ケースの最小StartTimeから最大StartTimeを差し引いて算出します。 例 15日4時間3日12時間32日8時間 | |||
| 開発項目の状態 DevelopmentItemState | イベント発生時点での開発項目のステータスまたは状態です。「未着手」「進行中」「完了」などが該当します。 | ||
| 説明 この属性は、ServiceNowにおける開発項目の正式なステータスを示します。アクティビティがプロセスから導き出されるステップであるのに対し、状態はシステム上の正式な段階を表します。 状態は、アクティビティを導き出す際の情報源となることがよくあります。データの検証や、プロセスを簡潔に把握するための概要表示に利用できます。たとえば、各状態にかかった時間を分析すると、アクティビティ間の時間を分析する場合とは異なる視点でボトルネックを把握できます。また、停滞している項目や解決済みの項目を特定する際にも役立ちます。 重要な理由 作業項目の正式なシステム上のステータスを示します。アクティビティの導出元となることが多く、データの検証やステータスの概要分析にも利用できます。 入手先 ServiceNowのタスク関連テーブルにある標準フィールドで、通常は「state」または「stage」という名前が付いています。 例 保留中作業中テスト準備完了完了してクローズ | |||
| 開発項目の種類 DevelopmentItemType | 作業項目の分類です。「機能」「バグ」「技術的負債」「Task」などが該当します。 | ||
| 説明 この属性は、SDLCプロセスを進む作業の種類を区別します。たとえば、重大なバグの修正と新機能の開発では、プロセスが異なり、修正のほうが短期間で完了する場合があります。 作業項目の種類ごとにプロセスを分析すると、パフォーマンスをより詳しく把握できます。「バグの手戻り率は新機能より高いか」「技術的負債の削減にかかるサイクルタイムは許容範囲か」といった問いに答えるのに役立ちます。このように分類することで、すべての作業を一律に扱う場合よりも深いインサイトが得られます。 重要な理由 機能やバグなど、作業の種類を区別します。種類によって、プロセスの経路、優先度、想定所要時間が異なる場合があります。 入手先 レコードのソーステーブル（例：「rm_story」と「rm_bug」）から判別するか、汎用タスクテーブルの「type」フィールドから判別できます。 例 機能バグTask技術検証 | |||
| コミットID CommitId | 開発作業に関連するソースコードのコミットを一意に識別するIDです。 | ||
| 説明 この属性を使うと、開発項目からGitなどのソースコードリポジトリ内の特定のコード変更に直接たどれます。「コードのコミット」アクティビティが発生した際に記録されます。 プロセスマイニングでは、コミットIDによってプロセスデータとエンジニアリングデータを関連付け、分析を詳しく行えます。問題のあるデプロイを特定のコード変更までさかのぼったり、コードの複雑さを示す指標と開発サイクルタイムを照合したりできます。これにより、根本原因を技術面からさらに詳しく分析できます。 重要な理由 プロセスイベントを特定のコード変更に関連付け、プロセス指標とコードレベルの詳細を照合して根本原因を詳しく分析できます。 入手先 この情報は、ServiceNow DevOpsとGitやSVNなどのソースコード管理システムとの連携によって記録されます。データは開発項目に関連付けられたテーブルに保存されます。 例 a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f | |||
| デプロイステータス DeploymentStatus | デプロイアクティビティの結果を示します。通常は「成功」または「失敗」です。 | ||
| 説明 この属性には、特定の環境へのデプロイ結果が記録されます。リリースプロセスの信頼性と安定性を把握するために欠かせない情報です。 「デプロイの成功・失敗の推移」ダッシュボードと「デプロイ失敗率」KPIでは、この属性を使用します。デプロイ失敗の頻度や推移を分析することで、テスト、インフラ、リリース調整に潜む問題を特定できます。ソフトウェア納品の品質と信頼性を高めるために、改善が必要な箇所を絞り込めます。 重要な理由 デプロイアクティビティの成否を直接測定します。デプロイ失敗率の算出やリリースの安定性分析に欠かせません。 入手先 このステータスは通常、ServiceNow DevOpsと連携したデプロイ追跡タスクやCI/CDパイプラインの実行記録に保存されます。 例 成功失敗警告ありで完了 | |||
| 手戻りの理由 ReworkReason | テスト後に開発項目の手戻りが必要になった理由を分類または説明する情報です。 | ||
| 説明 項目がQAまたはUATに失敗した場合、この属性に失敗の理由を記録します。特定のバグ分類、要件の誤解、環境上の問題などが該当します。 この情報は、「手戻りと差し戻しのフロー分析」ダッシュボードで状況を把握するために役立ちます。手戻りが発生した事実だけでなく、その理由も分析できます。要件定義の改善、単体テストの強化、テスト環境の安定化など、手戻り率を下げるための具体的な改善につなげられます。 重要な理由 手戻りが発生する理由を定性的に把握し、品質向上と手戻りの繰り返しを減らすための改善に役立てられます。 入手先 テスト失敗時の「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 | 開発項目の納品が予定されているソフトウェアのリリースまたはバージョンです。 | ||
| 説明 この属性は、開発項目を「バージョン2.3」や「2023年第4四半期リリース」など、特定の計画リリースに関連付けます。プロジェクト管理やリリース計画に欠かせない情報です。 プロセスマイニングでは、「リリース計画の遵守状況モニタリング」ダッシュボードにこの属性を使用します。実際の完了日と計画上のリリース日を比較することで、スケジュールの遵守状況を測定し、リリースに間に合わないリスクのある項目を特定して、遅延の原因を分析できます。開発プロセスの詳細と、上位のビジネス目標を直接結び付ける情報です。 重要な理由 開発作業を特定のリリースに関連付け、スケジュールの遵守状況やプロセスの遅延がリリース日程に与える影響を分析できます。 入手先 この情報は通常、「release」または「planned_release」フィールドに保存され、ServiceNowのリリース管理テーブルを参照する場合があります。ServiceNow DevOpsの文書をご確認ください。 例 v3.4.12024年第1四半期リリースプロジェクトPhoenixの本番稼働 | |||
ソフトウェア開発ライフサイクルのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| QAテストの完了 | 品質保証チームが開発項目のテストを完了したことを示します。通常、テスト中の状態から「Ready for UAT」や「Done」などに移行した時点で推定します。 | ||
| 重要な理由 品質を確認する主要なゲートの完了を示す節目です。ユーザー受け入れテストやリリース準備など、次の工程に進むための前提となります。 入手先 テスト中のステータス（例：「In QA」）からテスト後のステータス（例：「Ready for UAT」、「Resolved」）に変わったタイムスタンプから推定します。 記録 「Testing」から次の状態に変わったタイムスタンプに基づきます。 イベントタイプ inferred | |||
| UATの承認 | ユーザー受け入れテスト後に、事業部門の関係者が開発項目を正式に承認したことを示します。「In UAT」から「Ready for Release」や「Approved」に移行するなど、ステータスの変更から推定する重要な節目です。 | ||
| 重要な理由 本番環境へのデプロイが承認される前に行う、事業部門による最終承認です。品質とガバナンスを確認する重要なチェックポイントです。 入手先 UATの正常な完了を示す開発項目レコードの状態遷移から推定します。この情報は項目のアクティビティ履歴に記録されます。 記録 「UAT」から承認済みまたはリリース可能な状態に変わったことから推定します。 イベントタイプ inferred | |||
| コードレビューの実施 | プルリクエストまたはマージリクエストに関連する、ピアコードレビューの完了を示すアクティビティです。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ツールからこれらのイベントを明示的に記録します。 | ||
| 重要な理由 コミットを追跡すると、開発の進捗やアクティビティの頻度を詳しく把握できます。また、個々のコード変更を親となる開発項目に関連付けて分析できます。 入手先 ServiceNow DevOpsのCommits [sn_devops_commit]テーブルにイベントとして明示的に記録されます。このテーブルには、連携済みのソースコード管理システムからWebhookでデータが登録されます。 記録 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 | |||
| 本番環境へのデプロイ開始 | 本番環境へのデプロイパイプラインの開始を示すアクティビティです。CI/CDパイプラインの本番ステージが実行を開始すると、ServiceNow DevOpsにイベントとして明示的に記録されます。 | ||
| 重要な理由 ライフサイクルの最終段階であり、多くの場合、最も重要なフェーズの開始を示します。追跡することで、デプロイにかかる時間を分析し、自動化の機会を特定できます。 入手先 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]などです。たとえば、「進行中」という状態を「開発開始」アクティビティに対応させます。 - レポート作成画面を開く：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]テーブルについて繰り返します。これらのテーブルには、「ビルド開始」「本番環境へのデプロイ開始」「本番環境へのデプロイ完了」「デプロイ失敗」のアクティビティに関するレコードが含まれます。 - すべてのレポートをエクスポートする：作成したレポートを1つずつ実行します。各レポートのコンテキストメニュー（3つの点または下向き矢印）をクリックし、
Export > CSVまたはExport > Excelを選択します。すべてのファイルを保存してください。 - データを結合して変換する：エクスポートしたファイルを表計算ソフトで開くか、データ準備ツールを使います。すべてのファイルのデータを手作業で1つのシートにまとめます。必要なイベントログの列（
DevelopmentItem、ActivityName、EventTimeなど）を作成し、元の列のデータを対応付けます。たとえば、監査レポートのDocument keyとStoryレポートの数値をDevelopmentItem列に割り当てます。 - アクティビティ名を対応付ける：元データを変換して
ActivityName列を作成します。状態変更レポートでは、文書化した状態モデルに基づき、New valueの値をアクティビティ名に対応付けます（例：状態「テスト中」を「QAテスト開始」に対応させます）。その他のレポートでは、各行に固定のアクティビティ名を割り当てます（例：コミットのエクスポートデータの全行を「コードコミット」にします）。 - 仕上げて保存する：すべての行に固定値を設定した
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テスト開始」や「UAT承認」などの業務アクティビティに正しく対応付けるために必要です。 - 前提条件：抽出を行うユーザーには、レポートの作成と実行に必要な
report_userロール、または同等の権限が必要です。また、上記のDevOpsテーブルとアプリケーション開発テーブルへの読み取りアクセスも必要です。ServiceNow DevOpsプラグインをインストールし、SCMおよびCI/CDツールと連携しておく必要があります。
クエリの例 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（データソース名）を設定します。ODBCデータソースアドミニストレーターでServiceNowドライバーを追加し、インスタンスURL（例：
yourinstance.service-now.com）、ユーザー名、パスワードを設定します。 - SQLクライアントで接続する：DBeaverやMicrosoft SQL Server Management Studio（リンクサーバーを使用）などのSQLクライアント、またはODBCライブラリを使うPythonなどのスクリプト言語から、設定したDSNを使ってServiceNowに接続します。
- 状態モデルを確認する：クエリを実行する前に、開発項目テーブル（例：
rm_story、rm_defect）のstateフィールドで組織が使用している値を正確に確認します。クエリには「進行中」や「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）、その他のTaskタイプも使用している場合は、初期のDevItems共通テーブル式（CTE）にUNION ALLで追加してください。 - パフォーマンス：本番環境のServiceNowインスタンスに対する直接クエリは、パフォーマンスに影響する可能性があります。大量のデータを抽出する場合は、利用の少ない時間帯に実行してください。非常に大きなデータセットでは、
sys_updated_onフィールドに基づく増分抽出を検討してください。
クエリの例 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％以上短縮しましょう。
クレジットカードは不要です。今日から最適化を始めましょう。