機械の組み立てはごまかしが効かないツイート製造業時代に先輩に言われた「機械の組み立てはごまかしが効かない」という言葉をふと思い出した。当時いた会社で、ギアを使うような装置の組付けをする仕事をしてた時に、機械は適当に組むとすぐに問題が健在化する。原理原則に従って丁寧にやるしか手がない、ということ。問題が起きたら、必ず「急がば回れ」でしっかり解決すべきだということ。数メーターサイズの装置で、ギアを回すような機構を組み込む場合、ギアとギアの遊びとか、ネジに対する取り付け位置などがコンマ数ミリずれたまま組み立てると、異音が出たり、回すのが硬くなったりして、簡単に問題点が見つかる。初心者が組み立てた場合、先輩が軽くチェックすれば「何がダメなのか」問題がすぐにわかる。ソフトウエアで言うと、ペアプロして問題点をその場で指摘してもらえるようなものだ。何に問題があるのかを指導できる。進捗も、目の前にある機械の組み立て具合で把握できるので、作業が遅れているか否かというのもすぐに把握できるし、修正もしやすいし、修正に対する学びの量も大きい。・一見動いていても、不具合が隠れていることがあるが、そのコードクオリティがパッとは見えない・作業が遅れていることもあまり目に見えない・コピペコードのような低い品質のコードも指摘するタイミングが遅れる・動く動かないレベルより低いレイヤーの、コードが適切か不適切かどうかというのはわかりにくいなどの問題があって指導のタイミングが相対的に少ないと思う。これを解決するために、コードレビュー、TDDとかアジャイルによる進捗確認とかいろいろ提案されている。これらを導入することは、開発者の学びを得るという部分で重要だと考える。ソースコードの品質問題が発覚する時間が遅れれば遅れるほど、そのリカバーに対する学びの量は減っていくと思う。第三者チェックをせずリリースして後日問題が発覚したとすると、そもそも自分が何を書いたかなんてことも忘れてる可能性が高く、そういう人が反省をして学びの機会を得るというのは、正直、無理というものであろう。ソフトウエアの仕事は、学ぶのが少し難しい、と思う。ソフトウエアは割と力技で解決してもどうにかなってしまうという問題点がある。ソフトウエアにおける原理原則とは、セキュリティの件を一先ず置いておくと、CPUやメモリにとって心地よい動作になっているかということだと思うが、少々、CPUを熱くさせたとしても、性能向上が著しいこともあり問題は発覚しにくい。世の中のコードにおいては、将来のパフォーマンスの問題に繋がるコードでも、特に問題なく生涯を終えているケースは無視できないほどあるのではないだろうか。機械も、自動車なんかだと1年後ぐらいに溶接が甘くてリコールするような問題が発覚したりもするので、どっとも、そんなに変わらないんじゃないかという話もあるだろうが、原理原則に知らないことに対しては、ソフトウエアよりはハードウエアの方が厳しい(逆に言うと人の学びには優しい)かなとは経験論としては思うところである。Garageは、Webを中心としたビジネス&テクノロジーに関する思いつきを綴ったブログです。初代モバツイ開発者インターネットと日常の生活が融合された「何か楽しいもの」/「便利なもの」を作ることを目標に活動中。Fujikawa(@fshin2000)。