2023/12/1 JaSST Review2023“レビュー体系化”の経過報告

レビュー体系とレビューアーキテクチャ
JaSST Review2023実行委員会

Copyright © JaSST Review Executive Committee , All Rights Reserved

1Web告知https://www.jasst.jp/symposium/jasstreview23/timetable.html• JaSST Review実行委員会では、「レビューの体系化」について普段から議論しています。
具体的には、テストの体系をレビューに置き換えて考えたり、実際にレビューしてそれぞれの観点の違いを体感したり、出てきた観点の言葉を直して分類してみたりといったことを進めています。
• 昨年のJaSST Reviewで実施したワークではその成果の一端をみなさんにお知らせしましたが、今回はその内容を含めた「レビュー体系の全体像とその構成要素」として、特にレビューアーキテクチャ設計、実際に実行委員でレビューした事例における観点や分類についてご紹介します。
• 現場のガチガチなレビューから開発とQAのちょっとした相談のようなレビューまで、みなさんのモヤモヤが少し晴れたり、レビューアとしての不安がちょっと減ったり、普段のレビューをより良くするヒントにできるようにお話ししたいと思います。
Copyright © JaSST Review Executive Committee , All Rights Reserved

2

ASTER: ソフトウェアテスト技術振興協会

Association of Software Test EngineeRing
ソフトウェアテストを軸にして、ソフトウェア品質向上に関する研究開発、普及振興、教育、国際連携、資格認定などの事業を行う特定非営利活動法人(NPO法人)» 2006年4月に設立» 全国で理事・会員ともにボランティアで活動» JaSSTの運営母体組織

シンポジウム

教育事業

ASTER
資格認定

ソフトウェアテストシンポジウム
教育コンテンツ・セミナー開催
JSTQB(JaSST)
各地域での自立支援
北海道、東北、(FL, AL(TM, TA))
技術コミュニティ支援
東京、新潟、北陸、東海、関西、四国、
九州、 Review、
日本発の技術発信(InSTA)
Online、nano
国際標準化活動とのリエゾン
OPENクラス、U-30クラス(ISO/IEC JTC1/SC7/WG26)
アジア諸国連携(ASTA)
シンポジウム等への技術者派遣

国際連携

テスト設計コンテスト

Copyright © ASTER , All Rights Reserved

研究
テスト開発方法論(智美塾)
テストプロセス改善
バグモデリング(バグシェルジュ)レビュー体系化
ゲームのテスト
組込みCI
機械学習システムのQA(QA4AI)
テストツール
テストスキル標準(Test.SSF)
Wモデル
善吾賞
3

よくあるレビューの風景

Copyright © JaSST Review Executive Committee , All Rights Reserved4典型的なレビューの状態
モチベダウン

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

効果

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

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

レビューの効果が実感できない多忙・前向きになれない等の理由からレビューを省略

Copyright © JaSST Review Executive Committee , All Rights Reserved

5先日障害発生したからレビューは全員でやれ！

こんなことになっていませんか？
大勢でレビューしたからもうバグはないんだよね？

やっとできあがったのでレビューをお願いします

すべてレビューしたのになんでこんな問題が発生するんだ！

忙しいのに・・・大量の赤入れが必要な成果物って・・・
こっ、これ
全部直す？

作成者

レビュー担当作成者

Copyright © JaSST Review Executive Committee , All Rights Reserved

6先日障害発生したからレビューは全員でやれ！

こんなことになっていませんか？
大勢でレビューしたからもうバグはないんだよね？

多重度を上げると漏れがな
くなるんじゃないかレビュー

やっとできあがったのでレビューをお願いします

忙しいのに・・・大量の赤入れが必要な成果物って・・・

対象がすべてできあがらな
いと実施しないレビュー

作成者

レビュー担当

こっ、これ
全部直す？

すべてレビューしたのになんでこんな問題が発生するんだ！

レビューで欠陥がないことを証明できると勘違い

作成者

Copyright © JaSST Review Executive Committee , All Rights Reserved

7

理解不足

レビューへの誤認識や不適切な行動と結果□レビューとは、レビュー会議でレビュー対象をチェックして指摘すること。
□レビューでは、対象を知るための情報源（例：仕様書やコード）に書かれていることを確認すればよい。
□レビューで十分な確認を行うには、レビューアの人数を多くすればよい。
□レビューチェックリストに記載されている項目を確認すれば終わりだ。
□レビューの成果は業務知識豊富な有識者が出席出来るかどうかで決まる。

その結果・・・□レビューでの見逃しが多く、後工程で問題が発生する。
□もうあの人の独演会レビューには参加したくない。
□レビュー時間がムダに長く、ダメ出しが多くて気が滅入る。
□業務知識が重要→レビュートレーニングなんて必要ない。
□レビューの効果が実感できない。

