0→1フェーズのエンジニア採用で候補者に聞くべきこと
アドベントカレンダー5日目。本記事でエンジニア採用に関する振り返りは最後にする。次週からは実際のプロトタイプ開発、顧客開発について振り返る予定だ。
スキルセットを見極めることを、あきらめる
非エンジニア出身の起業家は、エンジニアのスキルを見極められない。わたしの出した結論だ。コーディングテストを実施して、同じ領域で実務経験豊富なエンジニアが技術的な質問をする以外にエンジニアのスキルを見極めることはむずかしい。
起業家として面談時に聞くべきことは、エンジニアがアンコントローラブルな開発期間をコントロールできる要素をいくつ持っているか？だと考えた。
開発期間をコントロールできる技術要素３選
1 サーバーサイドをクラウドで開発した経験がある
クラウドサービスを使うとサーバーサイドの開発工数は圧倒的に短縮できる。これは事実だ。リソースが少ない上に限りがある０→１フェーズのスタートアップがクラウドを利用しない理由がない。
重要なのは、クラウドサービスに抵抗がないかどうかを確認することだ。使ったことのないAWS内のサービスについて調べることは問題じゃない。
AWSやAzure, GCPいずれかのクラウドサービスを利用して、Webアプリケーションを開発した経験を聞く。AWSと一言で言っても、AWSの中には数多くのサービスがある。どのようなサービスを使ったほうが良いのか？はアーキテクチャを設計して判断する。
2 クライアントサイドよりもサーバーサイドが得意である
1名のエンジニアにWebアプリケーション開発を作ってもらう場合、フルスタック（クライアント・サーバーともに実装経験がある）であることは必須条件だ。
Webアプリケーションは機能の集合体である。機能がなければ始まらない。機能はサーバーサイドで実装する。機能を作るスピードが早ければ、開発工数を短縮できる。だからサーバーサイドが得意なエンジニアを採用する。
レストランを例にすると、クライアントサイドは店舗の内装やホールスタッフのような役割を担う。ユーザーが気持ちよく注文できる、過ごせる環境をつくる。サーバーサイドは厨房だ。ユーザーが注文した料理を実際につくる。
レストランで最も大切なことは、注文された料理（機能）を実際に作れることである。たとえ、店舗が汚かったり、ipadやスマホで便利に注文できなかったり、ホールスタッフの顧客対応が悪かったとしても、美味しい料理（機能）が提供されれば、ユーザーは不満があってもお金を支払うだろう。逆に、どれだけホールスタッフの印象が良くても、店構えがきれいでも、注文した料理（機能）が一向に作られなければユーザーはお金を払いたいとは思わない。
3 アーキテクチャ設計に対して挑戦心がある
アーキテクチャ・システム設計が苦手だという候補者は採用しない。非エンジニア出身の起業家は、この業務をエンジニアの代わりに担えないからだ。
重要なのは、アーキテクチャ設計経験があると書いていないことである。複業人材で０→１開発に興味があるエンジニアさんは、「私だったらこうやって作ってみるなぁ〜」と考えつつも、すでにある設計をもとに正しく実装する業務がふだんのミッションであることが多い。エンジニアさんが抱えるこの葛藤が０→１フェーズの起業家に合致する。
捨てなければならないのは、アーキテクチャ設計経験だ。経験があればマネージャーレベルである可能性が高い。契約単価が高額であったり、人気だから魅力ない０→１フェーズのスタートアップには興味を持たなかったりする。彼らの次のステップはCTO候補としての経験だったりする。
開発期間をコントロールできる非技術要素３選
私は60分程度の面談で、はじめてお会いした人の人間性を見極められるほど偉くない。見極められると勘違いするような人間にもなりたくない。人って出会う人によって変わることもあると思うから。
とはいえ、人間性まではいかなくとも、開発工数を短縮できる技術以外の要素というのはあるなと思った。
1 リスクを共有できる
０→１フェーズのスタートアップにとってのリスクは、リリース日が遅延することだ。
０→１フェーズの起業家が採用できる人材は、エンジニアの契約単価から鑑みるにジュニア以上シニア以下、マネージャー未満だ。つまり、技術スキルがとてつもなく高いエンジニアは採用できない可能性が高い。
問題ない。限られたリソース、予算のなかでいかに進めていくのか？実現していくのか？がスタートアップ起業家の醍醐味であるはずだから。
大事なのは、チームとして一緒にプロダクトを開発するときに、目標のリリース月に間に合わなさそうな時間ベースの議論ができる人材かどうか。
「この機能の開発は時間がかかりそうだ」
「やったことがないです。だから調べる時間がかかります」
「間に合わせるなら、力技で実装します」
プロダクトアイデアを面談中に話す。自信を持って何ヶ月以内に開発できますと宣言するエンジニアさんは採用しない。プレッシャーを感じたときに、相手を不安にさせないために反射的に嘘や宣言をしてしまうタイプは、このフェーズでは危険だと考えた。
このタイプの人材は基本的に優しい。チーム規模が大きくなったときに、チームメンバーの誰かを守ってくれるタイプだ。ただ、人数が少ないチームではメンバー一人あたりのプレッシャーが大きくなる。このとき、誰かを守ってしまうがゆえに自分自身が潰れてしまったり、潰れてしまわないように反射的に防御反応が出てしまうと、期日が遅延するリスクが高くなる。
2 技術に関して、やりたいことがある
エンジニアさんが技術に関するやってみたいことを聞く。
０→１フェーズのじゃない方起業家が、エンジニアさんに応えられることは、それっぽいビジョンでもなければ、お金でもない。
技術に関するやってみたいことを、プロダクト開発の中で実際に好きなように挑戦していただくことだ。これ以外にない。
０から１を作るときに大事なことは、好奇心だと思う。好奇心は人間が進歩するためのエネルギーの根っこだとおもっている。これはエンジニアに限らない。起業家自身もエンジニアが使っている技術、考えてくれたアーキテクチャについて関心をもつ。そうじゃない起業家は、少なくともWebアプリケーションを収益源とした素晴らしい事業はつくれないとおもう。
実際、多くの起業家や経営者がいろんなアプリを作りたいと思っている。素晴らしいスタートアップのプロダクトが生まれている。でも、その裏には屍になったプロダクトたちがいる。その原因のひとつに、すべてをエンジニアに任せきる起業家の無責任・無関心がある。０から１はチームでやらないと絶対に素晴らしいプロダクトはつくれない。
多分、関心がない起業家は本当はそのプロダクトを作りたくないんじゃないかなって思ったりもする。
3 できれば長い期間働きたいとおもっている
人材が入れ替わりする頻度が高いと、引き継ぎリスクが発生する。キャッチアップ工数も増える。すると開発期間が伸びる。リリース日に遅延する。
忙しいから数ヶ月しか働けませんというエンジニアさんは採用しない。スキルセットや人間性に魅力を感じたとしてもだ。
チームワークには遅効性がある。対話する中で、メンバーの強みや弱みがわかってくる。そして最適なチームワークが何かを考える。ある程度固定されたメンバーのなかで試行錯誤を繰り返すことでチームワークが向上し、結果的に開発効率が改善し、開発工数が短縮できる。
3ヶ月だけ働きたいという人は合致しない。遅延リスクを考慮して、3ヶ月の開発期間を要する場合は、最低でも6ヶ月程度働きたいと思いたい人材なのか確認する。
実際に採用したエンジニア
AWS利用経験があった。クラウドサービスを駆使して開発工数を短縮できる引き出しの数が多いと判断した。つぎに、「今までバックエンドの実装開発をやってきたのでバックエンドに自信はある。バックエンドだけでなくてフロントエンドも学んでいきたい」と仰っていた。
バックエンドはNode.jsを利用していた。Node.jsはJavaScript実行環境である。もともとJavaScriptはブラウザ上で動作する言語だ。つまり、JavaScriptでバックエンドを書けるならばフロントエンドもキャッチアップしながら実装できると判断した。
フロントエンドはReactと呼ばれるJavaScriptライブラリを利用すれば、Webアプリケーションなのにネイティブアプリのような操作性を実現できるシングルページアプリケーションを効率よく開発できる。Reactを採用すれば、Next.jsと呼ばれるNode.js上に構築されたフレームワークを利用できる。
色々書いたが、エンジニアさんが既に持っているNode.jsでのバックエンド開発経験が活きる上に、モダンなWebアプリケーションを開発できると判断した。モダンな技術に挑戦すれば、開発チームを作れるフェーズになったときに、好奇心の強いエンジニアさんが興味を持ってくれる可能性が高い。中期的に考えてもデメリットがなかった。
契約期間についても、具体的な期限はなかった。最低1年は継続したいという希望だった。稼働時間は平日夜と土日。基本的には土日がメインになると話していた。
自分自身が会社員と複業を両立していたとき、平日に複業をやるのはしんどいことを知っていた。無理はしないでほしかった。少なくとも私は激務なコンサル企業で働きながらプログラミングスクールに通っていた時期にプライベートを両立できた記憶はない。スタートアップで働きながら資本金を貯めるために早朝と就業後に副業したときも相当きつかった。エンジニアさんに無理はしてほしくなかった。長く一緒にやりたい。
平日は自分自身も売上を立てるための受託業務がある。もし平日に質問があっても、すぐに答えられないリスクがあった。チームワークを成立させる点において稼働時間も問題ないと判断した。
幅広い技術に触れたいと話しており、開発言語選定の経験はないから一緒に話して決めたいと回答してくれた。リスクを共有しあえるとおもった。オファーした。
さいごに
ここまで振り返ると、ロボットのように採用活動をおこなったように感じるかもしれない。実際は違う。
あれだけ人間性やビジョンに意味がない、偉そうに判断してる人間こそ.. のような書き方をした。実際は違う。
人間って動物だから、言葉にできない空気感、嗅覚があるとおもう。実際、根拠はないけれどもプロトタイプをチームとして開発できるニオイを感じた。
でも、限られたリソースのなかでスタートアップ経営をやっていくことを決めた以上、1つの採用ミスが目標リリースの遅延になる。だから、自分の人間的な部分や感情的な部分で勢い任せにならないように、採用戦略と方法を考えた。
目をつぶって4月を思い出す。4月3日に複業クラウドを契約した。前準備を怠っていたから実際に求人を掲載したのは4月21日である。
プロダクト開発において起業家がコントロールできるのは、人でもなく品質でもなく期日だとおもっている。期日だけは起業家が決められるから。
そういう考えもあって、自分自身で絶対に4月中にオファーを送ると決めていた。これを動かしたら、すべてコントロールできなくなる。期日にイニシアチブを持っていたから、7月のプロトタイプリリースが守れたとおもう。
4月21日から4月30日までで面談できる人数は3〜4名程度だったとおもう。ここで、いくら候補者がいたところで起業家本人が対応できる時間がなければ意味がないと学んだ。
エンジニアさんと合意できた。本当に嬉しかったし感謝している。ずっと踏み出せなかった一歩をやっと踏み出した気がした。ここから毎月支出がグッと大きくなることにゾクゾクした。生活に不安もあったけれど、こういうときにアクセルを踏める大人がカッコいいと思うし、カッコいいって思える自分でいたいなと思ったから、やったった。
言わずもがな、突き詰めてしまえば、すべての話はエンジニアさんとの出会いも含めて運以外にないだろう。
この記事が気に入ったらサポートをしてみませんか？