Redmineのチケット設計はMVCモデルで考えると上手くいく

Redmineのチケット設計はMVCモデルで考えると上手くいくと思う。

Model＝チケット。QCD分析の観点はカスタムフィールドで仕込む。
Controller＝各機能。
View＝QCD観点の集計ビュー。

なぜ、MVCモデルで考えるべきなのか？

MVCで考えると、PLが欲しいデータをチケットで作りこむ発想になる。
PJの状況をリアルタイムにモニタリングして、PJが暴走しないように早めにリスクを検知したい。
飛行機の操縦室のように、数多くの計測機を表示させて、少しでもおかしな点があれば、どこかでアラートが出るようにしたい。
つまり、各機能はQCDの観点で区別して利用すべき。

では、どんなビューが欲しいのか？

進捗の観点なら、ガントチャートやEVM、CCPMのバッファ管理図。
コストの観点なら、工数ベースや金額ベースのEVM。
品質の観点なら、機能ごとの障害・課題数、障害や課題の残枚数の時系列グラフ、信頼度成長曲線、障害密度のゾーン分析、とか。

では、どんな情報をチケットにするか？

進捗の観点なら、開始・終了日の予実、進捗率。
コストの観点なら、工数の予実。
品質の観点なら、障害・課題の原因、発生・流出原因、発生した機能、対応方法の種類など。

つまり、QCD分析したい時に必要な情報は何か、をViewからModelへさかのぼり、チケットの入力項目を決めることになる。
チケットの標準項目が不足していれば、カスタムフィールドを追加すればいい。
Redmineではカスタムフィールドをトラッカーごとに割当られるので、複数のトラッカーの入力項目から正規化することで、カスタムフィールドの数を減らせる。
この辺りは、データモデリングの設計思想と全く同じ。

@g_maedaさんは、「トラッカー設計＝帳票フォームの設計＝入力フォームの設計」と言われているが、MVCモデルで考える発想はこの設計に通じる。

はじめる! Redmine (2017) from Go Maeda