理解不足や誤認識は不適切な行動を生みイヤな結果を引き寄せる

Copyright © JaSST Review Executive Committee , All Rights Reserved8C

集合会議の際に初めて成果物を見ながらレビューを行う対象物だけを見てレビュー
を行う

全員類似の観点
で成果物を先頭から読んで記述
内容に反応して
指摘する

指摘の重複
が増える
書かれていないことへの指摘ができないA

有識者都合でレビュー開催待ちが増える

多忙のため大きなポイ
ントのみの指摘で終了することが増える

B

非有識者は何もできないと諦める

自ら見ようとしなくなる。（誰かが見るだろう）

C

C

C

一度に大量
(頁数)の成果
物を全員でレ
ビューする

声の大きな人や有識者だけが指摘・コメントを連発する
横道に逸れても、個人攻撃されても放置される

かける工数に対する効果が低くなりがち長時間となるため成果物の後半は集中力が落ち、薄い確認になりがち。

レビューで発生しがちな負の事象の連鎖と循環【因果関係モデル】
ソフトウェアシンポジウム2022 経験論文
「ソフトウェアレビュー研究結果の認知拡大と適用促進」 より

B
欠陥の見
逃しが増
える

あとから欠陥見逃しに起因する問題が発生するA
レビュー結果がレビューアの能力(例：有識者)に依存する

Copyright © SQiP Review Study Group , All Rights Reserved

手戻り負担増や費用対効果からレビューへのモ
チベーションが
低くなる

C
レビュー
改善が進
まない

※摘要1 aaによりbになるb※摘要2 A B C
は循環先(飛び先)を表す
9

JaSST2022東京ワークショップ参加者が感じていたレビューの問題点
レビューでの見逃しが多い(時支出来ていない
ことも？)レビュー指摘の出来が不安定
工数がかかる
レビューイ理解度(レビューアの伝え方)

人によってレビューの観点と粒度がバ
ラバラ／ほぼ機能していないレビューもある
レビュー成果物の質
発言・指摘が毎回同じ人

レビューMTGの進
め方

レビューの効果が可視化できてない

レビュアーの勘と経験に頼ったレビューになってしまっている。

途中から参加したプロダクトについて突っ込んでいいのか悪いのかわからない
必要以上に時間がかかっている
レビューイの心構え（受け身）

経験則に頼りすぎている

レビューイとレビューア間の関係性が薄くて協力関係になれなさそうなとき困る
レビュー以前に、何がわからないのか探す習慣がない
非形式なレビューをカジュアルにやってみるなど、取り組みができていないうまくいってない感を解消したいとおもえる、前向きな気持ちを育てたい
レビューを身近なものにしたい

ソフトウェアレビューシンポジウム2022東京 ワークショップ「そゆことね！よくわかるレビューテクニック～明日から使える技術をSQiPレビュー研究会からあなたに～」 より
10
Copyright © SQiP Review Study Group , All Rights Reserved

JaSST2022東京ワークショップ参加者が感じていたレビューの問題点
レビューでの見逃しが人によってレビューの観点と粒度がバ
ラバラ／ほぼ機能してい途中から参加したプロダクト

協力関係にな
誤認識や不適切な行動でいのか悪いのかわか
れなさそうなとき困る
らない
欲しい結果が出ない・・・
指摘の出来が成果物の質必要以上に時間が不安定
かかっている
この“もやもやした状態”をレビューMTGの進
レビューイの心構え
工数がかかるめ方（受け身）
レビューイ理解度(レレビュー体系化で変えたい！
経験則に頼りすぎてビューアの伝え方)

多い(時支出来ていない
ことも？)
レビュー

について突っ込んでいレビューイとレビューア間の関係性が薄くてないレビューもある

レビュー
発言・指摘が毎回同じ人

レビューの効果が可視化できてない

レビュアーの勘と経いる験に頼ったレビューになってしまっている。

レビュー以前に、何がわからないのか探す習慣がない
非形式なレビューをカジュアルにやってみるなど、取り組みができていないうまくいってない感を解消したいとおもえる、前向きな気持ちを育てたい
レビューを身近なものにしたい

ソフトウェアレビューシンポジウム2022東京 ワークショップ「そゆことね！よくわかるレビューテクニック～明日から使える技術をSQiPレビュー研究会からあなたに～」 より
11
Copyright © SQiP Review Study Group , All Rights Reservedわれわれがやっていること“レビューの体系化”“体系化”とは、バラバラな個々の物事を一つにまとめ、わかりやすくすること

Copyright © JaSST Review Executive Committee , All Rights Reserved

12レビュー体系化のイメージ
JSTQB Foundation Level シラバスの全体像

テスト用語

動的テスト
動的テスト

ソフトウェアライフ
サイクルとテスト
テスト計画
テスト実践例

テストの目的テストとは？

静的テスト

テスト分析・設計

テスト
評価

テスト
監視制御

リスク
マネジメント

構成
管理
テスト
技法

テスト
アプローチ

テスト
ツール

欠陥
マネジメントテスト
ウェア

Copyright © JaSST Review Executive Committee , All Rights Reserved

参考：ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版
Version 2023V4.0.J01
13

レビュー体系化のイメージ
JSTQB Foundation Level シラバスの全体像

レビュー用語
テスト用語

動的テスト
動的テスト

ソフトウェアライフ
サイクルとテスト
サイクルとレビュー
レビュー計画テスト計画
レビュー実践例
テスト実践例

レビューの目的
テストの目的レビューとは？
テストとは？

レビュー分析・設計
テスト分析・設計

レビュー
テスト
監視・制御
監視制御

リスク
リスク
マネジメントマネジメント

レビュー
テスト
評価

構成
構成
管理
管理
レビュー
テスト
技法

レビュー
テスト
アプローチ
アプローチ

レビュー
テスト
ツール

静的テスト
今日はこれらのうち(1)レビュープロセスと実践(2)ソフトウェアライフサイクルとレビュー(3)レビュー観点(4)レビューアーキテクチャ
についてお伝えします。

欠陥
マネジメント
レビュー
テスト
ウェア
ウェア

Copyright © JaSST Review Executive Committee , All Rights Reserved

参考：ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版
Version 2023V4.0.J01
14

レビュープロセスとその実践

Copyright © JaSST Review Executive Committee , All Rights Reserved

15現状の「レビュープロセス」

ISTQBテスト技術者資格制度 Foundation Levelシラバス
レビュー
計画
下記の項目を定義する
・目的、レビュー対象となる作業成果物
・評価対象の品質特性
・重点を置く領域
・終了基準
・標準などの裏付け情報
・レビューの工数
・時間枠からなるレビューの範囲

個々人の
レビュー

レビューの
立ち上げ
レビュー開始までに関係者や物事が準備できたことの明確化がゴール
・すべての参加者がレビュー対象の作業成果物にアクセスできる・自分の役割と責務を理解している・レビューの実行に必要なすべてのものを受け取っていることを確認することが含まれる。

共有と分析

・すべてのレビューアがレビュー対象の作業成果物の品質を精査
・1つ以上のレビュー技法（チェックリストベースドレ
ビュー、シナリオベースドレビューなど）を適用
不正、推奨、および質問を識別する
・レビューアは、特定されたすべての不正、推奨、および質問を記録する

Version 2023V4.0.J01

・通常、レビューミーティングを実施する
・すべての不正を分析して議論する
・すべての不正について、ステータス、オー
ナー、必要なアクションを決める・レビュー済作業成果物の品質レベルと必要なフォローアップのアクションを決める
・完了するには、フォローアップのレビューが必要になる場合がある

修正と報告・是正処置をフォローアップできるよ
うにすべての欠陥に対して欠陥レポートを作成する・終了基準を満たす場合、作業成果物を受け入れる・レビュー結果をレポートする

Copyright © JaSST Review Executive Committee , All Rights Reserved

END
16

JaSST’22Reviewワーク資料(改)検討中の「レビュープロセス」

テストプロセスを参考にしたレビュープロセスの分解
レビュー計画

レビュー

レビューの
立ち上げ

個々人の
レビュー

共有と分析

修正と報告

レビュー

レビュー

レビュー

レビュー

分析

設計

実装

実行

レビュー

完了

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

Copyright © JaSST Review Executive Committee , All Rights Reserved

17テスト体系に沿って実践するとテストにもエンジニアリングが必要／テストケースの意図が重要

テストアーキテクチャ(設計)／コンテナモデリング

テストケース表テスト設計チュートリアル
テスコン編資料(講義編) より
https://www.aster.or.jp/testcontest/doc/
2023_tescon_V1.0.0.pdf

テストケースの構造化／テストフレーム
Copyright © JaSST Review Executive Committee , All Rights Reserved

18テスト体系に沿って実践するとテストにもエンジニアリングが必要／テストケースの意図が重要

レビューはテストの一形態なので同じことが言えるのでは？
→ではレビューではどうなるのか？

テストアーキテクチャ(設計)／コンテナモデリング

テストケース表テスト設計チュートリアル
テスコン編資料(講義編) より
https://www.aster.or.jp/testcontest/doc/
2023_tescon_V1.0.0.pdf

テストケースの構造化／テストフレーム
Copyright © JaSST Review Executive Committee , All Rights Reserved

19

JaSST’22東京＋Review’22ワーク資料
目的構造と観点導出過程がある
ため、その内容確認とノウハウの蓄積と活用が容易になる

