問題解決の本質 #8 — 品質と研究開発の対立

TL;DR: 品質部門と研究開発部門はリリース判定の場で衝突します。「故障するかもしれない」対「リスクは小さい」という構図です。解決策は声を大きくすることではなく、定量化にあります。5,000台で1件の故障は、50万台では100件の故障に拡大します。「受け入れられるか」を「いくらかかるか」に変換し、定量化したリスクに対する緊急対応計画（Contingency Plan）を用意します。数値と計画がテーブルに載れば、膠着は合理的な協働へと変わります。

敵であり味方でもある関係

企業組織において、品質部門と研究開発部門はしばしば典型的な「敵であり味方でもある関係」にあります。技術課題の克服や顧客への品質製品の提供という場面では、両者は肩を並べて戦います。しかし製品リリースの瞬間には、しばしばテーブルを挟んで対峙し、時には公然と衝突に発展します。

この矛盾の本質は、「リスク回避」と「納期スピード」のせめぎ合いです。品質部門は下限を守る責務を負っており、潜在的な危険が存在する場合には、その一線を固く守らなければなりません。研究開発部門は市場投入という巨大なプレッシャーを背負っており、「些細な欠陥」による遅延が顧客の不満を引き起こしかねません。そのためリスク解放の意思決定ゲートにおいて、品質側は「事故につながるかもしれない」と強調し、研究開発側はリスクは「重大ではない」と主張します。この曖昧で定性的な論争は、しばしば双方が相手を説得できない膠着状態に陥ります。

実際の事例

ある企業が新製品を50万台規模で量産する計画を立てていました。認証試験の過程で、品質部門はあるスイッチの耐久指標がわずかに不足していることを発見しました。

研究開発を代表するプロジェクトマネージャーは、計画どおり市場投入することを主張しました。理由は二つあります。第一に、同じスイッチは同社の以前の少量生産製品で使用されており、深刻な市場クレームには至らなかったため、「許容可能」と判断されていました。第二に、今から新しいスイッチに切り替えると設計変更と再検証が必要となり、開発コストが増加し市場投入時期が遅れるためです。

品質部門はリリースに断固反対しました。その核心的な論理は単純です。新製品の計画生産量は旧製品の100倍です。同じ故障率であれば、潜在的な故障の絶対数は幾何級数的に増加し、大規模な顧客クレームを引き起こす可能性が非常に高いというものです。

双方とも一歩も譲らず、リリースの可否をめぐって激しく議論しました。

問いを変える：「受け入れられるか」から「いくらかかるか」へ

この終わりのない論争をどう打破するのでしょうか。答えは問題の本質を掘り下げること、すなわち曖昧な認識を定量化されたデータに置き換え、「受け入れられるか」という主観的判断を「いくらかかるか」という定量的な意思決定に変換することにあります。

この事例では、双方が「可か不可か」の論争をやめ、もう一歩踏み込んで、スイッチの重要な耐久指標を定量的に外挿すれば、状況は一変します。

旧製品が北米市場で5,000台販売され、スイッチの故障は1件のみで、保守後に直ちに解決され顧客不満はゼロだったと仮定します。同じ故障率を外挿すると、新製品の50万台では約100件の故障が発生すると見込まれます。

この時点で、意思決定の論理は「技術パラメータの論争」から「商業コストと緊急対応の実現可能性のトレードオフ」へと移ります。すなわち、これら100件の潜在的故障のアフターサービスコストを企業は負担できるのか、という問いです。

緊急対応計画は判断よりも強い

問題の本質は数値にとどまりません。定量化は第一歩にすぎず、第二歩は定量化によって露呈したリスクに対して周到な緊急対応計画（Contingency Plan）を用意することです。

新製品が市場に出る前に、チームがこのスイッチ故障に特化した緊急対応計画を事前に準備していたとします。交換部品を備蓄し、最前線の保守スタッフを訓練し、問題発生時に旧製品のあの1件の故障に対処したときと同じように、現場に急行して完璧に解決できるようにしておくのです。そうすればリスクは「制御不能」から「制御可能」へと変わります。

研究開発部門が定量化されたリスク予測と具体的な対応計画を品質部門の面前に提示できれば、論争は「リスクを取る勇気があるか」という絶望的なゲームではなく、「このリスクは取る価値があるか、計画は十分かを共に見よう」という合理的な協働になります。品質部門は「阻害者」から「ゲートキーパー」へと変わります。すなわち、通過を妨げるのではなく、通過するすべての段階がデータに裏付けられ、緊急対応計画によってカバーされていることを保証する役割です。

曖昧さから抜け出し、明確さへ踏み出す

多くの部門間の対立は、立場の相違から生じるのではなく、問題に対する浅い理解から生じます。議論が「問題があるかもしれない」対「おそらく大丈夫だ」というレベルにとどまっている限り、どちらの側も確固たる証拠を持たず、感情が唯一の武器になります。

さらに二歩踏み出すと、すなわちまず数値を計算し、次に計画を用意すると、状況は明確になります。曖昧な「かもしれない」は具体的な「100件の故障」に、抽象的な「リスクを取る」は具体的な「計画がある」に変わり、対立は協働に変わり、衝突は解消します。

これが問題の本質を掘り下げることの意味です。それは「リリースする」か「リリースしない」かの二者択一ではなく、二値的な選択を、データと緊急対応計画と合意を伴うエンジニアリング課題へと変える方法なのです。