月曜日の定例ミーティングを思い浮かべてください。チームはRedmineで数十件のチケットを抱えており、どのチケットにも担当者と期日が設定されています。

.

それでも、スポンサーから「リリースは予定どおりですか？」と聞かれると、正直な答えは「場合によります」になってしまいます。タスク管理でわかるのは、一人ひとりが何をしているかです。プロジェクト全体が期日どおりに完了するかどうかまでは教えてくれません。

Redmineにおけるタスク管理とプロジェクト計画の違い

Redmineは、タスク管理という最初の仕事を非常にうまくこなします。チケットが割り当てられ、ステータスが変わり、作業時間が記録され、誰が何を担当しているかを誰でも確認できます。小規模なチームで期間の短いプロジェクトであれば、多くの場合これで十分です。

しかしプロジェクトが大きくなると、チケット一覧では答えられない別の疑問が生まれます。

  • 本当にスケジュールどおりに進んでいるのか？
  • どのタスクが進捗を妨げているのか？
  • メンバーの誰かが期限に間に合わなかったらどうなるのか？
  • この遅れは最終リリースに影響するのか？
  • 当初のプロジェクト計画に今も沿っているのか？

これらはいずれも、タスク同士の関係についての問いです。遅れているタスクを何が待っているのか、計画の残りにどれだけ余裕があるのか、全員が合意したスケジュールから現在の計画がどれだけずれているのか。チケットのステータスによる進捗管理でわかるのは、何が完了したかです。それを根拠のある納期に変えるのがプロジェクト計画です。以下のセクションで、これらの問いを順に取り上げます。

Redmineでのプロジェクト計画：標準機能でできること

何かを追加する前に、標準のRedmineで何ができるのかを整理しておきましょう。実は多くのチームが使いこなしている以上の機能があります。

  • 日付と見積もり ：すべてのチケットに設定でき、親子チケットで作業を分解できます。
  • チケット間の関連 ：先行・後続の関連 により、あるタスクは別のタスクが終わるまで開始できないことを表し、遅延日数も設定できます。先行するチケットが後ろにずれると、Redmineは後続のチケットも一緒に後ろへずらします。
  • バージョン ：期日を設定でき、リリースのマイルストーンとして機能し、ロードマップで進捗を確認できます。
  • ガントチャート ：チケットとバージョンをタイムライン上に表示し、関連を矢印で示します。
  • 保存済みクエリとCSVエクスポート ：状況報告や、計画を手作業で控えておくには十分です。

小規模なチームであれば、これだけでもRedmineでのプロジェクト計画として機能します。課題が見えてくるのは、スケジュールが大きくなってからです。Redmineはクリティカルパスを計算しません（ ガントチャートにクリティカルパスを表示する要望 は2013年からredmine.orgで未解決のままです）。承認済みの計画を現在の計画と並べて保持する標準の仕組みもなく、日付の変更はすべてチケットの編集画面を通して行う必要があります。

Redmine Gantt（ガントチャート）の限界

ガントチャートはこうした機能の中心ですが、プロジェクト計画に使うガントチャートには、日付を表示する以上の役割が求められます。

標準のガントチャートは、チケット、日付、関連を把握するのに役立つ概要を提供します。ただし、インタラクティブな計画用ワークスペースではありません。日付を変えるにはチケットを編集する必要があり、変更案が全体に与える影響を把握するにも手間がかかります。マイルストーンを1週間動かそうとしたプロジェクトマネージャーは、十数件のチケットを開くことになり、長いタスク一覧から依存関係を読み取るのにも時間がかかります。さらに、どのタスクが完了日を決めているのか、現在のスケジュールは承認された計画と比べてどうなのか、という2つの問いにも答えが出ないままです。

これが、スケジュールを「見る」ことと「管理する」ことの違いです。見ることは表示の問題です。管理するとは、計画を変更し、その変更の結果を確認し、チームと合意できることを意味します。Plannerは、スケジュールの編集、依存関係の可視化、変更のレビューをチャート上で直接行えるようにします。本記事で取り上げるRedmine Gantt代替ツールとは、別のツールではなく、Redmineの中にありながら編集できるチャートのことです。