レビュー体系に沿った実践事例

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 © JaSST Review Executive Committee , All Rights Reserved

レビュー目的を基軸とした目的構造化表記の採用[拡張]
レビュー観点導出技法
としての部品化と目的構造化表記への割り付けによるレビュー観点導出[技法バリエーション充実]
レビュー観点に基づくレビュー実施集合レビュー会での建設的議論による結果共有
レビュー結果評価[拡張]とふりかえりによるレビュー改20
善検討

JaSST’22Reviewワーク資料

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

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

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

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

上位目的

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

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

マネジメント系要素

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

Copyright © JaSST Review Executive Committee , All Rights Reserved

レビュー
トレーニング

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

JaSST’22東京＋Review’22ワーク資料

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

プロジェクト・
運用時リスクプロジェクト・システム運用時発生事象

Goal32

Goal32

Goal33

要求実
装未達

進捗･納
期遅延

コスト
オーバー

Context
レビュー対象物＝要求仕様書Strategy2

作り込む

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

Goal12

Goal13

Goal21

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

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

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

Goal11Strategy3

Goal22

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

Goal23

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

Goal24

開発関係
Phaseへの影響

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

対象物の典
型的な欠陥

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

Copyright © JaSST Review Executive Committee , All Rights Reserved

Goal34

レビュー
設計技法
22

JaSST’22東京＋Review’22ワーク資料

レビュー設計技法（例1）
利害関係者の関心事アプローチ

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

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

腕っこきレビューアの思考
方法を見える化したもの

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

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

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

Copyright © JaSST Review Executive Committee , All Rights Reserved

23

JaSST’22東京＋Review’22ワーク資料

レビュー設計技法（例2）
対象成果物に求められることアプローチ

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

腕っこきレビューアの思考
方法を見える化したもの

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

確認方法

観点
確認方法
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
Copyright © JaSST Review Executive Committee , All Rights Reserved

24

JaSST’22Reviewワーク資料

レビュー結果の見える化→ふりかえりに活用

観点に基づくレビューの評価（例）aさん
レビュー結果評価指標
効果･影響度大bさん
レビュー結果cさん
レビュー結果dさん
レビュー結果主対象：

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

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

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

指摘件数計

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

②

③

①

bさん
（A1）

ｃさん
（A3）

⑥

⑨

⑤

⑧

④
4

dさん
（A4）

⑫

⑪

⑩

⑦
2

Copyright © JaSST Review Executive Committee , All Rights Reserved3※記述内容は事例

325

JaSST’22Reviewワーク資料

レビュー結果の見える化→ふりかえりに活用

観点に基づくレビューの評価（例）aさん
レビュー結果評価指標
効果･影響度大bさん
レビュー結果cさん
レビュー結果dさん
レビュー結果主対象：

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

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

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

指摘件数計

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

②

③

①

bさん
（A1）

ｃさん
（A3）

⑥

⑨

⑤

⑧

④
4

dさん
（A4）

⑫

⑪

⑩

⑦
2

Copyright © JaSST Review Executive Committee , All Rights Reserved3※記述内容は事例

326

JaSST’22Reviewワーク結果

各チームのレビュー導出技法選択と指摘数
チーム

人
数

A
B
C
D
E

4
4
4
3
4

レビュー観点導出技法選択と指摘数
M1
M2
M3
M4
M5
3-2
6-2
1-0
2-1
1-1
9-3
3-1
4-1
3-1
4-1
6-5
3-1
5-1
6-2
4-2

M6

指摘数
計

5-2
6-0
3-1
3-1

12-5
18-6
17-3
12-7
18-6

※全指摘数(m件)とそのうちの効果大の指摘数(n件)を“m-n形式”で示した

計77-2727

Copyright © JaSST Review Executive Committee , All Rights Reserved

某組織でのワーク結果

各チームのレビュー導出技法選択と指摘数
チーム

人
数

A
B
C
D
E
F

4
4
4
4
4
3

レビュー観点導出技法選択と指摘数
M1
M2
M3
M4
M5
3-1
3-0
2-0
3-0
2-1
3-1
1-0
1-1
1-1
1-0
1-1
2-0
1-0
0-0
4-2
4-1
3-1

M6
3-2
4-0
8-2
7-2
2-1
8-3

※全指摘数(m件)とそのうちの効果大指摘数(n件)を“m-n形式”で示した
ソフトウェアシンポジウム2022 経験論文 「ソフトウェアレビュー研究結果の認知拡大と適用促進」 より
Copyright © SQiP Review Study Group , All Rights Reserved

指摘数
計
11-3
12-2
11-4
11-3
7-3
15-5
計67-2028

JaSST’22Reviewワーク結果

ワークふりかえり結果
レビュー依頼

レビュー分析・設計・計画

