■今回の有識者ジョイント「レビューワークショップ」開催によせて
(7)事前レビューのススメ
レビューは成果物案が出来上がってから実施するモノ、、、と思っている方が多いと思いますが、作業開始時に「作業の進め方や作業に求められるコト、注意すべき事項など」をすり合わせる事前レビューを行うこともできますよね。
これは、「レビューは対象を選ばない」という特徴を活かしたものです。
腕の良い作業者は大丈夫かもしれませんが、普通～発展途上にある作業者は、作業に求められるコトを把握しそこなっていたり、インプット情報を的確に把握していない、作業の進め方そのものに問題がある場合が多いのです。
そんな状態の作業者が事前の摺り合わせもなく自分の思う通りに作業を進めるとどうなるか・・・・・・・当然レビューで大量の指摘事項が発生しやすくなります。
誰だって一生懸命やった仕事に対してレビューで指摘されるのは気持ちの良いことではありません。
時には「そういう大事なことは最初から言っておいてくれれば」的な指摘が出されたりもします。
”後出しじゃんけん”は心理的に受け付けられないのが人間のサガなので、そういう事態はできるだけ避けたいですよね。
そしてレビューア側も、忙しい時間を割いて確認してみると、沢山指摘事項が出る・・・時間がどんどん食いつぶされていくわけです。
そうなると指摘事項を伝達する際に語気が強くなりがちです。
売り言葉に買い言葉・・・イヤな状態になりやすいですよね。
このように、事前のすりあわせがない作業によって「関係者みな不幸」の図になりやすい状態が生まれます。
レビューでいつも指摘事項が多い・・・そんな状態であれば、事前レビューから入るのも一案です。
(6)レビュー（やテスト）でやっていること
このことはJaSST'15東北でもお話ししました。
レビューやテストでやっていることは「対象に存在する欠陥指摘」や「問題がないことの確認」という意味もありますが、それよりもむしろ「対象成果物の内容を通じて開発（や保守）しているシステムがどのようなものなのかを理解すること、そして顧客を含む関係者でその認識を共有するコト」だと思います。
それを実現するには、対象成果物に表現されている内容だけを捉えるのでは不足になります。
どのような人が、どのような局面で、どのような使い方をすることが想定されるのか。
その際に、システムはどのように動作することになるのか。
どんな結果が出るのか。その振る舞いは利用者のやりたいことを適切に支援するのか。
これらはシステムの存在目的や意図に合っているのか。
間違って操作してしまった際にも、許容できる範囲の被害でとどめることができるのか。。。などなど、レビュー対象に書かれていないことも頭に描きながら確認し、（システムに対する）理解を深めていく。
レビュー（やテスト）で対象成果物に対していくら欠陥（や故障）を見つけても、そして記述内容（や実装、振る舞い）に問題がないことを確認できたとしても、対象となるシステムのことを理解できていなければ、プロジェクトはそのあと（いろいろな意味で）よくない状況になっていくと思います。
なお、レビュー、テストだけでこれらを行うのだ！他の活動では一切やらなくてもよいのだ！ということを意図しているわけではありません。
プロジェクト進行中のあらゆる過程で、システムを理解し、関係者で認識を共有していくことが必要になります。
しかし、レビュー（やテスト）は（担当者がそれぞれの役割で個別に活動することに比べ）、多くの関係者が集合して情報を共有し、認識を合わせる局面が多い活動ですので、これらの目的を達成するために有効活用していきたいものですね。
(5)レビュー対象だけ見てレビューしていませんか？
「レビューで有効な指摘ができない」という方たちに”レビューの仕方”を確認すると、高い確率でレビュー対象だけを見てレビューを行っています。そしておそらく作成者もレビューアにレビュー対象だけを提示し、「お願いします！」って依頼しているのでしょうね。
この状況でレビューアが行いそうな行動（できること）は以下の通りです。
・レビュー対象に書かれている文字、文章、図表の”おかしい”、”わからない”ところがあれば指摘する
あたり前ですがこの状況でレビューを行うと、レビュー対象に書かれていることの中で、読んで理解できるか、論理的におかしくないか、関連する箇所は整合しているか、などを確認し、おかしなところや不明なところを指摘しようとするわけです。
さて、この状況では何が不足し、どのような確認や指摘ができないのでしょうか。
最も欠けているものは、今回の成果物作成作業に活用した情報源、です。
例えば、要求仕様書なら製品企画書やプロジェクトに求められる要件・制約事項、顧客要求事項が把握できるソース（議事録、ヒアリング記録、現状分析結果など）などがそれにあたります。
修正依頼への対応におけるソースコードなら、修正前コードや修正依頼（議事録など）が該当します。
これらがないと
・「書かれていることそのものが適切なのか」
・「書かなければならないのに書かれていないものはないか」
・「書く必要のないことが書かれていないか」
・（修正依頼への対応なら）「依頼された内容を満足するものか」
の確認が難しくなります。
よく考えてみるとあたり前なことなのですが、意外と実践されていないことも多いのです。
新しい手法やツールに目が奪われることも多い昨今ですが、レビューを改善したいならまずは自分の足下（基本）を見直してみることが必要な場合もある、というお話でした。
(4)これまでのレビュー実践評価でわかった共通的なレビューの問題点
10数年にわたりさまざなま組織のレビュー実践状況を一緒に評価してきましたが、「レビューの効果が実感できない」という組織の多くが共通的に抱える問題点があります。
それは「レビュー対象の事前配付がない」こと、その結果「集合レビュー前に個別レビューが実施されていない」こと、です。
さらに見方を変えると「開始基準がない／存在しても有効に機能していない」と捉えることも可能です。
これらは総じて「アドホックレビュー」にならざるを得ない状況を作り出しています。
□レビュー対象はレビュー実施前に突然やってくる。
□レビュー対象がレビューを実施するにふさわしい状態になっている／いないにかかわらず突然レビューを実施してしまう。
□その結果、多くの場合、レビューする価値の低い対象を（アドホックに（思いつきで））レビューしている。
レビューを実施するには工数（実施者×時間分）が必要です。
別途工数をかける意義を高めるには、レビューアに見てもらう価値のある内容であることが求められます。
例えば、経験豊富な（単価の高い）レビューアに、構成もグダグダ、誤字・脱字・衍字（えんじ＝余計な文字）だらけで、何を言いたいのかわからない対象を見てもらうのはすごく”もったいない”ですよね。
レビューの費用対効果を高める、レビューの効果を実感するためには、「（レビューするに）ふさわしい対象だけをレビューする」ことが重要です。
このことを実現させるためには何が必要でしょうか？
例えば以下のようなことが考えられますよね。
□作業者のスキルに不安があるなら、作業前に「どのような成果物を、どうやって構築するのか」をすり合わせる。
□レビュー対象に対して、作業者のセルフチェックを徹底する。
→「レビューで指摘されたら直せばいい／指摘されなければ何もしない」的な甘えを排除する
□レビューを実施する前にレビュー対象をざっと把握し、レビューするに値する状態かを確認する。（開始基準の徹底）
→簡単に間違いやおかしなところが複数件見つかるような状態なら作業者に返却し、セルフチェック後の再提出を依頼する
□作業量が多い場合は、段階的に内容をレビューし、フィードバックを提供しながら進める。
ここで間違ってほしくないのは、この共通的な問題点”だけ”を解消できればレビューの問題がすべて解決されるわけではないことです。
あくまでもレビューのパフォーマンスをよくするための「第一歩」として解消すべきと思われるコトにすぎませんのでご注意ください。
（例：思いつきでレビューしている、への一つの対策として「レビュー観点設定」が必要、など）
(3)レビューの目標はどこにおくべきか？
「(2)レビューでは指摘する能力だけ鍛えればよいわけではない」でも伝えましたが、レビュー対象の不備などを指摘するだけで「よい成果物」になるわけではありません。
それなのによくあるレビューのメトリクスは「規模あたりの指摘件数」や「指摘密度」がメインとなるケースも多く、他にはなかったりします。
メトリクスや目標というのは「それを重視せよ！／数値をよくしろ！」という強いメッセージになるので、指摘件数や密度などを前に出すとみな”指摘しようとがんばる”・・・・それ以上にはならない可能性が高くなります。
そして、一生懸命指摘しようとすればするほど、人間関係がギクシャクしやすくもなるのです。困ったものですね。
では、どこに、どのように目標を置くといいのでしょうか？
こういうときはまず”レビューによってどのような状態が実現できればよいか”を表現してみるのがいいでしょう。
以下はその例です。
＜レビューで実現したいこと＞
(1)レビューにより成果物案に存在する不備、不明点、問題事項（以上、指摘事項）が明確になる。
(2)レビューでの指摘事項を適切に処置（修正・回答⇒納得など）し終えることができる。
(3)レビュー終了後に、どうすればレビューでよりよい結果が得られるかを明確にし、関係者で共有・活用する。
(4)関係者により以上の内容が気持ちよく協力的に進められる。
この結果から「必要なメトリクス」を導びいてみましょう。
＜レビューで必要なメトリクス＞
(1)「規模あたりの指摘件数」「指摘密度」「指摘内容の価値指数や分布」「レビュー未検出欠陥の事後発生数」など
(2)「質問回答率」「修正率」など
(3)「レビュー終了直後のふりかえり実施有無」「Try導出件数」「改善(Try)実践率」「Try効果獲得実感数」など
(4)「レビューニコニコ実践指数（ｗ）」など
※注意：あくまでも例なので、すべて取得しなければならないものではありません。
このように取得するメトリクスをいきなり導くよりも、実現したいこと＝どういう状態になりたいのか？を全体で明確にしてからメトリクスを導く方が、不必要なメトリクスやなぜ取得しているのかよくわからないメトリクスを取得せずに済むことにもつながります。
メトリクス、目標、がわかりやすい重点事項だけを強調してしまい、それが一人歩きするとマイナスの効果をもたらす可能性もある、ということにも注意したいものです。
(2)レビューでは指摘する能力だけ鍛えればよいわけではない
今回の「レビュー実践編」では、レビューで適切な指摘ができるようになるために、観点設定を学ぶワークを実施します。
http://www.software-quasol.com/review-workshop/
観点のないところに指摘はない、、、ちょっと言い過ぎなようにも聞こえますが、実際にはそうだと考えています。
「観点なんて設定していないけどいつも指摘できている」という方の頭の中にはその指摘をするための観点が備わっているはずです。
そう、レビュー観点設定とは、頭の中にある”指摘するための切り口”を外部表現する行為にあたります。
観点設定も終わり、レビューを実践してめでたく成果物の一部に指摘事項を見つけたとします。
その内容は的確で非の打ちどころがないものであったとしても、相手（成果物作成者）への伝え方が悪いと適切に修正してもらえない可能性が高まります。
例：「ここが〇〇の意味でおかしい。何でこんな間違いをするわけ！」
このように少なくとも感情的に指摘するのはダメっぽいですよね。
このことに加えて人間の特性上、面白くない、イライラしている、怒っている局面でいい仕事はしにくいと思います。
よって、「ダメな指摘伝達」→「作成者が面白くない気持ちになる」→「ダメな成果物修正」の連鎖を生む可能性を高めます。
ではどのように伝えれば、作成者が気持ちよく、自分のことだと思って、適切に修正してもらえるでしょうか？
あなたならどのように指摘してもらうと「ああそうか！なるほど！ちゃんと直さないと！」と思って前向きに行動しますか？
ということで、レビューで指摘する能力だけを鍛えても不足です。
人間の特性をよく理解して、レビューを実践しましょう！
(1)”レビュー”を限定的に捉えていませんか？
先日私が実施した「レビューワークショップ」を受講してくれた開発者さんのところにフォローアップでお邪魔した際に気づいたのですが、開発者の方が「レビュー」を非常に限定的に捉えていらっしゃいました。
どのように限定的かというと、自分たちやお客様と「○○レビュー」と命名した行為だけを「レビュー」として認識しているのです。
自分たちが設計した結果をお客さんと一緒に確認する「設計書レビュー」、仲間が作成したコードを一緒に確認する「コードレビュー」などがそれにあたります。
特徴としては、「自分たちが作り上げたもの」を対象とした確認行為をレビューと呼んでいるようです。
このように限定的に認識していると、結果的にその活動にのみ「レビューのノウハウ」を活用しようと考えてしまいます。
そう、もしWebや研修、書籍で役に立ちそうな知識やノウハウを獲得できたとしても、それを活用する先は自らが認識している「レビュー」にしか向けられないのです。
たとえば、顧客から当初の要件や仕様が提示された時点を考えてみましょう。
そのまま受け取って作業を開始すると、作業途中で「あれ？これはどういう意味だろう？こういうことかな？それともああいうことかな？」という記述が見つかることがあります。
さらに「この言葉はどんな意味？」とか「この仕様だと、別の機能仕様とかみ合わないんだけどどっちを信用すればいいのかな？」などなどいろいろと不備が見つかり、そのたびに作業を止めて問い合わせ、回答を待つ・・・ということに。
こんな状態がよく起きるときこそ”レビュー”です。
成果物が組織をまたがる際に”受け入れても問題ないのか””この内容で作業ができるのか”などを確認し、不備があればあらかじめ（早いうちに）内容を手直しするのが効果的でしょう。
余計な手直しや待ち時間を減らし、お互いに気持ちよく作業を行えるように”レビュー”のノウハウを活用できます。
先ほどの開発者さんがいるチームでは、お客さまから入手するドキュメントを事前確認はしているようでしたが表面的なチェックのみ・・・レビューのノウハウを活用していなかったようでした。
結果的にその開発者の上司の方が「そこにこそレビューを入れたら効果的じゃない？」と提案して、開発者さんが「あ！なるほど！気づきませんでした！ぜひやってみます！」となりました。
めでたしめでたし。（笑）
批判を恐れずにあえて広めの解釈をして表現すると、レビューは「ある対象の内容を理解しようとする行為」と言い換えることができると思います。
その過程で、おかしなところやよくわからないところがあれば、それらを知らせて調整し、理解したうえで適切な内容に整え、関係者で共有する。
そのことにより、関係者全員が対象に関して”同じ認識”となるようにしていくことが重要になります。
対象に対する共通理解を促進することで、このようにみんなが不幸になる可能性をできるだけ低くすれば、質のよいソフトウェアを、余計なコストや期間をかけずに、関係者間も気持ちよく作り上げることができる。
それを実現する手段の一つとして「レビュー」のノウハウを活用することができます。
裏を返せば、関係者間の共通理解が得られないとうまくいかない状況があれば、レビューのノウハウを活用すればよいわけですね。
(0)開催の経緯とその概要
7/22（with栗田さん）と8/8（with小池さん）に初開催する「レビューワークショップ（東京・大崎）」のご紹介を兼ねて、開催に至った経緯などをメモしておきますね。
まずは簡単にお二人とのつながりについて。
栗田さんとつながったのは「ソフトウェア・シンポジウム（SS）」がきっかけです。
私がSSに初めて参画したのは2009年に札幌で開催された時でテスト（・・・レビューだったかも）WGでした。
そのWGには秋山さん、にしさんなどがいらっしゃいましたが、その際にSSの事務局をやっていたのが栗田さんです。
それ以降、私もSSの運営委員などをやらせていただく中で薄く関わってきた感じですが、昨年和歌山で開催されたSS2015の「レビューWG」で共同リーダとなり、一気に関わりが深くなりました。
2015年末にはSEA Forum @ 北海道 in December 2015「レビュー」と「仕様記述」でもご一緒させていただき、技術に対する真摯な姿勢を感じておりました。終了後の打ち上げで「いつか二人で何かしたいよね」と意気投合し、今回ついにそれが実現することになりました。
小池さんと最初にお会いして話をしたのはたしか「SPI Japan（ソフトウェアプロセス改善カンファレンス）2011（浜松）」だったと思います。
もちろんそれ以前から存じ上げていた方ですが、クロージングパネルで司会の和田さん（ソニー（当時））にいろいろな意味で絡み、会場を沸かしていたのが小池さんでした。「面白い方だなぁ」と思いつつ会場で初めて名刺交換をし、ちょっとだけお話をしたのが最初です。
現在のつながりは数か月に一度開催される「ソフトウェア品質(SQiP）委員会」ですが、北海道（札幌）出身の方なので、里帰りに乗じて勉強会にゲストにお呼びしてなど、地域コミュニティ間の交流を含めて懇意にさせていただいています。
「今度一緒に何かやりたいね・・・共通しているのは”レビュー”だよね」と昨年話していたのが今回実現します。
レビューには限りませんが、有識者の方たちが持っている貴重なノウハウを業界内に直接共有する機会は実はそう多くありません。
特にレビューは、私も十数年間、数をこなし苦しみながら実践してきた中で気づいたことや試してきたことなどが多い、ある種”思い入れ”のある領域です。しかもレビューは、その運営方法についての研究を除けば未開の領域が多い分野でもあり、外部研修や書籍なども著しく少ない状態です。
そこで、まずは自らが発信することから始める、その後一人の偏った考えやノウハウを提供するのではなく、いくつかの立場や製品領域から導き出された考え方やノウハウを共有して、共通点（重要なポイント）や新しい気づきを獲得できる機会を増やしていこうと思っていました。
8年ほど前からレビュー関連のセミナーやワークショップ、改善支援を開始し、それらの実績情報を活用して事例発表などを行っています。
そして今回お二人にお声掛けして実現するのが今回のジョイント形式のワークショップです。
小池さんには、書籍「データ指向のソフトウェア品質マネジメント」の中に書かれている「レビュープロセスの制御と評価」「レビュー欠陥指摘数にかかわるメカニズムの把握」「レビューの品質向上効果のモデル化」「レビュー実績データを用いた品質予測」などを素材に、事例を含めた解説とワークを実施頂きます。
また栗田さんには、その豊富な実務経験とワーク設計やチームビルディング実践で培われたノウハウをベースに、レビュー実施時のファシリテーション・モデレーションについて教えていただきます。
そして私は、(1)なんとなくやるレビューから脱却するために「観点設定に基づくレビュー実践」の威力を体感いただく、(2)レビューを成功させるために必要なレビュー計画立案のあり方、そしてレビューの評価・改善の実践方法をワークを通して一緒に考えていきます。
業界の有識者である小池さん、栗田さんと一緒に実施できるワークショップを楽しみにしています。