チケット駆動開発の弱点～プロダクトオーナーをどこに配置するのか？

チケット駆動開発を今まで実践してきて、アジャイル開発を現場で導入するための一手法としてとても有効だと思う。
でも、多分唯一の弱点とすれば、「プロダクトオーナーをどこに配置するのか？」という問題があると思う。
ラフなメモ書き。

【1】プロダクトオーナーは、開発チームと同等の立場で、リリース計画を作り、マイルストーン単位にリリースすべき機能を定めて、少しずつ製品を完成させていく。
プロダクトオーナーは、顧客と交渉して要件をまとめたり、作るべき製品の機能を整理して開発チームへ説明すしたり、予算計画を作って日々のコスト管理を行ったりする。
だから、プロダクトオーナーが開発チームを管理したり、進捗を監視する必要はそもそもないし、そんなことをする暇もない。

すると、チケット駆動開発では、プロダクトオーナーはどこに配置すべきか？

【2】チケット駆動開発で出てくる役割(ロール、権限)は最大4つある。
それは、システム管理者、管理者、開発者、報告者。

システム開発者は、BTSないしITSのサイト自身の管理者。
管理者は、ITSの該当プロジェクトで最も権限を持つ人。イメージはプロジェクトリーダー。
開発者は、ITSの該当プロジェクトで、チケットに書かれた作業に従事する人。イメージはプログラマ。
報告者は、リリースされたシステムをテストして障害報告したり、使ってみて機能改善の要望をあげる人。テスターないし製品の一般ユーザ。

これら4つのロールは、元々、障害を管理するためのシステムとしてBTSないしITSが生まれた経緯を、チケット駆動開発が引き継いでいる。
だから、自分たちで作業を作り出してどんどん開発していくスタイルには向いている。

すると、あるべきシステム、あるべき製品のロードマップを作って、そこから少しずつ改良しながら小規模リリースしていく場合、仕様を生み出し、決定する人はどこに配置すべきか？

【3】開発チーム主導ならば、管理者(＝プロジェクトリーダー)がプロダクトオーナーになる。
管理者がリリース計画を作り、マイルストーンごとにリリースする機能を定めて、チケットへタスクを落としていく。
しかし、管理者はチケット駆動開発の中で最も権限が強いため、普通は、開発者は管理者に従属しがちだ。
開発者と管理者は権限として対等ではない。

【4】ユーザストーリーから駆動して開発するスタイルならば、報告者(＝ユーザ)がプロダクトオーナーになる。
報告者は障害を報告したり、使いづらいユーザインターフェースを改善する要望を上げて、機能拡張や品質改良に自らも積極的に関わる。
しかし、報告者はチケット駆動開発の中で最も権限が弱いため、普通は、報告者は開発チームにお伺いを立てる行動ぐらいしかできない。
報告者は、開発者や管理者が形成する開発チームと同等ではない。

【5】チケット駆動開発では、開発者は自らのタスクをチケットで公開することで、チームや自分自身の透明性(オープン)を保証してくれる基盤はある。
また、チケットがタスクであるから、そのタスクを担当することで、コミットすべき責任も負う。

システムのリリースバージョンをイテレーションと見なすことで、リリース後のフィードバックを得たり、日々の朝会やユーザからの障害報告からフィードバックを得たりして、開発チームがリリース計画を改良し、経験知を上げて成長していく基盤もある。
少なくとも、開発チームがソフトウェア開発を自律的に進めていくための基盤は揃っている。

でも、プロダクトオーナーをどこに配置すべきか、という問題は、チケット駆動開発だけでは解決してくれない。
それは組織構造の問題も孕んでいる。

こんな製品を作りたいという曖昧な所から、少しずつ作っては製品イメージを固めて、製品を最終リリースしていこうとすると、プロダクトオーナーのような役割がとても重要になるのに、その権限をマッピングする役割をチケット駆動開発のオリジナルだけでは実装できていないのだ。

多分、プロダクトオーナーというロールを管理者や開発者とは別に作る必要があるのかも知れない。
色々考えてみる。