レビュー実施Copyright © JaSST Review Executive Committee , All Rights Reserved

レビュー評価・ふりかえり

29

JaSST’22東京ワーク結果

ワークふりかえり結果

ソフトウェアシンポジウム2022 経験論文 「ソフトウェアレビュー研究結果の認知拡大と適用促進」 より
Copyright © SQiP Review Study Group , All Rights Reserved

30

JaSST’22Reviewワーク資料

よくあるレビューアプローチ
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 © JaSST Review Executive Committee , All Rights Reserved31ソフトウェアライフサイクルとレビュー

Copyright © JaSST Review Executive Committee , All Rights Reserved

32テストプロセスの前段部分を先出しする～テストのシフトレフト（例）
製品企画

受入テスト

左(レフト)にシフト
要求定義

左(レフト)にシフト方式設計

左(レフト)にシフト

早期テストの原則
プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。
SDLCの後半に発生する故障が少なくなるため、品質コストは削減される。
早い段階で欠陥を見つけるために、静的テストと動的テストの両方をなるべく早い時期に開始すべきである。
引用：ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 Version
2023V4.0.J01

システム
統合テスト

詳細設計

左(レフト)に
シフト
実装

システム
テスト

ユニット
統合テスト

ユニット
テスト

テスト（プロセス）
テスト
分析

Copyright © JaSST Review Executive Committee , All Rights Reserved

テスト
設計

テスト
実装

テスト
実行

テスト
完了
33

シフトレフトの原理を活用したテスト主導ソフトウェア開発
BDD
Behavior Driven Development
振る舞い駆動開発

ATDD
Acceptance test–driven
development
受け入れテスト駆動開発

TDDとBDD/ATDD(4)ツールとしてのBDDとプロセスに組み込まれたBDD より

TDDとBDD/ATDD(3)BDDとATDDとSbE より

TDD
Test-Driven Development
テスト駆動開発

50分でわかるテスト駆動開発 /TDD Live in 50 minutes より

Copyright © JaSST Review Executive Committee , All Rights Reserved34同一フェーズ内でのシフトレフトライクなこと（テストの例）
入力

フェーズ
作業

成果物
レビュー

素案

修正

完成

テスト分析、設計過程で多くの質問や欠陥指摘が発生し、事後修正が多くなる
成果物レビュー
入力

最初から品質
を作り込む

フェーズ
作業

修正

素案

通常見逃しがちな欠陥も指摘されるため修正が多くなる

観点
整理
入力

完成

フェーズ
作業

初めから観点に注意して成果物を作成するので欠陥作り込みが減る

素案

成果物
レビュー

修
正

完成

欠陥指摘数が減る
ため修正が少ない

Copyright © JaSST Review Executive Committee , All Rights Reserved

35

レビューにおけるシフトレフトライクなこと（レビューの例）
入力

フェーズ
作業

成果物
Adhoc
レビュー

素案

修正

完成

次フェーズ以降で多くの質問や欠陥指摘が発生し、事後修正が多くなる
観点設計
入力

フェーズ
作業

成果物レビュー

素案

修正

完成

通常見逃しがちな欠陥も指摘されるため修正が多くなる

最初から品質
を作り込む

入力

観点
設計

共有
フェーズ
作業

初めから観点に注意して成果物を作成するので欠陥作り込みが減る

次フェーズ以降での質問や欠陥指摘は少なくなる

利用
素案

成果物
レビュー

修
正

完成

欠陥指摘数が減る
ため修正が少ない

Copyright © JaSST Review Executive Committee , All Rights Reserved

次フェーズ以降での質問や欠陥指摘はより少なくなる36モブプログラミング
JaSST Review2018 @TAKAKING22さん「レビュー再定義」講演資料より

37

Copyright © JaSST Review Executive Committee , All Rights Reserved

レビュー観点

レビューアーキテクチャの構成要素

Copyright © JaSST Review Executive Committee , All Rights Reserved

38

JaSST’22Reviewワーク資料

われわれが目指していること

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

有識者依存

観点共有・活用

Copyright © JaSST Review Executive Committee , All Rights Reserved39

【実験】レビュー観点を共有せずに
Adhocにレビューすると何が起きるのか？
実験：実行委員4名で「交通費精算
システム要求仕様書」をそれぞれ突然レビューし、記録した。
↓分析
・指摘総数: のべ92件 (52種類)
・重複なし指摘数：25種
・重複した指摘：27種類→複数人が指摘した件数：計67件→同一指摘: 67 – 27＝40件分
Copyright © JaSST Review Executive Committee , All Rights Reserved

40

JaSST’22Reviewワーク資料

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

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

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

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

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

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

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

実現手段
Copyright © JaSST Review Executive Committee , All Rights Reserved

41

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

具体的なレビュー観点
指摘
事項

