ソースコードなんて綺麗に書く必要はない

はじめに

私は以前まで、受託会社でスマホアプリを開発していましたが、独立してから自社事業に多く参画することになりました。
同じエンジニアリングでも受託会社からのマインドを一新する必要がありました。
それらの経験を経て感じたことを話したいと思います。

ソースコードなんて綺麗に書く必要はない

受託開発になるとソースコードに対して、ある程度品質を担保する必要があります。
理由は他にもありますが、一つ例を挙げると、開発する会社と運用する会社が異なるケースが存在するからです。
家に例えると、ハウスメーカーである建設会社とリフォームなどを行う地域の工務店みたいなものです。家を建てるのは建設会社ですが、リフォームを行うのは工務店です。
リフォームを行なっている際に、欠陥住宅であるということがバレると建築会社の信頼に関わるので、顧客は二度とその会社には依頼しないでしょう。
つまり、再発注をもらえなくなるリスクがあります。

f:id:QoopMk:20191107015116j:plain

極端な話、自社の新規サービスを構築する場合はそんなことどうだっていいのです。
ソースコードが汚くても、サービスが正常に使えるのであれば、ユーザーにとっては関係のない話だということです。
ソースコード内の変数をわかりやすい名前にするのってエンジニアの自己満であり、サービス全体を俯瞰としてみると小さな問題です。

もちろんマインドの話をしているのであって、汚いソースコードを書いてもいいって話をしているわけではないです。
例えば、何気なく行なっている言語を採用する際に関しても「このフレームワークは、完結にソースコードを書くことができるから採用しよう」ではなく、「このフレームワークを使うことでソースコードを完結に書くことができ、全体的な開発コストが下がり、ユーザーにサービスを安く提供できる」というところまで考えることが重要であるということです。

常にユーザーの利点に繋がるように考えていれば、1つの判断の軸になるかもしれません。