受託案件の現場をRedmineチケット駆動で回すための具体的な運用ルール

「チケットはちゃんと切っています」——そう言うプロジェクトが、なぜか回っていない。

PM歴10年以上、受託・SES・内製を渡り歩いてきた私が何度も見てきた光景です。チケット管理ツールは入っている。Redmineも使っている。なのに、いざ「現在の進捗は？」と聞くと「ちょっと確認します」が返ってくる。チケット一覧を見ても、何が動いていて何が詰まっているのかよく分からない。

問題はツールではなく、チケットに「誰が・いつ・何をしたら次に進めるか」が書かれていないことにある、というのが今の私の結論です。

今回は、弊社の受託案件でチケット運用を見直した実記録を書きます。「そんなことか」と思うかもしれません。でも、理屈としては簡単なことを現場に定着させるのが一番難しいんです。

最初にやった失敗：チケットが「メモ帳」になっていた

私がある中規模案件（エンジニア5名・期間4か月）のPMを引き受けたとき、前任のリーダーから引き継いだRedmineには300枚近いチケットがありました。

一見、管理されているように見えた。でも実態はひどかった。

チケットのタイトルは「認証周りの修正」「管理画面バグ対応」のような曖昧なものばかり。内容欄には「後で詳細を書く」が3か月放置されている。最悪なのは「進行中」のチケットが82枚あり、そのうち実際に動いているものがどれか誰も把握していなかったことです。

理屈はそうなんですが、最初は「チケットをちゃんと書けばいい」という話だと思っていました。全員に「説明をちゃんと書いてください」と頼んだ。2週間でまた同じ状態に戻りました。

チケットを「書かせる」だけでは何も変わらない。 チケットの粒度・ステータス遷移・完了条件、この3つを明示的にルール化しなければ、チームは自分なりの解釈で動き続けます。

ルール1：チケットの粒度は「半日〜2日」に収める

最初に手をつけたのがここです。

「認証周りの修正」というチケットは大きすぎる。「ログイン時のJWTトークン生成ロジックをリファクタリングする」まで分解して初めてチケットになる。逆に「変数名をリネーム」という1行で終わる作業をチケットに起こす必要はない。

私たちが基準にしているのは 1チケット = 半日〜2日の作業量 です。

この粒度にした理由は2つあります。ひとつは 進捗の視認性。1チケット2日以内なら、3日更新がなければ「詰まっている」とすぐ判断できる。もうひとつは 見積もり精度。半日〜2日粒度のタスクは見積もり誤差が少ない。5日以上の作業を1枚のチケットにすると、3日目に「やっぱり2週間かかります」が発覚する。

実際、この粒度基準を徹底した後から、週次の進捗ミーティングで「なぜ遅れているのか」がチケット一覧を見るだけで分かるようになりました。

ルール2：ステータス遷移を「プロトコル」として定義する

次に取り組んだのがステータスです。

デフォルトのRedmineには「未着手 → 進行中 → 解決 → 完了」のような汎用的なステータスが入っています。これをそのまま使うのは危険です。「解決」と「完了」の違いが人によってバラバラになる。「進行中」に一度入れたら「レビュー待ちだけど進行中のまま」「仕様確認中だけど進行中のまま」という状態が生まれる。

私たちはRedmineのステータスを以下のように再定義しました（受託案件のデフォルトとして使っているもの）:

未着手 → 実装中 → レビュー待ち → レビュー中 → 完了待ち確認 → 完了

それだけでなく、各ステータス遷移に「誰が・何を確認したら次に進めるか」を明文化しました。

正直なところ、最初はこれを書いたとき「当たり前すぎる」とメンバーに笑われました。でも導入後2週間で「レビュー待ちが6件溜まっている」「レビュアーが詰まっている」が自動的に可視化されるようになった。以前は「なんか進んでいない気がする」という感覚論でしか語れなかった問題が、数字で話せるようになります。

ルール3：完了条件（Definition of Done）をチケットに必ず書く

これが一番効きました。そして一番定着させるのに時間がかかりました。

以前の現場では、チケットの「完了」の定義が人によって違っていた。「実装が終わった」「テストが通った」「レビューが通った」「本番に反映された」——どれが「完了」かを誰も定義していなかった。

