JaSST Review2022

レ ビ ュ ー で は 何 を 確 認 す る と い い の か な ？

さまざまなレビューの意図を整理して確認事項を明らかにしてみよう！
記述内容に反応するレビューから狙い撃つレビューへ
Software Quasol＠HBA
安達 賢二

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved1

安達 賢二（あだち けんじ） adachi@hba.co.jp

生株式会社HBA 経営管理本部 Executive Expert

http://www.softwarequasol.com/
株式会社レヴィ 共創ファシリテーター
https://levii.co.jp/

勤住

育

【経歴】

2012年社内イントレプレナー第一号事業者として品質向上支援事業を立ち上げ。
自律運営チーム構築･変革メソッドSaPIDをベースに、関係者と一緒に価値あるコトを創る共創ファシリテーター／自律組織･人財育成コーチ として活動中。
【社外活動】
NPO法人 ソフトウェアテスト技術振興協会（ASTER）理事
JSTQB（テスト技術者資格認定）技術委員
JaSST Review（ソフトウェアレビューシンポジウム）実行委員
兼レビュー体系化を目指す会（仮）メンバー
JaSST-nano お世話係軍団
JaSST（ソフトウェアテストシンポジウム）北海道
2006-2009実行委員長 2010-2018実行委員 2019～2021サポーター
テスト設計コンテスト本部審査委員(2015-2017)
SEA（ソフトウェア技術者協会）幹事・北海道支部メンバー
SS（ソフトウェア・シンポジウム）プログラム委員
第33-38期SQiP研究会ソフトウェアレビュー分科会アドバイザー
SQuBOK_Ver3プロセス改善研究Grリーダ（with プロセス改善の黒歴史研究）
元TEF（Test Engineer’s Forum）北海道テスト勉強会（TEF道）お世話係
TOCfE北海道幽霊メンバー など
2

Copyright © Kenji Adachi@Software Quasol , All Rights Reservedこのワークの出所
ソフトウェア品質管理（SQiP）研究会「ソフトウェアレビュー」のアドバイ
ザー等を通じて、数十年にわたるさまざまなレビュー研究結果や蓄積されたノウハウが実務であまり活用されていない実態を危惧しています。
その普及やレビュー体系化を目指す会（仮）メンバーとして「レビュー体系化」に取り組み、JaSST'22東京でのレビューワークを皮切りに「ソフトウェアレ
ビュー勉強会」を運営しています。
https://softwarereview-studygroup.connpass.com/
今回のワークはこの活動の一環で実施します。
ぜひ一緒に議論し、考え、手を動かしてみましょう！
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

3当ワークのねらい• レビューの意図（目的と観点）の明確化
方法（の一つ）を把握する。
• このアプローチの価値を評価し、現状のレビ
ューにどのように適用するのがよいかを考える。
4
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved想定する受講者と期待効果• 想定する受講者– いつもレビューで見逃しが多いと実感している方– レビューを実施しているが、効果が実感できない方– レビューの結果が有識者の出席有無に大きく依存するチームのメンバー• 期待効果– より有効な欠陥を検出する能力の向上• 業務知識に頼らず欠陥や不備が指摘できる領域の拡大– レビューの成果を有識者に頼りすぎる状態の緩和– 要求仕様、設計書作成時の考慮事項や注意事項の導出力向上– テスト設計との連携によるQAアプローチの足掛かりに

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved5このワークで行うこと
レビューの意図の明確化を
制限時間の中で部分体験する

レビューの意図の明確化を完遂するまで体験する

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

6ワークの対象領域
レビューで確実に確認・指摘をするためのノウハウ
レビュー目的～観点導出によるレビュー会で指摘をしやすくする場づくり
例：ファシリテーション

業務知識によらない
レビューノウハウ
業務知識による
レビューノウハウ
例1：物流系システム
例2：特定のITシステム

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved7

ワーク実践者と見学者に分かれて実施
ワーク見学者

ワーク実践者
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

8実施概要・タイムスケジュール（予定）
時 間 数 ( 予定)

実施事項

1

13:00～13:20

イントロダクション＆チームビルディング

2

13:20～15:00

レビューワーク(1)狙い撃ちレビュー準備～実施
目的洗い出し→観点導出→個別レビュー実施(2)レビュー結果評価・考察

結果評価→結果共有

事前解説
ワーク
結果解説

3

15:00～15:15※途中、それぞれの解説や休憩が入ります。
休憩

4

15:15～16:15

