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

アクティビティ名は、開発プロセスにおける具体的なステップやステータス変更を表します。これらのアクティビティはプロセスマップのノードとなり、「開発項目の承認」「コードレビューの依頼」「QAテストの完了」などの主要なマイルストーンを示します。

この属性は、プロセスフローを可視化し、イベントの順序を把握するうえで欠かせません。さまざまなアクティビティを分析すると、チームはよくある経路を特定し、プロセス逸脱を見つけ、各工程にかかる時間を測定できます。ボトルネック分析、手戻りの検出、目標プロセスモデルに対する適合性チェックの基礎となります。

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

多くの場合、開発作業項目に関連するステータス変更ログ、イベントストリーム、監査履歴テーブルから取得します。

イベント開始時刻は、アクティビティが始まった正確な日時を示します。1つのケース内にあるすべてのイベントの時系列を把握できるため、プロセスフローを正確に再構成するうえで欠かせません。

タイムスタンプは、時間に基づくプロセスマイニング分析の基礎です。サイクルタイム、待ち時間、アクティビティ間の処理時間など、重要業績評価指標の計算に使われます。タイムスタンプを分析すると、ボトルネックを特定し、プロセスの効率を測定し、開発ライフサイクルの各工程にかかる時間を把握できます。たとえば、「コードレビューの依頼」から「コードレビューの完了」までの時間から、レビュー工程の遅延が分かります。

イベントの順序を正しく並べ、サイクルタイムやボトルネックなど、時間に基づくすべての指標を計算するために必要なタイムスタンプです。

開発作業項目の変更を記録するイベントログ、監査証跡、履歴テーブルで確認できます。

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

プロセスマイニング分析では、この属性を使って各作業項目のエンドツーエンドの流れを再構成します。「開発の開始」「コードレビューの完了」「本番環境への展開」など、関連するすべてのアクティビティを結び付け、一貫したプロセスフローとして表示できます。開発項目ごとのライフサイクルを分析すると、作業ごとのばらつき、遅延、手戻りのループを特定できます。

各開発作業項目の開始から終了までのライフサイクル全体を追跡するために必要な、基本的なケース識別子です。

通常は、ソフトウェア開発管理システムの作業項目または課題を管理するメインテーブルにあります。

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

分析では、ソースシステムを指定することでデータを検証し、プロセスデータの背景を把握できます。異なるシステムで管理されているプロセスを比較できるほか、フィールド名やプロセスの慣例がシステムごとに異なる場合も、データを正しく解釈しやすくなります。特定のツールのデータに絞って分析することもできます。

データの出所を把握するための情報です。データの検証や、複数の連携システムにまたがる分析に役立ちます。

通常は、レコードの出所を識別するため、データ抽出時に追加する固定値です。

最終データ更新日時属性には、ソースシステムからデータを最後に抽出または更新した日時が記録されます。データがどの程度新しく、現在の状況を反映しているかを確認できます。

分析やダッシュボードが最新の情報に基づいているかを確認するうえで役立ちます。関係者はプロセスの状況がいつ時点のものかをすぐに把握でき、分析から得られるインサイトへの信頼につながります。データパイプラインの管理やデータ更新のスケジュール設定にも必要なメタデータです。

データの新しさを示し、意思決定に間に合う適切な分析を支えます。

この値は通常、データの抽出、変換、読み込みを行うETLパイプラインで生成され、保存されます。

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

この属性は、個々のタスクの実作業時間を計算し、待機時間と区別するために欠かせません。イベント開始時刻からイベント終了時刻までの時間を比較することで、分析担当者は価値を生み出す作業にかかった時間を測定できます。これにより、リソースの利用状況をより細かく分析し、実作業時間を最も多く要するタスクを特定できます。

個々のアクティビティの実作業時間を計算し、待機時間と区別することで、作業にかかった時間を把握しやすくします。

イベントログから取得するか、同じ作業項目の次のアクティビティのタイムスタンプを使って算出できます。

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

