課題管理のチケット駆動開発

従来から言われているアジャイル開発の弱点として、スケールアップと上流工程への応用があった。
チケット駆動開発を実践してみて、スケールアップはアジャイルリリーストレインとスクラムオブスクラムで解決できると思っている。
しかし、上流工程への応用はチケット駆動開発でも試行錯誤している。
考えていること、まだ疑問に思っていることをメモ。

アジャイル開発を現場に導入する場合、開発やテストの工程から導入すると成功する。
テスト駆動開発、継続的インテグレーションのようなプラクティスを部分的に導入するだけでも、開発の生産性は大きく上がる。
更に、Scrumを導入すれば、プロジェクト管理も支援できるだろう。
しかし、要件定義というシステム開発で最も揺れる工程にアジャイル開発を導入するのは上手くいっていないように思う。

アジャイル開発では要件をストーリーカードで表現して、バックログに貯蔵して管理する。
バックログに一度入れば、後はタスクカードへ落とすだけだから、開発者の本領発揮の領域だ。そして、どのイテレーションでリリースすべきかは、ユーザの希望順位とシステムの整合性の観点から、開発者主導で決めることができる。

しかし、肝心のストーリーカードをヒヤリングから収集して凝縮する作業が大変。その作業はアジャイル開発の領域というよりも、萩本さんが提唱する要求開発の領域に近い。
つまり、ユーザの現状(AsIs)を分析し、どこに不満や問題意識、課題を持っていて、どのように改善したら、あるべき姿(ToBe)になるのか、を導出しなくてはならない。
ToBeの業務がストーリーカードとしてまとめられるべきなのだが、そう簡単にはいかない。

その工程は要件定義というよりも、要件定義の前工程に当たるシステム化構想の工程。
要求されるスキルは、ビジネスモデリングや業務知識。
アジャイル開発なら、ユーザが常に開発者の身近にいるから、口頭ベースでヒヤリングしながらストーリーをまとめていけばいい。
実際はユーザの元へ出向いて、定期的にヒヤリングとレビューを繰り返しながら、ユーザの夢や不満をシステム構想へ落としていく。
その作業をアジャイル開発っぽく運用できないか、模索している。

今考えているアイデアは二つある。
一つは、顧客にヒヤリングやレビューしてもらうタイミングをイテレーションに変えてしまうこと。
つまり、定期的な訪問準備のための資料作りという作業をイテレーション単位で繰り返す。
実際、ヒヤリング前にドキュメントを準備する必要があるし、顧客によるレビューのタイミングが、作ったドキュメントを評価されるタイミングだから、顧客によるテストと見なすこともできる。
そして、そのドキュメントは、顧客のレビューやフィードバックをイテレーションのたびに反映していくから、どんどんVerUPされていく。
すなわち、システム化構想や要件定義書、RFPなどは構成管理の配下に置くべき。
このやり方は、チームに馴染みやすい。

もう一つは、課題管理にチケット駆動開発を導入すること。
例えば、ドキュメントを作っている時に顧客へ質問したい課題、顧客から宿題として受けた課題、等が当たる。
これらの課題はシステム化構想や要件定義の工程で随時発生するが、普通の開発では課題管理はExcelで行われるため、作業ステータスや最新化がうまくいっていない時が多い。
だから、顧客に同じような質問を何度も繰り返したり、同じ原因の課題が似たような課題として随時現れたりする時が多い。
特に、システムのイメージが曖昧だったり、顧客の不満や課題を理解しきれなかったり、業務知識が不足していると起きやすい。すると、顧客からの信頼も落ちてしまい、その後の設計作業に支障が出る。
実際のコンサルティングでは、課題を見つけてそれをどんどん解決していくのがお仕事ゆえに、課題管理こそが最も重要とも言える。

課題をチケットで扱えば、作業ステータスも一括管理できるし、課題をカテゴリ分けしたり、集計することもできる。
課題をチケットにした場合の利点の一つは、上記のイテレーションで課題をアサインすることで、どの課題をまず片付けるべきか、という優先順位付けを自然に行えることだ。これによって、課題の優先度に自然に意識が向かい、膨大な課題を整理するモチベーションにもなる。

もう一つの利点は、課題をチケット駆動開発のワークフローにのせることができること。
課題の担当が今、開発チームにあるのか、顧客にあるのか、その後のフローはどうあるべきか、一貫して制御できる。
そして、課題を消し込むタイミングでチケットをCloseすればいい。
チケットをCloseするタイミングで、チケットに書かれた内容をSVNの配下にあるドキュメントへ反映すれば、チケットとSVNリビジョンのトレーサビリティができるから、その後の設計や開発で、何故こんな要件や仕様があるのか、追跡できる仕組みが整うだろう。

だが、課題管理のワークフローがいまいちスッキリしない。
普通は「新規→担当者決定→問合せ中→回答済み→終了」のワークフローになるだろう。
つまり、顧客に質問(問合せ)して、回答を得たら、その内容をドキュメントに反映すればいい。
しかし、実際は、顧客もその場で回答できず保留にすることがある。
あるいは、質問したのに、逆に、システム開発の工数を少なくするために他の案を出してくれ、などと逆に宿題として突き返される時もある。
すなわち、「顧客の回答待ち」「顧客の内容を受けて再設計」「宿題として保留」という作業状態が生まれる。
その作業状態にある課題を解決するのが難しい時が多く、顧客と開発チームの間で何度もやり取りしてやっと解決される時もままある。
これらの作業状態をワークフローに入れると、結構複雑になる。
しかしやむを得ない事も多く、課題だけがどんどん増えていくのが嫌だ。

更に、課題の終了条件がスッキリしない。
普通は、課題に対して回答が得られて、その回答をドキュメントに反映すれば終わる。
あるいは、課題の回答を受けて、疑問が解けて、何も問題なかったと分かれば終わる。
しかし、課題の回答を受けて、更に別の課題や要件が出てきた場合、その課題をどうすればいいのか？
今は、課題から要件が出た場合、その要件を要件定義書へ反映あるいはストーリーカードを作成すれば、その課題は要件定義の工程では完了としていいと思っている。
しかし、他の課題が出てきた場合、本来の課題から離れているので、管理が難しい。
実際は、元々の課題をCloseし、別の課題としてチケットを作り、元々のチケットへリンクしておく運用にしている。

実際の運用では、課題管理会議でアーキテクト、上司などがそれらの課題に対しヒントを授けたり、方針を決めて、解決する方向へ持って行く。
つまり、できるだけ課題をCloseする方向へ持って行く。
結果的にはうまくいっている。
でも、課題管理のチケット駆動開発は何かしっくりしない感触を持っている。
Redmineのワークフローを厳格に運用するとうまくいかない。
課題管理会議での棚卸しするために、課題が見える化され、議論して共有できるのが利点みたいだ。

何かしっくりしない。