ワーク結果解説・ワークふりかえり・Q&A
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

9チームビルディング：8分間• ブレイクアウトルームにて以下の対応を行ってください。

①メンバーの自己紹介[1人1分×人数][ハンドルネーム] [普段のお仕事の概要と役割][普段実施しているレビューの目的]②ワーク時の役割を決める[リーダ][タイムキーパー][情報共有役][盛り上げ役]
リーダー

タイム
キーパー

情報共有役

盛り上げ役

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

10観点に基づくレビューのイメージ

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

11典型的なレビューの状態重視されること：誰が確認するか？
モチベダウン

レビュー会議で初めてレビュー対象を配付ジャイアン独演会･あら捜し･
横道逸脱･人格否定･いざこざ

効果

見逃した欠陥があとになって爆発

書かれていることに反応し、気が付いたことを指摘
有識者がいないと軽微で、表面的な指摘ばかり

レビューの効果が実感できない

多忙につきレビューを省略

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

12レビュー観点設定～狙い撃ちレビューのイメージ重視すること：何を確認するか？

あらかじめ対象の内容や構造、
記述レベル等をざっと把握する

レビュー目的や制約条件に応じて必要な観点を洗い出し、どのように確認するかを事前に整理する

それぞれのレビューア
が観点に沿って確認
観点A

観点B

観点C

レビュー結果を評価し、目的達成できているか
等をふりかえる（以降のレビューに繋げる）

観点をそれぞれのレビューアに割当て
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

13

ワーク1：レビューの目的って？

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

14「レビューの効果」はどこから来るか？
• 現状レビューの問題点収集でいつも出てくる大事な命題「レビューの効果を実感できない」
表面的な指摘ばかりで有効な指摘ができていない

あとでレビューでの見逃しに起因する問題が発生する

Reviewの効果

費やした労力に見合う結果が得られていないと感じる

効果＝目指す結果の獲得／課題解決／目的達成
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

15

Work1-1

普段実施しているレビューの目的は？

3分間• みなさんが普段実施しているレビューの目的は何でしょうか？
• 「目的1つを1枚の付箋に」書いてください。（複数枚可）• 時間に余裕があれば他の方が何を書いているのかを見て、その目的が普段のレビューに当てはまらないか等を確認してみましょう。
レビュー対象が成果物要件を満足しているか
確認する

欠陥検出

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

レビュー
トレーニング

16

Work1-2「レビュー目的」どうしの関係性は？

7分間• 書き出した「レビューの目的」の内容が、同じもの、類似のものがあれば近くに寄せ、必要なら要約してみてください。
• 付箋を「マネジメント系の要素」は青系色、「テクニカル系の要テクニカル系要素
マネジメント系要素
素」は黄系色に変えてください。
• それぞれの「レビュー目的」の間にどのような関係性があるかを考察し、関係性が見つかった要素どうしを線で結び、どのような関係なのかを付記してください。
欠陥検出
おかしなと
ころを直す

成果物の
出来栄えを
判定する

欠陥・不備の検出・修正
欠陥検出

おかしなと
ころを直す

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

を活用して

成果物の
出来栄えを
判定する
17

レビュー目的の洗い出し（例1）
次フェーズ進行が可能かを判定する

レビュー対象の内容を関係者で理解する

対象成果物の欠陥や不備の検出

内規に従い、実施実績を記録に残す

レビュー
トレーニング

成果物の品質状況を把握する

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

18

レビュー目的の洗い出し（例2）
レビュー対象が企画内
容（コンセプトやウリ等）を反映しているのか？

対象製品・サービスが利用者の問題・課題を解決できるものになっているか？

対象製品・サービスによる利用者の問題・
課題解決は効率的か？

レビュー対象が成果物として備える要件を満足しているか？

この先プロジェクトや運用・保守に大きな影響を与えるリスクや問題はないか？

対象製品・サービスの利用時リスクが考慮され、回避されているか？

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

19レビュー目的の関係性（例）
レビュー対象の内容を関係者で理解する

レビュー対象が企
画内容（コンセプ
トやウリ等）を反映しているのか？

次フェーズ進
行が可能か
を判定する
成果物の品
質状況を把
握する
対象成果物
の欠陥や不
備の検出

対象製品・サービスが利用者の問題・
課題を解決できるものになっているか？

上位目的

テクニカル系要素：～により内規に従い、実施実績を記録に残す
この先プロジェクト
や運用・保守に大きな影響を与えるリス
クや問題はないか？

対象製品・サービスによる利用者の問題・課題解決は効率的か？

