設計者は製品の弱点を知っています。
設計段階でどのようなリスクを考慮し、どの様に対策を行うべきでしょうか？
不具合の盲点や設計段階でリスクを未然に防ぐ方法を解説します。
新製品開発に潜む「盲点」
新製品には、全く新しい技術を用いたものと、既存製品の改良型の2種類があります。
しかし、どちらのタイプも市場不具合のリスクをゼロにはできません。
では、設計段階でどのようなリスクを考慮し、どのように対策を行うべきでしょうか？
設計者だけが知るリスクをどう対策するか？
市場では問題が起きても製品規格では合格してしまう事がある。
何故なら試験方法は一般的な基準に沿っているだけで、その製品独自の「弱点」には対応していないからです。
あなたが設計者なら、その盲点を見抜く事ができる筈です！
では、どんな先手を打つべきでしょうか？
設計者の視点で市場リスクを先回りする
私が過去に新技術を搭載した製品を上市する際、社内の製品規格には合格していましたが、設計者として「どんな使い方をすると どんな問題（現象）が発生するか？」を自分は分かってました。
そこでサービス部門と連携して事前教育会を実施しました：
- この製品の特性上、発生しやすい不具合
- ノイズの種類（ホワイトノイズ、ダークノイズなど）を定義し、報告ルールを決める
この取組みにより、現場でのトラブルシューティングの質向上に繋がり、企業内での不具合対応の質や効率が向上しました。
「製品規格試験に合格＝安全」ではない！ 盲点を見抜く方法
例えば、私が過去に関わった製品で、ポータブル機器の外装が割れるという市場不具合がありました。
製品規格の試験では問題なし。しかし実際には「少しぶつけただけで割れる」との声が、。
構造を調べると、補強用のスチールフレームに幾つかの軽量化穴が開けられていた。
そこで「その穴のある部分に突起物をぶつけたら？」と試した結果、市場での現象が見事に再現されたのです！
つまり実際の使用環境や設計構造を意識したテストが不足していたのです。
でも多分ですが、もしその開発者に聞いたなら「あー、その部分は衝撃に弱いです」と言っただろうと思います。
ソフトウェアでの盲点？
ソフトウェアでの不具合例として、やはり設計からの検証の盲点という事例も多々見て来ました。
ソフトウェアの場合は、要求事項からの設計要件を定義する様々な手法があり、それは：
- 振る舞いを定義するダイヤグラム（状態遷移、ユースケース、シーケンス、アクティビティ図）
- 機能を整理する機能ブロック図
- データ構造を定義するエンティティ図
などがあります。 これらも設計する人がどれだけ客観的に分かり易く記述すか？によって、第三者検証で不具合が検出できるかが影響されます。 しかも最終的なプログラムでは記号の１つが違うだけでバグ発生となります。 コロン「：」とセミコロン「；」を間違えてしまうと それはバグになります。
実際にあった不具合例でも、設計者が「市場で出ちゃいましたか？ 万が一にもそんな使い方はしないと思った」と言った とかという話も聞きましたが、市場では万が一には発生するのです。
設計段階でできる「不具合の未然防止」とは？
製品特有の弱点を理解しているのは 設計者自身でもあります。
どんなに厳格な試験を行なっても、その製品特有のリスクは見逃されがち。
だからこそ、設計者の視点を活かしたリスク管理が重要。
特に医療機器や自動車のように人命に関わる製品では、盲点を見抜く事が必須。
「安全性試験の合格＝問題なし」ではなく実際の使用環境をシミュレーションする発想が重要。
まとめ
- 製品規格試験に合格したからといって安全とは限らない
- 設計者だからこそ見抜けるリスクをどれだけ対策できるか？
- 想定外を想定するのが真のリスク管理である！
コメント