チケット駆動開発について今更考えてみた

• 概要
• チケット駆動開発とは
  • どんな使い方をしていたか
• メリットとかイケてるところ
• デメリットとイケてないところ
  • その他アンチパターン
• まとめと所感

概要

1年弱くらいチケット駆動開発をして来て感じたことがあったので今更ながらメリット・デメリットの観点でまとめてみました

チケット駆動開発とは

作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル

Wikipediaより一部を抜粋

要するに「やること」や「やりたい」ことをチケットという単位で管理し開発を進める手法
Githubのissueみたいな感じ、Closeされれば終了

また今回、私はBTSにRedmineを使いましたのでRedmineでの話を中心に記載したいと思います

どんな使い方をしていたか

特殊な使い方をしていたつもりはないので至って普通かと思いますがコンテキストをまとめておいたほうがいいと思うので簡単に記載します

• チケット
  
  • チケットの発行（開発タスク、bugfix、ツール開発、テスト実施、次期開発、やりたいこと、調査依頼等々何かあれば発行）
  • チケットへのカテゴリ付与（必須）
  • チケットへのトラッカー付与（必須）
  • チケットのステータスの活用（終わった場合は必ず終了にする）（必須）
  • チケットを担当者に割り当てる（必須）
  • 本文、タイトルは基本フリーフォーマット、開始日、進捗率も特にルールはなし（任意）
  • 子チケット、関連チケットも自由に作成可能（任意）
• wiki
  
  • 基本はフリーフォーマット
  • 記事録、ノウハウ、検証記録等を記載していく
  • 記載する際の基準はない（このタイミングで、これを書いてねみたいなのはない）
• 文書管理
  
  • ルールは特に無し、置きたいものを自由に置く

基本的には上記の機能を使うことが多かったです
上記を踏まえて運用した上でのメリット・デメリットを考えてみました

メリットとかイケてるところ

• 進捗を把握しやすい
  全てはチケット管理なのでシンプルかつ明確にタスク管理することができると思います
  進捗率や期日も設定できるのでガントチャート的な見え方もできてGood
  優先度を駆使すれば今やるべきことがすぐわかる
  子チケットを駆使すればタスクのカテゴライズができて把握しやすい

• マネージメントが簡単
  日本の会社のようにヒエラルキー型の会社にはがっつりハマると思います
  上の人がチケット切って「はい、これやって、これやって」とホイホイ下の人に割り当てればいいだけなのでマネージメントはめちゃくちゃ簡単
  アサインしている人ごとにチケットも見れるのでリソースの空き状況もすぐに把握できる
  チケットさえちゃんと作成できていればという点はあるが

• ルールが勝手に出来上がる（出来上がった）
  これはいい事象かなと思ってます
  例えば、文書管理のフォルダ名とかwikiのタイトルとかは全くルールがない状態で初めたんですが、初めに誰かが作成した命名規則的なものを次の人がそれに沿って「いい感じ」に作ってくれるようになりました
  例えば、wikiページは必ずYYYYMMDD_で始まるように記載していたら、他の人もそれに合わせて書いてくれるようになったりとか、文書管理のフォルダ名もはじめに00_hogehogeとか数字をつけるようにしていたら次のフォルダ名が01_barbarとかになって自然にルールができていたのはいいなと感じました

• 通知機能
  チケットを更新するとメール通知できるので他の人の作業内容が把握しやすいです
  自分はgrowlと組み合わせて担当者が自分にアサインされるとgrowlで通知してくれる機能を作ってチケットの見落としを防いでいました

• 低学習コスト
  かなり個人的な間隔もありますが、そこまで勉強しなくても使えると思います
  ツールにもよりけりですが、Redmineに関しては低いと思います
  ただ、機能は本当にたくさんあるので使い込もうとするとそれなりのコストがかかると思っていただければと思います

デメリットとイケてないところ