出発点は、わかりやすい全体像です。担当者、日付、期間がひとつのプロジェクトタイムライン上に並んでいれば、チケット一覧から状況を組み立て直さなくても、プロジェクトを一目で把握できます。下の画面は、本記事の後半で改めて紹介するプラグインRedmineUP Plannerで作成した、10タスクのリリース計画です。

プロジェクトのタイムライン、タスク、担当メンバーを表示したRedmineのガントチャート

プロジェクトのスケジュール、タスク、担当をひとつのRedmineガントチャートで明確に把握できます。

タスク依存関係：ひとつの遅れがプロジェクト全体を動かす

プロジェクトの遅れの多くは、ひとつの大きな失敗から生じるわけではありません。ほかのタスクが暗黙のうちに依存しているタスクの、小さな遅れから生じます。

よくあるソフトウェアリリースを例に考えてみましょう。バックエンド開発 → 結合 → QAテスト → リリースという流れです。バックエンドの作業は2週間の予定でしたが、3週間かかりました。結合作業はバックエンドが終わるまで始められないため、後ろにずれます。QAは結合が終わるまで始められないため、これもずれます。先月顧客に約束したリリース日も、一緒にずれていきます。最初の遅れのあと、誰もミスをしていません。スケジュールは依存関係のとおりに動いただけです。

遅れが発覚するのが遅いほど、影響は大きくなります。バックエンド担当者が1週間遅れで「完了しました」と報告した時点で初めて結合作業が止まっていると気づいても、打てる手は限られます。この連鎖を事前に把握できていれば、まだコストが小さいうちに人員を追加する、スコープを削る、関係者の期待値を調整するといった対応が取れます。

だからこそプロジェクトマネージャーは、期限を変更したり納期を約束したりする前に、依存関係を理解しておく必要があります。日付が動くたびに「このタスクを何が待っているのか？」と問いかけてください。Redmineの関連を使えばその答えを記録でき、視覚的なチャートがあればすぐに読み取れます。

下のスクリーンショットでは、矢印が各タスクとそれに依存するタスクを結んでいます。そのうち1本が赤で表示されています。これは、フロントエンド画面のスケジュールが、後続の結合タスクと矛盾していることを示しています。このような矛盾は一覧では見落としやすい一方、タイムライン上では一目瞭然です。そのため、テスト段階で発覚する前に、計画ミーティングの場で修正できます。

タスク依存関係とスケジュールの矛盾を表示したRedmineのプロジェクト計画用ガントチャート

タスク同士の依存関係を把握し、プロジェクトの納期に影響する前にスケジュールの矛盾を見つけられます。

Redmineのクリティカルパス：完了日を決めるタスクはどれか

依存関係が見えるようになると、次の疑問が浮かびます。すべてがつながっているなら、どの遅れが最も重要なのでしょうか？

その答えは、プロジェクトのスケジューリングにおける標準的な手法であるクリティカルパス法（CPM）から得られます。クリティカルパスとは、依存関係でつながったタスクのうち所要期間が最も長い経路で、プロジェクトの最短完了日を決定します。この経路上のタスクはトータルフロートがゼロです。つまり、そのうちのどれかが遅れると、チームが遅れを取り戻す対策を取らない限り、プロジェクトの完了日も後ろにずれます。経路から外れたタスクには、ある程度の余裕があります。

この余裕をフロートと呼び、次の2種類があります。

  • トータルフロート ：プロジェクトの完了日を遅らせずに、そのタスクが遅れてもよい期間です。
  • フリーフロート ：後続タスクの開始を遅らせずに、そのタスクが遅れてもよい期間です。

フロートは稼働日数で数えます。トータルフロートが12日のタスクは、同じ連鎖上のほかのタスクが動かない限り、12稼働日遅れても完了日に影響しません。値がマイナスの場合は、現在のスケジュールでは終了日に間に合わないこと、または依存関係に違反していることを意味します。たとえば、後続タスクが許容する時点よりも遅くタスクが終わるケースです。

