森崎修司の「どうやってはかるの？」

情報処理学会のウィンターワークショップという恒例のイベントがある。2010年は倉敷で開催された。詳細はこちら。ワークショップは7つのテーマから成り、私は「ソフトウェア開発マネジメント「ソフトウェア計測とその活用」 」セッションのセッションリーダを仰せつかった。

ポジションペーパを事前に提出し自身の問題意識やテーマを紹介、参加者全員で意見交換する（ポジションペーパは査読で、セッションと合致しているかをチェックされる）。丸2日にわたり、様々なディスカッションが行われた。内容はかなり濃かった。参加者は全部で11名、研究者から問題意識や定式化の提案いただいた。プロジェクトマネージメントに従事されている方から、現実に困っている問題を提起いただいた。

実データの分析、利用方法、計測にまつわる課題についてディスカッションできた。出てきた話題はいずれも興味深かったが、特に私の印象に残ったのは以下のとおり。

• 「品質を早期に予測したい」→「欠陥検出密度のような数値を欠陥カテゴリ毎に収集したほうがよい。単純に数値だけでは判断できないことが多い。偏って検出されていることがあるから。」
• 「リスク分析、リスク予測するために着目すべきデータは？」→「過去の予実差の大きいプロジェクトの分析。見積りに失敗しているから」
• 「予測モデル、分析技法を普及させたい」→「モデル、技法のユーザビリティを考えるべき。信頼性、学習容易性をはじめとして、モデル、技法がどのくらい使いやすいか検討すべき。また、経営陣やプロジェクトマネージャ等のペルソナを設定しないとユーザビリティを考えるのは難しい。」

お忙しい中、集まっていただいたご参加者に感謝する。

また、このような機会がもてればと思う。

森崎

ソースコードリーディングワークショップ2010を開催した。日本IBMに共催いただき、@ITにメディア協賛いただいた。内容は、ハンズオンと呼ぶ、ご参加者が手を動かすセッション、ハンズオンにもとづいて参加者どうしで議論するセッション、講演X2, パネルセッション。

今回、休日であったり、仕事の都合でお越しいただけなかった方のために、今回のワークショップの縮小版を日本IBMにご協力いただいて、デブサミでも実施する。詳細はこちら。

開催は1/30(土)午後、休日の午後をほぼつぶすイベントだったので、ご参加いただいた方はたいへんモチベーションの高い方だ（物好きといってもいいだろう）。前回のソフトウェアインスペクションワークショップと比較すると、当日キャンセルの割合が高かったが、それでも通常のセミナと同程度だそうだ。参加者の方がここを読まれていたら、お礼を申し上げたい。お休みのところご参加いただいてたいへんありがとうございます。

コード読解のための時間は2.5時間。約2000行のJavaソースコードを読むには十分とはいえない時間だ。いつもと勝手の違う環境で、勝手の違うソースコードを読み、普段とは違う設問に回答するのは、スキルの高いエンジニアであってもたいへんな作業であると推測する。

せめてものおもてなしとして、共催のIBMさんと相談して、参加者にミネラルウォータをプレゼント。

ハンズオンは、紙かPCいずれかから、Javaソースコードのアプリケーションのバージョン1.0を理解し、2.0との差分13種類を理解する。13種類の差分を適用しても問題ないかどうかを判断するための所要時間と判断の可否を答える。バージョン1.0の理解の正しさや深さは、2.0との差分の可否によって判断できる。また、各差分には、変更の種類(追加、削除、修正)、変更規模(行数)、変更が与える影響規模(波及先: 行数)等の特徴を持たせている。

これらの特徴と、回答いただいた所要時間を合わせることにより、ソースコードの読みにくさを計測しようとしている。たとえば「波及先規模が大きい場合、変更規模が小さくても、理解に時間がかかる」というような知見が得られれば、派生開発や保守開発で、これから変更しようとしているソースコードがどの程度複雑(人手で確認するのが難しい)かがわかれば、これらの開発の見積りの精度が向上する。

また、回答いただいた所要時間から個人情報を削除すれば、コード読解のベンチマークになりうる。自身のソースコード読解の強みや弱みをみつけるための判断材料になる。また、読み進め方や回答例を示すことにより、自分がこれまで知らなかったソースコード読解のアプローチを知ることができるだろう。

ハンズオンの狙いは、@ITの記事で紹介いただいている。

また、当日の内容は以下の2メディアで記事化されている。
http://www.atmarkit.co.jp/news/201002/02/code.html
http://itpro.nikkeibp.co.jp/article/Watcher/20100202/344062/

日経ITproのほうは、2/2のアクセスランキング1位だったようだ。@ITの記事のほうは、はてぶが300を超えている。

ご参加者のエントリもある。
http://kwappa.txt-nifty.com/blog/2010/01/2010-9eff.html

Twitterのタグは#scr_ws2010。@kwappaさんをはじめとして、有益なtweetを数多くしていただいている。また、@src_wsでは、後日の報告をしていこうと思っている。

