先日発売された書籍「チケット駆動開発」をやっとのことで読み終えた。大変興味深い本だったのだが、仕事の状況などにかまけて通読するのに妙に時間がかかってしまった。ソフトウェア開発のコミュニケーションに関するプラクティスに関する本と捉えていて、いろいろな問題提起が含まれているのがとても面白い本だと思った（逆に、実践的ハウツー本を求めている人には向かないかもしれない）。以下、感想をいくつか。
方法論ではなくて一つのプラクティス
「チケット駆動開発」はひとつのプラクティスであって方法論ではないと思っている。必要に応じてプロジェクトに取り込めば良い、プラガブルなテクニックのようなものだ。
- ウォーターフォール型でもアジャイル型でもハイブリッド型でも良いが、まず前提として「きちんとソフトウェアを開発できる計画・作戦が立てられる」人でないと本書は面白くないと思う。
- 逆に本書はソフトウェア開発の現場を加速したり向上させたりするものという理解。
- 一種の「コミュニケーションパターン」×「リーダーシップパターン」なんだろうと思っている(詳細後述)。ただ面白いのはイシュー管理システムを活用して、これらのパターンを現場に半強制してしまうところ。
- ただし、ツールの導入は現場を取り巻く環境などにも依存してしまうので普遍的ではない(ツールは時により進化してく)。本書がツール「ありき」で書かれている印象なのはちょっと残念なところもある。
本書を読んでRedmineやTracのようなITS・BTSを導入しちゃうのは多分乱暴だろう。すこし引いて手元の現場の状況をよく観察してみることから始めないとうまくないと思っている。
コミュニケーションパターンとしてのチケット駆動開発
もともとソフトウェア開発は大量のコミュニケーションで成り立っているようなものだけれども、チケット駆動開発ではこのコミュニケーションを汎用的な「チケット」でマーク付け（タグ付け？）して管理するというのが一つのキモだと思う。ソフトウェア開発以外の世界だと、基本的にコミュニケーションは「流れ去っていく」ものである。議事録であったりメールの履歴としての記録はされるが、これらはあくまで記録であって随時閲覧されるものではない。チケットになって初めて管理できるようになる、というのがポイントなのだと理解している。
元ネタを失念してしまったのだけれども、どこかの企業の社長は部下に指示をする際に二枚複写のメモ帳に書き込みをして、一枚を渡しているそうだ。これも一種のチケット管理のやり方で、局面がフィットしていればうまく回るような気がしている。
リーダーシップパターンとしてのチケット駆動開発
チケット駆動開発を実際にやると「計画」から距離を置けるようになるというのも良い点だ（別にアジャイルを擁護するつもりはないのだけれども）。チケット駆動を回すと「権威付けされたトップダウンのリーダーシップ」は自動的に抑止されるような気がする。
- 指示出し・タスク出しの間にチケット管理システムが入るので、トップダウンの性格が緩和される
- 作業完了報告もリーダー宛というよりは、チケット管理システムが相手先になる
- 指示出し・タスク出しそのものがトップダウンからボトムアップに切り替わる
- リーダーシップは「皆に指示出しをする」というより「全体が回るように支援する」傾向が強くなる
うまく整理がついていないけれども、このあたりの変化がチケット駆動開発の面白みなのかもしれないと思っている
参考
- [#TiDD] 「チケット駆動開発」への思い #RxTstudy 発表資料: ソフトウェアさかば
- スライドの最後のほうで、「ソフトウェア開発と真剣に向き合う本です」と紹介されているのだけれども、まさにそのとおりだと思う
- アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ
