withコロナのエンジニア育成と採用の戦略と実践とは？(前編)
2020年8月4日に開催されたCTOmeetupのテーマはwithコロナのエンジニア育成と採用。規模感やフェーズの異なる企業から登壇者を招き、コロナ禍への対応も含めて両テーマについて語っていただきました。
今回は特に、スタートアップ企業の参考になるような話題が満載。エンジニアの育成や採用に課題を感じているCTO、VPoE、経営層の方はもちろん、テックリードやPMなど直接エンジニアをマネジメントする立場の方もぜひ一読ください。
目次
登壇者の自己紹介
各社のエンジニア組織の概要とフェーズ
株式会社マクアケ 執行役員 CTO 生内 洋平さん（以下、生内）：株式会社マクアケのCTOを務めている生内と申します。もともとはバンドマンからキャリアをスタートしたのですが、デザイナー、エンジニアを経て現在は会社経営をする事業家です。
マクアケ自体は創業8年目、僕は入社して3年ほどです。会社はかなり急成長しており、僕は主にクリエイティブ（開発・デザイン・UX）組織づくりを担っています。入社当時は8名だったクリエイティブ組織も35名の規模になりました。サービスは創業時から使っているPHPを引き継いだアーキテクチャもありながら、マイクロサービスにもアプローチしている最中なので、レガシーとモダンが入り混じったような形になっています。
株式会社スタメン 常務取締役 VPoE 小林 一樹さん（以下、小林）：株式会社スタメンのVPoEを務めている小林です。2016年の創業時に取締役CTOとして参画しているので、現在5年目です。スタメンは、名古屋、東京、大阪の3拠点に展開している60名ほどのスタートアップです。本社は名古屋で、新幹線の高架下にある非常にベンチャーらしいオフィスで仕事をしています。
作っているサービスは組織の信頼関係の構築目的とした「TUNAG」という企業向けSNSで、2017年のリリース以来、規模を問わず300社以上に導入されています。スタメンではチームワークやチームビルディング、育成を重視しており、エンゲージメントを重視した経営を評価していただき Great Place to Workによる2020年度「働きがいのある会社」小規模部門1位に選出されました。
採用に関しては、名古屋は東京に比べるとエンジニアの経験者が少ないこともあって、新卒や未経験者を積極的に採用し育成しています。現在はデザイナーも含めて21名の開発部門ですが、平均年齢は27.9歳。20代が67％を占めています。実際には24～26歳が多いです。 エンジニアは18名で、このうち未経験で入社したのは12名です。一方で技術的にはPCとスマホで利用される社内SNSということで、大規模かつ複雑なアプリケーションになっています。未経験者を育成しながら高い技術力が求められる複雑なSaaSを運営しているという状態ですね。
現在も採用には力を入れていますので、今日の話を通してスタメンにも興味を持っていただければ幸いです。
BASE株式会社 取締役 EVP of Development 藤川 真一さん（以下、藤川）：BASE株式会社の取締役EVP of Development藤川です。BASEグループはBASE、PAY、BASE BANKの3社から構成されているのですが、僕はその全てに関わっています。まずBASEは無料でネットショップを構築できるサービスを開発運営している会社で、先程もお伝えしたとおり僕は取締役です。さらに、PAY株式会社というクレジットカード決済のAPIを提供している会社でも取締役を務めています。もう一つがBASE BANK株式会社で、「BASE」のショップ様に対して資金提供を行ういわゆるFintech系のサービスを提供しています。僕はここではマネージャーの立場です。
当初はBASEの技術顧問を経てCTOに就任したのですが、去年別のメンバーにCTOの役職を引き継ぎ、その人がサービスの維持継続に専念することになりました。僕は現在、VPoEやCISO的な仕事を全て担っています。
立場的に特に重要なのが採用で、今はハイスキルなフロントエンジニア及びサーバーサイドエンジニアを探しています。フロントエンドはVue.jsが中心、サーバーサイドはPHPです。AWS環境があったり多大なトラフィックが発生したりするので、安定的かつ良いUXのサービスをどう実現するかという視野で一緒に走ってくれる方を求めています。
今日は皆さんのお話を伺って僕も勉強したいと思っていますので、よろしくお願いします。
ShowTalk株式会社 執行役員 CTO 水上 学さん（以下、水上）：ShowTalk株式会社でCTOを務めています水上です。会社は2017年にスタートし、東京の本社以外に青森と福岡、宮崎に事業所があります。サービスはセールスに特化したチャットボットです。実は僕は2020年7月1日に入社したばかりで、まだ1ヶ月しか経っていないという状態です。
ShowTalkの特殊な部分は、6月時点でエンジニアが1名しかいなかったことです。現在は僕も含めてエンジニアが4名、PMが1名で、エンジニアは全員リファラルで採用しています。まだまだエンジニアチームを立ち上げるフェーズという段階です。もともとエンジニアがいない状態で事業が成長してきた会社なので、エンジニアチームの存在意義を社内で認められる状況を作る必要があります。現在は総合職とは別に、エンジニアの評価基準や目標、給与テーブルなどを作成中です。本日はどうぞよろしくお願いします。
withコロナ状況下での各社育成の変化
コロナの状況に合わせてリモートと出社を柔軟に切り替え
生内：各社に社員の育成ポリシーがあり、コロナ禍で変化した部分もあると思います。みなさんは現在どのように育成に取り組んでいらっしゃるのでしょうか。
小林：当社は実務での開発が未経験で入社したエンジニアが多いので、エンジニアとしてのマインドセットや行動規約を作ったり、1on1、席の配置などを大事にするなど、密なコミュニケーションで育成する方針です。育成した人が育ったら、その人がまた新しい人を育てるというチームカルチャーも大切にしています。
ただ、コロナの影響でオフィスでのチームビルディングができなくなってしまったので、現在はオンラインに移行しています。コロナの動きに合わせてオンラインと出社を切り替えており、緊急事態宣言解除後にリモートワークからオフィスに戻しましたが、第２波で今はまたリモートになっている段階です。
コロナがなんとか収まったらまた出社に戻したいと思っているのが、他社と違うポイントかもしれません。オフィスを出社する価値のある場所にしたいと考えて組織運営している会社です。
生内：うちも週単位で出社かリモートにするかを判断しています。コロナ禍ならではの状況ですね。
小林：週単位、あるいは木金のみリモートにするといった形で出社とリモートを切り替える方法も考えたのですが、一旦は1ヶ月単位でオンオフを切り替える作戦にしようと思っています。出社とリモートではマネジメントのスタイルが違いますからね。
生内：一つお伺いしたいのですが、まだまだエンジニア組織が大きくない段階から行動規約を設定するメリットはどういうところにあるのでしょうか？
小林：「Star Code」という行動規約を作ったのが2019年なのですが、これはエンジニアが10名いる中で4名辞めてしまったタイミングだったんですよ。残ったメンバーで今後どういうチームを目指したいのか、どういう人を採用したいのかをひたすら話し合いました。本音で話したいとか、誇りを持って仕事をしたいといった想いを積み重ねて完成したのが「Star Code」なのです。
やはりみんなで議論すると当事者意識が持てます。組織が大きくないときに、みんなで作ったからこそ、各自の考えが反映された当事者意識が強い行動規約になり、チームのカルチャーが一気に固まったと思います。朝会や1on1など1日に何回も行動規約を引用して内容を組織に浸透させ、行動が変わるようにしています。
会社へのロイヤリティを損ねないための対策
生内：藤川さんのところは全く規模が違うと思いますが、いかがですか？
藤川：うちは少人数というわけではありませんが、少数精鋭であるという感覚は持っているので、ある程度自立して動ける人を中心に採用しています。もちろんジュニアエンジニアを採用することもありますが、その場合もきちんとメンターが付き、エンジニアリングマネージャーが1on1を実施してチームを引っ張っていきます。マネージャーを中心としたコミュニティを意識しながら上手くやるという感じですね。
顔を合わせることでクリエイティビティのコミュニケーションコストを最小限にしようと考えていたので、これまでリモートワークはNGでした。家庭の事情などがある場合はもちろん許容していましたが、そうでなければ基本的には会社に来てもらっていましたね。現在もコロナの状況に応じてメンバーの安全を第一に考えながらリモートにするかどうかを判断していて、ここ1ヶ月はリモート推奨で出社も可能ということにしています。
SlackとZoomがあればリモートでもプロジェクト自体は進行できるのですが、やはり新人のオンボーディングや会社に対する社員のロイヤリティが低下する懸念があります。そこでメンバーにお願いしているのが毎日朝会をやることと、始業と就業時はSlackに報告してもらうことです。あとはHRや経営陣で毎週相談して、できるだけ雑談を生むような施策を行っています。
また、新しくチームに入った人とはある程度のタイミングで顔を合わせないと怖い部分があるので、そのあたりはチームの気持ちに委ねて自主的に出社してもらうようにしています。
生内：水上さんはいかがでしょうか。
水上：僕は最初からリモートベースでチームを作ろうとしているので、できるだけマネジメントコストがかからないよう、メンバーには自立していてほしいと思っています。
そのためにはチームの方針をしっかり固めて、何が正しいのかという基準をより細かく作る必要があります。また、どういう状態になれば給与アップできるのか評価を明確にし、さらにどこを目指して成長してくのかというスキルツリーの大枠も設定しています。
生内：ShowTalkさんはPMを含めて5名のチームということでしたが、その規模感だと行動指針などもみんなで話し合って決めるのでしょうか？
水上：一度僕が作り、違和感が無いかを確認する感じです。リファラル採用で僕の思考を知っている人が入社しているということもあり、阿吽の呼吸とまでは言いませんがスムーズに決まっています。
上層レイヤーほどキャリアステップの設定が難しい
生内：ベースとしてエンジニアという職種は成長したい意欲が高い人が多いので、僕はその意欲をどう刺激するのか、成長しやすい環境をどう作るのかという点に気を使っています。
具体的には、今後何をどのようにできるようになっていきたいのかイメージを持ってもらうようにしていて、1on1を通して事業の状態とも擦り合わせながら個人のキャリアステップをアレンジしています。これはコロナ禍でもあまりやり方は変わりませんね。
小林：うちも同じような感じです。一つ質問なのですが、シニアエンジニアやテックリードといった役職はどういうときに与えますか？
生内：フロントエンドのテックリードといったように、技術分野的に細分化しています。バッジ集めのような感覚を意識していますね。技術を深堀りしていったときの称号をどうするのかは各社の思想が出そうですが、僕はGoogleの評価制度にある「フェロー」が好きです。
藤川：うちは先日プリンシパルテックリードという役職を置きました。テクニカルな部分に特化した肩書きなので、テックリードには違いないんですけどね。
また、サービスリードを置くかどうかでずっと悩んでいます。いわゆるサービス系のエンジニアのキャリアパスです。テックリードと何が違うのかということになりそうですが、テックリードは基盤技術やテクノロジー自体に興味がある人で、サービスリードはUXやプロダクトマネージャー的な技術ディレクションを担う人というイメージです。
あと、うちは今VPoEがいないんですよね。僕はもともとCTOで、現在は役員としてVPoE的なアクションを取ってはいるのですが、一方で開発チームのディビジョンマネージャーでもあります。僕の上司としてVPoEを置くのかという問題が出てきてしまうので、組織構造の調整が不可欠で上のレイヤーの役職が一番難しいです。
生内：役割をどうアレンジするかという話になってきますしね。
藤川：仮にVPoE候補の方を採用したら、最初にどういう風にステップアップしていくかの設計も必要です。上位のレイヤーほど周囲からの信頼を前提としますしね。
そういう意味ではプリンシパルテックリードになった人は最初エンジニアとして入社したのですが、1ヶ月で周りが「この人をリードにしてほしい」と言い出したので、期待通りでした。
生内：周りがそういう提言をしてくれるというのは非常にいいですね。
エンジニアに長く続けてもらうためには会社の成長が重要
生内：育成の観点で、採用した人にいてもらう期間について何か考えはありますか？自分の会社で仕事をしてもらうことの意味に賞味期限はあるのか、それともどんどん更新されていくのかといったようなことですが。
小林：10年後もいようと思える会社でなければいけないと思っています。社員との1on1でよく言っているのが、「あなたが今から10年後も在籍してくれてたら僕はVPoEの役割を果たせている」ということです。10年同じ会社にいるには本当にその会社が好きでなければいけませんし、報酬などの所属する理由も成長できる環境も必要です。10年以内に辞める理由が信頼関係の崩壊や喧嘩別れの「家出」では寂しいのではやめに話をさせてほしいし、もっと上を目指したいといった「卒業」なら僕たちの力不足なので、寂しいけど応援して送り出すと伝えています。
生内：このあたりのテーマについて、水上さんはいかがですか？
水上：基本的にエンジニアは5年で辞めるくらいの気持ちでいます（笑）もちろん事業が成長し続けられるならずっと続けてほしいと思っています。事業を成長させる中で、技術だったり組織だったり色々な経験が出来ると思います。
なので、一緒に事業を成長させていきながら、個人スキルも一緒に成長していけたらいいなと考えています。ほかのメンバーたちも同じだと嬉しいです。
生内：エンジニアといえど事業を成長させるために来ていますからね。僕はマクアケに入社したからには、クリ上イーター職の生きる力の源ともいうべきデザインや技術力、価値を伝える力など、その人それぞれが考えるチカラを身に着けてもらいたいと思っています。
その上で、ずっと一緒に働いてもらうなり、そういった力の成長につながるような目的が会社や事業の中になくなってしまった場合は小林さんの言葉を借りるなら卒業ということになるのがいいなと思います。
イベント応募時に頂いてた参加者からの質問に回答
※本イベント開催にあたり、多数の質問が寄せられました。積極的にリファラルしてもらう秘訣は「自分が責任を取る」こと
質問者：スタートアップ企業の初期のエンジニア採用はどうしましたか？（エンジニアのつながりがあまり無いので、リファラルを見込めない前提で）
生内：水上さんのところはリファラル採用をされているそうですが、リファラルが尽きたらどうしますか？
水上：ShowTalkがエンジニアにとって良い会社だと思ってもらうことが前段階としてあるとは思うのですが、リファラル採用した人からさらにつながっていくことで、リファラル採用でやり続けられるのではないかと思います。非エンジニアの方で全くエンジニアの知り合いがいなかったとしたら、それこそFLEXYを利用するのがいいということなのかもしれません。
藤川：メンバーがリファラルに慣れてないこともあると思いますが、その点はいかがでしょうか。
水上：もともと友人が多くて、イベントを開催したら誰かを連れてきてくれるような人を最初に集めているというのは大きいかもしれません。
小林：僕は「紹介した人とされた人同士の人間関係は絶対壊さないし、採用の責任は僕が取るから紹介してくれ」と話します。合否判断や人間関係に影響しないようにリファラルしてくれた人は採用フローからも外します。
生内：リファラルでない方法としては、エージェントが紹介してくれるサービスはいろいろあると思うのですが、どういうコンセプトで人を集めているのかはきちんと擦り合わせたほうがいいですね。教えてくれる人材の情報そのものが自社に向いていないと、合わない人を多く見ることになってしまいますから。
お互いの期待値がズレてしまうとリカバリーは難しい
質問者：エンジニア採用の成功談と失敗談を聞きたいです。
藤川：失敗談で言うと、期待値が合わなかったことがたまにありますね。我々はレガシーなコードをどんどん新しいものに変えながらシステムを運用しているのですが、そのために「もっとスピーディーに開発できると思っていた」という理由で辞められてしまうことがあります。そういう期待値が合わないと申し訳ないです。
生内：期待値がズレてしまったときのリカバリーの方法はあるのでしょうか？
藤川：そもそもズレていることに気が付かないといけないんですよね。辞めると言われてからではもう遅いので、その前にいかに期待値に関する話ができるかです。オンボーディングに近いタイミングではなかなか難しいので、そこはエンジニアリングマネージャーに委ねて見逃さないようにするしかありません。
生内：そういう意味ではやはりエンジニアリングマネージャーは必要ですよね。
藤川：最近はすごく重要性を感じています。
小林：給与と実際の貢献度の期待値のズレは表面化しづらいけど課題になりますよね。活躍できるように支援したり、時間をかけて補正するしかないのですが、そこはよく課題になるかなと思います。