マネジメント系要素

レビュー対象が成果物として備える要件を満足しているか？

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

レビュー
トレーニング

下位目的
対象製品・サービスの利用時リスクが考慮され、回避
されているか？
20

レビュー観点はどのようなものか？
人によって“観点”の捉え方には幅がある

レビューの意図や目的を段階的に詳細化したもの。
レビュー目的を達成するための、レビューアによるレビュー対象の見方、レビューで検出したい欠陥を見つけるためにレビューアが集中して着目する対象成果物の側面。さらに何を、どのように確認するのかを表したもの。
レビューケース【目的】
使用性を確保する実現手段
一貫した構造や用語使用で構築する

確認事項
ドキュメント内整合（一貫性・整合性）

確認方法
類似画面を洗い出し
目視で比較確認【指摘事項】
画面1は「登録」ボタンなのに、画面2は「書き込み」ボタンに
なっている

実現手段
利用者にわかりや
すい手続きの導線
を提供する

確認事項
手続きの容易性・簡潔性

確認方法
被験者が迷わずス
ムーズにタスクを完了できるかを確認【指摘事項】〇〇と□□でつまず
いて先に進めず

実現手段
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

21

レビュー観点は階層構造
抽象度の高いレビュー観点（抽象的）人によってはその意味や内訳が異なる可能性がある
粒度が大きい【ハイレベルレビューケース：HRC】【ミディアムレベルレビューケース：MRC】

抽象度が低いレビュー観点（具体的）
指摘
事項

指摘
事項

指摘
事項

指摘
事項

誰がチェックしても同じ結果が導ける可能性が高い
粒度が小さい【ローレベルレビューケース：LRC】

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

22

人によって適切に実践できる観点粒度が異なる
レビューアの状態で観点粒度を調整する

利害関係者

対象システムにおける主な活動

実利用者 システムに必要情報を入力して、ほしい結果
を得る

Aさん

関心事

必要なレビュー観点・
対象

誤入力情報がそのまま処理されないか？

入力ミス検知機能があるか？（入力画面）

OK! この場合だと□必須項目記入漏れの検出□入力不可文字の検出□日付、時間範囲外の検出ができればよいね！

レビュー観点の具体化□必須項目記入漏れの検出□入力不可文字の検出□日付、時間範囲外の検出

OK!
Aさん

Bさん
ん～この場合だと□必須項目記入漏れの検出は思いつくけど他には何ができればよいのかな？？？

Bさん

Bさん
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

23

観点に基づく要求仕様書レビュー

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

24レビュー対象物

P3.交通費精算一覧• 交通費精算システム要求仕様（案）
https://www.softwarequasol.com/jasst-review2022workshop/
P1.背景説明

P4.交通費精算明細P2.システム概要説明
P5.交通費承認一覧

P6.交通費精算書出力※レビュー対象外
ただし、内容は理解する必要有
25

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

システム開発フェーズと現在

システム
企画書

要求定義
要求
仕様書案

いまココ
↓

受入テスト
運用テスト

Review

方式設計

システムテスト
統合テスト
機能テスト

詳細設計

実装・UT
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved26

ワーク2：レビュー観点の導出

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

27

レビュー目的達成のためのアプローチ概要設計（例）

目的(Goal1)→目的達成に必要な事項(Strategy)→必要事項の内訳(subGoal)

目的※GSN（Goal Structure
Notation）による表現

Why

何が揃えば目的が達成できるのか？

Strategy1
システムリスクを明らかにする

Goal11

Goal12類似システムの過去トラから特定システムの特徴から発生事
象を推論

Goal【レビュー目的】
レビュー対象に大きな影響があるリスクがあれば可能な限り特定

What
具体的に何がわかればよいのか？
Goal13？？

How toContext
レビュー対象＝要求仕様書Strategy2
レビュー対象物のリ
スクを明らかにする

Goal21

Goal22

レビュー対象物に求められることへの合致度合い関係Phaseへの影響

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

Strategy3？？

Goal23？？
28

レビュー観点導出アプローチの割り当て（例）Goal【レビュー目的】
大きな影響があるリスクを可能な限り特定

Strategy1
システムリスク

Goal11

Goal12類似システムの過去トラから特定システムの特徴から発生事象を推論（A5）プロダクトリスク
アプローチ 3)

Context
レビュー対象＝要求仕様書Strategy2
レビュー対象物のリスク

Goal21
レビュー対象物に求められることへの合致度合い