もう一つ、今回のイベントは企画段階で紆余曲折がたくさんあった。途中で「ひょっとして開催できないかも」と思うことがあったが、谷川氏、新野氏にとてもご尽力いただいた。とても感謝しているので、お礼を申し上げたい。お二人のご支援、事務局を担当くださったIBMさんのご支援なくして、今回のワークショップは成しえませんでした。たいへんありがとうございます。

もちろん、当日会場スタッフとなってくださった春原氏、服部氏、原氏、三井氏、田村氏、保田氏のご尽力、ご登壇いただいた戸島氏、ひが氏、細川氏、新野氏、よしおか氏にもいくら感謝しても十分に感謝したとはいえないくらい、助けていただいた。

久々に内容の長いエントリになった。ワークショップでの講演の内容やパネルディスカッションについては別エントリで報告したいと思う。

森崎

Twitterが広く受け入れられる理由のいくつかを次のように考えている。

• 読む（みる）立場から
  • みにいくと何か新しい内容があるという高い更新頻度
  • 「みているかもしれない」程度のゆるい情報共有が前提
• 書く（つぶやく）立場から
  • すぐに書き終えられるだろうという気軽さ（140文字しかないので本題から入っていても特に失礼にはあたらない点）
  • 長期にわたって議論につきあう必要がなさそうに思える or みなくても特にとがめられないであろうという雰囲気

他にも、電車に乗っている間や少しのスキマ時間を使える点も優れていると思う。このスキマ時間でコードを書いてみたらどうなるだろうか。現行Twitterを使うならば、書けるコードはオープンソースをはじめとして、機密がないものに限定されそうだ。

1ステートメント1つぶやきで、何らかのBOTにファイルにためていってもらう。ひょっとすると誰かが続きをつぶやいてくれることもあるのではないかと。

コードを書くには30分、1時間なりのまとまった時間が必要というイメージが強いのだが、つぶやくようにコードが書けたら、開発ももう少し変わっていくのではないかと思う。

つぶやいているそばから、テストコードをレビューするには案外向いているんではないかと思うが、いかがだろうか。。テストの網羅性は全部揃ってからでないと判断できないが。

次のエントリではちゃんとソースコードリーディングワークショップの内容を報告したい。

森崎

ソフトウェアテストシンポジウム2010東京の初日セッションC4「レビュー おいでやす」という変わった名前のセッションで、セッション内司会者として少しだけ登壇する。当セッションの前半は日立システムアンドサービスの角口氏の講演、後半は会場の皆様、データプロセスの新美氏をまじえて実際にレビューをしてしまおうという試み。

私は全体の流れの説明、タイムキーパーとガイド役、そしてもう一役、詳細は後日報告したい。先週土曜日に打合せがあり、大まかな流れを確認した。主役は、角口氏、新美氏だが、私にとってもいろいろと初の試みがあるので、楽しみにしている。

その2日後にはソースコードリーディングワークショップ2010を開催予定。

森崎

ソフトウェアテストシンポジウム2010 東京の1日目のセッションC2-4、ソニーの永田氏と共著で投稿した経験論文「アジャイルインスペクションの実際」の発表がある。アジャイルインスペクションについてはここ（本ブログの過去エントリ）で説明している。

内容の詳細は当日のお楽しみだが、アジャイルインスペクションを実際にやってみようという方には興味深い内容になる。アジャイルインスペクションが特に効果を上げるにはいくつかの条件があり、論文の考察にはその条件のいくつかが書かれている。

森崎

1/30(土)に東京、田町でソースコードリーディングワークショップ2010を開催する。参加者で同一のJavaソースコードを読んでいただき、参加者同士でその読解戦略の意見交換をしていただく。主旨や意義は@ITの記事にしていただいた。

ソースコードを理解することを厳密に定義することは難しいため、本ワークショップでは「バージョン1.0を大まかに理解し、バージョン2.0との差分の適用可否を正しく判断できること」としている。差分は複数ある。現時点では15種類程度になる予定で、バージョン1.0からの機能追加やリファクタリング等のタスクを設定し、タスクごとに差分が用意される。差分を適用して問題がないかを回答していく。

対象プログラムは、現在のところGUIアプリケーションでJavaアプレットで書かれたものになる予定。Java言語、アクションリスナやパネル等の知識があれば、読める。

ワークショップでは、Publickeyの新野氏をモデレータとして迎え、サン・マイクロシステムズの戸島 義徳氏、Seasarプロジェクトチーフコミッタ/電通国際情報サービスのひが やすを氏、日本IBM 細川 宣啓 氏、カーネル読書会主宰/楽天 よしおか ひろたか氏、私をパネリストとして、読解戦略を語る。

