2019/1/25 祝 JaSST’19北陸 初開催！

そのレビュー、大丈夫ですか？
～現状レビューの問題発見・解決

株式会社HBA 安達 賢二
http://www.software-quasol.com/
adachi@hba.co.jp

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

安達 賢二（あだち けんじ） adachi@hba.co.jp
株式会社HBA 経営管理本部 共創推進グループ

生

http://www.software-quasol.com/
勤住

ものごとの見かたを変える【経歴】
育1987年北海道ビジネスオートメーション（現HBA）入社
システム保守・運用・開発業務、プロジェクトマネージャなどを経験後、部門品質保証担当、システム監査委員、全社品質保証担当、全社品質・セキュリティ・環境管理統括責任者、
全社生産革新活動SLIM（スリーム）技術統括コーディネータなどを担当。
2012年社内イントレプレナー第一号事業者として品質向上支援事業を立ち上げ。
現在、自律運営チーム構築･変革メソッドSaPIDをベースに、関係者と一緒に価値あるコトを創
る共創ファシリテータとして活動中。
【社外活動】
NPO法人 ソフトウェアテスト技術振興協会（ASTER）理事
JSTQB（テスト技術者資格認定）技術委員
JaSST（ソフトウェアテストシンポジウム）北海道実行委員
JaSST-Review（ソフトウェアレビューシンポジウム）実行委員
SEA（ソフトウェア技術者協会）北海道支部
SS（ソフトウェア・シンポジウム）プログラム委員
第33-35期SQiP研究会レビュー分科会アドバイザー
SQuBOK_Ver3プロセス改善研究Grリーダ（プロセス改善の黒歴史研究）
TEF（Test Engineer’s Forum）北海道テスト勉強会（TEF道）お世話係
IPA（独立行政法人 情報処理推進機構）連携委員
TOCfE北海道幽霊メンバー など
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved2

本講演の概要• レビューは、欠陥検出・予防、生産性向上などへの有効な活動として多くの方たちに認識されています。しかし、レビューをする時間がない、責められるのでイヤだ、時間ばかりかかる、効果が実感できない、などの声が多いのも事実です。

• 本講演では、受講者のみなさんにも一部参加してもらい、現状のレビューの問題点と解決の方向性を持ち帰ってもらえるよう、相互に対話しながら進めるような内容にします。
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved3この講演で目指すゴール
受講者の皆さんが• 周囲も同じようにレビューに問題を感じていると気づく。
• 自ら捉えるべきレビューの問題点を認識する。
• 改善を進める際の注意事項を理解している。
• これなら自分にもできそう！と思っている。

• 直近レビューで実際に○○を試してみよう！
と思っている。
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved4コンテンツ• (1)レビューの現状– レビューってどうなってるの？

• (2)レビューで効果を高めるために– ではどうすればいいの？

• (3)改善を効果的に進めるために– カイゼンってどうやればうまくいく？

• (4)講演のふりかえりとまとめ– 今日は何の話だったかな？
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

5最後に 当講演のふりかえり があります！
これは大事･試してみたいと感じたこと

具体的にどのようにするとよいか？
（どのタイミングで何をするか？何で結果・成果を把握すればよいか？など）

大事･試したいと思ったコトに関する現状

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

6

(1)レビューの現状
レビューってどうなってるの？

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

7

事前依頼事項：アンケート• 受講者（予定者）にアンケートを実施。
• 現在のレビューの問題点や困り事を教えてください。
• 何を対象にしたレビューのことなのかを付記してもらう。
• 例：設計書レビューで軽微な指摘しか出ない→あとになってから重大な設計上の問題が発覚する• 一人：選りすぐり3件まで。
• 開催までに結果を収集して事前にお送りいただく。

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

8レビューの困り事と問題構造

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

9

ダメな

レビュー運営シナリオ□レビューが依頼されたら実施する。
□時間や余裕がなくなると必要なレビューを端折ってしまう。
□レビュー実施時に対象成果物（のみ）が配付される。
□レビューアがその場で思い思いの観点でレビューを実施する。
□レビューアの経験則や暗黙知、スキルなどにより指摘内容がばらつく。
例：全体的には表面的なもの（主に記載内容の不備や誤り、不明点など）が多く、腕の良いレビューアが担当する場合などのレアケースで鋭い指摘が混在する。

□レビューに使用できる時間により、指摘数や指摘内容が変化する。
例：時間が少ないほど指摘数や重要な指摘事項が減少し、記述の先頭から順に確認する傾向が高いため、成果物の後半に欠陥が残存する可能性が高まる。

□かけた時間・工数に対して有効な指摘事項が少なくなる傾向が高い。

□役割分担などを決めずにレビューを行う（ことが多い）ため、探索領域、および観点・指摘内容の重複、抜けが発生する。
□レビューの結果（記録）が残らない。
□フォローアップは実施されない。
□レビューに関わる要員はレビューの効果が実感できず、以降のレビューへのモチベーションが低くなる。
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved10アドホックレビューのアプローチパターン
観点？

観点？

観点？

観点？

1p

1p

1p

1p

2p

2p

2p

2p

3p

3p

4p

5p

重複指摘

4p

2p

3p

3p

4p

4p

4p

・ 時間切れ・・

5p

・ 時間切れ・・
上から順に記述確認型

・ 時間切れ
・
・

6p

重複指摘

経験的
観点

時間切れ

全体の8～9割程度

成果物の
後半に指
摘が少ない

3p

全体把握→個別詳細
攻撃型

経験的
観点

3p

7p

リスク察知・エラー推測
によるピンポイント攻撃型

全体の1～2割程度

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

11レビュー結果分析表と記載例
見逃した場合の発見可能Phase（想定）△●：指摘事項

実装・UT

IT

ST・OT

C/O後

1

3

5

7

計

効果大
例：
要件抜け・誤り

5

35

効果中

検
出
効
果

3

効果小
例：
誤字・脱字・衍字

1

1

UT＝Unit Test
IT=Integration Test
ST=System Test
OT=Operation Test
C/O＝Cutover計
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

12ぼんやりレビューするとこうなる（例）発見可能Phase（想定）

△指摘事項
23件

実装・UT

IT

ST・OT

C/O後

1

3

5

7

計

効果大
主対象：

要件抜け・誤り

5

30

3

75

効果中

検 主対象：
出 機能上のバグ
効 （誤植による）
果△が左下（指摘価値が低
い）に集中

効果小
主対象：

誤字・脱字・衍字
規約違反

計

1

16

35

18

40

28

121

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved 13

レビューの視野や深みを小さくする要因の例• セルフチェックがない粗雑な対象をいきなりレビューする。
– 表面的な指摘に終始してしまう• レビュー対象だけを見てレビューする。
– 書かれていることだけに反応してしまう• 既成の汎用チェックリストに沿うだけのレビューを行う。
– 重要度の高低を無視して載せられた項目を平坦に確認する• 一度に大量の冊子をレビューする。 何時間（例：6h）もかけてレビューを行う。
– “こなす”レビューに。集中できた箇所以外はスッカスカになりうる• 大勢で同じ対象を（ぼんやり）チェックする。
– 誰かが見るから私くらい見なくてもダイジョウブ症候群に陥り、見逃しが多くなる／探索領域と指摘事項の重複（ムダ）も多くなる

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

