チケット駆動開発で作業管理はしないほうがいい
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。
基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。
チケット駆動開発とウォーターフォール
パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。
この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。
僕自身はBTS（Bug Tracking System/課題管理ツール）を開発プロセスに組み込むことを数年前から取り組んでいたので、"チケット駆動開発"というものがアジャイルという文脈だけではなく、広くソフトウェア開発プロセス全般に広まって欲しいと考えています。今だにEXCELで課題管理しているとか、使いにくいお手製ツールにこだわっているとか頭が悪いとしか思えn、はっ、今日の芸風はこっちではありませんね。
さて、WF的な新規案件の開発現場でチケット駆動開発を採用する場合のノウハウを2つ紹介します。1つめが「作業計画にチケットを使うことなかれ」、2つめが「チケットはコミュニケーション手段」です。
作業計画にチケットを使うことなかれ
1つめは前述の通り「作業計画にチケットを使ってはいけない」ということです。では何を使うかと言えばWBSWBSを元にしたガントチャートによる管理手法（以下WBSと呼称 ※追記1を参照）です。WBSというのは本当に良く出来たツールで、タスクを時間軸とリソース（人）に割り付けて管理します。タスクの前後関係や依存関係を明示するため、タスクを組み替える場合にどういった影響があるのかを一目で理解することができます。
アジャイルの場合はタイムボックスで棚卸をしますが、タイムボックスにしていない場合でも一定のタイミングでスケジュールの進捗を棚卸する必要があります。そのときのよりどころがWBSです。イナズマ線と言われますが、あれは問題が分かりやすく表現できます。
WBS批判として「PMが予定にこだわってズレることが許されない。そんな管理に意味が無い」というのがありますが、もう完全に同意です。それはWBSの問題ではなく、PMの問題です。
WBSにおける予定と実績のズレは「何かが起きている」というシグナルであり、それを素早く見つけて対処するのがPMの仕事です。WBSというのは予定と実績の差を把握するためのツールであり、予定通りに物事が行くためのおまじないではありません。だいたい、予定と実績がズレないなんてありないことで、予定通りに進んでいるWBSとか、疑いの目でしか見れません。それはさておき。
WBSではなく、チケットで作業管理をしていると個別のチケットの状況ははっきりしますが、全体としての前後関係を視覚化することが難しくなります。たとえば1つのチケットの進捗がずれると、どこに影響が出るのかとかが把握しにくくなります。
RedmineはWBS風に表示できるよ！と思われるかもしれませんが「ココの日付を2日ずらしたから後も全部ずれる」みたいなことはできないですよね（する必要も無いです）。RedmineのWBSビューは実績の視覚化であって予定の確認として使うのは面倒なはずです。RedmineのWBSビューでご丁寧に予定を立てている（チケット1枚1枚にちまちま開始日付をいれている）方はEXCELとか使った方が簡単に管理ができると思います。
もちろん、こうしたチケットの特性がダメなわけではありません。アジャイル管理の中ではタイムボックスの中で工数枠にチケットを割り付けたら、あとは優先順位でやっていけばいいわけで細かい前後関係などを管理する必要は無いでしょう。これはこれで良いのです。あきぴーさんとは「WBSはPM視点のトップダウンで、チケットは開発視点のボトムアップ」みたいな合意をしました。
余談ですがチケットをくみ上げて全体視点を作るようなカンバンは興味深いアプローチです。カンバンは要員が未確定でも確定でも利用可能で、チケットのステータスを明確に伝えることができる上、時間軸を厳しくは求めません。WBSがリソースと時間を厳格に定義し、ステータスは進捗率でしか表現できないのと対比すると違いがよく分かります。
というわけで、規模が大きい場合や新規開発でアジャイル的に進められない場合には作業管理にWBSを使った方が良いのです。
ですが、プロジェクトには計画にしにくいタスクがあります。それがQAやバグなど、発生することは分かっているけど具体的な内容を予定することができない作業です。こうした作業は発生したら一覧にして個別の課題を細かくトレースする必要があります。発生時点では影響が見えていないため、それがプロジェクトのリスク（不確定要素）だからです。
こうした"計画外に発生したもの"はチケット/BTSでの管理が非常に向いています。ですので「計画できることはWBSで。計画できないことはチケットで」というのが僕の主張です。
繰り返しますがWBSとBTSを併用することが大事です。BTSだけで普通のプロジェクトを管理しようと思うと崩壊すること間違いないです。併用する場合、WBS側には「QA対応工数」とか「バグ対応工数」みたいな枠を積んでおくと良いでしょう。あとはチケットの枚数や工数を積み上げて伸長率を見ていれば予定と実績の差を把握することができます。
チケットはコミュニケーション手段
上記のようなQAやバグにチケットを使うようになるとメールが圧倒的に減ります。チケットをコミュニケーションの基点になることで課題の抜け漏れをなくし、管理品質を向上させるのです。
BTSを運用する場合のワークフローを考えるとき、チケットをバトンのように渡していくイメージを持つと良いでしょう。このタスクがどこから生まれ、誰が処理をし、最後に誰が確認をするのかといった一連の流れを想像していくことが大事です。
特に「誰がクローズするのか（課題一覧から見えなくするのか）」というのが重要で、この設計をミスると抜け漏れが発生します。たとえば「定例で顧客に確認をしてから」「テスタが確認をしてから」「リーダーがチェックしてから」とか、色々と考えることができます。正解はありませんが一覧から消えると言うことは全員の視界から消えることを指すので後々に「実は終わっていなかった」というような問題が発生しないための予防をする必要があるのです。
だから、僕は個人に閉じるようなタスクを登録することは否定的です。そういったものはコミュニケーションではないからです。作業者は手元の好きなTODOツールで管理をすればよいのです。
ところで「作業計画にチケットを使うな」とか「個人のタスクはBTSにいれるな」というは昨年のデブサミで講演した際にはTwitter上で「それじゃチケット駆動の意味が無い（大意）」という反論を頂戴しています。
それは分かりますが、多くのプロジェクトではチケットをいきなり作業計画に使うのは難易度が高いはずです。チケットの適用を計画外で既に発生した事象を捉えることから始めてはいかがでしょうか。一番はもちろんバグですが、次は顧客とのコミュニケーションです。メールの応酬がなくなって履歴が残るだけでもやる価値があると思いますよ。
宣伝
で、チケットはコミュニケーションだな、と思ったときはBTSとしてJIRAをお勧めしたいと思います。やはりRedmineは開発者のためのツールという印象が強く、アジャイル的な作業計画立案に最適化されている気がしています。その点、JIRAは商用製品だけあって見た目もかわいいですし、操作に迷うということはほとんどありません。フロー制御もバグることはないです。実際、弊社で顧客に使い始めてもらうときに操作説明をしたことはほとんどありません。「使ってください」というだけでOKです。
＜追記１＞
Twitterなどで「WBSは成果物管理のことでは」との指摘がありました。その通りです。エントリで書いた「WBS」は「WBSを元にしたガントチャートによる管理手法」というのが正確な表現です。WBSという言葉にガントチャートまで含む事が一般的になっていますが、用語としては間違っていますので追記として訂正をさせていただきます。
＜追記２：皆様の反応＞