どうやって観点を具体化するか？
（A3）対象成果物に？？？？？？
求められることアプローチ
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

Goal22
関係Phaseへの影響？？？？？？

29

レビュー目的達成のためのアプローチ概要設計と観点導出アプローチの割り当て[目的・観点構造化結果例]
Goal【レビュー目的】
大きな影響があるリスクを可能な限り特定プロジェクト・システム運用時発生事象

Goal32

Goal32

Goal33

要求実
装未達

進捗･納
期遅延

コスト
オーバー

レビュー対象物＝要求仕様書作り込む

レビュー対象物
欠陥･不備が持つリスク

Goal12

Goal13

Goal21

類似システムの過去トラから特定システムの特徴
から発生事象を推論

利用者背景と利用から発生
事象を推論

成果物に求められることへの合致度合い（A5）-3プロダ
クトリスクアプローチ（A5）-2プロダ
クトリスクアプ
ローチ（A6）利用シナリ
オアプローチ（A3）対象成果物に求められることアプローチ

Goal11

プロジェクト・
運用時リスクContext

Strategy2

Strategy1 実利用時
システムリスク 発生事象

Strategy3

Goal22

ワーク
対象外

検討時Keyword例（アプローチは省略）
要件変更
要件実装
見積
優先度
可能性
可能性
精度
設定

Goal23

非機能要
求未達
障害発生
時対策

Goal24

開発関係
Phaseへの影響

作成プロセスによる欠陥作り込
みリスク

対象物の典
型的な欠陥

（A2）利害関係者の関心事アプローチ（A1）作成者
コンテキストア
プローチ（A4）対象成
果物によくある
欠陥アプローチ

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

Goal3430

レビュー観点導出アプローチ
レビューベースからレビュー観点を、または、ある粒度のレビュー
観点からより粒度の小さいレビュー観点を導出するアプローチ(A1)作成者コンテキストアプローチ(A2)利害関係者の関心事アプローチ(A3)対象成果物に求められることアプローチ(A4)対象成果物によくある欠陥アプローチ(A5)プロダクトリスクアプローチ(A6)利用シナリオアプローチ

欠陥検出に繋げる
ワザの集合体※他にもたくさんあるはず
あとで探してみてください※テストの文脈では「テスト設計技法」に類似する

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved31

(A1)作成者コンテキストアプローチ
作成者のコンテキスト＝対象成果物がどのような状況の中で、どのように作成されたのかから、レビュー観点を導出する。
(1)作成者はシステム開発経験3年目。これまでは設計のサブ担当者であったが、今回初めてメイン設計担
当として割り当てられた。この分野のシステムを手掛けるのは初めて。
(2)レビュー対象成果物の作成に着手したのは2日前とのこと。
(3)作成者は、過去に参加したプロジェクトで構築したシステムの障害対応に2か月前から借り出され、継続して残業、休出が突出していた。障害対応は現在も継続中。
(4) レビュー対象成果物（MS-Wordで作成）の最終書き込み日時は今日のAM3:35。
また、当初書き込み日時は、5年前の3/28 AM2:58。
着目した兆候例

例
当wordファイルの当初書き
込み日時は、5年前の3/28
AM2:58。

兆候からの仮説
過去のプロジェクト成果物を流用した可能性大想定される欠陥レビュー観点□部分流用した結果、今回 今回の内容には不必要な/の要件に合わない状態になっ 不適切な旧成果物の残骸はているないか?
□旧成果物の残骸がそのまま残されている32

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

(A2)利害関係者の関心事アプローチ
利害関係者を明確化→関心事→観点・対象を明確化

利害関係者
例．システム設
計担当者

対象システムにおける主な活動

システムへの関心事（期待･疑問･懸念等）

必要なレビュー観点・対象

当システムの基本設計を システム設計に必要な情報が漏 システムに求められる要件が理由や目的、制担当
れなく入手できるか？
約事項と共に明示されているか？

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

33

(A3)対象成果物に求められることアプローチ
確認方法を明確化すること＝レビュー観点導出とする

ソフトウェア要求仕様の目次例
観点

確認方法

ソフトウェア要求仕様が持つべき特性

