[#TiDD] チケット駆動開発によるプロセス改善(事例) -SPI Japan 2013 -

SPI Japan 2013で発表させていただきました。

「チケット駆動開発によるプロセス改善 - 現場重視、管理重視、それとも情報共有重視 -」と題して、これまでの事例から現場を考えたチケット駆動開発の必要性を話しました。

チケット駆動開発によるプロセス改善 - 現場重視、管理重視、それとも情報共有重視 - from Makoto SAKAI

セッションの発表

同じセッションでは、共同プログラム委員長でもあるSRAの古石さんは小規模プロジェクトでのチケット駆動のお話。tracの画面やデータの関係を示しながら、わかり易く説明されました。

パナソニックの林さんは外国へのODM(Original Design Manufacturing)のお話で、ODM先に常駐していても発生した様々なトラブルをお話しされました。外国の方が外国の特性を率直に語られていて興味深かったです。

東芝の田村さんはホフステードの文化的次元を用いて、オフショアで発生した事例を分析・改善されていました。知っている人には当たり前の知識かもしれませんが、分析対象を絞るとき、分析時、対策時に使っている点が興味深かったです。改善率も定量的に計測されていて、さすがです。

クロージグパネル

クロージグパネルは「“「共感」”　・・・　心が動くとき、行動は変わる！～開発におけるツールの有効な活用方法～」というタイトルでツールのお話をされました。

議論の中では

　Toolは「使う」のではなく、「使われる」ぐらいが良い。

と言う言葉が出てきました。ツールの思い(設計思想)を活かしましょう、と理解しました。

なかなか面白い議論だったのですが、イマイチ乗れませんでした。一つには形式検証やリバースツールなどと、チケット駆動開発で使われるITS、バージョン管理ツール、CIツールが同時に議論されたからかもしれません。

チケット駆動開発的なところは深く議論したいものの、知らないか避けているのか、あるいは、わかっていない人が反論でもなく、別のツールのずれた意見を重ねられると、深い議論をする気になりませんでした。

チケット駆動開発を伝える難しさ

ここがチケット駆動開発の難しいところです。基本的な話をするとわかっている人はつまらないし、深い話だけするとやった事のない人は理解できません。チケット駆動開発のリズムやテンポ、安心感すごさがうまく伝わらないのです。

これまでシェルスクリプトでやってきた人にRubyの良さを伝えたり、MS-DOSのベテランにUNIXの良さを伝えたり、そんな、限界のある物をそれなりに使う事が良いと思う人に、色々できる物を上手に工夫する醍醐味を伝えるような苦しみです。

現場と共に

チケット駆動開発をうまく回すには、標準化から入るのではなく、問題の対策から入るようなアプローチが必要だと思います。SPI Japanは元々SEPG Japanで組織プロセスの改善の人たちの集まりで、どことなく組織的なアプローチが前提になっていた事も乗れなかった理由だったのかもしれません。

チケット駆動開発は現場から生まれて普及しました。現場の諸処の事情に工夫するからうまく使える面があるからです。「組織から」ではなく「現場と共に」がとても大切だと思っているからです。

おわりに

３日間のうちの１日だけの参加でしたが、色々と考える機会になった１日でした。

チケット駆動開発のすごさを伝えるには、まだまだ工夫が必要かも知れません。今後も機会があるごとに、工夫して伝えていきたいと思います。

なお、発表資料のうち、公開可能な物はJaspicのサイトで公開される様です。