RedmineStudio 工数入力 クイックスタート
redminepower
RedminePower
Redmineの作業分類とチケット構成の考え方 — 工数管理を破綻させないための設計指針
redminepower
Redmineで工数管理を始めるとき、最初に直面するのが「作業分類をどう設計するか」という問題です。
作業分類の設計を間違えると、分類の数が膨大に膨らみ、運用が破綻します。逆に、正しく設計すれば作業分類はたった3つで十分です。
この記事では、よくある失敗パターンと、それを回避する推奨パターンを解説します。
Contents
よくある失敗パターン：作業分類に工程を持たせる
最もよくある失敗は、工程ごとに作業分類を作るアプローチです。
例えば、以下のように作業分類を設計したとします。
| 作業分類 | 用途 |
|---|---|
| 要件定義 | 要件定義工程の作業 |
| 基本設計 | 基本設計工程の作業 |
| 詳細設計 | 詳細設計工程の作業 |
| 実装 | 実装工程の作業 |
| テスト | テスト工程の作業 |
一見問題なさそうですが、ここにレビューの時間も記録したいとなると、状況が一変します。
| 作業分類 | 用途 |
|---|---|
| 要件定義 | 要件定義の作業 |
| 基本設計 | 基本設計の作業 |
| 詳細設計 | 詳細設計の作業 |
| 実装 | 実装の作業 |
| テスト | テストの作業 |
| 要件定義DR | 要件定義のレビュー実施 |
| 要件定義DR指摘反映 | 要件定義レビュー指摘への対応 |
| 基本設計DR | 基本設計のレビュー実施 |
| 基本設計DR指摘反映 | 基本設計レビュー指摘への対応 |
| 詳細設計DR | … |
| 詳細設計DR指摘反映 | … |
| コードPR | … |
| コードPR指摘反映 | … |
工程数 × レビュー種別（DR/PR）× 作業種別（レビュー/指摘反映）で、作業分類が爆発的に増えていきます。5つの工程に2種類のレビューと指摘反映を加えると、5 + 5×2×2 = 25個の作業分類が必要になります。
以下は、実際にこのアプローチで運用した結果の作業分類設定画面です。
これでは、時間入力のたびにスクロールして正しい分類を探す必要があり、入力効率が大幅に低下します。
推奨パターン：工程はチケット構成で管理する
解決策はシンプルです。工程の管理を作業分類ではなく、チケットの親子構造で行うのです。
チケット構成で工程を表現する
案件（親チケット）の下に、各工程を子チケットとして作成します。各チケットには予定工数を設定します。
この構成により、各工程チケットに予定工数が入るため、チケット単位で「予定 vs 実績」の対比ができるようになります。
作業分類は3つだけ
工程をチケットで管理すると、作業分類に求められる役割は「作業の性質」の区別だけになります。
| 作業分類 | 意味 | 例 |
|---|---|---|
| 開発 | レビュー以外のすべての作業 | 設計、実装、テスト、ドキュメント作成、調査 |
| DR | デザインレビューの実施時間 | 設計書レビュー、コードレビュー |
| DR指摘反映 | レビュー指摘への対応時間 | 指摘された箇所の修正作業 |
Redmineの作業分類設定はこれだけです。
なぜこの構成が良いのか
1. 予定と実績の対比ができる
各工程チケットに予定工数を設定しているので、「詳細設計に20時間見積もったが、実際は30時間かかった」ということがチケット単位で分かります。作業分類に工程を持たせた場合は、この対比ができません。
2. 作業分類が膨張しない
工程が増えても作業分類は3つのまま。新しい案件が来ても、新しい工程が追加されても、作業分類を変更する必要がありません。
3. レビューの工数が可視化される
「開発」「DR」「DR指摘反映」の3つに分けることで、以下が分析できるようになります。
- レビューにどれだけ時間をかけたか — DRの合計時間
- 指摘反映にどれだけかかったか — DR指摘反映の合計時間
- レビューの効率 — DR時間とDR指摘反映時間の比率
レビューに十分な時間をかけているか、指摘反映に時間がかかりすぎていないかを定量的に把握できます。
4. 各工程のチケットに3種類のデータが蓄積される
1つの工程チケット（例：「詳細設計」）に対して、3種類の作業実績が記録されます。
| 作業分類 | 時間 | 意味 |
|---|---|---|
| 開発 | 16h | 詳細設計書の作成にかけた時間 |
| DR | 3h | 詳細設計書のレビューにかけた時間 |
| DR指摘反映 | 5h | レビュー指摘の修正にかけた時間 |
| 合計 | 24h | 詳細設計の総工数（予定: 20h → 4h超過） |
チケットの予定工数が20hに対して実績が24hなら、4時間の超過が分かります。さらにその内訳（開発16h、レビュー3h、指摘反映5h）も把握できます。
作業分類の自動振り分け
「開発」「DR」「DR指摘反映」の3つの作業分類は、毎回手動で選択する必要はありません。Redmine Studioの自動振り分け機能を使えば、チケットの条件に応じて作業分類を自動設定できます。
例えば、以下のような自動判定ルールを設定できます。
| 条件 | 自動設定される作業分類 |
|---|---|
| トラッカーが「レビュー開催」または「レビュー依頼」 | DR |
| トラッカーが「レビュー指摘」かつ担当者が自分 | DR指摘反映 |
| 上記以外 | 開発（デフォルト） |
自動振り分けの設定方法は設定② -作業分類-を参照してください。
運用イメージ
Redmine Studioの時間入力画面では、左側に作業分類、下側にチケット一覧が表示されます。
日々の時間入力は以下の流れで行います。
- 左側の作業分類から「開発」「DR」「DR指摘反映」のいずれかを選ぶ
- 下側のチケット一覧から対象の工程チケットを選ぶ
- スケジュールビュー上でドラッグして時間範囲を指定する
作業分類が3つだけなので迷うことがなく、1日の作業実績を30秒で入力し切ることが現実的になります。
まとめ
| 失敗パターン | 推奨パターン | |
|---|---|---|
| 工程の管理 | 作業分類で管理 | チケット構成で管理 |
| 作業分類の数 | 工程数に比例して増加（20個以上） | 常に3つ（開発/DR/DR指摘反映） |
| 予定vs実績の対比 | できない | チケット単位で可能 |
| レビュー工数の可視化 | 困難 | 自動的に分離される |
| 新規案件追加時 | 作業分類の追加が必要 | チケットを作るだけ |
工程はチケットで、作業の性質は作業分類で。この原則を守ることで、工数管理が破綻することなく、正確なデータが蓄積されていきます。
Redmine Studioは、この考え方をベースに設計されています。工数入力の詳しい使い方は工数入力クイックスタートをご覧ください。
