少数精鋭のスタートアップがEMを設置するまでの組織の変化
Engineering Manager Advent Calender 2023 8日目です！
株式会社SpecteeでVPoEをしております、おーのAです。
少数精鋭で開発するスタートアップのエンジニア組織が組織拡大に伴ってどのような変化をたどっていったか、私が参画してからの３年間の道程を語っていきます。チーム化やエンジニアリングマネージャーの役割を導入検討しているスタートアップの方々の一助になれば幸いです。
※以降人数の記載がありますが、記憶を頼りに書いているので大体です。PdMやデザイナーなどの人数も含みます。また、インターンは除外しています。
スタートアップの成長の過程
私が参画した頃(2020/10~2021/4頃・フルタイム7~8名)
私がフルスタックエンドエンジニアとして参画したのは2020年10月頃。フルタイムは6名でCTO含めた全員がコードを書いているという状況でした。CTOがリリース機能の優先順位を決定し、それぞれのメンバーがそれぞれ開発している状況でした。
この頃、全社員が参加するVoice Of Customer ミーティング（以下、VOCミーティング）というものがありましたが、エンジニアが要件に関して確認したり、時には意見を言ったり、プロダクトに貢献できている感覚を得られる状況でした。全員でプロダクトを作っている、そんな雰囲気が私はとても好きでした。プロダクトにも今まで無かった地図機能が追加されたり、地図機能に様々なコンテンツが拡充されたりと、日々プロダクトが成長していて、顧客価値を素早く提供できていたと思います。
開発体制としても、各個人で開発しているとはいえ、開発人数も少なく全体が見通せる状況でした。技術に関してもトピックごとに委員会が設置され、メンバー間が自律的に連携しながら開発できていたのではないかと思います。すごく楽しく仕事をできていたと思います。
チーム体制へ【2021/5~2021/12頃・フルタイム8~10名】
この頃から社内向けのツールの改善が始まったため、プロダクト開発と社内ツール開発のチームに分かれました。同時期からVOCミーティングでのエンジニアの発言数が減っていきました。本質的な問題は不明ではあるのですが、全社員数が増えたり、分業が明確になっていったことによるものかも知れません。私の視点ではありますが、この頃から何となくエンジニア組織に閉塞感や、トップダウンに仕事がおりてくる印象、ギスギスした雰囲気も感じるようになりました。みんなが活き活きと働いているとは言えない状況でした。
チーム力強化のため、ふりかえりの実施【2021/12頃・フルタイム10名程度】
私は、自律的に活き活きと働くためには、ボトムアップな活動が必要だと考えました。
そこで、プロダクト開発チームメンバー4名で集まって週次でコーディングルールや、リポジトリ作成のガイドライン作成などに取り組み始めました。そして、その活動についてKPTでふりかえりを実施することを始めました。
しかし、それぞれ個人で開発しているため、各人の興味のズレがあり、議論は発散していくことが多かったです。その結果、時間内で議論をしてTryを決めても、ほとんどのメンバーはTryを実施することがありませんでした。ふりかえりは、1ヶ月程度で断ち切れとなりました。理由は私が諦めて打ち合わせの時間を削除したためです。
言い訳ではありますが、当時私はプロダクト開発の作業を離れ、研究開発の作業に携わっていました。プロダクト開発チームに対して意見を言うだけの存在にならないようにしたかったので、意見を言いにくかったという理由もあります。
この体験から得たことは、このように個人個人で開発しているような環境ではボトムアップな雰囲気を醸成していくのは難しいということです。上司がボトムアップな意見を受け入れるような人柄があったとしても、それは一人の上司と一人のメンバーの意見の合意でしかありません。そうなると、結局組織全体に浸透させることが難しくなります。だからこそ、個人個人の意見が組織全体として尊重されるような仕組みや工夫が無いとボトムアップに意見を言いやすい文化は難しいと私は考えています。
スクラムの導入検討【2021/12〜2022/3・フルタイム10~20名程度】
私はその頃の閉塞感や社内に流れる雰囲気を問題視していました。しかし、このような状況だったにも関わらず、「人が足りない」という理由で採用はどんどん進んでいました。その頃の体制は整っているとはとても言えない状況だったため、人が増えていけば、もっと閉塞感が漂うのではないかと大きな不安を感じていたことを思い出します。
どうしたら、入社当時の状況のように活き活きと働くことができるか。ふと、思いついたことが、過去の職場で取り組んでいたスクラムでした。過去の職場でのスクラムでは、当初7人程度だった組織が20人程度（4チームのLeSS）まで拡大しても皆が活き活きと働いていた感覚がありました。あの感覚で仕事をすれば、入社当時のように活き活きと働けるのではないか、そう思い、当時担当していた研究開発の領域をスクラムチームで開発することをCTOに提案しました。
チーム化を提案した経緯を簡単に書いておきます。
当時の研究開発は他社との協業による実証実験がほとんどで、かつ、プロダクトにつながるような実証実験に取り組めておらず、プロダクト価値を高める研究開発に取り組めておりませんでした。また、実証実験は私が担当している２件以外、ほぼ一人の裁量で進められており、締め切り間近になってから突然作業をプロダクトのエンジニアに依頼しなければいけないといった割り込み作業が発生していました。プロダクト開発への影響を最小限にするためという目的を持ってチーム化を提案しました。
本題に話を戻しますが、当時の開発への影響を最小限にするために今までいる開発者をスクラムにするという手段は取りませんでした。2022/4に2名の新卒採用、2023/5に機械学習エンジニアの1名採用が決まっていたため、彼らに最初からスクラムで業務開始してもらうことにしました。
スクラム導入決定後、私は研究開発バックログを整理、スクラムに参加するメンバーへの説明資料作成などを進め、来たるスクラムの開始へ準備を進めました。
スクラムの開始とチームリーダーの導入【2022/4〜2022/12・フルタイム20名〜30名程度】
会社からすれば、うまくいくか分からないスクラム。いきなりPOをアサインすることも難しいため、私がSM・PO兼任で開始しました。8月までは開発成果やプロセスも含めて私が手厚くサポートをしながらスクラムチームの成長を支援していきました。その成果が認められ、別のチームもスクラムを導入することになりました。結果、私が忙しくなったため、最初のチームには当時、研究開発の実証実験の窓口を担当していた方に声をかけて、POをやってくれないか、相談、快諾してもらいました。その後、私が過去の職場で一緒にスクラムで開発していたメンバーが参画したため、彼と共にもう1チームの立ち上げを実施しました。この期間に3チームのスクラムが立ち上がりました。（スクラムに関しては本記事では本筋ではないのでここで終わりにしたいと思います）
同時期、各開発チームでチームリーダーという役割が導入された時期でもありました（私を含めた4名、うち2名内部昇格、2名採用）。しかし、このリーダーは役割が不明瞭で、それぞれが自分のやり方でチームの活動の一部を担うような役割でした。曖昧な役割であることはそれぞれの仕事の取り組みやすさはあったものの、結果的にチームの状況が見えにくくなり、不透明な組織状態を生み出しました。
リーダーの連携（とエンジニアリングマネージャーの自称）【2023/1〜2023/8・フルタイム30名〜35名程度】
上記のような状況で、組織の透明性を保つためにどうしたら良いかを検討し、既に存在していた1on1の仕組みの再構築を行うことを実施しました。具体的には質問項目を決めてアンケートを取りフィードバックを得るという手段でした。しかし、今考えると、組織の状態を良くしていきたいという抽象度の高いレベルでの方向性は一致していたものの、それに関して具体的なものに落とし込んでいったときに、それぞれのリーダーの思いが一致していなかったのだと思います。1on1とアンケートを取るという取り組みは効果を感じられなかった、また改善に結びつけられなかったため、終了するという判断をしました。
これ以外にもリーダーで定期的に集まり、1on1のふりかえりを含めた様々な取り組みを進めていたものの、やはり業務の役割が異なったり、各リーダーの興味のズレで方向性が定まらず、ふりかえりの取り組みは終了しました。
余談ですが、私個人の話ですが、リーダーという役割をあえて社外では「エンジニアリングマネージャー」と称し、地味に組織にエンジニアリングマネージャーの言葉が浸透するように努めていました。
エンジニアリングマネージャーのロールを作成！【2023/8〜2023/11・フルタイム35名〜40名程度】
リーダーが思うように連携できない中、初のマルチプロダクトとなる開発が昨年から進行していました。先日発表された以下のサービスです。
マルチプロダクトの開発が進む中で、チーム間の連携が必要なものの、十分に連携が取れないという状況に陥っています。さらには、PdMやリーダーの役割も不明瞭であり、ますます曖昧な状況になっていました。明確に役割を定義してこなかった結果、極端に言うと「自分の仕事ではない」と押し付け合うような状況になってしまったと思います。そういった状況を打破するため、PdMやデザイナーを含めて一つの組織であった組織を分割し、プロダクト企画とプロダクト開発に分けることにしました。2023/11に組織の変更とともにそれまでリーダーと呼ばれていた人たちをピープルマネジメントにコミットしてもらうため、エンジニアリングマネージャーというロールを作成しました。イマココ、です。
弊社のエンジニアリングマネージャーのこれから
実はエンジニアリングマネージャーというロールを作ったものの、まだ、明確な役割や業務を定義できていません。作ったはいいけど、まだまだ探索中です。
マネージャーのアウトプット=
自分の組織のアウトプット＋自分の影響力が及ぶ隣接諸組織のアウトプット
みんな大好きHIGH OUTPUT MANAGEMENTからの引用ですが、ここを目指せるような役割にしたいと考えています。今まで「リーダー」と呼ばれる人たちは、あくまで「自分の組織のアウトプット」を高めることにフォーカスしていたと思います。これを隣接諸組織のアウトプットを高めることにも力を入れられるような組織設計を行っていきたいと考えています。
ちなみに、エンジニアリングマネージャーを置いたからといって、活き活きとした組織に変化したかというと、そんなことはありません。
今後、エンジニアリングマネージャーを含めたマネジメント層を中心に組織の透明性を保ち、組織の方向性とメンバーの想いを擦り合わせていき、皆が活き活きと働けるような体制を整え、活き活きとした組織文化を醸成していきます。
（ちなみに、趣旨とは離れてしまいますが、社内で勉強会したり、動画視聴会、LT会などを実施し、メンバー間のつながりが増え、活き活きとした雰囲気は戻りつつあります。）
ところで・・・大事なのはCTOのリーダーシップ
最後に最も重要なことを語らなければいけないと思います。CTOの存在です。彼のリーダーシップが無ければ変化する土壌は作れなかったと思います。彼のことを紹介したいと思います。
人を大切にする
メンバーからの信頼がある
変化を受け入れる
組織の変化をそれぞれのメンバーの思いを大切にしながら受け入れていく、CTOの存在があってこその変化であったと思います。ちなみに弊社エンジニアは会社を嫌って退職した方はいません（別の理由で退職した方はいます）。そういった点でも彼の素晴らしさは伝わるかなと思います。
終わりに・・・
このような組織の変化を楽しみたいテックリードの方を募集しております。ご興味お持ちいただけましたらお声がけいただけたら幸いです。
最後までお読みいただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？