観点
確認方法
1.はじめに正当性（Correct）
例.目次に該当する事項がドキュメント目的システムに対するすべての要求が含まれ、以外の要求を含まな存在しているかを目視で確
いこと
記述範囲
認する。
用語定義
無曖昧性（Unambiguous）
全ての要求の意味が一意に識別されること
参考文献
完全性（Complete）
全体構成
次をすべて含んでいること＝(1)すべての必要な要求、(2)すべ2.製品の背景と概要ての入力データと状況に関する応答の定義、(3)用語および図
製品の背景
表の説明
製品機能
一貫性（Consistent）
ユーザー特性
要求間で矛盾がないこと
制約
順位付け（Ranked for importance and/or stability）
要求が重要性や安定性に関して順位付けられていること
要求項目の仮定と依存関係
例.解決したい利用者の課
3.具体的な要求事項
検証容易性（Verifiable）
題に対して必要な機能がすべての要求に対して有限のコストで評価可能な手続きが存在
外部インタフェース
漏れなく明記されているかし、検証できること機能を目視で存在を確認する
修正容易性（Modifiable）
性能要求
要求の変更に対して、容易かつ完全で一貫性を保って修正で論理データベース要求
きるような構造を持つこと
設計の制約
追跡性（Traceable）
例：要求の背景や理由→要求＋制約条件が漏れなく非機能要求等ソフトウェア特性
要求の根拠が明確で、開発工程全体で参照できること追跡できるかを企画書と要求仕様で目視確認する
要求仕様の段落構成
引用：要求工学：第3回要求仕様
https://www.bcm.co.jp/site/2004/2004Dec/04-youkyuu-kougaku-12/04-youkyuu-kougaku-12.htm
34
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

(A4)対象成果物によくある欠陥アプローチ
確認方法を明確化すること＝レビュー観点導出とする
観点

確認方法

□ユースケースや業務フロー、機能などの開始、終了条件の不備や条件によるアンマッチ□信頼性、効率性、保守性などの非機能要求の不備や具体化不足 (非現実的な網羅的設定の場合もある)□システムのSCOPEや他システムとの境界定義の不備□要求間、機能間連携部分の例外事項などが一方の備考欄に記述され、他方で認識されない□実現優先度未設定

例：要求事項単位に優先度が付与されているか＋判断根
拠が把握できるかを目視確認する
引用/参考：「間違いだらけの設計レビュー改訂版」 森崎 修司著
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

35

(A5)プロダクトリスクアプローチ
1)利用者の立場、こんな使い方をすれば〇〇が発生するかも！を検討してみる。
2)システムの機能から「こんなことが起きるかも」を想定してみる。
参考：安全リスクには健康リスク・経済リスク・環境リスクがある
3)類似製品の事故や障害、問題発生事例を確認してみる。（例：Web検索で探す）
どのような事象？
「湯沸かしポット」の例．
給湯時にやけどやケガをする

技法選択肢
は３つ

発生要因と影響

関係する機能

給湯速度が速すぎる→熱湯が 給湯機能
飛び散る→手をやけど→持っていた器を落として破損or足に落として怪我

レビュー観点と対象
お湯の飛び跳ねを考慮した
給湯速度設定をしているか
対象：給湯コントロール(A5)-1)(A5)-2)(A5)-3)

利用者ベース

機能ベース

事故・障害ベース

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved36

(A6)利用シナリオアプローチ※利用シナリオ導出＝レビュー観点導出とする
利用者の典型的な課題を解決する利用シナリオ(通常+例外)を作成する。
それをベースに対象成果物をトレース（レビューを実施）することで、不明点や指摘事項があれば記録する。
＜解決したい課題例＞
業務で使用した交通費(往復分)を精算
往路：さっぽろ→(地下鉄：340円)→新さっぽろ(徒歩移動)新札幌→(バス：210円)→森林公園（復路はこのルートを逆に辿る（同一金額）ため省略）■利用シナリオ（通常）
途中でエラーも発生せず、すんなり順調に入力・申請でき、承認後に口座に入金されるシナリオ。
■利用シナリオ（例外）
途中でさまざまなエラーに遭遇しながら入力・申請するが、結果的に否認されるシナリオ。
さらに否認後に再申請して承認され、最終的に口座に入金されるシナリオを付与するとよりよい。
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved37

Work2

レビュー観点導出アプローチ選択&実践 20分間
ブレイクアウト• 観点導出アプローチのうち各自選りすぐり1つを選んでください。
※チーム内で重複がないように調整してください。

• 選んだ技法に基づき観点を導出してください。
アプローチ選択

5分間
aさん

bさん

dさん

cさん

（A5）
観点導出

（A1）
観点導出

（A3）
観点導出

（A4）
観点導出

(A5)
観点群

(A1)
観点群

(A3)
観点群

(A4)
観点群

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

アプローチ実践15分間
38

