エンジニア採用の状況は地域によって大きく異なる
最近視聴した2つのコンテンツが、同じソフトウェアエンジニア採用の話題を取り扱っているにもかかわらず、その内容が両極端で非常に興味深かった。
ひとつは「エンジニア採用必勝法・これだけでわかるDevRel入門」という動画で、もうひとつは「最近カナダで就職したエンジニアと一緒に北米就活の攻略法を語る」というポッドキャストのエピソードだ。
エンジニア市場と企業の採用戦略は地域や業界によって異なるが、ここで話されている東京と北米（バンクーバー）では顕著な違いが見られる。
東京を中心とする日本ではテック企業間での人材獲得競争が激しく、特にエンジニアが不足しているため、採用広報の役割の重要性が増し、DevRelといった呼び名で施策が実行されている。 一方、カナダでは、永住権を持たない外国人労働者が職を得るハードルが高く、求職者の競争が激しい現状が実際に就職活動をした本人から語られていた。
日本では、DevRelという概念が広がりつつあり、エンジニア採用戦略の一部として注目されている
このエンジニア採用活動をテーマにしたビジネス映像メディアPIVOTの動画は、ビジネス系チャンネルにありがちなサムネイルの印象に反して、落ち着いたトーンで進行している。
サムネイルを見た段階で「ウッ」と拒否反応くる人がいると思うが、実際に見てみると、エンジニアの採用に苦心している各社の話題であることを知って、その後はそれなりに楽しめる。
ちなみに【エンジニア採用必勝法】の結論は出ていないと思う。 やっていこうなぐらいの温度感。
DevRelというPIVOTの視聴者にはなじみがないであろう職種にフォーカスし、会社代表としてDeveloper Relationsのサポート事業を展開する佐藤祥子さんのプレゼンが行われる。
しかし実際にはPIVOTのプロダクトマネジャーである蜂須賀さんも、自分の見解を積極的に共有しており、動画の中で二人の意見が均等に交わる形となっている。
また、左側に座っている男性が誰か分からない視聴者も多いかもしれませんが、彼はPIVOTの代表である佐々木さんで、この動画では生徒のような立場で参加している。
ビジパ視聴者代表として「おいちゃんにも聞かせてよ」みたいなトーンでたまに会話に入り込んでくる。
日本のIT業界の一部では、DevRelという概念が広がりつつあり、その使い方が注目されている。 佐藤さんの前職LINEヤフーもDevRel部署抱える日系テック企業の一つだ。
前編の動画では、米国発祥とされるDevRelの日本での使われ方や違いを解説し、後編でエンジニア採用における企業の典型的な誤解、いわゆるアンチパターンを説明している。
この動画は前後編に分割されており、後編を見るためにはPIVOTアプリのダウンロードが必要と書いてあったが、視聴の料金はかからず、プロフィール登録も必須ではない。 したがって、このコンテンツは広く公開され、誰でもアクセス可能なものとして言及する。
ちなみにウェブ版でも観られる。
事業会社によるエンジニア採用の広報活動におけるDevRelの呼称は、米国における従来型の自社製品技術の利用拡大を目指すDevRelとは異なるニュアンスを持ち始めているというエクスキューズは前半にある。
日本における事例として、941::blogでまとめられているような呼称の正確性と実態の問題意識は私は持たないため、ここでは触れない。
そういえば私が初めてDevRelという言葉に出会ったのはグーグルジャパンのAPI Expertに関連する話題であった。
その時代の関連する文献を探したが、見つかったのは以下のバイオハザードの起きた研究所跡地のような見た目の記事だけであった。
しかし、比較的新しい資料である2019年のTaiji HAGINOさんのスライドが、DevRelの歴史を振り返る上で非常に参考になった。 このスライドは、DevRel/Japanというコミュニティのイベントで発表されたものであり、このコミュニティは海外にルーツがあり2010年代から日本で積極的に活動している。 DevRel/Japanはその発祥に忠実であり、技術広報やエンジニア採用とは異なる文脈で活動している人たちで、DevRelに関する著書を書いたり、コミュニティを運営したりしている*1。
佐藤さんのプレゼンでは自社エンジニアへの内向きなコミュニケーションも、外向けの広報と同様に重要と説明している。 これは実践している現場の人らしい意見だと思った。
この内向きなコミュニケーションが不十分だと、エンジニアの不満や離職が直接的に増加する可能性があるし、エンジニアが自分たちの職場環境に満足していなければ、知人に紹介するリファラル採用も進まなくる。
たとえば、ウォーターサーバーや撤去された、やきそばを焼く業務がある、などの噂が広がるようなこともありうる（架空の話です）。
また、技術ブログの投稿ノルマに追われている開発チームが、タスクの過負荷に苦しむ状況もアンチパターンとして見られると言及されていた。
エンジニアコミュニティとの関係構築が企業の採用力に直接影響を与える
結論として企業は採用活動を行う際に、エンジニアコミュニティを無視できない状況にある。
ソフトウェア技術は日々進化し、そのスピードに対応するためには、エンジニア同士がコミュニティ内で情報交換を行うしかない。
その結果、エンジニアの仕事はOSSや技術ブログなどのコミュニティの成果や知見の共有に大きく依存している。
リファラル採用も、多くはコミュニティ内の評判を基に機能する。
コミュニティでの評判が企業の採用力に直接影響を与えるため、コミュニティとのつながりが企業の成功に重要な役割を果たすようになっている。
大企業の多くが従来型のエンジニア採用戦略で苦戦している
昨今の市場変化に対応するために、大企業もエンジニアを採用する必要性が高まっている。
技術の進化やデジタルトランスフォーメーション（DX）圧によって、企業は迅速な対応を求められているが、エンジニア採用戦略に不慣れな大企業は多くの失敗を繰り返してアンチパターンを踏みまくる。
たとえば、カジュアル面談で志望動機を聞くような行動や、テンプレート化されたスカウティングメールを大量に送る戦術が目立つ。
その結果、多くの企業が他職種での成功体験をもとにした、消費者知名度にもとづく従来型の採用戦略をとり苦戦しているが、そこを改善するのが佐藤さんらのDevRelコンサルの役割である。
一方で、成功事例としてイオンのDX推進のためのエンジニア採用成功例は注目に値すると紹介された。 これは、過去動画のPRでもある。
北米（カナダ）では、エンジニア市場が日本とは異なり、より求職者間での競争が激しい
PIVOTの動画とは対照的に「最近カナダで就職したエンジニアと一緒に北米就活の攻略法を語る」では、カナダでの就活においては、エンジニア市場の状況が日本と異なることが語られた。
このエピソードに出演しているのは日本のスタートアップで5年間エンジニアとして働いた後、カナダのバンクーバーに移住し、現地の会社でエンジニアとして働き始めたYugoさんと、ポッドキャストのホストの一人であるKeiさん。 Keiさんの方が先輩にあたり、彼はバンクーバーから帰国した後に現在は日本で外資企業でエンジニアとして働いているという。
日本では、エンジニアは人手不足の影響で転職市場で優位な立場にあるが、北米ではそうはいかない。
シニアな経験を持ち、多少のOSSコントリビュートがあったとしても、それだけでは差別化が難しいという。
実際、日本と同じ水準で企業から日夜スカウトが来続けるようなアプローチを受けるためには、Node.jsコアコントリビューターなどトップクラスの実績が求められる。
その上で、書類選考に応募した全体の1割程度が通過したというYugoさんの結果は二人の感覚から見てハイアベレージなものであるので、情報収集の方法や、応募のタイミング、自己紹介ビデオの作成、などの攻略法が具体的に紹介された（こっちは結論がある）。
リファラルやコミュニティの重要性は、どのような市場状況でも変わらない
私が興味深かったのは、リファラルやコミュニティの重要性は、どのような市場状況でも変わらないことだった。
採用において、企業は膨大な数の応募者の中から適切な候補者を探し出すという難題に直面してる。
たとえATSでの書類選考が自動化されても、応募者はそれに対してレジュメを最適化し、企業との間でいたちごっこが続く。
結果として、企業は信頼できる人脈を通じて候補者を見つけることが多くなる。 優秀なエンジニアであっても、コールドアプリケーションで採用される確率は低く、人脈を持つことが重要視されるのだ。
転職するならまず人脈。
私は北米事情は知らないから触れないが、リファラル採用は、日本の会社において効果的に運用されていることは間違いない。
私の知り合いの中でも、リファラルによって転職の満足度が高い職を得た人は多い。
特に初期スタートアップでは、ジョブディスクリプションを定義する人材を最初に採用する必要があり、なんかよさげな人紹介してレベルのリファラルが重要な役割を果たしている。
とはいえ、これは特定のコミュニティへの偏りを生む可能性もある。 採用候補者に、より多様な人材を得る機会が制限されることも懸念される面もある。
イベント運営などのコミュニティ活動は重要だが万能ではない
採用広報文脈で重要とされているイベント運営についても同様だ。
エンジニアが集まりわいわいするイベントは、生存者たちによる社交の場であり、適性のある人々が残りがちである。
昨今問題になるのは無銭飲食目的の参加などだが、しかしそういった場所に最初から馴染めない人も多く、参加できていない層もいる。
私もその一人であり、イベント登壇や懇親会、資金提供(!)などの経験はあるものの、コミュニティのインサイダーになれていると思うことは少ない。
かといってテキストサイト世代なのでオンラインでの他者とのコミュニケーションも少ない。
唯一あるのは、このブログのように突如放心状態で関心のあるトピックに12時間かけてテキストを書き、煽りタイトルをつけて発表した結果、知らない人に褒められたり、怒られたり、スルーされたりする刹那的なものである。
とはいえ個人の愚痴を持ち出すまでもなくイベント運用が万能ではないのは関係者もそう思っているだろう。
それでも、エンジニアの採用・求職においては、コミュニティとのつながりが重要であることは間違いない。
日本語話者でエンジニアという恵まれた環境にいることは、私のキャリアにおいて幸運だった。
たまたま、パソコンのさらにウェブのソフトウェアレイヤーが趣味であり、それが収入を生む時期の社会に出現した結果いまに生きている。
もし、別の分野のプログラミングにしか関心を持てなかったら、状況は違っただろう。
中世であれば、王族お気に入りの大衆浴場のアーキテクチャを勝手に改変し、「こちらのがいいのでは？」と失礼な提案をして即座に首をはねられてしまったかもしれない。
少ない人数でプロダクトを開発できる体制を模索する必要がある
しかしエンジニアの供給不足が目立つ現在、需要側をコントロールするための抜本的な手段は求められないのだろうか。
要は開発のための必要な人員が増えすぎているという部分にも注目したい。
ここ10数年スマートフォンが普及してデバイスからの利用も増え、ソフトウェアの要求水準もあがり、一方開発対象のソフトウェアアーキテクチャが複雑化しているため、1つの水準のプロダクト開発に必要な人員の数は年々増加している。
さらに、多様な開発対象が存在することから、フロントエンド、バックエンド、モバイル、プラットフォームなど分業も促進されている。
これらの要因が相まっていることもあり、プロジェクトあたりのエンジニア不足の問題はさらに深刻化させている。 アーキテクチャレベルでの戦略的アプローチも必要なのではないか。
私としては今より少ない人数で1つのプロダクトを開発できる体制を模索したい。
このブログでいつも放心状態で提言されるようなアーキテクチャに関する議論だ。
近年、デスクトップアプリのWeb化、Electron化、モバイルアプリのFlutter化、ゲームエンジンでの開発がこの目的を満たす充分に普及したアプローチとして機能している。
2000年代にRailsブームが起きたときの状況を考えると、主流のサーバーサイドJavaは大量のボイラープレートコードとXML設定ファイルを記述し、コンパイルしてサーバーに適切に配置する手順が多く、目的に対して非効率とDISられがちだった。
一方で、LLはコマンドを打ったらコードが自動化され、生のコードがそのまま動き、サーバーにログインして編集しながらデバッグもできるため、作業時間の短縮が可能になると受け入れられた。
37signalsのような逆張り戦略が、プロダクト開発のヒントになる
これと似たような流れが次の周回でまた起こるのではないか。
今ではRails開発元37signalsはONCEで、ウェブサービスではなくパッケージソフトウェア提供の逆張りを行っており、これは広く見ると、サービス提供の方法論も変化していることを示している。
さらに37signalsは、このパッケージソフトウェアに向け全部入りアーキテクチャを促進しており、フロントエンド構築が概念圧縮され、クラウドリソースのパイプラインを構築するグルーコードとの闘いもコンテナでリノベして切り捨てる姿勢でいる。
このような流れは、少人数で効率的にプロダクトを開発するための大きなヒントになると思う。 小さなチーム、大きな仕事2だ。