指摘
事項

指摘
事項

指摘
事項

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

Copyright © JaSST Review Executive Committee , All Rights Reserved

42

JaSST’22Reviewワーク資料(改)人によって適切に実践できる観点粒度が異なる
レビューアの所有スキルにより観点粒度を調整する

利害関係者

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

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

関心事

必要なレビュー観点（対象）

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

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

観点の具体化・詳細化□必須項目記入漏れの検出□入力不可文字の検出□日付、時間範囲外の検出
これをやればいいんだね！

Aさん
Bさん

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

Aさん

Bさん

Bさん

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

Copyright © JaSST Review Executive Committee , All Rights Reserved

43

JaSST’22Reviewワーク資料

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

内容

1

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

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

3

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

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

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

6

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

Copyright © JaSST Review Executive Committee , All Rights Reserved

44

JaSST’22Reviewワーク資料(改)なぜレビュー観点が必要なのか？(1)”観点”があれば雑多な情報群の中から集中して該当を直接探し当てられやすい□顔色が悪そうな人は？
□人ではないのは？
□隊列が乱れているのは？
Copyright © JaSST Review Executive Committee , All Rights Reserved

45

JaSST’22Reviewワーク資料

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

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

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

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

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

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

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

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

46

JaSST’22Reviewワーク資料

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

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

レビュー観点設計による典型的な指摘変化の例△=アドホックレビュー指摘
JaSST2016東京 事例発表「レビュー目的･観点設定の効果と課題」より●=観点設計レビュー指摘
Copyright © JaSST Review Executive Committee , All Rights Reserved

47

JaSST’22Reviewワーク資料

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

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

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

Copyright © JaSST Review Executive Committee , All Rights Reserved

48

JaSST’22Reviewワーク資料

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

レビューア
Qさん

機能

確認観点リストレビューア
Sさん

機能要求確認

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

非機能

レビューア
Uさん

観点と探索領域の無駄な重複・レビューア 抜け漏れが最小限になる
Pさん
Copyright © JaSST Review Executive Committee , All Rights Reserved

49

JaSST’22Reviewワーク資料

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

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

取捨
選択

RFV Project
YHN Project
取捨
選択

取捨
選択

有効なレビュー観点をまとめて再利用することでレビューの効果を高める
Copyright © JaSST Review Executive Committee , All Rights Reserved

50

JaSST’22Reviewワーク資料(改)目的～観点構造化は重要だが簡単ではない構造化･モデル化にはノウハウがある• 観点設定ではトップダウン／ボトムアップの両面アプローチとMECEである
ことが求められる。
入力ミス検
入力ミス
検知かな

入力ミス検出
機能
これが必要だよね
必須項目記入漏れの検出

出機能

他のミス検出には何がある？
必須項目
記入漏れの
検出

受付不
可文字の
検出

日付、時間
範囲外の
検出

？

それから・・

えっと・・
受付不可文字の検出

日付、時間範囲
外の検出

要は何の
機能？
Copyright © JaSST Review Executive Committee , All Rights Reserved

51

JaSST’22Reviewワーク資料(改)適切な思考・実践方法を身につけるには継続実践が不可欠• 観点設定→観点に基づくレビューを、思考を伴わず形式的に行っても効果は期待できない。
• 重要なのはレビュー対象や観点設計への理解に基づくに実践。
そこには状況に応じた「適切な思考」と「モデル化」が求められる。
• その実践力は、継続して取り組むことで身につくもの。
当初は時間がかかる割に効果は？？？～失敗も多い。
[実践→ふりかえり]の継続～時短＆効果向上

Copyright © JaSST Review Executive Committee , All Rights Reserved

52

レビューアーキテクチャ

レビュー観点によるレビューアーキテクチャの設計

Copyright © JaSST Review Executive Committee , All Rights Reserved53

にしさんの予告 レビューアーキテクチャ
レビュー(運営)タイプの例

レビューレベルの例(テストレベルの対比)

SQiPシンポジウム2019 併設チュートリアル3「ソフトウェア開発における品質の作り込み ～フロントローディングの基礎～」よりレビュータイプの例(テストタイプの対比)

Copyright © JaSST Review Executive Committee , All Rights Reserved□誤字・脱字・衍字チェック□曖昧・不明確・矛盾チェック□規約・様式遵守チェック□利用時シナリオ分析□インターフェース分析□合目的性確認□リスクマネジメントレビュー□性能見積レビュー□セキュリティ要件実装レビュー□内部・外部整合性確認 など
54

レビューアーキテクチャ検討例「要求仕様書のレビュー技法と実践のポイント」安達2020 よりドキュメント特性
基本・形式
規約
曖昧
不遵守
不明確
矛盾
未決

誤字
脱字
衍字
不統一

