コードレビューするくらいならコードレビューする必要ないエンジニアを採用する

シード・アーリーステージのCTOはつらいよ

　シード・アーリーステージのCTOは業界の多数の「すべき」と戦う必要があります。CI/CDが整ったDevOpsを構築すべきだし、新しいUIはABテストすべきだし、明確なジョブディスクリプションのもとエンジニアを管理すべきだし、エンジニアの成長を促すような教育・評価制度を整えるべきだし...
タイトルにある「コードレビュー」もその中に含まれるかと思います。
　大企業やメガベンチャー等でのみ働いていた方や、そういった企業の情報が標準だと思っている学生の方からみると、それらの「すべき」は当然あるものと考えます。（シード・アーリーステージを経験していなければ必然的にそうなります。）

考えるべきこと

　人・もの・カネ・時間がないシード・アーリーステージの企業は何をやらないのか優先順位を決める必要があります。その優先順位を決めるために必要なことは、コストxインパクトの考え方です。「コスト」は人・もの・カネ・時間と考えます。そして、「インパクト」はユーザに与える価値の大きさです。つまり、より「コスト」が小さく、より「インパクト」が大きいものから優先的に対応していきます。

コードレビューはユーザに何を与えるか？

　では、コードレビューを行うことによってユーザに提供できる価値は何でしょうか？それはサービスが安定して稼働する、新機能追加の速度が上がるといったところかと思います。でもこれってユーザをしっかりと獲得できて、定着した後じゃないと意味ないですよね？

ユーザに提供すべき最も重要な価値とは

　では、シード・アーリーステージの企業にとってユーザに提供すべき最も重要な価値とは何でしょうか？私はそれは、これまでにない新しい価値を与えることだと考えています。つまり、企業のコアバリュー・存在意義そのものです。

コードレビューするくらいならコードレビューする必要ないエンジニアを採用する

　（ここでタイトル回収です。）
　以上のことから、シード・アーリーステージのCTOはコードレビューする時間を捻出するぐらいならコードレビューする必要のないエンジニアを採用するために時間・カネを使った方が良いと考えています。
　そのために、ジュニアレベルは採用せず、できるだけレベルの高いエンジニアを採用する。レベルを測りかねるなら業務委託からスタートして様子を見るといったことも重要かと思います。当たり前ですがレベルの高いエンジニアはそう簡単には見つかりません。しかし、最近は副業や複業が基本的になっていますし、そういったエンジニアを探すサービスもたくさんあります。また、企業のミッションやコアバリューが魅力的であれば必ず興味を持ってくれると思います。

最後に

　ここまで偉そうなことを述べてきましたが、振り返れば優先順位を間違えていたと思うこともありますし、採用に関してもうまくできたという自信はありません。しかし、この投稿の内容に関してはシリーズ前半まできた私がこれまでを振り返ってみて身に染みて思うことですので、誰かの参考になるのではないかと考えています。