この記事は「Engineering Manager Advent Calendar 2022」に参加しています
24日目の記事です。
昨日は @rinchsan さんによる 「【前編】SWEからVPoEになってからの1年 〜リソース効率からフロー効率へ〜」 でした。
おれやで！（原西）
20名のエンジニア組織でVPoEになり1年が経ちました
株式会社SODA でVPoE兼エンジニアリングマネージャーをしている @rinchsan です。
2年ほど前の2020年10月よりソフトウェアエンジニア（SWE）としてSODAへ入社しました。
そのタイミングではマネジメントの知識は皆無で、マネージャーは「いい感じに1on1と言って話を聞いてくれるおじさん」としか思っていませんでした。
そんな僕ですが、今年2022年の1月よりVPoE兼エンジニアリングマネージャーに転向し、1年ほどが経過しました。
SODAは現在20名ほどのエンジニア組織で、プロダクトマネージャーやデザイナーと協力しながら「SNKRDUNK（スニーカーダンク）」というプロダクトを開発しています。
ここ1年の取り組みをご紹介します
SODAで直近1年ほどで取り組んできたことをご紹介します。
今回ご紹介する取り組みは、すべてにおいて僕1人で進めたものではなく、ありがたいことにプロダクト開発チームの皆さん（エンジニア、PdM、デザイナー、などなど）が積極的に協力してくれたからこそ進んだものばかりです。
圧倒的感謝。
感謝するぜ お前らと出会えた これまでの全てに!!!
前編からご覧ください
前編を読んでいない方は是非そちらからご覧ください。
でも実は特に強く結びついている部分はないので、後編だけ読んでも大丈夫な気もします。
新入社員のオンボーディングも結局詳しい人に聞いちゃう属人化
新しくジョインしてくれたエンジニアのオンボーディングも特に型が決まっていませんでした。
そのため、不明点があった場合、古くから開発組織に所属するエンジニアやCTOに最終的に質問が集中してしまい、開発Tipsのようなものが組織に広がりづらくなってしまう属人化が発生していました。
オンボーディングを標準化してチーム内でオンボを進められるように
ドキュメントツールとして使っているNotionの中に、新しくジョインしたエンジニアごとに「オンボーディングカンバン」を作成し、オンボーディングに必要なタスクを可視化できるようにしました。
オンボーディングを進めていくにあたって必要なタスク一覧の明確化と、どこまでキャッチアップが進んでいるかの可視化ができました。
これによってオンボーディングのサポートが誰でも出来る体制（に近づけていける体制）になりました。
そして、オンボタスクを進めていくにあたっての必要な情報ももちろん同じ場所で管理され、改善が必要ならNotionを直接編集できる、という状態を作ることで継続的に改善される体制も整備できました。
今月ジョインしたエンジニアのオンボーディングカンバン
エンジニア採用に関する意思決定基準が明確化されておらず個人へ属人化
エンジニア採用におけるオファー可否などの意思決定はなんとなくCTOやVPoEが最終決定をしており、これは特に課題ではありませんでした。
ただ、オファー判断前の数回の採用面談における候補者の採用基準が明確化されておらず、誰が面談を担当するかによって基準がバラバラで一貫性のある採用があまり出来ていませんでした。
これは誰か1人に属人化するというよりも、採用に関わってくれているエンジニアそれぞれ個人への属人化というイメージです。
ちなみにですが、弊社SODAはエンジニア全員（ジョインしたばかりの人を除く）が採用面談に参加してくれており、ワンチームで採用していくというのは自然と出来ている組織でした。感謝。
採用まわりの話はこちらのインタビュー記事でもしていますので是非ご覧ください（宣伝）。
採用要件を改めて言語化して採用面談を進めやすく
採用したいエンジニア像はどのようなものか、採用面談へ参加してくれているエンジニア陣を集めてブレスト形式で議論しました。
そして、カルチャーマッチとスキルマッチの2つの観点からどういうエンジニアと一緒に働きたいかを言語化しました。
これによってある程度自社にマッチしたエンジニアかどうかの判断が標準化されました。
改めてキックオフされたWebエンジニア採用チーム
採用面談の半構造化で改善していける状態を作る
採用したいエンジニア像を言語化するだけではやはり細かい部分で判断の差は出てしまいます。
そこで、Googleが提唱する「構造化面接」を参考に「半構造化面談」を整備しました。
カルチャーマッチとスキルマッチそれぞれの領域において、一緒に働きたいエンジニア像とはつまりはどのようなスキルや志向性を持っている人かを考えました。
いくつか洗い出した項目それぞれにおいて、候補者の過去の経験や今の考え方などを出来るだけ引き出すことが出来る質問集のようなものを作りました。
それぞれの質問において「相手の返答によってどのように展開していくと話を広げやすいか」はある程度考えて定義しましたが、基本的には面談担当者の裁量で話を展開していける部分は残したため、「半構造化」と呼んでいます。
ただ、そこが結構難しいポイントで差も出てしまうところなので、もっとレベルを上げて標準化していくことが今後の課題です。
半構造化面談フォーマットの一部。開発プロセスに関する話題の例
【宣伝】EMが2人になりチームへ
今年2022年の8月より社内でソフトウェアエンジニアをしていたメンバーが「エンジニアリングマネジメントに興味がある」と手を挙げてくれてEMチームは2名体制になりました。
しかしエンジニア組織は年明けに25名ほどになる予定で、さらにEMのパワーを増やさねば健全な開発組織作りが難しくなってくると想定しています。
今後はScaling Agileの導入やデザイン組織作りなどにも注力します
サービス特性上、ソフトウェアエンジニアのパワーが持つビジネスインパクトは非常に大きいため、今後も引き続きエンジニア採用へ注力し続けます。
エンジニアの数がどんどん増えても1人あたりの開発生産性を下げることなく、むしろプロダクト開発のアジリティを上げていきたいと考えています。
「LeSS」や「Scrum@Scale」のようなScaling Agileフレームワークの導入や、デザイン組織のプロダクト開発プロセスへの適切な巻き込み[1]なども今後の大きな課題です。
LeanとDevOpsの科学 で言及されているような、人数が増えてもデプロイ頻度が単調増加していくハイパフォーマーなチームになっていきたいです。
ハイパフォーマーなチームは開発者数が増えてもデプロイ頻度が増加していく図（出典：LeanとDevOpsの科学）
Engineering Managers Wanted !!!
このようなエンジニアリングマネジメント領域の取り組みに少しでも興味のあるEM志望の方がおりましたら、是非お話ししましょう！！
-
デザイン組織の巻き込みに関する課題は こちらのインタビュー記事 でも言及しています。 ↩︎
株式会社SODAの開発組織がお届けするZenn Publicationです。 是非Entrance Bookもご覧ください！ → recruit.soda-inc.jp/engineer
Discussion