レビュー時間を短縮するための技法「アジャイルインスペクション」の勉強会 (9/15 東京三田)

レビュー／インスペクションの時間を短縮したいという方向け。7月にソニーの永田氏が実施されています。今回は、普段ソフトウェア設計、プログラミング、プロジェクトリーダ・マネージャをされている方向けに以下の要領で実施します。お気軽にご参加ください。

  • 日時: 2009/9/15(火) 19:00〜20:30（予定）
  • 場所: 東京三田、キャンパスイノベーションセンター（地図JR田町駅 芝浦口すぐ）
  • 参加資格: 普段、業務でソフトウェア設計、プログラミング、プロジェクトリーダ、マネージャをされている方
  • 参加費: 無料（ただし事前登録制）
  • 注意事項
    • 参加者全員にアジャイルインスペクションを実施いただきます。
    • 7月の永田氏のワークショップに参加された方はお控えください
    • 筆記用具をお持ちください。
    • 実施結果は個人情報を削除の上、論文等で公開いたします。
  • 参加方法（9/9（水）まで。定員になり次第、締切ります）

inspection_wg_info＠is.aist-nara.ac.jp（"＠"は半角に変更ください）まで「アジャイルインスペクションワークショップ参加希望」の旨と氏名、電話番号をご記入の上、メールしてください。場所等、細かい情報を9/11（金）までに送りします。

プログラム（予定）
19:00〜19:20 アジャイルインスペクションの概要説明（永田氏 or 森崎）
19:20〜19:40 第1回アジャイルインスペクション（参加者）
19:40〜19:50 休憩
19:50〜20:10 第2回アジャイルインスペクション（参加者）
20:10〜20:30 ディスカッション（参加者）

アジャイルインスペクションはレビュー／インスペクションの1つの方法です。対象ドキュメント全てをレビュー／インスペクションするのではなく、一部を抜き取って実施し、品質（欠陥密度）が目標値になるまで、抜き取り→インスペクション→修正のサイクルを繰り返します。品質が目標に達していない場合には、ドキュメント作成者に指摘事項とともに他の部分も修正するよう依頼します。通常のレビュー／インスペクションが網羅的な欠陥の指摘と指摘の修正であるのに対して、アジャイルインスペクションでは、一部を対象とする点が異なります。また、ドキュメント作成者が指摘された欠陥のみを修正するのではなく、指摘された欠陥と類似する別の欠陥の修正をする点も異なります。

情報処理学会会誌 2009/5に永田氏（ソニー）の解説記事にアジャイルインスペクションの解説が掲載されていますので、詳しくはそちらをご覧いただければと思います。

「ソフトウェアインスペクションワークショップ2009」@ITでニュース記事に

ここで紹介していたソフトウェアインスペクションワークショップ2009を7/2に開催した。その内容は、atmarkitのニュース記事("レビュー"とは、責め合うものではなく、品質を高め合うもの)になった。

定員60名を大幅に上回る申込みをいただき、開催10日前にして申込みを締切ることになった。100名の定員の会場はとてもせまく、普段の力が発揮できなかったのではないかと思う。

このワークショップの特徴の1つは、参加者によるハンズオンとハンズオン結果を（個人情報を削除し）公開していくことにある。参加者をオープンに募集し実施したものを論文を中心に調べたが、私が知る限り過去にはないようだ。ハンズオンでは、4500LOCのJavaソースコードをセキュリティの観点で1時間ちょっとで読むという内容だった。それでもアンケート結果によって、3割の参加者の方が普段よりも時間当たりの量は少ない、という結果が得られた。

ハンズオンでは3種類の技法を実施いただいた。うち、2技法はチェックリスト等のガイドに沿って読み進めていただくもので、1つの技法あたりガイドが4種類あり、全部で9種類(2技法 X 4種類 + 1技法)のハンズオン資料を準備した。題材はドイツのFraunhofer Institute for Experimental Software Engineeringからのもので、10日前に届いた英語版の要求仕様、ソースコード(表示メッセージやコメント)、設計書、技法の説明を和訳しなければならず準備のほうも相当厳しい状況だった。学生さんの援助なくして実施はできなかった。

事後アンケートの結果によると非常に評判がよかった。運営メンバとの雑談では、最後のパネルディスカッションの後、「このまま打ち上げいきましょう」と提案すれば多くの参加者が参加したのでは？という話題もあがるくらいだった。

「ソフトウェアレビュー会議の計画、参加者は納得していますか？」@ITの記事より

レビューがうまくいかない理由の1つに、参加者(レビューア)の同意がないということが挙げられる。
たとえば、以下のような感じ。これを解決するための方法として、計画と納得してもらう方法を紹介した。詳細はこちら。

中堅くらいの方であれば目にしたことがある、あるいは、実際に自分のレビューで起きた、ということがあるのではないだろうか。

──ある日のこと……

担当者 「Xサブシステムの設計レビュー、どうしましょうか？」
リーダー 「エラーを見逃すと、結合テストのときにバグがたくさん出るだろうしな、きちんとレビューしておこうよ。C課長、D主任、E主任、あとは君と私でやろう。日程調整してもらえるかい？」

