エンピリカルソフトウェア工学をチケット駆動開発がサポートする

エンピリカルソフトウェア工学(実証的ソフトウェア工学)に関する記事を見つけたのでメモ。

【元ネタ】
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催 － Publickey

少人数のチームの方がソフトウェアの品質は高い - 思考のスキマ

【参考】
ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する: プログラマの思索

BTSをBusiness Intelligenceとして使う: プログラマの思索

Web2.0時代のプロジェクト管理: プログラマの思索

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

チケット駆動開発が進むべき道part2～プロジェクト管理サーバーは開発チームの資産: プログラマの思索

エンピリカルソフトウェア工学は、ソフトウェア工学を科学実験のように実証的に確かめていく分野の学問。
「データ指向のソフトウェア工学」の特徴を持つ。
普通は、BTSにある障害報告票やSCMにあるソース履歴から、開発組織の構造(プロセスも含む)がソフトウェアにどう影響するのか、を探る学問。
僕のイメージでは、エンピリカルソフトウェア工学は社会科学のように、ソフトウェア開発に従事する組織や人を分析する学問であり、コンピュータサイエンスや物理学、数学のような科学ではないと思っている。

ソフトウェア工学の中では、ブルックスの人月の神話が最も知られている経験則の一つ。
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催 － Publickeyが面白いと思ったのは、「少人数のチームの方がソフトウェアの品質は高い」「組織構造の縦方向が短い方がソフトウェア品質がいい」という指摘をしたこと。

ソフトウェアをチームで開発する経験を持った人なら、その事実は当たり前に思うだろう。
大規模プロジェクトになり、開発チームが複数になるほど、コミュニケーションコストが大きくなる。
それ以上にマネジメントコストやアーキテクチャの整合性を取るためのコスト、システム全体の品質を確保するコストが指数関数的に肥大化していく。

「結果、エンジニア同士の距離がどれくらい離れると、どれくらいバグが増えるかは、ビルが異なると2.6％増加、カフェテリアが異なると3.9％増加、キャンパスが異なると6.3％増加、地域が異なると8.3％増加、大陸が異なると -3.9％となった。」という事実はとても興味深い。

だがその経験則に逆らうようなソフトウェア開発が増えているのが事実。
典型的な例がオフショア開発。
日本のSIなら、中国などの人月が安い外国へ下流工程の開発を委託するビジネスになる。

大規模プロジェクトを自社開発で内製化していても、開発メンバーが部屋やビルで隔離されていれば、心理的にはオフショア開発と変わらない。
分散開発は本来コミュニケーションコストが大きい。

そういう経験則に逆らってソフトウェア開発を成功させるには、顔を見ながらのミーティングが出来る環境作り、ブリッジSEだけでなく委託先の開発者もプロジェクトの最初は一緒に仕事するなど、心理的な距離を縮める努力が必要、とのこと。

個人的には、プロジェクトファシリテーションが分散開発におけるコミュニケーションについて、もっと役立つプラクティスを提供してくれるといいのに、と思っている。

又、チケット駆動開発がエンピリカルソフトウェア工学をサポートする可能性を秘めていると思っている。
チケット駆動開発は本来BTSというツールを使うことから始まったし、進捗や品質に関するメトリクスをいくらでも好きなように加工して出力できる。
ガントチャートやカレンダー、ロードマップ、バグ収束曲線などは、開発の現状に合わせてリアルタイムに最新化する仕組みをツールでサポートすればいいだけ。

何よりも、開発者が「チケットファースト」「No Ticket, No Commit」の運用ルールを守ってくれれば、バックグラウンドでメトリクスの元ネタを収集してくれるので、メトリクス採取のコストは劇的に下がる。
この手法は、Mixiの足跡機能やGoogleのPageRank、Amazonのレコメンドエンジンのように、クローラーのような機能で緩やかにログを採取して、価値ある情報を加工して出力する機能が簡単に実装できるようになったからこそ生まれた。
つまり、いわゆるBI(ビジネスインテリジェンス)をプロジェクト運営の意思決定に役立てることができるはず。

そして、BIで得られた情報を実際に運用してみて役立ったならば、一つのノウハウとしてチームが学習する。
この際に、KPTによるふりかえりは特に有効だ。
学習したノウハウはKeepとして貯められて、チームの資産になる。
Keepとして貯められた独自のノウハウが多いチームや組織ほど、自分たちで開発現場を改善する能力を拡張していける。
これがいわゆる、アジャイル開発で言う自己組織化ではないか、と直感している。