チケット駆動開発はまさにチケット管理ゲームだ
Redmineでチケット駆動開発をやっていると、まるでゲームをやっている感覚になってきた。
そのフィーリングをメモ。
【参考】
チケット駆動開発はステータス追跡システム: プログラマの思索
【1】ゲームというモデルには特徴がある。
一つはゴールがあること。
桃太郎電鉄やファイナルファンタジーも、資産が一番大きいこと、全てのステージをクリアすることがゴール。
つまり、成功の終了条件がある。
当然、ゴールに達せずにゲームオーバーする時もある。
完了できずに途中リタイアの時もある。
チケット駆動開発のゴールは、期日までに全てのチケットを終了ステータスにして、システムをリリースすること。
そのために、Redmineバージョン単位にタスクをグループ化して、小刻みに定期的にリリースしながら、システムの品質も機能も拡張していく。
いきなり最終ゴールを目指すのではなく、ステージを踏みながらゴールに近づいていく。
その方が確実なのだ。
とはいえ、チケット駆動開発を運用してもうまく回らず、破綻する場合もある。
チケットが乱発されたり、誰もチケットに対処せずに放置したり、一人がチケットを溜め込んだりして、期日までにリリースできなかったら、ゲームオーバーと同じ。
チケット駆動開発をやっていると、XPの言うドライブ(運転)の感覚が分かってくる。
ソフトウェア開発のプロジェクト管理は、いつもコントロール(ドライブ)しないと、すぐにハンドルで制御できなくなって、デスマーチに陥りやすい。
ゲームオーバーにならないように、チケットを取捨選択しながら、リリースに近づけるのが大事。
ゴールに近づくには、定石があるのだ。
その定石は既に色んなプラクティスが知られているので、うまく当てはめればいい。
【2】二つ目はルールがあること。
何でもかんでも可能なわけではなく、行為がルールによって限定される。
代わりにアイテムがある。
パワーアップできたり、防御できるアイテムがある。
それらアイテムを上手く使いこなすのが大事。
チケット駆動開発では、チケットを起票する時、チケットの内容だけでなく、開始日・終了日、担当者、マイルストーン(バージョン)を入力しなければならない。
又、チケットをCloseする時は、ワークフロー管理機能によって、必ずリーダーがCloseするなどのルールもあるだろう。
チケットのライフサイクルには厳格なルールがある。
Redmineによるチケット駆動開発のアイテムは、リリース計画(ロードマップ)と各種のチケット集計機能、そしてワークフロー管理、トレーサビリティの4つ。
まず、ロードマップで大まかなリリース計画を立てて、イテレーション計画で更にタスクを詳細化する。
当然、リリース計画は、イテレーション実施中も現状に合わせて柔軟に変えて、状況を見える化する。
地図が最新化されていなければ、ゴールまでの距離も分からない。
イテレーション実施中は、ガントチャート、かんばん、サマリなど各種のチケット集計機能で進捗やリスクをリアルタイムに把握する。
自分たちの能力はどれくらいなのか、今どれくらい自分たちは傷ついているのか、今後どんなトラップがありそうなのか、を早めに検知できれば、リスクに対して準備しやすい。
又、チケットの種類に応じてワークフローを変えて、ペア作業するときもあれば、顧客と質問や問合せをキャッチボールする時もある。
あるいは、チケットとソースの相互リンクによって、成果物の履歴管理だけでなく、ソース修正の変更理由を追跡できて、コミュニケーション向上に役立てたりする。
チケット駆動開発のアイテムは、特にRedmineならRubyで簡単にパワーアップできる。
足りない武器は、自分でアイテムを作ってしまえばいい。
【3】何よりもゲームは楽しい。
ゲームをやる事自体が楽しい。
夢中になって我を忘れてしまう。
チケット駆動開発をやっていると、自分たちの作業履歴がタイムラインとして残る。
タイムラインをふりかえるだけでも、結構気づきがある。
特に新人は、作業履歴やコミット履歴を振り返って、自分は半年でこれだけ仕事できたのだ、と自信がつくらしい。
チケット駆動開発はプロジェクトファシリテーション(PF)と相性が良い。
ニコニコカレンダー、かんばん、ソフトウェアあんどんなどのアイテムは全てRedmine上で実現可能だ。
朝会で毎日の自分のタスクを確認するだけでなく、プロジェクトのゴールや各人の役割を共有する。
リリース後のふりかえりで、イテレーションの作業ログを見ながら、自分たちの能力を客観的に直視して、次のイテレーションへ向けて、プロセス改善していく。
KPTによるふりかえりの結果をWikiに残して、数回ふりかえりを続けると、各人の成長、チームの成長が分かるので、モチベーションアップにつながる。
それが楽しい。
下記の記事を読んで、似たような感想を持った。
日々是精進。: 2/17: デブサミ 2011 / チケット管理システム大決戦
(引用開始)
Face To Faceのやりとりの大切さは、スピーカーの皆さんが仰っておりましたが、会話の中で出てきた本当に共有すべきことや、お互いに合意し合った証、アイディアの種は、大切にプラットフォーム上に記していきたいな、と思いました。
きっと、あとでITS上のタイムラインを眺めることで、自分たちのプロジェクトの軌跡をたどることができる、大切な『場』になってくれるんじゃないかな~、と思っています。
(引用終了)
そんなことを考えると、チケット駆動開発は単なるソフトウェア開発のタスク管理だけでなく、チケットをトランプのカードに見立てて、どれだけ早くチケットをこなしながら、リリースと言うゴールに近づけるのか、というゲームをやっている気がしてくる。
XPの「計画ゲーム」というプラクティスは、多分そういうことを意味していたのではないかと直感している。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
「Redmine」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmineはチェンジマネジメントのツールであるべきだ(2026.07.13)
「プロジェクトファシリテーション」カテゴリの記事
- 組織変革の鍵を「聞く」体験から探る(2026.06.14)
- PM理論で読み解く日本人リーダーの弱点(2026.05.12)
- astahでPJ管理もプロセス設計もアイデア発想も全て表現したい(2025.10.25)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
「チケット駆動開発」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
「Agile」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- アジャイル開発を強化するキルチェーン進化の歴史~VUCA時代におけるモノづくりの新アーキテクチャ(2026.08.11)
- 脱PDCA!DXを加速する超高速戦略「KillChain」(2026.08.10)


コメント