サービス開発を生業とするソフトウェアベンチャーにとって、優秀なエンジニア組織の拡大は事業を伸ばすための重要な要素。しかし創業間もないベンチャーにとって、開発チーム作りはおろか、エンジニア1人を獲得することすら難しいことも珍しくありません。
本シリーズでは、草創期にあるベンチャーがエンジニア採用の困難をいかに乗り越えるべきか、そのヒントを探るべく、成長を続けるソフトウェア企業の技術責任者に話を聞いていきます。今回はネットショップ作成サービス「BASE」や、ショップオーナー向け金融サービス「YELL BANK」など、さまざまなEC関連サービスを提供するBASEで、EVP of Developmentを務める「えふしん」さんこと、藤川真一氏の登場です。
優秀なエンジニアを採用するコツを公開
自社にマッチした優秀なエンジニアにアプローチできていますか？
開発に馴染みのない採用担当者や経営者にとって、エンジニア採用の要件を正しく設定することは容易ではありません。
そこで、優秀なエンジニアを採用するために押さえておきたいポイントを、1つの資料にまとめました。
専門知識を持たない採用担当者の方にも簡単に理解できる内容になっていますので、ぜひご覧ください。
BASE株式会社EVP of Development藤川 真一 氏1973年生まれ、埼玉県出身。FA装置メーカー、Web制作のベンチャーを経て、2006年にGMOペパボ株式会社入社。2007年から携帯向けTwitterクライアント「モバツイ」の開発・運営。2014年8月からBASE株式会社 取締役CTOに就任。2019年7月から同社取締役EVP of DevelopmentおよびPAY株式会社取締役に就任。2018年1月に慶應義塾大学大学院において博士（メディアデザイン学）取得。
Contents
現在の担当は、BASEの技術部門におけるCTOが担うべき仕事以外の「すべて」
——本日はよろしくお願いします。早速ですが、現在、BASEさんのエンジニア組織はどのような体制になっているのかお聞かせください。
BASEのエンジニアはすべてプロダクト開発部門に所属し、サーバサイド、フロントエンド、ネイティブアプリ、機械学習など、専門領域ごとにチームを分けています。いまBASEの従業員数は100名を少し超えたくらいなのですが、エンジニアの比率は約4割。デザイナーとプロダクトマネジャーを含めると全体の半分以上のメンバーがモノ作りに携わっている計算です。エンジニアは、プロダクトマネジャーやデザイナーを含む5名ほどのプロジェクトにアサインされ、日々、既存機能の見直しや新機能開発に取り組んでいます。
——2019年7月に、CTO職を後進に譲られたそうですね。
それまでテックリードを務めていた川口将貴にCTOを委譲し、現在の肩書きになりました。このとき、BASEにおけるCTOの職責を「開発現場のリーダーとして、技術によってサービスをスケールさせる立場」と再定義したこともあり、私が担当するのは、いうなればそれ以外の「すべて」。開発部門の環境整備やマネジメント業務の統括などがそれにあたります。
——現在は「EVP（Executive Vice President） of Development」という役職名ですが、具体的にはどのようなお仕事を担当されているのでしょうか？
主だったところだと、エンジニア採用、予算管理、社内情報システム、内部統制などですね。これらは、以前私がCTOだった当時から担当していた業務ですが、技術部門のマネジメント体制を見直すにあたってCTOの職務から外しました。あまりにも見るべき領域が増えてしまい、肝心の「技術」に専念する時間が少なくなっていたからです。そのため、いずれ後進に引き継ぐことを念頭に、これらの業務をいったん私がすべて引き取りました。将来的にVPoE的な立場で、エンジニア組織のマネジメントを任せられる人材が見つかったら、私自身はBASEグループ全体のシナジーを考える立場へと軸足を移すことになるかもしれません。
——草創期のベンチャーにおいては、CTOといえどもPCの設定からエンジニアのマネジメントまで「技術に関する何でも屋」になりがちです。どのようなタイミングでその段階から脱却されたのでしょうか？
BASEの場合ですと、2016年にシステムの信頼性を保証するSREチームを作ったことが契機になりました。このとき、それまでCTOが担っていたソースコードのデプロイ権限を彼らに渡したのですが、こうした責任の重い役割をうまく移管できたことが自信につながり、若い世代に権限をシェアしていこうという流れを作れた気がします。まずは自分が責任者として実務に関与し、ある程度理解が深まったら、素養や経験がある人に責任者になってもらう。そうやって徐々に権限や責任を組織的に分担し、それぞれが本来取り組むべき課題にフォーカスできる環境が作れるようになりました。事業内容や会社の規模、状況などによって異なるので一概にはいえませんが、新しい取り組みに挑戦するタイミングがチャンスだと思います。
ダイレクトスカウトは、意中の相手にラブレターを書くような気持ちで
——藤川さんがCTOとしてBASEさんにご入社されたのは2014年です。この間、エンジニア組織も大きく変わったのでは？
私が入社した当時、確かエンジニアはまだ10名もいなかったと思います。それに比べたらエンジニアの層はかなり厚くなりましたね。エンジニア採用のプライオリティが高くなったのは、2016年に大型の資金調達を行い、組織を拡大できる環境が整ってからのことです。それまで採用は当時のCOOが主に見てくれていたのですが、本腰を入れてエンジニア採用に乗り出すことになり、CTOだった私も採用に関わるようになりました。
——それまで採用のご経験は？
BASEに入ったときから「コードを書かないCTO」として、エンジニアの能力開発や開発組織のマネジメントに携わっていたので、面接以外でエンジニア採用の実務に関わることはほとんどありませんでした。そのため当時一番苦労したのは、エンジニアリングやマネジメントにまつわる仕事から、採用業務へと気持ちを切り替えることでしたね。どうしても得意な仕事に気を取られてしまって、なかなか採用について考えたり、作業時間を確保したりするのが難しかった記憶があります。
——どうやって乗り越えたのでしょうか？
やると決めた以上、腹を決めて頑張るしかありません。時間を決めて集中して取り組む、採用に専念すると周囲に宣言してそれ以外の仕事を一時的にシャットアウトするというやり方もありますが、私の場合は、CEOからの進捗確認など、周囲のプレッシャーを利用して自分を奮い立たせました（笑）。実際、エンジニア採用に携わってみると、すぐに募集情報を出すだけでは思うような採用が出来ないことがわかったので、自ずとプライオリティを上げざるを得なかったということも、意識を変えるきっかけになりました。
——草創期にあるベンチャーのなかには、採用に苦戦している企業が少なくありません。まずは自社の存在を知ってもらうために心がけるべきことがあれば教えてください。
先ほども少し触れましたが、募集情報を出せば優秀なエンジニアの関心を惹きつけ、採用できるかといえばそんなことはありません。それはどんな有名企業でも難しい。ダイレクトスカウトなどを駆使し、自社から能動的に仕掛けていかなければ、ほしい人材と会うことすら覚束ないのが現実です。とはいえ、宛名を変えただけにしか見えないスカウトに心を動かされる人はいません。私も以前、Wantedlyのダイレクトスカウトを利用したことがあるのですが、「なぜあなたに注目したのか」「あなたに何をしてほしいか」「自分たちならどんな環境が提供できるか」について、意中の相手にラブレターを書くような気持ちで伝えるようにしたところ、当初は芳しくなかった返信率が大幅に改善しました。もちろんプレスリリースやテックブログを定期的に書いたり、イベントに登壇して発表したりするなど、より多くのエンジニアと接触する機会を作っていくことも重要な取り組みです。プル型の情報提供と、プッシュ型の能動的なアプローチを組み合わせ、認知度を上げていくべきでしょうね。
——藤川さんがCTOとして採用に本腰を入れられてから約5年。IPOを経験されたBASEさんクラスの企業でもそこまでやるのですから、ベンチャーにやらない選択肢はなさそうですね。
メルカリさんのように、だれでも知っているような有名企業も積極的に情報開示を行い、エンジニア一人ひとりにきめ細やかな対応をとっているのは有名な話です。知名度が低いベンチャーがエンジニア採用を成功させようと思ったら、それ相応のパワーを注がなければならないのはいうまでもありません。誕生間もないベンチャーのリソースが乏しいのは承知の上で申し上げますが、採用において能動的なアクションを起こさなければ、何も状況は改善しません。自社にマッチした人材が集まれば安心して仕事を任せられるのですから、無理を承知でやりきらなければならない局面があるんだと覚悟して頑張るしかないでしょう。
——では、候補者の中からどのようにして自社にマッチするエンジニアを見つけるべきだと思われますか？
現状の組織に単に欠落した機能を埋めればいいといった安易な考えに終始していたら、適任者を見つけるのは難しいでしょうね。
——そうした考えに足りないものは何でしょう？
エンジニアが成長の手応えを感じてもらえる環境を作れるか、また年間を通してその仕事ぶりを評価したときに、給料で報いてあげられるかという観点が足りません。CTOという役割を現CTOに渡す前に、実績のある方を紹介いただきCTO候補の採用に動いていたことがあるのですが、「また現職と同じことをやるの？」と思われてしまったことが要因で採用できませんでした。僕がいたからコンフリクトしかねないという前提があったからかもしれませんが、採用はお互いのチャレンジが同期した時に実現するものだと思います。力のあるエンジニアは転職先に困りませんし、自己成長につながりそうなチャレンジがない仕事を好んでしたがるエンジニアは多くありません。仮にそんな奇特なエンジニアがいたとして、お互いが満足できる結果に至る可能性は低いのではないでしょうか。
大切なのはカルチャーフィット、そして事業コンセプトへの理解と共感
——エンジニアの立場や気持ちを踏まえたオファーを出すために、気をつけていることはありますか？
カジュアル面談を通じてとにかく相手の話を聞いてみて、「これは」というエンジニアには、その人のモチベーションを刺激しそうなチャレンジなり、成長のストーリーなりをこちらから提案することですね。また、人材を採用するときには、BASEのカルチャーである「Stay Geek（ギークであれ）」に馴染んでもらえそうか、また「Be Hopeful（楽観的でいること）」「Move Fast（速く動くこと）」「Speak Openly（率直に話すこと）」という行動指針に共感してもらえるかどうかを重視します。さらに、多様性を許容するインターネットの特性を生かし、魅力的で個性的なクリエイターやショップのみなさんに利用していただくことがBASEの成長の原動力であるという事業の核心部分についても、できるだけ丁寧に説明して理解を求めるようにしています。
——企業カルチャーや自社の存在意義に共感があれば、働く環境や担当領域、会社の状況が変わってもエンジニアの心が離れてしまうことは少ないでしょうね。
もし入社後、何かの事情でエンジニアのロールが変わったとしても、会社やビジネスの核となる部分に共感があれば、マネジャーとメンバーが話し合うことによって、よりよい落としどころを見つけることはできますからね。だからこそ、それだけにカルチャーフィットや事業の根幹を成すコンセプトの理解、共感は、組織の大小や事業フェーズに関係なく、非常に重要なポイントなんです。むしろ、一人ひとりの存在が組織に与える影響が大きい草創期のベンチャーのほうが切実かもしれません。経営陣はできるだけ早い段階で自らの考えや価値観を明文化し、ことあるごとにエンジニアに伝えるべきでしょう。
——当たり前のこと着実にやり抜くことで、道が開かれることがわかりました。最後にBASEさんのような企業を目指す、若きベンチャーに励ましのメッセージをお願いします。
もし「うちには有名なエンジニアもいないから採用が難しい」と考えていたとしたら、それもありがちな認識違いの1つでしょう。有名企業ですら苦戦するのがエンジニア採用です。もし社内に著名なエンジニアがいたとしても、積極的な情報開示や、エンジニアの共感を呼ぶオファー、そしてエンジニアが働きたいと思える環境づくりなど、やるべきことをやらなければ満足な採用はできません。とくに、特定企業を相手にする受託開発ではなく、多くの方々にご利用していただく自社サービス開発を手掛けているベンチャーにとって、自らイシューを見つけ、率先して課題解決に取り組むのは当然の試みです。当たり前のことを地道にやり続けた先に明るい未来があるのですから、苦しくても諦めず、なんとかエンジニア採用を成功させてほしいと願っています。
（取材・執筆協力／武田敏則）
＜藤川氏推奨。シード期、アーリー期の技術責任者にお勧めする情報源＞
『グロービスＭＢＡリーダーシップ』(グロービス経営大学院) 実際に新任マネジャーにオススメしている本です。リーダーとして人に動いてもらう難しさについてケーススタディとして学ぶことができます。2章ぐらいまでをサクッと読むことを推奨しています。
『ザ・プロフィット 利益はどのようにして生まれるのか』(エイドリアン・J・スライウォツキー) 古い本で恐縮ですが、さまざまな産業の利益モデルについて開設している本。自分達はどういうビジネスを提供しているのか？パートナーさんはどういうビジネスモデルなのか？などを意識することは、適切な期待値マネジメントをするのに必要なのではないかと思い挙げてみました。
『信頼の構造』(山岸 俊男) マネジメントにおいて一番重要なのは、チームメンバーや業務委託の方に適切な期待をかけるということです。根拠のない信用や過剰な期待はトラブルのもとですし、一切、人を信用しないというのでは仕事が回せませんし評価もできません。適切な期待値コントロールをするのに必要な「信頼とは何か？」ということを学ぶことができます。
『ピープルウエア』『熊とワルツを』(トム デマルコ) トム・デマルコの一連の本はソフトウエア開発組織の具体例にフォーカスした本です。昨今はアジャイル開発のようにプロセスそのものがマネジメント手法に基づくものがありますが、こちらは普遍的かつ抽象的なソフトウエア開発の生産性やリスクマネジメントについて知ることができます。古い本ですが、解決したい問題の根っこは流行りの開発プロセスとも共通するものがありますので、手法に依存しない「なぜやるのか、何をするべきか」を身につけるのにおすすめです。
▼あわせてこちらの記事もご覧ください
「エンジニア採用における6つの課題と解決策を解説」
https://www.wantedly.com/hiringeek/recruit/recruit_issue
「エンジニア採用が難しい3つの理由」
https://www.wantedly.com/hiringeek/recruit/engineer_recruiting_top