チーム名で分析すると、チーム間のパフォーマンスを比較し、優れた取り組みを共有できます。「サイクルタイムが最も短いチームはどこか」「他のチームより手戻りが多いチームはあるか」といった問いにも答えられます。ワークフロー、スキル、リソースの状況の違いが、納品パフォーマンス全体にどう影響するかを明らかにし、対象を絞ったプロセス改善につなげられます。

チーム間のパフォーマンスを比較し、優れた取り組みや改善が必要な領域を特定できます。

担当ユーザーに関連付けられているか、プロジェクトまたは作業項目のレコードに直接記録されています。

プロジェクト名を使うと、特定の製品、取り組み、コードベースに属する作業項目をまとめて把握できます。たとえば、レガシーシステムと新規開発のアプリケーションでは、開発手法やサイクルタイムが大きく異なる場合があります。

この属性を使うと、組織内のさまざまな領域における開発プロセスを集計し、全体的な視点から比較できます。プロジェクトで分析を絞り込むことで、マネージャーは各開発作業の健全性や効率を評価できます。また、プロセスのパフォーマンスと、プロジェクト固有の状況や技術環境との関係を把握するうえでも欠かせません。

製品や取り組みごとにプロセス分析を分け、プロジェクトの状況によるパフォーマンスの違いを明らかにします。

作業項目または課題のレコードに標準項目として記録されるか、Gitなどのシステムではリポジトリ名として確認できます。

この属性は、現在のステップまたは作業項目全体の完了を担う個人やグループを示します。ライフサイクルを通じて担当者が何度も変わることがあり、開発者、QAテスター、レビュー担当者など、異なるロール間での引き継ぎが反映されます。

担当者属性を分析すると、チームの作業負荷、引き継ぎの効率、連携のパターンを把握できます。プロセスマップを担当者で絞り込み、特定の個人やチームの作業を確認できるため、リソースに起因するボトルネックの特定にも役立ちます。担当者間の引き継ぎを基にソーシャルネットワーク分析を行うと、コミュニケーションの不足や、複雑すぎる連携体制が明らかになる場合があります。

リソースの作業負荷、引き継ぎの頻度、連携のパターンを分析し、チームの効率向上に役立てられます。

作業項目または課題のレコードに記録されています。多くの場合、項目の履歴や監査ログで確認できます。

開発項目のステータスは、特定の時点における作業項目の状態を示します。アクティビティ名がステータス変更というイベントを記録するのに対し、この属性は変更後の状態そのものを記録します。イベント発生時点での作業の状態を分析する際に役立ちます。

この属性はアクティビティ名の作成に使われることが多い一方、追加のコンテキストも提供します。たとえば、ステータス項目を分析すると、「ブロック中」や「レビュー待ち」など、特定の状態に項目がとどまる時間を調べられます。生産性の低い状態に費やす時間を把握することは、組織的な遅延を特定し、作業の流れを改善するうえで重要です。

各状態に費やす時間を分析し、「ブロック中」のように価値を生まないステータスでの遅延や滞留を特定できます。

作業項目または課題のレコードに主要項目として記録され、履歴ログで追跡できます。

優先度属性は、作業項目のビジネス上または技術上の緊急度を示します。通常は「高」「中」「低」などの値を設定し、チームが次に取り組む作業を決める際に使います。

プロセスマイニングでは、優先度を分析の軸として利用できます。優先度の高い項目が、低い項目より実際に速く処理されているかを確認できます。優先度ごとにサイクルタイムを比較すると、プロセスがビジネス上の優先順位に沿っているかが分かります。優先度の高い項目が頻繁に遅れている場合は、計画、リソース配分、ワークフロー設計に課題がある可能性があります。

優先度の高い作業がプロセスを速く進んでいるかを確認し、重大な項目に大きな影響を及ぼすボトルネックを特定できます。

多くの開発管理システムで、作業項目または課題のレコードに標準項目として用意されています。