サービス領域（利用）
判読性

有効性

NG表現
多義表現

効率性

機能

利用状況
適合性

合目的性

性能

使用性

正確性

信頼性

互換性

適切性

保守性

移植性

リスク
回避性

抽象表現

サービス領域（提供）

レビュー共通（レビュー自動化へ）
どのドキュメントでも必ず最初にチェックする共通確認事項

運用性システム／ソフトウェア領域

Ｉ
/
Ｆ

非機能

セキュリティ

信頼性

保守性

画面

構造/論理

製品・サービスの特徴とフェーズにより取捨選択
開発フェーズ進行に応じて選択してチェックする確認事項
55

Copyright © JaSST Review Executive Committee , All Rights Reserved

実行委員によるレビューアーキ構築試行結果(1)観点洗い出し←→(2)同類事項集約←→(3)構造化(1)観点洗い出し(2)同類事項集約

Copyright © JaSST Review Executive Committee , All Rights Reserved

56

実行委員によるレビューアーキ構築試行結果(1)観点洗い出し←→(2)同類事項集約←→(3)構造化
参加者(3)構造化

使用性
満足

効率性
上位目的
達成

内外整合
MECE

リスク対応

判断根拠

誤字/脱字/衍字
体裁･判読可能･規約準拠
INPUT内容の連携/反映

兆候→
欠陥系

次工程実
施可能性

欠陥系

保留・未決

57

Copyright © JaSST Review Executive Committee , All Rights Reserved

レビューアーキテクチャ検討（嬉野さんの例）

①

③

②
④

Copyright © JaSST Review Executive Committee , All Rights Reserved

58

レビューアーキテクチャ検討（嬉野さんの例）

①

＜全体感＞
世の中にある基本的な構造を活用する＜対象＞
・成果物そのもの（自処理やドキュメント内・自処理との関連処理との連携）・（キリがないので今回は省略
または超副次的に）成果物ができる前の開発者の思考・検討・調査の中身（参考）「全」欠点や傷がない。あますところがない。

＜困っていること・課題→解決へ向けて＞
足りないことないかな？
どっか間違えてるんじゃない？
リクエストにないこと入ってたらお客様に叱られる！
なんて不安を解消できるかも

MECE＜メリット＞
・昨年のワークで出た課題「指摘が偏る」「行き当たりばったり」「指摘が散らばる」の解決
・新しいサービスの担当になった・業務が複雑だしあまり知らない・システムに詳しい人が別にいる
なんて時も何とか今までの技術で乗り越えられる、逆に知らない状態を生かして（最低限レビューできる材料だけに限定して）レビューを重ねつつ徐々に知るのもあり

Copyright © JaSST Review Executive Committee , All Rights Reserved

59

レビューアーキテクチャ検討（嬉野さんの例）

②

MECE

Copyright © JaSST Review Executive Committee , All Rights Reserved

60

レビューアーキテクチャ検討（嬉野さんの例）③

Copyright © JaSST Review Executive Committee , All Rights Reserved

61レビューアーキテクチャ検討（嬉野さんの例）④

Copyright © JaSST Review Executive Committee , All Rights Reserved

62

レビューアーキテクチャはプロダクト開発サイクルを回しながら要件は徐々に段階的に洗練していく
固まっていく

対象への理解度は
徐々に高まっていく

ふりかえり

Copyright © JaSST Review Executive Committee , All Rights Reserved

63レビューアークテクチャの利用方法（例）Aプロダクト用レビューアーキテクチャ

Tailoring（取捨選択）

過去トラブル実績

要求定義Phase用レビュー観点群

Review
結果

要求定義

要求仕様書
要求
Review

システムデザインPhase用レビュー観点群

仕様書

システム
デザイン
Copyright © JaSST Review Executive Committee , All Rights Reserved

設計書
Review64

レビュー体系化～このあと

Copyright © JaSST Review Executive Committee , All Rights Reserved

65レビュー体系化のこの先（予定・想定・妄想等）□レビューとは何か？どのようなものか？の探索（われわれの原点～継続検討）□体系化SCOPEの明確化

例：モブワーク、プロジェクト計画レビュー、テスト仕様レビュー、テスト結果レビュー、フェーズ/プロジェクトふりかえり等は対象？

□用語定義の作成

例：レビューレベル、レビュータイプ、レビュー設計、レビュー設計技法、レビューベース、レビューウェア、レビューケース
（ハイレベル・ミディアムレベル・ローレベル）、レビュータイプ、レビュー運営タイプ など□レビュー設計技法の構築／整理

