[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi

ベストスピーカー賞(3位)をいただきました

デベロッパーズサミット2011で、小川さんと共にベストスピーカー賞(3位)をいただきました。ご参加いただいたみなさま、スタッフのみなさま、ありがとうございました。

色々なところで発表していますが、実はこれが初めての受賞です。ノミネートされたり、次点だったこともあるようです。常連のシンポジウムでは、プログラム委員の方から「受賞したことがあると思って推薦しなかった。ごめんね」と言われたことさえあります。なので、章とは縁が無いと思っていました。

今回は、本に興味を持っていただいたみなさんや小川さんの人気に救われたほか、ベストと言いながら3位まで賞をいただけたのが、次点までしか経験のなかった私にはとてもラッキーだったのかもしれません。

ソフトウェア工学の不幸な歴史

今回発表したチケット駆動開発には、特別な思いがあります。それは「現場のソフトウェア工学」であることです。

ソフトウェア工学という言葉は、私が社会人になった時に初めて聞きました。しかし、英語のエンジニアリングという言葉から期待するものと、現場で感じるものはかけ離れているように思いました。現場で苦労しながら開発している現状を、当時のソフトウェア工学は解決してくれないと思っていました。

時は過ぎ、私はソフトウェア工学を学ぶ機会を得ました。そしてわかったのは、ソフトウェア工学は役に立つということです。ただし、正しく実施する、すなわち、ふさわしい問題にふさわしい解決法を実施した場合だけです。

でも、実際には、ふさわしいかどうかと関係なく、ルールだから、とか、良いと言われている、話題になっている、などという理由で、トップダウンに強制されることが多いと思います。

そのような形での技術導入では、現場はやらされ感がいっぱいで、面倒なことにならないように指標に合うように開発するだけです。たしかに、指標が正しいかどうかに関係なく、一定の値になるように開発していればそれなりには安定するという一面もあるのですが、現場から見るとなにも良くなっていない。ソフトウェア工学や改善は管理職のためのもので、自分たちには関係ないことだと思ってしまいます。

そのような状況では精神的な負担を増やすだけで、現場を改善しようと言う雰囲気になるわけがありません。

現場のソフトウェア工学

チケット駆動開発を知ったのは、共著者で一緒に発表させていただいた小川さんからです。現場で苦労されているうちにチケット駆動開発を始められ、「アジャイルがわかった！」と言われるようになりました。チケットでタスクマネージメントするだけだと思っていたのになぜなのだろうと、そのころから私もチケット駆動開発に興味を持ちました。

そして色々と調べたり、考えたりするうちに気が付いたのです。これは「現場のソフトウェア工学」だと。tracとかRedmineは障害管理ツールですから、もちろん障害管理ができます。そしてチケットでタスクを管理するのは、チケットが構造を持つのでWBSと同じ。また、基本ルールの「No ticket! No commit!」は構成管理ツールと連携するのですから、もちろん構成管理もしている。さらには、アジャイルの要素である、タイムボックス管理、スコープの変更、見える化、コミュニケーションの向上。そして、小川さんはEVMとの関係まで語っている。

このように、現場から始まった技術であるにもかかわらず、チケット駆動開発にはいろいろなソフトウエア工学の要素が入っています。現場の問題を解決するために始まったチケット駆動開発によって、ソフトウェア工学の技術をを正しく導入したのです。もちろん、「はやっているから」とか、「おもしろそうだから」と始めてはこれまでと同じです。現場にある問題を確認し、チケット駆動開発で解決で きるなら、その時に導入するべきです。私が発表で、どうしても伝えたかったのはそのことです。それは私が最後に付け加えた一言、

「もし問題がないならばそのままで良いと思います。(説明した)これらの問題が当てはまるならチケット駆動開発を検討してください」

ということです。現場の問題を見極めることから始めることは、現場で改善を進めていくにはとても大切なことだと思っています。