ソフトウェア開発において何らかの定量データを収集して、状況を推測しようとしたり問題を解決しようとしたりすることは一般的になっていると思います。データ収集の対象はコードカバレッジかもしれないですし、工程毎の欠陥除去率かもしれないですし、スプリントのベロシティかもしれません。
現時点では、計測値か計測値による意思決定の基準の両方、またはどちらかが完全には客観的にはなっていないため、計測値や基準は、あくまで目安です。これだけ計測してモニタしてさえおけば十分ということはほとんどないでしょう。
計測と計測値による判断は、何らかの望ましくない状況や望ましい状況とメトリクスをひもづけて、計測値がこうなっていたら望ましくない状況が起き始めている、望ましい状況になっているということを事前合意しようとしていることだと解釈できるでしょう。実際にはお仕着せで合意なんてしていないという話はあると思いますが、根源をたどるとそのような事前合意があったのではないでしょうか。
合意が十分でなかったり、計測が想定している「望ましい状況」、「望ましくない状況」が伝えられないまま計測と判断だけが残ってしまっていることも少なくありません。計測値の正確性や再現性、判断基準に曖昧さが残るものであればソフトウェア開発に限定されないと思うのですが、計測結果の背景にある状況をそもそも意識できているかどうか、意識しているとして具体的に状況をイメージできたり、問題解決に向けた対策の姿勢があるかどうかが大切です。
特に、自身で計測しながら、基準外の場合にその理由を説明しなければならないときや結局自己解決しか方法がないときには、計測と説明のオーバヘッドばかりが目立ってしまい、必ずしも本質的な解決に至らない場合があります。
「基準値に達しなかったから（基準値の上限値、下限値の範囲を超えている）その理由を書く」というような手順が浸透していると、ついついその値と理由だけから状況を判断してしまいがちです。本来であれば、その背景にある状況や課題を推測して、解決を試みなければならないはずです。
どうやって計測するか、計測値の判断はどうするかということよりもその背景の状況や課題解決を試みることが大事な局面は多く、メトリクスを扱う上で最も大事なことの1つですが、気がつくと意識されていなかったりするのではないでしょうか。
ソフトウェアメトリクスの基本分類と本エントリの内容を日経SYSTEMS 2012年5月号に「メトリクスのきほん」という記事を寄稿しました（22～23ページ）。短い記事ですが、私が大事だと思っていることを要約できたように思います。お近くにあればご覧ください。目次はこちら。
バグが含まれていそうなソースコードモジュールを予測することをfault-proneモジュール予測と呼びます。予測の単位であるモジュールはソースコードファイルであったり、メソッド、クラスであったりします。過去の傾向に照らし合わせて、予測する方法が一般的です。
たとえば、規模が大きいファイル、メソッド、クラスにバグが含まれているという傾向から予測したり、特定の（一般には複雑なロジックを持つために実現が難しい）機能を実現するソースコードという傾向から予測したりします。ここ（本ブログの過去エントリ）でも紹介しましたが、過去に何度も改変されているとバグを含む可能性が高いという経験則を使っているものもあります。改変担当者による予測もあります。
過去にバグが含まれていたモジュールとソースコードメトリクス等の特徴を統計モデル等を使って学習させ、それ以外のソースコードにバグが含まれているかどうかを学習したモデルを使って予測する方法もあります。上の方法と比較すると予測精度が高まることが確認されています。ソースコードメトリクスは規模、複雑さ、他との結合の度合い（他への依存性）といった特徴を数値化したものです。
もっと簡単に「ここは怪しいなぁ」という感触もfault-proneモジュール予測となり得ます。そのような感触を含め、ご自身のプロジェクトでは何をヒントにfault-proneモジュール予測をされていますか？
Programs, Life Cycles, and Laws of Software EvolutionというタイトルのM. Lehman氏の論文があります。論文の著者の名前で"Lehman's law（リーマンの法則）"と呼ばれていることもあります。
論文はタイトルのとおり、以下のような3つの部分から構成されています。
- プログラムの分類: プログラムを3つのタイプに分類しています。
- ライフサイクル: 開発→リリース→拡張→リリース・・・といったソフトウェアのライフサイクルが書かれています。
- ソフトウェア保守の法則: 商用ソフトウェアの開発において収集したデータをもとに「使われるシステムは変わり続ける」「対策をしない限り、継続して変更していくとソフトウェアがだんだん複雑になる」等をはじめとして5つの法則が書かれています。
出典は M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution” IEEE Transactions on Software Engineering, Vol. 68, No. 9, pp. 1060-1076 (1980) です。
シンプルなものばかりですが、今でも十分に通用する内容です。この論文をはじめとして保守開発（既存バージョンをもとに拡張していくタイプのソフトウェア）を対象とした論文は非常に多いのですが、意外と知られていないものが多いように思います。
前に本ブログのエントリにした「バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点」もそのような知られていないものの一つではないかと思います。このエントリで紹介している論文は2000年に公開されたものです。
また、Google Engineering Toolsのブログエントリ「グーグルでのバグ予測」（Bug prediction at Google）で参考にしたと記述されている論文の1つである"Predicting Faults from Cached History"も同じように過去の不具合と更新履歴からApache httpd, Subversion, PostgreSQL, Mozilla, JEdit等を対象にして過去に修正の多い箇所に次の不具合も存在しやすいという経験的法則を報告しています。
商用開発においても、開発のほとんどは既存バージョンのソフトウェアを改変して新たなバージョンを作るという保守開発になりつつあるように思います。そのような保守開発に関してプロセス、課題、基礎技術、事例、研究動向を紹介するセッション「アプリケーション保守開発の基礎と研究動向～短納期時代の課題と対策、最新動向～」をSODEC（ソフトウェア開発環境展）の専門セミナーでお話することになりました。5/10（木）9:30～ 東京ビッグサイトです。詳細はこちら。他のセッションを含めた一覧はこちら。
有料のセミナーなので保守開発に困ってらっしゃる方が対象になるかと思いますが、プロセスの整理や事例に関して、基礎的な情報から動向まで概観できる内容となるよう準備しています。セッションの後半は富士通鎌倉氏から運用コストの視点も含めて保守開発の事例と効率化のポイントが紹介されます。
「レビューの価値を考える」という記事をEM West vol. 2というフリーペーパに寄稿しました。2010年7月くらいです。紙の冊子で勉強会やカンファレンス等のイベントで配布されることが多かったのですが、iPadZine経由でオンラインでも読めるようになったそうです。こちらから。同ページのリンク「直接ファイルを開く」からPDFとしてダウンロードすることもできるようです。
内容の詳細はリンクをご覧いただくとして、概要は以下の通りで、私のレビューに対する考えを比較的コンパクトに示しています。レビューの価値はレビュー実施の効果があるか、適切に実施されたか？という二つから決まり、その判断はコンテキスト（対象ソフトウェア、プロジェクト、レビュー対象）から総合的に決まるというものです。レビューの価値がどういうときに得られるかという点については、ウォータフォールモデルを前提としない汎用的な書き方に近いと思っています。
オンライン化に伴って、自分自身で久々に読み返してみたのですが、私のソフトウェアレビューに関する考えが比較的コンパクトにまとまっているように感じました。2ページほどですが、書くのに時間がかかった記憶があります。
EM West vol.2では、そのほかにも電通大の西氏がW字モデルを紹介されていたり、データプロセスの新美氏がソフトウェアテストシンポジウム関西の紹介をされていたり、XPJUG関西前代表の細谷氏がET West2010での「アジャイル×テスト開発プロセスを考える」というセッションを紹介されています。
他にも、横山氏が西日本のソフトウェアエンジニアのコミュニティの紹介、大谷氏が北陸のコミュニティの紹介、細谷（あ）氏がアロマ・ハーブティーの紹介、前川氏が要求開発の紹介、本間氏がソフトウェア開発における動機付けといった盛りだくさんです。
執筆の際に、細谷氏（@yasuohosotani）、前川（@tetsu_m）氏にたいへんお世話になりました。ありがとうございます。
きれいに整理され、見た目も美しいドキュメント作成に時間をかける、やるべきことを細かくリストアップし、全てを計画どおりに実施する、とにかく最高の状態に仕上げる、というのは私を含め日本人にとっては気持ちの良い作業で美徳と感じる方も多いと思います。
やるべきことがガチッと決まっていてあまり変わらず、上のような作業が最終的な価値や質の向上に結びついている場合には大きな効果を発揮しますが、場合によっては単にたくさんの作業をこなしているだけで最終的な価値や質の向上には結びついていないということもあります。
事前に計画してから実施している場合であっても、本当に最終成果に結びつくような活動をしているかどうかを常に意識することは、意外と難しいのですが大事なことだと思います。作業の積上げが大きい場合にはなおさらで、いったんやってしまうとなかなか後に引きにくくなることもあるため、短い周期で振返り、必要であれば軌道修正していくことが大事なように思います。
ご自身のソフトウェア開発においても最終成果と現在の作業の関連を見直さなければならない状況に出会ったことはないでしょうか。何年か後に再設計の可能性のある部分で特に求められていないのに、ひたすらリファクタリングをしていたり、その部分よりも実行頻度が高かったりソフトウェアのウリになる部分があるにも関わらず、他の部分をテストしていたりという光景はどこにでもあるのでないでしょうか。
また、担当者に限らず、教育と称して長時間にわたる会議やレビューと称してあまり意味のない会議を繰り返してしまっていたり、管理部門やPMOに対する報告書を書くことが主目的になって懸念事項や課題を列挙するだけで解決ができていなかったりということもあると思います。
これらの作業は最終的な成果物の価値や品質の向上に結びつく部分も、もちろんあるので、状況や背景、最終成果物に求められているものを考えずに、適切、不適切の判断をすることはできないことが多いでしょう。適切、不適切は誰かが考えるものではなく、時々で作業に関わる全員が見直していく必要があるように思います。見直しは1回目はうまくいかず、あの人ガンコだなぁという感想だけが残るかもしれませんが、数回繰り返していくうちに考えがまとまっていくこともあるように思います。
本来、作業（上述の成果物やドキュメントをブラッシュアップする作業）と同じくらい時間をかけて、計画や合意、見直しをしないといけないはずですが、意外にさらっと決まっていたり、とりあえず書いた案が通っていたりということも少なくないように思います。その感覚をもって見直しができるかどうかが最終的な価値や品質に大きく寄与すると考えています。
ご自身や所属する組織やチームでは、メンバの間でそれらを合意したり見直したりするためにどのような工夫がありますか？
ソフトウェアレビューでは検出すべき欠陥をイメージしてから進めたほうが効率的で欠陥の検出もやりやすいと感じています。検出すべき欠陥は「性能(の欠陥・問題)」「セキュリティ」といった多くのソフトウェアにあてはまる汎用的なものが多いと思います。チェックリストは検出すべき欠陥をリスト化していると考えることもできると思います（欲張りすぎて形骸化していることもあると思いますがチェックリストの本来の意図は検出したい欠陥のリスト化にあると思います）。
一方で検出すべき欠陥が汎用的ではないけれども、特定業務において特に検出したい典型的な欠陥、特定業務においてレビューで見逃すとリスクや手戻りが大きくなる欠陥もあります。過去のバージョンの開発時に収集されたバグ票を見渡すとそのような欠陥種別に出会うことがあると思います。業務系であれば月締めの処理での典型的な欠陥がそれにあてはまったり、高いリアルタイム性が求められるソフトウェアの場合には実行命令の分岐数や最長パスに絡む欠陥がそれにあてはまったりすると思います。ドメインのノウハウと呼ぶことができるのかもしれません。
ユーザ系企業のシステム部門とご一緒して、そのような特定業務の観点でのレビューが可能かどうかを過去に収集された不具合管理表の情報を使って検討しました。検討では日付に関する欠陥(期間の定義や日次処理のチェック)を早期検出できるかどうかを調査、検討しています。秋葉原UDXで2012年3/5(月)のエンピリカルソフトウェア工学研究会で検討結果を紹介します。当日お越しいただいた方には、より具体的な情報を提供できるのでお時間があればお越しください。研究会の詳細はこちら。
他人が他に正解はなく自身を正当化しようとするところを見たことは誰にでもあるのではないでしょうか。また、知らず知らずのうちに自分がそうなっていることもあるかもしれません。
本ブログはソフトウェア開発に関することをテーマとしているので、ここを読んでくださっている方にもう少し身近な例として「正解」を「現場」と変えて紹介してみたいと思います。現実には開発の現場は多種多様でひとくくりに「現場では」というふうに抽象化するのは適切でない場合が多いのではないでしょうか。自身の現場を様々な現場の代表とする考えは必ずしも適切とは限りません。特に規模が大きいソフトウェア、高い信頼性が求められるソフトウェア、その分野を専業としている場合には、特にその傾向が強くなるように思います。「自分が関わっている現場では」というのが適切ではないでしょうか。
たとえば、多種多様なバックグラウンドを持つ数人～十数人の集まりがあり、その中で自分1人だけがエンタープライズ系のソフトウェア開発に携わっているとします。他の方は組込みソフトウェアを開発しているとしいます。そうすると自分が知っていることを「エンタープライズ系では」と言ってしまったとします。それは厳密には「私が携わっているプロジェクトでは」の可能性もあります。もちろん言葉どおりエンタープライズ系のソフトウェア開発に固有の話かもしれません。
正解が1つしかない場合と比較すると、状況や文脈（コンテキスト）に応じて複数の正解があることのほうが圧倒的に多いはずです。また、何を正解としてよいのかわからないことのほうが多いかもしれません。そして、複数の正解を受入れたり正解の判断に困ることは視野を広げてくれることにつながると思います。
正解がコンテキストに応じて複数あることを受入れるための1つの方法に、コンテキストが異なる人の前で議論や発表することが挙げられます。勉強会やコミュニティでの議論や発表の魅力の1つはここにあると思います。
少しまとまった準備時間をとってこれまでのご自身の活動を振返りたいという方にはカンファレンスやシンポジウムへの論文投稿をお勧めします。準備の時間が必要になることや聴衆のほとんどが見知らぬ人ということを意識すれば、より深い成功要因の分析、振返り、内省につながる場合が多くなるでしょう。
ここからは宣伝なのですが、そのようなシンポジウムの1つとしてソフトウェア品質シンポジウムがあります。私は今年も実行委員の1人としてシンポジウムを盛り上げていきたいと思っています。詳しくはこちらを。
論文投稿の受付けを開始しており締切りは4/18です。Webページに掲載されている初回投稿時のフォーマットを見るとわかるのですが、分量はそれほど多くありません。査読があり、採録になれば論文や発表スライドを準備いただくことになります。発表者の参加費は5,250円でカテゴリDのPDUも発給されます。
PC MagazineのWeb記事として、マイクロソフトのWebブラウザの性能向上のためのテスト環境の取材記事が掲載されています。（「Microsoft Details Its Browser Performance Testing」）
Windows 8のブラウザで閲覧を速くするための環境で、140台の計算機から構成され、模擬的なインターネット、サーバ、クライアントから構成されているそうです。ネットワーク環境として様々な帯域、遅延、DNS、プロキシの有無をはじめとして、サーバやクライアントにも様々なものが用意されており、性能評価のために再現性があり信頼できるメトリクスを収集しているそうです。
収集メトリクスは、ページが表示されるまでの時間、ページをネットワークから取得するまでの時間、CPU占有率をはじめとして850種類以上あるそうです。1日200回のテストを実施し、480GBのデータを収集しているそうです。記事には具体的に性能向上に結びついたメトリクスや性能向上の方法は掲載されていませんが、テスト環境の写真がおよそ10枚掲載されており、その様子を見ることができます。
Windows 8のブラウザがこれまでのブラウザよりも大幅に性能向上していたら、このテスト環境での分析が役立っている可能性が高く、網羅的で現実に即したテストと細かいデータ収集が性能向上に役立つことを示唆する結果となるかもしれません。
今年のAgile Japan 2012は大阪ATCで3/16（金）に開催されます。午前中の講演は、大阪から他の地域（サテライトと呼ぶ）へUStreamで配信されるそうです。午後のセッションは各サテライトで独自のものが計画されています。午前中は「アジャイルサムライ - 達人開発者への道」という書籍（原題: Agile Samurai）の著者J. Rasmusson氏、岸良 裕司氏の基調講演とIPA SECから山下氏の特別講演があります。ソフトウェア開発に関するイベントで大阪で海外の著名な講演者の講演があることは、それほど多くないように思います。この機会に出かけてみてはいかがでしょうか？午後のセッションも大阪を活動の中心にされているコテコテな方から、首都圏を中心に活動されている方のセッションまで、どれに出ようか困るくらい並んでいます。
私は、午後2番目のセッションに脇役として登壇します。Deep Agile Peopleというセッションです。牛尾氏、川端氏、原田氏の三名がそれぞれの立場からアジャイルに関する議論をします。パネルディスカッションのようですが、実は三名にはあまり聴講されている方のことを考えず、三名だけの世界でお話していただく予定です。解説・進行担当の細谷氏と私が、三名の話に適宜細かい説明を加える予定です。このセッションの起案は細谷氏、NHKのDeep peopleというテレビ番組がモチーフになっているそうで、かなり引き込まれていくのではないかと楽しみにしています。
大阪でイベントの企画や登壇すると関西以外の方から「大阪独特の雰囲気が少し敷居が高い」という感想をたまにいただくことがあるのですが、セッションの多様さからAgile Japan 2012は関西以外の地域の方からの参加もお勧めできそうです。金曜日開催なので、土曜日に観光するという選択もありそうです。会場のATC付近には、海遊館という有名な水族館やユニバーサルスタジオジャパンも近くにあります。
Agile Japan 2012に参加するには参加費が必要です。2/17が早期割引の締切りだそうです。詳細はこちら。
D. Hamlet, R. Taylor: "Partition Testing Does not Inspire Confidence", IEEE Transactions on Software Engineering, vol. 16, No. 12, p. 1402-1411(1990)という論文があります。そこでランダムテストと分割テストの不具合発見率を掲載しており、結果の考察において下のような部分（原典では「ルーチン」）をテストすることを"suspicion testing"として提案しています。タイトルにあるとおり「疑わしいところテスト」と訳しておきました。よりよい訳があればコメント欄から送信していただければと思います。
- 開発プロジェクトの中で最も経験の少ないプログラマが書いた部分
- 開発や過去のリリースで不具合があった部分
- レビューで欠陥が指摘され開発サイクルの終盤で変更のあった部分
- ほとんどのコーディングが終了した時点で設計変更のあった部分
- 設計者や実装者が簡単ではないと感じた部分
論文では実際にこれらを用いて評価は実施していませんが、探索的テストやテストで不具合をうまく見つけられるエンジニアが実践していることのようにも思えます。「そんな情報出せないよ」とか「そんなところテストしてもしょうがないよ」と思ったときには、この論文を引き合いに出すとうまくいくかもしれません。タイトルで検索すると著者のWebで公開されているPDFが見つかるかもしれません。
ストレス社会との付き合い方
「思いやり経営」のススメ
テレワークが労働者のマインドを変える
求む、クックパッド男子
37歳の常識――我々は一生学び続ける