Redmineでここまで見える。チケット設計で変わる“燃えない”プロジェクトの進め方

ジェイ・ライン流「燃えない」プロジェクトの前提

Redmineで炎上を防ぐポイントは、「誰が・いつまでに・何を・どのくらいの工数でやるか」をチケットにすべて乗せることです。ジェイ・ラインでは、
・要件定義／構成案
・デザイン
・実装（フロント／バックエンド）
・テスト／公開・リリース後対応
の各工程を、Redmine上で一貫して管理します。
単にタスクを洗い出すのではなく、「粒度をそろえる」「担当者を明確にする」「期日と見積工数を必ず入れる」ことを徹底することで、進行管理・工数管理・リスク検知を同時に行える状態を作っています。

工程別の粒度設計：どこまで分解するか

粒度が粗すぎると遅延が見えず、細かすぎると運用コストが増えます。ジェイ・ラインでは、
・1〜2日以内に完了する作業を1チケット
・複数人が関わる場合は「親チケット＋子チケット」で分解
を基本としています。例えば要件定義では「トップページ要件整理」「フォーム要件整理」など画面単位、デザインでは「TOPデザイン初稿」「下層テンプレートデザイン」などアウトプット単位で切ります。実装では「ヘッダー共通化」「お問い合わせフォーム実装」など、レビュー可能な最小単位で分解し、テストは「画面別」「機能別」で分けるのがルールです。

チケット項目の実例：こんな情報を入れている

Redmine上のチケット項目は、以下を基本フォーマットにしています。
・トラッカー：要件定義／デザイン／実装／テストなど
・題名：<例>【要件】TOPページ要件整理
・説明：目的／アウトプット／前提条件／完了条件
・担当者：実務担当1名のみ
・期日：工程マイルストンから逆算した日付
・予定工数（時間）：実績と比較できる単位に固定
・親チケット：機能単位・ページ単位のまとめ
・カスタムフィールド：レビュー担当、想定難易度など
このフォーマットをテンプレート化し、ディレクター・エンジニア間で共通言語として運用しています。

担当者の割り当てと「丸投げ」防止の工夫

炎上要因になりがちなのが「エンジニアへの丸投げ」です。ジェイ・ラインでは、
・ディレクターが要件定義～公開までの親チケットを持つ
・作業チケットは「実務担当者」を1名に限定
・レビュワーはカスタムフィールドで明示
というルールで責任の所在を明確にしています。また、
・仕様検討タスクと実装タスクを分ける
・不明点の洗い出し用チケットを事前に作る
ことで、実装フェーズに入ってからの仕様ブレ・手戻りを抑制。結果として、ディレクターとエンジニア間の期待値齟齬を小さくし、「頼んだつもり」「聞いていない」を発生させない設計にしています。

期日と工数見積：遅延の早期検知をどう実現するか

Redmineでは、期日と予定工数、進捗率の3点を必須とし、「見える遅延」を作っています。具体的には、
・週次で「今週完了予定チケット」と「予定工数合計」を確認
・実績工数との差分が大きい担当者・工程を早期に把握
・期限前に進捗率が上がっていないチケットをアラート扱い
といった運用です。特にエンジニアには、1日単位での工数配分をRedmine上で管理してもらい、残業が常態化しそうな案件はディレクター側でスコープ調整・役割再配分をかけます。これにより、「締切前の一気残業」を避ける体制を整えています。

残業抑制と炎上防止につながった実例

ある採用サイト制作では、初期設計時に「フォーム仕様未確定」のリスクをチケットとして独立させ、決定期限と工数を明示しました。結果として、営業・クライアントを巻き込んだ早期の仕様確定が進み、実装フェーズでのやり直し工数を30％以上削減できました。
別案件では、実装タスクをコンポーネント単位に分解・見積した結果、初期段階で工数オーバーが判明し、納期前倒しではなく機能スコープの調整を選択。ピーク時の残業時間を20時間／月以内に抑えつつ、クオリティを維持したままリリースできました。

ディレクター・テクニカルディレクター志望者が意識したい視点

Redmineのチケット設計は、単なるツール運用ではなく「プロジェクトの回り方」を設計する行為です。ディレクター・テクニカルディレクター志望者にとって重要なのは、
・工程ごとに、どのアウトプットで区切るかを言語化する
・責任の所在とコミュニケーション経路をチケット上で明示する
・期日と工数から、チームの限界値を逆算して計画する
という視点です。こうした考え方が身につくと、Redmineは単なるタスク管理ツールから、「炎上しない進行の型」を共有するためのプラットフォームへと変わります。プロジェクト全体を俯瞰したい人ほど、チケット設計の精度にこだわる価値があります。