Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
レビューってなんなの〜レビューに対する5つの誤解〜 / 5 misconceptions ab...
Search
nihonbuson
PRO
August 17, 2021
Technology
3
1.5k
レビューってなんなの〜レビューに対する5つの誤解〜 / 5 misconceptions about software review
nihonbuson
PRO
August 17, 2021
Tweet
Share
More Decks by nihonbuson
See All by nihonbuson
ホリスティックテスティングの右側も大切にする 〜2つの[はか]る〜 / Holistic Testing: Right Side Matters
nihonbuson
PRO
0
1.5k
テストを実施する前に考えるべきテストの話 / Thinking About Testing Before You Test
nihonbuson
PRO
18
3.2k
テストコードにはテストの意図を込めよう(2025年版) #retechtalk / Put the intent of the test 2025
nihonbuson
PRO
17
3.2k
ソフトウェアテスト 最初の一歩 〜テスト設計技法をワークで体験しながら学ぶ〜 #JaSSTTokyo / SoftwareTestingFirstStep
nihonbuson
PRO
6
880
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB #JaSST #JaSSTTokyo / Readable test code
nihonbuson
PRO
14
15k
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
PRO
2
9.3k
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
nihonbuson
PRO
3
3.7k
品質管理の歴史学 / Quality Management History
nihonbuson
PRO
41
15k
境界値分析
nihonbuson
PRO
4
520
Other Decks in Technology
See All in Technology
GopherCon Tour 概略
logica0419
2
190
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
0
140
BirdCLEF+2025 Noir 5位解法紹介
myso
0
190
小学4年生夏休みの自由研究「ぼくと Copilot エージェント」
taichinakamura
0
120
後進育成のしくじり〜任せるスキルとリーダーシップの両立〜
matsu0228
7
2.4k
PLaMoの事後学習を支える技術 / PFN LLMセミナー
pfn
PRO
9
3.8k
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
3
330
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
900
AI ReadyなData PlatformとしてのAutonomous Databaseアップデート
oracle4engineer
PRO
0
180
動画データのポテンシャルを引き出す! Databricks と AI活用への奮闘記(現在進行形)
databricksjapan
0
140
OCI Network Firewall 概要
oracle4engineer
PRO
1
7.8k
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
310
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
2.8k
Balancing Empowerment & Direction
lara
4
680
Context Engineering - Making Every Token Count
addyosmani
5
180
How GitHub (no longer) Works
holman
315
140k
Practical Orchestrator
shlominoach
190
11k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.7k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
9
580
Designing for Performance
lara
610
69k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Transcript
レビューって なんなの? 〜レビューに対する 5つの誤解〜 ブロッコリー (@nihonbuson)
自己紹介 • 風間裕也(ブロッコリー) • @nihonbuson • 社外活動 ◦ JaSST Review実行委員長
◦ WACATE実行委員 • 執筆活動 ◦ 『テストコードの注入から始める レガシーコードのリファクタリング』 ◦ 『Agile Testing Condensed』翻訳 ◦ 『Testing in DevOps』翻訳
執筆or翻訳した書籍 Agile Testing Condensed Japanese Edition テストコードの注入から始める レガシーコードのリファクタリング A Practical
Guide to Testing in DevOps Japanese Edition 執筆 翻訳 翻訳
自己紹介 • 風間裕也(ブロッコリー) • @nihonbuson • 社外活動 ◦ JaSST Review実行委員長
◦ WACATE実行委員 • 執筆活動 ◦ 『テストコードの注入から始める レガシーコードのリファクタリング』 ◦ 『Agile Testing Condensed』翻訳 ◦ 『Testing in DevOps』翻訳
ソフトウェアレビューに対する誤解 1. レビューはテストではない 2. レビューは、お硬いミーティングである 3. 知識をたくさん持っている人だけがレビュアーになる 4. QAはインプットを得るために 設計のレビューに参加する
5. レビューの唯一の目的は、説明した内容で実装したら 動かないような欠陥を指摘することである
誤解1 レビューは テストではない
レビューはテストの1つ by JSTQB テスト対象のコンポーネントやシステムを実行することは、 動的テストと呼ぶ。 テスト対象のコンポーネントやシステムを実行しない場合は、 静的テストと呼ぶ。 このため、テストは要件、ユーザーストーリー、ソースコード などの作業成果物をレビューする活動も含む。 出典:http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
誤解2 レビューは、お硬い ミーティングである
よくあるレビューのイメージ • 会議室に集まる • 声の大きい人が 威張り散らす • ドキュメント作成者が 萎縮する •
他の人は発言しないので つまらなくなる いらすとや1、2
開催形式 • インスペクション …最も公式的なレビュー • チームレビュー …チームで実施 • パスアラウンド …成果物を配布、回覧 • ラウンドロビンレビュー…全員が順番に司会者と レビュアーになる
• ピアデスクチェック …熟練者のレビュアーと実施 • ウォークスルー …参加者が質問やコメント • ピアレビュー …作成者以外と気軽に行う • アドホックレビュー …近くの同僚に声をかける • ペアプログラミング …他者視点を取り入れる 参考:SQuBOK策定部会(2014) 『ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)』オーム社
日々の相談もレビューの1つ • 「ちょっとこの部分が分からないんだけど」 • 「この部分を見てくれない?」 • 「この部分、チームでモブワークしよう!」 いらすとや
誤解3 知識をたくさん 持っている人だけが レビュアーになる
知識がないと発言できない? ドキュメント 作成者 Aの方針で実装します 開発者 知識が無いから 何も発言できないけど この方針で実装すれば 良いのね、了解
レビューは指摘だけでなく質問も! ドキュメント 作成者 Aの方針で実装します レビュアー これって他の実装方針は無いの?
作成者が自分で気付くかもしれない ドキュメント 作成者 Bの実装方針やCの実装方針があって…あれ? もしかしたらCの実装方針の方が良いかも?
他の開発者にとって学びになるかもしれない ドキュメント 作成者 Bの実装方針やCの実装方針もあったが、 リスクXがあるから、Aの実装方針で実装します 開発者 なるほど!だからAの 実装方針にしたのね!
誤解4 QAはインプットを 得るために 設計のレビューに 参加する
QAは聞いているだけ? ドキュメント 作成者 この部分は◦◦なので、△△の考え方を用いて ◇◇の方針で実装して… QA 詳細はよくわからないけど、 この情報をテストの時に 活かそう
QAの見え方をどんどんフィードバックしよう ドキュメント 作成者 QA この部分は、別の画面★★が影響しそうだけど 関係ないんですかね? この部分は◦◦なので、△△の考え方を用いて ◇◇の方針で実装して…
QAもどんどんフィードバックした例 https://speakerdeck.com/nihonbuson/example-mapping https://speakerdeck.com/nihonbuson/tddbc-2020-online-lt https://speakerdeck.com/nihonbuson/testing-is-the-creative-activity
誤解5 レビューの唯一の目的は、 説明した内容で実装したら 動かないような欠陥を 指摘することである
顧客が本当に必要だったもの http://ntd.way-nifty.com/blog/2005/05/post_80fd.html
レビューで話すこと • もしも設計書作成者が こんな認識を持っていたら…
レビューで話すこと(欠陥の指摘) レビュアー これだと、実装しても 何も動かないのでは?
レビューで話すこと(PLとの認識の差異) レビュアー 木に板がぶら下がってる 状態にしたかったのでは?
レビューで話すこと(顧客との認識の差異) レビュアー 顧客は、3枚の板が ぶら下がっている状態を 欲しがっていたのでは?
レビューで話すこと(本当に必要だったもの) レビュアー 本来は、揺れて遊ぶものが 欲しかったのでは?
レビューで話すこと(本当に必要だったもの) レビュアー 本来は、揺れて遊ぶものが 欲しかったのでは? レビューでは この質問を 目指したい!
レビューで話すこと(こんな質問でもOK) レビュアー そもそも今回はどんな物が 欲しかったんでしたっけ?
まとめ
まとめ • レビューもテストの1つ • 日々の相談もレビューである ◦ モブワークもレビューの1種 • 知識を持っていなくても質問することが価値になる •
QAもインプットする(ただ聞く)だけでなく、 一緒にレビューに参加してフィードバックしよう • レビューは欠陥の指摘だけでなく、 「本当に必要だったもの」に立ち返るためでもある
宣伝
レビューで話すこと(本当に必要だったもの) 「顧客が本当に必要だったもの」を 見つけ出すのは難しい…。
「本当に必要だったもの」を見つけるきっかけ(宣伝) • JaSST Review'21は10月22日開催! • 今回のテーマは 「価値を実現するためにレビューができること」 • 事例投稿も募集中!(8月30日締め切り) ◦
「日々の会話でこんな工夫をしたら、 本当に必要だったものを見つけられたよ!」報告 ◦ その他、レビューに関することなら何でも!
「本当に必要だったもの」を見つけるきっかけ(宣伝) • JaSST Review'21は10月22日開催! • 今回のテーマは 「価値を実現するためにレビューができること」 • 事例投稿も募集中!(8月30日締め切り) ◦
「日々の会話でこんな工夫をしたら、 本当に必要だったものを見つけられたよ!」報告 ◦ その他、レビューに関することなら何でも! レビューの分野は 新規性しかない! 論理的な結果よりも、 実際に行った事例重視!
おしまい