今月の勉強会は、『レビューのススメ』ということで、皆さん大好き？なレビューについて実施しました。集まった参加者は14名。新しい参加者もいて本当に嬉しい限りです。
場所は楽天さん会議室をお借りしました。本当に助かります！！ありがとうございました。
また今回の題材はTEF道のJaSST'12北海道のワークショップのものです。それだけになかなか手ごわい勉強会になったと思います！！
おっと、4月にレビューのススメのおかわり（再）を実施する予定なので、
もし参加される予定の方は以下は読まずに参加することをお勧めします。
まず最初にレビューしてますか？と聞いてみました。
大体半分くらいの方の手があがりました。まあまあというところでしょうか？
まずはレビューって何ということを復習してみます。
*****************************************************************************
レビューは、ソフトウェア成果物(コードも含む)をテストする一つの手段であり、
動的テスト実行前に大きな効果がある。
ライフサイクルの初期のレビューで摘出した欠陥(例えば要件の欠陥)の修正は、
コードを実行して検出した欠陥を修正する場合にくらべ、はるかに安価である。
（中略）
レビュー、静的解析、動的テストは、欠陥の検出という同じ目的を持っている。
この3つの技法は、お互いに補い合っている。
すなわち、異なる技法は異なる欠陥を効率よく効果的に摘出する。
静的テスト技法は、動的テストと比較した場合、故障自体ではなく、
故障の原因(欠陥)を探すという違いがある。
JSTQB FLシラバスより抜粋
*****************************************************************************
レビューは広義の意味でのテストの一つであり、欠陥を検出するという目的ということですね。
さて、レビューの種類の説明です。
アドホック、パスアラウンド、ペアレビュー、ウォークスルー、チームレビュー、インスペクションなどです。
参考にしたのはSQiP研究会のレビューオリエンテーションキットを用いた、育成によるレビュー文化の形成
2011年度SQiP研究会 第三分科会 第一グループ(キットは付録)
http://www.juse.or.jp/software/394/attachs/SQiP3-1.pdf
この研究会の成果は本当に面白いのでぜひ一度目を通してみてください。
そしていきなりのレビューをやってもらいました！！
会社でもありますよね？これレビューしておいて～って言われること。
お題はFreeCelというマインドマップのFreeMindからExcelへ変換をするツール。
このお題の凄いところは、要求仕様書に万遍なく散りばめられた誤字・脱字・衍字。
気になってしかたがないはずっ！！
それぞれの人を見ていましたが、悩みながら色々書きだしてました。
エクセルのバージョンが書かれていない。このメッセージが分かりにくいなどですね。
ある程度出したところで、お互いに確認してもらいました。
そして今回の山場のひとつであるリバースを行います。
指摘事項から、観点、目的まで逆に辿って頭の中でどういう風に考えていたかを導出していきます。
これがかなり難しくて、手が止まっていましたね。。。
もう少し誘導が必要でしたね。すいません。
この後グループで導出した観点、目的を共有してみます。
色々な見方があって面白そうでした。
一通りリバースしたところでレビューの目的の復習。
『レビューでは欠陥を見つけたいのです！！』
ありものに対して行い故障を見つける動的テストに比べ、レビューは欠陥をダイレクトに見つけ、そして抜けている仕様を見つけやすいです。テストの最中に、『おっと！この機能がないじゃん』っていうのはなかなかないですよね。
そしてレビューでは、修正に経済的コストがかかるものを優先的に見つけておきたいということを伝えました。
誤字・脱字・衍字はほとんどが致命的な欠陥を引き起こすことがないものの、何回も見つかった日にはレビューアをイラつかせるのには十分だと思います。
個人的には『自分で見直していないはず』という判断から、内容もレビューに値しないと判断してしまうのだと思います。
誤字・脱字・衍字と欠陥の検出の記事は森崎先生が書いていますのでこちらを参照ください。
本質的でないレビュー指摘を減らすための試行の紹介
http://blogs.itmedia.co.jp/morisaki/2012/08/itpro-5706.html
ではどうやって、経済的コストがかかるものを効率良く見つけるのでしょうか？
それは先ほどリバースしたときに出てきた観点になります。
観点の無いレビューを「ワイルドレビュー」（TEF道の造語）と言います。
観点とは何でしょうか？
*****************************************************************************
観点とは「物事を考察・判断するときの立場。見地（けんち）」。
立場や見方を考えてレビューすることが大事。人を意識すると分かりやすい。
例) エンドユーザー（立場）が使いやすいか（観点）ということを考えながらレビューする。
例)保守担当（立場）が保守しやすいか（観点）ということを考えながらレビューする。
*****************************************************************************
このときに、レビュー時に観点を明確に定義しているか聞いたのですが、会社のレビュー実施時に明確に定義している人はいませんでした。実際は暗黙の観点を自分の中に持っているのだと思います。
その後、観点の例として、以下の４つを挙げました。
①利用時の品質 ISO/IEC9126
②外部および内部品質（ソフトウェア品質特性）ISO/IEC9126
→分かりやすいのは「ぶっちゃけ品質特性」になります。
③要求仕様書レビュー項目の例
④過去不具合分析からの観点
もちろん、それぞれの製品によって重要な立場・観点は違ってきますので、気をつけてください。
医療用の機器、家電、スマホのゲームで必要な品質や観点は違いますよね？？
さてここからが本番。
今度は背景が書かれた紙を渡して、このFreeCelというツールが生まれた背景を読み取っていきます。
えーーーみたいな顔をしている人がほとんど。
そうなっちゃいますよね（笑
背景を読み取った後に、目的と立場・観点を出しました。
少し立場・観点を出しにくいグループがいたので、自分の方から少し例を挙げて紹介しました。
その後、自分たちでその立場・観点を使ってレビューをしてもらいました。
見ていると最初のワイルドレビューのときより、指摘が多く、やりやすそうでした。
感想を聞いてもワイルドレビューに比べて、指摘が出しやすいという意見がほとんどでした。
実業務でもレビューアにとっても、この観点で見て大丈夫だった！と結果に自信が持てるのではないかと思います。レビュー前に背景の確認、観点決めが重要ということに気づいてもらえると嬉しいです。
ここで面白かった立場を紹介します。
ドキュメント管理者という立場でレビューをしている参加者が居ました。
その後のレビューの結果も書類管理者からの指摘に相応しい指摘が出ていて、『人と観点を具体的にイメージすると指摘が良く出せました』という感想も貰いました。
立場を使うレビューは以下の森崎先生の記事が参考になります。
異なる立場でレビューするパースペクティブべースドリーディング
http://www.atmarkit.co.jp/im/carc/serial/review/03/04.html
さらにこれを推し進めると、その人が乗り移ったようにレビューするイタコメソッド（by TEF道）という方法になります。イャーーーッ！はい、降りました！
最後に明日から使えるレビューのちょいコツを紹介して終わりました。
ちょいコツに協力してくれたTEF道の皆さん本当にどうもありがとうございました。
「レビューというのは レビューする前に 全て すでに決定されている」By JoJo
そして、時間が終わっても自分たちの納得いくまで話し合っているグループがあって、超感動しました。
めっちゃ嬉しい！！
終わってから楽天さんの会場をそのまま借りてビアバッシュ。
レビューの話やらテストの話やら、本当に楽しい時間でした。
今月もどうもありがとうございました！！
＃最初にも書きましたが、来月再度レビューのススメを実施します。
＃ワークの方法なども再度見直しますので、是非参加してみてください。