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

アクティビティ名とは、開発プロセスにおける特定のステップやステータス変更を表すものです。これらのアクティビティはプロセスマップのノードを形成し、「開発承認済」、「レビューのためにコード提出」、「QAテスト完了」のような主要なマイルストーンを表します。

この属性は、プロセスフローを可視化し、イベントの順序を理解するために不可欠です。異なるアクティビティを分析することで、チームは最も一般的な経路を特定し、プロセス逸脱を発見し、様々なステージでの滞在時間を測定できます。これは、ボトルネック分析、手戻り検出、および目標プロセスモデルに対する適合性チェックの基礎となります。

プロセスにおけるステップを定義し、開発ワークフローの可視化と分析を可能にします。

開発作業アイテムに関連するステータス変更ログ、イベントストリーム、または監査履歴テーブルから導き出されることが多いです。

イベント開始時間は、アクティビティが開始された正確な日時を示します。これは、単一ケース内のすべてのイベントの時系列順序を提供し、プロセスフローを正確に再構築するために不可欠です。

タイムスタンプは、すべての時間ベースのプロセスマイニング分析の基礎となります。これらは、サイクルタイム、待機時間、アクティビティ間の処理時間などの主要業績評価指標（KPI）を計算するために使用されます。タイムスタンプを分析することで、ボトルネックを特定し、プロセス効率を測定し、開発ライフサイクルにおける異なるステージの期間を理解するのに役立ちます。例えば、「レビューのためにコード提出」と「コードレビュー完了」の間の時間は、レビュープロセスにおける遅延を明らかにできます。

このタイムスタンプは、イベントを正しく順序付けし、サイクルタイムやボトルネックなど、すべての時間ベースのメトリクスを計算するために不可欠です。

開発作業アイテムへの変更を記録するイベントログ、監査証跡、または履歴テーブルで利用可能です。

開発アイテムIDは、ソフトウェア開発ライフサイクル全体を通じて各ケースインスタンスを一意に識別する主キーです。各IDは、ユーザーストーリー、タスク、バグ修正など、その作成から最終的な解決またはデプロイまでの個別の作業を表します。

プロセスマイニング分析において、この属性は各作業アイテムのエンドツーエンドのジャーニーを再構築するために不可欠です。これにより、ツールは「開発開始」、「コードレビュー完了」、「本番環境にデプロイ済み」のようなすべての関連アクティビティを一貫したプロセスフローとして連結できます。個々の開発アイテムのライフサイクルを分析することで、特定の作業に関連するバリエーション、遅延、手戻りループを特定するのに役立ちます。

これは、各開発作業項目の完全なライフサイクルを最初から最後まで追跡するために必要な、基本的なケース識別子です。

通常、ソフトウェア開発管理システムの主要な作業項目または課題追跡テーブルに存在します。

ソースシステム属性は、開発ライフサイクルデータが記録された元のアプリケーションまたはプラットフォームを識別します。これは、例えば課題追跡にJira、ソースコード管理にGitLabなど、複数の開発ツールが使用されている環境で特に有用です。

分析においてソースシステムを指定することは、データ検証に役立ち、プロセスデータにコンテキストを与えます。これにより、異なるシステムで管理されているプロセス間の比較分析が可能になり、フィールド名やプロセス慣行がシステム間で異なるため、データ解釈が正しいことを保証します。また、分析を特定のツールのデータセットに絞り込むためにも使用できます。

データの起源に関するコンテキストを提供します。これはデータ検証や、複数の統合システムが関わる分析において極めて重要です。

これは通常、データ抽出プロセス中に、レコードの発生源を識別するために追加される静的な値です。

最終データ更新属性は、ソースシステムからデータが最後に抽出または更新された日時を記録します。これにより、データの鮮度と関連性が明確に示されます。

この情報は、分析やダッシュボードが最新の情報に基づいていることを確実にする上で不可欠です。ステークホルダーは、プロセスビューがどれほど最新であるかを一目で確認でき、そこから導き出されるインサイトへの信頼を深めることができます。これは、データパイプラインの管理やデータ更新のスケジュール設定において重要なメタデータです。

データの鮮度を示し、分析がタイムリーで意思決定に関連性があることを保証します。

この値は通常、データ抽出、変換、ロード（ETL）パイプラインによって生成および保存されます。

イベント終了時間は、アクティビティの完了を示します。多くのプロセスステップは開始時間と終了時間が同じ瞬時イベントとして記録されますが、一部のアクティビティには測定可能な期間があります。例えば、「コードレビュー」アクティビティには明確な開始時間と終了時間がある場合があります。

この属性は、特定のタスクのアクティブな処理時間を計算し、アイドル時間や待機時間と区別するために不可欠です。イベント開始時間とイベント終了時間の間の期間を比較することで、アナリストは付加価値活動に費やされた労力を測定できます。これにより、リソース利用のより詳細な分析が可能になり、どのタスクが最も多く実作業時間を消費しているかを特定するのに役立ちます。

