翔泳社のショップのセールでポイント還元セールしていたときに『チケット駆動開発』を買って読んだ。
うちではRedmineでチケット駆動開発をしているんだけれど、なんかいまいちしっくりきていなかった。20代の頃に、この本の著者の小川さんのブログをよく読んでいて、チケット駆動開発の考え方にめちゃめちゃ感銘を受けて、それをやるようにしていた。自分の中では非常にしっくりきていたので、チームのメンバーが少なくて自分の裁量がかなりあるようなケースだと全然問題なくできてたんだけれど、今のチームになってから、形骸化した『なんちゃってスクラム』になっていたから、それを打破するためにカンバンに変えたりとか、色々としていた。
カンバンに変えたチームはそれはそれでうまくいくようになったからよかったかなと思うんだけれど、新製品を作るほうのチームではちゃんとスクラムできるんじゃないか？と思ってやろうとしてみたけれど、全然ダメで、結果、なんちゃってスクラムになっていた。ただ、メンバーが経験を積んできて成長してきたり、スクラムに対する理解が深まってきたことで、だいぶ良くなっている。良くなっているんだけれど、Redmineの運用の仕方が悪いのか、今でもそこまでうまくいってないと思う。単に、俺のプロジェクト管理能力が低いとも言えるが…。
最近、Geminiと相談しながら、Redmineの綺麗な運用方法を模索していたのだけれど、そこである程度クリアにすることができた。 ただ、その中でもカテゴリやバージョンの使い方、カスタムフィールドの使い方等、非常に悩んでいたので、他所がどういうふうに使っているのかを知りたかったし、自分の考えの正しさを確認したいという気持ちがあった。
バージョンの扱い方
最初、バージョンの使い方が下手過ぎた。開発フェーズとして使ってしまっていた。一次開発、二次開発のように…。 一次開発なんて、開発するものが大量にあるからRedmine上でWBSを上手くつくることができないのと大量のチケットのせいでクエリが重すぎて開けなくなったりしていた。 そのせいで、一次開発のリリースは済んでいるのに、対応されていないチケットがゾンビのように残っていた。
自分も、自身のタスクに追われてしまって、あるいはそれを言い訳に、プロジェクト全体を見る余裕がなかった。 ほぼ誰も過去のバージョンを整理することもなく、二次開発・三次開発と進んでいて、綱渡りでやっているような状態で、そんな状態だから結局タスクに追われて余裕がなくなるというスパイラルだった。 過去のチケット棚卸も時々やっているが、そんなに活かせてない。
本を読んでいるうちに、バージョンをどう扱うかというところが載っていて、リリース予定バージョン、ベースライン、イテレーション、マイルストーン、ビジネス要求として考えるというのがあった。
特別なバージョン
この中で、イテレーションのところにて、いつやるか分からない課題系を扱う特別なバージョンを用意しているという話があり、これは即採用させてもらった。
- 35期3Q_課題一覧
- 35期3Q_バグ一覧
を作った。本では、内部課題というバージョンを作っておいて、イテレーションが変わるタイミングで、そのイテレーションのバージョンにチケットを付け替えるのであろうけれど、うちの部署ではアジャイルプラグインを使っていて、イテレーションはそちらで管理しているため、バージョンは使わない。ただ、四半期毎にどれくらいの課題に対応したか、どれくらいのバグを対応したかを見える化できるやん！ということで採用。3Qで終わらなかったチケットは35期4Q_課題一覧などのほうに送られる。
昔のバージョンに紐づいたままのゾンビチケットについて、メンバーに確認をとりながら課題一覧のほうに移動させて、スプリントプランニングの対象にさせていったり、整地日（リファクタリング等を行う日）に対応してもらうなどで、ゾンビチケットを撃退していきたい。
マイルストーンとして考える
読んでいて一番しっくりくるのが、これだった。この機能をいつ頃までに確認できるようにしたい、という話があるのに、複数の機能開発が二次開発という大きなバージョンで括られている、かつ、各機能の予定日を入力する習慣がなかったものだから、全然見える化できていなかった。
この考え方を意識してバージョンを定義してチケットの関連付けをしっかり行ったら、そこそこ綺麗なガントチャートが出来上がって感動した。 もっと細かくマイルストーンを定義して、進捗を管理すべきだったと痛感しているところだが、余裕がなかったので仕方がない。未来でちゃんとしていけるようにしたい。
カスタムクエリを使ってシステム連携する
チケット一覧のところで、検索条件を保存することができるのだが、そこまで使いこなしてなかった。だが、これはめちゃめちゃ使える！！本を読むまでは、できることはもちろん知っていたんだけれど、そこまで活かせてなかった。 特に、RSSフィード（Atomフィード）でチケットを購読することができるのがでかい。
他のチームからの作業依頼のチケットを見るためのカスタムクエリを作って、それのRSSフィードをMicrosoftのPowerAutomateで購読して、チケットが登録されたらTeamsにメンションを送るようにした。Redmineでも担当者に登録されたらメールが送られてくるのだが、もうコミュニケーションがTeams等のチャットツールが主戦場でメールはあまり見ないので、これでだいぶ良くなった。
昔のチケット駆動開発と今のチケット駆動開発の違和感の正体
本を読んでいるときに思ったのだが、この本を読んでいると「チケットの情報が集まってくる」と書いてあったのだが、現代はなかなかそうなっていない。その原因はさきほども書いたが、コミュニケーションの主戦場がメールではなくチャットツールになっているからだ。
昔は、チケットに情報を書いて、1つ1つのチケットが掲示板のように扱われて、そこで議論が深まっていっていたのだが、今は議論は基本的にチャットツールでやる。なので、決まったことがチャットツールに残っているせいで、チケットに反映されないことが多くなってきた。 何故、小規模なチームの時はそこそこうまくいってたかと考えたんだが、議論に自分が参加しているから、決まったことをチケットに転記していた。しかし、今は参加しないこともあるから、それがそのままになったり、忙しさのせいで転記するのを忘れることがあった。
コミュニケーションツールの変化が、チケット駆動開発に影響を与えているということに気付けたので、今後は決まったことはチケットに転記するように伝えた。
とはいえ、チケット上だけでもやりとりできるんじゃないか？と考えて試してみたが、ダメだった。みんな、ほとんどRedmineからのメール見てない。結局、Teamsで「このチケットについてなんですが～」ってことになった。結局、そこのやりとりを転記した。
感想
チケット駆動開発に関する本だから、いろんな障害管理ツールの話が出てきて、それも学びがあったし、チケット駆動開発自体の概念や発展形の話、アンチパターンに関すること等があり、今の自分にとっては凄く発見が多くてよかった。この本の前に、Redmineによるタスクマネジメント実践技法という本が出ているらしくて、「詳しくはそちらを見てほしい」という書かれ方をしていたのでそちらも買ってみたが、まだ読めていない。テスト管理ツールとの連携の話があるみたいだったので、そちらも現代に合わせる形で調査してみたいと考えている。