この属性は、実施する作業の種類を分類します。作業項目の種類によって、プロセスの経路や求められるパフォーマンスは異なります。たとえば、「バグ」には迅速な修正プロセスが必要な一方、「機能」は標準的な開発・テストサイクルに沿って進められます。

この属性を使うと、作業の種類ごとにプロセスの流れやパフォーマンスを比較できます。「バグ修正のプロセスは機能開発より速いか」「技術的負債の項目では手戻りが多いか」といった問いに答えるのに役立ちます。データを細かく分類するための基本的な軸となり、より具体的な改善案を見つけられます。

作業の分類ごとにプロセスやパフォーマンスを比較し、特定の開発項目に固有の非効率な点を明らかにします。

多くの開発管理システムで、作業項目または課題のレコードに標準項目として用意されています。

予定リリース属性は、開発項目を特定の納品スケジュールまたはバージョンに関連付けます。リリース計画では、機能や修正をまとめ、計画的にデプロイするためによく使われます。

予定リリースで分析すると、リリースプロセスの予測可能性と信頼性を評価できます。予定リリースと実際のデプロイ日を比較し、予定どおりに納品できた割合を追跡できます。また、対象リリースに向けた作業の流れを把握し、範囲の管理にも役立ちます。納品スケジュールに影響する可能性のあるリスクや遅延も明らかになります。

開発作業と納品スケジュールを関連付け、予定どおりの納品率やリリースの予測可能性を分析できます。

アジャイル計画・開発ツールで、「修正バージョン」「対象リリース」「イテレーションパス」などの標準項目として記録されています。

作成者属性は、作業項目を開始した人を示します。ユーザーストーリーを作成したプロダクトマネージャー、バグを記録したQAテスター、顧客の問題を報告したカスタマーサービス担当者などが該当します。

作業項目の作成者を分析すると、作業がどこから発生しているかを把握できます。たとえば、エンドユーザーから報告されるバグが多い場合、最近のリリースに品質上の問題がある可能性があります。また、作成者と後工程での手戻りや遅延を照らし合わせることで、初期要件の明確さや品質を分析できます。

作業の起点となった人を特定し、需要、バグ、機能リクエストの発生源を把握するのに役立ちます。

作業項目の作成時に記録される「報告者」や「作成者」などの標準項目です。

手戻り指標は、イベントが手戻りサイクルに含まれることを示す、算出された真偽値またはカテゴリ属性です。通常、プロセスの流れが逆戻りした場合、たとえば「QAテスト」から「開発中」に戻った場合や、「QAで手戻りを特定」のような特定のアクティビティが発生した場合に識別します。

この属性は、品質と効率の分析に役立ちます。手戻り率を直接計算し、プロセスのどの部分で手戻りが最も多く発生しているかを把握できます。手戻りのアクティビティで絞り込むと、品質上の問題を早期に検出できなかった原因を分析できます。手戻りの削減は、開発速度と製品品質の両方を高めるための重要な手段です。

手戻りを直接定量化し、その頻度や原因を分析するとともに、品質の改善状況を継続的に追跡できます。

通常、データ変換時にプロセスの逆戻りや、失敗を示す特定のアクティビティ名を特定して算出します。

重大度と優先度は異なります。重大度は問題の技術的な影響を示し、優先度は修正の緊急度を示します。たとえば、閲覧頻度の低いページの誤字は重大度も優先度も低い一方、重大なデータ破損の問題は、重大度も優先度も高くなります。

この属性は、特にバグ修正プロセスの品質分析に欠かせません。チームが重大な問題から優先して適切に対処できているかを評価できます。重大度ごとのサイクルタイムを分析することで、組織は顧客への影響を抑えるため、システムの重大な問題が速やかに解決されているかを確認できます。

技術的な影響に応じてチームが問題にどれだけ適切に対処しているかを分析し、重大な問題が速やかに解決されているかを確認できます。

開発管理システムでは、特に「バグ」や「インシデント」タイプの作業項目に標準項目として用意されています。