年末から私の仕事がうまくさばけておらず、本ブログでのワークショップ開催のお知らせが遅くなったが、既に申し込み開始しており定員を超える申し込みをいただいている。申し込みはこのページのリンクをたどっていただきたい。一部の時間帯で会場を増やす予定だが、その分もそろそろ埋まる見込みだ。

ディベロッパーサミット2010でも類似のワークショップを開催する。「平日じゃないと参加が難しいなぁ」という方や1/30の申込み終了の場合にお勧めしたい。

森崎

日本科学技術連盟の日科技連ニュースNo. 80（2009年12月）に寄稿した。

3つの課題としたのは以下のとおり。寄稿した記事ではもっと具体的に説明している。

• コスト・リソース
  レビューに必要な工数・時間、適任人材の少なさ等
• コミュニケーション
  レビューに参加するメンバの間のコミュニケーションの問題。目的の共有ができていない、指摘されてもエラーとは認めない等。
• 技術・制度
  技法や基準の不在。レビューへの参加や的確な指摘に対する評価制度の不在。

ご自身のレビューで最も課題と考えられるものはどれだろうか？

また、同記事で特に目的を明示的に指摘しなかった場合のレビュー指摘の70%超が将来の保守や拡張時の問題や表記上の欠陥であることを報告した論文の内容を紹介し、レビューの事前合意（目的意識の共有）の重要性を説明している。

森崎

修正確認テスト（回帰テスト）の規模が大きくなりそうなところからレビューしていく、という技法の論文が掲載された。レビューで見逃した場合にテストで手こずってしまうエラーを優先的に発見するための技法だ。

我々の研究グループで技法を検討の上、実験したところ効果を確認できた。設計ドキュメントであれば、多くの機能やサブシステムから利用されるインタフェースやプロトコル定義、ソースコードであれば、共通ライブラリ、性能改善部分等、もしもレビューで見逃して、テストで発見された場合に、修正と修正確認コストが大きくなりそうなところから、レビューしていく。

論文では、テスト計画書のような大まかなテスト規模がわかるドキュメントを使って、見逃した場合にテスト規模が大きくなりそうな部分からソースコードを読んでいく実験をした。何も指定しないアドホックリーディングと比較して、レビューで低減できる修正確認テスト規模が半分程度になることが確認できた。

詳細は以下の論文にある。PDFは情報処理学会電子図書館かこちらへ。

田村 晃一, 亀井 靖高, 上野 秀剛, 森崎 修司, 松本 健一"修正確認テスト規模の低減を目的としたコードレビュー手法,'' 情報処理学会論文誌, Vol.50, No.12, pp.3074-3083 (Dec. 2009)

森崎

私自身は残務があって、まだ休みに入れないという状況だが、当ブログの振り返りを。

上位はソフトウェア開発に関係するものがほとんど。それ以外ほとんど書いていないので、当たり前だが。ランキングは下のとおり。来年こそは、閲覧数以外にも読者の多様性等や新規の閲覧者などのメトリクス（評価尺度）を含めたいところ。機会があれば、私のお気に入りエントリも紹介したい。

1. トップページ
2. ソースコードのコメントよりも空白行のほうが理解を助けるという研究結果
3. 三菱東京UFJのシステム統合完了の話題は少ないようだが。。
4. 本当に「マルチコアプロセッサのコア増加のペースが早すぎてそれをフルに活かすソフトウェアが現れない」のだろうか？
5. 趣旨と異なるが学会発表風にしてみる・・・『普通のプレゼン資料を５分で「かっこ良く」するテクニック（初級編）』
6. 「計測/メトリクス」カテゴリーの投稿（カテゴリのトップページ）
7. 「レビュー/インスペクション」カテゴリーの投稿（カテゴリのトップページ）
8. ソースコードを書くスキルよりも読むスキルが求められる理由
9. Googleのコードレビュー
10. ソフトウェアFMEAの事例発表（来週）

カテゴリのトップページが6, 7位となったこと、1位がトップページ。検索エンジン経由での閲覧が多いことを示しているからだろう。

森崎 http://twitter.com/smorisaki

IEEE Working Conference on Mining Software Repository（MSR）というソフトウェア開発に関するデータベースにおけるマイニング（傾向抽出、知見獲得）を検討するカンファレンスで発表した修正工数分析の論文（Defect Data Analysis Based on Extended Association Rule Mining）に手を加えて日本語版をSoftware Testing ManiaXに寄稿した。

過去のバージョンのバグ票のうち、修正に時間がかかったものにどのようなものがあるかを調べるための手法を提案し、実際にバグ票あてはめた結果を国際会議の論文に書いた。論文の詳細はこちらへ

今回寄稿した原稿では、研究的バックグラウンド、分析アルゴリズムを省略し、実際の分析結果や実施方法を書いている。

Software Testing ManiaX vol.2の購入方法はこちらへ。ソフトウェアテストに関連する業務に従事する若手を支援するワークショップ（WACATE）の活動に役立つらしいので、私なりの恩返しということで寄稿した。

森崎