チケット管理でウォーターフォール型プロジェクトがうまく回らないときの参考

はじめに

プロジェクト管理にチケットツールを導入したけど、なぜかうまく回らない。
そんな悩みを抱えているマネージャーやチームリーダーが多いのではないでしょうか。
私自身も、最初に気合を入れて何百というチケットを作成したにもかかわらず、現場に使ってもらえなかった経験を何度も重ねてきました（これは本当に辛い...）。

アジャイルプロジェクトのベストプラクティスについての記事はよく見かけますが、ウォーターフォール型のプロジェクトにおける具体的な実践方法は、検索してもなかなか出てこないのが現状です。
そこで、自分がこれまでに実践し効果を感じたケースをいくつか紹介してみることにしました。
$\color{gray}{\tiny \textsf{～画像はChatGTP 4.0で生成。AI時代のビックウェーブに乗るしかない！～}}$

うまく回らない理由

よく聞くチケット管理失敗のパタンは下記でした。

1. 現実と理想の乖離
2. チケット管理疲れ
3. 見通しの見えない構成
4. チケットの意味が分からない

1.2.はチケット更新者のモチベーション低下が要因
3.4.は管理者側の管理限界が要因
$\color{gray}{\tiny \textsf{～以下の背景は私の実体験とこれまで関わってきたPMの方からの情報をもとに作成しています。～}}$

今回は1.2.に対応するためのプラクティスをまとめてみました。
以下あるある集は長いので、先にプラクティスに飛びたい方はこちら

現実と理想の乖離

背景

恥ずかしながらこれは自分の過去エピソード
作業を完璧に把握するためにも、プロジェクト開始時に詳細なWBSをもとにして、全工程・全作業のチケットを200件以上作成しました。要件定義からテストまで、全ての作業を網羅し、「これで完璧に回せるはずだ」とやる気満々！🚀

が...実際にプロジェクトが始まると、要件の見直しや顧客からの仕様変更が相次ぎ、前提が次々に崩れていきました。初期に作ったチケットは、すぐに予定と合わなくなり、誰も更新しなくなっていきました。
チームメンバーは口をそろえて 「チケットは参考程度で」、「実際の作業は別で管理してます」 と言うように。

結果

結果として、チケット管理は形だけになり、進捗も全体像も把握できない状態に。最初の理想が高かった分、現実とのギャップが大きく、管理コストと私の精神が無駄にすり減らされる結果に...

でも、自分でも
分かる分かる・・・これは書かないな...というのが正直な感想。

各担当者はチケットを確認しながらも、進捗は別途Excelで作成した作業進捗表で管理する、という二重管理のような運用に落ち着き、プロジェクト自体は何とか回った。
しかし、タスク間の前後関係を正しく把握できていないメンバーも出てきて、後続タスクが始まった後に 前提作業の漏れが発覚して作業が止まる、といった問題が発生。
また、あるタスクについての検討経緯を把握しようとした際には、メールやチャットを遡って関係者とのやり取りを探す必要があり、 情報の分散によって不要な工数が発生することもあった。
これらの情報がチケットに集約されていれば防げたはずの事態も多く、今振り返ると「もったいなかったな…」と後悔が残るプロジェクトでした。
当時一緒に進めていただいた方々に本当にお詫び申し上げます...🙇‍♂️

チケット管理疲れ

背景

作業を細分化し、1つの作業ごとにチケットを起票する運用を導入。
レビューや連携のタイミングも漏れなく可視化することを目的に、タスク単位はかなり小さめに設定し、日々チケットの更新とステータス変更を徹底するようにメンバーへ依頼。
「これで漏れなく管理できる」と期待していたが、運用が進むにつれ、現場からは 「更新が多すぎて実務の時間が取られる」 、「チケットの操作ばかりで疲れる」 といった声が増加。

結果

ステータス更新やコメントの記載が実務と同じくらいの時間を要し、プロジェクト後半になると メンバーがチケットの更新を放棄。
結果として、ボード上では「進んでいない」ように見えるタスクが多くなり、実際の進捗との乖離が発生。管理者としても、正しく状況を把握できない状態に。

見通しの見えない構成

背景

過去に「計画通りに進まないから、先のチケットは作っても無駄」という反省があり、現時点で必要なものだけを都度作成する形をとっていたPJがあった。
運用初期はうまくいっているように見えた。ボードもすっきりしており、進行中の作業に集中できている。
しかし、プロジェクトが中盤に差し掛かると、メンバーから 「この後、どんな作業が待っているのか把握しづらい」、 「自分の作業がプロジェクト全体の中でどう位置づけられているか分からない」 といった声があがる。

結果

チケットが後出しで作成されるため、進捗報告のたびに「次に何が来るか」を毎回口頭で説明する必要があり、情報共有のコストが増大。

