「要求のブレを経験した人は78%、特定の技法がブレを小さくするという研究結果」と聞いてもやみくもに技法を勉強してはいけない
本エントリは、「要求のブレを経験した人は78%、特定の技法がブレを小さくするという研究結果」で公開したものを一部改変している。
Journal of Software Maintenance and Evolutionに掲載のReducing the risk of requirements volatility: findings from an empirical surveyで、300名のソフトウェア開発の実務者にアンケートを実施した調査結果を報告している。CMMIとPMIのソフトウェア開発を対象にしている人へアンケートの回答を呼びかけて回収したものだそうだ。
調査項目は多岐にわたる。詳細は論文を参照いただくとして、私が気になった部分は以下のとおり。
- 要求の規模が増えた経験をもつアンケート回答者は78%
- 要求がブレるのを防ぐ技法は「既存の要件定義書を再利用する」「業務の対象など、要件定義書を書く技術者が実際の活動を観察する（エスノグラフィー）」「プロトタイピング」だった。（統計的有意さがあるもののみ）
- アンケート、ヒアリング（インタビュー）では要求のブレを低減できない。（統計的有意さによる判断）
- CMMIのプロセス成熟度レベルが大きくなれば、アンケートで回答された要求のブレの大きさが減る。ただし、レベル3と4の間には大きな差はない結果
これは、ユーザ本人に聞くのではなく、過去の蓄積やプロトタイピング等、具体的な形をとったり、ユーザと同じ環境に身をおく、ということのほうが、要求のブレを減らすことにつながっている、と解釈できないだろうか。
もう少し注意深く考えると、やみくもにプロトタイピングの方法やエスのグラフィーのやり方を学習するというのではなく、単純にユーザに聞くだけではなく、適切なユーザに聞く必要があることを意味していると考えられないだろうか？
また、一般にアンケートの結果は多数派に目が向くが、多数派のやり方を取り込んだからといって、ご自身の組織やプロジェクトの要求のブレが減るとは限らない。ご自身のプロジェクト等で、要求がブレないようにするためには、何をするのが最善だろうか？
Test Driven Maintenance
"Prioritizing Unit Test Creation for Test-Driven Maintenance of Legacy Systems"というタイトルの論文が10th International Conference on Quality SoftwareでEmad Shihab, Zhen Ming Jiang, Bram Adams, Ahmed E. Hassan , Robert Bowermanにより発表された。以前に意見交換したときにShihab氏に教えてもらったのだが発表が済み、公開されたのでエントリにした。論文のPDFがここで公開されている。
本エントリは、「既存コードにテストコードを書くなら、どこから始めるのが効率的か？」で公開したエントリを一部改変している。
テストコードがない既存のソースコードにテストコードを少しずつ追加することをTest Driven Maintenanceと呼んでいる。その際、どこからテストコードを書いていくのが効率的かを長期にわたってメンテナンスされている商用ソフトウェアを対象としてシミュレーションしている。テストコードを書くという点ではTDD(Test Driven Development)に似ているため、彼らはTDM(Test Driven Maintenance)と呼んでいる。論文の結果が全てのソフトウェアにあてはまるとは到底思えないが、シミュレーションを実施すれば、これからテストコードを追加しようとするソフトウェアでも調査することができるだろう。
論文での対象ソースコードは、5年以上保守され、1万モジュール、5万回の修正、数百万行のコード。実際にテストコードを書いたわけではなく、開発半年後以降のある時点で仮にテストコードを書いていたとして、以降、同じ部分から不具合が検出されていれば、そのテストコードに価値があったと判断する。これをUsefulnesという評価尺度として定義している。また、ある時点から収集しているデータの範囲内の未来において、全てのバグがどこから検出されるかがわかっている場合と比較した場合の的中率を、percentage of optimal performanceとして定義している。
シミュレーションには、次の方法で10個のメソッド/関数を選び、テストコードを書いたとして、上述の評価尺度を算出している。いずれもランダムに選ぶよりも高い値が出ている。
-
- 変更頻度の高い順
- 変更時期が近い順
- 過去の発見不具合が多い順
- 不具合の発見時期が近い順
- 変更規模が大きい順
- 不具合修正による変更規模が大きい順
- これまでの不具合修正による修正規模（コード行数）の割合が大きい順（対象モジュールのみ）
- 7と同じだが、割合の算出に対象モジュールではなく、修正により変更した全行数を使っている。
ご自身の開発にあてはめてみると、どれがもっとも効率的になりそうだろうか？
シミュレーションと論文でのデータでは、usefulness, percentage of optimal performanceとも6, 5, 3, 1の順でシミュレーション結果がよくなっている。ランダムに選んでテストコードを書いた場合、usefulnessが27.7%、percentage of optimal performanceが1.7%であるのに対して、上述4つはいずれもusefulnessが80%以上、percentage of optimal performanceが20%以上となっている。（評価尺度は複数のシミュレーションの中央値）
ここでも書いたが、この結果で重要なのは、6, 5, 3, 1という順番ではなく、ランダムに選んだ場合よりも、非常に効率が高くなる可能性があることだ。過去のデータがあれば、これくらいの精度で予測ができる可能性があることを認識すべきだ。論文には、対象ソフトウェアの特徴等は詳しく書かれていないので、ご自身のソースコードでも同様にモデルを作るほうが予測精度は高まるだろう。
論文の著者のShihab氏やHassan氏は去年、今年に奈良先端科学技術大学院大学ソフトウェア工学講座を訪問し、意見交換している。私は今年の冬にこの論文の話を聞かせてもらい、非常に興味深いと感じた。
Twitterのリストが表示されなくなったのは「ダークモード」によるもの? - リリースと開発の分離の幕開けとなるか
先週、Twitterの被リスト数やリスト表示が一時的に表示されなくなった。Twitterには、ある機能を一時的に無効にする機能があるそうだ。本エントリは、「Twitterの「ダークモード」はリリースと開発の分離の幕開けになるか？」で公開したものを一部改変している。
Velocity 2010の講演"In the Belly of the Whale: Operations at Twitter"で紹介されているTwitterの「Darkmode」。講演のビデオはここから見ることができる。Publickeyの記事から日本語訳を読める。私はPublickeyの記事で知った。
記事と動画によるとTwitterにはDarkmodeと呼ぶ機能があり、Twitterの個々の機能を有効化したり無効化できるそうだ。最近、Tweet数が表示されない（誤った値が表示されるのではなく、そもそも表示されない）ということがあったが、この機能によるものかもしれない（推測なので、真偽はわからない）。
Darkmodeはソフトウェア開発の側面からみても、非常に興味深い。特定機能のリリースをコントロールできることは、開発とリリースを分離することができることを意味する。実現するためにはそれなりの仕組みと開発の手間が必要になるだろうが、特定のクラスタやユーザ等、段階的かつ実験的なリリースが可能になったり、いったんリリースした機能に不備や不具合があれば、元に戻すことができる。
これは、開発とリリースを分離する第一歩と位置づけることができる。分離されていない状況では開発担当者やテストエンジニアがリリースの可否を検討する。開発とリリースを分離できれば、リリースエンジニアと呼ばれる役割のエンジニアが機能の利用状況、負荷、不具合をモニタしながら、リリースの可否を決めることができそうだ。もちろん開発担当者がリリースエンジニアを兼任することもできる。
Darkmodeのような機能は「継続的リリース」のためのツールと呼べるだろう。アジャイルのようなイテレーティブな開発との親和性が高そうだが、必ずしも開発プロセスを限定しない点でも興味深い。継続的リリースはこれまでのソフトウェアのtime to marketの概念を変えてしまう可能性もある。たとえば、「機能Aは既に実現できているが、品質に問題があるためリリースしない」「機能Bは品質に懸念事項が残るもののリリースする」というような判断ができる。
継続的リリースが可能なソフトウェアの条件を列挙するのは簡単ではなさそうだが、少なくとも、次のような条件を満たすソフトウェアではないだろうか。このあたりの条件をどのように捉え、どのように定義していくかがソフトウェアを使った新たなビジネスのはじまりになるのではないかと思う。
サービスとして提供される
（ソフトウェアを配布する場合でも外部から瞬時に入れ替えたり、有効化、無効化できれば可能）
有効化、無効化する機能はミッションクリティカルなものではない。
有効化、無効化する機能に対して、ユーザから直接対価を回収しない。
ご自身のソフトウェア開発では、継続的リリースは可能だろうか。「ウチは組込みだから関係ない」と即断するのはひょっとすると尚早かもしれない。ネットワーク等、外部から機能を実現するプログラムの変更、有効化、無効化ができれば上述は実現できるだろう。あとは、それに見合うような価値がユーザから認められるかどうかではないだろうか。
テスト駆動開発の事例（MS, IBM）の研究論文
本エントリは、オルタナティブブログのこのエントリを少し改変、再掲したものです。
N. Nagappan, M. E. Maximilien, T. Bhat and L. Williams: Realizing quality improvement through test driven development: results and experiences of four industrial teams, Journal of Empirical Software Engineering, vol. 13, pp. 289-302 (2008)
読んだ論文は次のとおり。Journal of Empirical Software Engineeringは論文誌としては、採択基準が厳しい部類に入る。
MS ResearchのWebから全文がPDFで読める。TDD Boot campを紹介するエントリでも本論文を紹介されているので、参考にしていただきたい。
示されている定量データのうち私が気にかかったのは以下のとおり。
| 定量データ（メトリクス） | IBM Driver | MS Windows | MS MSN | MS Visual Studio |
| ソースコードサイズ(KLOC) | 41.0 | 6.0 | 26.0 | 155.2 |
| テストコードサイズ(KLOC) | 28.5 | 4.0 | 23.2 | 60.3 |
| TDDを採用していない類似プロジェクトでの欠陥密度を1としたときの欠陥密度 | 0.61 | 0.38 | 0.24 | 0.09 |
| TDD採用により増加したコード実装時間（管理者の見積りによる） | 15〜20% | 25〜35% | 15% | 25〜20% |
欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。
また、次のような知見が紹介されている。
- 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき（既存のソフトウェアの次バージョンから始める場合には言及がない）
- テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。
- テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。
- 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。
どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数が2割増しと見積られている。また、不具合密度が9〜61%まで低減したことも述べられている。工数は見積りであり、不具合密度は同一のソフトウェアを比較したわけではないので、議論の余地はある）。
論文で紹介されているテストコードの比率を考えると、テストコードのメンテナンスのコストもそれなりに必要になりそうだ。
上述のようなデータが公開されていることは、これからTDDを、と考える方には貴重なものとなり得るだろう。テスト駆動開発のメリットは拡張性、保守性、可読性を（デグレードのことをあまり気にせず）高められることにもある。このあたりを評価できるようになると、TDDが適している開発、そうでない開発がもっと明確になり、自身のプロジェクトで採用するかどうか判断しやすくなるだろう。それはそんなに遠くない未来ではないように感じている。
ソースコード・リーディング・ワークショップ in デブサミ2010、締切りまで3日、まもなく満席、参加のご決断を
ディベロッパーサミット2010の1セッションとして、ソースコードリーディングワークショップ in デブサミ2010の進行を奈良先端大 保田と私で担当する。1/30に実施したソースコードリーディングワークショップ2010と類似するが、読解時間の「見積り」という点で少し趣が異なる。
参加者全員で手を動かし、その後、参加者どうしで意見交換する。そもそもデブサミに参加する時点で濃いエンジニアだと思うのだが、その中でも自身で手を動かし、このようなワークショップに参加する濃いメンバでソースコードの読み方戦略、ノウハウ、テクニックを意見交換しようという、もっと濃いエンジニアの集まりになるはずだ。
ソースコードリーディングワークショップでは、読解に焦点をおいたが、デブサミでは見積り時間の観点を加えている。今回の見積りはイテレーション、アジャイル開発等、個々人の見積りが重要度を増すような開発において、役立つと考えている。
参加の前提もそれなりにハードルが高いが、それだけに議論内容には熱が入ると見込んでいる。Javaアプレットのバージョン1.0の読解(1500行程度の規模)、バージョン2.0への簡単な変更仕様メモ、バージョン2.0と1.0の差分（13パッチ）が与えられる。1.0を理解し、13パッチそれぞれについて適用して問題がないかどうかを答えるのが具体的な作業だ。このとき、全体の所要時間を見積り、当日1時間分を残す形で、2/14（日） 22:00にデブサミ事務局に途中経過をメールする。
当日は実際に残りの1時間を読んでいただき、作業全てを終えることができるか実際に試していただく。その後、読み方、見積り方法をはじめ、参加者どうしでディスカッションいただく。また、ソースコードリーディングワークショップ2010のパネルディスカッションでの発言等もここで紹介するつもりだ。現在、集計中だが、間に合えば、1/30の読解結果の統計情報もここで紹介したい（今のところ間に合うか少し自信がない）。
デブサミのセッションのほとんどは、1セッション1時間程度だが、本セッションはほぼ2時間の長さだ。大きなイベントほど、著名な方の講演を拝聴する場になりがちだが、イベントの参加者どうしももっと交流すべきだと思っている。参加者も業務に何らかの都合をつけて、イベントで何かを得ようとしているモチベーションの高いエンジニアだ。そのようなモチベーションが高い者どうしでの意見交換は非常に価値が高いと思っている。
参加者全員が個別にコードを読んで意見交換するという機会は、それほど多くないはずだ。会場セッティングについて、デブサミ事務局の方にもいろいろとわがままを聞いていただいている。また、このワークショップをデブサミのセッションとして開催するにあたって日本IBMに、ご協力をいただいている。
セッションの最後で、これまでの調査結果から読解時間とソースコードの特徴を紹介する。現在、これまでにあまり言及されていなかったタイプのCouplingの概念が解明されつつあり、その一部を紹介したいと思っている。この調査においても日本IBM（同社アカデミックプログラム）から協力をいただいている。ソースコードの特徴解析ツールIBM Rational Software Analyzerを無償貸与いただいている。
このセッションの参加には準備が必要になるので、今週末にご決断を。準備の時間はかかるが当日のディスカッションでは、通常にはない貴重な経験が得られるはずだ。
詳細はこちらの「参加申し込み」から。
ソースコード読解。協力いただいた方には中間集計結果をお知らせ中
Javaで書かれた1500行程度のGUIアプリケーションのバージョンのnを理解し、バージョンn+1との差分19種類を適用してよいかどうかを答えていただく。バージョンnを理解するための所要時間、読み方の戦略、差分を理解するための所要時間、判断の戦略を答えていただく。
現在までに協力いただいた方のデータから19種類の差分の適用可否を判断するための所要時間の比率を算出し、中間結果とし、これまでの協力者の方々にお知らせするとともに、これから協力して下さった方には結果を確認し次第、中間報告の情報を提供していく予定。
オンラインで実施できる。結果をメールで送信いただく。メールアドレスはフリーのものを使っていただくことができ、匿名のまま実施できる。締切りは祝日に設定しており、次の締切は11/3。11/23を最終締切りとする予定。
こちらから今すぐ試せる。
Javaの言語使用と基礎的なライブラリをだいたい理解されていれば、1時間弱〜3時間くらいで終わる。
その意義や詳細はこちらをご覧いただきたい。
