レビューってなんなの〜レビューに対する5つの誤解〜 / 5 misconceptions about software review

Slide 1

Slide 1 text

レビューってなんなの？〜レビューに対する 5つの誤解〜ブロッコリー (@nihonbuson)

Slide 2

Slide 2 text

自己紹介 ● 風間裕也（ブロッコリー） ● @nihonbuson ● 社外活動 ○ JaSST Review実行委員長 ○ WACATE実行委員 ● 執筆活動 ○ 『テストコードの注入から始めるレガシーコードのリファクタリング』 ○ 『Agile Testing Condensed』翻訳 ○ 『Testing in DevOps』翻訳

Slide 3

Slide 3 text

執筆or翻訳した書籍 Agile Testing Condensed Japanese Edition テストコードの注入から始めるレガシーコードのリファクタリング A Practical Guide to Testing in DevOps Japanese Edition 執筆翻訳翻訳

Slide 4

Slide 4 text

Slide 5

Slide 5 text

ソフトウェアレビューに対する誤解 1. レビューはテストではない 2. レビューは、お硬いミーティングである 3. 知識をたくさん持っている人だけがレビュアーになる 4. QAはインプットを得るために設計のレビューに参加する 5. レビューの唯一の目的は、説明した内容で実装したら動かないような欠陥を指摘することである

Slide 6

Slide 6 text

誤解1 レビューはテストではない

Slide 7

Slide 7 text

レビューはテストの1つ by JSTQB テスト対象のコンポーネントやシステムを実行することは、動的テストと呼ぶ。テスト対象のコンポーネントやシステムを実行しない場合は、静的テストと呼ぶ。このため、テストは要件、ユーザーストーリー、ソースコードなどの作業成果物をレビューする活動も含む。出典：http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

Slide 8

Slide 8 text

誤解2 レビューは、お硬いミーティングである

Slide 9

Slide 9 text

よくあるレビューのイメージ ● 会議室に集まる ● 声の大きい人が威張り散らす ● ドキュメント作成者が萎縮する ● 他の人は発言しないのでつまらなくなるいらすとや1、2

Slide 10

Slide 10 text

開催形式 ● インスペクション　　　…最も公式的なレビュー ● チームレビュー　　　　…チームで実施 ● パスアラウンド　　　　…成果物を配布、回覧 ● ラウンドロビンレビュー…全員が順番に司会者と　　　　　　　　　　　　レビュアーになる ● ピアデスクチェック　　…熟練者のレビュアーと実施 ● ウォークスルー　　　　…参加者が質問やコメント ● ピアレビュー　　　　　…作成者以外と気軽に行う ● アドホックレビュー　　…近くの同僚に声をかける ● ペアプログラミング　　…他者視点を取り入れる参考：SQuBOK策定部会(2014) 『ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)』オーム社

Slide 11

Slide 11 text

日々の相談もレビューの1つ ● 「ちょっとこの部分が分からないんだけど」 ● 「この部分を見てくれない？」 ● 「この部分、チームでモブワークしよう！」いらすとや

Slide 12

Slide 12 text

誤解3 知識をたくさん持っている人だけがレビュアーになる

Slide 13

Slide 13 text

知識がないと発言できない？ドキュメント作成者 Aの方針で実装します開発者知識が無いから何も発言できないけどこの方針で実装すれば良いのね、了解

Slide 14

Slide 14 text

レビューは指摘だけでなく質問も！ドキュメント作成者 Aの方針で実装しますレビュアーこれって他の実装方針は無いの？

Slide 15

Slide 15 text

作成者が自分で気付くかもしれないドキュメント作成者 Bの実装方針やCの実装方針があって…あれ？もしかしたらCの実装方針の方が良いかも？

Slide 16

Slide 16 text

他の開発者にとって学びになるかもしれないドキュメント作成者 Bの実装方針やCの実装方針もあったが、リスクXがあるから、Aの実装方針で実装します開発者なるほど！だからAの実装方針にしたのね！

Slide 17

Slide 17 text

誤解4 QAはインプットを得るために設計のレビューに参加する

Slide 18

Slide 18 text

QAは聞いているだけ？ドキュメント作成者この部分は○○なので、△△の考え方を用いて ◇◇の方針で実装して… QA 詳細はよくわからないけど、この情報をテストの時に活かそう

Slide 19

Slide 19 text

QAの見え方をどんどんフィードバックしようドキュメント作成者 QA この部分は、別の画面★★が影響しそうだけど関係ないんですかね？この部分は○○なので、△△の考え方を用いて ◇◇の方針で実装して…

Slide 20

Slide 20 text

QAもどんどんフィードバックした例 https://speakerdeck.com/nihonbuson/example-mapping https://speakerdeck.com/nihonbuson/tddbc-2020-online-lt https://speakerdeck.com/nihonbuson/testing-is-the-creative-activity

Slide 21

Slide 21 text

誤解5 レビューの唯一の目的は、説明した内容で実装したら動かないような欠陥を指摘することである

Slide 22

Slide 22 text

顧客が本当に必要だったもの http://ntd.way-nifty.com/blog/2005/05/post_80fd.html

Slide 23

Slide 23 text

レビューで話すこと ● もしも設計書作成者がこんな認識を持っていたら…

Slide 24

Slide 24 text

レビューで話すこと（欠陥の指摘）レビュアーこれだと、実装しても何も動かないのでは？

Slide 25

Slide 25 text

レビューで話すこと（PLとの認識の差異）レビュアー木に板がぶら下がってる状態にしたかったのでは？

Slide 26

Slide 26 text

レビューで話すこと（顧客との認識の差異）レビュアー顧客は、3枚の板がぶら下がっている状態を欲しがっていたのでは？

Slide 27

Slide 27 text

レビューで話すこと（本当に必要だったもの）レビュアー本来は、揺れて遊ぶものが欲しかったのでは？

Slide 28

Slide 28 text

レビューで話すこと（本当に必要だったもの）レビュアー本来は、揺れて遊ぶものが欲しかったのでは？レビューではこの質問を目指したい！

Slide 29

Slide 29 text

レビューで話すこと（こんな質問でもOK）レビュアーそもそも今回はどんな物が欲しかったんでしたっけ？

Slide 30

Slide 30 text

まとめ

Slide 31

Slide 31 text

まとめ ● レビューもテストの1つ ● 日々の相談もレビューである ○ モブワークもレビューの1種 ● 知識を持っていなくても質問することが価値になる ● QAもインプットする（ただ聞く）だけでなく、一緒にレビューに参加してフィードバックしよう ● レビューは欠陥の指摘だけでなく、「本当に必要だったもの」に立ち返るためでもある

Slide 32

Slide 32 text

宣伝

Slide 33

Slide 33 text

レビューで話すこと（本当に必要だったもの）「顧客が本当に必要だったもの」を見つけ出すのは難しい…。

Slide 34

Slide 34 text

「本当に必要だったもの」を見つけるきっかけ（宣伝） ● JaSST Review'21は10月22日開催！ ● 今回のテーマは「価値を実現するためにレビューができること」 ● 事例投稿も募集中！（8月30日締め切り） ○ 「日々の会話でこんな工夫をしたら、本当に必要だったものを見つけられたよ！」報告 ○ その他、レビューに関することなら何でも！