ワーク3：観点に基づくレビュー実行

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

39

Work3

15分間

個別レビュー実施• 各自で導出した観点に基づくレビューを実施し、結果を記録してく
ださい。
(A5)
観点群

レビュー
対象

(A1)
観点群

レビュー
実施
aさん

レビュー
結果

bさん

レビュー
対象

レビュー
対象

レビュー
実施

レビュー
実施

レビュー
結果

レビュー
結果

(A3)
観点群

レビュー
対象

(A4)
観点群

レビュー
実施
cさん

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

レビュー
結果

dさん

40

レビュー結果記録様式
観点導出アプローチ番号：

N
o.

指摘箇所

A

担当者：

指摘グレード
重･中･軽

指摘内容

観点

1
2
3
4
5

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved41

ワーク4：観点に基づくレビューの評価と考察

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

42

Work4aさん
レビュー結果観点に基づくレビューの評価と考察(1)観点設定レビュー結果評価
評価指標
効果･影響度大bさん
レビュー結果cさん
レビュー結果dさん
レビュー結果【参考】評価指標
テンプレート

主対象：

安全性未考慮
キャパシティ要件欠落

検 効果･影響度中
出 主対象：
性能要件未考慮
効 機能不足→使いにくい
果
効果･影響度小
主対象：

誤字･脱字･衍字
部分的画面遷移なし
画面項目不足

指摘件数計

計25分間
18分間
ブレイクアウト

観点設定レビュー結果
aさん
（A5）

②

③

①

bさん
（A1）

ｃさん
（A3）

⑥

⑨

⑤

⑧

④
4

dさん
（A4）

⑫

⑪

⑩

⑦
2

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved3※記述内容は事例

3
43

Work4

観点に基づくレビューの考察(2)観点に基づくレビューの考察

計25分間
7分間
ブレイクアウト

実践難易度が一番高いのはAXだね！

観点導出→実施→
効果とつながるな
ら逆もできるということでは？
欠陥指摘が
◇◇側に集
まってる！

考察結果
事実
＋結論or推論

気づいたこと／感じたこと疑問･不安など

この評価を「狙い」にすると〇〇になるかも！

いつもの方法との違い／適用へのアイデア

その他

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

実務での活用方法

44

ワーク結果解説

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

45

事前レビュー結果
アドホックレビュー結果の典型的な特徴（例）成果物の前半部分での指摘数が多く、後半部分ほど指摘数が少なくなる。
→理由：先頭から読んで指摘することで、時間切れとなり／
または集中力低下により後ろ側に未確認領域が存在する。

記述内容に対する表面的な指摘が多く、記述の要否や踏み込んだ内容に対する指摘が少ない。
複数レビューアが同じ確認をし、同じ指摘が提示される。
→探索領域・観点→指摘の重複

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved46当アプローチによる実験結果
2012～2020年に実施した全ワークショップ（11社30チーム）実績から算出

レビュー観点設計による典型的な指摘変化の例△=アドホックレビュー指摘●=観点設計レビュー指摘
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

47

レビュー結果の評価• 基本：目指す結果(目的)がどの程度獲得(達成)できたのかを評価する。
• 目指す結果＝レビュー対象に存在する「大きな影響があるリスク」を特定する。

【評価方法例】
その指摘事項を見逃した場合、以降発生する可能性がある負の事象の被害度合いで評価する。

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved48当手法でも効果が獲得できなかった事例
指摘件数： △14 → ●11△改善前（Before）
レビュー
計●改善後（After）
結果
効果大
ハード変更必要
計測器故障

アプローチの活用方法を誤っていた！

効果中
沸点記述
検
整合性
出
デフォルト
効
エラー後復帰×果
効果小誤記
仕向け表記なし
ロック押下仕様
長押し仕様
計

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

5

0
↓
40

3

69
↓
18

1

9
↓
7
78→65
49

このアプローチと効果（解説）Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

50

本日のワークコンテンツ
Work1

レビュー目的の構造化（解説で代替）

Work2

レビュー観点導出手法割り付けと観点導出

Work3

個別レビュー実施

Work4

レビュー結果評価・考察

Work5

レビューふりかえり（このあと）
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

51

レビューアプローチの全体像（イメージ）
目的構造と観点導出過程がある
ため、その内容確認とノウハウの蓄積・活用が容易になる

Goal1【レビュー目的】
大きな影響があるリスクを可能な限り特定Context
レビュー対象＝要求仕様書Strategy1

Strategy2