14レビューパフォーマンス影響要因と構造レビュー計画・運営（実践）レビュー改善

目的・
観点

レビュー
対象の質

スキル・知
識・経験
参加者

指摘
内容

運営
方法

レビューへのモチベーション

結果・
成果

効果
実感

時間・
工数

情報
活用
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

15

(2)レビューで効果を高めるためにではどうすればいいの？

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

16

レビューで効果を高めるために【対応方針1】 できるだけ（無駄な）レビューをしない– レビューすべきものだけをレビューする• レビュー以前の問題は作成者の責任で解決• 限られたリソースで最大の効果を発揮するレビュー対象を特定する– 集合形式のレビュー時間を最小化する• 個別レビューで8割方の決着をつける– 一度のレビュー規模を小さくする• 対象作成作業とレビューを連携させる• 事前すり合わせ、試作→レビュー＆早めのフィードバックを繰り返して完成させる【対応方針2】 ぼんやりレビューを行わない– 目的をより効果的に達成するレビュータイプ等を選択する– 必要なレビュー観点等を明確化＝狙いを定めてレビューを行う– 作成状況や成果物の特徴等から兆候を察知し、仮説を立ててアプローチを決める– 人間特性を考慮して運営を設計する【対応方針3】 レビューをやりっぱなしにしない– 完了判定とフォローアップによりリスクを識別し、修正を確実に完了させる– ふりかえりにより改善事項を明確にする
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

17レビューの有効性を支える要因

業務に
よらない
レビュー
技術

業務固有
ノウハウ

運営方法
場／相互理解・協調
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

18

レビューで効果を高めるために【対応方針1】 できるだけ（無駄な）レビューをしない– レビューすべきものだけをレビューする• レビュー以前の問題は作成者の責任で解決• 限られたリソースで最大の効果を発揮するレビュー対象を特定する– 集合形式のレビュー時間を最小化する• 個別レビューで8割方の決着をつける– 一度のレビュー規模を小さくする• 対象作成作業とレビューを連携させる• 事前すり合わせ、試作→レビュー＆早めのフィードバックを繰り返して完成させる【対応方針2】 ぼんやりレビューを行わない– 目的をより効果的に達成するレビュータイプ等を選択する– 必要なレビュー観点等を明確化＝狙いを定めてレビューを行う– 作成状況や成果物の特徴等から兆候を察知し、仮説を立ててアプローチを決める– 人間特性を考慮して運営を設計する【対応方針3】 レビューをやりっぱなしにしない– 完了判定とフォローアップによりリスクを識別し、修正を確実に完了させる– ふりかえりにより改善事項を明確にする
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved19対象の質がレビューに与える影響
間違い探しレビュー実験結果
入力情報は等価（同一間違い10件混入）【A：複雑】 VS 【B：構造化】【複雑・ランダムな情報羅列】

間違い探し
レビュー

A
情報
【構造化・意味ある分類】

B
情報＜レビュールール＞
各自すべての情報の確認を終了したら経過時間と検出した間違い数
を記録する

間違い探し
レビュー

平均検出率
（％）

平均時間
（分）

73 8.0【B：構造化】の方が・「71%の時間」で
・「検出率が18point 高い」
平均検出率
（％）

平均時間
（分）

91 5.6

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

20START

突然依頼

レビューの全体像

目的
設定
状況把握→
観点設定

個別
Review
個別
Review
個別
Review

タイプ・技法
設定

確認手段
設定

開始
判断

集合
Review

結果評価
結果判定

レビューア
割り当て
メトリクス・
評価方法

ふりかえり

GOAL

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

21

レビューすべきものだけをレビューする

レビューするに値する対象をレビューする
作業+セルフチェック
セルフ
チェック
時間

レビュー
対象

開始
基準
NG

レビュー
OK
レビュー
時間

◎効果1 作業者としての最低限の責任（例：セルフチェックの励行）や質の良い作業を動機づける。
◎効果2 効果の低い欠陥や不備の確認→検出などに時間・工数を浪費することを防ぐ。
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

22

レビュー開始基準・判定
よくある開始基準の構成要素例□セルフチェック済みである。
□バージョン識別子が付与されている。
□パッと見で重大な欠陥や軽微なバグ群が存在しない。
□未解決課題と解決の目途がすべて明示されている。
□入力、参照情報がすべて参照可能である。
□先行作業成果物の品質レベルが確認されている。
□レビュー目的が理解され、共有されている。
□作成者が自ら確認して欲しい観点を提示している。

開始基準とは、レビュー実施に必要な条件や準備しておいて欲しい事項
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved23限られたリソースで最大の効果を発揮するレビュー対象を特定するどれが重要（レビュー必須）？
成果物

A

B

C

D

E

機能重要度低1-5高

1

1

3

1

5

難易度

低

高

中

低

超高

規模（Page）

5P

13P

25P

3P

7P

作成日数

1.5日

4日

8日

1日

7日

担当者開発経験

10年

3年

3年

1年

8年

作業中変更受付数

0件

5件

1件

2件

1件

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved24集合形式のレビュー時間を最小化するとある集合レビューの10分間
1分
レビューアA

レビューアB

1分

1分

1分

質問・コメント

1分

1分

1分

1分

1分

質問・コメント

コメン
ト

5人分

コメン
ト

質問･
コメン
ト

2人分

コメン
ト

レビューアC

レビューアD

1分

質問

1人分
コメン
ト

2人分

総工数：4人×10分=40人分 実稼動工数：1分稼動×10=10人分
稼動効率：実稼動工数／総工数×100＝25%
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved25集合形式のレビュー時間を最小化する／一度のレビュー規模を小さくする

人間の集中力継続時間

１５分×３（計４５分）学習
グループのガンマ波波形

６０分学習グループのガンマ波波形※グラフ１と２のガンマ波の絶対値の大小は関係なし
集中力の維持と長期的な学習効果につながる方法（東京大学・池谷裕二教授の見解）より
http://www.asahi.com/ad/15minutes/article_02.html
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

26

一度のレビュー規模を小さくするどの運営がよいですか？
作成

レビュー
大量フィードバック

作成

作成

レビュー

少量フィードバック
事前認識
あわせ

作成

レビュー

レビュー

作成

少量フィードバック

作成

レビュー

少量フィードバック 少量フィードバック

作成
寄り添い

リアルタイムフィードバック

レビュー

少量フィードバック

精神的・身体的・ものづくり的に最も負荷が高い/低いもの、効果的なものはどれでしょうか？

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved27

上流工程でバグを検出するのがよい？
リードタイムが長くなるほど、手戻り工数が膨らみ、生産性が低下し、品質確保が困難に

Bug

見つけた！
直した！

混入

時間の流れ
このリードタイムを最小にすること
が品質を高め、手戻りを最小にし、生産性を高める秘訣※時間が経過しても手戻りが変わらないものもあるので注意
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

28

