How should you respond to feedback from reviews and tests

Development may change by using a review view points

Transcript

1. レ ビ ュ ー / テ ス ト か ら の フ ィ ー ド バ ッ ク に ど う 立 ち 向 か う の が よ い か ？ 〜 レ ビ ュ ー 観 点 活 用 で 開 発 が 変 わ る か も Software Review Engineering Explorers (SReEE)安達 賢二 1 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 2025/2/14 Developers Summit 2025
2. 安達 賢二（あだち けんじ） adachi@hba.co.jp 株式会社HBA 経営企画本部 Exective Expert（理事） イノベーション推進室 アドバイザー http://www.softwarequasol.com/ 株式会社Levii 共創ファシリテーター https://levii.co.jp/about/ 【経歴】 2012年社内イントレプレナー第一号事業者として品質向上支援事業を立ち上げ。 自律運営チーム構築･変革メソッドSaPIDをベースに、 関係者と一緒に価値あるコトを創る共創ファシリテーター／ 自律組織･人財育成コーチとして活動中。 【社外活動】 NPO法人 ソフトウェアテスト技術振興協会（ASTER）理事 JSTQB（テスト技術者資格認定）技術委員 JaSST（ソフトウェアテストシンポジウム）北海道 2006-2009実行委員長 2010-2018実行委員 2019～2022サポーター JaSST-Review（ソフトウェアレビューシンポジウム）実行委員 JaSST-nanoお世話係 ソフトウェアレビューをエンジニアリングっぽく捉える会 ：Software Review Engineering Explorers／SReEE(スリー)メンバー テスト設計コンテスト本部審査委員(2015-2017) SEA（ソフトウェア技術者協会）幹事・北海道支部メンバー SS（ソフトウェア・シンポジウム）プログラム委員 第33-40期SQiP研究会レビュー分科会アドバイザー SQuBOK_Ver3プロセス改善研究Grリーダ（with プロセス改善の黒歴史研究） TEF北海道お世話係／TOCfE北海道幽霊メンバー など 2 Twitter（X） Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
3. 発表概要 • 多忙で限られた時間の中で一生懸命に作り上げた開発成果 物なのにレビュー、テストで容赦なく突き返される・・・どう立ち向 かうのが良いですか？ • 単に「突き返される→手直し」を繰り返しても解決しませんよね。 • 積み重ねられたレビュー結果やバグ票をすべて読み解いて開発 に活かす・・・よく聞く話ですが実際に成功した事例はあまり聞き ませんし、本当に多忙な中でできることなのでしょうか？ • その解決策として今回は「レビュー観点を活用した開発」を提 案し、そのカラクリや想定される効果（Quality of Engineer Lifeがどう変化するかを含む）を共有します。 3 Copyright © Kenji Adachi＠Software Quasol, All Rights Reserved
4. コンテンツ • よくある開発の状態 • Quality･Speed･Costをマルっと変えるために • 戦略1：欠陥混入予防 • 戦略2：問題早期発見・解決 • [戦略1×戦略2]の実践スタイルと位置づけ • この発表の意味と価値 • この提案の実践に必要なこと • おわりに 4 Copyright © Kenji Adachi＠Software Quasol, All Rights Reserved
5. よくある開発の状態 5 Copyright © Kenji Adachi＠Software Quasol, All Rights Reserved
6. プロジェクトチームの実態 ベストメンバーは揃わない 失敗を許容し、メンバーの特徴を活かして、協調・成長しながら進める 厳しい制約条件 いろんなワガママに付き合う～良いモノを、早く、安く、安全に チームはどこかで壁にぶつかる 新しいチームは壁を乗り越えられれば成長し、跳ね返されると崩壊する 失敗から学ぶ文化と相互理解に基づく心理的安全性の確保がカギ 大事なことは目に見えない 本当のポリシー・場を支配するルール・信頼・気持ち・ノウハウ・共感など～ 適切な方針を言動と行動で示し、共有する（知行合一） 6 Copyright © Kenji Adachi＠Software Quasol, All Rights Reserved
7. こんなことになっていませんか？ 【レビュー編】 作成者 成果物 作成 レビュー 実施 やっとできあがっ たのでレビューを お願いします 7 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved レビュー 担当 作成者 レビュー結果 成果物修正 プロジェクト 管理者 どうしてこんなに 遅れてるんだ！ こっ、これ 全部直す？
8. こんなことになっていませんか？ 【テスト編】 8 成果物修正 プロジェクト 管理者 どうしてこんなに 遅れてるんだ！ 開発者 こんなにバグ あるの？ テスト実施 開発作業 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
9. それはレビュー工数ではなく開発工数です 9 レビュー分析・ 設計・実装 レビュー 実行 レビュー 終了処理 成果物確認・修正 (デバッグ) 再レビュー依頼 再レビュー Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 手戻り
10. それはテスト工数ではなく開発工数です 10 テスト分析・ 設計・実装 テスト 実行 テスト 終了処理 成果物調査・修正 (デバッグ) 再テスト依頼 再テスト Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 手戻り
11. •手戻り 手順や成果物の内容を間違えて作業をやり直すこと。 追加工数が必要で時間もかかるため開発スピードが 鈍化する。 •手戻り発生の主な要因 •顧客等からの変更要求 •関係者間の齟齬／認識違い •レビュー・テストによる欠陥・不備の露呈 プロジェクトの混乱/スピード鈍化の原因 [手戻り＝やり直し・修正作業] 11 今日の話はここに着目 Copyright © Kenji Adachi@Software Quasol , All Rights Reserved
12. 「Software Quality In 2008」 Capers Jones Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 上流フェーズ成果物を対象としたレビューでの欠陥・不備の 見逃しがソフトウェアプロジェクトに与える悪影響は大きい 判明時にはリ リースまでの残り 時間が少ない 放置期間が長い→大きな問題に発展する 上位概念レベル の欠陥・不備は悪 影響の範囲が広い 12
13. 「Software Quality In 2008」 Capers Jones Copyright © Kenji Adachi@Software Quasol , All Rights Reserved 上流フェーズ成果物を対象としたレビューでの欠陥・不備の 見逃しがソフトウェアプロジェクトに与える悪影響は大きい 判明時にはリ リースまでの残り 時間が少ない 放置期間が長い→大きな問題に発展する 上位概念レベル の欠陥・不備は悪 影響の範囲が広い 上流フェーズレビューによる欠陥・不備の見逃し防止・緩和は プロジェクトリスクを大幅に低減する 13 今日は 【レビュー観点の活用】 を中心にお伝えします ※テスト観点も同様の考え方で対応可能です！
14. Quality･Speed･Costをマルっと変えるために 14 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
15. シフトレフト • 「シフトレフト」はソフトウェア開発プロセス～開発ライフサイクルの右側にあ るテストフェーズ（の一部）を開発フェーズから実 施し、不具合を早期に検出・修正する手法 •不具合を早期に検出し修正することで、手戻りを 削減し、レビュー、テストと修正にかかる時間とコス トを節約し、最終的にプロジェクト全体期間を短 縮する 15 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
16. テスト（プロセス） 開発プロセス（Vモデル） 要求定義 方式設計 詳細設計 実装 ユニット テスト ユニット 統合テスト システム テスト システム 統合テスト 受入テスト テスト 分析 テスト 設計 テスト 実装 テスト 実行 テスト 完了 製品企画 16 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
17. テスト（プロセス） テストプロセスの前段部分を先出しする シフトレフト（例） 要求定義 方式設計 詳細設計 実装 ユニット テスト ユニット 統合テスト システム テスト システム 統合テスト 受入テスト テスト 分析 テスト 設計 テスト 実装 テスト 実行 テスト 完了 製品企画 左(レフト)にシフト 左(レフト)にシフト 左(レフト)にシフト 左(レフト)に シフト 早期テストの原則 プロセスの早い段階で欠陥を取り除くと、 その後の作業成果物では取り除かれた欠 陥に起因する欠陥を引き起こすことはない。 SDLCの後半に発生する故障が少なく なるため、品質コストは削減される。 早い段階で欠陥を見つけるために、静的 テストと動的テストの両方をなるべく早い 時期に開始すべきである。 17 引用：ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
18. テスト（プロセス） テストプロセスの前段部分を先出しする シフトレフト（例） 要求定義 方式設計 詳細設計 実装 ユニット テスト ユニット 統合テスト システム テスト システム 統合テスト 受入テスト テスト 分析 テスト 設計 テスト 実装 テスト 実行 テスト 完了 製品企画 左(レフト)にシフト 左(レフト)にシフト 左(レフト)にシフト 左(レフト)に シフト 早期テストの原則 プロセスの早い段階で欠陥を取り除くと、 その後の作業成果物では取り除かれた欠 陥に起因する欠陥を引き起こすことはない。 SDLCの後半に発生する故障が少なく なるため、品質コストは削減される。 早い段階で欠陥を見つけるために、静的 テストと動的テストの両方をなるべく早い 時期に開始すべきである。 18 引用：ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 欠陥や不備を作り込んでから検出・除 去するまでのリードタイムを短くする 【問題の早期発見・解決】
19. シフトレフトの原理を活用した テスト主導ソフトウェア開発 TDD ATDD BDD 50分でわかるテスト駆動開発 / TDD Live in 50 minutes より Test-Driven Development テスト駆動開発 Behavior Driven Development 振る舞い駆動開発 Acceptance test–driven development 受け入れテスト駆動開発 TDDとBDD/ATDD(3) BDDとATDDとSbE より TDDとBDD/ATDD(4) ツールとしてのBDDとプロセスに 組み込まれたBDD より 19 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
20. TDD:テスト駆動開発は欠陥･不備の早期発見 ＋欠陥･不備の作り込み防止を志向するアプローチ 20 実装 ユニット テスト 部分 シフト Red Green Refact aring Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 実装 実装
21. TDD:テスト駆動開発は欠陥･不備の早期発見 ＋欠陥･不備の作り込み防止を志向するアプローチ 21 実装 ユニット テスト 部分 シフト Red Green Refact aring 欠陥や不備を できるだけ作り込まない 【欠陥混入の予防】 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
22. Quality･Speed･Costをマルっと変える戦略と戦術 22 (1)できるだけ欠 陥や不備を作らず に開発を進める (2)欠陥や不備を作 り込んでから検出・除 去するまでのリードタ イムを最小にする 関係者でレビュー観 点・テスト観点を共 有してから作成者が 作業に着手する でも人間は 間違うこと があるので 戦略 戦術 その実現のために ・作成者が観点をベースにセルフ チェックをしっかり実践する ・段階レビューで進める [部分開発→Review]×n その実現のために 【欠陥混入の予防】 【問題の早期発見・解決】 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
23. 戦略1：欠陥混入予防 23 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved (1)できるだけ欠 陥や不備を作らず に開発を進める (2)欠陥や不備を作 り込んでから検出・除 去するまでのリードタ イムを最小にする でも人間は 間違うこと があるので
24. Quality･Speed･Costをマルっと変える戦略と戦術 24 (1)できるだけ欠 陥や不備を作らず に開発を進める (2)欠陥や不備を作 り込んでから検出・除 去するまでのリードタ イムを最小にする 関係者でレビュー観 点・テスト観点を共 有してから作成者が 作業に着手する でも人間は 間違うこと があるので 戦略 戦術 その実現のために ・作成者が観点をベースにセルフ チェックをしっかり実践する ・段階レビューで進める [部分開発→Review]×n その実現のために 【欠陥混入の予防】 【問題の早期発見・解決】 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
25. 欠陥混入の現状 [現状：Before] 25 エラー error 欠陥 defect 故障 failure Review Test 間違った結果 を生み出す 人間の行為 思考 適切な 行動 適切な 実装 対象への理 解・認知 入力 作成者と作業 観点 観点 適切な 振舞い 成果物 実利用 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
26. 今回の提案：欠陥混入の予防のカラクリ [After] 26 エラー error 欠陥 defect 故障 failure Review Test 間違った結果 を生み出す 人間の行為 思考 適切な 行動 適切な 実装 対象への理 解・認知 入力 作成者と作業 観点 観点 観点 適切な 振舞い 成果物 実利用 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
27. レビュー指摘には観点がある！ (4)どんな目的を達成 するためのもの？ (3)どのような確認を したことになる？ (2)どのように 調べた結果？ (1)レビューで検出し た欠陥・不備の内容 使用性・保守性 が確保されてい ることを確実にす る ドキュメント内、およ び画面・機能間整合 確認（一貫性・整合 性） システムを一貫した 構造や用語使用で 構築するため 類似画面を洗い出し 、同じ意味のオブジェ クトや説明を目視で 比較確認→表現や形 状が不一致の場合は 指摘する P1では「登録」ボ タンなのに、P3で は「書き込み」ボタ ンになっている 検出した欠陥・ 不備を転記 左に一つずつシフトしながら回答する 27 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
28. レビュー観点とは？ 【目的】 使用性を確保する 【指摘事項】 同じ意味なのに画面1は 「登録」ボタン、画面2は 「書き込み」ボタン 実現手段 一貫した構造や用 語使用で構築する 確認事項 ドキュメント内整合 （一貫性・整合性） 確認方法 類似画面を洗い出し目視で 比較確認 →異なれば指摘する レビューの意図や目的を段階的に詳細化したもの。 レビュー目的を達成するための、レビューアによるレビュー対象の見方、レビュー で欠陥を見つけるために集中して着目する対象成果物の側面。さらに何を、ど のように確認するのかを表したものを含む。 レビューケース 実現手段 利用者にわかりや すい手続きの導線 を提供する 確認事項 手続きの容易性 ・簡潔性 確認方法 被験者が迷わずにタスク完 了できるか確認 →未達になるなら指摘する 【指摘事項】 〇〇と□□でつまずいて 先に進めなくなる 実現手段 おかしな操作をした際 にその旨を伝える 確認事項 エラー検知→通知の 有無 確認方法 入力必須項目空欄のまま 申請時エラーとなるか確認 →なければ指摘する 【指摘事項】 すべて入力してから知らせて いる／必須項目単位にそ の場でエラー表示すべき 28 レビュー観点 摘要： Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
29. 粒度が小さい レビュー観点は階層構造 29 抽象度の高いレビュー観点（抽象的） 人によってはその意味や内訳が異なる可能性 がある【ハイレベルレビューケース：HRC】 抽象度が低いレビュー観点（具体的） 誰がチェックしても同じ結果が導ける可能性が 高い【ローレベルレビューケース：LRC】 【ミディアムレベルレビューケース：MRC】 粒度が大きい Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 指摘 事項 指摘 事項 指摘 事項 指摘 事項
30. レビューで指摘した欠陥・不備はそれぞれ効果が異なる 指摘効果＝それを見逃した場合の悪影響度≒手戻り規模 30 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 指摘事項(欠陥・不備例) 指摘事項の意味(観点) 指摘効果 この機能構成だけでは利用者 課題を解決できない 利用者課題不解決 ＝システム目的未達 大 子供がいたずらして使うとケガを する可能性が高い 安全性未考慮 大 抽象用語と文章説明ばかりで 内容がわかりにくい 理解性・保守性未考慮 中 回収→改修 格納る→格納する 書き換込む→書き込む 誤字･脱字･衍字 小
31. 混入予防優先度が高い[エラー→欠陥]は？ 31 エラー 欠陥 指摘効果大 システム目的未達 思考 対象への理 解・認知 エラー 欠陥 指摘効果大 安全性未考慮 エラー 欠陥 指摘効果中 理解性未考慮 エラー 欠陥 指摘効果小：衍字 エラー 欠陥 指摘効果小：誤字・脱字 エラー 欠陥 指摘効果中 保守性未考慮 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 作成者と作業
32. 欠陥混入予防は「指摘効果が大きい」観点優先で 32 エラー error 欠陥 defect 故障 failure Review Test 間違った結果 を生み出す 人間の行為 思考 適切な 行動 適切な 実装 対象への理 解・認知 入力 作成者と作業 観点 観点 指摘効果が 大きい観点 適切な 振舞い 成果物 実利用 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
33. レビュー観点活用例1：フェーズのタスク設計 33 プロダクト リスク分析 過去トラブル情報 成果物によくある欠陥 作成者コンテキスト 機能構成 TASK INPUT OUTPUT Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 成果物構成案 実装すべき観点群
34. レビュー観点活用例2：成果物観点実装マッピング 成果物構成案に観点割り付け←→成果物実装→セルフチェック 34 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 実装すべき観点群[優先度考慮] 成 果 物 構 成 案
35. 戦略2：問題早期発見・解決 35 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved (1)できるだけ欠 陥や不備を作らず に開発を進める (2)欠陥や不備を作 り込んでから検出・除 去するまでのリードタ イムを最小にする でも人間は 間違うこと があるので
36. Quality･Speed･Costをマルっと変える戦略と戦術 36 (1)できるだけ欠 陥や不備を作らず に開発を進める (2)欠陥や不備を作 り込んでから検出・除 去するまでのリードタ イムを最小にする 関係者でレビュー観 点・テスト観点を共 有してから作成者が 作業に着手する でも人間は 間違うこと があるので 戦略 戦術 その実現のために 作成者が観点をベースにセルフ チェックをしっかり実践する 段階レビューで進める [部分開発→Review]×n その実現のために 【欠陥混入の予防】 【問題の早期発見・解決】 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
37. セルフチェック [欠陥･不備混入→検出･修正]リードタイムが最小 37 成果物案 作成 セルフ チェック フィードバック レビュー NG NG OK フィードバック リードタイム長い OK 作成者が観点をベースにセルフチェックをしっかり実践する 観点 観点 観点 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved リードタイム短い
38. セルフチェック徹底～レビュー開始基準励行 同じ欠陥・不備を見つけるためのレビュー工数最小化 38 指摘効果大 システム目的未達 指摘効果大 安全性未考慮 指摘効果中 理解性未考慮 指摘効果小：衍字 指摘効果小：誤字・脱字 指摘効果中 保守性未考慮 セルフ チェック レビュー                       セルフチェックによりレビューアの 質問や欠陥・不備を記録する 質問や欠陥・不備を伝える 工数が削減できる 欠陥 欠陥 欠陥 欠陥 欠陥 欠陥 成果物案 作成者が観点をベースにセルフチェックをしっかり実践する Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 修正 修正 修正 修正
39. 実利用 実利用 実利用 SWテスト 製品・サービス開発と品質保証の変遷 39 製品開発 実利用 製品設計 製品製造 検査 実利用 企画 SW 設計 SW 実装 Review 実利用 Review Review 企画 Review 設計 R 実装 R テスト 設計 R 実装 R テスト 設計 R 実装 R テスト 設計 R 実装 R テスト 実利用 製造業モデル DR 段階レビューで進める [部分開発→Review]×n 時間 時代 ソフトウェア開発モデル Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
40. 成果物案が完成してからレビュー→手戻りを促進 スピードが鈍化＋余計にコストがかかる+全員が不幸に 40 やっとできあがっ たのでレビューを お願いします 作成者の誤認識や 不認識、癖等が成果 物全体に反映される 混入した多くの欠陥を見つ ける＋記録して伝えるため に工数と時間がかかる 指摘された欠陥を漏れ なく直すために 工数と時間がかかる 他者の知見が入る 欠陥の見逃しも増える あとになってから発覚して 余計な時間と工数がかかる 一人の知見で作る Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 段階レビューで進める [部分開発→Review]×n
41. 作成 レビュー 作成 レビュー 作成：Driver フィードバック：Navigator 大量フィードバック 少量フィードバック 作成 レビュー 少量フィードバック 作成 レビュー 少量フィードバック 41 一括レビュー → 段階レビュー → モブ〇〇 へ [作成－フィードバック]のリードタイム最小化 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 一括レビュー 段階レビュー モブ〇〇 段階レビューで進める [部分開発→Review]×n リードタイム長い リードタイム短い
42. [部分成果物作成⇒レビュー]✕n回で進める 総混入欠陥数が減少し、レビュー工数も減少する 42 作成者の誤認識や 認識不足、癖等が部 分成果物に反映され る 部分成果物なので、 少ないレビュー工数 で欠陥を見つける＋ 記録して伝えられる レビュー結果により自分の 誤認識、認識不足、癖等 を把握して以降の作業を 注意しながら進められる (欠陥の作りこみが減少)     ①     ② ✕n回 修正 次の部分 成果物 作成 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 段階レビューで進める [部分開発→Review]×n すぐに他者の知見 が入る 一部分を 一人の知見で作る
43. 段階レビューにすると欠陥検出率が向上する 43 １５分×３（計４５分） 学習グループのガンマ波波形 ６０分学習グループの ガンマ波波形 集中力の維持と長期的な学習効果につながる方法 （東京大学・池谷裕二教授の見解）より http://www.asahi.com/ad/15minutes/article_02.html ※グラフ１と２のガンマ波の絶対値の大小は関係なし 1回のレビュー規模を小さく→レビュー時間短縮→欠陥検出力向上 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 段階レビューで進める [部分開発→Review]×n
44. 上流設計モデリング環境例 上流フェーズ担当者＋関係者全員がアクセス 44 成果物構築過程で、一緒に検討(モ ブ設計)したり、非同期で関係者がレ ビューして結果を都度示し(段階レ ビューと同等)、作成者が適宜それを 取り込んで修正しながら作業を進め ることが可能 チーム構造化コラボレーションツール ：Balus(バルス) https://levii.co.jp/services/balus/ Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
45. [戦略1×戦略2]の実践スタイルと位置づけ 45 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
46. 作成 レビュー 作成 レビュー 作成：Driver フィードバック：Navigator 観点・ 認識共有 大量フィードバック 少量フィードバック 修正 作成 レビュー 少量フィードバック 修正 作成 レビュー 少量フィードバック 作成 レビュー 少量フィードバック 修正 作成 レビュー 少量フィードバック 46 まとめ：[戦略1×戦略2]の実践スタイルと位置づけ Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 一括レビュー 段階レビュー 事前観点・認識共有 ＋段階レビュー モブ〇〇 欠陥混入予防 修正 作成 レビュー 少量フィードバック 問題早期発見・解決
47. この発表の意味と価値 47 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
48. Quality･Speed･Costをマルっと変える 48 【戦術1】 関係者でレビュー観 点・テスト観点を共 有してから作成者が 作業に着手する 【戦術2-2】 段階開発 段階レビュー 【戦術2-1】 作成者が観点 をベースにセルフ チェックをしっか り実践する 最初から関係者の知見を融合して作り込む【共創】 問題の早期発見･解決 部分開発 部分Review ✕n回 でも人間は 間違うこと があるので 低Cost化＆Speed Up メンバーの総力でよりよいQualityに 欠陥・不備混入予防 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
49. メンバーの総力で良いモノを作る＝共創 開発者が見えていること 開発者には見えていないこと 検証者が 見えているこ と ー 検証者には 見えていない こと 誰にも 見えていないこと 49 開発者が 検証者から 共有してもらう 検証者が 開発者から 共有してもらう 観点 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
50. 最初から品質を作り込む→関係者がみな幸せに 50 Before After 開発者 一生懸命やっているのに後出しじゃんけ ん的なダメ出しが多い 不得意・気づかないことに他者の知見や先 出支援が入るため欠陥・不備が少なくなる ダメ出しが多いので修正に時間がかかる 修正件数が少ないため短時間で済む あとフェーズで見逃した欠陥への対応が 多いため手戻り工数と余計な苦労増 見逃す欠陥も少ないため対応が最小限で 済む 検証者 欠陥・不備が多いのでチェックと記録に 時間がかかる 欠陥・不備が少ないためチェックと記録が 短い時間で済む 欠陥・不備の見逃しも多くなる →レビュー能力への疑念を持たれる 短時間レビューのため集中でき、欠陥・不備 の見逃しが減る 管理者 進捗遅延と突発問題にあくせくする 最終的にシステム品質と生産性が悪い 結果に 進捗遅延や予期せぬ問題発生が最小化 し、システム品質と生産性が高まる Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
51. 最初から品質を作り込む→関係者がみな幸せに 51 Before After 開発者 一生懸命やっているのに後出しじゃんけ ん的なダメ出しが多い 不得意・気づかないことに他者の知見や先 出支援が入るため欠陥・不備が少なくなる ダメ出しが多いので修正に時間がかかる 修正件数が少ないため短時間で済む あとフェーズで見逃した欠陥への対応が 多いため手戻り工数と余計な苦労増 見逃す欠陥も少ないため対応が最小限で 済む 検証者 欠陥・不備が多いのでチェックと記録に 時間がかかる 欠陥・不備が少ないためチェックと記録が 短い時間で済む 欠陥・不備の見逃しも多くなる →レビュー能力への疑念を持たれる 短時間レビューのため集中でき、欠陥・不備 の見逃しが減る 管理者 進捗遅延と突発問題にあくせくする 最終的にシステム品質と生産性が悪い 結果に 進捗遅延や予期せぬ問題発生が最小化 し、システム品質と生産性が高まる Copyright © Kenji Adachi@Software Quasol, All Rights Reserved 手戻り工数が減る ↓ 時間に余裕が生まれる ↓ マネージャ・リーダー・エンジ ニアとしてより価値のあるタ スクやトレーニングに有効活 用できる（QoLが高まる）
52. この提案の実践に必要なこと 52 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
53. チームの自律的な 課題発見(と解決) この提案の実践に必要なこと 53 ダイバーシティ＆ インクルージョン 多様性と受容 グロース マインド 協調による相互成長 内発的動機 内面で沸き起こる興味・関心・意欲 検証観点設計 →観点を用いた 検証実践 検証結果や市場 不具合の分析実 践を通じた品質・ 価値観の共有 顧客の課題・コンテ キスト・関心事の積 極的把握と共有・活 用 Copyright © Kenji Adachi＠Software Quasol, All Rights Reserved 組織的 要因 技術的 要因
54. おわりに 54 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved
55. シャープ伝説のエンジニア 佐々木正氏（シャープ元副社長）の座右の銘 「いいかい、君たち。分からなければ聞けばいい。 持っていないなら借りればいい。逆に聞かれたら教 えるべきだし、持っているものは与えるべきだ。人 間、一人でできることなど高が知れている。 技術の世界はみんなで共に創る『共創』が肝心 だ。」 55 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved https://kitto-cea.com/column/detail/17
56. 参考文献 • Software Quality In 2008(JaSST’08東京) Capers Jones https://www.jasst.jp/archives/jasst08e/pdf/A1.pdf • ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf • 50分でわかるテスト駆動開発 / TDD Live in 50 minutes https://speakerdeck.com/twada/tdd-live-in-50-minutes?slide=9 • TDDとBDD/ATDD(3) BDDとATDDとSbE https://sqripts.com/2023/08/07/61460/ • TDDとBDD/ATDD(4) ツールとしてのBDDとプロセスに組み込まれたBDD https://sqripts.com/2023/08/28/61494/ • 観点活用レビューワークでわかったこと 一意な観点設定から観点設計への壁(SQiP2024) • 集中力の維持と長期的な学習効果につながる方法（東京大学・池谷裕二教授の見解） http://www.asahi.com/ad/15minutes/article_02.html • システムモデルを用いた対話型上流設計によるサービス開発 - モデルで納品・モデルで開発・モデルで検証 -（三浦 政司） • 【ロケット・ササキ】 https://kitto-cea.com/column/detail/17 56 Copyright © Kenji Adachi@Software Quasol, All Rights Reserved