開発時の不具合は宝？
開発時の不具合は、いろんなプレッシャーの中で仕事をしなければならないのでイヤなものです。
ただ、量産後にその不具合が出た場合には、何倍何十倍も対応が大変です。
最初に苦労をしておいて、のちの苦労を減らすというやり方は、”Front loading”と呼ばれますが、日本のことわざにも ’当を得た一針は十針を省く’（ほつれ始めに縫っておけば、後でいっぱい縫わなくってすむ）という言葉があります。ただし言うは易しで実行には強い信念が必要です。
開発で大事なことは、開発中に、いかに多く不具合を出し切るかです。
そのために不具合を出し切れるような有効な評価ができるかです。
不具合への取り組み方
不具合対応で一番大事なことは不具合メカニズムの明確化です。これが誤っていたり、不十分だと再発や類似不具合のリスクが大きく、逆に不具合メカニズムを理論化＆実証することが技術力の蓄積に繋がります。
不具合要因分析（FTA）をすることは不具合解決のためだけでなく、不具合の価値を高めることができます。
まずは（試作）製造品質と設計仕様の両方のFTAをやって原因を絞りこんでいくわけですが、原因が分かって対策ができた後でも、このFTAにより見つかった弱点は、優先順位を決めて量産前には改善しておかなければなりません。
これをしておくと次の三つの不具合パターンを予防することができます。
- モグラたたきのような散発的に見える不具合
- 複合要因による不具合
- 品質レベルや変動による量産品質不具合
不具合対策は特許として権利化する
特許の説明には、従来技術、課題、解決方法（本発明）という構成があります。
不具合が対策できると良かった良かったで忘れがちですが、対策した内容を特許化しておくことは重要です。
特許化は、最終的に実施した解決手段に限りません。最終解決手段は、いろいろな要因を考えながら選ばれています。
例えば、対策の有効性以外にも、実施に必要な時間、コストアップ、保有生産設備への適合性などです。後半の三つで採用できなった案も特許化できます。
もし自分たちが、同じ製品を開発しようとした場合に必ず遭遇する不具合を先に検出した場合、自分たちが選んだ解決方法以外も特許として権利化しておくことは競合者に対しての防衛効果が大きいです。
競合者を網のように捕まえるためには、不具合対策をした時の議論を整理する必要があります。実際に試作してテストしたものは、特許的に言うと実施例です。その大元には、必ず対策原理Aが、そして採用されなかった対策原理B,C…があるはずです。対策原理Aはもちろんですが、議論の結果、今回は選択しなかった対策原理B,C…についても特許権利化の対象になります。
不具合は人を成長させる
結局、不具合は問題ではなく課題と呼んだ方が良く、これを一所懸命に乗り越えることにより、技術者としての知見は深まり、人間としての問題対応能力も向上していくのだと思います。
（アイアール技術者教育研究所 H・N)