これまでに提案されてきたレビュー観点導出アプローチの抽出・技法化、リーディング技法の整理／すみ分け／マッピン
グ□レビューマネジメントの構成要素分解と実践事項の明確化
レビュー□レビューファシリテーションの構成要素分解と実践力習得方法の明確化
体系化□レビューアーキテクチャの深掘り□各種実践事例構築／収集／共有
レビュー体系が使える□体系化結果～成果物構築・公開（レビューシラバス化？）
モノにするための活動□レビュー実践力向上の場の提供
レビュー設計トレーニング／各種ワークショップ／コンテスト 等

Copyright © JaSST Review Executive Committee , All Rights Reserved

66

JaSST
Review2021
スクラム開発における
POの振る舞い

鈴木 祥子氏

レビューとは何か？
どのようなものか？の探索

Matt Wynne氏

JaSST
Review2022
実例マッピング

河村明彦氏「三越伊勢丹におけるデジタルサービスのつくりかた」

JaSST Review2023
チーム全体でテスト・品質に向かうアプローチ「うまくコラボレーションするためのヒミツ」

Lisi Hocke 氏「チーム一丸となったテストと品質のためのチーム変革戦術」
Copyright © JaSST Review Executive Committee , All Rights Reserved

67レビューマニフェスト（工事中）

Copyright © JaSST Review Executive Committee , All Rights Reserved

68にしさんの予告 QAアーキテクチャ
レビューアーキテクチャ＋テストアーキテクチャの統合？

QAアーキテクチャの設計による説明責任の高いテスト・
品質保証（2016）

車載ソフトウェアの品質保証のこれから(2020/8/28)

Copyright © JaSST Review Executive Committee , All Rights Reserved

69

参考文献
• ソフトウェアシンポジウム2022 経験論文
「ソフトウェアレビュー研究結果の認知拡大と適用促進」
https://www.sea.jp/ss2022/download/7-SS2022.pdf• ソフトウェアレビューシンポジウム2022東京 ワークショップ 「そゆことね！よくわかるレビューテクニック～明日から使える技術をSQiPレビュー研究会からあなたに～」
https://www.jasst.jp/symposium/jasst22tokyo/pdf/F6.pdf• ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf• テスト設計チュートリアル テスコン編資料(講義編)https://www.aster.or.jp/testcontest/doc/2023_tescon_V1.0.0.pdf• ソフトウェアレビューシンポジウム2022 ワークショップ 「レビューでは何を確認するといいのかな？さまざまなレビューの意図を整理して確認事項を明らかにしてみよう！」
https://www.jasst.jp/symposium/jasstreview22/pdf/S4-2.pdf• 要求工学：第3回要求仕様
https://www.bcm.co.jp/site/2004/2004Dec/04-youkyuu-kougaku-12/04-youkyuukougaku-12.htm
Copyright © JaSST Review Executive Committee , All Rights Reserved

70

参考文献
• 50分でわかるテスト駆動開発 / TDD Live in 50 minutes
https://speakerdeck.com/twada/tdd-live-in-50-minutes?slide=9• TDDとBDD/ATDD(3) BDDとATDDとSbE
https://sqripts.com/2023/08/07/61460/• TDDとBDD/ATDD(4) ツールとしてのBDDとプロセスに組み込まれたBDD
https://sqripts.com/2023/08/28/61494/• ソフトウェアレビューシンポジウム2018 講演 「レビュー再定義」
https://www.jasst.jp/symposium/jasstreview18/pdf/S2.pdf• JaSST2016東京 事例発表 「レビュー目的･観点設定の効果と課題」
https://www.jasst.jp/symposium/jasst16tokyo/pdf/A2-1.pdf• 島倉大輔・田中健次（2003）：人間による防護の多重化の有効性、「品質」、33、〔3〕、104-112。
• ソフトウェア開発における品質の作り込み ～フロントローディングの基礎～
https://www.slideshare.net/YasuharuNishi/software-frontloading-and-qa
Copyright © JaSST Review Executive Committee , All Rights Reserved

71

参考文献
• ソフトウェア品質知識体系ガイド （第3版） －SQuBOK Guide V3－• ソフトウェアレビューシンポジウム2021 講演 「三越伊勢丹におけるデジタルサービスのつくりかた」
https://www.jasst.jp/symposium/jasstreview21/pdf/S1.pdf• ソフトウェアレビューシンポジウム2022 講演 「The secrets of effective collaboration 「うまくコラボレー
ションするためのヒミツ」」• QAアーキテクチャの設計による説明責任の高いテスト・品質保証
https://www.slideshare.net/YasuharuNishi/qa-67559281• 車載ソフトウェアの品質保証のこれから

https://www.slideshare.net/YasuharuNishi/ambidexterity-of-automotive-software-qa

Copyright © JaSST Review Executive Committee , All Rights Reserved

72このあともレビューという深い沼を探索し続けます
役立つ成果物が出せるのか・・・乞うご期待

Copyright © JaSST Review Executive Committee , All Rights Reserved73