[#TiDD] チケット駆動開発がもたらすプロセス その６：現場力

続きです。ようやく最終回(のつもり)です。

１．事件は現場で起きている！

チケット駆動開発は現場から生まれました。

• 細かな作業を管理する
• ソースコードの履歴を管理する
• ツールで自動化する

これらは、現場がいかに楽をするか、肉体労働でなく知的生産をするか、という観点です。もちろん、プロジェクトマネージメントやプロセス改善で意識するQCDの向上、つまり品質向上、コストダウン、納期とも間接的には関係しますが、それが目的ではなかったのです。

２．既存技術の現場との乖離

ソフトウェア工学の歴史を振り返ると、その始まりころは構造化プログラミングによって、現場のスパゲッティプログラム問題を解決してくれましたが、定量的、統計的、汎用的、なものを目指すあまりに現場に対して即効性が低くなったように思います。

研究の価値を考えるならば、定量的であることで客観的になり、統計的であることでその有効性が明らかになり、汎用的であることで広く活用されます。しかし、このことが現場との乖離を生みました。

まず、定量的なデータを集める場合、既知のメトリクス(尺度)でない場合は、まず仮設を立て、その仮説に沿ったメトリクスでデータ収集します。仮説が正しければ対象となったプロジェクトで役に立つデータ収集である可能性がありますが、仮説が外れれば無駄な作業を追加するだけになり、現場にとっては負担だけが残ります。

次に、集められたデータを統計的に扱うためには、個別の事情による誤差をなくす程度の数が必要になります。単純に検定するだけなら20以上必要といわれています(うまくいけば10以下でも可能らしいです)。組織的に協力していただけるなら大量のデータ収集も可能かもしれませんが、実際には難しいので、実験計画法を参考に条件の組み合わせなどで個別のデータのノイズをなくす努力をします。その結果明らかになるのは、個別のプロジェクトで何がおきたか(たとえば配員)など現場の問題を無視した一般的な情報が多くなります。そして、その多くはプロジェクト終了後に計算されますから、開発中のプロジェクトでなく、次のプロジェクトから役に立つ情報です。

最後に汎用的な研究を重視すると、研究結果のツール化は評価されますが、ツールの利用による研究はあまり評価されません。個別のツールに依存した研究は汎用性がありませんし、ツールが良かったのか、提案する方法が良かったのか、区別することが難しいからです。

このように定量的、統計的、汎用的なものを求めることによって、即効性がないので効果が出るのは次回以降のプロジェクトであることが多く、人などの個別情報を失いがちで、ツールと独立した研究が多く、目の前の問題に困っている現場と距離があるように思います。

３．人の重視とアナログ指向

アジャイル宣言以降、人を重視した開発が注目されるようになっています。これまでのソフトウェア工学では、統計データのノイズとして扱われていた人の違いやモチベーションといったこともプロジェクト運営で重視されるようになりました。

定量的なデータだけでなく定性的なデータが扱われるようになり、感情や雰囲気といったアナログ情報も重視されています。そのような流れの中で使われるツールがアナログ中心になるのも分かります。人の直感はアナログ情報を扱えるのですから、付箋を位置から書き直さずに赤ペンで修正するほうがわかりやすいのも事実です。

このような流れの中で、なんとなく個人やプロジェクトにまかされたまま、あまり議論されなかったのが、基本的なツールの使い方です。ツールのTIPSのほか、どのような考え方で活用し、どのように組み合わせていくか、技術者がより良い仕事をするために道具を磨いていく。そんな古き良きUNIXの時代の技術者魂がどこかに忘れられたような気がします。

４．ツール時代の開発法

かつてはプロセスの議論だけでよかったのでしょう。組織は時間をかけて成長し、技術は個人やプロジェクトが蓄積する。やり方が決まっていて、必要な知識も明確であれば、これまでのやり方が通用しました。

でも、いつのまにか変わってしまって、プロセスが追いつかなくなったのです。環境構築だけでも大変なのに、高機能なソフトウェアを開発しなければならず、しかも開発期間は非常に短い。こんな状況で、10年も20年も前から提案されているプロセスを適用するだけでは開発できなくなりました。

このようなきびしい状況で、とんでもない開発法が現れてきました。ひとつは海外に出して安く上げる方法、もうひとつはいい加減に開発する方法です。きちんと戦略を立てて海外に出すならまだしも、いい加減な開発が許されるはずはない、そう思いたいのですが、そうでもない(リンク先は達人プログラマーを目指して)ようです。

こんなライバルを相手にして、まともな技術者が生き残るのは困難です。海外の単価や、いい加減な開発の単価と同じ単価になるように、現場で起きている問題を解決し、技術力を高めないといけないからです。これまでのように、技術の確立に時間のかかる技術に依存した開発では難しく、即効性のある技術による自律的な開発が求められます。リーンソフトウェア開発で出てきたような海兵隊のような組織でないといけません。個々人が自律的に行動し、何かあった時も正しく判断して行動ができるような組織です。チケット駆動開発はそれを可能にするものだと思います。

５．チケット駆動開発の可能性

チケット駆動開発はアジャイル的ですが、アジャイル開発そのものではありません。マイルストーン(バージョン)ごとに開発する、チケットの優先順位に従ってスコープを変更するなど、とてもアジャイル的です。しかし、その特徴は、ツールを用いたプロセス改善で、チケット中心に個人とプロジェクトの2重プロセスがあり、それらは形式化され、リズムが生まれ、成熟していくことです。

チケット駆動開発は顧客同席などの要件を満たしていませんので、アジャイル開発そのものではありません。しかし、その根底にあるのはアジャイルと同じように、現場重視、人重視です。厳しい条件の中でもあきらめず、どのようにより良いソフトウェアを開発するかというアプローチです。

日本にはカンバンやファシリテーションなど、日本の文化に根付いたアジャイル技術があります。チケット駆動開発がこれらを取り込んで発展したならば、真に日本発のアジャイル開発法になり得ると思います。

完(のつもり)