【発展編 第2回】品質は「合否を出す」ことではなく「リスクを判断する」こと——リスク受容としての品質ガバナンス

本連載では、品質を3つの軸で捉えます——
①設計書適合（仕様どおりか）
②暗黙要件（仕様に書かれない当たり前）
③本質要件（本当に達成したい目的）

なぜ「統治」なのか

AIは①を強化する一方で、②③は放置されやすくなる。この非対称を組織として吸収するには、品質を「結果責任」ではなく「統治責任」として位置づける必要がある。

原則は、この連載で繰り返してきたとおりだ。AIは品質を"加速"するが、"保証"はしない。 ①はAIが大部分を担えるが、それは品質保証の必要条件であって十分条件ではない。②は人間とAIの協働（QEハーネスが媒体）、③は最終的に人間の意思決定が残る。どこにAIの責任があり、どこに人間の責任が残るかを設計するのが、品質ガバナンスだ。

②③には「統合する場所」が要る

よくある構造は「PMが最終責任、QAが実行責任」だ。だがこの構造には、②③を統合する場所がない。PMもQAも、それぞれの主業務（全体管理／品質確認）の枠を超えて、要件統合まで踏み込みにくいからだ。

そこで、②③の統合をひとつの機能として明示的に定義する。②と③を別々に扱うと、②は実務者がなんとか拾う一方、③は誰の主業務にもならず後回しになり、結局どちらも担保されない。だから②③は一体の統治責任として設計する。「QA部門」ではなく「Quality Governanceという機能」として置くのが要点で、これを主導するのが——第6回で見た——QEアーキテクトだ。

③は「品質の合否」ではなく「リスク受容」の問題

ここが品質ガバナンスの核心だ。③は「正解か誤りか」で白黒つくものではない。だから実務では「止める／止めない」の二択ではなく、リスクをどこまで受け入れるかの問題として扱う。

ただし、ただ現場に「どうします？」と委ねるのは違う。何が許容水準かが事前に合意されていないまま判断を求めると、些細なリスクでもNoGoになりがちだからだ（逆に、雰囲気で通せば何でも通ってしまう）。品質ガバナンスの主業務は、リスクを許容水準まで下げることにある。段取りはこうなる。

• 事前：水準の合意——「どのレベルのリスクならリリース可能か」を関係者と先に決める（品質ゲート・Exitクライテリア）

• 実施中：リスクコントロール——リスクを可視化しながら、合意した許容水準まで低減する。これが主業務

• リリース判断：判断材料の提示と協働——許容水準に達しているかを根拠として示し、最終的なGo/No-Go（リスクを事業として引き受ける意思決定）は事業責任者と協働して決める

QEアーキテクトが担うのは「どのリスクをどこまで受け入れるべきか」を見極めて提言・推奨するところまでだ。決定を丸投げするのでも、現場で抱え込むのでもない。判断材料を整え、決定は事業責任者とともに行う。

一文で構える

この立場をステークホルダーに伝えるとき、入り口になる問いかけがある。

「止める」でも「丸投げ」でもなく、受け入れる水準を先に合意しておく。そうすれば、些細なリスクでの過剰なNoGoも、雰囲気での見切り発車も避けられる。

まとめ

AIが①を加速するほど、②③を組織として引き受ける機能が要る。それが品質ガバナンスだ。②③を一体の統治責任として置き（主導はQEアーキテクト）、③はリスク受容の問題として、許容水準を事前に合意し → 低減し → 根拠を示して事業責任者とともに決める。品質を「結果の合否」から「統治のプロセス」へ——これが、AI時代に品質を守る組織の形である。

▼連載の全体像と各回へのリンク（連載インデックス）

本稿および本編は個人の見解であり、所属する組織を代表するものではありません。
問い合わせ先：terumitsu.takahashi.qe [at] gmail.com