これが優先順位を変える理由です。Redmineでどちらも優先度「高」になっている2つのチケットを考えてみましょう。ひとつはクリティカルパス上にある結合作業です。もうひとつは、急ぎで依存しているものが何もないステージング環境の構築です。結合作業が2日遅れれば、チームがどこかで時間を取り戻さない限り、リリースも2日遅れます。ステージング環境の構築が1週間遅れても、リリース日は変わりません。優先度のラベルからはこの違いがわかりませんが、クリティカルパスならわかります。クリティカルパスがなければ、チームは納期を左右するタスクではなく、声の大きいタスクや期日が近いタスクに優秀なメンバーを割り当てがちです。

標準のRedmineにはクリティカルパス分析の機能がないため、多くのチームは分析自体を省くか、すぐに情報が古くなる別ツールで管理しています。スクリーンショットでは、クリティカルな連鎖が赤で強調され、すべてのタスクにフロート値が表示されています。バックエンド、結合、QA、リリースはゼロです。ステージング環境と顧客向けウェビナーには12稼働日のフロートがあります。フロントエンド画面はマイナスの値になっています。後続タスクが許容するよりも遅く終わる設定になっており、前のスクリーンショットで指摘されたのと同じ矛盾で、対応が必要です。

クリティカルパスとタスクのフロートを強調表示したRedmineのガントチャート

プロジェクトの完了日に直接影響するクリティカルなタスクを特定し、本当に重要なところにチームの力を集中できます。

プロジェクトのベースライン：計画の実行状況を測定可能にする

よく練られた計画にも賞味期限があります。要件が変わり、メンバーがほかの仕事に呼ばれ、ベンダーが遅れます。一つひとつの変更は小さく妥当なもので、それぞれ別々のチケットで、別々の日に行われます。

数か月もすると、当初の計画はどこにも残っていません。承認された日付を誰も覚えておらず、計画の実行状況の評価は個人の感覚に頼ることになります。ある人は「1週間くらい遅れている」と言い、別の人は「2週間」と言います。納期がずれた理由を顧客に説明しなければならないマネージャーには、時間がどこで失われたのかを明確に示す手段がありません。

この問題を解決するのがプロジェクトのベースラインです。ベースラインとは、承認されたスケジュールを保存したスナップショットです。記録するのは計画上の開始日と期日で、見積もりや担当者などほかのチケット属性は含みません。ベースラインは変更せずに保持し、いつでも現在のスケジュールと比較できます。「なんとなくずれている」という曖昧な感覚ではなく、どのタスクが、どちらの方向に、何日動いたのかという具体的な情報が得られます。

これにより、多くのチームに欠けている3つのものが手に入ります。

  • 説明責任 ：全員が合意した計画が記録として残り、こっそり書き換えられることがありません。
  • 現実的な予測 ：特定の領域で小さな遅れが続くパターンは早期の警告サインです。最後に「バッファ」を足すよりも誠実な方法です。
  • 透明性のあるコミュニケーション ：「リリースは承認済みの計画より4日遅れており、原因はこの3つのタスクです」と伝えるほうが、「いくつか問題が発生しました」と伝えるよりも、スポンサーとの建設的な対話になります。

スクリーンショットでは、チームはキックオフ時に「Initial plan」という名前でベースラインを保存しています。各バーの下にある細い線が当初の計画位置を示し、列には各タスクが何稼働日ずれたかが表示されています。ステージング環境は計画どおりの位置にあります。ランディングページは5稼働日、フロントエンド画面は6稼働日、リリースの展開は4稼働日遅れています。誰かが推測するまでもなく、これがプロジェクトの実際の状態を数字で示したものです。

計画時と現在のタスクスケジュールを比較するRedmineのプロジェクトベースライン

現在のプロジェクトスケジュールを当初の計画と比較し、大きな問題になる前に遅れを特定できます。

チームで進めるプロジェクト計画：変更は適用前にレビューする

チャートがどれほど整っていても、計画はプロジェクトマネージャーがひとりで行うものではありません。スケジュールの変更が個人的な編集で済むことはまずありません。あるタスクが動けば、その担当の開発者だけでなく、そのタスクに依存しているメンバー、ビルドを待っているテスター、その週に人員を割り当てたチームリーダーにも影響が及びます。

それにもかかわらず、多くのチームではスケジュールの変更が予告なしの編集として行われています。誰かが日付を調整し、通知が送られ、ほかのメンバーは受信トレイで新しい計画を知ることになります。複数の人に関わる決定の進め方としては、あまり良い方法とはいえません。