システムリスク

成果物のリスク

Goal12

Goal11

Goal13

Goal21

Goal22

Goal23類似システムの過去トラから特定システムの特徴
から発生事象を推論

利用者背景と利用から発生
事象を推論

成果物に求められることへの合致度合い（A5）-3プロ
ダクトリスクアプ
ローチ（A5）-2プロ
ダクトリスクアプ
ローチ（A3）対象成
果物に求められることアプローチ（A2）利害関係者の関心事アプローチ

（A1）作成者コンテキスト
アプローチ

(A5)
観点群

(A5)
観点群

（A5）-1プロダク
トリスクアプローチ（A6）利用シナ
リオアプローチ

(A3)
観点群

(A2)
観点群

(A1)
観点群

レビュー
実施

レビュー
実施

レビュー
実施

レビュー
実施

レビュー
実施

レビュー
実施

レビュー
結果

レビュー
結果

レビュー
結果

レビュー
結果

レビュー
結果

レビュー
結果

集合レビュー会(A5･A6)
観点群

レビュー
結果

レビュー
評価＆ふりかえり
レビュー
評価結果

ふりかえり
結果

関係Phase
への影響

作成者状況
による欠陥
作り込み

目的構造と観点導出過程があるため、結果をベースにした検討過程の良し悪し判断が容易
で改善が進みやすい

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

レビュー目的を基軸とした目的構造化表記の採用[拡張]
レビュー観点導出技法
としての部品化と目的構造化表記への割り付けによるレビュー観点導出[技法バリエーション充実]
レビュー観点に基づくレビュー実施集合レビュー会での建設的議論による結果共有
レビュー結果評価[拡張]とふりかえりによるレビュー改52
善検討よくあるレビューアプローチ
Goal1【レビュー目的】
大きな影響があるリスクを可能な限り特定Context
レビュー対象＝要求仕様書Strategy1

Strategy2

システムリスク

成果物のリスク

Goal12

Goal11

Goal13

Goal21

Goal23

Goal22類似システムの過去トラから特定システムの特徴
から発生事象を推論

利用者背景と利用から発生
事象を推論

成果物に求められることへの合致度合い（A5）-3プロ
ダクトリスクアプ
ローチ（A5）-2プロ
ダクトリスクアプ
ローチ（A3）対象成
果物に求められることアプローチ（A2）利害関係者の関心事アプローチ

（A1）作成者コンテキスト
アプローチ

(A5)
観点群

(A5)
観点群

（A5）-1プロダク
トリスクアプローチ（A6）利用シナ
リオアプローチ

(A3)
観点群

(A2)
観点群

(A1)
観点群

レビュー
実施

レビュー
実施

レビュー
実施

レビュー
実施

レビュー
実施

レビュー
実施

レビュー
結果

レビュー
結果

レビュー
結果

レビュー
結果

レビュー
結果

レビュー
結果

集合レビュー会(A5･A6)
観点群

レビュー
結果

関係Phase
への影響

作成者状況
による欠陥
作り込み

ここをすべてレビューアの頭の中だけで暗黙的に実施する／あるいは形式的・固定的なチェックリ
スト等で済ませている（思考せずに形式化）

結果的にレビューの成果が有識者の参加有無に依存する状態にレビュー
評価＆ふりかえり
レビュー
評価結果

ふりかえり
結果

結果評価もふりかえりも行わない→レビューはいつも同じやり方に

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved53テストプロセスを参考にしたレビュープロセスの分解
個々の
レビュー

レビュー
の開始

Work1

レビュー

懸念事項
の共有と
分析

修正と
報告

Work3

Work2

レビュー

レビュー

レビュー

レビュー

分析

設計

実装

実行

計画

Work4・5

レビュー

完了
レビューのモニタリングとコントロール

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved54

なぜレビュー観点が必要なのか？
No.

内容

1

”観点”があれば雑多な情報群の中から集中して該当を直接探し当てられやすい

2”観点”がない場合、書かれていることだけに反応した指摘に終始してしまう

3

有効な指摘事項など優先度の高い欠陥・不備を見つけやすい

4”観点”がない場合、メンバー間での重複確認や誰も見ていない抜け・漏れが発生しやすい

5”観点”があれば、メンバー間で確認する観点の分担が可能になる

6

有効指摘のノウハウを再利用しやすくなる（有識者依存度を低減できる）

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved55

なぜレビュー観点が必要なのか？(1)”観点”があれば雑多な情報群の中から集中して該当を直接探し当てられやすい□隊列が乱れているのは？
□顔が白い人は？
□人ではないのは？
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved56

