ソフトウェアテストシンポジウム2021四国 招待講演資料 http://www.jasst.jp/symposium/jasst21shikoku/report.html
「レビューの成功要因」はどの程度のキキメがあるの？1レビューのキキメ～Part2Software Quasol ＠HBA 安達 賢二https://www.softwarequasol.com/[email protected]ソフトウェアテストシンポジウム(JaSST)2021四国Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
View Slide
安達 賢二（あだち けんじ） [email protected]株式会社HBA 経営管理本部 Exective Experthttp://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テスト技術者資格制度 Foundation Levelシラバス3.2.5 レビューの成功要因レビューを成功させるための組織的な要因• レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。• 達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。• レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法やロールベース技法など）を1つ以上使用する。• チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。• 欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなドキュメントは小さく分割して記述およびレビューする。• 参加者に十分な準備時間を与える。• レビューのスケジュールは適切に通知する。• マネージャーがレビュープロセスを支援する（例えば、プロジェクトスケジュールでレビューに十分な時間が割り当てられるようにする）。• レビューは、社内の品質、および/またはテストのポリシーに統合するレビューを成功させるための人的な要因• レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパースペクティブを持ち、対象のドキュメントを使うことがある人たち）。• テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテストを早期に準備できると、レビューアとして価値がでる。• 参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。• レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビューは対象を小さく分割して実施する。• 見つかった欠陥は客観的な態度で確認、識別、対処をする。• ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。• レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。• 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。• 特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。• 学習とプロセス改善の文化を醸成する。レビューの問題構造本当に解決するのか？Copyright © Kenji Adachi@Software Quasol , All Rights ReservedJSTQB
コンテンツ• レビューの成功要因• レビューの問題構造• レビューの成功要因はレビューの問題を解決するのか？• レビューの成功とは？• レビューの成功とその先4Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューの成功要因5Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューを成功させるための組織的な要因テスト技術者資格制度 Foundation Levelシラバス 3.2.5 レビューの成功要因S1：レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。S2:達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。S3：レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法やロールベース技法など）を 1 つ以上使用する。S4：チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。S5：欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなドキュメントは小さく分割して記述およびレビューする。S6：参加者に十分な準備時間を与える。S7：レビューのスケジュールは適切に通知する。S8：マネージャーがレビュープロセスを支援する（例えば、プロジェクトスケジュールでレビューに十分な時間が割り当てられるようにする）。S9：レビューは、社内の品質、および/またはテストのポリシーに統合する。6Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビュータイプテスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03• 非形式的レビュー– 例えば、バディチェック、ペアリング、ペアレビュー• ウォークスルー• テクニカルレビュー• インスペクション7レビュー対象非形式レビューテクニカルレビュー修正済レビュー対象レビュー済成果物Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビュー技法テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03• アドホック• チェックリストベース• シナリオとドライラン• パースペクティブベース• ロールベース8Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューを成功させるための人的な要因テスト技術者資格制度 Foundation Levelシラバス 3.2.5 レビューの成功要因H1：レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパースペクティブを持ち、対象のドキュメントを使うことがある人たち）。H2：テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテストを早期に準備できると、レビューアとして価値がでる。H3：参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。H4：レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビューは対象を小さく分割して実施する。H5：見つかった欠陥は客観的な態度で確認、識別、対処をする。H6：ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。H7：レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。H8：参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。H9：特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。H10：学習とプロセス改善の文化を醸成する。9Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
〇〇作成例：基本設計成果物案INPUTReview結果サマリReview計画Review開始個々のReview懸念事項共有･分析 修正･報告Review計画1 2 3 4 50個別Review結果Review報告集合会議 結果評価開始基準終了基準修正 報告成果物Copyright © Kenji Adachi@Software Quasol , All Rights Reserved終了基準レビュープロセス参考：テスト技術者資格制度 Foundation Levelシラバス 3.2.1 作業成果物のレビュープロセス10
S5小分割レビューH4小分割レビューH3 適切な時間割当による詳細なレビュー〇〇作成例：基本設計成果物案INPUTReview結果サマリReview計画Review開始個々のReview懸念事項共有･分析 修正･報告Review計画1 2 3 4 50個別Review結果Review報告集合会議 結果評価開始基準終了基準S1目的定義S2適切なレビュータイプ選択参加者選定S6十分な準備時間S7ｽｹｼﾞｭｰﾙ通知S8レビュープロセス支援ManagerQualityPolicy TestPolicyS9品質･テストポリシーに統合ReviewS4 Checklist最新維持ChecklistS3-1適切なレビュー技法選択H1適切な要員の関与TestEngineerH2 早期テスト準備による貢献H5 検出欠陥の客観的確認･識別･対処H7-1信頼できる雰囲気で実施H7-2レビュー結果を人的評価に使用しないH8発言の受取に注意(退屈感、憤り、敵意)H9高度レビュータイプへトレーニング提供ふりかえり修正 報告成果物H6 有意義な時間となる適切なマネジメントS3-2適切なレビュー技法使用Copyright © Kenji Adachi@Software Quasol , All Rights Reserved終了基準H10学習とプロセス改善文化の醸成レビュープロセス上に成功要因をマッピング11
レビューの問題構造12Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
分析は大変・実施されない日程調整が不調・大変対象物事前提出なしor遅れ作り方、内容ばらつき成果物がレビューするに値しない状態自己チェックなし・チェック不足レビュー工数が取れないレビューへのモチベーションが低い場面に適したレビュー形式がわからない何でもレビュー対象になっている曖昧指摘形式的・形骸化事前チェックなし適切なメンバーが揃わない参加者が多い有識者が多忙で不参加有識者が少ないスキル差が大きいレビューア育成が進まないドメイン・レビュー知識不足チェックリストが形骸化チェックリストを使っても指摘が漏れるチェック項目が多い・使われない結果がレビューアに依存するいつも同じ欠陥ばかり軽微な指摘ばかり欠陥・問題の見逃し指摘を適切に伝えられない回答できない 自己防衛思いつき・観点がバラバラ意見・指摘が偏る/発散する参加者が寝る・発言しない声大者独壇場脱線する怒られる、説教等ツライ説明会になる知見を蓄積できない指標値の収集・分析が未定着生産性が低い・効果が不明時間がかかる落としどころ不明で何度も繰り返す指摘漏れがないか確信できないOK/NG判断が困難欠陥指摘が少ない議論したが未修正指摘のみ修正し，全体確認や横展開なし記録作成に時間がかかる議事内容がばらばら議事録が残らないレビューが進捗のボトルネックになりやすいレビューの重要性・必要性が広まらない後工程で欠陥が発見される1 23122 3246466355131Copyright © 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
分析は大変・実施されない日程調整が不調・大変対象物事前提出なしor遅れ作り方、内容ばらつき成果物がレビューするに値しない状態自己チェックなし・チェック不足レビュー工数が取れないレビューへのモチベーションが低い場面に適したレビュー形式がわからない何でもレビュー対象になっている曖昧指摘形式的・形骸化事前チェックなし適切なメンバーが揃わない参加者が多い有識者が多忙で不参加有識者が少ないスキル差が大きいレビューア育成が進まないドメイン・レビュー知識不足チェックリストが形骸化チェックリストを使っても指摘が漏れるチェック項目が多い・使われない結果がレビューアに依存するいつも同じ欠陥ばかり軽微な指摘ばかり欠陥・問題の見逃し指摘を適切に伝えられない回答できない 自己防衛思いつき・観点がバラバラ意見・指摘が偏る/発散する参加者が寝る・発言しない声大者独壇場脱線する怒られる、説教等ツライ説明会になる知見を蓄積できない指標値の収集・分析が未定着生産性が低い・効果が不明時間がかかる落としどころ不明で何度も繰り返す指摘漏れがないか確信できないOK/NG判断が困難欠陥指摘が少ない議論したが未修正指摘のみ修正し，全体確認や横展開なし記録作成に時間がかかる議事内容がばらばら議事録が残らないレビューが進捗のボトルネックになりやすいレビューの重要性・必要性が広まらない後工程で欠陥が発見される1 23122 3246466355141レビューへのモチベーションレベル対象成果物の質・状態事前配布の有無工数余裕度対象量数･規模調整努力量要員の知識･スキルの状態レビュー訓練と効果経験･知見の蓄積状態参加者の適切性ミーティングの状態(場･感情･時間等)レビュー観点の適切性指摘の質と量修正の適切さ計画の適切さレビューの効果・以降への影響記録の有無・状態指標値収集･分析の状態知見の蓄積量レビューの重要性認識事前レビューの有無結果の有識者依存度指摘伝達の良し悪しCopyright © Kenji Adachi@Software Quasol , All Rights Reserved結果への納得度
15レビューへのモチベーションレベル対象成果物の質・状態事前配布等準備の有無工数余裕度調整努力量要員の知識･スキルの状態レビュー訓練の有無と効果経験･知見の活用度参加者の適切性ミーティングの状態(場･感情･時間等)レビュー観点の適切性レビュー指摘の質と量修正の適切さ計画の適切さレビュー効果･生産性･以降への影響記録有無･状態レビューの重要性認識事前レビューの有無結果の有識者依存度指摘伝達の質結果への納得度フォローの有無･質1 2213Copyright © Kenji Adachi@Software Quasol , All Rights Reservedレビュー効果図式ライクなもの正負の関係性を表現していませんのでご注意を結果･指標値収集･分析の有無･状態知見のまとめ方･蓄積状態23
レビューの成功要因はレビューの問題を解決するのか？16Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
17レビューへのモチベーションレベル対象成果物の質・状態事前配布等準備の有無工数余裕度調整努力量要員の知識･スキルの状態レビュー訓練の有無と効果経験･知見の活用度参加者の適切性ミーティングの状態(場･感情･時間等)レビュー観点の適切性レビュー指摘の質と量修正の適切さ計画の適切さレビュー効果･生産性･以降への影響記録有無･状態レビューの重要性認識個別レビューの有無結果の有識者依存度指摘伝達の質結果への納得度フォローの有無･質1 2213Copyright © Kenji Adachi@Software Quasol , All Rights ReservedS5小分割レビュー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適切なレビュータイプ使用結果･指標値収集･分析の有無･状態知見のまとめ方･蓄積状態23H10学習とプロセス改善文化の醸成
〇〇作成例：基本設計成果物案INPUTReview結果サマリReview計画Review開始個々のReview懸念事項共有･分析 修正･報告Review計画1 2 3 4 50個別Review結果Review報告集合会議 結果評価開始基準終了基準参加者選定Manager QualityPolicy TestPolicyReviewChecklistTestEngineer修正 報告成果物□有能なファシリテータが運営する□有識者を含めた適切なメンバーが参画する□対象規模・難易度に対して適切な時間実施される□全員が参画し、集中して建設的な議論がなされる□相乗効果でより多くの有効な指摘・コメントが得られる□修正が必要な欠陥等が漏れなく記録される□指摘事項を確定し、ステータスを割り付ける□終了基準に照らして今後の取扱いを判定する□作成者は結果を理解し、適切に・前向きに受け取る□レビューをふりかえり、今後の実践方法を磨く□レビューするに値する対象成果物案が提出される□集合前に個々のレビューを実施して結果を記録する□個々のレビュー結果が収集され、集約・共有される□迅速に、適切に成果物を修正する□必要な場合、修正をフォローする□終了基準に照らして完了判断する□質の高い成果物が完成する□レビュー目的・範囲・観点等を決める□適切なレビュータイプ、技法を選定する□有識者を含めた適切なメンバーを選定する□時間・工数を見積り、日程等を決定する□開始基準、終了基準を定める□開始基準に照らして開始を判定する□必要な資料が事前配付される□実施に際しての疑問が解消される□Checklist等を活用し、必要な観点を整理する□関係者は全員日程、レビューの進め方、役割を理解し、適切に実践できる状態である＜Goal＞□レビューの目的を達成している□レビューの時間、工数当たりの効果・成果が高い□以降の作業での問題発生や再作業がほとんどない□参加者がレビューの効果や価値を実感している終了基準□観点や欠陥情報を蓄積し、活用しやすくまとめ最新状態を維持するCopyright © Kenji Adachi@Software Quasol , All Rights Reserved欠陥DBレビュー成功のためのシナリオ（例）□レビューのよりよい実践を支援する□現状評価・把握して改善を促進する18
Manager QualityPolicy TestPolicyReview□レビューのよりよい実践を支援する□現状評価・把握して改善を促進するChecklist□観点や欠陥情報を蓄積し、活用しやすくまとめ最新状態を維持する欠陥DB〇〇作成例：基本設計成果物案INPUTReview結果サマリReview計画Review開始個々のReview懸念事項共有･分析 修正･報告Review計画1 2 3 4 50個別Review結果Review報告集合会議 結果評価開始基準終了基準参加者選定TestEngineer修正 報告成果物□有能なファシリテータが運営する□有識者を含めた適切なメンバーが参画する□対象規模・難易度に対して適切な時間実施される□全員が参画し、集中して建設的な議論がなされる□相乗効果でより多くの有効な指摘・コメントが得られる□修正が必要な欠陥等が漏れなく記録される□指摘事項を確定し、ステータスを割り付ける□終了基準に照らして今後の取扱いを判定する□作成者は結果を理解し、適切に・前向きに受け取る□レビューをふりかえり、今後の実践方法を磨く□レビューするに値する対象成果物案が提出される□集合前に個々のレビューを実施して結果を記録する□個々のレビュー結果が収集され、集約・共有される□迅速に、適切に成果物を修正する□必要な場合、修正をフォローする□終了基準に照らして完了判断する□質の高い成果物が完成する□レビュー目的・範囲・観点等を決める□適切なレビュータイプ、技法を選定する□有識者を含めた適切なメンバーを選定する□時間・工数を見積り、日程等を決定する□開始基準、終了基準を定める□開始基準に照らして開始を判定する□必要な資料が事前配付される□実施に際しての疑問が解消される□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 検出欠陥の客観的確認･識別19H3 適切な時間割当による詳細なレビューH3 適切な時間割当H10学習とプロセス改善文化の醸成H1適切な要員の関与S1目的定義
〇〇作成例：基本設計成果物案INPUTReview結果サマリReview計画Review開始個々のReview懸念事項共有･分析 修正･報告Review計画1 2 3 4 50個別Review結果Review報告集合会議 結果評価開始基準終了基準参加者選定Manager QualityPolicy TestPolicyReviewChecklistTestEngineer修正 報告成果物□有能なファシリテータが運営する□有識者を含めた適切なメンバーが参画する□対象規模・難易度に対して適切な時間実施される□全員が参画し、集中して建設的な議論がなされる□相乗効果でより多くの有効な指摘・コメントが得られる□修正が必要な欠陥等が漏れなく記録される□指摘事項を確定し、ステータスを割り付ける□終了基準に照らして今後の取扱いを判定する□作成者は結果を理解し、適切に・前向きに受け取る□レビューをふりかえり、今後の実践方法を磨く□レビューするに値する対象成果物案が提出される□集合前に個々のレビューを実施して結果を記録する□個々のレビュー結果が収集され、集約・共有される□迅速に、適切に成果物を修正する□必要な場合、修正をフォローする□終了基準に照らして完了判断する□質の高い成果物が完成する□レビュー目的・範囲・観点等を決める□適切なレビュータイプ、技法を選定する□有識者を含めた適切なメンバーを選定する□時間・工数を見積り、日程等を決定する□開始基準、終了基準を定める□開始基準に照らして開始を判定する□必要な資料が事前配付される□実施に際しての疑問が解消される□Checklist等を活用し、必要な観点を整理する□関係者は全員日程、レビューの進め方、役割を理解し、適切に実践できる状態である＜Goal＞□レビューの目的を達成している□レビューの時間、工数当たりの効果・成果が高い□以降の作業での問題発生や再作業がほとんどない□参加者がレビューの効果や価値を実感している終了基準□観点や欠陥情報を蓄積し、活用しやすくまとめ最新状態を維持するCopyright © Kenji Adachi@Software Quasol , All Rights Reserved欠陥DBレビュー成功要因の効果は [67点/100点]□レビューのよりよい実践を支援する□現状評価・把握して改善を促進する20
レビューの成功とは？レビューの成功に最も重要で外せない要因21Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューが成功した状態とは？（一例）この中でレビューの成功に最も重要で外せない要因はどれ？• レビューの目的を達成している。– 有効な指摘、必要な欠陥検出が行われる／致命的な見逃しがない（少ない）– レビューを通じてレビュー対象やレビュー実践方法への理解が促進される• レビューの効果を実感し、レビューに対するモチベーションが高くなる。– 関係者がレビューの効果と重要性を認識している• 作成者が結果に納得し、確実に成果物の修正を実施する• レビューへの参画、実践に前向きになる• さらに良い結果を少ない手間、時間で獲得する準備を行っている。• レビュートレーニングの実践• 自組織、自チームのレビュー実践バリエーションの整備、更新• 検出欠陥情報DBやレビュー観点群の整備、更新 など22Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
23レビューへのモチベーションレベル対象成果物の質・状態事前配布等準備の有無工数余裕度調整努力量要員の知識･スキルの状態レビュー訓練の有無と効果経験･知見の活用度参加者の適切性ミーティングの状態(場･感情･時間等)レビュー観点の適切性レビュー指摘の質と量修正の適切さ計画の適切さレビュー効果･生産性･以降への影響記録有無･状態結果･指標値収集･分析の有無･状態知見のまとめ方･蓄積状態レビューの重要性認識事前レビューの有無結果の有識者依存度指摘伝達の質結果への納得度フォローの有無･質1 2213Copyright © Kenji Adachi@Software Quasol , All Rights Reservedレビュー効果図式この中でレビューの成功に最も重要で外せない要因はどれ？23
JaSST’16東京 事例発表レビュー目的・観点設定の効果と課題http://www.jasst.jp/symposium/jasst16tokyo/pdf/A2-1.pdf24Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビュープロセス レビュー成功要因 有効指摘獲得への直接的要因 有効指摘獲得への環境的要因[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学習とプロセス改善文化醸成 △25Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
有効な指摘、必要な欠陥検出が行われる／致命的な見逃しがない（少ない）のために適切な要員の関与• 有識者の参画– 有識者＝有効な確認と指摘ができる要員– “多忙な方”なのでスケジュール調整が難しい＝ボトルネックに• 有能なファシリテータによるレビュー会議運営– タイムマネジメントされたスムーズな会議運営もさることながら、参加者それぞれが持つ特徴を引き出し、相乗効果を獲得する質問や問いかけ（観点の提供や掘り下げ）アプローチが重要★いかにして有識者でなくても確認できる領域を広げるか、どうやって有能なレビューアやファシリテータを育てるかが現状のレビューの課題26Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
有効な指摘、必要な欠陥検出が行われる／致命的な見逃しがない（少ない）のために適切なレビュー技法の使用テスト技術者資格制度 Foundation Levelシラバス 3.2.4 レビュー技法の適用レビュー技法名 技法の概要アドホック レビューアは、このレビューに関するタスクのガイダンスをほとんどまたはまったく提供されない。一般的に、レビューアは作業成果物を順番に読んで懸念事項を識別するごとに記録に残す。チェックリストベース レビューアはレビューの開始時に（例えばファシリテーターにより）配布されるチェックリストを使用して懸念事項を検出する。レビューチェックリストは、経験から導出した起こりえる欠陥に基づく一連の質問を列挙したものである。シナリオとドライラン 作業成果物を読むための構造化されたガイドラインをレビューアに提供する。レビューアはシナリオベースドレビューを使用して、（作業成果物がユースケースなど適切な形式で文書化されている場合）作業成果物の期待する使い方に基づいて、作業成果物に対して「ドライラン」を行う。ロールベース レビューアは個々のステークホルダーの役割の観点から作業成果物を評価する。パースペクティブベース レビューアはそれぞれに異なるステークホルダーの観点でレビュー活動を行う。レビュー対象の作業成果物から各レビューアの役割で導出する成果物を作成する。27Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
チェックリストベースの例ガイドワードによるレビュー＜ガイドワード例＞• 類似の意味を持つ複数の言葉例：完了・終了 警報・警告• 複数の意味を持つ一つの言葉例：電源オフ/スタンバイ• 非対称な機能遷移 <：上位遷移 >：下位遷移• 条件指定：～のとき、～でない時、～の際、～場合• 否定表現：～しない、～ではない• 紛らわしい：詳細度が低い＜効果的実践法＞□ツールで漏れなく検出する→そして判定・処理へ□発生した不具合の内容を継続して蓄積・整理し、以降のレビューで活用する出典：鈴木三紀夫氏意地悪漢字28Copyright © Kenji Adachi@Software Quasol , All Rights Reservedhttp://www.jasst.jp/archives/jasst10s/pdf/S3-9.pdf
キーワードベースドレビュー－ドキュメントのあいまいさや不備に着目したレビュー手法観点 具体的記述例 確認ポイント数値的表現 から、～、以上、以下 数値の境界が明確に切り分けできるか時間的表現 あとで、先に、事前に、のちほど、常に、いつも、常時、逐次、一定時間が明確に特定できるか深さ・長さの表現 消去する、残す、保持する、制限する、記憶する 程度（レベル）が明確に特定できるか実体のない表現 管理する、運用する、処理する、実行する 具体的に実態を表す内容に展開できるか条件指定表現 とき、以外、の際 指定条件以外の条件を記述しているか否定 しない、できない、 実施すべき内容が並列に記述されているか受動 される、と思われる 主体が明確に特定できるか不明瞭 くらい、とか、みたいな、的には、そらく、ほぼ、ような、できるだけ具体的な表現が追記されているか形容表現 多、少、速、遅 数値仕様として特定できるか指示表現 これ、あれ、それ、どれ。そこ、この 指示先が特定できるか29Copyright © Kenji Adachi@Software Quasol , All Rights Reserved高品質ソフトウェア技術者交流会現場改善技法検討分科会SEチーム http://www.jasst.jp/archives/jasst10e/pdf/C2-3.pdf
パースペクティブベースドリーディングレビューアが持つロール（下記事例は設計者・テスト担当者）が導出する成果物を作成して確認する30状態遷移図の作成・追跡による確認※シナリオの併用も効果的レビュー対象成果物Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
入力・遷移元・イベント 判定・処理 出力・遷移先保温状態 下記のいずれかで遷移する(1)エラー検知(2)蓋センサーOFF(3)全水位センサーOFFアイドル状態事前条件 事後条件？？？ ？？？31Copyright © Kenji Adachi@Software Quasol , All Rights Reservedパースペクティブベースドリーディング早期テスト準備による貢献 へのアプローチ事例テストケースが記載できるかをテストケースフレームに入れて確認してみる
レビュー（リーディング）技法の特徴（実験結果考察）32項目/技法 アドホック（Ad-hoc） チェックリスト（CBR） シナリオ（SBR）～ドライラン特徴 ・無計画、思いつき対応・未確認、見逃しが多くなる可能性大・新発想獲得の可能性・網羅に向くため見逃しを防止できる可能性大・項目毎に個別確認することが多く時間がかかる・利用者、設計者などの視点で、流れで確認する・上流工程で使用されることが多い効果決定要因担当者のスキル、経験に結果が大きく左右されるチェックリストの質と活用方法に結果が左右される設定するシナリオの質に結果が左右されるコミュニケーションの影響結果・効果に大きな影響を与える 結果・効果に影響を与える場合がある 結果・効果への影響を受けにくい強み 担当者が持つノウハウ・直感による確認が可能・時間がかからない・チェック項目を網羅しやすい・スキルのばらつき影響を受けにくい利用者、設計者等様々な視点で、目的達成の可能性に対する確認が可能弱み ・確認漏れ、重複、表面的確認に終始しがちになる時間がかかる／形式的確認となる可能性あり／チェック項目以外に目がいかなくなる可能性あり／チェックリストの作成、維持が大変表現形式、スタイルの良し悪しなどの基本的事項の確認が抜けてしまう可能性あり／想定利用者のコンテキストと合わない可能性あり／不整合を見逃す可能性あり事前準備等考慮事項スキル・経験ある担当者が対応する 事前にレビュー対象に必要なチェック項目の選定や追加・カスタマイズを行うことが必要想定利用者とその利用状況を具体化し、利用者の立場に立って行う効果的活用法別途網羅的確認を行いつつ、ピンポイントでこの技法を活用するのが効果的チェック項目の選定・追加・カスタマイズした上で網羅的確認に活用する上流工程を中心に、チェックリストと併用することで効果が期待できる立場で見る「Perspective/Role Based Reading」やユースケースで見る「Usage Based Reading」などがあるCopyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビュー技法の原理• 立ち位置を変えるロールベース、パースペクティブベース• 狙って撃つチェックリスト、長文、NGワード（キーワード）• 表現方法や捉え方を変えてみる読み手、文章→図表、機能→状態、機能作り込み→利用の仕方• リスクから逆算してみるエラー推測、発生しそうな問題（例：過去トラ）33Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューで有効な確認と指摘をするために34Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビュー指摘に至るまでの道筋有効な指摘からのリバース例35(4)どのような目的を達成するためのものですか？(3)それはどのような観点と言えますか？ (2)どのように調べた結果ですか？ (1)レビューで検出した内容売れるのか？ ターゲットユーザーにヒットするかターゲットユーザーの立ち位置で「備えるべき特徴」が実現できているかを確認単独タイマ機能でコストが高くなるなら必要ないのでは？（100均ショップで分秒表示タイマ購入可能）ターゲットユーザーの立ち位置で、企画書「備えるべき特徴」が実現できているかを確認ターゲットユーザ―の特徴からするとミルクモードは必要ないのでは？安全に、快適に利用できること安全性、利用しやすさ（快適性・使用性）利用の流れに沿って戸惑ったり、疑問が生まれたり、危険になることはないかを確認（持ち運び、設置時）筐体の大きさ、形状、重さ、取っ手の場所・持ちやすさ、がわからない（持ち運ぶ際の快適さが確保されているか）同上（利用開始時） 2-5解除ボタン デフォルト コンセントつなぐロック解除 →危険性があるのでロックすべきでは？同上（利用開始時） ふた 閉めると沸騰モードに遷移するのはわかりにくい／意図しない沸騰は避けたい同上（モード単位の利用時） ミルクモード100℃→追い炊き→60℃になるまで冷ます 60℃になったら知らせる機能はいらない？システム設計の実施可能性条件外の動作や振る舞い特定条件下で動作や振る舞いが指定された場合、条件以外の動作や振る舞いがあるかを確認4P内部構成記載～センサーがONの時の記述が複数ある→OFFの時どうなるのか不明レビュー目的 レビュー観点レビューケース／レビュー手順・スクリプトレビューコメント・指摘事項Copyright © Kenji Adachi@Software Quasol , All Rights Reservedレビュー技法の適用
儲かるかな？開発プロジェクト〇〇システム主な観点は立ち位置で変わる利害関係者の立ち位置と関心事(例)開発プロジェクトチームシステムオーナー組織(発注者)保守・運用メンバーリリース協力会社 協力会社外部ベンダー36役に立つのかな？使いやすいのかな？実利用者運用しやすいのかな？保守しやすいのかな？納期遵守？採算は？顧客に評価される？機能は動く？ 非機能要件は？利用者評価は？雇い主の評価は？提供部品の評価は？テストにパスする？この機器で使える？セキュリティは？発売タイミングは？Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
モノゴトに対する認識モノゴトに対する判断行動 結果成果(価値提供度)人は見たいものしか見ない立ち位置で視野と見え方が異なる立ち位置によって関心事が異なる事業 業務ITシステム距離幅･深み･奥行開発･運用･保守Process認識の差異 判断の差異 行動の差異システム･ソフトウェアは目に見えない視野 視野視野 視野モノゴトの表現･共有方法の自由度が高い認識の壁によるサイロ化認識の壁認識の壁認識の壁実利用レビューの役割立ち位置の視野の違い等による悪影響を最小化するCopyright © Kenji Adachi@Software Quasol , All Rights Reserved37
レビュー観点導出アプローチの例• プロダクトの目的・背景、要求事項（機能・非機能）、特徴の把握• 利害関係者とその関心事の洗い出しと重要度設定– 関係者例：実利用者、オーナー、開発者、テスト担当、運用保守担当、企画者、マーケッター– 実利用者関心事例： 課題解決、自環境での利用可能性、利用しやすさ、コストや手間、利用によるリスク• プロダクトリスクの洗い出し• システム外部との関係性、機能、動作・処理順～内部物理構成、運用方法等の把握– Context View/Functional View/Process View/Physical View/Operational View など• 発生しそうな障害やバグの洗い出し– 過去トラ（内部・外部）、複雑な構造やつくり、利用者がやりそうなミス、顧客クレームからの類推、担当者の不安、複数回の変更発生個所 など• 以上の結果を整理し、観点群として体系化• 忘れ物チェック– システム・ソフトウェア品質特性や利用時の品質、非機能グレード など• 対象ドキュメントとして必要な記述内容の把握– 要求仕様書、基本設計書、テスト仕様書、操作説明書、、、、、38毎回ゼロから作成するのは大変なので個人やプロダクト単位でレビュー観点図を作っておくと便利※ただし、観点の形式チェックのような使い方はご法度Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
観点設定優先度（おおまかな方針）対象の規模により“一度にすべて”が無理な場合が多い39認識できる 理解できるレビュー共通（レビュー自動化へ）製品・サービスの特徴とフェーズにより取捨選択Copyright © Kenji Adachi@Software Quasol , All Rights Reserved表記方法の参考文献：テスト設計チュートリアル テスコン編資料(講義編)サービス領域（提供）システム／ソフトウェア領域サービス領域（利用）曖昧不明確矛盾基本・形式規約不遵守不統一多義表現機能未決誤字脱字衍字合目的性有効性抽象表現非機能判読性NG表現リスク回避性正確性適切性ドキュメント特性使用性性能信頼性 互換性セキュリティ効率性利用状況適合性保守性運用性保守性信頼性画面 構造/論理Ｉ/Ｆ移植性
システム運用･保守観点の関係性（例）40有効性効率性リスク回避性満足性利用状況網羅性可用性性能･拡張性保守･運用性移行性システム環境･エコロジーセキュリティ機能機能適合性性能効率性互換性使用性信頼性保守性移植性セキュリティシステム/ソフトウェア特性システム利用時/利用後Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
保守性が悪いスピードが重視される領域保守性が悪いと競争力が低下する41保守･運用性機能機能適合性性能効率性互換性使用性信頼性保守性移植性セキュリティ余裕度がなくなると捨てられる優先度開発者が最も尽力する優先度中味がわかりにくいテストしにくい変更しにくい欠陥見逃しが増える作業効率が落ちる障害が発生しやすい障害対応が必要改修スピードが鈍る改修リードタイム長くなるMTBF・MTTR悪化デプロイ頻度低下変更成功率低下つくりが複雑運用･保守チームが不幸利用者が不幸→離れていくオーナー企業が不幸Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューメタ観点図活用イメージ42要求定義 設計Copyright © Kenji Adachi@Software Quasol , All Rights Reserved取捨選択要求仕様書Review設計書ReviewReview結果開発の背景・目的製品特徴など要求仕様書
役立つのか？売れるのか？43マインドマップによるレビュー観点設計事例必要なレビュー観点等を明確化＝狙いを定めてレビューを行うCopyright © Kenji Adachi@Software Quasol , All Rights Reserved
△改善前（Before）●改善後（After）発見可能Phase（想定）計実装・UT IT ST・OT C/O後1 3 5 7検出効果効果大主対象：要件抜け・誤り 530↓335効果中主対象：機能上のバグ（誤植による）375↓93効果小主対象：誤字・脱字・衍字規約違反 116↓8計 35→19 18→0 40→340 28→77 121→436指摘件数： △23 → ●2444△が左下（指摘価値が低い）に集中●が右上（指摘価値が高い）に集中目的・観点設定による典型的な指摘変化の例Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビュー観点設定なし→ありの効果2012～2020年に実施した全ワークショップ（11社30チーム）実績から算出45観点設定なし観点設定なし観点設定あり観点設定ありCopyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューの成功とその先46Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューのキキメを得るために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.ふりかえりにより改善事項を明確にし、知見を蓄積して同じ失敗を繰り返さない47Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューパフォーマンス改善階段の上がり方を判断する• 今持っている力を最大限発揮する– 実施環境面、マネジメント面の施策から開始する– 施策例：小さな単位で作成→レビューを行う、開始基準による運営、有能なファシリテータ―による運営、簡潔なグランドルールの採用、事前配付による個別チェック、ジャイアン独演会の回避、レビュー直後のふりかえり実践（運営方法の継続改善） など• 今持っている力をさらに向上させる– 意図的に狙ってレビューする力を向上させる– 施策例：レビュー観点設計力を鍛える、レビュー観点図作成と継続更新、検出した欠陥の分析とレビュー直後のふりかえり実践（欠陥検出方法の磨き込み）など48Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューファーストによるシフトレフト49手戻り障害対応実作業 成果物案成果物レビューレビュー結果成果物修正 成果物実作業 成果物案成果物レビューレビュー結果成果物修正 成果物レビュー観点手戻り障害対応作業要件･注意事項実作業 成果物案成果物レビューレビュー結果成果物修正 成果物レビュー観点手戻り障害対応進化Copyright © Kenji Adachi@Software Quasol , All Rights Reserved★RDD：Review Driven Development
レビューファースト50テストテスト分析テスト設計テスト実装テスト実行テスト完了テスト設計 テスト実行この部分を要求定義や設計段階に一緒に行う＝テストファーストレビューレビュー分析レビュー設計レビュー実装レビュー実行レビュー完了レビュー設計 レビュー実行この部分を対象作業着手前に一緒に行う＝レビューファーストCopyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビューとテストの協調・連携レビューが(テストに比べて)検出可能な欠陥例テスト技術者資格制度 Foundation Levelシラバス 3.1.3 静的テストと動的テストの違い より• 要件の欠陥– 例えば、不整合、曖昧性、矛盾、欠落、不正確性、冗長性• 設計の欠陥– 例えば、非効率なアルゴリズムやデータベース構造、高い結合度、低い凝集度• コードの欠陥– 例えば、値が未定定義な変数、宣言済の未使用変数、到達不能コード、重複したコード• 標準からの逸脱– 例えば、コーディング標準の不遵守51• 正しくないインターフェース仕様– 例えば、呼び出し側のシステムと呼び出される側のシステムで異なる単位の使用• セキュリティの脆弱性– 例えば、バッファオーバーフローが発生する可能性• テストベースのトレーサビリティ／カバレッジ不十分or不正確– 例えば、受入基準に対するテストケース欠落• 保守性欠陥のほとんど– 例えば、不適切なモジュール化、低いコンポーネント再利用性、分析困難で新たな欠陥混入なしでの修正困難なコードCopyright © Kenji Adachi@Software Quasol , All Rights Reserved
レビュー×テストによるQAイメージ52設計実装 UTITST/OTTest設計Review設計Test設計Copyright © Kenji Adachi@Software Quasol , All Rights Reserved開発の背景・目的製品特徴など要求定義Review設計Test設計取捨選択Review QAアーキテクチャ取捨選択要求仕様書ReviewReview
「いつも同じやり方」「ぼんやり何となく実施する」「参加するのが辛い」「効果が実感できない」このようなレビューから脱却して、みんなで価値あるシステム／ソフトウェアを世に送り出しましょう！53Copyright © Kenji Adachi@Software Quasol , All Rights Reservedご清聴ありがとうございました！
参考文献• ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03http://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=kVtd8bL9qrM54Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
kitanosirokuma
ayamakkie
tomomifuruya
yusukemarvel
ecrowd
knr109
professionalstudio
recruitasken
dahatake
recruithokkaidousubaru
nstock
kiyoshi502
o_ob
iamctodd
matthewcrist
myddelton
palkan
tanoku
gr2m
phodgson
addyosmani
productmarketing
rasmusluckow
jensimmons
kastner