レビューで効果を高めるために【対応方針1】 できるだけ（無駄な）レビューをしない– レビューすべきものだけをレビューする• レビュー以前の問題は作成者の責任で解決• 限られたリソースで最大の効果を発揮するレビュー対象を特定する– 集合形式のレビュー時間を最小化する• 個別レビューで8割方の決着をつける– 一度のレビュー規模を小さくする• 対象作成作業とレビューを連携させる• 事前すり合わせ、試作→レビュー＆早めのフィードバックを繰り返して完成させる【対応方針2】 ぼんやりレビューを行わない– 目的をより効果的に達成するレビュータイプ等を選択する– 必要なレビュー観点等を明確化＝狙いを定めてレビューを行う– 作成状況や成果物の特徴等から兆候を察知し、仮説を立ててアプローチを決める– 人間特性を考慮して運営を設計する【対応方針3】 レビューをやりっぱなしにしない– 完了判定とフォローアップによりリスクを識別し、修正を確実に完了させる– ふりかえりにより改善事項を明確にする
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved29

目的をより効果的に達成するレビュータイプ等を選択する

レビュータイプと期待効果例
レビュータイプ概要

期待効果（欠陥除去）

インスペクション最も厳格で、体系的、公式に実施されるレビュー。 1000行当たり16～17件という報告有り

チームレビュー

軽量化されたインスペクション。
構造化されているがインスペクションほど公式、厳格でない。

1時間当たりの欠陥検出数はインスペクションの2/3という報告有り

ウォークスルー作成者が主導して実施されるレビュー。
作成者自らが対象成果物内容を説明することで実施する。
記録が取られないことが多いため、バグの検出にそれほど効果的ではない。

1000行当たり8件程度（インスペクションの半分）という報
告有り

ピアデスクチェック

ペアレビューとも呼ばれ、作業者以外にはただ一 （少ない工数で欠陥検出する
人だけが作業成果物を調べる。最も安価なレ手法の一つ）
ビュー方法。

パスアラウンド

作成者が作業成果物のコピーを複数人に配付し、 （比較的時間がある場合や複数のコメント・フィードバックを獲得する方法。
分散開発で有効）アドホックレビュー

場当たり的、思いつきで実施するレビュー。ある
特定の切り口に対する意見・コメントを即興で求める場合にのみ有効。

欠陥除去にはあまり寄与しないCopyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved30特徴（長所・短所）

どのような場合に活用すると効果的か
どのような場合に使わないようにすべきか

インスペクション

厳格で、体系的、公式に実施されるレビュー。最も欠陥検出効果が高く、プロセス改善促進も期待できるが、不適切な運営では費用対効果が悪化する。

成功要因：トレーニングされた要員と組織的運営（特にモデレータは重要）、各種実績データに基づく判断等。
トレーニング不足なら採用しない方がよい。

チームレビュー

厳格さ抜きでも欠陥検出を期待する場合に効果がある。適切な運営により効果が期待できる。運営ノウハウがないとムダが増え、効果が得られない場合がある。

必要な有識者が参加できる場合、効果が期待できる。
力量あるモデレータがいるとスキル不足が補える場合があるが、スキル不足要員ばかりになる場合は避けた方がよい。

ウォークスルー作成者が主導して対象成果物内容を説明しながら実施する。説明が上手な人が対応する場合、レビュー対象の内容不備が検出されない可能性がある。

力量のある要員が自らの作業結果を確認する場合や、実作業前に作業者の理解度を確認する場合、また関係者に内容を把握しておいてもらいたい場合等に効果が期待できる。

ピアデスクチェック

机上で担当者とレビューア（通常1名）で行う確認。2名の都合が合えばすぐ実施できる。結果がレビューアの力量に大きく左右される。

有識者が育成過程要員の教育を兼ねてレビューア対応を行うのが最も効果的。レビューアの力量が伴わない場合はこの手段を選択しない方がよい。

パスアラウンド

集合せずに複数名のレビューアからコメントを取得できる。リードタイム制約が高い場合や、作業者と回覧先要員の力量が伴わない場合等では効果が少ない。

比較的時間・期間（リードタイム）をかけても構わず、作業者が一定レベル以上のスキルがあってコメント処理
を適切に対応できる場合に活用可能。時間がない場合は避ける。

アドホックレビュー

ピンポイントに活用すると費用対効果が最大になる可能性もある手法。
思いつき確認なので、網羅的な確認に向かない。

特定の確認したい事項を有識者に依頼するなどピンポ
イント確認での使用を推奨。
網羅的な確認、有識者ではないレビューでは採用しない方がよい。

レビュータイプ

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved31

目的をより効果的に達成するレビュータイプ等を選択する

リーディング技法の特徴（実験結果からの考察）
アドホック（Ad-hoc）

チェックリスト（CBR）

シナリオ（SBR）

特徴

・無計画、思いつき対応
・未確認、見逃しが多くなる可能
性大・新発想獲得の可能性

・網羅に向くため見逃しを防止できる可能性大・項目毎に個別確認することが多く時間がかかる

・利用者、設計者などの視点で、流れで確認する
・上流工程で使用されることが多い

効果決定
要因

担当者のスキル、経験に結果が大きく左右されるチェックリストの質と活用方法に結果が左右される

設定するシナリオの質に結果が左右される

コミュニケーショ
ンの影響

結果・効果に大きな影響を与える

結果・効果に影響を与える場合がある

結果・効果への影響を受けにくい

強み

担当者が持つノウハウ・直感による確認が可能・時間がかからない

・チェック項目を網羅しやすい・スキルのばらつき影響を受けにくい

利用者、設計者等様々な視点で、目的達成の可能性に対する確認が可能

弱み

・確認漏れ、重複、表面的確認に終始しがちになる

時間がかかる／形式的確認となる可能性あり／チェック項目以外に目がいかなくな
る可能性あり／チェックリストの作成、維持が大変表現形式、スタイルの良し悪しなどの基本的事項の確認が抜けてしまう可能性あり／想定利用者のコンテキストと合わない可能性あり／不整合を見逃す可能性あり

事前準備等考慮事項

スキル・経験ある担当者が対応する

事前にレビュー対象に必要なチェック項目の選定や追加・カスタマイズを行うことが必要

想定利用者とその利用状況を具体化
し、利用者の立場に立って行う

効果的
活用法

別途網羅的確認を行いつつ、ピンポイントでこの技法を活用するのが効果的

チェック項目の選定・追加・カスタマイズした上で網羅的確認に活用する

上流工程を中心に、チェックリストと併用することで効果が期待できる

項目/技法

立場で見る「Perspective Based Reading」やユースケースで見る「Usage Based Reading」などがある
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved32

目的をより効果的に達成するレビュータイプ等を選択する

製品特性・リスク、レビュー環境等によるレビュー実施方法の採用
レビュー
対象
関連
Doc

必要なレ
ビュー観点

製品特性把握
製品
特性
製品
リスク

製品リス
ク評価

レビュー
実施方法
の検討と決定レビュー計画

レビュー環境（レビューを実施する背景）
使える時間

