CTOアドベントカレンダー2021の12日目の記事です。
今の時代、様々な組織の情報透明性が上がっています。
有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。
しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。
それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。
そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。
成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。
具体的に、事業内容によって必要なエンジニア組織が変わるとはどういうことでしょうか？
例えばWebサービスの場合、toC向けかtoB向けかで大きく特性が変わります。
一般の人がよく使うtoC向けサービスの場合、事業への共感が得やすいのでエンジニア採用はtoBに比べるとずっと難易度が低いです。ただしプロダクト志向の人は採用しやすい反面、技術志向の人は採用しにくいなどの課題はあります。
toCだと機能がたくさんあるかどうかは重要ではなく、UXとして洗練されているかどうかが非常に重要になってきます。そのためシステムのインタラクションとしてユーザにどう見せるかが重要になるため、必然的にプロダクト志向を持っていることが重要になります。
また仮説検証を早く回すことが重要であり、リリース後捨てられる機能も多くあります。捨てる予定のコードのためにリファクタをする時間は少なく、またコードの再利用性を犠牲にしてUXを良くするための処理を書いたりすることもあるため、コードのキレイさもtoBほどは重要ではないことも多いでしょう。
逆にニッチな事業ドメインのtoB向けサービスの場合、事業への共感が得にくいのでエンジニア採用はtoCと比較すると困難になります。
共感を得るため採用時には「この事業はどういう課題を解決するのか」と事業の意義を訴求することになります。
ただ最近では事業の説明をほとんどせず「どれだけ素晴らしいチーム文化なのか」「どういう技術的チャレンジがあるのか」を説明するような会社も数多く見受けられます。
特に最近よくバズっているのを見かける（ブランディングに成功している）会社については、文化についてとにかく推す会社が多いように思えます。
採用要件としては、仕様の複雑さを理解してコードを綺麗にメンテナンスし続けるスキルが重要になります。
また業務SaaSであった場合はユーザ企業のデータを預かることになるため、万が一にもデータを漏らしたり壊したりすることがないよう堅牢なコードを書く必要があります。
そういった背景により、副業エンジニアはドメイン知識や仕様の共有に時間がかかり、またガバナンスが効きづらい（書いてもらったコードを結局注意深くレビューする必要がある）ため、なかなか採用しにくいです。
副業採用するとしても、リファラルでよく仕事スタイルを知った人を採用したり、フロントエンド部分だけお願いしたり、仕様が簡単な部分をアサインするなど、工夫が必要です。
同じtoBというカテゴリの中でも事業ドメインの難しさによって事情は全く変わります。
メディアであったり採用系サービス（求人媒体、スカウトサービス）については、事業ドメインの理解が簡単ですが、Fintech系の特殊なロジックを扱うようなサービスについてはドメインの理解が困難です。
前者であれば前述のようなtoCサービスと似た特性になるかもしれません。
先程toBでセキュアさが求められるようなサービスだと副業エンジニアの活用は難しいと書きましたが、某toCのHR向けサービスの開発責任者に聞くと学生インターンを10人くらい採用しRailsコードを書いてもらっていてうまく回っていたと聞き、事業内容により本当に組織は違うんだなと考えさせられました。
toBか、toCか以外にもいろいろな要素が絡みます。
例えば「クローラで様々な他社サービスのデータを取得する」「様々な他社APIと連携する」といった機能があるとマンパワーが必要になるため、スケールする組織・アーキテクチャにする必要があります。またページ数・機能数が多いサービスもやはりスケールできるようにする必要があります。
組織拡大する上では、一般的によく言われる原則からいうと「優秀なエンジニアだけを集める」のがエンジニア組織としては理想です。しかし優秀なエンジニアにとって技術的に退屈なチャレンジをし続けることになるのはモチベーション低下に繋がりチームの雰囲気も悪くします。1つの事業でできる技術的チャレンジの数は限られているので、それに挑戦できる席を全員に用意し続けることは困難です。下手をするとしなくてもいい技術的チャレンジをすることになり、オーバーエンジニアリングを招く恐れもあります。
そういった場合は、まだ経験が浅いけれども大量のコード量をゴリゴリ書いて成長したい若手エンジニアを採用したほうがむしろ優秀なエンジニアを採用するよりもうまく回ることもしばしばあります。
ジュニアなエンジニアはたくさん手を動かせて技術力が身につき、シニアなエンジニアは技術的に困難なタスクに集中できるというwin-winなチームになります。
新規事業立ち上げに関わるエンジニアの人は、自分が立ち上がる事業にはどんなエンジニア組織が必要なのか是非意識してみるといいのではないかと思っています。