さらに、あるフェーズでリソースが一時的に逼迫した際、どのタスクを後回しにできるか判断しづらく、優先順位付けや再スケジューリングに時間を要しました。結果的に「見通しの悪さ」がリスク管理を難しくし、管理側、現場共にストレスを感じる状況に。

柔軟性を重視して短期的な視点で運用されていましたが、マスタスケジュールやクリティカルパスの確認の重要さが分かったPJだったそうです。

チケットの意味が分からない

背景

チケットの粒度や記載内容に統一ルールがなかったため、次第に「何が書いてあるのか分からないチケット」が大量に発生。

「このタスクって、具体的に何をすれば完了なんですか？」と尋ねられたチケットには、タイトルが「画面仕様確認」とだけ書かれており、説明欄にも「〇〇機能について仕様確認済み」と一言だけ。 誰が誰に何を確認したのか、どの画面が対象なのか、どんな結果だったのか、何も分からない状態。
他にも、「対応済み」とマークされているチケットに対して、別のメンバーが「この件、まだやってないですよね？」と指摘する場面もあり、情報の信頼性にも疑問生じる状態。

結果

チケットを見ても進捗や状況を把握することができず、結局、口頭やチャットでのやりとりに依存する結果に。
関係者が一目で分かるような目的、背景、判断、成果が書かれていないチケットが、 「記録」としても「指示」としても機能しなくなった例でした。

4つのプラクティス

ベストプラクティスではないのは私自身の経験が多く、世の中の試行回数を重ねた結果ではないためです...名前も無いのでいい感じに定義してます。
以下4つはPJ管理に困った方へのヒントとしてご活用ください💡

1. フェーズドリブン方式
2. エピック先行展開方式
3. フルスタック初期展開方式
4. 成果物ドリブン方式（チケット体系が大きく違うため今回は詳細説明省略 3つしかないじゃないか👹すみません🙇‍♂️）

観点	フェーズドリブン方式	エピック先行展開方式	フルスタック初期展開方式	成果物ドリブン方式
思想	フェーズ開始時に必要なチケットのみ展開	全体構造（Epic）を初期に定義し、詳細は直前に展開	初期にすべてのチケットを設計・展開しておく	成果物単位で必要な作業をチケット化
チケット構成	将来フェーズは持たず、必要な時点で作成	Epicで構造を先に持ち、詳細タスクは後から展開	すべての作業をチケット化して構造化	工程ではなく成果物ベースでチケットを構成
全体の見通し	直近の作業に集中、先の見通しは最小限	全体像を早期に把握しつつ、実行段階で詳細化	初期段階で完全に全体を見通せる構成	成果物単位では見通しやすいが、工程全体は弱くなる場合も
柔軟性	非常に高い。変更に強い	中程度。Epic構造の変更には一定の労力がかかる	低い。変更があると構成全体が崩れやすい	中程度。成果物設計に依存
管理コスト	各フェーズごとに設計が必要でやや負荷あり	初期にEpicを設計すれば、以降は比較的軽く運用可能	初期工数と維持工数の両方が大きい	成果物の定義とレビュー項目を整備する前提が必要
向いているプロジェクト	変更が多く、段階的に仕様が固まっていく案件	中長期の見通しが必要だが、詳細は直前でよい案件	要件が初期に固まり、規模が大きく自動化も志向する案件	成果物や納品物に明確な完了定義がある受託・SI案件

なお、これから利用するチケットは下記のように定義しております。
ここはPJによって管理方法が違うと思うので置き換えながら考えていただけると助かります。

Jira項目	内容（対応する実体）	補足
エピック	工程（例：要件定義、設計、開発、テストなど）	WBSの上位層
ストーリー	機能名（例：ログイン機能、検索機能）	各工程での対象機能
サブタスク	各機能ごとの具体的なタスク（例：API設計、UI設計）	作業の細分化
タスク	課題（例：設計課題など）	各機能に紐づく課題

フェーズドリブン方式

• 「設計→開発→テスト」など、フェーズが来てから考える
  • 必要最小限の設計と運用
    「現実と理想の乖離」、「チケット管理疲れ」に効果的

「計画しすぎて破綻するより、必要になったときに考える」思想に近く、変化に強いプロジェクト管理を実現したい場合に有効なアプローチ
PoCなど請負開発ではなく準委任で実施するようなPJで採用した結果うまく活用できた

観点	フェーズドリブン方式
思想	フェーズ開始時に必要なチケットのみ展開
チケット構成	将来フェーズは持たず、必要な時点で作成
全体の見通し	直近の作業に集中、先の見通しは最小限
柔軟性	非常に高い。変更に強い
管理コスト	各フェーズごとに設計が必要でやや負荷あり
向いているプロジェクト	変更が多く、段階的に仕様が固まっていく案件

