「正しいことを行う」対「物事を正しく行う」7 — 屋外用デュアルケーブルの開発

2014年、私たちはドイツ本社から開発課題を受けた。屋外用デュアルケーブルを設計するというものである。表面上は目立った点がなく、構造も複雑ではなかった。しかし、この種の製品について私たちに事前の開発経験はなく、顧客の要求は数ページにわたって続いていた。そのため、初日からプロジェクトは不確実性に包まれていた。

これは典型的な「順方向開発（forward development）」のプロジェクトであった。順方向開発とは、会社がこれまでこの種の製品を作ったことがないことを意味する。すなわち、そのまま流用できる既存の経験や図面は存在せず、すべてをゼロから構築しなければならなかった。同時に、この小さなケーブルは非常に特殊な技術要求を担っていたため、順方向開発の縮図と見ることもできる。

この課題に直面し、私たちはすぐに製図板に向かうことはしなかった。会社の製品開発プロセスに厳格に従い、要求管理に重点を置いた。要求管理は、次の4つの段階的なステージに分解した。第一に、顧客の原要求を深く収集・整理し、雑多な表面から中核的な価値を抽出すること。第二に、社内要求を掘り起こして統合し、会社が蓄積してきた経験資産を動員すること。第三に、概念設計の段階で要求の統合とアーキテクチャ構築を第2ラウンドとして行うこと。そして最後に、3D・2D設計の段階で詳細要求の最終的な調整と実装を行うことである。

プロジェクト完了後に振り返ったとき、ある一連の数字が際立っていた。顧客が明示的に提起した要求は、要求セット全体のわずか5%にすぎなかった。他の製品設計に関する私たちの深い経験に基づいて主体的に補完した要求は46%を占めた。コンカレントエンジニアリング（Concurrent Engineering）を通じて製造・品質・購買などの部門から幅広く収集した要求は39%を占めた。さらに、その後の概念設計・製品設計の段階で、私たちは動的にさらに10%を追加した。

この要求セットの完全性を徹底的に追求したことが、その後のすべての土台を築いた。これほど完全な全体像を手にしたことで、残りの開発は円滑かつ迅速に進んだ。プロジェクト全体を通じて、大きな設計変更は一度も発生しなかった。すなわち、1回の設計、1回の試験、1回の成功である。最終的に、私たちは顧客が要求する期限より前にエンジニアリングサンプルを正式に納品した。

プロジェクト全体を振り返ると、中核となる成功要因は次のとおりであった。すなわち、製品とそれが動作する環境を深く理解し、製品要求の完全なセットを事前に収集して正確に定義することである。このように作業を前倒し（front-loading）することで、私たちは一発成功（first-time-right）の開発を実現し、曖昧な要求に起因する後工程の設計変更という大きなコストを完全に回避した。

これは製品品質と開発スピードの二重の勝利であり、「正しいことを行う」対「物事を正しく行う」という管理哲学を鮮やかに示すものであった。この事例において、正しいことを行うとは、顧客が明示した5%に盲目的に応答することではなく、現象の背後にある本質を見抜き、隠れた95%、すなわち要求セット全体を主体的に構築することによって、私たちが開発するものが真に「正しい製品」、すなわち用途に真に適合し、製造可能で、高い品質を提供できる製品であることを保証することであった。そして物事を正しく行うとは、4段階の要求管理プロセスを厳格に実行し、コンカレントエンジニアリングと専門的な経験を用いて、それらの要求を効率的かつ正確に設計図面へと変換することに表れていた。

最終的に、この小さな成功事例は、開発を前倒しする知恵を実証しただけでなく、ドイツ本社からのより深い信頼と、その後の絶え間ない新製品開発の受注をもたらした。そこから得られる教訓は次のとおりである。すなわち、「正しいこと」を早い段階で考え抜くことによってのみ、後に「物事」を正しく、そして美しく実行できるのである。

実践における4段階の要求ファネル

4つのステージは4回の会議ではなく、4つのフィルターであり、それぞれに異なる責任者と異なる成果物がある。これらをファネルとして扱うことで、5/46/39/10という内訳は偶発的なものではなく再現可能なものとなる。

その出所、責任者、検証方法を特定できない要求は、まだ要求ではなく意見にすぎない。ステージ4は、そのテストを1行ずつ適用する場である。

実例：「屋外」から測定可能な要求へ

顧客の1つの曖昧な表現、すなわち「屋外使用に適すること」が、どのようにして検証可能な要求の集合になるかを考えてみる。顧客の文書には数値は一切なく、数値はステージ2とステージ3から生まれる。