メンバー数と特性利活用可能な情報など

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved33

目的をより効果的に達成するレビュータイプ等を選択する

産学連携によるデザインレビュー改善事例
三菱電機 細谷さん他
http://www.jaspic.org/event/2011/SPIJapan/session1B/1B3_ID003.pdf

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved34

必要なレビュー観点等を明確化＝狙いを定めてレビューを行う
マインドマップによるレビュー観点設計事例

売れるのか？
役立つのか？

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

35

必要なレビュー観点等を明確化＝狙いを定めてレビューを行う

レビュー観点設定
ワークショップ実施組織• 組込み系メーカ2社 6チーム+6チーム• SIer 1社 5チーム
• 独立系システムソリューション企業 1社 2チーム• 組込み系メーカに勤務する協力会社 6社 5チーム
組織ロケーション：東京・横浜・札幌・大分・名古屋・仙台など
分析可能なデータが存在した

10社24チーム
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

36必要なレビュー観点等を明確化＝狙いを定めてレビューを行う

実施結果例

Aグループ

20140618

計画立案過程Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved37

必要なレビュー観点等を明確化＝狙いを定めてレビューを行う

実施結果例

Bグループ

20140618

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved38ぼんやりレビューするとこうなる（例）発見可能Phase（想定）

△指摘事項
23件

実装・UT

IT

ST・OT

C/O後

1

3

5

7

計

効果大
主対象：

要件抜け・誤り

5

30

3

75

効果中

検 主対象：
出 機能上のバグ
効 （誤植による）
果△が左下（指摘価値が低
い）に集中

効果小
主対象：

誤字・脱字・衍字
規約違反

計

1

16

35

18

40

28

121

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved 39

狙い撃ちレビューではこうなる（例）発見可能Phase（想定）

●指摘事項
24件

実装・UT

IT

ST・OT

C/O後

1

3

5

7

計

効果大
主対象：

要件抜け・誤り

5

335
●が右上
（指摘価値が高い）に集中

効果中

検 主対象：
出 機能上のバグ
効 （誤植による）
果

3

93

効果小
主対象：

誤字・脱字・衍字
規約違反

計

1

8

19

0

340

77

436

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved 40

レビュー改善による指摘変化の例 指摘件数： △23 → ●24△改善前（Before）●改善後（After）

発見可能Phase（想定）
実装・UT

IT

ST・OT

C/O後

1

3

5

7

計

効果大
30
↓
335

主対象：

要件抜け・誤り5

効果中

検 主対象：
出 機能上のバグ
効 （誤植による）
果

3

効果小

△が左下
（指摘価値が低い）に集中●が右上（指摘価値が高い）
に集中

主対象：

誤字・脱字・衍字
規約違反

計

75
↓
93

16
↓
8

1

35→19

18→0

40→340

28→77

121→436

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved 41

指摘件数の変化
35
30
25
20

15
10
5
0
改善前指摘件数

改善後指摘件数

・指摘件数増：18チーム（Max20件増）
・指摘件数変化なし：2チーム
・指摘件数減：4チーム（Max13件減）
・指摘件数変化平均：4.8件増／チーム

平均4.8件増
中央値5.5件増

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved42指摘内容（価値）の変化
600

500
400
300
200
100

0
改善前指摘価値改善後指摘価値・指摘価値増：21チーム（Max424p増）
・指摘価値減：3チーム（Max58p減）
・指摘価値変化平均：151.5p増／チーム

平均151.5P増
中央値172.5P増

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved43結果が出なかったチームの例△改善前（Before）●改善後（After）

指摘件数： △14 → ●11

発見可能Phase（想定）

実装・UT

IT

ST・OT

C/O後

1

3

5

7

計

効果大
ハード変更必要
ｻｰﾐｽﾀ壊れたら止
められない

5

0
↓
40

3

69
↓
18

1

9
↓
7

ミルク温度検出仕様なし

検
出
効
果

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

9→7

9→33

60→25

0→0

78→65

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved44

効果が出なかった理由（考察結果）
観点？

観点？

1p

1p

1p

観点？
観点2

1p
10p

2p
3p

観点1･4

1p

2p

2p

2p

11p

3p

3p

3p

12p

2p

13p

3p

4p
5p
6p
7p

4p

8p

・ 時間切れ
・
・

9p
・
・
・
17p

腕っこき
が沢山
指摘

4p

4p

観点3

5p

6p
時間切れ

・ 時間切れ・・

腕っこきの観点・探索領域を限定してし
まった

6p

4p

7p
8p

5p

9p

目的・観点設定レビュー時
アドホックレビュー時
45
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved書かれていないことを見つける方法の例
レビューで最も期待されていること• 過去の記載漏れ事例から確認する• 表現方法を変えてみる– 自分の表現で説明してみる– 別の切り口で再構成してみる– 図表やモデル化してみる– 記述フレームにはめてみる• テンプレートとガイドライン• テストケース構成要素に割り付けてみる

•
•
•
•

利用者の背景やシーンから読み解く
前フェーズ成果物、関連成果物との整合を見る
要素間の連携部分を狙う
特定の言葉で引っ掛けるなど

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

46

人間特性を考慮して運営を設計する
これまでのSQiP研究会レビュー関連研究対象（全体像）
原因分析
観点分析

観点-欠陥
兆候-仮説-欠陥
プロジェクト特性
作成者の特性INPUT【レビュー観点】
重大欠陥の見つけ方【認知バイアス】
作成者の背景×成果物の特徴→認知バイアス推測→欠陥傾向特定

TASK
例：設計【コンテキストベース】
プロジェクトの特徴（状況・知識・経験×
ユーザ・プロジェクト・作成者）→レビュー時注意事項→欠陥潜伏箇所

対象
成果物

Review

Review
結果【欠陥パターン】（兆候-仮説/検証） 【検出テクニック】
対象成果物の特徴 欠陥の見つけ方→作業方法や思考の推定→発生しやすい欠陥

欠陥パターン
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved47

人間特性を考慮して運営を設計する

次の状況から想定されることは何か？
どこをどのような視点で確認すると効果的か？
(1)レビュー対象の成果物は25ページ。ざっと目を通したところ
誤字、脱字、衍字が大量に見つかった。
(2)作成者がレビュー対象の成果物の作成に着手したのは2日前とのこと。
(3)作成者は先月からこれまで継続して残業、休出が突出していた。過去に参加したプロジェクトで構築したシステムに問題が見つかり、その対応に借り出されているとのコト。
(4)MS-Woｒｄで作成されたレビュー対象成果物の最終書き込み
日時は今日のAM3:35になっていた。また、当初書き込み日時
は、5年前の3/28AM2:58だった。

兆候察知 → 仮説設定 → 行動選択
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved48

人間特性を考慮して運営を設計する

レビューアの割り当て
人数は3～7名程度【理想】観点がレビュー出来るメンバーを割り当てる。
【現実】基本的に得意なところを見てもらう。（第一優先）そのうえで、残りを各メンバーで分担。
重点事項・見逃しリスクがある観点は、重点・軽減対策を施す。
複数担当配置・観点詳細化と事前摺り合わせ など

