TiDDを実践して気付いたことpart1～解ける問題であれば人は自然に解決する方向へ動き出す

PFP関西ワークショップ＃20で平鍋さんのPFの話を聞いた。
もう何度も同じスライドで同じ内容を聞いているのに、いつも新鮮な感覚がある。

プロジェクトファシリテーションの話を聞きながら、チケット駆動開発(TiDD)でどうやって実現できるか、妄想をめぐらせてみた。

【元ネタ】
【Facilitation】解けない問題を解ける問題へ変換する: プログラマの思索

「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」の本で「解けない問題を解ける問題へ変換する」という挿話がある。
この挿話では、解けない問題を解ける問題へ変換すると、人は自然に解決する方向へ動き出す、という教訓を提示している。

この教訓は、実際の開発現場でとても実感する現象だと思う。

SW開発では頻繁にデスマーチ・プロジェクトが起きる。
デスマーチ・プロジェクトでは、いくら目先の問題を解決しても、問題がとにかく多すぎて、現状がなかなか変わらない。
すると、メンバーもチームも無気力になり、一つの歯車で働いている感覚に陥る。
解けない問題はチームを無気力にするのだ。

過去、SW開発の諸問題を解決するために、色んな開発プロセスやプロセス改善の手法が提唱されてきた。
CMMI、PMBOK、RUP、Agileなど。
それらを勉強すると確かに概念は整理されるけれども、いずれも実践しにくい。

CMMIやRUPは、その膨大な量で圧倒されてしまう。
いくら勉強しても、あまりにも大きすぎて、開発現場へ応用しようとすると、畳の上の水泳練習みたいで、カスタマイズが難しい。
CMMIやRUPは勉強になるけど、運用するにはたくさんのノウハウを必要とする。

Agileも実践的プラクティスが多いけれど、良い方法と分かっていても、手が出せない部分が多い。
Agile開発の根本的な特徴は、頻繁なリリースを支える技術やプロジェクト管理手法が前提であるため、運用するには高度な作業やマネジメントが要求される。
手作業では到底無理であり、専用のツールは高価だったりする。

しかし、この数年で状況が少しずつ変わってきたように思う。
RedmineやTracなどのプロジェクト管理機能を持つBTS、SubversionやGit、Mercurialなど高機能なSCMのおかげで、タスク管理やソース管理をツールで補完できる範囲が広がってきた。

チケット駆動開発はTracのチケット管理から生まれたけれど、Redmineでチケット駆動開発を実践して初めてAgile開発をスムーズに運用できた経験をした。
すると、実際の現場の雰囲気も変わってきた。
つまり、ツールを使ってAgile開発について書かれた本の内容を運用できると、イテレーションを繰り返す度にチームは自然に改善されていった。

そして、Agile開発について書かれた本の内容を実践できただけでなく、それらの本に書かれていない新しい概念が出てきたように感じた。
その新しい概念は、当初はチーム特有のノウハウに過ぎないけれど、イテレーションを繰り返す度にノウハウが積み重なって、一つのプラクティスになる。

そのサイクルは、ツールを導入するとチームやメンバーの行動が変わり、行動が変われば考え方も変わっていく流れと同じ。
つまり、ツールが考え方を変えて、道具が新しい手法を生み出すサイクル。

ソフトウェアはとても柔軟で、しかもすごく威力がある。
それはビジネスだけでなく、SW開発自身についても同様だ。

ソフトウェア(ツール)で、SW開発の諸問題を解けない問題から解ける問題へ変換すると、チームもメンバーも自然に解決する方向へ動き出す。

SW開発の現状は、各種の概念や技法は出し尽くされた感があり、それをいかにツールで実現して、現場で運用できるようにするか、という問題へ変わりつつある気がする。

チケット駆動開発もその流れにあると思う。
実際、チケット駆動開発はBTSという従来のツールを使っているし、タスクをカードで管理する発想もXP等で既に提唱されているからだ。
しかし、チケット駆動開発というアイデアによって、アジャイル開発のインフラが整ってきたという現状がある。

今後、チケット駆動開発を実践して気付いたこと、考えたことを色々書いていく。