今月のお題は「レビューのススメ～おかわり～」ということで、前回来れなかった参加者からの熱烈ラブコール
によって決まりました。集まった参加者は11名。
場所は前回に引き続き楽天さん会議室をお借りしました。ありがとうございました。
また今回の題材もTEF道のJaSST'12北海道のワークショップのものです。
今回は前回の振り返りを反映して、ワークの進め方を少し変えてみました。
まず最初にレビューしてますか？と聞いてみました。
ほとんどの方の手があがりました。
その後にレビューを省くことはありますか？と聞いてみました。
こちらはソースコードレビューを省くことがあるという参加者がいました。
まずはレビューって何ということを復習してみます。これは前回と同じです。
*****************************************************************************
レビューは、ソフトウェア成果物(コードも含む)をテストする一つの手段であり、動的テスト実行前に大きな効果がある。
ライフサイクルの初期のレビューで摘出した欠陥(例えば要件の欠陥)の修正は、コードを実行して検出した欠陥を修正する場合にくらべ、はるかに安価である。
（中略）
レビュー、静的解析、動的テストは、欠陥の検出という同じ目的を持っている。この3つの技法は、お互いに補い合っている。すなわち、異なる技法は異なる欠陥を効率よく効果的に摘出する。静的テスト技法は、動的テストと比較した場合、故障自体ではなく、故障の原因(欠陥)を探すという違いがある。
JSTQB FLシラバスより抜粋
*****************************************************************************
レビューは広義の意味でのテストの一つであり、欠陥を検出するという目的ということですね。
さて、レビューの種類の説明です。
アドホック、パスアラウンド、ペアレビュー、ウォークスルー、チームレビュー、インスペクションなどです。
そして近頃流行語大賞を狙えそうな観点の指定がないワイルドレビューをやってもらいました！！お題はFreeCelというマインドマップのFreeMindからExcelへ変換をするツール。
実務でバリバリ実施している人は、ワイルドレビューでも独自に観点を設定しているようです。うーん さすがですねぇ。。。
さてここから前回と少し流れを変えて、今度は観点を持ってレビューしてもらいました。
「君がユーザーだとすると、メッセージが適切か？ 」
なかなかこのように明確にレビューを頼む人は少ないですよね！
観点を設定すると、ワイルドレビューのときより指摘がスルスルでるようです。
さて、観点の効果を確認したところで、自分が出した欠陥から観点と目的を出してもらいます。前回はリバースという方法を使ったのですが、手が止まっていましたので今回は以下の用に誘導しました。見ていると手が止まることはあまりなさそうでした。
・同じような欠陥を見つけるためにはどうする？（調べ方）
▼
・どのようなキーワード/フレーズがあれば意識できる？（観点）
▼
・その欠陥を見つけると誰の、どのような問題を解決できる？（目的）
このあとグループディスカッションでそれぞれの人の観点をお互いに確認しました。
ここでこの前実施したときに観点の粒度で悩んでいる参加者がいたので、自分の考えを伝えました。
観点は抽象度が高くなればなるほど全体の数が少なくなりますが、知識、経験の無い人には指摘を出しにくくなると思います。よって、達人には抽象度が高いものを、初心者には抽象度が低いものをお願いするのが良いと思っています。
# IBMの細川さんから以下のアドバイスを頂きました。ありがとうございます！
観点の粒度で新人／ベテランの配分を決めるよりも「経験なくてもできる／ないとできない」っていう分け方で配分を決めるという方法もありなんじゃないかな？
１）誤字の検出／列挙
２）当該機能の変更容易性に関する懸念箇所の列挙
細かい観点を見るクセを新人につけると、大局的に全体を把握する能力がつかないのではないかと感じます。全体観を見たり、周辺視が出来なかったり。。。という人ばかりになってしまうと、効率はいいですけど、チーム全体の検出精度は落ちるかもしれませんね。
その後、観点の例として、以下の４つを挙げました。抽象度は高めの観点です。
①利用時の品質 ISO/IEC9126
②外部および内部品質（ソフトウェア品質特性）ISO/IEC9126
→分かりやすいのは「ぶっちゃけ品質特性」になります。
③要求仕様書レビュー項目の例
④過去不具合分析からの観点
実はワークの内容について、IBMの細川さんに相談していたのですが、そのときに細川さんが考えるレビューの原則を教えていただきました。それがスゴイ良かったので皆さんに紹介しました！！
レビューの原則１）レビューは誰かを幸せにするために実施される
レビューを実施する際には、必ず「誰を幸せにするか？」を決めなくてはいけません。 ステークホルダーを定義するというのが大原則です。
レビューの原則2）レビュー計画書を書きましょう
レビュー計画書とは、テスト計画書と同様に上記のような「狙い」「レビュー大方針」等を記載し、レビュー結果のばらつきを抑えるために記述される「べき」なんですが、こういうことを考えず、対象成果物を「非現実的な労力をかけて」１ページ目からレビューすることが多いです。
レビューの原則3）レビューは自由度が高い品質保証活動
レビューポイント特定は負荷軽減（＝効率向上）や重点箇所の特定（＝効果向上）も包含して、もっと広い範囲でレビュー価値を高めるために必要と考えます。
レビューの原則4）レビューは欠陥を検出して終わりではない
プロが行うレビューとしては、レビューを通じて検出した欠陥は、検出したりバグをつぶして終わりではありません。
レビューを通じて得た欠陥は、必ず将来再発する！という観点から、企業内・業界内で資産化・保存・共有しなくてはなりません。
やはりというべきか、原則1のレビューは誰かを幸せにするために・・・というのが参加者の皆さんの心に響いたようです。いつか細川さんの講義仙台で聞きたいですね（笑
レビューの原則を心に留めた上で、仕様書の背景を読み取っていきます。
今度は背景が書かれた紙を渡して、このFreeCelというツールが生まれた背景を読み取っていきます。
前回と同じく、やっぱりえーーーみたいな顔をしている人が多かったです。
何か同じようなことが会社であったのでしょうか？（笑
ここでなんと！最後の高専生の参加者が登場。なんとこのとき20時50分！！
普通だったら残り10分ってとこなんだけど、この勉強会は遅れることを見透かされていたようです（笑 それにしても来てくれるって本当にありがたいです。m(_ _)m
まず背景を読み取り、今回のステークホルダーを抜き出しました。
仕様書だけのときは開発者または利用者目線が多かったですが色々でてましたね。
ステークホルダーが出きったところで、目的、観点を設定していきます。
そして、その観点を隣の人に渡してレビューしてもらいます。
ただ自分用に書いていたため字が読み取れないなど、ちょっとした落とし穴もありました。
その後、この演習で面白かったことと、自分の現場にどう繋げていくかをグループディスカッションしました。ほんとにワイワイ盛り上がって嬉しいですよね。
最後はレビューのちょいコツを紹介しました。
ちょいコツはTEF道の皆さんの協力でした。
ここでもやっぱり人気はイタコメソッドですね。これはそのうちブログで書こうと思います。
イタコメソッド：完全にその人の立場になり、あたかもその人が乗り移ったようにレビューする方法になります（by TEF道）
やっぱり最後はこれで〆でしょ。
「レビューというのは レビューする前に 全て すでに決定されている」By JoJo
終わってみれば2時間40分。
平日に頭フル回転で皆さんグッタリだと思いますが、濃かった！楽しかった！と言ってもらえ嬉しい限りです。
今回も楽天さんの会場をそのまま借りてビアバッシュ。
無駄な機能を作らないとかいう話とかいつものように盛り上がりました！！
参加者の皆さんどうもありがとうございました！！
# 今回参加してくれた方が書いてくれたブログです。
Togetter（nnasakiさんまとめ）
nnasakiさん
http://nnasaki.hatenablog.com/entry/2013/04/09/233000
mokkyさん
http://mokky14.hatenablog.com/entry/2013/04/10/224235