• クローズされない亡霊のようなゾンビチケットができあがってしまう
  「よし、絶対やるぞ！」とその場の勢いで作成したチケットが半年後に誰にもアサインされずに残り続けてしまう
  残り続けてしまうこと自体は「やるべきこと」なのでいいのですが、誰にもアサインされず「いや、これ誰がやるんだよ･･･」的な感じでみんなから無視され続けてクローズもされず、ほっとかれる現象が発生してしまう
  こうなってしまうと一生消化されることがなく「やっほうがいいのかな･･･でも他に優先度高いことあるし･･･今更そんなのやってるなよとか言われそうだし･･･」とか、精神衛生上もよくない、疑心暗鬼、そわそわしちゃう
  なのでそんなチケットが出来ちゃわないために「6ヶ月以上更新のないチケットはクローズして別チケットを発行して誰かにアサインする」とか「アサインを外して対応保留カテゴリに割り当てる」などルールを作ることが必要かなと感じた
  ルールでどうにもならないときには「カンバン機能」や「API」もあるので可視化、自動化でシステムに解決してもらうのがいいと思います

• チケットの粒度
  なんでもかんでもチケットが切れる状況だったので、開発者それぞれでチケットの粒度が統一されていないのが微妙でした
  これも「ルール」の問題なので事前に粒度のルールを決めておけばいい話なのですが、そもそも粒度をルール化するのは難しいという問題点もあります
  やるとしたら粒度のルールというよりかはチケットを発行できる人を制限する感じかと思いますが、それもそれで開発者の自由を縛るようなルールなのでやるのは微妙かと思います
  私の場合はだんだん各人が粒度を「暗黙的に」理解したので徐々によくなりましたが、最初のほうは1つのチケットにいろんな作業記録をコミットメントしまくってカオスな状況でした

• 検索機能が弱い
  デフォルト提供されている検索がそこまで賢くないのが残念でした
  せっかくチケットやwikiに貯めたノウハウもうまく取り出せないんじゃ意味がありません
  検索が微妙だった分カテゴリやトラッカーを適切に付与してカバーしてましたが、さすがに規模が大きくなると検索なしでは厳しかったです
  また、文書管理にあるファイル名と説明までは検索対象にできるのですが、ファイルの中までは検索対象にならないので、なるべく文書管理にノウハウを貯めるようなことは避けるようにしました
  よくある設計書にオフィス製品を使っちゃう問題もありましたが、極力ドキュメント類はコードに落とすか、wikiに記載するようにしました

その他アンチパターン

• wikiに動的に変化する情報を記載する
  なるべくwikiには普遍的な情報を記載する
  よくwikiにサーバ構成図などを書くが例えば頻繁にサーバが追加されたり削除されたりすると更新を忘れて管理が破綻する

まとめと所感

• GoodかBadかで言うとGood
  100点満点な開発方法ではないと思いますが、10点とか20点でもないです
  man powerで解決しなければいけない面（ルールとか縛りとか）もありますが、システム的に解決できる部分もあるので、なんとかなります
  全然、開発手法が決まっていなくてどうしたらいいかわからんときには、とりあえずチケット駆動にしておけばなんとかなると思います

• チケットエンジニア
  簡単に言うとチケットの進捗とか状況とかを管理する人
  ゾンビチケットやアサインされていない人を見つけたときに適切にアサインしたりする人
  マネージャではないので進捗管理とかタスク割り当てをするわけではなく、チケット駆動が回るために適切に振る舞う人
  的な人がいると更によくなるとは思うが、そこまでしてやるかというのと
  そもそも、そこにリソースを割り当てる人がいないという問題があるので正直やる価値はないと思うが、なんとなく思ったので記載

• ツールは
  今回はRedmineを例に話を進めましたが、それ以外にもめちゃくちゃあります
  参考 -> バグ管理システム
  「決定版はどれだ」という議論をするときっとキリがないのでここではしませんが、正直どれでもいいと思います
  あえて進めるならオープンソースでまだ開発が続いているツールにするのがいいと思いますあとは、拡張機能が作れるとか

文字ばかりですが、以上です
これからもチケット駆動を続けるのでまた何かあれば別ポストでもして、今回と見比べて解決してる点とかしてない点とか比較すると面白いかなと思いました