なぜレビュー観点が必要なのか？(2)”観点”がない場合、書かれていることだけに反応した指摘に終始してしまう
対象を読みながらぼんやり行うレビュー

書かれていることで気づいたことを指摘

レビューの効果が実感できない

有識者がいないと軽微で、表面的な指摘ばかりになりがち

見逃した欠陥があとになって爆発観点に基づくレビュー

観点1:性能要件
観点2:使いやすさ
観点3:利用者課題解決

性能要件
がないけど
大丈夫？

レビューに期待されていること（テストでは実現が困難なこと）
書かれるべきなのに書かれていない／書いてあるけど必要ないことを見つける
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved57

なぜレビュー観点が必要なのか？(3)

有効な指摘事項など優先度の高い欠陥・不備を見つけやすい
2012～2020年に実施した全ワークショップ（11社30チーム）実績から算出

レビュー観点設計による典型的な指摘変化の例△=アドホックレビュー指摘●=観点設計レビュー指摘
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved58

なぜレビュー観点が必要なのか？(4)”観点”がない場合、メンバー間での重複確認や誰も見ていない抜け・漏れが発生しやすい

ぼんやりレビューすると、みな上から順に読んで書かれていることに反応して指摘する→同じ指摘が重複する（重複チェック）

三重チェック以降は効果がない(誰かが見るから自分はいいや 等)

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved59

なぜレビュー観点が必要なのか？(5)”観点”があれば、メンバー間で確認する観点の分担が可能になる

レビューア
Qさん

機能

確認観点リスト
機能要求確認レビューア
Sさん

非機能要求確認
別モデル化確認
外部内部整合性

非機能

レビューア
Uさん

観点と探索領域の無駄な重複・レビューア 抜け漏れが最小限になる
Pさん

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved60

なぜレビュー観点が必要なのか？(6)

有効指摘のノウハウを再利用しやすくなる（有識者依存度を低減できる）
ABC Project
XYZ Project
取捨
選択

取捨
選択

RFV Project
YHN Project
取捨
選択

取捨
選択

有効なレビュー観点をまとめて再利用することでレビューの効果を高める
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved61ただし・・・
単発・形式的な取り組みでは効果は獲得できない• 観点設定→観点に基づくレビューを、思考を伴わず形式的に行っても効果は期待できない。
• 重要なのはレビュー対象や観点設計への理解に基づくに実践。
そこには状況に応じた「適切な思考」と「モデル化」が求められる。
• その実践力は、継続して取り組むことで身につくもの。
当初は時間がかかる割に効果は？？？～失敗も多い。
[実践→ふりかえり]の継続～時短＆効果向上

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved62

ワーク5：観点に基づくレビューのふりかえり

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved63

Work5

観点に基づくレビューのふりかえり
いつものレ
ビューと〇〇が違うと感じたブレイクアウト

結果はよいけど理解できてない
ところがある△△部分をこう
やって適用すればよいかも！

欠陥指摘が◇◇側に集まってる！

考察結果
事実＋結論or推論

20分間

気づいたこと／感じたこと疑問･不安など

いつもの方法との違い／適用へのアイデア

その他

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

実務での活用
方法

64

まとめ

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

65本日のまとめ• レビューの重要な問題点「効果が実感できない」となっている一つの要因
は、レビュー目的が関係者でしっかり共有できていない、ではないか？
• そこでGSNやレビュー観点導出アプローチを活用してレビュー目的を段階的に詳細化し、最終的に指摘事項となる過程の要素（レビュー観点）
群を見える化することで、有識者の頭の使い方を再現してみた。
このように整理することで、既に存在するさまざまなレビューのテクニックや実践方法をマッピングして整理することも可能になる。

• 当初はレビュー観点群を導出するのに苦労するかもしれない。しかし、導出したレビュー観点群をレビュー実践結果に基づいてブラッシュアップし続けることで、欲しい結果を効率よく獲得するレビューが徐々にできるようになっていく。
• 以上のことを意図した「レビュー体系化案」を部分体験し、共有した。
Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

66レビュー観点を活用して「誰が確認したか？」から「何を確認したか？」へシフトしよう！
有識者依存

観点共有・活用

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

67ソフトウェアレビュー勉強会

https://softwarereview-studygroup.connpass.com/

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

68お疲れさまでした

Copyright © Kenji Adachi@Software Quasol, All Rights Reserved

69