個々のアクティビティのアクティブな処理時間を計算し、待機時間と分離することで、作業負荷をより明確に把握できるようにします。

イベントログで見つけることができるか、同じ作業アイテムのシーケンスにおける次のアクティビティのタイムスタンプを取得することで導き出せます。

この属性は、開発項目のデリバリーを担当する特定のチーム、スクワッド、またはグループを識別します。大規模な組織では、作業は「フロントエンド」「バックエンド」「モバイル」「プラットフォーム」などの複数の専門チームに分散されることがよくあります。

チーム名で分析することにより、チーム間のパフォーマンス比較やベストプラクティスの共有が可能になります。これは、「どのチームが最も短いサイクルタイムを持っているか？」や「あるチームは他のチームよりも多くの手戻りを経験しているか？」といった質問に答えるのに役立ちます。この分析により、ワークフロー、スキルセット、またはリソースの可用性の違いが全体的なデリバリーパフォーマンスに影響を与える可能性を明らかにし、ターゲットを絞ったプロセス改善の機会を提供します。

異なるチーム間のパフォーマンスベンチマークを可能にし、ベストプラクティスや改善領域の特定に役立ちます。

多くの場合、割り当てられたユーザーに関連付けられるか、プロジェクトまたは作業アイテム記録上の直接フィールドとして存在します。

プロジェクト名は、特定の製品、イニシアチブ、またはコードベースに属する作業項目をグループ化することで、コンテキストを提供します。例えば、レガシーシステムと新規開発アプリケーションのように、プロジェクトによって開発プラクティスやサイクルタイムは大きく異なる場合があります。

この属性により、組織の異なる部門間での開発プロセスを高レベルで集計し、比較することができます。プロジェクトごとに分析をフィルタリングすることで、管理者は各開発作業の健全性と効率を評価できます。また、プロセスのパフォーマンスがプロジェクトの特定のコンテキストや技術環境にどのように関連しているかを理解するためにも不可欠です。

プロセス分析を製品やプロジェクトごとにセグメント化でき、プロジェクトの状況に応じたパフォーマンスの違いを明らかにします。

作業アイテムまたは課題記録上の標準フィールド、あるいはGitのようなシステムにおけるリポジトリ名です。

この属性は、現在のステップまたは作業項目全体の完了を担当する個人またはグループを識別します。担当者はライフサイクルを通じて何度も変更される可能性があり、開発者、QAテスター、レビュー担当者などの異なる役割間の引き渡しを反映します。

「担当者」属性を分析することは、チームの作業負荷、引き渡しの効率、およびコラボレーションパターンを理解する上で重要です。これにより、プロセスマップをフィルタリングして特定の個人またはチームの作業を表示し、リソース固有のボトルネックを特定するのに役立ちます。担当者間の引き渡しに基づくソーシャルネットワーク分析は、コミュニケーションギャップや過度に複雑なコラボレーション構造を明らかにすることができます。

リソースの作業負荷、引き継ぎの頻度、コラボレーションパターンの分析を可能にし、チームの効率を最適化するのに役立ちます。

作業アイテムまたは課題記録にあり、しばしばアイテムの履歴や監査ログで追跡されます。

開発アイテムステータスは、特定の時点における作業アイテムの状態を表します。アクティビティ名がステータス変更のイベントを捕捉するのに対し、この属性は状態そのものを捕捉します。これは、イベント発生時の作業の状態を分析するのに有用です。

この属性はアクティビティ名を作成するためによく使用されますが、追加のコンテキストを提供できます。例えば、ステータスフィールドを分析することで、「ブロック済み」や「レビュー待ち」のような特定の状態にアイテムがどれくらいの期間滞在しているかの期間分析が可能になります。非生産的な状態での滞在時間を理解することは、システム的な遅延を特定し、フロー効率を向上させる上で極めて重要です。

異なる状態での滞在時間を分析し、遅延や「ブロック済み」のような非付加価値状態での滞在時間を特定するのに役立ちます。

作業アイテムまたは課題記録の主要フィールドとして利用でき、その履歴ログで追跡されます。

この属性は、実行される作業の性質を分類します。異なる種類の作業項目は、多くの場合、異なるプロセスパスをたどり、異なるパフォーマンス期待値を持っています。例えば、「バグ」は迅速なホットフィックスプロセスを必要とするかもしれませんが、「機能」は標準の開発およびテストサイクルに従います。

この属性を使用することで、アナリストは異なる種類の作業のプロセスフローとパフォーマンスを比較できます。これは、「バグ修正プロセスは機能開発プロセスよりも速いか？」や「技術的負債項目はより多くの手戻りを経験するか？」といった疑問に答えるのに役立ちます。これは、より具体的で実用的な洞察を得るためにデータをセグメント化するための基本的な切り口です。