有識者が忙しい場合は、アドホックレビューでピンポイント確認依頼なども考慮。
これらの方法の強み・弱みは何？
担当a

担当b

担当c

担当d

重要

観点1

〇

〇

〇

〇

観点1

観点2

〇

〇

〇

〇

観点2

観点3

〇

〇

〇

〇

観点3

観点4

〇

〇

〇

〇

観点4

担当a

担当b

担当c

担当d

〇

◎

◎

〇

◎
☆
◎
★

〇

〇

※何となくアドホックレビューをやると依頼内容
はこの状態に近くなる（実施はバラバラ）

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved49人間特性を考慮して運営を設計する

レビュー・テストの心理•見つけたエラー、欠陥、故障を建設的に取り扱えれば、テスト担当者と設計者、開発担当者との間の敵対感情を避けられる。
テスト担当者やテストリーダは、欠陥、テストの進捗、リスクの情報をやり取りする
場合、建設的に作業が進むよう優れたコミュニケーション能力が必要となる。
テストで欠陥を見つけて修正するとリリース後に検出して修正するより時間と金の節約になるし、リスクも減る。欠陥の情報はソフトウェアやドキュメントの作成者のスキルを高めることにつながる。
テスト担当者が「悪いニュースを伝える使者」との扱いを受けるとコミュニケーションの問題が起きる。

•••

コミュニケーション／関係改善方法“分離”ではなく“協調と連携”で対応する
•
•

•
•

対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであること再認識するとよい。
プロダクトに対する指摘は、中立で、事実を中心にして実施し、欠陥を作りこんだ
担当者を非難する方向に行かないようにする。例えば、見つけたことを客観的かつ事実に基づいたインシデントレポートを書いたり、見つけたことをレビューしたりする。
他人の気持ちや反応を理解するように努力する。
自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する。
出典：ISTQBテスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02 より
50
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved人間特性を考慮して運営を設計するチームの文化が重要
レビューで想定される悪影響• 自己責任の放棄・他者責任への転嫁（甘え）誰かが誤りを見つけてくれるからそれなりにやっておけばよい。指摘されたら直せばよい。（指摘されない限
り一切直さない）指摘しない奴らの責任にできる。

• 過剰な自己防衛
恥をかきたくない。指摘されたくない。だから成果物案を見せるのを拒む。指摘されても拒否する など。
どちらも結局は生産性を悪化させ、要求品質未達成
やコスト超過・納期遅延の原因となる
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved51

人間特性を考慮して運営を設計する

プロジェクト計画書指摘と反応の例
レビュー指摘例1：計画書でG社との連絡チャネル・担当者が書WIN
かれていない
例2：計画書ではG社との連絡チャネル・担当者が不明である
例3：【確認】
G社との連絡･調整はどのように行う予定ですか？
【リスク】
納入済製品の動作に問題がある、納期が遅延すると○○工程で△△など危機的状況になりえるように思いますがいかがですか？

作成者が適切に修正し終わるまでがレビュー
相手の反応

LOSE

WIN

LOSE
WIN

LOSE
WIN
Risk
Management
PolicyWIN
LOSE

例１:計画書に書けばいいのね？それであなたの気が済むの？（形式対応）

例2：担当Sが窓口でG社と調整しながら進めることになっていますが、、、まだ周知してないですね。追記して周知しなくちゃ。
例3：いちいちうるさいなぁ。
そんなの知るか！
→手を変えるなど何度か働きかけても対応しない場合はエスカレーションへ

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved52人間特性を考慮して運営を設計する

受け取りやすい指摘の伝達• レビューアが行うのはよりよい成果物を作成するための作成者向け “支援”• （可能な限り）相手が受け取りやすい伝達により、作成者が自ら進んで行動することが重要（やらせる／やらされる→自ら進んでやる）• 主語を“あなた”ではなく“私”・“われわれ”
例：私はこう受け取ったのですが合ってますか？

• 断定的な物言いをしない
例：もしかすると○○かもしれないと（私が）感じたので確認してもらえますか？

• 手段よりも事実や目的にフォーカスする53

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved人間特性を考慮して運営を設計する

コミュニケーションスタイル

幸せでないことが起こるときがある

どのような物言いが好き
拠点が／嫌いなのか 離れて
いる
組織が
異なる

お互いを
知らない

お互い
面識す
らない

指摘される側を気遣うあまり表現が曖昧
になることも本来伝えたいことがうまく伝わらないうまく修正をナビゲートできなくなる指摘された側が傷ついたり腹が立ったりすることがある
指摘者も傷つくことがある

あなたは何タイプ？コミュニケーション上手になるための4タイプ診断法
https://next.rikunabi.com/journal/20151203/

Driving【現実派】

Expressive【感覚派】

自己主張：強感情表出：弱指図されるのは嫌い／思い通りにやらせてよタイプ

自己主張：強感情表出：強楽しく盛り上がって行
こう！タイプAmiable【協調派】

Analytical【思考派】

自己主張：弱感情表出：強みんなのため頑張れる／お役に立ちたいタ
イプ

自己主張：弱感情表出：弱やるべきことは正確に、
計画通り進めましょう
タイプ

2019/2/22 SQiP研究会2018年度
成果発表会で研究発表があります！

「コミュニケーションスタイル」 猪塚修さん資料を編集

論理派＆スピード重視型

感覚派＆スピード重視型

論理派＆マイペース型

感覚派＆マイペース型

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

54

レビューで効果を高めるために【対応方針1】 できるだけ（無駄な）レビューをしない– レビューすべきものだけをレビューする• レビュー以前の問題は作成者の責任で解決• 限られたリソースで最大の効果を発揮するレビュー対象を特定する– 集合形式のレビュー時間を最小化する• 個別レビューで8割方の決着をつける– 一度のレビュー規模を小さくする• 対象作成作業とレビューを連携させる• 事前すり合わせ、試作→レビュー＆早めのフィードバックを繰り返して完成させる【対応方針2】 ぼんやりレビューを行わない– 目的をより効果的に達成するレビュータイプ等を選択する– 必要なレビュー観点等を明確化＝狙いを定めてレビューを行う– 作成状況や成果物の特徴等から兆候を察知し、仮説を立ててアプローチを決める– 人間特性を考慮して運営を設計する【対応方針3】 レビューをやりっぱなしにしない– 完了判定とフォローアップによりリスクを識別し、修正を確実に完了させる– ふりかえりにより改善事項を明確にする
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

55

レビュー結果の判定
結果判定
□合格

□条件付き合格□不合格□指摘事項の修正後、再度レビューを実施する。
□指摘事項の修正状況と修正結果をモデレータが個別にフォローアップする。
□指摘事項の修正結果は、担当者自らが確認し、終了したことをモデレータに報告する。
□指摘事項の修正結果は、自ら確認し、問題なければそのまま次のフェーズに進む。
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

56結果記録（例）→修正・フォローアップ／指摘事項の評価
要求仕様レビュー結果を「レビュー効果分析表」にプロットする
指摘箇所

No.

指摘内容

指摘分類