直近フェーズのタスクのみを期日設定して管理

エピック先行展開方式

• 全体の「設計→開発→テスト」構造を最初に作り、中身（タスク）は直前に追加していく
  • マスタスケジュールを意識した形
    「現実と理想の乖離」、「チケット管理疲れ」に効果的

プロジェクトの初期段階で全体の構造をあらかじめ定義し、その後、各フェーズの開始直前に必要なタスクチケットを展開していくスタイル。
全体の作業範囲や流れを早期に可視化しつつ、詳細化は柔軟に対応できるため、「構造は固めたいが、運用は軽くしたい」 といったニーズにマッチする。
私はウォーターフォールの場合、見積時点で全体作業はできる限り把握した状態でPJに入るが、あえて全部をチケット化せず、工程開始（または1Wほど前）のタイミングでチケットを作成することで手戻りなく計画できる。
チームとしては全体の作業を確認できる方が良いので見積等で利用した事前のタスク整理結果はチケット化しないものの、チームが閲覧できる場所に配置されているのが好ましい。

（本当はない方が良いが）現実論、工程が並行で進む場合もあるので、その際は各工程にまたがった期日管理を意識する必要がある。

ウォーターフォールであるが、不確実性の高い案件で利用すると手戻りなく進められる観点から効率が良かった。

観点	エピック先行展開方式
思想	全体構造（Epic）を初期に定義し、詳細は直前に展開
チケット構成	Epicで構造を先に持ち、詳細タスクは後から展開
全体の見通し	全体像を早期に把握しつつ、実行段階で詳細化
柔軟性	中程度。Epic構造の変更には一定の労力がかかる
管理コスト	初期にEpicを設計すれば、以降は比較的軽く運用可能
向いているプロジェクト	中長期の見通しが必要だが、詳細は直前でよい案件

全体フェーズすべてのエピックを作成・期日設定して管理

フルスタック初期展開方式

• すべてのチケットを最初から作成
  • リソース変動等の事前計画や報告が必要な際に利用

プロジェクトの初期段階で全ての作業を洗い出し、すべてのチケットを一括で作成・整備しておくスタイル。
要件やスコープが明確に定まっているプロジェクトにおいて、初期から全体の進め方を設計し、実行段階では迷いなく作業できるようにすることを目的とする。
最大のメリットは、全体の可視性と統制のしやすさ。
全チケットが揃っているため、進捗管理、リソース配分、ステークホルダーへの報告などが効率的に行える。
一方で、初期段階でのチケット作成には多大な工数がかかり、構成の精度が重要となる。
要件変更やスコープの揺れがあると、既に作成したチケットの修正・削除・再設計が必要になるため、柔軟性には乏しく、特に変動が多いプロジェクトでは運用破綻のリスクがある。（「現実と理想の乖離」、「チケット管理疲れ」が起きる要因でもある）

「確実にやることが決まっている」、「繰り返し要素が多くパターン化しやすい」 といったプロジェクトで、綿密な初期設計と運用基盤が整っている場合に最も効果を発揮する方式と考えており、運用の定型作業でこの方式を利用することで抜け漏れなく正確に作業を完遂することができている。

観点	フルスタック初期展開方式
思想	初期にすべてのチケットを設計・展開しておく
チケット構成	すべての作業をチケット化して構造化
全体の見通し	初期段階で完全に全体を見通せる構成
柔軟性	低い。変更があると構成全体が崩れやすい
管理コスト	初期工数と維持工数の両方が大きい
向いているプロジェクト	要件が初期に固まり、規模が大きく自動化も志向する案件

おわりに

チケット管理は、単なる「作業の見える化ツール」ではなく、プロジェクトの進め方や文化そのものを映す鏡なのでは...と思います。
チケットが丁寧に運用されているチームは、たいていコミュニケーションが円滑で、合意や判断の履歴も明確です。
一方で、形式だけのチケット管理に陥ると、情報が分散し、手戻りや認識ズレの温床にもなりかねません。

重要なのは、「どの方式が正しいか」ではなく、「そのプロジェクトに合った管理スタイルは何か」 を見極めることだと考えています。
プロジェクトの規模や期間、要員構成、変化の頻度などによって最適なチケット管理の粒度やタイミングは大きく変わります。だからこそ、一般的な情報としての“型”や、成功例の“型”を知っておくことで、現場ごとに適した運用を選択・設計できるようになれるのかな...と思います。

プロジェクトの風紀や体制、特性をよく観察し、現場の実態と向き合いながら、「ちょうどいい管理」の形をチームと一緒に作っていける
それが、プロジェクトマネジメントにおける重要な要素かなと思います。

書きながら、AIがPJ資料をクローリングして最適なマネジメントを策定してくれる日も近いのかな...と思ったりしました。
温かみのあるAIであってほしい😺