なぜPrAha Inc.のエンジニアは設計を学ぶのか

こんにちは！株式会社プラハCEOの松原です。

PrAha Inc.では日々「エンジニアの設計力の強化」に取り組んでいます。

今年の冬には2ヶ月ほど毎週2時間近くかけてDDDにまつわる質疑応答会を実施したり、設計に関する技術書籍の輪読会を行ったり、3人ずつの小さなグループに別れて全社員でモデリングに取り組んだり...

会社のみんなと内定者でDDDモデリング勉強会なう

DDDって「集約を跨ぐ時」の扱いが一番難しいのに、同時に一番手法が幅広くて意見が割れやすいので、チームで基本方針を決め打ちしちゃうのが良いんだろうなぁ pic.twitter.com/crNHL6GwTe

— dowanna @PrAha Inc. CEO兼エンジニア (@dowanna6) August 20, 2020

なぜPrAha Inc.では設計を学ぶのでしょうか？

設計を学ぶ事は無駄にならない

WEBサービスを作る時にiOSアプリを開発する知識は不要だし、pythonで書かれたAPIを作る時にGo言語の知識は不要だし、バックエンドを全てlambdaで作成するならオンプレミスサーバの構築に関する知識は（一部を除いて）不要です。

作るサービス次第では、自分の保持している知識が無駄になる可能性があります。せっかく学ぶなら、何を作るにしても使える知識を習得したいものです。

それがソフトウェア設計です。

凝集度、結合度、デメテルの法則、SOLID、VIPER、クリーンアーキテクチャ、DDD、アトミックデザインに基づいた設計...

「変更しやすいコードを書く技術」は何を作る上でも役に立ちます。

今後AR/VRやDappsや未知の技術が現れたとしても、そこにソフトウェアが関わる以上、設計に関する知識が無駄になる事はありません。

「絶対に無駄にならないことから勉強した方が効率的だよね」と考えた末に、設計を学ぶことに決めました。

設計は、失敗した時の影響が大きい

ファットコントローラをリファクタした経験はありますか？

ビジネスロジックを大量に含んだフロントエンドを改修した経験は？

nullによる虫喰いだらけのDBをメンテナンスした経験は？

テストすら書けないコードを変更した経験は？

1つでも当てはまるなら、地獄を見たはずです。

初期段階の設計に失敗し、ゴミの上にゴミを重ねたコードを渡されたら、どれだけ優秀なエンジニアでも品質を維持するのは困難でしょう。

枝葉末節の実装に関するミスは簡単に直せます。

設計のミスは簡単には直せません。

だからこそ影響が大きい設計を学ぶべきだと考えました。

枝葉末節の技術は、どんどん自動化されていく

「コードを書くコード」はどんどん増えるでしょう。

bubble などのnocodeをはじめ、JS版のRailsライクなnest.js、feathersjs、OpenAIによるコード自動生成など、「人がコードを書く機会」は今後どんどん減っていくと考えています。ここまでの品質でなくても、ボイラープレートを自動生成するぐらいなら、僕のような何ちゃってエンジニアでも3時間程度でnpmパッケージとして公開できます。

自動化が進むと、例えば自分で最高のソートアルゴリズムを考えなくても、既に汎用化された最高のソートアルゴリズムが自動化に組み込まれていれば済むので、機械に近い低レイヤーの知識ほど習得する必要は薄れていくと考えます。

（勿論ソートがサービスの基幹であれば時間をかけて考えるべきですし、レガシーサービス、超大規模なサービスに関わる方々には必要な知識であり続けると思います）

機械に近い仕事ほど早く失われるとしたら、機械から最も遠いITエンジニアの仕事領域はどこか？と問われれば、それは設計です。

どんなツールをどう組み合わせてアイデアを形にするのか考える事。これがITエンジニアに残される最後の仕事ではないでしょうか。

（頑なに進化を拒むITサービスが時代の流れに抗い続けることで機械に近い仕事も残るとは思いますが、そうした不健全な生き残りについてはここでは言及しない...）

ヒトと機械のインターフェースが残る

より広義に捉えると、ヒトの世界と機械の世界のインターフェースが最後に残ると考えています。

盛んに騒がれる機械学習も大量の綺麗なデータが無ければ本領を発揮できませんが（最近はそうでも無いかもしれません？）「大量の綺麗なデータ」ほど現実世界で得難いモノも無い気がします。

機械は例外や汚れに弱い世界で生きています。複雑な現実世界をどうやって潔癖な機械の世界に落とし込むか。そこはITエンジニアの力量が問われる分野として残り続けると思います。

僕はITエンジニアの仕事が大好きです。コードを書くのは楽しいし、どう作るか考えるのも楽しい。この仕事を出来る限り続けたいと考えています。だからこそ、エンジニアであり続けるために必要な事（設計）から優先的に学びたいと考えています。

設計は、全員で学ぶ

少し細かい話に戻ると、設計は「全エンジニア」で「同時に」学ばないと効果が薄いと考えています。

例えば会社に1人だけ設計を意識しているエンジニアがいて、他の10人が一切設計のことは考えず、自由にコードを書く会社があったとしましょう。設計をきちんと考える1人のエンジニアはどうするでしょうか？多分、退職すると思います。

設計をきちんと意識する人にとって、設計に対する意識が低い相手と議論するほど消耗する事はありません。きちんと整理整頓する人の部屋に、汚部屋の主が引っ越してきて、家を荒らし回るような状況です。相当なストレスです。

かといって汚部屋の主を放置すると汚コードが量産されてしまうので、コードレビューで食い止めようとするかもしれません。

しかしコードレビューで設計を担保しようとすると、一人に注意した内容を何度も別の人に指摘する羽目になるため推奨しません。コードレビューは「明らかなミスがない事」などの確認に留めるべきで、設計の議論をする場としては非効率です。

最も効率的なのは全員で同時に学ぶ事です。一度認識が揃ってしまえば「どこにコードを書くべきか」という時間を取りやすい指摘事項が減らせるので、チームの開発効率も格段に上がります。ファイル名やディレクトリを見た瞬間に「多分こんなことが書いてあるんだろうな」と想像できる世界は幸せです。

それに、一人で学ぶより大勢で学んだ方が楽しいですしね。

まとめ

質問：

なぜPrAha Inc.は設計を学ぶ事を重視するのか

回答：

・最も無駄になりにくく、最も影響が大きく、かつ最後まで自動化されずヒトに残される領域になると考えているため。

・学ぶ時は全員で同時に学んだ方が良いし、楽しいよ。

現場からは以上です！