要修正

確認

①

筐体

筐体と構造が“手軽”でないのでは？

ウリ・使用性☑

☑

②

蓋

閉めると沸騰モードになるのはわかりにくい。

ウリ･使用性･安全
性

☑

□

③

タイマ

単独タイマ機能でコストが高いなら必要ないのでは？（100均ショップで分秒表示タイマ購入可能）

有効性・効率性

☑

☑

④

カルキ抜き

蒸気を逃がす機構がない。カルキが抜けない？

安全性・機能性

☑

☑

⑤

解除ボタン

100msec押下で解除可能。子供のいたずらや偶然の押下でも解除できてしまう可能性あり。

安全性

☑

□

⑥

解除ボタン

「解除」だけでは何の解除かわかりにくい。

ウリ・使用性☑

☑

⑦

アイドル移行

pot-330-12･13では蓋センサoffが条件となっているが、pot-221-11では蓋センサが1sec以上offとなったら温度制御行為中止となっている。不整合
では？

安全性・内部不整
合

☑

☑

⑧

ミルクモード対象ユーザのニーズなし。必要ないのでは？

有効性

☑

□

⑨

ミルクモード蒸気を逃がす機構もないため、沸騰・カルキ抜き
後から60℃になるまで時間がかかりすぎないか？（電源onのままだと60℃に到達しない？）

効率性・有効性

☑

☑

⑩

コンセント

筐体との接続部分は安全対策がなされている？

安全性

☑

☑

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

57

レビュー結果からリスクを特定

この領域は
大丈夫？

この領域は
大丈夫？

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

58

レビューメトリクス例
レビュー速度と欠陥当たり工数の関係
1.5

欠
陥
当
た
り
工
数
（
工
数
／
件
）

出典：「ピアレビュー」 Karl E. Wiegers 著

1欠陥検出に
かかる工数
が多い
＝非効率

1欠陥検出にかかる工数が少ない＝効率的

レビュー速度（LOC／時間）

500

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved59欠陥密度とレビュー速度100

出典：「ピアレビュー」 Karl E. Wiegers 著

80
欠
陥
密 60
度
（
件
／
40

効率と有効性の最適なバランスが取れる
速度の例
・仕様書、計画書など 3～4頁／時間
・ソースコード 150～200行／時間

KLOC

）
20

200

600
400
レビュー速度（LOC／時間）

800

1000

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

60

レビューメトリクス例
レビュー速度と欠陥指摘密度の関係
出典：「データ指向のソフトウェア品質マネジメント」 野中誠・小池利和・小室睦 著

一般的に「良い状態」
欠
陥
指
摘
密
度
（
件
／
行
）

※異常値がある場合は、レビュープロセスと指摘内容の吟味が必要

一般的に「品質不良」

一般的に「良い状態」

一般的に「急ぎすぎor
見落としの懸念」※異常値がある場合は、レビュープロセスに問題がないかを確認する※再レビュー検討※再レビュー検討

レビュー速度（行／分）Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

61レビューメトリクス例
600

←

5

レ
ビ
ュ
ー
速
度
（
行
／
時
）0

今回
上限値

7

2

4

1

平均値

6
8

3

レビュー番号（履歴）

←
欠
陥
密
度
（
件
／

K

行
）

3
4

8

7

6

検出欠陥分布1

2

今回
5

レビュー速度（行／時）→
出典：「ピアレビュー」 Karl E. Wiegers 著
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

62

レビュー比率-換算欠陥数
ユーザー企業 社団法人 日本情報システム・ユーザー協会 2008年6月 ２００８年版 【調査報告書】

レビュー比率-換算欠陥数

レビュー比率>10%：大きな換算欠陥率の点が無い<5％：大きな換算欠陥率の割合が高い

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved63ふりかえりの流れ• （実施計画立案～対象活動or期間の終了）• ふりかえり観点設定• 実施体制、情報共有・活用方法の明確化• ふりかえりフレームワークの選択
KPT：Keep/Problem/Try
YWT：やったこと/わかったこと/次にやること
ORID：Objective/Reflective/Interpretative/Decision• ふりかえり実施• ふりかえり結果と認識の共有• ふりかえり結果の活用（以降の活動で改善実践）
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

64

KPTによるふりかえり概要
①Keep

③Try

良かった点

次にやってみること

反省会（うまくいかなかったことだけが対象）ではないので、前向きに、明るく対応できるように良かった点（KEEP）から始める。良かった点をちゃんと出せること、それをみなで評価することが重要！

①

良い面、改善が必要な面の両方で効
果的なポイントを外さず次に繋げる②Problem

まずかった点
うまくいかなかったことをありのまま出せることはさらに重要！
（他者責任追及ではなく自己責任、活動面中心で）

うまくいったことは継続、またはさらにうまくいくように見直しをする

③

実施順
②

（それができているなら必ずしも①②の事項を網羅的に対応する必要はない）
うまくいかなかったことはどうしたらうまくいくようになるかを具体的に検討（必要なら原因分析）して結果を出す（抽象的な方向性だけで終わらない
ように注意！）

作業の節目（週末・フェーズ終了時・業務完了時など）に関係者全員で“良かった点（Keep）・まずかった点（Problem）・次にやってみること（Try）を出し合い、情報と認識を共有したうえで、次の業務や作業に確実に繋げる。
ホワイトボードに手書きで対応する、ワープロ・プレゼン用アプリケーションで対応するなど対応方法はいろいろありえる。
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

65ふりかえりフレームワークの例
KPT
Keep

最も普及しているフレームワーク。
シンプルなので使いやすいが、結果が個人の主観・記憶に左右されやすい側面もある。そのため初期導入時ほど、ふりかえり対象期間を短くする、
腕のよいモデレータが進行するなどの工夫が必
要になる。

Try

Problem

YWT
Y：やったこと

W：わかったこと

T：次にやること

ORID : Objective/Reflective/Interpretative/Decision
O：事実

R：感情

I：解釈

D：決定

KPTの次に普及しているフレームワーク。シンプ
ルなので使いやすく「Y：やったこと」からはじめる
ため過去の記憶を想起しやすい特徴を持つ。一方で「W:わかったこと」が「Y：やったこと」に引っ張られて一面的になるケースも。
ふりかえり対象のリードタイムが長い場合などに有効。

客観的事実だけでなく、それをどう感じたのかを含めることにより、メンバーがより気持ちよく能力を発揮してチームパフォーマンスを上げることを目指す。KPTで運営できるようになったあと、より深くふりかえりを実践する場合などに使う。

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

66ふりかえりのゴール（目指すこと）
OK！

こうする
べきだ

こうして
欲しい

全然問題
ないよ
俺はどうで
もいい

すごくい
いよね

いいよ

こんな問
題がある

×組織、チーム内で目的・目標が共有されておらず、個々のメンバーが自ら見えている領域で様々な意見や不満を持っている。今後の方向性を含めて認識が合っていない。

あいよ
分かった

了解！

よっしゃ