異なる作業カテゴリ間でプロセスとパフォーマンスを比較でき、特定の開発タイプに特有の非効率性を明らかにします。

ほとんどの開発管理システムにおける作業アイテムまたは課題記録上の標準フィールドです。

優先度属性は、作業項目のビジネス上または技術上の緊急度を示します。通常、「高」「中」「低」といった値が設定され、チームが次に何に取り組むかを決定するのに役立ちます。

プロセスマイニングにおいて、優先度は強力な分析の切り口となります。これにより、優先度の高い項目が実際に優先度の低い項目よりも速く処理されているかをチームが確認できます。異なる優先度レベル間のサイクルタイムを比較することで、プロセスがビジネス上の優先度を尊重しているかどうかが明らかになります。優先度の高い項目が頻繁に遅延している場合、それは計画、リソース配分、またはワークフロー設計における問題を示唆している可能性があります。

高優先度の作業がプロセスをより速く進むかを確認し、重要なアイテムに不均衡に影響を与えるボトルネックを特定するのに役立ちます。

ほとんどの開発管理システムにおける作業アイテムまたは課題記録上の標準フィールドです。

作成者属性は、作業アイテムを起票した人物を特定します。これは、ユーザーストーリーを作成したプロダクトマネージャー、バグを記録したQAテスター、または顧客の問題を報告したカスタマーサービスエージェントである可能性があります。

作業アイテムの作成者を分析することで、作業の発生源に関するインサイトが得られます。例えば、エンドユーザーから多数のバグが報告されている場合、最近のリリースに品質問題があることを示唆しているかもしれません。また、作成者と下流工程での手戻りや遅延を関連付けることで、初期要件の明確さや品質を分析するためにも活用できます。

作業の発生元を特定するのに役立ち、需要、バグ、または機能リクエストの発生源を理解するための分析に活用できます。

作業アイテムの初期作成記録にある、「報告者」や「作成者」のような標準フィールドです。

手戻り指標は、イベントが手戻りサイクルの一部であることを示す、派生したブール型またはカテゴリ型の属性です。これは通常、「QAテスト」から「開発中」に戻るなど、プロセスフローが逆行する場合や、「QAで手戻り発生」のような特定の手戻りアクティビティが発生した場合に識別されます。

この属性は、品質と効率の分析にとって極めて価値があります。手戻り率を直接計算し、プロセス内で最も手戻りを発生させている部分を浮き彫りにします。手戻りアクティビティでフィルタリングすることで、チームは品質問題がなぜ早期に発見されないのかを理解するための真因分析を行うことができます。手戻りの削減は、開発速度と製品品質の両方を向上させるための重要な手段となります。

手戻りを直接定量化し、チームがその頻度を測定し、原因を分析し、時間の経過とともに品質改善を追跡できるようにします。

通常、プロセスフロー内の逆行ループや特定の失敗関連アクティビティ名を識別することにより、データ変換中に派生します。

計画リリース属性は、開発項目を特定の納品スケジュールやバージョンに紐付けます。これは、リリース計画において、機能や修正をまとめて調整されたデプロイを行う際によく利用されます。

計画リリースで分析することにより、リリースプロセスの予測可能性と信頼性を評価できます。計画リリースと実際のデプロイ日を比較することで、納期遵守率を追跡することが可能です。さらに、スコープを管理し、特定のリリースに向けた作業の流れを把握するのに役立ち、納品期間に影響を及ぼす可能性のあるリスクや遅延を浮き彫りにします。

開発作業をリリーススケジュールと連携させ、定時デリバリー率とリリース予測可能性の分析を可能にします。

アジャイル計画および開発ツールにおける「修正バージョン」「ターゲットリリース」「イテレーションパス」といった標準フィールドです。

深刻度（Severity）は優先度（Priority）とは異なり、問題の技術的な影響度を測るものです。一方、優先度はその修正の緊急度を測ります。例えば、めったにアクセスされないページの誤字は深刻度も優先度も低いかもしれませんが、重大なデータ破損の問題は深刻度も優先度も高くなります。

この属性は、品質分析、特にバグ修正プロセスを分析する上で極めて重要です。チームが最も深刻な問題を最初に効果的に対処しているかを評価できます。異なる深刻度レベルのサイクルタイムを分析することで、組織は顧客への影響を最小限に抑えるために、重要なシステム問題が迅速に解決されることを確実にできます。

技術的な影響に基づき、チームが問題をどれだけ効果的に対処しているかを分析し、重要な問題が迅速に解決されるようにします。

開発管理システムにおいて、特に「バグ」や「インシデント」タイプの作業アイテムに用いられる標準フィールドです。