不具合の発生の背景
- Background of defects in products -
業務過多による疲弊が背景という指摘
自動車の不具合の場合、製品の設計に起因する不具合の割合が高いことを前回の記事で紹介した。特に、自動車のリコールにつながる製品不具合については、設計起因の不具合の中でも特に「評価基準の甘さ、開発評価の不備」による不具合の割合が高いことが国交省自動車局の資料で示されている(1)。「評価基準の甘さ、開発評価の不備」はどのようにして起こるのだろうか。また、どうすればこのような不手際を排除することができるのだろうか。
実際、このようなことは従来から考察されている。ここで「高品質と低コストのジレンマ：自動車リコール原因分析からの考察」(2)の内容を紹介したい。10年以上前に執筆された記事ではあるが、最近のリコールの原因は当時と変わっていないため、この記事に述べられている内容はそのまま現在にも当てはまる。この記事では「評価基準の甘さ」の背景は、「要求事項が増える一方、開発工数は減らされ、十分な組織的支援がないために生じる業務過多による設計担当エンジニアの疲弊などが影響している」と指摘されている。
この指摘は的を得ている。その理由は後述するとして、まず、「評価基準の甘さ」という課題を解決しようとした場合、評価基準が甘くならないような技術や仕組みを導入する、技術教育を徹底する、といった解決アプローチを選択しがちである。例えば、起こり得る不具合事象を想定し、FTA（Fault Tree Analysis）などの良く知られている信頼性技法で、その事象を発生させる要因を網羅的に抽出する。そして全ての要因に評価基準を設定し、一つ残らず事前評価すれば、評価基準の甘さは無くなると考えられる。さらに、デザインレビューでのチェック項目に信頼性技法による事前評価の結果を含めれば、設計基準の甘さは起こりようがないのである。実際、このようなアプローチは多くのメーカーで既に採用されているだろう。でも設計基準の甘さは長年、リコールの原因のトップを維持し続けており、製品の不具合は撲滅されていない。何故だろうか。
それは新たな技術や仕組みを導入する隙間が無いからである。つまり、ただでさえ業務過多なエンジニアに、さらに新たな技術や仕組みに取り組む時間的余裕は無い。技術教育の徹底という解決アプローチも同様に、業務過多のエンジニアに適したアプローチでは無いと思われる。筆者は設計者ではないが、ハードウェアの信頼性に関する研究開発に長年従事していることもあり、様々なメーカーのエンジニアと付き合いがある。第一線で活躍している設計者との付き合いで感じられる現場の肌感覚として、エンジニアの多忙さは現実味を持ってヒシヒシと感じることができる。以上のような理由で、ここで取り上げた記事(2)の「エンジニアの業務過多、疲弊」が不具合の背景であるという指摘は的を得ている。
何を隠そう筆者も、評価基準の甘さを解決するために、技術を導入するアプローチをかなり多く試みてきた。そのアプローチの全てが失敗したわけではないが、現場に導入できた技術は限られている。記事にはさらに「データ、情報の電子化が進み、データベースが年々充実しているにも関わらず、それらを参照する時間もない」と書かれている。評価基準の甘さを解決するアプローチとして、DXの活用は容易に考えられる。一方で、仮にDX的な仕組みを作ったとしても、何の工夫もなければ、やはり現場では活用されない。以上から、製品不具合を撲滅するには、エンジニアの業務過多や疲弊を考慮した上でのアプローチが必要なことがわかっていただけたと思う。