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

Slide 1

Slide 1 text

「レビューの成功要因」はどの程度のキキメがあるの？ 1 レビューのキキメ～Part2 Software Quasol ＠HBA 安達賢二 https://www.softwarequasol.com/ [email protected] ソフトウェアテストシンポジウム(JaSST)2021四国 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

Slide 2

Slide 2 text

安達賢二（あだちけんじ） [email protected] 株式会社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

Slide 3

Slide 3 text

今日のテーマ 3 テスト技術者資格制度 Foundation Levelシラバス 3.2.5 レビューの成功要因レビューを成功させるための組織的な要因 • レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。 • 達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。 • レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法やロールベース技法など）を1つ以上使用する。 • チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。 • 欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするために、大きなドキュメントは小さく分割して記述およびレビューする。 • 参加者に十分な準備時間を与える。 • レビューのスケジュールは適切に通知する。 • マネージャーがレビュープロセスを支援する（例えば、プロジェクトスケジュールでレビューに十分な時間が割り当てられるようにする）。 • レビューは、社内の品質、および/またはテストのポリシーに統合するレビューを成功させるための人的な要因 • レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパースペクティブを持ち、対象のドキュメントを使うことがある人たち）。 • テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテストを早期に準備できると、レビューアとして価値がでる。 • 参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。 • レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビューは対象を小さく分割して実施する。 • 見つかった欠陥は客観的な態度で確認、識別、対処をする。 • ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。 • レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。 • 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。 • 特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。 • 学習とプロセス改善の文化を醸成する。レビューの問題構造本当に解決するのか？ Copyright © Kenji Adachi@Software Quasol , All Rights Reserved JSTQB

Slide 13

Slide 13 text

分析は大変・実施されない日程調整が不調・大変対象物事前提出なし 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

Slide 14

Slide 14 text

分析は大変・実施されない日程調整が不調・大変対象物事前提出なし 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 結果への納得度

Slide 18

Slide 18 text

〇〇作成例：基本設計成果物案 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

Slide 19

Slide 19 text

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目的定義

Slide 20

Slide 20 text

〇〇作成例：基本設計成果物案 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

Slide 32

Slide 32 text

レビュー（リーディング）技法の特徴（実験結果考察） 32 項目/技法アドホック（Ad-hoc）チェックリスト（CBR）シナリオ（SBR）～ドライラン特徴・無計画、思いつき対応・未確認、見逃しが多くなる可能性大・新発想獲得の可能性・網羅に向くため見逃しを防止できる可能性大・項目毎に個別確認することが多く時間がかかる・利用者、設計者などの視点で、流れで確認する・上流工程で使用されることが多い効果決定要因担当者のスキル、経験に結果が大きく左右されるチェックリストの質と活用方法に結果が左右される設定するシナリオの質に結果が左右されるコミュニケーションの影響結果・効果に大きな影響を与える結果・効果に影響を与える場合がある結果・効果への影響を受けにくい強み担当者が持つノウハウ・直感による確認が可能・時間がかからない・チェック項目を網羅しやすい・スキルのばらつき影響を受けにくい利用者、設計者等様々な視点で、目的達成の可能性に対する確認が可能弱み・確認漏れ、重複、表面的確認に終始しがちになる時間がかかる／形式的確認となる可能性あり／チェック項目以外に目がいかなくなる可能性あり／チェックリストの作成、維持が大変表現形式、スタイルの良し悪しなどの基本的事項の確認が抜けてしまう可能性あり／想定利用者のコンテキストと合わない可能性あり／不整合を見逃す可能性あり事前準備等考慮事項スキル・経験ある担当者が対応する事前にレビュー対象に必要なチェック項目の選定や追加・カスタマイズを行うことが必要想定利用者とその利用状況を具体化し、利用者の立場に立って行う効果的活用法別途網羅的確認を行いつつ、ピンポイントでこの技法を活用するのが効果的チェック項目の選定・追加・カスタマイズした上で網羅的確認に活用する上流工程を中心に、チェックリストと併用することで効果が期待できる立場で見る「Perspective/Role Based Reading」やユースケースで見る「Usage Based Reading」などがある Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

Slide 35

Slide 35 text

レビュー指摘に至るまでの道筋有効な指摘からのリバース例 35 (4)どのような目的を達成するためのものですか？ (3)それはどのような観点と言えますか？ (2)どのように調べた結果ですか？ (1)レビューで検出した内容売れるのか？ターゲットユーザーにヒットするかターゲットユーザーの立ち位置で「備えるべき特徴」が実現できているかを確認単独タイマ機能でコストが高くなるなら必要ないのでは？（100均ショップで分秒表示タイマ購入可能）ターゲットユーザーの立ち位置で、企画書「備えるべき特徴」が実現できているかを確認ターゲットユーザ―の特徴からするとミルクモードは必要ないのでは？安全に、快適に利用できること安全性、利用しやすさ（快適性・使用性）利用の流れに沿って戸惑ったり、疑問が生まれたり、危険になることはないかを確認（持ち運び、設置時）筐体の大きさ、形状、重さ、取っ手の場所・持ちやすさ、がわからない（持ち運ぶ際の快適さが確保されているか）同上（利用開始時） 2-5解除ボタンデフォルトコンセントつなぐロック解除 →危険性があるのでロックすべきでは？同上（利用開始時）ふた閉めると沸騰モードに遷移するのはわかりにくい／意図しない沸騰は避けたい同上（モード単位の利用時）ミルクモード100℃→追い炊き→60℃になるまで冷ます 60℃になったら知らせる機能はいらない？システム設計の実施可能性条件外の動作や振る舞い特定条件下で動作や振る舞いが指定された場合、条件以外の動作や振る舞いがあるかを確認 4P内部構成記載～センサーがONの時の記述が複数ある→OFFの時どうなるのか不明レビュー目的レビュー観点レビューケース／レビュー手順・スクリプトレビューコメント・指摘事項 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved レビュー技法の適用

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text