職業エンジニアしてるとプロダクトをすばやく完成させられなくなる気がした

職業エンジニアを始めてみて、一人でコードを書いていた時に比べると大きく違うコストのかけ方をしている部分があることに気づいた。

それは・・・言葉にはしづらいが、設計でもあるし、コードの質とも言えるし、エンジニア的視点の実装のクオリティを大まかに指したものだと思う。

で、会社で働いているエンジニアの方々はここにめちゃくちゃコストをかけている。少しでもキレイなコードにして、後々メンテナンスしやすい実装を保とうとしている。

プロダクトに関わるエンジニアはみんな、プロダクト本体に実装を反映させるまでに必ず相互にレビューするし、全通りのテストを必ず通すし、本番と同様の環境をつくって作った機能がきちんと動くか検証もする。えらい。

・・・だけどこれ、コードの質を担保出来る代わりに、時間がものすごく犠牲になる。正常な動きをするだけのコードなら1日で書ける量でも、想定しうる例外をちゃんと全部補足して適切な処理に振り分けてテストはモックして・・・とかやってるだけで数日、一週間、どんどん溶ける。やばい。溶けまくる。

この質を担保する癖、タンポ癖がつくと、恐ろしいことにいつの間にか怖くてコードをすらすら書けなくなってしまう。このコード、書き方として妥当なの？とか、MVCの設計的にいいんだっけ？とか、この命名本当にわかりやすいの？などなど・・・手が止まる機会が発散的に増えちゃって、考えるだけでコードちょびちょびしか書けないマンが完成してしまう。

なので、仕事でコードを書く時と、趣味でコードを書く時には、違う頭の使い方が必要なんだと割り切らなきゃいけないなと感じた。汚いかもしれないけどすぐ動くコード。これを目指すべきだと思った。これを正当化できそうな理由として以下が考えられる。

• 大体プロダクトを新しく作り始める時というのは、どんなものを作るかというのも緻密には詰めきれていないことが多く、作っていきながらその場の仮説検証の判断で大きく方針を転換することが多いだろうということ。すなわちすぐ捨てる可能性の高いコードに設計コストをかけるなということ。
• もしまかり違ってそのプロダクトが人気になってしまっても、大体の職業エンジニアとして優秀な人はリファクタリングや作り直しに長けている人が多く、その人達がなんとかしてくれるから気にするなということ。（そして逆に仮説検証のためにすばやく作っては壊しが得意なエンジニアは少なそうな気がする（！）ということ。）

汚く素早くコードを書いてプロダクトを実現させる考え方に関しては、あまり知見として公開したり、定式化している人を見たことがない。もう少し浅いところだと、モックアップとか、プロトタイピングとか、色々あるが、結局これらは使った感想を演技でしか作れなくて、あまりやっていて面白みを感じないなあと個人的には感じてしまう。

やるからには実際に動いてほしいし、使った演技はどうしてもリアリティを感じられないので、体験を観察するという視点でも、作った感から来るモチベーション管理としても動くものが出来ることはいいことだと思う。

というわけで動くものをつくることに最適化した感じでコードを書こうと思って考えを整理してみたが、この考え方で進めてどうなるかは後のポストで分かるかもしれない。

追記：もしかするとキレイな設計やコードの書き方に長けまくったエンジニアはプロダクトを実現するのもくっそ早いかもしれないが、現実どうかはわからないので（あのすたーとあっぷは1年前からソース書き始めて今年リリースとかよく聞くし）、今はキレイ＝スピード遅い！と仮説的に定義しちゃってる。自分がそうなので、もしかするとこれは自分に合わせた、あるいはエンジニア初心者的な論理かもしれない。