今はチケット作成時に「受け入れ条件」欄を必須にしています。フォーマットはシンプルです:

## 受け入れ条件

- [ ] ○○機能が正常に動作すること（手順: ○○画面から○○操作を実行）
- [ ] 既存テストが全件パスすること（npm test で確認）
- [ ] ○○エラーが発生しないこと（○○のログを確認）
- [ ] コードレビューでの指摘がすべてResolve済みであること

これを全チケットに書くようになってから、手戻りが目に見えて減りました。数値で言うと、導入前3か月の手戻り件数（完了後に「やっぱり修正が必要」と再オープンされたチケット数）が月平均11件だったのが、導入後3か月で月平均7件に減っています。約40%の削減です。

完了条件を事前に書くことで、実装者は「何ができれば終わりか」を最初から意識する。レビュアーは「何を確認すればいいか」が明確になる。PMは「なぜ完了ではないか」を具体的に説明できる。

ただし、完了条件が形式的な箇条書きになると意味がありません。「ちゃんと動くこと」は受け入れ条件ではない。「どの画面で・どの操作をして・どの状態になっていれば完了か」という再現可能な記述にすること——これは最初のうちチケット作成時にレビューをして、基準を体に覚えてもらうしかありません。

想定外だった話：AIエージェントも同じルールで回せた

実はこの運用ルールを作った後、弊社では一部の定型作業をAIエージェント（Claude）に任せる試みを始めました。

最初は「AIにチケット管理させるには、専用のインターフェースや特別なルールが必要では」と思っていました。ところが、AIエージェントは人間と同じRedmineの画面・同じチケット運用・同じステータス遷移をそのまま使えることが分かった。

理由は単純で、私たちが作ったチケット運用が**「誰が・いつ・何を確認したら次に進むか」を曖昧なくコンテキストに書き込んでいた**からです。AIエージェントが判断するためには十分な情報がチケットに記載されている状態になっていた。人間のために明示化したルールが、そのままAIにとっても解釈可能な形式になっていたわけです。

ツールを変えなかった設計判断は正解でした。新しいAI専用のキューシステムを導入するコストや学習コストはゼロ。AIエージェントが作業記録をチケットコメントとして残すので、監査ログとしても機能する。人間もAIも同じ「チケット一覧」で進捗を把握できる。

チケット運用テンプレート（改善余地あり）

参考までに、現在使っているチケット本文のテンプレートを貼ります。これはまだ改善中で、「想定外な事象」欄は追加してから日が浅く、書き方にばらつきが残っています。

## 概要

<!-- 1〜3文で目的と背景を書く -->

## 作業内容

1. ○○をする
2. △△を確認する
3. □□をコミットする

## 受け入れ条件

- [ ] （再現可能な確認手順＋期待結果を書く）

## 想定外な事象への対応方針 ← 改善余地あり

<!-- 作業中に想定外が起きた場合どうするか。現状「PMに確認」と書いてあるケースが多く、もっと細かく書きたい -->

## 参考

<!-- 関連チケット・ドキュメントへのリンク -->

「想定外な事象への対応方針」欄は、前任者がいないプロジェクトや、仕様が不安定な案件でとくに重要になってきます。AIエージェントが実行する場合は、この欄がないと過度に保守的な判断に寄りすぎる傾向があります。ここはもう少し型化できると思っていて、現在試行中です。

振り返って

「チケット管理ツールは入っているのに現場が回らない」の本質は、ツールの問題でも、メンバーのリテラシーの問題でもなかった。運用ルールが暗黙知のまま共有されていなかっただけでした。

フレームワークは目的ではなく道具、というのが私の持論です。PMBOKを読んでいたときに「完了の定義（Definition of Done）」という概念は知っていました。でも現場に落とすには、それをRedmineのどの欄にどんな書式で書くか、誰がレビューするか、破ったらどうなるかまで決めて初めて機能する。

今後は「想定外な事象への対応方針」欄の標準化と、AIエージェントが読んで自律的に判断できる粒度の受け入れ条件フォーマットを整備していきたいと思っています。「AIと人間が同じチケットキューで並走する」という状態が当たり前になってきた今、チケットの書き方そのものの設計が、プロジェクトの実行速度を決める要素になりつつあります。