Scrum Fest Niigata 2025 Closing Keynote

基調講演「品質の原理・原則と研究事例 ー 品質やQA活動をいつもと違う視点で考える」

Transcript

1. 森崎 修司 名古屋大学 大学院情報学研究科 品質の原理・原則と研究事例 品質やQA活動をいつもと違う視点で考える
2. 自己紹介 • 小学5年生からプログラミングを始める。 • 2001～2005年 インターネットサービスプロバイダに勤務 – ストレージサービス開発、RFID国際標準策定 • 2005年～ソフトウェアエンジニアリングの研究 – 58社と機密保持契約下の共同研究 – 11名の社会人博士の支援、学位審査 – 論文140編超、著書10冊（共著、分担執筆含む） – 元エンジニアだからこそ設定できるテーマを目指す。 • 日本品質管理学会評議員（2022年～） • IPA ワーキンググループ主査（3グループ） • ソフトウェア品質シンポジウム2013～2024 企画委員長 • モビリティベンチャーの技術顧問 • https://x.com/smorisaki/ 2
3. アジェンダ • 品質 – 品質の難しさ – 日本的品質管理(TQM: Total Quality Management)とアジャイルの共通点 – 品質と価値 – バグを見つける方法とタイミング • 研究事例 – 継続的インテグレーションでの実行時間の短縮 – 分析、設計モデルの時点で実装するとバグが入り込みやすい部分を特定しておいて バグ修正の時間を減らす – アジャイル開発でのバグ検出のフロントローディング – 生成AIを使った既存コード理解 3
4. 品質の難しさ • パターン化したり、明示的にとらえたりするのが難しい。 • さまざま – ソフトウェア – ユーザー – その他のコンテキストによってさまざま • 評価 – ユーザーの主観 – 様々な要素 – 代用特性を使うことが多い。 • コミュニケーション – 品質の問題を見つけるスキルとそれを伝えるスキルは別もの （→ 略） 4
5. 品質の難しさ – おおざっぱに決められるが細かく確かめる必要 • 欠けているときは簡単にわかるが、説明するのは難しい*。 • ISO 9000 「対象に本来備わっている特性の集まりが、要求事項を満たす程度」 – ISO25000でもこの定義を参照 – 少し具体化すると「ソフトウェアが提供する機能がユーザの要求を満たす程度」とな るが、共通認識を得にくく、イメージしづらい。 – 例） • アクションゲーム: 遊ぶたびにそこそこ成長を感じられて、スカッとする。 • 車載安全支援システム: 必要な際に適切な支援ができ、誤作動せず、故障時の対処 ができる 5 ISO9000: Quality management systems ISO25000: Systems and software Quality Requirements and Evaluation * Kitchenham, B., & Pfleeger, S. L. (1996). Software quality: the elusive target, IEEE software, 13(1), 12-21
6. 品質の難しさ – さまざま • さまざまな要求事項があるが、それぞれユーザーの満足に影響する。 – ソフトウェア、関係者（ユーザ）、その他のコンテキスト – 要求事項のバランス自体も品質に影響がある。 – 「ソフトウェア」とひとくくりにできないくらい多岐にわたっている。 – 関係者 • ビジネスオーナー、発注者、ユーザー • 規模が大きくなると「ユーザー」もさまざま。 – コンテキスト • 競合、時代背景、市場の状況、ユーザーの環境、規制／法令 6
7. 品質の難しさ ー さまざま • 要求事項はソフトウェア、関係者（ユーザー）、コンテキストによって様々 – 同じユーザーであっても利用シーンやユーザーの状況や慣れによっても変わる。 7
8. 品質の難しさ ー さまざま • ユーザー、発注者によって要求事項への理解や明確さが違う。 – 開発チームと同等に詳しい場合（特定B2B） – 開発チームのほうがかなり詳しい場合（不特定多数B2C） 8
9. 品質の難しさ ー さまざま • ISO 25000シリーズのソフトウェア品質特性 （品質を属性に分解したもの） – 製品品質（8属性） • 外部品質 – 機能適合性: 明示的、暗示的なニーズを満足する機能を提供する度合い – 性能効率性: 明記された状態（条件）で仕様する資源の量に関係する性能の度合い – セキュリティ・・・ • 内部品質 – 保守性: 意図した保守者が修正することができる有効性及び効率性の度合い – … – 利用時の品質（5属性） • 効率性: 目標を達成するための正確さ及び完全さに関連してしようした資源の度合い • ・・・ 東 基衞, システム・ソフトウェア品質標準SQuaREシリーズの歴史と概要, SEC Journal, vol. 10, No. 5, pp. 15-22 (2015) https://www.ipa.go.jp/archive/files/000065855.pdf 9
10. 品質特性の活用 • 評価対象（ユーザーストーリー、機能、コンポーネント）ごとに品質特性を考えた ほうがよいものがある。 – 例） • レスポンスが大事なユーザーストーリー（性能効率性→時間効率性） • 途中でundo（やり直し）できることが大事なユーザーストーリー （使用性→ユーザエラー防止性） – 2つ以上の品質特性が重視されることがある。 – 両立しづらい品質特性があり、バランスをとる必要がある。 （使用性とセキュリティ） • 保守性や移植性のような内部品質はコードを書くメンバーで考える。 10
11. 品質の難しさ – 代用指標を使った評価 • 「性能」の代用指標の例） サーバからのレスポンス時間 – 代用指標で計測できる品質ばかりではない。 例） 使いやすさ、セキュリティ – 適切な代用特性も一定範囲外では効果が薄れることが多い。 例） レスポンス時間、省リソース、リリース頻度 11 ユーザーの満足度（架空の指標） レスポンス時間 ユーザーの満足度が反応しやすい 満足度の反応が鈍い
12. 品質の難しさ – Garvinの研究 • 1980年代の製品品質の調査 • 品質評価の方法 – 超越論(Transcendental approach: 理屈では説明できない) 直感的な感覚で品質がとらえられ、明確な定義はできない。 – 製品起点 製品の属性 – ユーザー起点 ユーザーのニーズや好みを満たす度合い – 開発起点 仕様や基準への適合度（欠陥が少ないと高品質） – 価値起点 品質を価格に見合う価値（支払意思額） 出典: Garvin David A., What Does “Product Quality” Really mean, Sloan management review, vol. 25, pp.25-43(1984) https://sloanreview.mit.edu/article/what-does-product-quality-really-mean/ 12
13. 品質の難しさ – Garvinの研究 • 品質の側面 – 性能 – 特徴 – 信頼性 – 耐久性 – サービス性: 修理やメンテナンス、スピード、正確さ – デザイン性: 製品の外観や感触 – 知覚品質: ブランドイメージや評判 側面の詳細は https://note.com/smorisaki/n/n8d3a5f18d8e4 出典: Garvin David A., What Does “Product Quality” Really mean, Sloan management review, vol. 25, pp.25-43(1984) https://sloanreview.mit.edu/article/what-does-product-quality-really-mean/ 13
14. 品質の難しさ – Garvinの研究（1984） 出典: Garvin David A., What Does “Product Quality” Really mean, Sloan management review, vol. 25, pp.25-43(1984) https://sloanreview.mit.edu/article/what-does-product-quality-really-mean/ 14
15. 品質の難しさ – Garvinの研究 出典: Garvin David A., What Does “Product Quality” Really mean, Sloan management review, vol. 25, pp.25-43(1984) https://sloanreview.mit.edu/article/what-does-product-quality-really-mean/ 15 製品の品質は急速に重要な競争上の課題となりつつ あります。多くの日本製品の優れた信頼性が、アメリカ の経営者の間で相当な内省を引き起こしています。 （Gemini 2.0 Flushによる翻訳）
16. 日本的品質管理 • 日本的品質管理の代表例: TQM(Total Quality Management) • 日本的品質管理とアジャイル／スクラムの共通点は性善説を前提としている点 • TQMの原則 – 目指すこと • マーケットイン • 後工程はお客様 • 品質第一 – 手法 • プロセス重視 • 標準化 • 源流管理 出典: 中條武志，山田秀編著，日本品質管理学会標準委員会編，寺部哲央，平林良人，棟近雅彦，村川賢司，矢 野友三郎著，TQMの基礎，日科技連出版(2006) 16
17. TQMの原則 – 手段、組織運営、ツール・手法 • 手段 – PDCAサイクル – 再発防止 – 未然防止 – 潜在トラブルの顕在化 – QCD結果にもとづく管理 – 重点志向 – 事実にもとづく管理 • 組織運営 – リーダーシップ – 全員参加 – 人間性尊重 – 教育・訓練の重視 17 出典: 中條武志，山田秀編著，日本品質管理学会標準委員会 編，寺部哲央，平林良人，棟近雅彦，村川賢司，矢野友三郎 著，TQMの基礎，日科技連出版(2006) • ツール・手法 – QFD（品質機能展開） – FMEA, FTA – 工程能力指数 – 改善の手順 – QC七つ道具 – 統計的方法 – 言語データ解析法 – ほか7件
18. TQMの原則 － 目指すこと、手法 1. 目指すこと a. マーケットイン: 顧客起点でニーズをつかみ、製品・サービスを開発・生産する。 b. 後工程はお客様: 後工程をお客様のように考え、後工程の立場に立って担当業 務のできばえを評価する。 c. 品質第一: 品質を第一とし、製品・サービスの提供およびそのための技術を作って いく。 2. 手法 a. プロセス重視: プロセス（仕事のしくみ・やり方）に着目し、管理、向上する。 b. 標準化: もっとも優れた方法を標準とし、これに則って行動する。 c. 源流管理: 仕事の流れの源流（上流）にさかのぼって、品質向上やサービスのしく みを掘り下げる。 18
19. TQMの原則 ー 手段 3. 手段 a. PDCAサイクル: 計画(Plan)、実施(Do)、結果の確認(Check)、改善(Act)のサイ クルを継続的に繰り返し、プロセス・しくみをレベルアップする。 b. 再発防止: 問題が発生したときに同じ原因で問題が起きないように対策する。 c. 未然防止: 問題を計画段階で考えておき、修正、対策する。 d. 潜在トラブルの顕在化: 報告されていない、表面化されていないクレーム、トラ ブルを明らかにする。 e. QCD(結果)に基づく管理: 結果に着目し、プロセス・しくみを議論する。 f. 重点志向: 結果に大きな影響を与えている問題に着目する。 g. 事実に基づく管理: 経験や勘にのみ頼るのでなく、データや事実に基づいて管 理する。 19
20. TQMの原則 ー 組織運営 4. 組織運営 a. リーダーシップ: 経営者・管理者がニーズ・期待を考え、価値観や高いパフォーマ ンスを示し、将来の仕事の機会を探すうえで適切な役割を果たす。 b. 全員参加: すべての部門のすべての職位の人が参加してTQMに取り組む。 c. 人間性尊重: 人間らしさを尊び、人間として特性を十分に発揮できるようにする。 d. 教育・訓練の重視: 知識、技能、モラルの向上により、社員一人ひとりの能力や 資質を対象に、長期的な視野に立って人材の開発、育成する。 20
21. TQMの原則 ー ツール・手法 • 具体的なツール・手法はそのままソフトウェアに流用するのは難しい。 • QFD（品質機能展開）: 要求品質から設計品質への変換 • FMEA, FTA: 不具合の連鎖や逸脱が起こる条件を洗い出して対策 • 工程能力指数: 安定した工程の生産性メトリクス • 改善の手順: データにもとづく改善の手順 • QC七つ道具: チェックシート、パレート図、ヒストグラムをはじめとする分析方法 • 統計的方法: 検定、推定、相関、多変量解析をはじめとする数学的方法 • 言語データ解析法: 親和図、連関図法をはじめとする分析方法 • ほか7件 21
22. TQMの威力 • TQMエキスパート6名から以下の提案、私見への賛同をもらった。 • 経営層を含め各階層で共通言語になっている。 – 「PDCA」「顧客目線」といった言葉で伝わる情報が多く、意思疎通が早い。 – 経営、管理職、設計、生産の間で共通言語になっており、考え方にコミットメントがある。 – 「TQM推進部」のような専門部門がある。 – 会社を超えて議論し、継続的に改善できる。 • 考え方（プロセスの側面）と実行（マインド、工夫）の両面の議論や記録がある。 – 様々な役割や階層で考え方、実行ともに議論され、その（一部が）記録が残っている。 – 「とはいえ、ここは注意が必要」といった工夫に関する書籍、記録が多い。 22
23. いろいろなところで流用可能なものも多い • 例） 「質創造」マネジメント，編: 中部品質管理協会，監修: 古谷 建夫 – 3.2.4節「正直にものが言える職場風土づくり」 人は皆、いつもと違うことに遭遇した際には，少なくとも身近な人（直属の上司や先 輩、同僚）に伝えようとするものである。しかし，その異常が自らの失敗やミスによっ て引き起こされた場合は，必ずしもそうならない。正直に話をしたのに，訳も効かず に管理者や上司が叱ったり，起こったりするような環境では，影響がお客様に直接 及ぶような大きな問題でない限り、当人もしくはその極近い人たちだけで，応急処置 をしてしまうのではないだろうか。・・・ • 心理的安全性を母国語でニュアンスまでわかる表現で読める。 23
24. TQMのツール・手法にあたる部分 • 流用できるものは限られる（4件／14件）。 – QFD（品質機能展開） – FMEA(Failure Mode and Effects Analysis: 故障モード影響解析), FTA(Fault Tree Analysis: 故障の木解析) （ミッション／セーフティクリティカル分野において） – 管理項目一覧表 – ぽかよけ（エラープルーフ） • 具体的な活動や考え方は他の分野を参考にしたほうがよさそう。 24
25. 手法やツールレベル • 現時点で入手できる公開情報では明らかになっていない。 （存在しないかもしれない） • ソフトウェアに合わせて考える必要がある。 – 「要求事項(ISO 9000/25000)」を的確にとらえる。 – 要求事項が満たされているか過不足なく評価する。 – 他のソフトウェアでの内容を流用できることは少ない。 25
26. アジェンダ • 品質 – 品質の難しさ – 日本的品質管理(TQM: Total Quality Management)とアジャイルの共通点 – 品質と価値 – バグを見つける方法とタイミング • 研究事例 – 継続的インテグレーションでの実行時間の短縮 – 分析、設計モデルの時点で実装するとバグが入り込みやすい部分を特定しておいて バグ修正の時間を減らす – アジャイル開発でのバグ検出のフロントローディング – 生成AIを使った既存コード理解 26
27. 自分たちのソフトウェアをより深く理解 • 対象ソフトウェア、要求事項、価値を理解する。 • アジャイル／スクラムは相性がよい。 – 必要な部分は詳細にそうでない部分はそこそこで理解する。 – チーム全員で理解を深め、共通認識を作る。 – 仮説検証を繰り返す。 • テスト、QAエンジニアも相性がよい（私見）。 – 全体感をもってソフトウェアをとらえることができる。 – ユーザーがはまりやすい箇所を想像できる。 – 起こりやすい実装の考慮漏れを知っている。 – リスクの見積りができるため、過不足なく評価できる。 – プロダクトオーナーよりも詳細なレベルで理解できる部分がある。 27
28. いい感じで理解するには • ソフトウェア自体 – 振る舞い – 構造 – 実装 • 品質やユーザーの価値 • イテレーション、スプリントに合わせて、バグを見つける方法 28
29. 出典: Hiromi Morikawa,デザイナーの帽子をかぶったわたしが、プロダクト開発するうえでスクラムチーム に提供したいこと, Scrum Fest Fukuoka 2024 https://speakerdeck.com/hiromitsuuuuu/what-i-want-to- provide-to-scrum-teams-when-developing-products 29
30. 出典: Hiromi Morikawa,デザイナーの帽子をかぶったわたしが、プロダクト開発するうえでスクラムチーム に提供したいこと, Scrum Fest Fukuoka 2024 https://speakerdeck.com/hiromitsuuuuu/what-i-want-to- provide-to-scrum-teams-when-developing-products 30
31. いい感じで理解するには • ソフトウェア自体 • 品質とユーザーの価値 • イテレーション、スプリントに合わせて、バグを見つける方法 31
32. 想定した価値 32 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 価値の高いものから順に実 装する。
33. 価値 • 狩野モデルで有名 • ハーズバーグの衛生理論（Hygiene Theory）、二要因理論 – 衛生要因: 満たさないと不満足を増やす要因 • 原典で挙げられている要因: 労働条件、雇用の安定、上司 • 例） バグが少ない。 – 動機づけ要因: 満足を増やすことによる要因 • 承認、昇進、責任範囲の拡大 • 例） 新しい機会による業務目標やビジネス目標の達成 33
34. 作り手の品質 • ユーザーストーリー、機能等を実装する前に想定した価値を提供できているか 確認することが品質評価や品質保証である。 34 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 要求品質を満たせていない ために目減りした価値（テス トと修正等で防げる）
35. 作り手の品質 • ユーザーストーリー、機能等を実装する前に想定した価値を提供できているか 確認することが品質評価や品質保証である。 例）音声で指定した場所と日時の天気の予報を音声で受け取る。 35 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 音声認識の精度が低く、場 所の認識を間違うことがある が、リリースした
36. 作り手の品質と実際の価値 • 実際にはユーザーのスキル、環境をはじめとした要因により期待する価値が得ら れない場合がある。 36 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 実際に使った 時点での価値 要求品質を満たせていない ために目減りした価値（テス トと修正等で防げる） 誤操作、スキル不足、操作の難 しさ、環境等で想定した使い方 ができない
37. 作り手の品質と実際の価値 • 実際にはユーザーのスキル、環境をはじめとした要因により期待する価値が得ら れない場合がある。 例）音声で指定した場所と日時の天気の予報を音声で受け取る。 37 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 実際に使った 時点での価値 音声認識の精度が低く、場 所の認識を間違うことがある 声が小さすぎて正しく認識できな い
38. ユーザーが感じる価値 • ユーザーが事前に想定した価値との差を品質と感じることが多い。 38 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 実際に使った 時点での価値 要求品質を満たせていない ために目減りした価値（テス トと修正等で防げる） 誤操作、スキル不足、操作の難 しさ、環境等で想定した使い方 ができない ユーザーが 想定する価値 実際に使った時点での差 を品質と感じることが多い
39. ユーザーが感じる価値 • ユーザーが事前に想定した価値との差を品質と感じることが多い。 例）音声で指定した場所と日時の天気の予報を音声で受け取る。 39 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 実際に使った 時点での価値 ユーザーが 想定する価値 大きい声でしか操作できな いなら恥ずかしくて使えない 声が小さすぎて正しく認識できない
40. ユーザーが感じる価値 • ユーザーが事前に想定した価値との差を品質と感じることがある。 40 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 実際に使った 時点での価値 ユーザーが 想定する価値 （実際より高い） 実際に使った時点での差 に応じて低い品質と感じる ユーザーが 想定する価値 （実際より低い） 実際に使った時点との差 に応じて品質を高く感じる
41. ユーザーが感じる価値 • ユーザーが期待する品質を超えていると魅力的品質、顧客歓喜につながる。 例）音声で指定した場所と日時の天気の予報を音声で受け取る。 41 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 実際に使った 時点での価値 ユーザーが 想定する価値 （実際より高い） 大きい声でしか操作でき ないなら恥ずかしくて使え ない ユーザーが 想定する価値 （実際より低い） クルマに乗りながら使うの で、大声で何度か言い直 すのは想定内
42. 品質と価値 • 価値は陳腐化したり当たり前になっていくので、新たな価値を提供する必要があ る。 42 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 実際に使った 時点での価値 ユーザーが 想定する価値 （実際より高い） ユーザーが 想定する価値 （実際より低い） ユーザーが想定する価値 は時間や成熟によって少 しずつ上がっていく
43. ユーザーが感じる価値 • ユーザーが感じる価値は作り手だけでは決められない。 （価値提案しかできない） – サービスドミナントロジック*が参考になる。 • 「関係者で価値を共創する」と考える。 「供給側から消費側に製品を受け渡し対価を払う」という考え方とは違う。 • どういうユーザーがいて、それぞれのユーザーにとっての価値は何かを考える。 • 音声で指定した場所と日時の天気の予報を音声で受け取る例） – ユーザーの音声の明瞭さ、大きさ、使う環境によっては価値が目減りするが、目減り した価値がユーザーにとっての価値 *: Vargo, Stephen L., Robert F. Lusch, Evolving to a New Dominant Logic for Marketing, Journal of Marketing vol 68, no. 1, pp. 1-171 (2004) 43
44. ユーザーが感じる価値 • 価値は実用性や目的達成だけではない。 • Shethらの価値の調査* – 機能的価値: 製品、サービスの性能、品質、信頼性をはじめ問題解決や実用性 – 経済的価値: 価格、コストパフォーマンス、経済的メリット – 社会的価値: 他者からの承認、社会的地位、所属集団との一体感、自己表現 – 情緒的価値: 喜び、わくわく、安心感をはじめ製品やサービスを使うことで得る感情 、感覚 • ソフトウェア（用途、種類、提供形態）やユーザーによって求める価値が違う。 – ユーザー自身が十分に把握できていないことがある。 – ユーザーのほうが詳しい場合もある。 *: Sheth, J. N., Newman, B. I., Gross, B. L., Why we buy what we buy: A theory of consumption values. Journal of business research, 22(2), pp. 159-170(1991) 44
45. いい感じで理解するには • ソフトウェア自体 • 品質とユーザーの価値 • イテレーション、スプリントに合わせて、バグを見つける方法を選ぶ 45
46. バグ分類と見つける方法の例: 境界値分析 • 仕様に沿ってプログラムを書くときに、条件分岐の境界値を間違って実装しやす いので、その境界値をテストするとバグをみつけやすい（経験則）。 例） – 仕様の例 「18歳未満であれば未成年、18歳以上であれば成年」 – 条件分岐の例「if (age < 18) { print(“未成年”)}else{print(“成年”);} 」 – 境界値の例「17, 18, 19」 46 プログラムを書く時点 （バグの混入） テスト （バグの検出） コードレビュー （バグの検出） コードレビューで検出する場合 テストで検出する場合 検出の手間をはじめ合理 的な品質評価方法を選ぶ 品質評価（未然防止、検出の方法）
47. バグ分類と見つける方法の例: 境界値分析 • 仕様に沿ってプログラムを書くときに、条件分岐の境界値を間違って実装しやす いので、その境界値をテストするとバグをみつけやすい（経験則）。 例） – 仕様の例 「18歳未満であれば未成年、18歳以上であれば成年」 – 条件分岐の例「if (age < 18) { print(“未成年”)}else{print(“成年”);} 」 – 境界値の例「17, 18, 19」 47 プログラムを書く時点 （バグの混入） テスト （バグの検出） コードレビュー （バグの検出） コードレビューで検出する場合 テストで検出する場合 ②検出の手間や影響の大きさ等か ら合理的な検出方法を選ぶ ①実装ミスがなけ れば、境界値テスト の効果は下がる プログラムを書く時点で未然防止 リリース後 （問題／バグの検出） 使い始めてから変更する場合 スプリントプランニング ユーザーストーリー 作成
48. バグを見つけるタイミングや方法 • 見つける方法が複数あれば、合理的な方法を選ぶ（必要なら併用）。 選ぶ基準の例） – 簡単に見つけられるか（検出できる）？ – 低コストで検出（評価）できるか？ – リスク低減／ユーザ価値向上につながるか？ 48 混入 見つける方法B 未然防止できなければ混入する 手間 未然防止 見つける方法A 合理的な（たとえば手間が小さい）方法で未然防止か見つける
49. 出典: Yasunobu Kawaguchi, Agile Testing Book https://speakerdeck.com/kawaguti/agile-testing-book 参考: J. Crispin, L. Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams, Addison- Wesley (2008) 49
50. 出典: Yasunobu Kawaguchi, Agile Testing Book https://speakerdeck.com/kawaguti/agile-testing-book 参考: J. Crispin, L. Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams, Addison- Wesley (2008) 50
51. 具体的なコミュニケーション 出典: Yasunobu Kawaguchi, Agile Testing Book https://speakerdeck.com/kawaguti/agile-testing-book 参考: J. Crispin, L. Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams, Addison- Wesley (2008) 51
52. 品質と価値 • ユーザーが期待する品質を超えていると魅力的品質、顧客歓喜につながる。 52 実装を決めた時点 での価値の想定 価値の大きさ （架空の指標） 実装できた時点 での価値 実際に使った 時点での価値 ユーザーが 想定する価値 （実際より高い） 実際に使った時点での差 に応じて低い品質と感じる ユーザーが 想定する価値 （実際より低い） 実際に使った時点との差 に応じて品質を高く感じる。
53. 53 バグ分類の設定方法 出典: 森崎 修司: なぜ重大な問題を見逃すのか？ 間違いだらけの設計レビュー 第3版, 日経BP(2023) 保証すべき内容を明らかにし、それ を損なうバグ分類を選ぶ方法(I) (I-1)提供できていない保証内容、提供することを明示して いる保証内容から、それを損なうバグ分類を見つける (I-2)システムが担うビジネスや業務、環境から期待される 価値を見つけて、その提供を損なうバグ分類を見つける バグ分類を直接選定する方法(D) (D-1)過去のバージョンや類似のシステムでのレビュー指 摘や検出されたバグを参考にする (D-2)システムの構成や要素技術が共通する他のシステ ムのレビュー指摘や検出されたバグを参考にする
54. アジェンダ（再掲） • 品質 – 品質の難しさ – 日本的品質管理(TQM: Total Quality Management)とアジャイルの共通点 – 品質と価値 – バグを見つける方法とタイミング • 研究事例 – 分析、設計モデルの時点で実装するとバグが入り込みやすい部分を特定しておいて バグ修正の手間を減らす – バグ検出のフロントローディング – 生成AIを使った既存コード理解 – 継続的インテグレーションでの実行時間の短縮 54
55. 設計ダイアグラムの時点からコードのバグを予測 55 出典: 公文一博、今西 洋二，ソニーが挑むソフト設計工程の改善、欠陥リスクを発見する「パターン」とは，日経xTech (2023) https://xtech.nikkei.com/atcl/nxt/column/18/02403/032300003/ 参考: Y. Imanishi, K. Kumon, S. Morisaki, Identifying Defect Injection Risks from Analysis and Design Diagrams: An Industrial Case Study at Sony, IEEE/ACM 45th International Conference on Software Engineering 2023: Software Engineering in Practice (ICSE-SEIP), pp. 420-431 (2023)
56. 設計ダイアグラムの時点からコードのバグを予測し注目 • 設計ダイアグラム作成時点で、バグが含まれそうなコードを予測する。 • コードレビュー、テストの重点化ができる。 56 出典: 公文一博、今西 洋二，ソニーが挑むソフト設計工程の改善、欠陥リスクを発見する「パターン」とは，日経xTech (2023) https://xtech.nikkei.com/atcl/nxt/column/18/02403/032300003/ キューを実装するときはオーバー フローに注意する 対応するコードに注意する
57. アジェンダ（再掲） • 品質 – 品質の難しさ – 日本的品質管理(TQM: Total Quality Management)とアジャイルの共通点 – 品質と価値 – バグを見つける方法とタイミング • 研究事例 – 分析、設計モデルの時点で実装するとバグが入り込みやすい部分を特定しておいて バグ修正の手間を減らす – バグ検出のフロントローディング – 生成AIを使った既存コード理解 – 継続的インテグレーションでの実行時間の短縮 57
58. イテレーション中にみつかったバグ検出のフロントローディング • 目的: 少しの工夫でバグ対応の手間を小さくできるものはないか探す。 • 方法: 記録されているバグを早く見つけたり未然防止できないか確かめる。 – 少ない手間で品質チェックできる • 対象データ – 「優先度」が「低」以外のバグ77件（「低」は早期に見つけようとしていないかもしれない） – アプリケーションソフトウェア開発で収集 58 出典: 谷﨑，田上，蛭田，森，森崎: アジャイル開発に適した品質チェック項目の構造化，ソフトウェア品質シンポジウム 2020 https://www.juse.jp/sqip/library/shousai/?id=486 バグ発見 バグ混入 バグの記録から、「もっと早く見つけら れたのでは？」「そもそも未然防止でき たのでは？」を推測 早期発見 未然防止
59. バグのフロントローディング – 結果 • 77件中57件が早くみつけたり未然防止できたりした可能性がある。 59 出典: 谷﨑，田上，蛭田，森，森崎:アジャイル開発に適した品質チェック項目の構造化，ソフトウェア品質シンポジウム 2020 https://www.juse.jp/sqip/library/shousai/?id=486 品質チェックの内容 該当するバグの件数 仕様同士の関係性は適切か 2 実際にエンドユーザが使う上で問題がないか 5 受け入れ基準が適切に定義されているか 12 技術的な制約が考慮されているか 3 受け入れ基準を満たすことを確認できるテストケースになっているか 26 テストコードが期待通り実装されているか 9
60. アジェンダ（再掲） • 品質 – 品質の難しさ – 日本的品質管理(TQM: Total Quality Management)とアジャイルの共通点 – 品質と価値 – バグを見つける方法とタイミング • 研究事例 – 分析、設計モデルの時点で実装するとバグが入り込みやすい部分を特定しておいて バグ修正の手間を減らす – バグ検出のフロントローディング – 生成AIを使った既存コード理解 – 継続的インテグレーションでの実行時間の短縮 60
61. 目的と方法 • 目的: 技術的負債をかかえたコードでも生成AIを使えば読むのがラクになるか 確かめる。 • 方法: 代表的な技術的負債をもつ2つのコードを準備し、エンジニアの方に実際 にコードを読んでもらう。 • 対象コード – 命名の問題(LA: Linguistic Anti-pattern): 名前がおかしい – 構造の問題: 条件分岐が多い • グループ – 慣れている生成AIを使ってもらって、命名の問題を含むコードを読む – 慣れている生成AIを使ってもらって、構造の問題を含むコードを読む – 生成AIを使わずに命名の問題を含むコードを読む – 生成AIを使わずに構造の問題を含むコードを読む 61
63. アジェンダ（再掲） • 品質 – 品質の難しさ – 日本的品質管理(TQM: Total Quality Management)とアジャイルの共通点 – 品質と価値 – バグを見つける方法とタイミング • 研究事例 – 分析、設計モデルの時点で実装するとバグが入り込みやすい部分を特定しておいて バグ修正の手間を減らす – バグ検出のフロントローディング – 生成AIを使った既存コード理解 – 継続的インテグレーションでの実行時間の短縮 63
64. 課題: 継続的インテグレーションで実行するテストと選択 • テスト規模が大きくなると継続的インテグレーションでのテストにかかる時間が問 題になる。 • なんらかの方法で実行するテストを減らす必要がある。 – Dailyでは代表的な部分（短時間で終わるようにする） – Weeklyではすべてのテスト（時間がかかってもよいとする） 64 Weekly Daily 実行するテスト 実行しないテスト
65. コードカバレージによる選択 • Dailyを選ぶ基準としてコードカバレージを調査 – あるテストSxを実行すると実行されるプロダクトコードを調べる – 複数の種類のカバレージがあり、メソッドカバレージで調査 65 テストSx int validate_plan() { … } void pre_check() { … } boolean finalize() { … } テストSy テストSz テストSxとSzで実行されるメソッドが同じで あれば、どちらかだけ実行する。
66. 対象ソースコードとテスト • 自動車の自動運転のシステムAutowareを対象にテストと実行されるプロダクトコ ードを調査 • テスト: 3749件、対象メソッド: 約4576件 66 ID メソッド数 テスト数 1 940 3748 2 336 3749 3 222 3490 4 175 3463 5 160 3740 6 152 3711 7 118 3719 8 77 3747 9 75 532 10 58 3744 ID メソッド数 テスト数 11 53 56 12 47 667 13 43 3738 14 42 29 15 39 3465 16 38 3437 17 36 1 18 36 332 19 31 3461 20 31 29
67. ID メソッド数 テスト数 1 940 3748 2 336 3749 3 222 3490 4 175 3463 5 160 3740 6 152 3711 7 118 3719 8 77 3747 9 75 532 10 58 3744 ID メソッド数 テスト数 11 53 56 12 47 667 13 43 3738 14 42 29 15 39 3465 16 38 3437 17 36 1 18 36 332 19 31 3461 20 31 29 対象ソースコードとテスト • 自動車の自動運転のシステムAutowareを対象にテストと実行されるプロダクトコ ードを調査 • テスト: 3749件、対象メソッド: 約4576件 67 3748件のテストで実行の有無が一 致するメソッドの数が940である。 3749件のテストで実行の有無が一 致するメソッドの数が336である。 各行でテストは重複するものがある が、メソッドの重複はない。
68. ID メソッド数 テスト数 1 940 3748 2 336 3749 3 222 3490 4 175 3463 5 160 3740 6 152 3711 7 118 3719 8 77 3747 9 75 532 10 58 3744 ID メソッド数 テスト数 11 53 56 12 47 667 13 43 3738 14 42 29 15 39 3465 16 38 3437 17 36 1 18 36 332 19 31 3461 20 31 29 対象ソースコードとテスト • 自動車の自動運転のシステムAutowareを対象にテストと実行されるプロダクトコ ードを調査 • テスト: 3749件、対象メソッド: 約4576件 68 もしかすると、3748件を少数で代表で きる可能性がある。 Dailyでは少数の代表のみ実行する。 変更／修正したメソッドが含まれるテストで代 表できる可能性がある。 変更／修正確認は対応するテストのみにし、 デグレードの確認は全数テストとする
69. まとめ • 品質の難しさを説明した。 • 日本的品質管理とアジャイルの共通点をみんなで議論した。 • ユーザーが感じる価値は作り手側だけでは決められないことを説明した。 • 品質と価値を比較した。 • バグを見つけるタイミングと手間を説明した。 • 研究事例を紹介した。 • 謝辞 – 日本的品質管理に関する議論に加わってくださった方に感謝する。 – 本資料作成にあたり、スクラムフェス 新潟 実行委員会、伊藤 潤平氏、品川アジャ イルコミュニティ、川口恭伸氏に協力をいただいた。 • 今後の情報 https://x.com/smorisaki/ https://note.com/smorisaki Voicy 69