業務委託CTO的な役割を２年近くやって気づいた「30人くらい迄のテックベンチャーで求められること５選」〜その４、エンジニア向け採用資料で重要なのはテック話ではない〜

エンジニアの採用環境は年々厳しくなっている

私が正社員としてのエンジニア採用に主体者として関わっていたのは２年ほど前なのですが、ここ最近も採用に関する相談は頻繁に頂きます（もしかすると最も多い相談内容かもしれません）相談を受ける以上は主体者じゃなくとも直近の採用環境をリサーチして話すわけですが、コロナ禍において「今まで売り手市場だった採用マーケットが逆転するのでチャンス！」という話題を耳にする機会もあります。しかしながらエンジニア採用に関しては引き続き難易度が高い状況が続いてると感じており、過去に比べて簡単になっている事は一つも無く、むしろ以下の理由を主として更に難しくなっていると感じています。

・各産業分野においてスタートアップからメガベンチャーまで幅広く参入しており採用における競合優位性を保つのが困難、数年前ならtoB向けバーティカルSaaSというのは良くも悪くも採用における競合は大していなかったのですが今ではメガレベルの競合が存在する事もあります

・ICTエコシステムは細分化が加速度的に進んでいるので最適な技術マッチングポイントを見つける事が複雑化しています。エンジニアであっても一人きりでスキルマッチを見極めるのはカバー範囲が広すぎるので難しく、非エンジニアで事業フェーズと必要スキルスタックの見極めをするのは殆ど無理だと感じています

・採用コスト、年収コストのどちらも高騰していおり、体感では２年前と比較すると正社員でも1.3倍、フリーランスについては1.7倍程度に高騰している感触です

という背景から経済合理的な側面から企業におけるエンジニア採用の難易度は増加していると感じています。

そうは言っても採用を進めなきゃコトが進まないのでどうすればいいのか？

創業者にエンジニアメンバーが居れば立ち上げフェーズは自身のネットワークを使い倒して何とかなるとしても、事業拡大していくフェーズでは必ず採用活動によって人手を増やす事が必要になります。とはいえ市況に合わせたコストで採用を進めていけるほど体力がある企業や事業モデルばかりでは無いので大抵はジレンマに陥ってしまうと思います。そうなると月並みなアイデアですがお金以外の部分で自社に魅力を感じてもらう事が必要になります。幸いな事にエンジニアの中にはお金を最優先事項として判断しない方は沢山居るので、下記の内容をしっかり伝える事でお金の面で優位性が無くとも採用が進む可能性はあります。

1. 行っている事業でどんな課題を解決しようとしているのか？その事業のビジネス的な実現性はどの程度なのか？その理由は？

2. 職場の環境や一緒に働く人達はどんな人なのか？事業の成功を目指す為にどのようなマインドセットが求められるのか？

3. 事業の成功に必要となる技術は何か？技術に期待している事は何か？

1と2についてはエンジニアという職種に限らずしっかり伝える事が必要だと思います。3については最も難しくて実際にアンチパターンになっている事を良く見かけます。これについては期待が大きすぎても小さすぎても駄目なのでエンジニアとしての経験が全く無い方が上手く伝える事は困難です。例えば以下のような伝え方は典型的なアンチパターンです。

・XXというテクノロジーさえあれば事業の成功確率は高い
具体的にそのテクノロジーが事業のどの部分に効き、結果として成功確率が高いという理由をかなり細かく説明できない限りは納得されません。エッジの効いた特定の技術が事業の要素にアラインしてビジネス成果を出す事はかなり難しく技術自体が先行して判断されるとほぼ失敗します。それよりも事業上の課題にフォーカスした上で技術を選ぶのが正しい順番です

・テクノロジーに関しては全く分からないのでお任せしたい
1の説明が充分に出来た上でエンジニア自身もビジネスにおける成果の出し方（お金の稼ぎ方という事です、プロダクトのコードが直接的にお金を稼ぐわけではありません）を理解していれば上手くいきますが、そうでない場合は中長期で期待値とのズレが起きやすいパターンです

・何を作れば良いかは分かっているので作るところは任せたい
明確すぎる分業は失敗しがちです、特にプロダクトや事業の初期段階ではその確率が上がります。経営者、事業責任者、プロダクトマネージャー、エンジニアリングマネージャー、エンジニアは全て違うロールで必要な技術も異なりますが、各ロールを縦割りにするのではなく専門分野を持ちつつ全てのロールを横断することの期待を伝えないと事業の成功という大枠の成功に寄与しない事に注力してしまうなどのズレが起きます。

というアンチパターンを踏まえて具体的にどのような事を伝えるか？を考えてみます。

