きっと誰かの暇つぶし

自動車業界の近くにいる現役エンジニアのクルマと思いつきの記録。

3.開発テストで一番怖いことは

なんやかんや5年くらいは自動車開発(いまは近いが違うけど)やってるとどういう時が怖いか分かることがある。

 

僕はずっと製品開発でテストエンジニアだったけれども進めていく中で一番気をつけないといけないのは狙った答えではないのに上手くいってしまった場合だ。

 

基本的製品開発の肝は開発期間中に不具合をすべて落とし込み対策をして不具合がないものを世に出すことだと思う。

 

期間内というのが大事で1日でもずれようもんならコスト等の影響が大きく守りきることが前提にある。そして量産前になればなるほど不具合がでた場合当然緊急度が高く自由度がなくなるので如何に早く不具合を予測し抑え込むかにかかっている。

 

なのでテストエンジニアはテストをする前に必ず予測をたて不具合が出そうならば対策をしてテスト前に落とし込んでうまくいくように仮説をたてる。

 

その仮説がねらい通りにいけばそれが本望。(もちろん当然確からしさの検証は必要である)

 

一方不具合がでた場合は何故予測を外したのか、何が原因なのか、不具合をどうおさえるか納期が決まっている中短い期間で事実確認→対策→再検証とやっていく。

 

不具合がでると苦しいのだけれども、その不具合はその時点でおさえることができるしある意味でさらに精度の高い予測ができる。

 

では狙い通りではないけど結果としてうまくいってしまった場合はどうであろうか。

 

結果がどうであれ予測と事実確認はする。でもうまくいってしまうと油断が生じる。気持ちの問題だが製品開発は時間との勝負なので検証するのにわざわざうまくいってるのにと思いがち(ダメだけど)である。

 

しかしそのうまくいったはたまたまもかもしれないし、不具合の兆候がでているかもしれないし、違う不具合が起こるかもしれない。そしてその場合最後の最後の量産前に起こるというのが往々にしてある。

自身もそんなことをしてしまったことがある。

それが起こると再び以前テスト(予測)を再検証しさらに今回のテストもまた検証ととにかく工数が倍増する。

これがかなり苦しい。まぁ結果としてなんとかなるのだけど(ほんとここがエンジニアってすごいと思うわ)

 

ただ初期にやっとけば良い話なのでやはりテストは検証→予測(対策)→テスト→事実確認までテストすることだと思う。

 

テストやるだけがテストエンジニアじゃないよなぁと自戒を込めて。