◎組織、チームとして目指す目的・目標に対して、現在の状況や今後の方向性と対応、各自のやるべきことについて関係者全員が同じ認識を持ち、同意している。

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved67しっかり狙って指摘できるようにする
レビュー
対象の質
レビュー実践
レビュー改善

目的・
観点

指摘
内容

レビューへのモチベーション

改善要因

結果・
成果

スキル・知
識・経験
参加者

運営
方法

時間・
工数

効果
実感
改善目的
要素

情報
活用
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

68指摘しやすい環境をつくり出す
レビュー
対象の質
レビュー実践
レビュー改善

目的・
観点

指摘
内容

レビューへのモチベーション

改善要因

結果・
成果

スキル・知
識・経験
参加者

運営
方法

時間・
工数

効果
実感
改善目的
要素

情報
活用
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

69

レビュー改善による設計プロセスの進化例
設計活動

成果物

段階的な進化を駆動する手段が“ふりかえり”

進化

設計活動

成果物
案

Review

成果物

進化

Review
設計活動

計画

成果物
案

観点
導出

Review

記録化
保管
共有

成果物

進化

考慮事
項設定
計画

設計活動

成果物
案

観点
更新

Review
記録化

Review

テスト担当
の参画
成果物

保管
共有

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved70ちょっとまともなレビューワークシナリオ
1)レビューが依頼される。
2)レビュー対象の内容や背景を事前に把握する。レビュー開始できるかを判定
し、基準を満足しない場合は作成者にその旨を伝えて返却する。
3)レビュー対象の特徴、該当フェーズ、入力情報、製品リスク、利害関係者の要望などを考慮してレビュー目的･観点を導出し、体系化する。
4)観点の重要度などを参考にして優先順位を付与し、それぞれのレビューアが担当するレビュー観点を調整し、確定する。
5)役割分担に従い、割り当てられた観点でレビューを行う。各レビューアは時間制約の中で、最も重要な観点から確認する。
6)観点が特定されているため、探索領域を絞り込みやすく、欠陥検出がしやすくなる。また、観点重複、探索領域の偏り、指摘重複が減少する。
7)以上の結果、かけた時間・工数に対して有効な指摘事項が多くなる。レビュー
結果がレビューアのスキルに依存する度合いが減少する。
8)ふりかえりによりレビューの成果、よい点、問題点、以降のレビュー改善内容が明確になる。
9)費用対効果が高くなるため、レビューに関わる要員はレビューの効果を実感し、以降のレビュー実施やその改善に対するモチベーションが高まりやすい。
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved71

(3)改善を効果的に進めるためにカイゼンってどうやればうまくいく？

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved72

改善の制約条件• 組織には改善に使える余裕はほとんどない。
• 実務は問題だらけ。すべてを一網打尽にはできない。
• 関係者はそれぞれの立ち位置で見えている問題を、自ら見えているものを見たい（歪んだ）見方、で捉えている。
• 関係者それぞれの思いは違っている可能性が高い。
• 人に命令されたコトは後ろ向きに、自分で決めたことは前向きに実施する可能性が高い。
• 人間は感情の動物、慣習を好む＝変化を避ける傾向がある。論理より感情が勝る。
• 自らが思う問題を相手が理解するのは意外と難しい。
• 理解・納得していないことにチカラを注ぐ人はいない。
• 過去と他人は変えれらない＝誰かのせいにしても解決しない。
• 変えられるのは自分と未来だけ。
• 撃ち落せる問題領域の幅や奥行きは、担当者～組織が持つ能力に依存する。
これら制約条件をベースに進められる改善プロセスでなければならない
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved73

改善を進める上で大事なこと• 多くの問題、困り事から、取り組む価値のある改善ターゲットを特定する– 使えるリソースは非常に限られている！⇒一網打尽はムリ– 複数の要素が相互に作用して問題や困り事が発生している– 問題、困り事発生のメカニズムから取り組むべき改善ターゲットを特定する• 関係者全員が状況を理解・納得し、当事者（自分事）として取り組む– 納得していないことに労力を注ぐ人はいない– 当事者として関わらなければ成功の実感も得られない– 他者責任追及はあとで／自分たちの役割の範疇で改善すべきことを優先にする• 改善ターゲットが大きければ、価値ある小さい領域に絞り込む– たくさんのことを、長い期間で改善する方法は結局うまくいかなくなる– 小さい領域をできるだけ短い期間、少ない工数でちゃんと打ち落とす• 実践可能で、効果・効率を兼ね備えた手段でターゲットを撃ち落とす– 現状能力レベルの110～120%程度のストレッチ目標がベター– できなかったことができるようになる、自ら狙って撃ち落せたら“うれしい”• 小さな成功を積み重ね、改善力と成果を雪だるま式に高める– 100m全力走の連続実施や20km全力走は困難– 継続できるレベルのFun Runを継続しながらレベルを上げていくのが理想
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved74

自律型プロセス改善実践手法

SaPID（サピッド）
Systems analysis / Systems approach based Process Improvement methoD（業界・職種を問わない）
ソフトウェア関連業務に携わる組織やチーム、管理者やエンジ
ニア（または実務担当者）が期待する成果を得る、そして成長するために、当事者自らがシステムズアプローチを実践しながら段階的にゴールを目指すプロセス改善手法。
※システム化検討（現状分析～企画立案）時や、さまざまな業種の改善にも適用可能な手法

システムズアプローチ
対象領域に存在するさまざまな要素の関係性、相互作用全体を一つのシステムと捉え、システム的な思考と各種手法を駆使しながら分析・評価・最適化などの段階（フェーズ）を経て複雑な問題の解決を探る方法論。
問題はさまざまな要素の相互作用・関係性が引き起こしている、という立場で解決策を見出す。
関係者からさまざまな情報（構成要素）を収集して「問題構造図」に表し、関係者間で共有することで自らの背景や現状に対する適切な解決策を探る。

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

75

SaPIDによる改善事例（一部）
今回のアプローチもSaPIDを活用した事例です◆情報処理推進機構（IPA）主催セミナーでの事例解説「ソフトウェア開発現場の"気づき"から始めるプロセス改善 実施事例紹介その1」
https://www.youtube.com/watch?v=n4aRBB_zv2c※SaPIDを活用してシステム保守を行うチームが自ら改善した事例の解説ビデオ。
表題はSPINA3CH（スピナッチキューブ）ですが、SaPIDでアプローチした事例です。

◆ソフトウェアテストシンポジウム2016東京（JaSST'16東京）「レビューの目的・観点設定の効果と課題」
http://www.slideshare.net/AdachiKenji/ss-59510938
レビューの問題点をSaPIDシステムズアプローチで分析し、攻略ポイントとその解決手段を導出、実践結果を考察したもの。

◆ソフトウェアテストシンポジウム2018東京（JaSST2018東京）「TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善」
http://bit.ly/2FLtpHU
テストの問題点をSaPIDシステムズアプローチで分析し、TPI NEXTによる評価結果を併用しながら自律化を目指すアプローチの事例です。
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

76

SaPIDでできること・やっていること
これらの場づくりと
ファシリテーション

関係者の巻き込み・
コミュニケーション促進
過去・現状・未来
モノ・コト・人の想い
など

