Redmineの作業分類とチケット構成の考え方 — 工数管理を破綻させないための設計指針

Redmineで工数管理を始めるとき、最初に直面するのが「作業分類をどう設計するか」という問題です。

作業分類の設計を間違えると、分類の数が膨大に膨らみ、運用が破綻します。逆に、正しく設計すれば作業分類はたった3つで十分です。

この記事では、よくある失敗パターンと、それを回避する推奨パターンを解説します。

よくある失敗パターン：作業分類に工程を持たせる

最もよくある失敗は、工程ごとに作業分類を作るアプローチです。

例えば、以下のように作業分類を設計したとします。

一見問題なさそうですが、ここにレビューの時間も記録したいとなると、状況が一変します。

工程数 × レビュー種別（DR/PR）× 作業種別（レビュー/指摘反映）で、作業分類が爆発的に増えていきます。5つの工程に2種類のレビューと指摘反映を加えると、5 + 5×2×2 = 25個の作業分類が必要になります。

以下は、実際にこのアプローチで運用した結果の作業分類設定画面です。

これでは、時間入力のたびにスクロールして正しい分類を探す必要があり、入力効率が大幅に低下します。

推奨パターン：工程はチケット構成で管理する

解決策はシンプルです。工程の管理を作業分類ではなく、チケットの親子構造で行うのです。

チケット構成で工程を表現する

案件（親チケット）の下に、各工程を子チケットとして作成します。各チケットには予定工数を設定します。

この構成により、各工程チケットに予定工数が入るため、チケット単位で「予定 vs 実績」の対比ができるようになります。

作業分類は3つだけ

工程をチケットで管理すると、作業分類に求められる役割は「作業の性質」の区別だけになります。

Redmineの作業分類設定はこれだけです。

なぜこの構成が良いのか

1. 予定と実績の対比ができる

各工程チケットに予定工数を設定しているので、「詳細設計に20時間見積もったが、実際は30時間かかった」ということがチケット単位で分かります。作業分類に工程を持たせた場合は、この対比ができません。

2. 作業分類が膨張しない

工程が増えても作業分類は3つのまま。新しい案件が来ても、新しい工程が追加されても、作業分類を変更する必要がありません。

3. レビューの工数が可視化される

「開発」「DR」「DR指摘反映」の3つに分けることで、以下が分析できるようになります。

• レビューにどれだけ時間をかけたか — DRの合計時間
• 指摘反映にどれだけかかったか — DR指摘反映の合計時間
• レビューの効率 — DR時間とDR指摘反映時間の比率

レビューに十分な時間をかけているか、指摘反映に時間がかかりすぎていないかを定量的に把握できます。

4. 各工程のチケットに3種類のデータが蓄積される

1つの工程チケット（例：「詳細設計」）に対して、3種類の作業実績が記録されます。

チケットの予定工数が20hに対して実績が24hなら、4時間の超過が分かります。さらにその内訳（開発16h、レビュー3h、指摘反映5h）も把握できます。

作業分類の自動振り分け

「開発」「DR」「DR指摘反映」の3つの作業分類は、毎回手動で選択する必要はありません。Redmine Studioの自動振り分け機能を使えば、チケットの条件に応じて作業分類を自動設定できます。

例えば、以下のような自動判定ルールを設定できます。

自動振り分けの設定方法は設定② -作業分類-を参照してください。

運用イメージ

Redmine Studioの時間入力画面では、左側に作業分類、下側にチケット一覧が表示されます。

日々の時間入力は以下の流れで行います。

1. 左側の作業分類から「開発」「DR」「DR指摘反映」のいずれかを選ぶ
2. 下側のチケット一覧から対象の工程チケットを選ぶ
3. スケジュールビュー上でドラッグして時間範囲を指定する

作業分類が3つだけなので迷うことがなく、1日の作業実績を30秒で入力し切ることが現実的になります。

まとめ

工程はチケットで、作業の性質は作業分類で。この原則を守ることで、工数管理が破綻することなく、正確なデータが蓄積されていきます。

Redmine Studioは、この考え方をベースに設計されています。工数入力の詳しい使い方は工数入力クイックスタートをご覧ください。

次のステップ

→ 工数入力 クイックスタート — 実際に使い始める

→ 設定② 作業分類 — 自動振り分けの設定方法