コアメンバーの連続退職、エンジニア組織崩壊の危機から、退職ゼロ・人員倍増に至るまでの話
2023年の4月から、プロダクト開発チームのEMを務めている岩谷です。本記事では、当時プロダクトエンジニア13人中3人の退職が重なる中々しびれる状況から、エンゲージメントや開発品質の改善に向き合い、怒涛の半年間が過ぎ、現在21人の組織になるまでに取り組んできたことや学びについてご紹介できればと思います。
事業背景
2023年3月以前、以下のような組織体制で、私はML Engineering / MLOpsを推進する基盤チームのEMを勤めておりました。
プロダクト開発チームは、いわゆるマトリクス組織で、３つの職能横断のフィーチャーチームを構成し１つのAnewsというプロダクトを開発していました。エンジニアは全体でEMが1名、チームごとにエンジニアのリーダーがおり、開発の運用方法は全て各チームに委ねられている状態でした。
そんな中、EM1名、リーダー１名、エンジニア1名が新しいチャレンジの場を求める形で、3~4月の間に退職が重なってしまいました。退職理由は、全員と深く話せたわけではありませんが、例えば社員ではなく個人として社会で自律していきたいなど、真剣に自身に合った生き方やキャリアを考えて下した結論でした。私としては一定仕方の無いことと捉えていましたが、事象だけを見るとネガティブに捉えられる可能性もあり、残されたメンバーは役割の穴埋めだけでなく、精神的な部分のフォローアップも重要であったと思います。
私は過去にAnewsの開発チームでチームリーダー・テックリードを担っていた時期もあり、マネジメント職の中では、メンバー・システムの両面で解像度を最も高く持っていたため、プロダクト開発チームのEMを兼務し本イシューに取り組むことになりました。
これまではプレイングマネージャーとしての仕事がメインであり、チームから一歩離れた立場で開発チームに関わっていくというのは初めての経験だったため、本当にできるのか不安はありました。ただ、客観的に見ても自身が適任者だと思い使命感を感じていたことと、自身のキャリアを広げるチャンスとも捉えており、当時はポジティブな気持ちで走り出していたと思います。
やったこと
責務・課題の把握
責務・課題の把握を進めるにあたり、まず、コアとなる役割が抜けたことから、主要なステークホルダから複数の視点での情報を得て、責務の棚卸しが必要があると考えました。加え、人間関係的な問題や精神的にネガティブな空気が無いかも確認するために、各チームリーダーおよびPdMと1on1を行うことにしました。
責務について、幸いなことにフィーチャーチーム内の運用は安定しており、基本的な開発〜保守は自律的に進められる状態になっており、EMとしては主に以下のような業務を行っていたことがわかりました。
- ピープルマネジメント（全メンバーの目標設定・育成・評価・1on1）
- 採用（ペルソナ策定、スカウト、面談、面接、オファー）
- コスト管理（クラウド、各種開発ツール）
- 情シス系の業務（ISMS対応／セキュリティ管理）
課題については、特に多く挙がったのが品質に関わる事項でした。
- 有識者の不足による考慮漏れの多発
- 10人中、4人が元々別プロダクトのメンバー、3人が1年以内の入社者、1人がSREであり、ソフトウェアエンジニアの中でプロダクト把握度の高いメンバー（いわゆる「有識者」）が2人だけになっていた。
- 中規模以上の改善施策の停滞
- 品質向上につながる改善施策について、20%の稼働を充てるという大方針はあったものの、実態としては新規開発の隙間で各メンバーの判断で実施する、という形をとっており、長期化しそうな中規模以上の施策や、チームを跨ぐような課題に中々手がつけられていない状況であった。
逆に、1on1の中でわかった良い点もありました。実はこの３ヶ月程前に、企画と開発を分離した体制から、フィーチャーチーム体制への変更を行なっていたのですが、企画の進めやすさ、コミュニケーションパスのシンプル化等の理由でPdM、エンジニアともにポジティブな意見が多く、かつチーム内の人間関係も良好であった点は不幸中の幸いでした。
3チームから暫定的に2チームへ
まず最初に決めたのは、チームを２チームに減らすことです。リーダーが退職したことはもちろんありますが、全体としてAnewsの経験が浅く、ドメイン知識や技術力の底上げをするためにも相互サポートがしやすいようチームを分散させすぎない方が良いと考えました。
改善施策の期初計画化
停滞していた中規模以上の改善施策については、「やっていいのかわからない」というPdM・他チームへの遠慮のようなものが感じられたため、やって良いのか迷わず計画的に進められるよう、半期ごとの期初計画に入れることにしました。誤解のないように補足しますが、PdMのメンバーは皆エンジニアリングに対して理解があり、改善施策にも協力的でした。それでも、「自由にやって良いよ」だけでは動きづらい現実があったのです。
期初計画とは言いましたが、なるべく自律性を重視したかったため、課題感とアイデア自体は各チームでリストアップしてもらい、マージした後自分とリーダーで話し合って優先度付けをしました。
決定した施策については、担当チームを決めて、リーダーがチームに持ち帰り各個人の目標まで落とし込んでいきました。
成長・育成目標の策定
有識者の減少という問題に対処するために、ドメイン知識も含めたスキルマップを作成しました。シンプルなもので、フロントエンド、バックエンド、バッチ処理、モバイルアプリの４つに対し、開発できない、開発はできる、影響まで考慮して設計・レビューできるの３段階にわけました。
考慮漏れを減らすには「影響まで考慮して設計・レビューできる」人の存在が重要であるため、特に開発量が多いフロントエンド、バックエンドに絞って、各チームに１人以上はそういった人が配置できるようにすることを全体の目標とした上で、これも個人目標まで落とし込んでいきました。
ピープルマネジメントのリーダーへの委譲
元々EMが全員の目標設定、1on1、評価を行っていましたが、退職が続き不安感のある中で、兼務かつしばらくチームを離れていた自分が全てを行うことに懸念がありました。
そんな中、タイムリーにもCo-VPoEであるiwashiさんがモデレーターを務めるイベントで、「エンジニアリングマネージャーのしごと」の著者でもある吉羽さんが、目標設定は土台であり、運用が大事である旨を話されており、日々メンバーの仕事を見ているリーダーに運用に入ってもらうべきと言う考えが強くなりました。
しかし、目標設定・評価の経験がないリーダーもいたため、いきなり完全に任せるのではなく、伴走する形を取ることにしました。
具体的には、目標設定および最終評価には自分も参加し等級ごとに適切な目標ラインの目線合わせを行うこと、自分とリーダーの間で高頻度でメンバーの目標進捗について共有してもらい、課題に対する対応策の検討や、目標自体の見直しなどを話し合うようにすることで、委譲を進められる地盤を整えていきました。
採用の委譲、役割整理
また、採用においても、一部委譲を進めました。元々EMが全てを行ってたカジュアル面談は、リーダーと分担して実施することにしました。カジュアル面談では、相互理解を深めること、マッチングの可能性を探ることが主目的と考えており、例えばエンジニア経験が短く、技術的な幅や深さを広めていきたいと考えられているような方の場合、現場開発に入っていない自分よりチームリーダーと対話してもらったほうがより手触り感のある話ができると考え、候補者様の書面情報から適切な面談者をアサインする形式にしました。
また、候補者様に魅力を感じていただくことも重要で、プロダクトに関するお客様の成功事例等を集めて関係者で話し合い解像度を上げる活動を行い、皆が自信を持って話せるようにしていきました。
カジュアル面談でリーダーの負荷が高まる懸念に対し、元々リーダー２人で実施していた１次面接を、１人で実施できるようにし、時間的負荷の軽減を行いました。リーダー２人はそれぞれフロントエンドとサーバサイドに強みが分かれていたので、候補者様に合わせて適切な面接者をアサインする形です。このように、役割ややり方を常に見直しながら運用を現体制にアジャストしていきました。
学び
良かったこと
人員面については、元々入社の決まっていた2人、新たに採用の決まった5人、基盤チームの統合による4人（自分含む）が加わり、退職も出ていないため10人から21人の組織となりました。
もちろん、人が増えれば良い・退職が出なければ良いというものではありませんし、まだ期間が短いので問題が顕在化していない可能性もありますが、悪い流れで退職が続いていき組織崩壊、という最悪のシナリオは避けられたのかなと思っています。
定性的な面では、改善が進められない、考慮漏れが多いといったエンジニアの不安の声がほとんど出なくなりました。様々な要因はあると思いますが、1on1でエンジニアのメンバーと話す中で、「これをやった方が良さそうなんだけど影響範囲広くて・・・次の期初計画で提案します！」と言われた時は本当に嬉しくて、ああこれか、と思いました。決して全ての課題が無くなったわけではありませんが、課題があっても自分達で変えていけば良い、変えられるという手応えが得られたというのが１番大きかったのではないかと思います。
今振り返ると、元の状態は、プロダクトの新規開発とシステム品質の担保という責務に対し、十分な権限の執行の仕方が明示されていなかったとも取れます。主体的に期初計画を立てるというプロセスを入れたことにより、責務と権限のバランスが取れ、より自分事として自律的に動ける状態になり、「不安を言う」というアクションから「不安な事項に対して具体アクションを起こす」という変容が起きたのかもしれません。
課題
様々な事を行いましたが、特にリーダーにはチーム開発の運用に加え様々な役割も持ってもらい、結果としてもついてきていたため自分としては十分に高い評価を行ったつもりでしたが、最終評価の際に少しギャップが生じるということが起こりました。
距離が近くなるほど、まあ大丈夫だろう、わざわざそこまで話さなくても、という感覚で十分な期待値すり合わせが期中にできていませんでした。色々なことに追われていたため甘えが出ていたのだと思います。どんな関係性であっても基本に忠実にやるべきことはやらなければならないと痛感しました。
また、育成計画で有識者を増やす事を掲げていましたが、退職したEMやリーダーのように何年もいたメンバーと同等レベルの有識者を半年で育成するのはさすがに無理がありました。
一方で、知見を高める手段として行ったドキュメンテーションなどを通じて、組織として知見を溜めていく動きが活発化していったことで、中期的によりロバストな組織になっていくための足がかりができ、むしろ良かったのかもしれません。メンバーと1on1等で話す中では不安の声を聞くことが無くなっているため、良い方向に向かっている感覚を組織として持ててきているのだと思っています。
このように当初計画とは違う形で進んだ状況を振り返り、特に人や組織が関わってくると、計画の蓋然性は低くなるものだと思うので、あまりMECEに考えすぎず、失敗する前提で並列に施策を進めるのも１つのやり方だと思いました。エンジニアリング組織論への招待の中で「経験主義と仮説思考」として不確実な問題に対する向き合い方が取り扱われていますが、１つ体感できたケースだったと思います。
今後の取り組み
これまでは顕在化した課題に対する対処的な施策が主でしたが、今後は成長可能性を高める潜在的なイシューに取り組んでいきたいと考えています。具体的には以下のような取り組みを始めているところです。
- 生成AI領域での価値創造を加速するために、専門チームを立ち上げ、３チーム体制を復活させました。
- よりプロダクト価値を生む組織を目指して、プロダクト戦略の解像度を高める活動、フィーチャーチーム内の共創の進め方の見直し等、探索的に取り組んでいます。
- 採用力や成長力を高めるために、外部発信等の活動を強化していきたいと考え、テックブログ執筆や外部登壇等、少しづつですが活動を増やしています。
- 成長指針づくりがしやすい環境を目指し、等級制度を改定したいと考えています。
最後に
様々な取り組みを記載してきましたが、前提として良いプロダクトを作っていきたい、良い開発組織になっていきたいという思いを持ったメンバーが集まってくれていることに大きく支えられてきていると実感しています。
まだまだ学ぶべきことも多く、伸び代だらけの組織ですが、一緒にプロダクトと組織を成長させていただける方をまだまだ募集していますのでカジュアル面談からお気軽にご連絡ください。