──ところが、レビュー会議当日になってみると……

D主任 「これはまだレビューできる状態じゃないと思いますね。例えば『機能一覧』なんて抜けが3カ所もあるし。それよりさっき顧客から電話があってね、そっちの対応が緊急なので、すみませんが抜けさせてください」
リーダー 「仕方ない……。ところで、E主任は？」
担当者 「来るはずだったんですけど、どうも外出中のようです」
リーダー 「……Cさん、すみませんが、3人でやっちゃいましょう」
C課長 「よし、じゃひととおり説明してくれる？ まだ読んでないんだよ」
リーダー 「はい。まず『機能一覧』ですが……」
C課長 「ふんふん、なるほど。ところでさ、最後のページの用語集なんだけど、用語を選ぶ基準が不明確だよね。今日はとりあえず用語集を徹底的に修正しよう」
リーダー 「……はぁ」

──Xサブシステムのソフトウェアテスト結果を見て……

リーダー 「うーん……。異常系のテスト結果がひどいな。設計レビューでの見逃しが多すぎる」

IBM developerWorksの「コードレビューの道具、使っていますか？」という記事

IBMの方に声をかけていただき執筆する機会をいただいた。記事はこちら。atmarkitの連載記事（現在、1回目のみ公開中、近々2回目も公開予定）のほうはここ数回は入門的なものになっているが(これからこちらもマニアックになる予定)、developerWorksのほうは、読者層もマニアックな気がしたので、デザインパターンの自動抽出ツールの研究段階のプロトタイプの紹介等、少し先進的な内容もいれてみた。

レビュー、インスペクションがもっと効率化されたら(定時で帰れたり、終業後、技術談義とかできたら。。)いいなぁ。

今みたら「はてぶ」が56ついている。

ソフトウェアレビュー技術者集まれ 7/2(木) 13:30〜 @ 三田

実際に手を動かしながらソフトウェアレビューをし、実感して得られたことを会社の垣根を越えてグループでディスカッションする。グループ毎のディスカッションの内容を受けて、参加者全員でパネルディスカッションを通じて明日に活かせる内容を考える。

そのような交流の場（ソフトウェアインスペクションワークショップ2009）を7/2(木) 13:30〜 東京三田で企画している。日本IBMでクオリティインスペクション活動を進められている細川氏からも講演いただく。

ワークショップの詳細はこちらから。参加は無料だが、人数把握のため事前登録制としている。主催はワーキングループ（Working Group of International Research Cooperation on Software Inspections）、共催はFraunhofer Institute for Experimental Software Engineering、日本IBM、奈良先端科学技術大学院大学。

参加者が実際に手を動かしてレビューをした結果は、個人情報を削除した上で、論文としてフィードバックする予定だ。自身のレビューに関する知識を会社の垣根を越えて共有し、論文へのインプットを作ることで業界や学界へ貢献できる稀な機会となっている。ぜひ参加いただきたい。

ソフトウェアレビュー会議の記録、どうしていますか？

ソフトウェアレビューの記事がatmarkitに掲載された。記事は連載の予定で、初歩的なところからだんだんと高度になっていく予定だ。タイトルは「“確実な記録”こそが、品質・コストに貢献する」。連載の1回目になる。記事はここに掲載されていく。

1回目は初歩的なミスではあるが、下のようなことが起こっていれば今回の記事は役に立つだろう。
逆に「また書きものの話か。。」と思われる方には、おそらく今回の記事はあまり役には立たないだろう、次回以降より高度な内容になった時点でご覧いただきたい。

レビューアA　「あれ？ そこ、タイムアウトしたときの処理を1つ追加してほしいってレビューで指摘したつもりだったんだけど……」

修正担当者　「そんなのありましたっけ」

レビューアA　「記録を見てごらん」

修正担当者　「手書きのメモしかないんですが……書いてないですね」

レビューアB　「うーん……。僕もそのタイムアウトの件では、『ほかとの整合性が取れるように、そろえてほしい』といったように記憶している。それがつまり『処理を追加してくれ』という意味だったんだけど」

修正担当者　「……書いてないですね。でもBさんの指摘は確かにメモがあります。ただ、『そろえてほしい』というのは、その直前まで話していた“タイムアウトした際のエラー画面のレイアウト”についてだと思っていました」

インスペクション特集 第5週のまとめ

あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。
第5週目をまとめてみた。

一言ずつ私の感触を書いてみると。。

  • インスペクションを自在にカスタマイズ（Frank Elberzhager Institute for Experimental Software Engineering: 訳: 森崎 奈良先端科学技術大学院大学）レビュー／インスペクションを参加者やシステム、ソフトウェアの求められる要件にあわせてカスタマイズする方法を商用開発での実践例に基づいて述べている。同じコードレビューアでもビギナとエキスパートでは観点を変える、等。
  • 技術レビュー演習のWeb上体験（野中氏 東洋大学） レビューの実際の課題を紹介し、レビューの進め方や効果計測について紹介している。課題は、レビューしがいのある規模、複雑さ、現実のシステムで起こりうる要素を含みながら、コンパクトにまとまっている。また、読み進める際の観点についても具体的に書かれている。