レビューの成功要因はどの程度のキキメがあるの？

ソフトウェアテストシンポジウム2021四国　招待講演資料
http://www.jasst.jp/symposium/jasst21shikoku/report.html

Transcript

1. 「レビューの成功要因」は どの程度のキキメがあるの？ 1 レビューのキキメ～Part2 Software Quasol ＠HBA 安達 賢二 https://www.softwarequasol.com/ adachi@hba.co.jp ソフトウェアテストシンポジウム(JaSST)2021四国 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
2. 安達 賢二（あだち けんじ） adachi@hba.co.jp 株式会社HBA 経営管理本部 Exective Expert http://www.softwarequasol.com/ 【経歴】 2012年社内イントレプレナー第一号事業者として品質向上支援事業SoftwareQuasolを立ち上げ。 自律運営チーム構築･変革メソッドSaPIDをベースに、 関係者と一緒に価値あるコトを創る共創ファシリテーター／自律組織･人財育成コーチ として活動中。 【社外活動】 NPO法人 ソフトウェアテスト技術振興協会（ASTER）理事 JSTQB（テスト技術者資格認定）技術委員 JaSST（ソフトウェアテストシンポジウム）北海道 2006-2009実行委員長 2010-2018実行委員 2019～サポーター テスト設計コンテスト本部審査委員(2015-2017) JaSST-Review（ソフトウェアレビューシンポジウム）実行委員 SEA（ソフトウェア技術者協会）北海道支部メンバー SS（ソフトウェア・シンポジウム）プログラム委員 第33-37期SQiP研究会レビュー分科会アドバイザー SQuBOK_Ver3プロセス改善研究Grリーダ（with プロセス改善の黒歴史研究） TEF（Test Engineer’s Forum）北海道テスト勉強会（TEF道）お世話係 TOCfE北海道幽霊メンバー など 2 生 育 住 勤 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
3. 今日のテーマ 3 テスト技術者資格制度 Foundation Levelシラバス 3.2.5 レビューの成功要因 レビューを成功させるための組織的な要因 • レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。 • 達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。 • レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法 やロールベース技法など）を1つ以上使用する。 • チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。 • 欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなド キュメントは小さく分割して記述およびレビューする。 • 参加者に十分な準備時間を与える。 • レビューのスケジュールは適切に通知する。 • マネージャーがレビュープロセスを支援する（例えば、プロジェクトスケジュールでレビューに十分な時間が割 り当てられるようにする）。 • レビューは、社内の品質、および/またはテストのポリシーに統合する レビューを成功させるための人的な要因 • レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパースペクティブを 持ち、対象のドキュメントを使うことがある人たち）。 • テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテス トを早期に準備できると、レビューアとして価値がでる。 • 参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。 • レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビュー は対象を小さく分割して実施する。 • 見つかった欠陥は客観的な態度で確認、識別、対処をする。 • ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。 • レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。 • 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。 • 特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。 • 学習とプロセス改善の文化を醸成する。 レビューの問題構造 本当に解決 するのか？ Copyright © Kenji Adachi@Software Quasol , All Rights Reserved JSTQB
4. コンテンツ • レビューの成功要因 • レビューの問題構造 • レビューの成功要因はレビューの問題を解決するのか？ • レビューの成功とは？ • レビューの成功とその先 4 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
5. レビューの成功要因 5 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
6. レビューを成功させるための組織的な要因 テスト技術者資格制度 Foundation Levelシラバス 3.2.5 レビューの成功要因 S1：レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。 S2:達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。 S3：レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法 やロールベース技法など）を 1 つ以上使用する。 S4：チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。 S5：欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなドキ ュメントは小さく分割して記述およびレビューする。 S6：参加者に十分な準備時間を与える。 S7：レビューのスケジュールは適切に通知する。 S8：マネージャーがレビュープロセスを支援する（例えば、プロジェクトスケジュールでレビューに十分な時間が割 り当てられるようにする）。 S9：レビューは、社内の品質、および/またはテストのポリシーに統合する。 6 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
7. レビュータイプ テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03 • 非形式的レビュー – 例えば、バディチェック、ペアリング、ペアレビュー • ウォークスルー • テクニカルレビュー • インスペクション 7 レビュー 対象 非形式 レビュー テクニカル レビュー 修正済 レビュー 対象 レビュー 済成果物 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
8. レビュー技法 テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03 • アドホック • チェックリストベース • シナリオとドライラン • パースペクティブベース • ロールベース 8 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
9. レビューを成功させるための人的な要因 テスト技術者資格制度 Foundation Levelシラバス 3.2.5 レビューの成功要因 H1：レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパースペクティブを 持ち、対象のドキュメントを使うことがある人たち）。 H2：テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテスト を早期に準備できると、レビューアとして価値がでる。 H3：参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。 H4：レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビュー は対象を小さく分割して実施する。 H5：見つかった欠陥は客観的な態度で確認、識別、対処をする。 H6：ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。 H7：レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。 H8：参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。 H9：特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。 H10：学習とプロセス改善の文化を醸成する。 9 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
10. 〇〇作成 例：基本設計 成果物 案 INPUT Review 結果サマリ Review 計画 Review 開始 個々の Review 懸念事項共有･分析 修正･報告 Review 計画 1 2 3 4 5 0 個別 Review 結果 Review 報告 集合会議 結果評価 開始 基準 終了 基準 修正 報告 成果物 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 終了 基準 レビュープロセス 参考：テスト技術者資格制度 Foundation Levelシラバス 3.2.1 作業成果物のレビュープロセス 10
11. S5小分割レビュー H4小分割レビュー H3 適切な時間割当に よる詳細なレビュー 〇〇作成 例：基本設計 成果物 案 INPUT Review 結果サマリ Review 計画 Review 開始 個々の Review 懸念事項共有･分析 修正･報告 Review 計画 1 2 3 4 5 0 個別 Review 結果 Review 報告 集合会議 結果評価 開始 基準 終了 基準 S1目的定義 S2適切なレ ビュータイ プ選択 参加者選定 S6十分な 準備時間 S7ｽｹｼﾞｭｰﾙ通知 S8レビュー プロセス支援 Manager Quality Policy Test Policy S9品質･テスト ポリシーに統合 Review S4 Checklist 最新維持 Check list S3-1適切なレ ビュー技法選択 H1適切な 要員の関与 Test Engineer H2 早期テスト準備 による貢献 H5 検出欠陥の客観 的確認･識別･対処 H7-1信頼できる 雰囲気で実施 H7-2レビュー結果 を人的評価に使 用しない H8発言の受取に注意 (退屈感、憤り、敵意) H9高度レビュータイプ へトレーニング提供 ふりかえり 修正 報告 成果物 H6 有意義な時間とな る適切なマネジメント S3-2適切なレ ビュー技法使用 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 終了 基準 H10学習とプロセス 改善文化の醸成 レビュープロセス上に成功要因をマッピング 11
12. レビューの問題構造 12 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
13. 分析は大 変・実施 されない 日程調整が 不調・大変 対象物事 前提出なし or遅れ 作り方、内 容ばらつき 成果物がレ ビューする に値しない 状態 自己チェック なし・チェッ ク不足 レビュー 工数が取 れない レビューへの モチベーショ ンが低い 場面に適した レビュー形式 がわからない 何でもレ ビュー対象 になっている 曖昧 指摘 形式的・ 形骸化 事前 チェック なし 適切なメ ンバーが 揃わない 参加者 が多い 有識者が 多忙で不 参加 有識者が 少ない スキル差 が大きい レビュー ア育成が 進まない ドメイン・ レビュー 知識不足 チェックリスト が形骸化 チェックリスト を使っても指 摘が漏れる チェック項目 が多い・使わ れない 結果がレビューア に依存する いつも同じ 欠陥ばかり 軽微な指 摘ばかり 欠陥・問題 の見逃し 指摘を適 切に伝え られない 回答できない 自己 防衛 思いつき・ 観点がバ ラバラ 意見・指摘が偏る /発散する 参加者が 寝る・発 言しない 声大者独壇場 脱線 する 怒られる、説教 等ツライ 説明会になる 知見を 蓄積で きない 指標値の 収集・分析 が未定着 生産性が 低い・効果 が不明 時間が かかる 落としどころ 不明で何度 も繰り返す 指摘漏れがない か確信できない OK/NG判断 が困難 欠陥指摘 が少ない 議論したが 未修正 指摘のみ修 正し，全体 確認や横展 開なし 記録作成に 時間がかかる 議事内容 がばらばら 議事録が 残らない レビューが 進捗のボト ルネックにな りやすい レビューの 重要性・必 要性が広ま らない 後工程で 欠陥が発 見される 1 2 3 1 2 2 3 2 4 6 4 6 6 3 5 5 13 1 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved どのくらいどのように自己レビューするのか説得できない 自己レビューをやらない人、やれない人がいる 誤字脱字が多い成果物案も多い 人によりコード等の書き方が異なる 仕様や設計の記載の仕方の問題もある レビューのインプットが不明確 レビューするに値しない成果物も多い 議論したが仕様に未記載で設計に考慮されない 製品として本当に必要な機能なのか疑問なものもある バグ分析で必要な作業が抜けていることが分かる チェックリストが数100件で大変 参加メンバーのレベル不ぞろい 対象ドメインの有識者不足 チェックリストを作るが、別プロジェクト、メンバーが使わないことが多い 読み合わせレビューなど形骸化している 明確な誤り以外指摘しない、欠如、過剰は見逃される傾向あり すぐ目に見えるところだけレビューする傾向がある せっかくの知見が横展開されない 知識、経験共有をしていない なんでもレビューすることになっている インスペクションをやるほど工数を持っていない場合も多い レビュー工数割り当てが少ない レビューする暇がない 実施調整ができずサーバに成果物案を置き見ておいてね、になる レスポンスがないと問題なしと受取ることもある どうやってしっかりやるのか分からない どの場面でどのレビュー形式を採用したらよいのかが不明確 レビュー時間の落とし所が分からない レビュー指標：上限値・下限値はあるが、当てはまらないことも多い レビューの効果が不明瞭 時間がかかる・効率が悪い レビュー生産性が低い 設計漏れなど同様の指摘が複数のプロジェクトで発生する 人を沢山投入しても欠陥指摘が少ない “ざるレビュー”になっていることがある ソフトウェア開発企業1_札幌(20件) 設計者・レビューアにより着眼点・重点ポイントが異なる 担当者のスキル差が大きい 知識が浅くてもレビューする場合あり ソースレビューとテストの責務の境目があいまい Docでは理由・根拠が理解しがたい場合がある 内容の分かりやすさや体裁などの指摘が難しい 自分の思いつくままに問題を指摘していく 設計に記載する観点が担当者毎にバラバラ レビューOK・終了判定が難しい 担当者で指摘事項の差が大きい レビューアにより指摘の深さ・範囲が異なる レビュアーが適切な人員ではない場合がある この辺は大丈夫だろうと思うところにうっかり不具合が多い レビューア（の考え）により都度対応を変えるのが大変 その場で答えられない質問が管理しきれない場合がある 細かい内容を確認し始めると無尽蔵に時間を費やしてしまう 問題を見逃す場合がある 問題を捉えきれない場合がある 議事の内容がチームごとにばらばら レビューに時間がかかる Docの目的を把握せずに作成・レビューする レビュー資格者にレベル有 レビュー観点が担当者で異なる おおもとの構造/機能設計が完了しないまま詳細設計が行われる 弊害確認等のレベルが担当者により大きく異なる 担当者で指摘内容が変わる 効率的、精度の良いレビューの方法が分かっていない レビューア育成のため出席者が多い 事前に資料展開されることが少ない MTG時に初めてものを見る レビュー実施が形骸化している レビュアーに該当知識が無い レビューで必要ない質問等がある 設計業務担当者の責任範囲・Outputが不明確なまま割り振られる レビューと、責任範囲・Outputを決める打ち合わせが混在している Docレビューで正しい判断が出来ない 議事録が残らない時がある OK/NG判定の経緯が議事録に取り切れていない 長時間になることがある 1回のレビューに時間がかかる レビュー工数を使ってしまう レビューの必要性が理解されない レビューをやりたがらない やれと言われてしょうがなくレビューする 意見が偏る メンバーが集まらない 特定の奴（例：偉い奴）だけ話す レビューしてほしい人が出ない／少ない 資料を事前に出せない (ocの質が悪い 資料事前確認しない 説明会になる 検討会になる 軽微な指摘ばかり レビューイが黙る・回答できない 権限など気にして発言ない（例：若手） 時間長い・ダラダラ 自分の意見を否定 いじめられる ダメ出し大会 怒られる きつく指摘する 説教 参加人数が多い 寝てる人がいる レビュー開催が伝わってこない レビュー対象（結構膨大な量）が直前に提出 レビュー対象の内容が担当者によって違う 関係者を揃わないため日程がうしろにずれる レビューに時間がかかりすぎてしまう コード確認に時間がかかりすぎる 時間がかかる レビュー時間がほとんど取れない 期限になってもレビューしてくれていない 本質ではない話題にそれ無駄に時間が経過する 内容の把握に時間がかかる 入力文書で条件を出すには時間不足 不整合，誤字脱字などが多数あり理解し難い 誤字脱字探しになりがち レビューの進め方がうまくできない 単なるコードの説明になってしまう 中身のないレビューになる 誤字・脱字などが多すぎてレビューが進まない 指摘にムキになって反論・言い訳する人がいる 未完成で口頭の説明になってしまう 何でこんな事分かってないんだとイライラする（指摘にもその気持ちが出てしまう） 悪いことしたような気持ちになってしまう コードレビューができる人が、社内にほとんどいない 個人の知識に依存する スキルを持ったレビュアー自体が少ない （スキルのある要員に）負担がかかりすぎる レビューア依存 有識者を集められない レビューアが育たない 技術力により品質がばらつく 軽微な指摘しか出てこない 指摘は人による差が出てしまう 指摘のポイントが異なる 漏れた指摘がレビューアの責任にされすぎる。 参加人数が多いと様々な指摘が出て、なかなかまとまらない 指摘個所のみ修正し，全体確認や横展開してもらえない 効果があると現場が感じる方法が上手く見つからない レビューポイントが明確でない レビュアーによって言うことが異なる レビューの指摘が曖昧で対応に苦慮する レビュー対象が膨大 レビュー工数が不足する 「声のでかい人」がやたらと仕切り、自分の意見・考えを通そうとする 当事者意識が少なく、積極的にレビューに加わらない人がいる 自己チェックが甘い 形式チェック（誤字・脱字など）に目が奪われる レビューが内容チェックには入れない 自己チェックリストも形骸化する 有効なレビューをするために有識者を集めるが、スケジュールの調整に苦労する 有識者はとにかくビジー レビュー結果のドキュメント化（レビュー記録）に時間がかかる 記録の傾向分析もあまりやられていないのが現状 レビュー記録から区分を選択するなどは面倒） レビューアがレビューする開発システムの業務詳細、システム詳細に関して理解度が低い つっこんだレビューが出来ない レビューアの育成がなかなか進まない。 知識がないと漏れがないかの確信が持てない 業務視点でのレビューが、なかなかできない（または、弱い）場合がある。⇒お客様業務を深く理解できない場合に、社内レビューが手薄、浅はかとなる レビューを受ける側もレビューコメントをする側も幸せでないことが起こるときがある レビュー指摘件数などの指標が蓄積できていない 指摘された側が傷ついたり腹が立ったりすることがある 指摘者も傷つくことがある 指摘される側を気遣うあまりに、表現が曖昧になり、本来伝えたいことが伝わらずにうまく修正をナビゲートできなくなる 拠点が離れていたり、組織が異なったり、面識すらないときもある 誤字、誤記、罫線の切れなど体裁ばかりの指摘が多く、肝心の機能的な指摘が少ない場合が多い。 機能については、レビューではなく実施側や受け入れ時に見つかる。 細かくみると時間がかかる。 行き当たりばったりの指摘で、本題からそれていく。 レビューを繰り返すうちに落としどころが見つからず、ずるずるレビューの回数だけが増えていき、どこでけりをつけていいのかいまいち分からないときがある。 お客様の理解が取れずレビューにかかる工数（費用）を確保できない。 レビュー工数に対する指摘の件数が少ない チェックリストを使用してもレビュー漏れが発生する 時間をかける割には、些末な指摘しか出来ずない 単なる儀式になってしまっている 指標値の収集・分析活動が組織として定着していない 指標値は少数の大規模件名の結果から作成されたものであり，小規模件名に対する妥当性が不明 後工程で欠陥が発見される レビューが進捗のボトルネックになりやすい レビューに耐えられない成果品がレビューにかかっている レビュー観点が定まっておらず仔細な指摘が多い 本当のレビューができる要員（業務有識者）が少ない 業務有識者が参加していない形骸化したレビューが散見される 実のあるレビュー実施の重要性の認識が広まらない（やらされ感、形骸化） レビューアが効果的なレビューのやり方を知らない 経験と勘によるレビューになっている レビューアの体調、気分、作業状況により、レビューのしかたが変わる レビューされる側に成果物に対する責任感が低い場合がある レビューアに指摘してもらえばよいと思ってわからないところを残したままの成果物を持ってくることがある レビューア育成が進まない レビューアの育成をやっていない 作成者が指摘され修正することを前提にレビューする レビューで指摘してくれるからとレビュー対象を中途半端な状態で依頼してくる 成果物の作り込みが甘い レビュー対象物がレビューするに足る品質に達していない レビューに時間がかかりすぎる レビューに費やす時間が多すぎて大変 作成者が自分は100点だと思ってレビューを受けない レビューを後回しにしがち／されがち レビューが適切なタイミングでできていない 承認を得るためのレビューになっている 参加者が安定しない 自分がレビューするときの観点が正しのかどうかわからなくなる レビュー観点があいまい ぼんやりレビューが多く、問題の本質について掘り下げができていない 「ダメなレビュー運営シナリオ」の半分以上が当てはまっている レビューアが忙しいときは大雑把になる レビューアが不機嫌だと細かいところまで指摘する レビューチェックリストの項目が多すぎて広く浅いレビューになる レビューチェックリストの項目が多すぎて非効率なレビューになる レビューが属人的になっている 人格否定をしてしまう 作成者にレビューアが攻撃的になる レビューが形式的になっている レビューの効率がよくない 作成者のスキルによってレビューの良し悪しが決まる レビューの指摘コメントが意図しない方向に捉えられる（プレッシャーとか） レビューのやり方がわからないので思いつきでやってしまう レビューの質がレビューアの能力に依存している 経験（失敗を含む） レビューアの能力によって問題の抽出が変わる 毎回同じような問題が上がる しゃべりがうまいのドキュメントは、レビューでOKになってもよくわからないものが多い 関係性 分析 レビューの困り事・問題点 2009年～全国各地で収集 JaSST‘19北陸 そのレビュー、大丈夫ですか？ ～現状レビューの問題発見・解決 補足資料：http://www.jasst.jp/symposium/jasst19hokuriku/pdf/S2-2.pdf
14. 分析は大 変・実施 されない 日程調整が 不調・大変 対象物事 前提出なし or遅れ 作り方、内 容ばらつき 成果物がレ ビューする に値しない 状態 自己チェック なし・チェッ ク不足 レビュー 工数が取 れない レビューへの モチベーショ ンが低い 場面に適した レビュー形式 がわからない 何でもレ ビュー対象 になっている 曖昧 指摘 形式的・ 形骸化 事前 チェック なし 適切なメ ンバーが 揃わない 参加者 が多い 有識者が 多忙で不 参加 有識者が 少ない スキル差 が大きい レビュー ア育成が 進まない ドメイン・ レビュー 知識不足 チェックリスト が形骸化 チェックリスト を使っても指 摘が漏れる チェック項目 が多い・使わ れない 結果がレビューア に依存する いつも同じ 欠陥ばかり 軽微な指 摘ばかり 欠陥・問題 の見逃し 指摘を適 切に伝え られない 回答できない 自己 防衛 思いつき・ 観点がバ ラバラ 意見・指摘が偏る /発散する 参加者が 寝る・発 言しない 声大者独壇場 脱線 する 怒られる、説教 等ツライ 説明会になる 知見を 蓄積で きない 指標値の 収集・分析 が未定着 生産性が 低い・効果 が不明 時間が かかる 落としどころ 不明で何度 も繰り返す 指摘漏れがない か確信できない OK/NG判断 が困難 欠陥指摘 が少ない 議論したが 未修正 指摘のみ修 正し，全体 確認や横展 開なし 記録作成に 時間がかかる 議事内容 がばらばら 議事録が 残らない レビューが 進捗のボト ルネックにな りやすい レビューの 重要性・必 要性が広ま らない 後工程で 欠陥が発 見される 1 2 3 1 2 2 3 2 4 6 4 6 6 3 5 5 14 1 レビューへの モチベーショ ンレベル 対象成果物の質 ・状態 事前配布 の有無 工数 余裕度 対象量 数･規模 調整 努力量 要員の 知識･ス キルの 状態 レビュー訓 練と効果 経験･知 見の蓄積 状態 参加者 の適切 性 ミーティングの状態 (場･感情･時間等) レビュー観 点の適切性 指摘の 質と量 修正の 適切さ 計画の 適切さ レビュー の効果・ 以降への 影響 記録の有無 ・状態 指標値収集･ 分析の状態 知見の 蓄積量 レビュー の重要性 認識 事前レ ビュー の有無 結果の有 識者依存 度 指摘伝 達の良 し悪し Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 結果への 納得度
15. 15 レビューへの モチベーショ ンレベル 対象成果物 の質・状態 事前配布 等準備の 有無 工数余裕度 調整 努力量 要員の知 識･スキル の状態 レビュー訓 練の有無と 効果 経験･知見 の活用度 参加者の 適切性 ミーティングの状態 (場･感情･時間等) レビュー観 点の適切性 レビュー指 摘の質と量 修正の 適切さ 計画の 適切さ レビュー 効果･生産 性･以降へ の影響 記録有無 ･状態 レビュー の重要性 認識 事前レ ビュー の有無 結果の有識 者依存度 指摘伝達 の質 結果への 納得度 フォローの有無･質 1 2 2 1 3 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved レビュー効果図式ライクなもの 正負の関係性を表現していませんのでご注意を 結果･指標値 収集･分析の 有無･状態 知見のま とめ方･蓄 積状態 2 3
16. レビューの成功要因は レビューの問題を解決するのか？ 16 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
17. 17 レビューへの モチベーショ ンレベル 対象成果物 の質・状態 事前配布 等準備の 有無 工数余裕度 調整 努力量 要員の知 識･スキル の状態 レビュー訓 練の有無と 効果 経験･知見 の活用度 参加者の 適切性 ミーティングの状態 (場･感情･時間等) レビュー観 点の適切性 レビュー指 摘の質と量 修正の 適切さ 計画の 適切さ レビュー 効果･生産 性･以降へ の影響 記録有無 ･状態 レビュー の重要性 認識 個別レ ビュー の有無 結果の有識 者依存度 指摘伝達 の質 結果への 納得度 フォローの有無･質 1 2 2 1 3 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved S5小分割レビュー H4小分割レビュー H3-1 適切な時間割当 S1目的定義 S2-1適切なレビュータイプ選択 S7ｽｹｼﾞｭｰﾙ通知 S8レビュー プロセス支援 S9品質･テスト ポリシーに統合 S4 Checklist 最新維持 S3-1適切なレビュー技法選択 H1適切な 要員の関与 H2 早期テスト準備による貢献 H5 検出欠陥の客観 的確認･識別･対処 H7-1信頼できる雰囲気で実施 H7-2レビュー結果を人的 評価に使用しない H8発言の受取に注意 (退屈感、憤り、敵意) H9高度レビュータイプ へトレーニング提供 H6 有意義な時間となる 適切なマネジメント H3-2 詳細なレビュー レビュー効果図式上に成功要因をマッピング S3-2適切なレビュー技法使用 S2-2適切なレビュータイプ使用 結果･指標値 収集･分析の 有無･状態 知見のま とめ方･蓄 積状態 2 3 H10学習とプロセス 改善文化の醸成
18. 〇〇作成 例：基本設計 成果物 案 INPUT Review 結果サマリ Review 計画 Review 開始 個々の Review 懸念事項共有･分析 修正･報告 Review 計画 1 2 3 4 5 0 個別 Review 結果 Review 報告 集合会議 結果評価 開始 基準 終了 基準 参加者選定 Manager Quality Policy Test Policy Review Check list Test Engineer 修正 報告 成果物 □有能なファシリテータが運営する □有識者を含めた適切なメンバーが参画する □対象規模・難易度に対して適切な時間実施される □全員が参画し、集中して建設的な議論がなされる □相乗効果でより多くの有効な指摘・コメントが得られる □修正が必要な欠陥等が漏れなく記録される □指摘事項を確定し、ステータスを割り付ける □終了基準に照らして今後の取扱いを判定する □作成者は結果を理解し、適切に・前向きに受け取る □レビューをふりかえり、今後の実践方法を磨く □レビューするに値する対象 成果物案が提出される □集合前に個々のレビュー を実施して結果を記録する □個々のレビュー結果が収 集され、集約・共有される □迅速に、適切に成果物を修正する □必要な場合、修正をフォローする □終了基準に照らして完了判断する □質の高い成果物が完成する □レビュー目的・範囲・観点等を決める □適切なレビュータイプ、技法を選定する □有識者を含めた適切なメンバーを選定する □時間・工数を見積り、日程等を決定する □開始基準、終了基準を定める □開始基準に照らして開始を判定する □必要な資料が事前配付される □実施に際しての疑問が解消される □Checklist等を活用し、必要な観点を 整理する □関係者は全員日程、レビューの進め 方、役割を理解し、適切に実践できる 状態である ＜Goal＞ □レビューの目的を達成している □レビューの時間、工数当たりの効果・成果が高い □以降の作業での問題発生や再作業がほとんどない □参加者がレビューの効果や価値を実感している 終了 基準 □観点や欠陥情報を蓄積 し、活用しやすくまとめ最 新状態を維持する Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 欠陥DB レビュー成功のためのシナリオ（例） □レビューのよりよい実践を支援する □現状評価・把握して改善を促進する 18
19. Manager Quality Policy Test Policy Review □レビューのよりよい実践を支援する □現状評価・把握して改善を促進する Check list □観点や欠陥情報を蓄積 し、活用しやすくまとめ最 新状態を維持する 欠陥DB 〇〇作成 例：基本設計 成果物 案 INPUT Review 結果サマリ Review 計画 Review 開始 個々の Review 懸念事項共有･分析 修正･報告 Review 計画 1 2 3 4 5 0 個別 Review 結果 Review 報告 集合会議 結果評価 開始 基準 終了 基準 参加者選定 Test Engineer 修正 報告 成果物 □有能なファシリテータが運営する □有識者を含めた適切なメンバーが参画する □対象規模・難易度に対して適切な時間実施される □全員が参画し、集中して建設的な議論がなされる □相乗効果でより多くの有効な指摘・コメントが得られる □修正が必要な欠陥等が漏れなく記録される □指摘事項を確定し、ステータスを割り付ける □終了基準に照らして今後の取扱いを判定する □作成者は結果を理解し、適切に・前向きに受け取る □レビューをふりかえり、今後の実践方法を磨く □レビューするに値する対象 成果物案が提出される □集合前に個々のレビュー を実施して結果を記録する □個々のレビュー結果が収 集され、集約・共有される □迅速に、適切に成果物を修正する □必要な場合、修正をフォローする □終了基準に照らして完了判断する □質の高い成果物が完成する □レビュー目的・範囲・観点等を決める □適切なレビュータイプ、技法を選定する □有識者を含めた適切なメンバーを選定する □時間・工数を見積り、日程等を決定する □開始基準、終了基準を定める □開始基準に照らして開始を判定する □必要な資料が事前配付される □実施に際しての疑問が解消される □Checklist等を活用し、必要な観点を 整理する □関係者は全員日程、レビューの進め 方、役割を理解し、適切に実践できる 状態である 終了 基準 S1目的定義 S5小分割レビュー H4小分割レビュー H3 適切な時間割当に よる詳細なレビュー S2適切なレビュータイプ選択 S7ｽｹｼﾞｭｰﾙ通知 S8レビュープロセス支援 S9品質･テスト ポリシーに統合 S4 Checklist最新維持 S3適切なレビュー技法選択 H1適切な要員の関与 H2 早期テスト準備 による貢献 H5-2 検出欠陥の対処 H7-1信頼できる雰囲気で実施 H7-2レビュー結果 を人的評価に使 用しない H8発言の受取に注意(退屈感、憤り、敵意) H9高度レビュータイプ へトレーニング提供 H10学習とプロセス改善文化の醸成 H6 有意義な時間となる適切なマネジメント S3適切なレビュー 技法使用 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved ＜Goal＞ □レビューの目的を達成している □レビューの時間、工数当たりの効果・成果が高い □以降の作業での問題発生や再作業がほとんどない □参加者がレビューの効果や価値を実感している レビュー成功のためのシナリオへの要因マッピング H5-1 検出欠陥の客観的確認･識別 19 H3 適切な時間割当による詳細なレビュー H3 適切な時間割当 H10学習とプロセス改善文化の醸成 H1適切な要員の関与 S1目的定義
20. 〇〇作成 例：基本設計 成果物 案 INPUT Review 結果サマリ Review 計画 Review 開始 個々の Review 懸念事項共有･分析 修正･報告 Review 計画 1 2 3 4 5 0 個別 Review 結果 Review 報告 集合会議 結果評価 開始 基準 終了 基準 参加者選定 Manager Quality Policy Test Policy Review Check list Test Engineer 修正 報告 成果物 □有能なファシリテータが運営する □有識者を含めた適切なメンバーが参画する □対象規模・難易度に対して適切な時間実施される □全員が参画し、集中して建設的な議論がなされる □相乗効果でより多くの有効な指摘・コメントが得られる □修正が必要な欠陥等が漏れなく記録される □指摘事項を確定し、ステータスを割り付ける □終了基準に照らして今後の取扱いを判定する □作成者は結果を理解し、適切に・前向きに受け取る □レビューをふりかえり、今後の実践方法を磨く □レビューするに値する対象 成果物案が提出される □集合前に個々のレビュー を実施して結果を記録する □個々のレビュー結果が収 集され、集約・共有される □迅速に、適切に成果物を修正する □必要な場合、修正をフォローする □終了基準に照らして完了判断する □質の高い成果物が完成する □レビュー目的・範囲・観点等を決める □適切なレビュータイプ、技法を選定する □有識者を含めた適切なメンバーを選定する □時間・工数を見積り、日程等を決定する □開始基準、終了基準を定める □開始基準に照らして開始を判定する □必要な資料が事前配付される □実施に際しての疑問が解消される □Checklist等を活用し、必要な観点を 整理する □関係者は全員日程、レビューの進め 方、役割を理解し、適切に実践できる 状態である ＜Goal＞ □レビューの目的を達成している □レビューの時間、工数当たりの効果・成果が高い □以降の作業での問題発生や再作業がほとんどない □参加者がレビューの効果や価値を実感している 終了 基準 □観点や欠陥情報を蓄積 し、活用しやすくまとめ最 新状態を維持する Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 欠陥DB レビュー成功要因の効果は [67点/100点] □レビューのよりよい実践を支援する □現状評価・把握して改善を促進する 20
21. レビューの成功とは？ レビューの成功に最も重要で外せない要因 21 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
22. レビューが成功した状態とは？（一例） この中でレビューの成功に最も重要で外せない要因はどれ？ • レビューの目的を達成している。 – 有効な指摘、必要な欠陥検出が行われる／致命的な見逃しがない（少ない） – レビューを通じてレビュー対象やレビュー実践方法への理解が促進される • レビューの効果を実感し、レビューに対するモチベーションが高くなる。 – 関係者がレビューの効果と重要性を認識している • 作成者が結果に納得し、確実に成果物の修正を実施する • レビューへの参画、実践に前向きになる • さらに良い結果を少ない手間、時間で獲得する準備を行っている。 • レビュートレーニングの実践 • 自組織、自チームのレビュー実践バリエーションの整備、更新 • 検出欠陥情報DBやレビュー観点群の整備、更新 など 22 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
23. 23 レビューへの モチベーショ ンレベル 対象成果物 の質・状態 事前配布 等準備の 有無 工数余裕度 調整 努力量 要員の知 識･スキル の状態 レビュー訓 練の有無と 効果 経験･知見 の活用度 参加者の 適切性 ミーティングの状態 (場･感情･時間等) レビュー観 点の適切性 レビュー指 摘の質と量 修正の 適切さ 計画の 適切さ レビュー 効果･生産 性･以降へ の影響 記録有無 ･状態 結果･指標値 収集･分析の 有無･状態 知見のま とめ方･蓄 積状態 レビュー の重要性 認識 事前レ ビュー の有無 結果の有識 者依存度 指摘伝達 の質 結果への 納得度 フォローの有無･質 1 2 2 1 3 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved レビュー効果図式 この中でレビューの成功に最も重要で外せない要因はどれ？ 2 3
24. JaSST’16東京 事例発表 レビュー目的・観点設定の効果と課題 http://www.jasst.jp/symposium/jasst16tokyo/pdf/A2-1.pdf 24 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
25. レビュープロセス レビュー成功要因 有効指摘獲得への直接的要因 有効指摘獲得への環境的要因 [1]レビュー計画 S1目的定義 〇（観点設計のベース） S2-1適切なレビュータイプ選択 〇 S3-1適切なレビュー技法選択 〇 H1適切な要員の関与 〇（有識者の参画） [2]レビューの開始 S7スケジュール通知 〇 H9高度レビュータイプへトレーニング提供 〇（観点設計・欠陥検出方法） 〇 [3]個別レビュー H2 早期テスト準備による貢献 〇（テストベースのレビュー） H4・S5小分割レビュー 〇 S6十分な準備時間 〇 H3 適切な時間割当による詳細なレビュー 〇 S3-2適切なレビュー技法使用 〇（レビュースクリプト検討） 〇 [4]懸念事項の共有と分析 S2-2適切なレビュータイプ使用 〇 S3-2適切なレビュー技法使用 〇（レビュースクリプト検討） 〇 H6 有意義な時間となる適切なマネジメント 〇（探索的ファシリテーション） 〇 H7-1信頼できる雰囲気で実施 〇 H8発言の受取に注意 〇 H5-1検出欠陥の客観的確認･識別 〇（検出事項の解像度アップ） [5]修正と報告 H5-2検出欠陥の対処 （〇） H10学習とプロセス改善文化醸成 △ 25 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
26. 有効な指摘、必要な欠陥検出が行われる／致命的な見逃しがない（少ない）のために 適切な要員の関与 • 有識者の参画 – 有識者＝有効な確認と指摘ができる要員 – “多忙な方”なのでスケジュール調整が難しい＝ボトルネックに • 有能なファシリテータによるレビュー会議運営 – タイムマネジメントされたスムーズな会議運営もさることながら、参 加者それぞれが持つ特徴を引き出し、相乗効果を獲得する質問や 問いかけ（観点の提供や掘り下げ）アプローチが重要 ★いかにして有識者でなくても確認できる領域を広げるか、どうやって有 能なレビューアやファシリテータを育てるかが現状のレビューの課題 26 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
27. 有効な指摘、必要な欠陥検出が行われる／致命的な見逃しがない（少ない）のために 適切なレビュー技法の使用 テスト技術者資格制度 Foundation Levelシラバス 3.2.4 レビュー技法の適用 レビュー技法名 技法の概要 アドホック レビューアは、このレビューに関するタスクのガイダンスをほとんどまたはまったく提供 されない。一般的に、レビューアは作業成果物を順番に読んで懸念事項を識別するご とに記録に残す。 チェックリストベース レビューアはレビューの開始時に（例えばファシリテーターにより）配布されるチェックリ ストを使用して懸念事項を検出する。レビューチェックリストは、経験から導出した起こり える欠陥に基づく一連の質問を列挙したものである。 シナリオとドライラン 作業成果物を読むための構造化されたガイドラインをレビューアに提供する。レビュー アはシナリオベースドレビューを使用して、（作業成果物がユースケースなど適切な形 式で文書化されている場合）作業成果物の期待する使い方に基づいて、作業成果物に 対して「ドライラン」を行う。 ロールベース レビューアは個々のステークホルダーの役割の観点から作業成果物を評価する。 パースペクティブベース レビューアはそれぞれに異なるステークホルダーの観点でレビュー活動を行う。レ ビュー対象の作業成果物から各レビューアの役割で導出する成果物を作成する。 27 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
28. チェックリストベースの例 ガイドワードによるレビュー ＜ガイドワード例＞ • 類似の意味を持つ複数の言葉 例：完了・終了 警報・警告 • 複数の意味を持つ一つの言葉 例：電源オフ/スタンバイ • 非対称な機能遷移 <：上位遷移 >：下位遷移 • 条件指定：～のとき、～でない時、～の際、～場合 • 否定表現：～しない、～ではない • 紛らわしい：詳細度が低い ＜効果的実践法＞ □ツールで漏れなく検出する →そして判定・処理へ □発生した不具合の内容を継続して蓄積・ 整理し、以降のレビューで活用する 出典： 鈴木三紀夫氏 意地悪漢字 28 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved http://www.jasst.jp/archives/jasst10s/pdf/S3-9.pdf
29. キーワードベースドレビュー －ドキュメントのあいまいさや不備に着目したレビュー手法 観点 具体的記述例 確認ポイント 数値的表現 から、～、以上、以下 数値の境界が明確に切り分けできるか 時間的表現 あとで、先に、事前に、のちほど、常に、いつも、常時、 逐次、一定 時間が明確に特定できるか 深さ・長さの表現 消去する、残す、保持する、制限する、記憶する 程度（レベル）が明確に特定できるか 実体のない表現 管理する、運用する、処理する、実行する 具体的に実態を表す内容に展開できるか 条件指定表現 とき、以外、の際 指定条件以外の条件を記述しているか 否定 しない、できない、 実施すべき内容が並列に記述されているか 受動 される、と思われる 主体が明確に特定できるか 不明瞭 くらい、とか、みたいな、的には、そらく、ほぼ、ような、 できるだけ 具体的な表現が追記されているか 形容表現 多、少、速、遅 数値仕様として特定できるか 指示表現 これ、あれ、それ、どれ。そこ、この 指示先が特定できるか 29 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 高品質ソフトウェア技術者交流会現場改善技法検討分科会SEチーム http://www.jasst.jp/archives/jasst10e/pdf/C2-3.pdf
30. パースペクティブベースドリーディング レビューアが持つロール（下記事例は設計者・テスト担当者）が導出する成果物を作成して確認する 30 状態遷移図の作成・追跡による確認 ※シナリオの併用 も効果的 レビュー対象成果物 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
31. 入力・遷移元・イベント 判定・処理 出力・遷移先 保温状態 下記のいずれかで遷移する (1)エラー検知 (2)蓋センサーOFF (3)全水位センサーOFF アイドル状態 事前条件 事後条件 ？？？ ？？？ 31 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved パースペクティブベースドリーディング 早期テスト準備による貢献 へのアプローチ事例 テストケースが記載できるかを テストケースフレームに入れて 確認してみる
32. レビュー（リーディング）技法の特徴（実験結果考察） 32 項目/技法 アドホック（Ad-hoc） チェックリスト（CBR） シナリオ（SBR）～ドライラン 特徴 ・無計画、思いつき対応 ・未確認、見逃しが多くなる可能性大 ・新発想獲得の可能性 ・網羅に向くため見逃しを防止できる可能性 大 ・項目毎に個別確認することが多く時間がか かる ・利用者、設計者などの視点で、流れで確認 する ・上流工程で使用されることが多い 効果決定 要因 担当者のスキル、経験に結果が大き く左右される チェックリストの質と活用方法に結果が左右 される 設定するシナリオの質に結果が左右される コミュニケーション の影響 結果・効果に大きな影響を与える 結果・効果に影響を与える場合がある 結果・効果への影響を受けにくい 強み 担当者が持つノウハウ・直感による 確認が可能・時間がかからない ・チェック項目を網羅しやすい ・スキルのばらつき影響を受けにくい 利用者、設計者等様々な視点で、目的達成 の可能性に対する確認が可能 弱み ・確認漏れ、重複、表面的確認に終 始しがちになる 時間がかかる／形式的確認となる可能性あ り／チェック項目以外に目がいかなくなる可 能性あり／チェックリストの作成、維持が大 変 表現形式、スタイルの良し悪しなどの基本的 事項の確認が抜けてしまう可能性あり／想 定利用者のコンテキストと合わない可能性あ り／不整合を見逃す可能性あり 事前準備等考慮 事項 スキル・経験ある担当者が対応する 事前にレビュー対象に必要なチェック項目 の選定や追加・カスタマイズを行うことが必 要 想定利用者とその利用状況を具体化し、利 用者の立場に立って行う 効果的 活用法 別途網羅的確認を行いつつ、ピンポ イントでこの技法を活用するのが効 果的 チェック項目の選定・追加・カスタマイズした 上で網羅的確認に活用する 上流工程を中心に、チェックリストと併用する ことで効果が期待できる 立場で見る「Perspective/Role Based Reading」やユースケースで見る「Usage Based Reading」などがある Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
33. レビュー技法の原理 • 立ち位置を変える ロールベース、パースペクティブベース • 狙って撃つ チェックリスト、長文、NGワード（キーワード） • 表現方法や捉え方を変えてみる 読み手、文章→図表、機能→状態、機能作り込み→利用の仕方 • リスクから逆算してみる エラー推測、発生しそうな問題（例：過去トラ） 33 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
34. レビューで有効な確認と指摘をするために 34 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
35. レビュー指摘に至るまでの道筋 有効な指摘からのリバース例 35 (4)どのような目的を達成 するためのものですか？ (3)それはどのような観点 と言えますか？ (2)どのように調べた結果ですか？ (1)レビューで検出した内容 売れるのか？ ターゲットユーザーにヒッ トするか ターゲットユーザーの立ち位置で「備えるべき特徴 」が実現できているかを確認 単独タイマ機能でコストが高くなるなら必要 ないのでは？（100均ショップで分秒表示タ イマ購入可能） ターゲットユーザーの立ち位置で、企画書「備える べき特徴」が実現できているかを確認 ターゲットユーザ―の特徴からするとミルク モードは必要ないのでは？ 安全に、快適に利用でき ること 安全性、利用しやすさ（ 快適性・使用性） 利用の流れに沿って戸惑ったり、疑問が生まれた り、危険になることはないかを確認 （持ち運び、設置時） 筐体の大きさ、形状、重さ、取っ手の場所・ 持ちやすさ、がわからない（持ち運ぶ際の快 適さが確保されているか） 同上（利用開始時） 2-5解除ボタン デフォルト コンセントつなぐ ロック解除 →危険性があるのでロックすべ きでは？ 同上（利用開始時） ふた 閉めると沸騰モードに遷移するのは わかりにくい／意図しない沸騰は避けたい 同上（モード単位の利用時） ミルクモード100℃→追い炊き→60℃になる まで冷ます 60℃になったら知らせる機能 はいらない？ システム設計の実施可 能性 条件外の動作や振る舞 い 特定条件下で動作や振る舞いが指定された場合 、条件以外の動作や振る舞いがあるかを確認 4P内部構成記載～センサーがONの時の記 述が複数ある→OFFの時どうなるのか不明 レビュー目的 レビュー観点 レビューケース／ レビュー手順・スクリプト レビューコメント・指摘事項 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved レビュー技法の適用
36. 儲かるかな？ 開発プロジェクト 〇〇システム 主な観点は立ち位置で変わる 利害関係者の立ち位置と関心事(例) 開発プロジェクトチーム システムオーナー組織 (発注者) 保守・運用メンバー リリース 協力会社 協力会社 外部ベンダー 36 役に立つ のかな？ 使いやすい のかな？ 実利用者 運用しやす いのかな？ 保守しやす いのかな？ 納期遵守？ 採算は？ 顧客に評価 される？ 機能は 動く？ 非機能 要件は？ 利用者 評価は？ 雇い主の 評価は？ 提供部品の 評価は？ テストに パスする？ この機器で 使える？ セキュリ ティは？ 発売タイミ ングは？ Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
37. モノゴト に対する 認識 モノゴト に対する 判断 行動 結果 成果 (価値提供度) 人は見たいもの しか見ない 立ち位置で視野と 見え方が異なる 立ち位置によって関心 事が異なる 事業 業務 IT システム 距離 幅･深み･奥行 開発･運用･ 保守Process 認識の差異 判断の差異 行動の差異 システム･ソフトウェア は目に見えない 視野 視野 視野 視野 モノゴトの表現･共有方 法の自由度が高い 認識の壁によるサイロ化 認 識 の 壁 認 識 の 壁 認 識 の 壁 実利用 レビューの役割 立ち位置の視野の違い等による 悪影響を最小化する Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 37
38. レビュー観点導出アプローチの例 • プロダクトの目的・背景、要求事項（機能・非機能）、特徴の把握 • 利害関係者とその関心事の洗い出しと重要度設定 – 関係者例：実利用者、オーナー、開発者、テスト担当、運用保守担当、企画者、マーケッター – 実利用者関心事例： 課題解決、自環境での利用可能性、利用しやすさ、コストや手間、利用によるリスク • プロダクトリスクの洗い出し • システム外部との関係性、機能、動作・処理順～内部物理構成、運用方法等の把握 – Context View/Functional View/Process View/Physical View/Operational View など • 発生しそうな障害やバグの洗い出し – 過去トラ（内部・外部）、複雑な構造やつくり、利用者がやりそうなミス、顧客クレームからの類推、担当者の不安、複数 回の変更発生個所 など • 以上の結果を整理し、観点群として体系化 • 忘れ物チェック – システム・ソフトウェア品質特性や利用時の品質、非機能グレード など • 対象ドキュメントとして必要な記述内容の把握 – 要求仕様書、基本設計書、テスト仕様書、操作説明書、、、、、 38 毎回ゼロから作成するのは 大変なので個人やプロダク ト単位でレビュー観点図を 作っておくと便利 ※ただし、観点の形式チェック のような使い方はご法度 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
39. 観点設定優先度（おおまかな方針） 対象の規模により“一度にすべて”が無理な場合が多い 39 認識できる 理解できる レビュー共通（レビュー自動化へ） 製品・サービスの特徴とフェーズにより取捨選択 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 表記方法の参考文献：テスト設計チュートリアル テスコン編資料(講義編) サービス領域（提供） システム／ソフトウェア領域 サービス領域（利用） 曖昧 不明確 矛盾 基本・形式 規約 不遵守 不統一 多義表現 機能 未決 誤字 脱字 衍字 合目的性 有効性 抽象表現 非機能 判読性 NG表現 リスク 回避性 正確性 適切性 ドキュメント特性 使用性 性能 信頼性 互換性 セキュリティ 効率性 利用状況 適合性 保守性 運用性 保守性 信頼性 画面 構造/論理 Ｉ / Ｆ 移植性
40. システム運用･保守 観点の関係性（例） 40 有効性 効率性 リスク回避性 満足性 利用状況網羅性 可用性 性能･拡張性 保守･運用性 移行性 システム環境･ エコロジー セキュリティ 機能 機能適合性 性能効率性 互換性 使用性 信頼性 保守性 移植性 セキュリティ システム/ソフトウェア特性 システム利用時/利用後 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
41. 保守性が悪い スピードが重視される領域 保守性が悪いと競争力が低下する 41 保守･運用性 機能 機能適合性 性能効率性 互換性 使用性 信頼性 保守性 移植性 セキュリティ 余裕度がなくなると 捨てられる優先度 開発者が最も尽力 する優先度 中味がわかりにくい テストしにくい 変更しにくい 欠陥見逃し が増える 作業効率 が落ちる 障害が発生 しやすい 障害対応が 必要 改修スピード が鈍る 改修リードタイム長くなる MTBF・MTTR悪化 デプロイ頻度低下 変更成功率低下 つくりが複雑 運用･保守 チームが不幸 利用者が不幸 →離れていく オーナー企業 が不幸 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
42. レビューメタ観点図活用イメージ 42 要求定義 設計 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 取捨選択 要求仕様書 Review 設計書 Review Review 結果 開発の背景・目的 製品特徴など 要求仕 様書
43. 役立つのか？ 売れるのか？ 43 マインドマップによるレビュー観点設計事例 必要なレビュー観点等を明確化＝狙いを定めてレビューを行う Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
44. △改善前（Before） •改善後（After） 発見可能Phase（想定） 計 実装・UT IT ST・OT C/O後 1 3 5 7 検 出 効 果 効果大 主対象： 要件抜け・誤り 5 30 ↓ 335 効果中 主対象： 機能上のバグ （誤植による） 3 75 ↓ 93 効果小 主対象： 誤字・脱字・衍字 規約違反 1 16 ↓ 8 計 35→19 18→0 40→340 28→77 121→436 指摘件数： △23 → •24 44 △が左下 （指摘価値が低 い）に集中 •が右上 （指摘価値が高い） に集中 目的・観点設定による典型的な指摘変化の例 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
45. レビュー観点設定なし→ありの効果 2012～2020年に実施した全ワークショップ（11社30チーム）実績から算出 45 観点設定 なし 観点設定 なし 観点設定 あり 観点設定 あり Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
46. レビューの成功とその先 46 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
47. レビューのキキメを得るために http://www.jasst.jp/symposium/jasst19niigata/pdf/S1.pdf 【対応方針1】 できるだけ（無駄な）レビューをしない – 1-1.レビューすべきものだけをレビューする • 1-1-1.レビュー以前の問題が作成者の責任で解決されたものだけをレビューする • 1-1-2.限られたリソースで効果を発揮するためにレビュー対象・箇所のグラデーションを特定する – 1-2.集合形式のレビュー時間を最小化する • 1-2-1. 個別レビューで8割方の決着をつけ、無駄のない集合レビューで結果をサマリする – 1-3.できるだけリアルタイムフィードバックに近づける • 1-3-1.一度のレビュー規模を小さくし、対象作成作業とレビューを連携させる • 1-3-2.事前すり合わせ→[試作→レビュー＆早めのフィードバック]を繰り返して完成させる 【対応方針2】 ぼんやりレビューを行わない – 2-1.目的を定め、効果的に達成するメンバー、レビュータイプ、技法を選択する – 2-2.必要なレビュー観点を明確化＝狙いを定めてレビューを行う – 2-3.作成状況や成果物の特徴等から兆候を察知し、仮説を立ててアプローチを決める – 2-4.人間特性を考慮してレビューのやり方を設計する 【対応方針3】 レビューをやりっぱなしにしない – 3-1.完了判定とフォローアップによりリスクを識別し、修正を確実に完了させる – 3-2.ふりかえりにより改善事項を明確にし、知見を蓄積して同じ失敗を繰り返さない 47 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
48. レビューパフォーマンス改善 階段の上がり方を判断する • 今持っている力を最大限発揮する – 実施環境面、マネジメント面の施策から開始する – 施策例：小さな単位で作成→レビューを行う、開始基準による運営、有能なファ シリテータ―による運営、簡潔なグランドルールの採用、事前配付による個別チ ェック、ジャイアン独演会の回避、レビュー直後のふりかえり実践（運営方法の 継続改善） など • 今持っている力をさらに向上させる – 意図的に狙ってレビューする力を向上させる – 施策例：レビュー観点設計力を鍛える、レビュー観点図作成と継続更新、検出 した欠陥の分析とレビュー直後のふりかえり実践（欠陥検出方法の磨き込み） など 48 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
49. レビューファーストによるシフトレフト 49 手戻り 障害対応 実作業 成果物 案 成果物 レビュー レビュー 結果 成果物 修正 成果物 実作業 成果物 案 成果物 レビュー レビュー 結果 成果物 修正 成果物 レビュー 観点 手戻り 障害対応 作業要件･ 注意事項 実作業 成果物 案 成果物 レビュー レビュー 結果 成果物 修正 成果物 レビュー 観点 手戻り 障害対応 進化 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved ★RDD： Review Driven Development
50. レビューファースト 50 テスト テスト 分析 テスト 設計 テスト 実装 テスト 実行 テスト 完了 テスト設計 テスト実行 この部分を要求定義や設計段階に一緒に行う ＝テストファースト レビュー レビュー 分析 レビュー 設計 レビュー 実装 レビュー 実行 レビュー 完了 レビュー設計 レビュー実行 この部分を対象作業着手前に一緒に行う ＝レビューファースト Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
51. レビューとテストの協調・連携 レビューが(テストに比べて)検出可能な欠陥例 テスト技術者資格制度 Foundation Levelシラバス 3.1.3 静的テストと動的テストの違い より • 要件の欠陥 – 例えば、不整合、曖昧性、矛盾、欠落、不正確性、冗 長性 • 設計の欠陥 – 例えば、非効率なアルゴリズムやデータベース構造、 高い結合度、低い凝集度 • コードの欠陥 – 例えば、値が未定定義な変数、宣言済の未使用変数 、到達不能コード、重複したコード • 標準からの逸脱 – 例えば、コーディング標準の不遵守 51 • 正しくないインターフェース仕様 – 例えば、呼び出し側のシステムと呼び出される側のシ ステムで異なる単位の使用 • セキュリティの脆弱性 – 例えば、バッファオーバーフローが発生する可能性 • テストベースのトレーサビリティ／ カバレッジ不十分or不正確 – 例えば、受入基準に対するテストケース欠落 • 保守性欠陥のほとんど – 例えば、不適切なモジュール化、低いコンポーネント 再利用性、分析困難で新たな欠陥混入なしでの修正 困難なコード Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
52. レビュー×テストによるQAイメージ 52 設計 実装 UT IT ST/OT Test 設計 Review 設計 Test 設計 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 開発の背景・目的 製品特徴など 要求定義 Review 設計 Test 設計 取捨選択 Review QAアーキテクチャ 取捨選択 要求 仕様書 Review Review
53. 「いつも同じやり方」 「ぼんやり何となく実施する」 「参加するのが辛い」 「効果が実感できない」 このようなレビューから脱却して、みんなで価値あ るシステム／ソフトウェアを世に送り出しましょう！ 53 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved ご清聴ありがとうございました！
54. 参考文献 • ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf • そのレビュー、大丈夫ですか？～現状レビューの問題発見・解決（JaSST‘19北陸 招待講演）補足資料 http://www.jasst.jp/symposium/jasst19hokuriku/pdf/S2-2.pdf • レビューのキキメを得るために（JaSST’19新潟 基調講演） http://www.jasst.jp/symposium/jasst19niigata/pdf/S1.pdf • レビュー目的･観点設定の効果と課題（JaSST’16東京 事例発表） http://www.jasst.jp/symposium/jasst16tokyo/pdf/A2-1.pdf • 意地悪漢字 http://www.jasst.jp/archives/jasst10s/pdf/S3-9.pdf • キーワードベースドレビュー －ドキュメントのあいまいさや不備に着目したレビュー手法 高品質ソフトウェア技術者交流会現場改善技法検討分科会SEチーム http://www.jasst.jp/archives/jasst10e/pdf/C2-3.pdf • テスト設計チュートリアル テスコン編資料(講義編) http://aster.or.jp/business/contest/doc/2021_tescon_V1.0.0.pdf • システム開発の幸せなゴールとは？システムの関係者がみな幸せになる条件（Developers Festa2020） https://www.youtube.com/watch?v=kVtd8bL9qrM 54 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved