設計根拠を残す人は少数派？
回路設計、機構設計、ソフトウェア設計、どのような設計においても「設計根拠を書き残すこと」の大切さは語られています。
しかし実際にはきちんと書き残している人は少数派のようです。
製品設計では、設計結果は必須の成果物（アウトプット）として作成されます。
電子回路で言えば回路図、部品表、プリント基板図などがそれにあたります。
それは設計者のアウトプットそのものなので誰もが作っているでしょう。
一方で、設計の根拠をきっちり文書として作成している人はどれだけいるでしょうか。
「ここはどういう考え方をして、こういう構成にしたのか？」
「この設計値を導き出した計算は？」
を書き残すことが会社や職場のルールで決まっているところならともかく、
それが本人の意思に任されている場合、記録している人は少ないのではないでしょうか。
私が設計現場にいた当時の実感では、設計根拠を整理して残していた人はやはり少数派でした。
かく言う私も、電子回路の設計者として仕事を始めた当初はノートにざっとは書くものの、丁寧に書き直すような事はしていませんでした。
正直、終わった設計作業を振り返って、何を考えたかを書くのは面倒です。
なかなか手を付けないうちに時間が経って細かいことは忘れてしまい、結局はきちんと書かずに済ましていました。
トラブルシュートで大いに困る
ところが、製品をリリースしてしばらくしてから、その製品がトラブルで戻ってきたときに困るようになりました。
技術部に解析依頼がくるトラブル対応は、サービス部門が手に負えずに回ってくるものばかりです。
原因究明のために設計を疑わなくてはならない場合もあり、その際に設計根拠を記録したものが必要になるのです。
ところが自分はそれ文書として残していなかったので、自分以外の人では検証ができません。
誰かに任せることができず、自分は手持ちの業務を止めてトラブル対応をしなくてはなりませんでした。
書き残して新しいことにチャレンジ
このようなことが何度も起きた後、懲りた私はようやく設計の背景を書き残すようになりました。
ただ、最初から上手な残し方ができたわけではありませんでした。
自分なりに検討の経緯や式を書き残して、ファイリングしておいたのですが、それを見た先輩から「何を言っているんだかわからん」と言われ、内心ショックを受けたこともありました。
試行錯誤が何年か続きました。
そうこうしているうちに、次第に残し方が改善されてきて、トラブル対応で効果を発揮しだしました。どうしてこのような設計になっているかが書き残されているため、トラブルの原因が元々の設計にあるのか、それとも部品の不良とか別の要因なのかの切り分けが早くできるようになってきました。
結果、作った製品の「手離れ」が良くなり、自分が今携わっている開発スケジュールへの影響を抑えることが出来るようになりました。以前より新製品の開発に集中できるようになったのです。
設計根拠を「いつ」、「何を」、「どこまで」残すべきかについては別の機会に書きたいと思います。
コメント