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

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

この属性は、プロセスフローを可視化し、イベントの順序を把握するために欠かせません。さまざまなアクティビティを分析することで、チームは一般的な経路を特定し、プロセスからの逸脱を見つけ、各段階にかかった時間を測定できます。ボトルネック分析、手戻り検出、目標プロセスモデルとの適合性確認の基盤にもなります。

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

通常は、開発作業項目に関連付けられたステータス変更ログ、イベントストリーム、監査履歴テーブルから取得します。

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

タイムスタンプは、時間を基準とするプロセスマイニング分析の基盤です。サイクルタイム、待機時間、アクティビティ間の処理時間など、主要なパフォーマンス指標の計算に使用します。タイムスタンプを分析することで、ボトルネックを特定し、プロセス効率を測定し、開発ライフサイクルの各段階にかかる時間を把握できます。たとえば、「レビュー用コード提出」から「コードレビュー完了」までの時間から、レビュー工程の遅延を明らかにできます。

イベントを正しい順序に並べ、サイクルタイムやボトルネックなど、時間に基づくすべての指標を計算するために欠かせません。

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

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

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

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

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

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

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

データの出所に関する背景を提供します。データ検証や、複数の統合システムにまたがる分析に欠かせません。

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

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

この情報は、分析やダッシュボードが最新の情報に基づいていることを確認するために重要です。関係者はプロセスビューがどの程度最新かを一目で確認でき、そこから得られる分析結果への信頼につながります。データパイプラインの管理やデータ更新のスケジュール設定に必要なメタデータでもあります。

データの新しさを示し、意思決定に必要な分析を適切なタイミングで行えるようにします。

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

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

この属性は、待機時間やアイドル時間と区別して、特定のタスクの実作業時間を計算するために欠かせません。イベント開始時刻とイベント終了時刻の差を分析することで、分析担当者は価値を生むアクティビティに費やした作業量を測定できます。これにより、リソースの利用状況をより詳細に分析し、実作業時間を最も多く消費しているタスクを特定できます。

個々のアクティビティの実作業時間を計算し、待機時間と区別できます。作業量をより明確に把握できます。

イベントログに記録されているほか、同じ作業項目における次のアクティビティのタイムスタンプから算出できます。

この属性は、開発項目の提供を担当する特定のチーム、スクワッド、またはグループを識別します。大規模な組織では、「Frontend」、「Backend」、「Mobile」、「Platform」など、複数の専門チームに作業を分担することが一般的です。

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

異なるチーム間のパフォーマンスを比較し、ベストプラクティスや改善すべき領域を特定できます。

担当ユーザーに関連付けられているか、プロジェクトまたは作業項目の記録に直接設定されていることが一般的です。

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

この属性により、組織内の異なる領域における開発プロセスを高いレベルで集計・比較できます。プロジェクトで分析を絞り込むことで、管理者は各開発活動の健全性と効率を評価できます。また、プロセスパフォーマンスとプロジェクト固有の背景や技術環境との関係を把握するうえでも欠かせません。

製品または取り組みごとにプロセス分析を分け、プロジェクトの背景に関連するパフォーマンスの違いを明らかにできます。

通常は、作業項目または課題の記録にある標準フィールド、またはGitなどのシステムにおけるリポジトリ名です。

この属性は、現在のステップまたは作業項目全体の完了に責任を持つ個人またはグループを識別します。ライフサイクルの途中で担当者が何度も変わることがあり、開発者、QAテスター、レビュー担当者など、異なる役割間の引き継ぎを反映します。

担当者属性を分析することで、チームの作業負荷、引き継ぎの効率、コラボレーションのパターンを把握できます。プロセスマップを特定の個人やチームの作業に絞り込み、リソース固有のボトルネックを特定することも可能です。担当者間の引き継ぎに基づくソーシャルネットワーク分析から、コミュニケーションの不足や、複雑すぎる協業構造が明らかになる場合もあります。

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

作業項目または課題の記録にあり、項目の履歴や監査ログで追跡されることが一般的です。

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

この属性はアクティビティ名の作成に使われることが多い一方、追加の背景情報も提供します。たとえば、ステータスフィールドを分析することで、「Blocked」や「Waiting for Review」など、項目が特定の状態にとどまった時間を測定できます。生産性につながらない状態に費やした時間を把握することは、構造的な遅延を特定し、フロー効率を改善するうえで重要です。

異なる状態に費やした時間を分析し、「Blocked」など、遅延や価値を生まないステータスにとどまった時間を特定できます。

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

この属性は、実施している作業の性質を分類します。作業項目のタイプによって、たどるプロセスや期待されるパフォーマンスが異なることがあります。たとえば、「Bug」では迅速なホットフィックスのプロセスが必要になる一方、「Feature」では標準的な開発・テストサイクルに従います。

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

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

ほとんどの開発管理システムで、作業項目または課題の記録に標準フィールドとして用意されています。

優先度属性は、作業項目の業務上または技術上の緊急度を示します。通常は「High」、「Medium」、「Low」などの値を設定し、チームが次に取り組む作業を決める際に役立ちます。

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

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

ほとんどの開発管理システムで、作業項目または課題の記録に標準フィールドとして用意されています。

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

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

作業の発生元を特定し、需要、バグ、機能リクエストの発生源を把握するために分析できます。

通常は、作業項目の初回作成記録にある「Reporter」や「Author」などの標準フィールドです。

手戻り指標は、イベントが手戻りサイクルの一部であることを示す、派生したブール値またはカテゴリ属性です。通常は、プロセスフローが後戻りした場合、たとえば「QA Testing」から「Development in Progress」に戻った場合や、「Rework Identified in QA」など特定の手戻りアクティビティが発生した場合に識別します。

この属性は、品質と効率の分析に非常に役立ちます。手戻り率を直接計算し、手戻りを最も多く発生させているプロセス部分を明らかにできます。手戻りアクティビティに絞り込むことで、品質問題が早期に検出されない理由を根本原因分析できます。手戻りの削減は、開発速度と製品品質の両方を改善する重要な手段です。

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

通常は、プロセスフロー内の後戻りループや、失敗に関連する特定のアクティビティ名を特定し、データ変換時に算出します。

計画リリース属性は、開発項目を特定の提供スケジュールまたはバージョンに関連付けます。通常は、機能や修正をまとめて計画的にデプロイするリリース計画で使用します。

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

開発作業を提供スケジュールに結び付け、予定どおりに提供できた割合やリリースの予測可能性を分析できます。

アジャイル計画・開発ツールにある「Fix Version」、「Target Release」、「Iteration Path」などの標準フィールドです。

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

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

技術的な影響に基づいて課題へどの程度効果的に対処できているかを分析し、重大な問題を速やかに解決できるようにします。

開発管理システムで、特に「Bug」または「Incident」タイプの作業項目に用意されている標準フィールドです。