より健全な進め方は、次の4つのステップで構成されます。

  1. 変更は、そのまま適用するのではなく提案する。
  2. 影響を受ける人が、ほかのタスクへの波及効果も含めて、何が変わるのかを正確に確認できる。
  3. プロジェクトマネージャーが、承認する前に影響をレビューする。
  4. そのうえで初めて、新しいスケジュールを実行計画とする。

このように進めるチームは、修正作業や突然のスケジュール変更に費やす時間が少なくなります。また、現在の計画についての共通認識も生まれます。これは、メンバーが異なるタイムゾーンや異なるプロジェクトで働いている場合に特に大きな価値を持ちます。

スクリーンショットは、この考え方を実際に形にしたものです。Plannerは依存関係を矢印で表示し、スケジュール上の違反を強調します。提案された変更が後続チケットに影響する場合、Reviewテーブルには、Redmineに適用される前に、その結果として生じる日付の変更が表示されます。ここでは、フロントエンド画面に対する変更案が共有ドラフトで保留されており、変更前と変更後の日付が並べて表示され、提案者の名前も示されています。ダイアログには、その結果としてRedmineが結合タスクを月末に移動することも記載されています。実際のチケットにはまだ何も書き込まれておらず、何を適用するかはチームで決められます。

プロジェクトスケジュールの変更をレビューするRedmine Plannerの共有ドラフト画面

提案されたスケジュール変更とその影響を、Redmineプロジェクトに適用する前にレビューできます。

RedmineUP Planner：プロジェクト計画のためのRedmine Gantt代替ツール

ここまで紹介した内容は、規律とスプレッドシート、そして多大な忍耐があれば実現できます。 RedmineUP Planner は、これらの実践をRedmineの中のひとつのワークフローにまとめるプロジェクト計画ソフトウェアで、チームがすでに使っているチケットの上で動作します。依存関係が矢印で表示され、違反が警告される編集可能なガントチャート上で計画を立てられます。提案された変更は、誰かがレビューして適用するまで共有ドラフトで保留され、クリティカルパス、ベースライン、バージョンのマイルストーンも同じチャート上に表示されます。

実際のメリットは、個々の機能にあるわけではありません。スケジュールの変更をひとつの場所で議論し、レビューし、管理しやすくなること、そして作業そのものについてはRedmineが引き続き信頼できる唯一の情報源であり続けることです。

Plannerは、編集可能なガントチャート、Review・Applyによる共有Draft、依存関係、Undo/Redoに加え、高度な計画機能を備えています。トータルフロートとフリーフロートを含むクリティカルパス分析、差異列付きのベースライン、グルーピング、追加のクエリ列、バーの色分け、バージョンのマイルストーンです。詳しくは Plannerのページ と ドキュメント をご覧ください。

Plannerは、RedmineUPのほかの製品とも連携して使えます。スプリントを運用しているチームは Agileプラグイン でボードを管理でき、プロジェクトをまたいで人員配分を調整したいマネージャーは Resourcesプラグイン を追加できます。選択肢を幅広く知りたい方は、ガイド記事 プロジェクト管理に最適なRedmineプラグイン をご覧いただくか、 Redmineプラグイン一覧 をご確認ください。

Ganttによるプロジェクト計画をRedmineのワークフローに組み込む

Redmineは、チームがすでに日々の作業を管理している場所です。より良い計画の実践を取り入れれば、スケジュールを計画し、依存関係を理解し、計画の実行状況を追跡する場所にもなります。誰も更新しない別ツールに計画を移す必要はありません。

何もインストールせずに始めたい場合は、小さな習慣から始めましょう。進行中のプロジェクトをひとつ選び、本記事の冒頭で挙げた5つの問いを投げかけてみてください。今の環境で答えられない問いがあれば、それがプロジェクト計画のギャップです。そのリストは、チームに次に何が必要かを話し合う出発点として最適です。

基本的なタスク管理の一歩先に進みたいチームにとって、RedmineUP Plannerは次のステップです。 ライブデモ を開いてPlannerを選び、サンプルデータでクリティカルパス、ベースライン、Draftのレビューを試してみてください。準備ができたら、ご自身のRedmine（5.0〜7.0）にPlannerをインストールできます。

RedmineUP Plannerを入手