• 顧客の記述（ステージ1）：「ケーブルは屋外に設置され、機能を維持しなければならない」。1行のみで、数値はない。
• 用途に関する質問（ステージ1）： どこに取り付けるのか（外壁、ポール、埋設ダクト）。期待される使用寿命はどれほどか。設置後に屈曲されるのか、固定されるのか。
• 社内の掘り起こし（ステージ2）： 当社のポートフォリオにおける過去の屋外製品は、主にジャケットの紫外線脆化とコネクタ界面への水の浸入によって現場で故障していた。教訓記録は、紫外線暴露試験とIP定格を必須の補完項目として示している。
• 概念段階での統合（ステージ3）： チームはアーキテクチャを確定する。すなわち、紫外線安定化ジャケットコンパウンド、コネクタへの密封された移行部である。そしてそれぞれに目標を割り当てる。すなわち、定義された紫外線劣化時間の目標と、定義された浸入保護レベルであり、いずれも顧客と書面で合意する。
• 詳細の調整（ステージ4）： 各目標は、図面の指示事項と設計検証計画における試験になる。すなわち、2D図面へのジャケット材料仕様、紫外線劣化試験、3つのサンプルでの浸入試験である。

これらの数値はいずれも顧客の文書から来たものではない。すべてが出所、責任者、試験を備えているため、すべてが正当化できる。まさにこれが、日常業務において46%と39%という割合が表しているものである。

要求フェーズのステップバイステップ・チェックリスト

概念設計の開始が許可される前のゲートレビューとして、このリストを使用する。

1. 顧客のすべての文を番号付き要求に転記し、原文の表現を自分の解釈と並べて保持する。
2. 各行を明示・導出・仮定のいずれかに分類する。仮定は最もリスクの高いカテゴリである。
3. 顧客とともに用途を確認する。すなわち、取付方法、環境、使用寿命、嵌合部品、設置工具である。
4. 教訓ライブラリと過去の8D報告書から類似製品を検索し、関連するすべての故障モードを補完要求として追加する。
5. 製造・品質・購買を交えた部門横断レビューを実施し、誰が何を提起したかを記録する。
6. すべての要求を、検証方法（試験、解析、検査、実証）を伴う測定可能な合格基準に変換する。
7. 検証できない要求にはフラグを立て、試験を定義するか、未解決リスクとしてエスカレーションする。
8. 要求セットをベースライン化し、バージョン管理し、3D設計の前に凍結する。以降の変更は変更管理を経由させる。
9. 各要求を図面の機能および検証記録へ前方トレースする。

よくある失敗モードとその検出方法

• 暗黙の仮定。 チームはある要求が明白だと信じ、決して書き留めない。検出方法は、各技術者に製品が果たすべきことを1文で述べさせ、回答の不一致からギャップを明らかにすることである。
• 顧客仕様書の絶対視。 チームは顧客文書を完全なものとみなし、ステージ2を省略する。検出方法は、補完要求と明示要求の比率を確認することである。新製品ファミリで補完率がほぼゼロであることは、効率ではなく危険信号である。
• 検証不能な要求。 「堅牢」「長寿命」といった表現がベースラインまで生き残る。検出方法は、要求リストをキーワードスキャンし、数値を伴わない形容詞を探すことである。
• 要求の発見が遅れる。 3D設計中または初回サンプル後に新たなニーズが現れる。検出方法は、ベースライン後に追加された要求を数えることである。それぞれが、どのステージが見落としたかという根本原因の問いを引き起こすべきである。
• 名目だけのコンカレントエンジニアリング。 製造と品質がレビューシートに署名するが、内容には決して貢献しない。検出方法は、出所の列を監査することである。それらの機能にトレースされる要求が1つもなければ、そのレビューは儀式的なものであった。

成果物の検証方法

検証は2つのレベルで行う。要求レベルでは、すべての行が出所、責任者、測定可能な基準、検証方法を備えていること、またトレースマトリクスに孤立機能（背後に要求のない図面指示事項）も孤立要求（機能のない要求）もないことを確認する。プロジェクトレベルでは、証拠は行動面にある。すなわち、大きな設計変更のない一発成功の通過、単一の試験ラウンド、予定どおりまたは前倒しの納品である。設計凍結後に提起された設計変更要求の数を追跡する。このプロジェクトでは大きな変更はゼロであり、その数字こそが要求管理の正直なKPIである。

隣接するDステップとの関連

この作業は8Dの連鎖の最前段に位置し、残りのステップの挙動を決定づける。完全な要求セットは**D2（問題の記述）への入力である。それがなければ、「問題」を「欠落した要求」から切り分けることはできない。これはD3（暫定処置）**にも影響する。なぜなら、遅れて発見された要求のギャップは、出荷済みサンプルに対する暫定処置を強いられるからである。また、**D4（根本原因）**が設計上の不具合と仕様上の不具合を区別する際の基準となる。最も重要なのは、**D5/D6（是正処置と検証）**を守ることである。要求を後付けで追加する是正処置は、要求を事前に捉えておく場合よりもはるかに高コストであり、D6における検証は、凍結されトレース可能なベースラインに対してのみ意味を持つ。要するに、4段階のファネルは、D5とD6を安価にする場なのである。