機械の組み立てはごまかしが効かない

製造業時代に先輩に言われた「機械の組み立てはごまかしが効かない」という言葉をふと思い出した。

当時いた会社で、ギアを使うような装置の組付けをする仕事をしてた時に、機械は適当に組むとすぐに問題が健在化する。だから原理原則に従って丁寧にやるしか手がない、ということ。

問題が起きたら、必ず「急がば回れ」でしっかり解決すべきだということ。

数メーターサイズの装置で、ギアを回すような機構を組み込む場合、ギアとギアの遊びとか、ネジに対する取り付け位置などがコンマ数ミリずれたまま組み立てると、異音が出たり、回すのが硬くなったりして、簡単に問題点が見つかる。

だから初心者が組み立てた場合、先輩が軽くチェックすれば「何がダメなのか」問題がすぐにわかる。

ソフトウエアで言うと、ペアプロして問題点をその場で指摘してもらえるようなものだ。すぐに何に問題があるのかを指導できる。進捗も、目の前にある機械の組み立て具合で把握できるので、作業が遅れているか否かというのもすぐに把握できるし、修正もしやすいし、修正に対する学びの量も大きい。

ソフトウエアの場合は、

・一見動いていても、不具合が隠れていることがあるが、そのコードクオリティがパッとは見えない
・作業が遅れていることもあまり目に見えない
・コピペコードのような低い品質のコードも指摘するタイミングが遅れる
・動く動かないレベルより低いレイヤーの、コードが適切か不適切かどうかというのはわかりにくい

などの問題があって指導のタイミングが相対的に少ないと思う。

これを解決するために、コードレビュー、TDDとかアジャイルによる進捗確認とかいろいろ提案されている。これらを導入することは、開発者の学びを得るという部分で重要だと考える。

ソースコードの品質問題が発覚する時間が遅れれば遅れるほど、そのリカバーに対する学びの量は減っていくと思う。もし全く第三者チェックをせずリリースして後日問題が発覚したとすると、そもそも自分が何を書いたかなんてことも忘れてる可能性が高く、そういう人が反省をして学びの機会を得るというのは、正直、無理というものであろう。

だから、ソフトウエアの仕事は、学ぶのが少し難しい、と思う。

またソフトウエアは割と力技で解決してもどうにかなってしまうという問題点がある。ソフトウエアにおける原理原則とは、セキュリティの件を一先ず置いておくと、CPUやメモリにとって心地よい動作になっているかということだと思うが、少々、CPUを熱くさせたとしても、性能向上が著しいこともあり問題は発覚しにくい。世の中のコードにおいては、将来のパフォーマンスの問題に繋がるコードでも、特に問題なく生涯を終えているケースは無視できないほどあるのではないだろうか。

もちろん機械も、自動車なんかだと1年後ぐらいに溶接が甘くてリコールするような問題が発覚したりもするので、どっとも、そんなに変わらないんじゃないかという話もあるだろうが、原理原則に知らないことに対しては、ソフトウエアよりはハードウエアの方が厳しい(逆に言うと人の学びには優しい)かなとは経験論としては思うところである。

【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください