品質を経営にどう語るか #jassttokyo / Communicating the Strategic Value of Quality to Executive Leadership

https://jasst.jp/tokyo/26-timetable/ での発表資料です。

AI活用を前提としていくDXや製造業サービスでは非構造データが多く、自動化による品質保証が難しくなっています。QA4AIなどの議論が進んでいることからも従来のテスト理論がそのままでは機能しません。2026年では開発プロセス自体にAIも入り込んでおりその不確実性はさらに増加しています。
本セッションでは、PdMとQAが経験した「品質活動を上長に伝えきれなかった失敗」や「AI前提の不確実性に対して消極的になってしまった失敗」を出発点に、Cost of Qualityやデジタル経済と製造業DXの研究、DXリスク評価モデルなどの理論・調査結果を背景に紹介しつつ、現場とのギャップを率直に議論します
様々な障害を組織変革のきっかけに変える視点を、対談形式でお届けします。

Transcript

1. 品質を経営にどう語るか JaSST Tokyo 2026 kyon_mm/naco_mm/moriyuya < Confidential >
2. 2 • AI活⽤を前提としていくDXや製造業サービスでは⾮構造データが 多く、⾃動化による品質保証が難しくなっています。 • QA4AIなどの議論が進んでいることからも従来のテスト理論がその ままでは機能しません。 • 2026年では開発プロセス⾃体にAIも⼊り込んでおりその不確実 性はさらに増加しています。 • 本セッションでは、PdMとQAが経験した「品質活動を上⻑に伝え きれなかった失敗」や「AI前提の不確実性に対して消極的になっ てしまった失敗」を出発点に、Cost of Qualityやデジタル経済と 製造業DXの研究、DXリスク評価モデルなどの理論・調査結果を 背景に紹介しつつ、現場とのギャップを率直に議論します • 様々な障害を組織変⾰のきっかけに変える視点を、対談形式で お届けします。 1. ⾃⼰紹介 2. アンケート 3. 背景 4. QAチームの苦労 5. 経営者の苦労 6. ステコミレポートというアイディア 7. 導⼊イメージ 8. パネルディスカッション 品質を経営にどう語るか アブストラクト アウトライン AI前提の開発では従来のテスト結果だけでは品質を⼗分に説明できない。
3. ⾃⼰紹介 3 品質を経営にどう語るか
4. 4 • 所属：合同会社デロイトトーマツ OI&DS 47機関 執⾏役員 • ⼤規模システム開発、新規事業開発、アジャイル組織変⾰のご ⽀援 • 新卒、⼤学⽣へのアジャイル教育：筑波⼤学 enPiT2 • 防災DX : SmartBosaiConnect Product Manager 品質を経営にどう語るか ⾃⼰紹介 kyon_mm/きょん
5. 🩷 🩷 🩷 🩷 🩷 🩷 🩷 🩷 🩷 • キャディ株式会社でQAエンジニアをしています。 • カンファレンスの運営をしたり、参加したりするのが好き です。 • 好きな飲み物はクラフトビール • 好きな絵⽂字は🍥 🩷 🩷 🩷 🩷 🩷 🩷 🩷 🩷 🩷 5 品質を経営にどう語るか naco_mm / X(Twitter) : 750_naco ⾃⼰紹介
6. 6 • 株式会社witch&wizards 代表取締役社⻑ • プロダクトマネジメントコーチ • ソフトウェアに限らず、重⼯業、⾷品業界、エンタメ業界などで 新製品開発を成功指せるための伴⾛や育成を⾏っています。 • プロダクト開発に関する多数の講演をしてきました 品質を経営にどう語るか 森 雄哉 / moriyuya / X(Twitter):_N_A_ / note:mryy ⾃⼰紹介
7. 品質を経営にどう語るか 7 普段経営者や上位層に対してどのように品質活動を報 告、議論していますか？ オンサイトの⽅は近くの2-3名で。オンラインの⽅はDiscordに書いてください。
8. 背景 8 品質を経営にどう語るか
9. 9 仕様とテストケースに基づき、 「どれだけテストしたか」 「どれだけバグが残っていそうか」 暗黙の前提 • 仕様が⽐較的安定している。 • ⼊⼒データの分布がある程度予 測できる。 • 実装の振る舞いは決定的である （同じ⼊⼒→同じ出⼒）。 品質説明の典型パターン • テストケース数・網羅率 • 発⾒バグ数と重⼤度 • 性能・可⽤性などのSLA達成度 品質を経営にどう語るか 第３次産業⾰命までの品質説明 第４次産業⾰命からの品質説明 AIやデータ中⼼のシステムが増える中で、従来のテスト指標だけでは品質に関する意思決定に 必要な情報を経営に⼗分に伝えにくくなっている 参考：The Digital Transformation Risk Matrix: A Tool for Assessing the Impact/Control Nature of Digital Transformation Risk Digital transformation project risks assessment using hybrid picture fuzzy distance measure-based ARAS method 「データ」 「運⽤状況」 「モデル更新」が品質を左右する。 特徴１ ⾮構造データ・多様な⼊⼒画像・⾳声・テキスト・セン サーデータなど、⼈間の解釈が必要なデータが多い。 特徴２ データ中⼼構造モデルの振る舞いが、訓練データ・評価 データ・運⽤データの性質に強く依存する。 特徴３ 不確実性と変化⼊⼒分布の変化・モデルの更新・外 部APIや⽣成AIの挙動変化が前提になる。 この変化に対して、説明の型が追いついていないのではないか？
10. 品質を経営にどう語るか 10 構造の変化 品質を説明する際の材料が「仕様とテスト結果」から「仕様・データ分布・モデル・運⽤シナリ オ」に広がった結果として、経営が⾒ている軸との間に構造的なギャップが⽣じている 使⽤できる説明材料が変化 従来: 仕様・テストケース・コード 現在: 仕様＋データ分布＋モデル構造＋運⽤シナリオ 説明相⼿の視界とのギャップ 経営層は、売上・コスト・リスク・責任範囲を軸に意思決定する。QA側が 持っている情報は、テスト指標や技術的リスクに偏りがち。 結果として、「同じ品質」を⾒ているのに⾒えているものがずれる。 説明が難しいのは“スキル不⾜”ではなく“構造の変化”への対応不⾜。 意思決定のタイミングごとに増 える“わからない” 企画時点:AIの適⽤余地・データ⼊⼿性・初期投資規模が不明瞭。 開発・PoC時点:どの程度の精度／誤判定率であればビジネス的に許容か が曖昧。 本番・運⽤時点:データドリフト・モデル劣化・サイバーリスクの発⽣確率が読 みにくい。 構造データから⾮構造データへ 業務中⼼からデータ中⼼へ ビジネスの不確実性とシステム の確率論的挙動の増加 現在の事象 構造的変化
11. QAチームでの苦労 11 品質を経営にどう語るか
12. 12 品質を経営にどう語るか 第３次産業⾰命時代までの課題 第４次産業⾰命でおきている課題 QAチームから経営層へ伝わらない恐れが局所最適を⽣み、上位の意思決定を⽌めるときが ある その結果、経営層への相談や提案に⼼理的なハードルが⽣まれている。 「うまく説明できなかったら怖い」「失敗したら次がない気がする」と感じ、現場で⼿の届く範囲の仕事に閉じやすい。 品質を説明しようとしても、「何を・どの粒度で・どう伝えれば意思決 定につながるのか」が曖昧で、テスト結果の報告で⽌まりがちだった。 AI4QA / QA4AIが⾝近になり、品質の論点がデータ・モデル・運⽤ま で広がった結果、「何を伝えればよいか」がさらに曖昧になり、説明の 難易度が上がった。 現場の声 結果やってしまっていること しかし実際には、現場だけでは動かせない要件、決められない論点があり、そこを前に進めない限りは「⼿の届く範 囲の仕事に閉じてしまう問題」は解消しない。 QAチームは品質を解像度 ⾼く説明したい 事業の品質を 向上させたい 経営者は効果的な投資 をしたい 経営指標で判断する QAプロセスを説明する 妥 協 QAチームは⼩さな意思決定で済む 範囲で仕事をし、局所最適に 品質活動は短期的成果指標で表 現できる活動が少ないため、⻑期的 な活動への投資が減る
13. よくある対処(アンチパターン) 短期的な結果 ⻑期的な結果 QAプロセスを説明する 経営はQAプロセスがわかっても経営指標には結びつかず、 経営判断ができるようになるわけではない QAチームは⼩さな意思決定で済む範囲で仕事をし、局所 最適になりがち 経営指標で判断する 品質活動は複利的に効果が出ることが多く、短期的成 果指標で表現できる活動が少ないため、⻑期的な活動 への投資が減る ⻑期⽬線では事業の品質コストが⾼くなっていき、事業の 利益率が悪化していく 経営とQAが話す時間を増やす ⾔葉合わせに時間がかかるため、改善に時間がかかる。 特に経営者は時間が少ないので、散発的な取り組みに なる。 改善活動は中断しがちになり、QAチーム、経営の両者共 に、やっても効果がでないという認識が強まる 経営がCIO/CTOに任せる (よくわからないので任せてしまう) CIO/CTOに投資判断を任せる場合には予算を別途プー ル化することになり、予算を個別最適する 経営レベルで局所最適化された投資判断が常態化する 品質を経営にどう語るか 13 アンチパターン それぞれの事象に対して解決を試みようとしても、更に悪化することがおおく、対話量や説明の 平易化だけでは意思決定不全は解消しない。
14. 品質を経営にどう語るか 14 良かれと思ってやっている対⽴から同じ⽬標へアプローチを合わせる 対⽴を埋めるのではなく、⽐較可能な形（品質を経営指標と投資活動に翻訳するプロトコ ル）へ変換する。 品質を経営指標で説明する 効果的な投資活動としてQAプロセスを説明する 短期から中期までふくめて、経営と 現場のプロトコルの開発 QAチームは品質を解像度 ⾼く説明したい 事業の品質を 向上させたい 経営者は効果的な投資 をしたい 経営指標で判断する QAプロセスを説明する 妥 協 QAチームは⼩さな意思決定で済む範 囲で仕事をし、局所最適に 品質活動は短期的成果指標で表 現できる活動が少ないため、⻑期的 な活動への投資が減る
15. 品質を経営にどう語るか 15 構造の変化 品質を説明する際の材料が「仕様とテスト結果」から「仕様・データ分布・モデル・運⽤シナリ オ」に広がった結果として、経営が⾒ている軸との間に構造的なギャップが⽣じている 第３次産業⾰命時代から経 営への説明責任が曖昧 第４次産業⾰命によって説明 のための構造的変化がおきたこ とで、説明責任が果たしにくく なっている QAと経営のプロトコルとしてステアリングコミッティへのレポート や投資申請資料などをベースに AI時代に必要な要素を⾜すといいのではないか？ 第４次産業⾰命によって⽐較 対象が広がり、品質投資の優 先順位を決めにくくなっている ２０２６年のQAチームにおける課題 ２０２６年のソフトウェア開発企業の経営における課題 多基準品質を意思決定する
16. 経営者の苦労 16 品質を経営にどう語るか
17. 17 プロダクトは企画、開発、ローンチ、ユーザーの 利⽤体験、保守サポートといった異なる能⼒ が求められる様々な活動によって成り⽴つ。 これらはそれぞれ独⾃の品質基準を持つ。 それぞれの担当部署が⾃分の部署に必要 な予算を、⾃分の部署の⾔葉で主張し、予 算を増やしてもらえれば⾃部署の品質を⾼ めることが容易になる。ところが企画は企画 の⾔葉で書かれ、開発は開発の⾔葉で書か れている。 経営者は何にリソースを投⼊するかを判断す る必要がある。ところが全てに深く精通してい る経営者はなかなかいない。しかし、事業全 体が成⽴するように判断しなければない。 経営者から⾒ると異なる品質基準の主張で ある。⽐較できないが、予算を決めなければ ならない。 品質を経営にどう語るか 問題状況 各部署は⾃部署の品質基準で予算を主張するが、経営陣はそれらを⽐較できず、根拠の薄 い状況で判断を強いられている それぞれの担当部署や現場は、経営陣がプロダクト全体に対して適切に意思決定できるよう になるためにどのような情報を提供する必要があるだろうか? 経 営 現 場
18. 品質を経営にどう語るか 18 状況を引き起こす原因 原因と制約を同時に満たす解は、「わかる⼈を増やすこと」ではなく「⽐較できる形式をつくるこ と」である。 各部署の品質基準は、固有の知識や評 価尺度で構成される。他部署や経営層 は意味を完全には読み取れない。 各部署は⾃部署の品質基準で予算 を主張するが、経営陣はそれらを⽐較 できず、根拠の薄い状況で判断を強 いられている 各部署は⾃部署の必要性は主張できる。 ⼀⽅で、事業全体における重み付けはで きない。 各部署に経営の教育を施すことも 現実的ではない 経営陣が全ての部署に精通するこ とは現実的ではない 問題状況 原因 制約 他部署同⼠や現場との間で、お互いの基 準を相互に理解し合う場は稀である 短期的には、限定的な知識構造を 前提として、⽐較可能性を⾼める ⽅法が必要になる
19. 通勤時間（時間的経済性） 家賃（⾦銭的経済性） 緑の多さ、公園の近さ 災害リスク 治安、騒⾳ 品質を経営にどう語るか 19 引っ越しの多基準例 異質な基準を⽐べるには意思決定者の重み付けを促す情報が必要である。 体験による重みづけ 意思決定者である⾃分⾃⾝が、現地を訪問することを通して実際に体験し、 ⾃分の価値観に照らし合わせて、何がより重要で何がそうでないかという感覚 を掴むことができるからである。異なる基準の⽐較を可能にしているのは、客観 的な数値ではなく、意思決定者⾃⾝の体験に基づいた主観的な重み付けに なっている。 体験できないことによる困難さ 引越は難しいことですが、事業の意思決定ではさらに難しくなる。経営者は各 部署の現場を毎⽇体験するわけではない。ソフトウェアのコードを⾃分でテスト するわけではない。質の基準は各部署の担当者の頭の中にあり、経営者が常 に直接確かめられるわけではない。 引越ではある程度の⼿間暇をかければできようになる重み付けも、事業では 簡単にはできない。経営者が重み付けできるようにするため、構造化された情 報を現場が提供する必要がある。 引 っ 越 し の 基 準 例
20. 品質を経営にどう語るか 20 解決策の⽅向性 現場は品質基準を経営の⾔葉へ翻訳し、部署横断で共通の⽐較軸をそろえるべきである。 第⼀に経営の⾔葉である必要がある。 • 経営者が直接体験できない以上、現場が⾃分たちの品質基準を経営の⾔葉で 表現する必要がある。 第⼆に⽐較可能である必要がある。 • 経営の⾔葉は、部署を問わず共通にする必要がある。事業の意思決定において 共通するのは主に価値、コスト、リスクとなる。
21. 品質を経営にどう語るか 21 品質を経営と語る3要素と選択肢の提案 このような状況下では価値・コスト・リスク・選択肢を同じ紙⾯で⽐較できるようなテンプレート (意思決定者の重み付けを促す情報/ステアリングコミッティレポート)を提案する ・現場の⾔葉:この活動に関するリスクは何か ・経営の⾔葉: ・実⾏した場合: ・実⾏しない場合 期待コストの幅:最⼩◦◦万円〜最⼤◦◦万円 価値 コスト リスク ・現場の⾔葉:この活動が直接向上 させる⾃部署の品質指標は何か 例:リリース後の重⼤バグ0件 ・経営の⾔葉:その品質向上は、 どの事業KPI/KGIに貢献するか 例: 顧客継続率 （中期計画の重点指標）の向上 ・現場の⾔葉:この活動に必要な ⼈員/期間/設備は何か ・経営の⾔葉: ・実⾏コスト:◦◦万円 期間◦◦⽇ ・やらないことによるコスト:◦◦万円 (障害対応、顧客対応など) ・現場の⾔葉:この活動に関するリス クは何か ・経営の⾔葉: ・実⾏した場合: ・実⾏しない場合 ・期待コストの幅: 最⼩◦◦万円〜最⼤◦◦万円 選択肢
22. ステコミレポートというアイディア 22 品質を経営にどう語るか
23. NIST AI RMFの枠 組みを⽤いて案件 固有のAIリスクを把 握し測定と対応⽅ 針を整理することで、 ステコミレポートにリス クと信頼性の観点を ⼀貫した形で組み 込む 品質を経営にどう語るか 23 品質を経営と語る４要素 ステコミレポートに説得⼒を持たせるために価値・コスト・リスク・データという４つの観点で根拠 を明⽰的に揃える必要がある バランススコアカード 戦略管理の４分類 「財務／顧客／内 部プロセス／学習と 成⻑」の観点で書き、 価値の漏れを減らす CoQ コスト/品質の4分類 NIST AI RMF AIリスクを4つの機能で整理する 価値、コスト、リスク、前提となるデータを揃えておくことで経営の関⼼と現場の関⼼を同⼀のフレーム上で扱えるようになり、 その結果としてステコミレポートを起点とした議論がかみ合いやすくする。 価値 コスト リスク ISO 25012 データ品質の15特性 / ISO 5259⼈⼯知能−分析と機械学習(ML)のデータ品質 ISO/IEC 25012のデータ品質特性を参照することで、どのレベルの正確性や完全性であったり ISO5259でAIでのデータ品質を前提に品質議論を⾏うのかをステコミレポートの中で合意可能な形で記述する 分類 概要 予防 ⽋陥の発⽣を未然に防ぐ努⼒から⽣じる 評価 検査、テスト、監査による⽋陥の検出から ⽣じる 内部 失敗 内部で発⾒された⽋陥から発⽣し、⽋陥 品を廃棄または修理することで対処する 外部 失敗 外部で発⾒された⽋陥から発⽣し、⽋陥 品を廃棄または修理することで対処する。 引⽤：バランス・スコアカード【BSC】の論理と使い⽅を経営学者が解説！ - やさしいビジネススクール 2026/03/20参照 , 引⽤： NIST AI 100-1AI リスクマネジメントフレームワーク（AI RMF 1.0） 2026/03/20参照
24. 品質を経営にどう語るか 24 品質を経営と語る４要素 ステコミレポートに説得⼒を持たせるために価値・コスト・リスク・データという４つの観点で根拠 を明⽰的に揃える必要がある バランススコアカード 戦略を⽇常の活動と指標に接続するための経営フレーム 効果 戦略と現場活動のずれが⾒えやすく なる 先⾏指標と結果指標を同時に扱える 会議体の論点が「活動報告」から「成 果と因果」に移りやすい どの能⼒を⾼め、どの業務 プロセスを改善し、 その結果として顧客価値と 財務結果がどう変わるか Cost of Quality 品質問題をコスト構造で捉えるための枠組み 効果 「品質は⼤事」から「どこにいくら損失 が出ているか」へ議論を進められる 再発防⽌と予防投資の優先順位を 付けやすくなる COPQ（Cost of Poor Quality）の 縮減余地を説明しやすくなる 失敗コストを減らすために、 どこまで予防に振り向けるか NIST AI RMF AIを安全・信頼・説明可能なかたちで使うためのリスク管 理フレーム 効果 AI導⼊時の論点漏れを減らせる 導⼊前審査と導⼊後監視をつなげや すい 事故や炎上への備えを平時から組み 込みやすい GOVERN は組織の⼟台 MAP は設計前提の明確化 MEASURE は検証と監視 MANAGE は対応と運⽤ ISO 25012 / ISO 5259 データの品質特性を定義する国際規格 効果 「品質が悪い」を具体的な特性で分 解できる データ改善の優先順位が付けやすくな る AIや分析の誤判断リスクを下げやすい 構造データと⾮構造データの特性 を踏まえて、データが利⽤⽬的に 対して 最適かを、共通の枠組み で定義・測定・管理・報告・統治 できるようにする
25. 品質を経営にどう語るか 25 メモのテンプレート 顧客２０社以上要望がある〜機能を提供することで、財務的には売上XX円増加、内部プロセスの改善を並⾏ で進めて類似案件への対応⼒向上、最新AIモデルに対する知⾒獲得を⽬指す 採⽤したいPlanと理由：PlanA。価値が最も⾼く、現在の現場リソースで⼗分にコストを払えるため。また、リスクは社内標準で⼗分である。 論点：より⾼い価値を出すためにはどうすればいいか、短期と中期両⾯で成果をあげるにはどうすればよいか。 Decision（決めたいこと）：＿＿＿＿を、＿＿＿＿までに決定したい。 Decision Owner（決める⼈）：＿＿＿＿（承認者：＿＿＿＿） 前提制約（守る条件）：法規／安全／納期／予算上限／品質下限（該当するものを定量的に記載） ⽬標としている価値 品質のためのコスト AIリスクへの対応 データ前提 最新性、⼀貫性、完全性の担保 追跡可能性や精度は劣後 予防：現⾏どおり 評価：現⾏どおり（AIツール学習で+、総⼯数 でー。合計で現⾏通り） 内部失敗：低減させる 外部失敗：現⾏どおり 財務：売上XX円増加 顧客：提案機会50件増加 内部プロセス：ツール活⽤でトリアージ30%⾼速 学習：AIモデルに対する知⾒獲得 Govern：社内のAI倫理ポリシー準拠 Map：⾒逃し、誤検知までは識別 Measure：⾒逃し率・誤検知率 Manage：閾値、⼈⼿によるテスト、⾒逃 し率が⼀定期間で閾値超過したら停⽌ 価値 品質コスト リスク Plan A （左記） 〇 〇 △ Plan B △ △ 〇 Plan C △ 〇 △ 〇：向上、△：現⾏維持、×：悪化
26. 品質を経営にどう語るか 26 品質向上施策サマリー プロジェクトAの品質向上施策は計画通り推移しており、重⼤⽋陥は確認されていない。 ⼀⽅で、High相当の懸念が継続しているため、来⽉も重点領域に絞って予防と評価継続予定。 品質コストの構成を「リリースしてから修正」から「予防前提」に移⾏できている。 採⽤したいPlanと理由：PlanA。価値と品質コストが最も効率よく、中期的には最もリターンが⾼い。リスク対策は社内標準で⼗分である。 論点：来⽉も予防と評価へのコスト注⼒でよいか、他プロジェクトへの適⽤を⾒据える必要はあるか テスト結果サマリーは別紙参照。 Decision（決めたいこと）：現時点の品質状況と残留リスクを確認いただき、来⽉のQA活動の重点と対応⽅針を合意いただきたい。 Decision Owner（決める⼈）：開発部⻑（承認者：事業責任者、情報セキュリティ責任者） 前提制約（守る条件）：個⼈情報を含む⼊⼒データの保存率0%、社内データ取扱基準への不適合0件、重⼤な安全逸脱の⾒逃し0件 提供している価値 品質のためのコスト AIリスクへの対応 データ前提 学習データ4.2万件、最新版FAQ反映は 週1回 ラベル⽋損は約8%、鮮度は24時間以内 ⾼重要問い合わせの正例データはまだ不 ⾜ 予防：30%上昇 評価：20%上昇 内部失敗：20%減少 外部失敗：30%減少 財務：外部障害対応⼯数を前⽉⽐30%削減 顧客：誤回答率と有害応答率が60%改善、⼀ ⽅でHigh相当の懸念が継続中 内部プロセス：回帰テスト⾃動化率5%向上 学習：レビュー⼿順を標準化 Govern：対象業務と停⽌基準は合意済 Map：⾼重要問い合わせで誤案内余地あり Measure：正答率・誤案内率・⼈⼿介⼊率を 監視 Manage：閾値超過時は⾃動回答を停⽌し有 ⼈転送 価値 品質コスト リスク Plan A （左記） 〇 〇 △ Plan B 〇 △ 〇 Plan C △ 〇 〇 〇：向上、△：現⾏維持、×：悪化
27. 導⼊イメージ 27 品質を経営にどう語るか
28. 品質を経営にどう語るか 28 品質を中⼼とした会話の変化イメージ ３つの構造的変化に対してQA専⾨家ではない経営が現場と議論しやすくなった ⾮構造データ・多様な⼊⼒ データ中⼼構造 不確実性と変化 従来⼿法で起きること ⾮構造化データの場合のテスト設 計の説明に時間がかかったのに、経 営として判断しやすくなったわけでは ない ⾮機能要件に関するテストに関して は業務を理解している前提で説明 可能だが、経営として判断しやすい わけではない 不確実性に対してテストの詳細を説 明することで対応していることはわか るが、お互いの解像度が合いにくい 提案⼿法で起こること 扱うデータ構造によらず、経営者も つかう⾔葉で表現しているため、テス ト対象が変化しても経営と会話で きる AI RMFでプロセス、ISO 25012で データの特性を踏まえたQA活動の 標準的な特性を会話できる AI RMFによりリスクマネジメントプロ セスの全体像と、CoQによるコスト の注⼒先という観点で経営と会話 できる 品質報告は「結果の共有」から、「代替案を⽐較し、投資判断につなげるための情報提供」へ変わる。 その結果、経営は、どこに投資するかだけでなく、どのリスクをどこまで許容するか、 誰がいつまでに整備するかまで決めやすくなる。
29. 品質を経営にどう語るか 29 導⼊ステップ ⽐較可能にし、優先順位を決め、責任と期限を決めて実⾏に移し、これらを繰り返す 具体例：実データを⽤いたテスト環境の整備 QAやエンジニアだけでテストデータの準備を⾏おうとすると、議論がテック組織の中に閉じやすい。 顧客や営業も巻き込み、実データを使った検証に広げることで、テストだけでなく計測・評価・顧客理解にもつながる。 その実現には、価値・リスク・コストを整理し、関係者で優先順位と責任を決める必要がある。 STEP1：⽐較可能にする STEP2：優先順位を決める STEP3：責任と期限を決める 経営層 ⽐較軸を合意（価値・リスク・コスト） ／判断基準の前提を置く 重み付けして「やる／やらない／後回し」を決め る 予算・期限を承認する マネージャー テーマを絞る／ステコミレポートの前提 （KPI・制約）を揃える 代替案のトレードオフを整理する 実⾏計画に落とし込み、オーナーと期限を確定 する QAチーム ステコミレポートを作る（選択肢＋価値 /リスク/コスト） 根拠を添える（CoQ・データ品質・AIリスク）／ 根拠不⾜がある場合は調査案を提⽰ 決定内容を実⾏する
30. パネルディスカッション 30 品質を経営にどう語るか
31. 品質を経営にどう語るか 31 このセッションを聞いたうえで明⽇から何をするといいのだろうか？
32. 品質を経営にどう語るか 32 AIを前提としたQAと経営の課題感はどの程度の幅広さであるべきか？