対象
関係者間の
相互理解促進

対象の明確化
対象への理解腹落ちと納得

関係者の当事者化促進合意形成

良好なチーム
ワークの醸成改善の活性化
成長の促進
個人・チーム・組織

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

77

SaPIDが促進する成長発達段階とスキルレベル
実際の人数分布に基づく整理
自己変容・相互発達段階
成人の1%未満

成 自己変容型知性
自己主導段階長
成人の20%程度
発
達 自己主導型知性
理論に
他者依存段階基
成人の70%程度
づく
成 環境順応型知性
長
道具主義的段階
発
成人の10%程度
達段
段階的思考段階
階

5
4

3

2
1

子供

ハーバード大学 ロバートキーガン
教授による成長発達理論 より★2～3へ、3～4へ上がるために必要な事項
・自分中心の視点から一歩離れた視点を持つ
・自分の考えを言語化する
・より上の段階に発達した人とのコミュニケーション
効果的な小さなリアクションの積み重ねが重要
それを周囲でファシリテーションしていくことが必要

最低限
の基礎

1

指導下
で遂行

2 独力で 3

4

5 6 7

遂行 応用

企業内 国内 世界で実践者 有識者 有識者 通用

ITSS・ETSS等に基づくスキルレベル（分野毎）
ITスキル標準とは？ https://www.ipa.go.jp/jinzai/itss/itss7.html

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

78

(4)講演のふりかえりとまとめ
今日は何の話だったかな？

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

79

レビューの困り事と問題構造

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

80

レビューで効果を高めるために【対応方針1】 できるだけ（無駄な）レビューをしない– レビューすべきものだけをレビューする• レビュー以前の問題は作成者の責任で解決• 限られたリソースで最大の効果を発揮するレビュー対象を特定する– 集合形式のレビュー時間を最小化する• 個別レビューで8割方の決着をつける– 一度のレビュー規模を小さくする• 対象作成作業とレビューを連携させる• 事前すり合わせ、試作→レビュー＆早めのフィードバックを繰り返して完成させる【対応方針2】 ぼんやりレビューを行わない– 目的をより効果的に達成するレビュータイプ等を選択する– 必要なレビュー観点等を明確化＝狙いを定めてレビューを行う– 作成状況や成果物の特徴等から兆候を察知し、仮説を立ててアプローチを決める– 人間特性を考慮して運営を設計する【対応方針3】 レビューをやりっぱなしにしない– 完了判定とフォローアップによりリスクを識別し、修正を確実に完了させる– ふりかえりにより改善事項を明確にする
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

81レビューの有効性を支える要因

業務に
よらない
レビュー
技術

業務固有
ノウハウ

運営方法
場／相互理解・協調
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved82当講演のふりかえり
何か実務に役立ちそうな内容はありましたか？
これは大事･試してみたいと感じたこと

具体的にどのようにするとよいか？
（どのタイミングで何をするか？何で結果・成果を把握すればよいか？など）

大事･試したいと思ったコトに関する現状

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

83相互理解&協調によるチームプレーで楽しく仕事をして、「いいね！」と言われるシステム・ソフトウェアをどんどん提供していきましょう！

ありがとうございました。

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

84

参考文献
•
•
•
•
•
•
•
•
•
•
•
•
•

「ピアレビュー」 Karl E.Wiegers著, 大久保 雅一監訳
JaSST’16東京事例発表：レビュー目的・観点設定の効果と課題
http://jasst.jp/symposium/jasst16tokyo/pdf/A2-1.pdf
JaSST’15東北基調講演：現在のレビューに必要な次の一手を把握するレビュー実践ウォークスルー
http://jasst.jp/symposium/jasst15tohoku/pdf/S1.pdf
集中力の維持と長期的な学習効果につながる方法（東京大学・池谷裕二教授の見解）より
http://www.asahi.com/ad/15minutes/article_02.html
産学連携によるデザインレビュー改善事例 細谷泰夫、吉岡克浩、森崎修司
http://www.jaspic.org/event/2011/SPIJapan/session1B/1B3_ID003.pdf
SPI Japan 2011：ふりかえり実践方法の変遷による業務運営プロセスと成果の改善
http://www.jaspic.org/event/2011/SPIJapan/session3B/3B4_ID008.pdf「コミュニケーションスタイル」 猪塚修さんの資料
あなたは何タイプ？コミュニケーション上手になるための4タイプ診断法
https://next.rikunabi.com/journal/20151203/
20180413開催：SaPID3.0ガイダンス資料
ユーザー企業 社団法人 日本情報システム・ユーザー協会 2008年6月 ２００８年版 【調査報告書】
http://www.juas.or.jp/cms/media/2017/02/08swm.pdf「なぜ弱さを見せあえる組織が強いのか ― すべての人が自己変革に取り組む「発達指向型組織」をつくる」 ロバート・キーガン (著), リサ・ラスコウ・レイヒー (著), 中土井僚 (著)
ITスキル標準とは？ https://www.ipa.go.jp/jinzai/itss/itss7.html「データ指向のソフトウェア品質マネジメント」 野中誠・小池利和・小室睦 著
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved85参考文献：SQiPライブラリー掲載論文
http://www.juse.jp/sqip/library/
•

•
•
•
•
•
•
•
•
•
•
•
•
•
•

欠陥パターンと検出テクニックを用いたレビュー手法の提案と そのトレーニング
教材の有効性評価の報告
HDR法：仮説駆動型レビュー手法の提案
検出難易度の高い欠陥を検出するレビュー観点の提案
SBR（ステルスベースドレビュー手法）の提案
欠陥連鎖チャートを用いたレビュー方法の提案
作成者の認知バイアスに着目したレビュー手法の提案
要求仕様書の特性に着目した個人レビュー手法の実験的評価
設計者自身による設計品質の作り込み～テストエンジニア視点の活かし方
間接的メトリクスを用いて欠陥予測を行うレビュー方法の提案
ソフトウェア品質不安に対する心理的側面に着目した、レビュー計画作成技法の
提案
要求仕様書におけるテストエンジニアの視点を活かした欠陥検出方法の提案
効率的・効果的なレビュー実施のための新規役割「ハーベスタ」の提案
重点欠陥を早期是正するレビュー手法 ３分割レビューの提案
重点欠陥を効率よく検出するレビュー手法の提案と有効性の実験報告
重大欠陥検出に集中するための問診に基づくレビュー法（IBR法）の提案
Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved86ソフトウェアレビュー関連書籍

ソフトウェアインスペクション
Tom Gilb、 Dorothy Graham著

ピアレビューKarl E.Wiegers著
大久保 雅一 著

間違いだらけの設計レビュー
森崎修司著

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

87

今年も開催予定！
①設計レビューで問題を叩き出せ！～QAの役割～
白水 俊治氏（日立製作所）②レビュー再定義 及部 敬雄氏（楽天株式会社）③アーキテクチャのレビューについて 鈴木 雄介氏（グロース・アーキテクチャ＆チームス）

Copyright © Kenji Adachi / HBA Co-creation & collaboration Promotion Group , All Rights Reserved

88