事業と技術の繋がりの説明

実は上に挙げたアンチパターンは全て似た構造を持っています。どれも「事業よりもテクノロジーが先行して考えられてる」という構造です。つまり良いと言えるパターンと真逆であり、あくまでも事業環境や事業課題が先行した上でテクノロジーが適用される、という順番であればアンチパターンを回避できます。Googleの検索エンジン誕生の話などはテクノロジーの深堀りから圧倒的な事業規模を築いたので、そういう例を完全に否定はしませんが自社と初期Googleの環境差異は充分に検討した上で事例として理解したいところです。
事業課題を先行して考えるためには事業を詳細に伝えるしかありません。前回記事でも「非エンジニアに伝わるアーキテクチャ図」の話題を書きましたが、今回は「非ビジネスサイドに伝わる事業構造図」が必要となるわけです。事業はビジネスモデルや4C,4Pなどのマーケティング概念、バリューチェーンや各種の戦略論などがあり、説明するツールは豊富ではありますが上手く説明するのはとても複雑です。事業に慣れてないエンジニアがこの複雑な概念を簡単な説明で理解する事は出来ないので詳細な説明をする事が大事です。
詳細な事業説明と把握している事業課題が説明出来たらテクノロジーの適用はエンジニアの判断に任せて問題ありません。この場合に重要なのは必ずしもテクノロジーが課題解決として適切でない場合があるという事です。事業や企業にとって良いエンジニアは最適な解決案を見つけてくれるので、その方法がプログラミングやシステム開発でなくても適切な方法を提案出来るならば採用すべきエンジニアです。

それではエンジニア向け採用資料とは何かと言うと、事業の内容や課題（出来れば目標や目指す姿）を詳細まで説明している資料という事になります。技術の話はそんなに必要なく、すでに開発が進んでるのであれば使ってるテックスタックや組織形態を説明すれば充分です。

実際の採用資料を見てみる

では実際の採用資料例を見てみましょう。これまでの流れ通り画像館プロジェクトを例にとって採用資料を作成しています。
https://docs.google.com/presentation/d/1IAIdB7Q2uyR68_NW0KBObg28arQxHnaH4rqSsKGwMNs/edit?usp=sharing

※前回まで使っていたスプレッドシートはこちらです
https://docs.google.com/spreadsheets/d/1Ar3cVAO3TzDJywfjI5rJO7K03pHbM2ohRo2Nh_cd7hY/edit#gid=1400109227

今回はnote用のプロジェクトという事なのでビジネス部分のロジックが薄弱だったり、デザイン要素がグダグダになっているのはご愛嬌という事で・・それよりもこの資料のポイントとしては下記の点です。

・画像という素材をライブラリを用いて変換したり、メタデータを機械学習で分類するのに適切なライブラリが豊富である、という観点でPythonを選択しています。もちろん他の言語でも何とかする事はできますが「宗教上の理由でPythonが触れない」とかでない限りは本プロジェクトにおいてPythonは優先的なチョイスになると思います。

・フレームワークとして新興のFastAPIを用いています。フロントとバックエンドの分離については当初からやるか悩ましい部分なのですが、モノリスでやる場合のチョイスとなるとdjangoが優先されると思います。ただしdjangoは日本国内においてはそこまでメジャーフレームワークというポジションでもない（ここは本気でやるなら定量的に調べますが）上にGeneric viewsという少し独特なview機構が他のフレームワークから来た人に学習コストを強いる可能性が高いので2020年9月のタイミングでは優先的に使いたい状況では無いと判断しています。以上の理由からマイクロフレームワークであるFastAPIをチョイスしてフロントはtypescript系フレームワーク（個人的にSPAフレームワークは全部何とも・・という感じなのでエイヤでNuxtです）をチョイスしてバックエンドの学習コストを抑えると共に、プロジェクトに携わるエンジニアにとっても未来に向けた投資になると考えてチョイスしています。

・インフラやコミュニケーションツールについては最近実務で使っているモダンで使いやすいツールをチョイスしています。この辺りはツールオタクの如く誰もしらないようなツールをチョイスする必要はなく、現時点である程度シェアがあり（イメージとしてはアーリーマジョリティに達している製品）エンジニアが使った上でモダンさを感じられるツールであれば良いと思います。ちなみにプログラミング言語などの実際の製品開発技術以外であるこの部分は入社前後のギャップが大きくなりがちなので、開発フローも合わせて入社前にしっかり伝えておくと入社後もスムーズに動けるようになります

次回はやっと第１章最終回です。直近私自身も置い続けている開発投資対効果がテーマです。