スタートアップで1人目EMが生まれた理由・生まれてからやっていること

これは何？

この記事はEngineering Manager Advent Calendar 2023 17日目の記事です。
僕がCloudbase株式会社にジョインしてからEMのロールをなぜ持ち始めたのか、そしてEMがスタートアップにもたらした効果と今後の展望について記述しています。
EMというロールは各社で様々な解釈があり、その責任範囲は多くのバリエーションがあるかと思います。
今回は、より特定の課題にフォーカスしてEMのロールを設置した事例について紹介することで、組織、特にスタートアップにおいてEMを置く意義について整理できたら嬉しいです。

対象読者

この記事は以下のような方を対象読者としています。もちろん、他の方に読んでいただけるのも、コメントを頂けるもの歓迎です。

• 現在EMのポジションを担っており、他社のEMの取り組みに興味がある方
• スタートアップでEMをまだ配置しておらず、EMがもたらす価値に興味がある方
• スタートアップの組織作りに興味がある方

筆者プロフィール

成瀬 真
Cloudbase株式会社 エンジニアリングマネージャ・ソフトウェアエンジニア
【略歴】
京都大学工学部情報学科卒業後、大学院在学中に複数社のインターンを経て株式会社メルカリに新卒入社。グループ共通の通知基盤の改善に取り組む。2023年8月にCloudbase株式会社へとジョイン。現在はバックエンドのセキュリティスキャン開発を行いつつ、エンジニア組織の仕組み作りを進めている。副業ではスポチュニティ株式会社のCTOとして、スポーツ業界へのクラウドファンディングを支援するシステムを開発している。
【リンク】
カヌー界をたった一人でDX！？メルカリ出身凄腕エンジニアがCloudbaseで実現すること
https://note.com/cloudbase/n/n939dfb1fddad

初めにお伝えしておきたいこと

ここで述べるEMはポジションではなくロールの話として前提を置かせてください。そのため、EMとは何か？その人の責任範囲は何か？という議論とは一致しない可能性が高いです。
僕は現在100%EMという人として行動しているのではなく、今もソフトウェアエンジニアに主軸を置きつつ20〜50%をEMロールに割いています。その中で得られたインサイトを今回お伝えできれば嬉しいです。
大前提、今回の話はすべて組織全体の長期的なアウトプット・アウトカムを上げるのが目的です。EM業が組織に対してどんな貢献をできるのかを語っていきます。

スタートアップにEMが生まれるまで

ここの章では僕がジョインしてからEMロールを一部担うと宣言するまでの過程をご紹介します。

ジョイン当初

僕が5人目としてCloudbaseにジョインしたのは2022年8月です。
ソフトウェアエンジニアポジションはCTO含め3人しかいない時代でした。
この時代は誰もがオラオラと開発しまくり、やりたいことをなんでもやってコミットしまくることで全てが成立していた時代でした。
全社としても6人で、コミュニケーションの組み合わせは6C2で15通りしかありません。
話したい時に、話したい人と、全てを話すことできました。

1年でエンジニアが3倍まで増加

プロダクト組織はそこから急成長します。
2023年6月までの間にソフトウェアエンジニアやPdMが6人ジョインし、デザイナーも合わせるとプロダクト組織だけでも10人になりました。
この規模では1チームでコミュニケーションを取るのは難しく、明確な境界を引いたチーム分割を行いました。
チーム分割の方法や課題感については他のメンバーが発信しているのでCloudbaseの他のメンバーの登壇資料などを参照いただければ幸いです。
全社としても15人ほど、コミュニケーションの組み合わせは100通りを突破してもはや話したい人と話したい時には話せなくなってきます。
特に経営レイヤーの仲間とは普段の仕事で話すことは少なくなり、情報を仕入れるのがAll Handsというケースも少なくありません。
だからこそ、All Hands等で発信される情報の重要性が増してきました。

発生した出来事と感じた課題

ある時、社内でのちょっとした出来事がきっかけで今の組織の問題点を全員で話し合う機会がありました。
その際は根本の課題感やNext Actionを明確に導き出すことはできませんでした。
しかしながら、個人的に強く課題と感じて行動しようと決意しようと思った事柄が2つあり、このタイミングでEMロールをやろうという決意が固まりました。
その課題2つは以下の通りです。

課題1. 暗黙的に形成されていた期待値

1つ目の課題は暗黙的に形成されていた期待値です。
Cloudbaseのプロダクト組織は途中までリファラルのみで採用をしており、とても仲良しな集団でした。
これは良い意味でお互いを理解しているメンバーが多く、前職で一緒だった経験も多いので上手く仕事が回っているように思われました。
しかしそれには2つ問題があると当時の僕は考えます。

• 1つ目はBさんがAさんに思う期待値と、CさんがAさんに思う期待値が乖離するケースがあったことです。お互いを理解しているようで、全体としてみた時に認識が揃っていないケースがありました。
• 2つ目は新しいメンバーが入ってきた時に、暗黙知で形成されている期待値を理解できないことです。仕事を進める上で、各メンバーがどんな期待値やミッションを持って行動しているかを理解するのは非常に重要です。その人の行動原理を理解しないことには上手くコラボレーションをすることはできません。既存のメンバーはそれを暗黙的にできていましたが、新しいメンバーがそれをできるとは限らない状況でした。

課題2. 単方向通信な全社発信

2つ目の課題は単方向通信な状態になっていた全社発信です。
先述のように、CTOや経営レイヤーとコンスタントに話せる機会が減ってきており、話を伝えられる場所がAll Handsのみになり情報の伝達重要性が増していました。
しかし、話し合いの中で全体発信の内容に対しての認識が個々人で大きく異なっていたことが判明します。
これを揃えないことには、全体として同じ方向に進んでいけないと当時の僕は考え、この課題についても解決に動き出します。
後にEMゆるミートアップに参加した際、全体発信の内容が行き渡らなくなった時がミドルマネージャーを置き始める1つの意思決定ポイントだよというお言葉をいただき、この意思決定の確信度をより高めることができました。

EMとしてやってきたこと

そうした課題を解決するために、僕は2023年8月からEMロールを持ち始めます。
先述の通り、ソフトウェアエンジニアに主軸を置きつつ20〜30%程度をEM業に使うと合意を取り、動き始めました。
ここに書かれているやってきたことは、良く言われるEMの4要素の中ではPeople Managementのみを対象をしています。成瀬の個人全体としては他のマネジメント要素を組み合わせて行動しているケースもありますが、ここではPeople ManagementにフォーカスしてEMロールを定義していることを留意してください

個々人の期待値の作成

やってきたこと1つ目は個々人の期待値の作成です。
Self Job Description(以下Self JD)という名付けをして、1on1を通して1人1人に対して作成を行いました。
前提として、スタートアップなのでそれぞれのメンバーがやっていることは非常に幅広いです。
一方で、その人が何が得意で、何が好きで、何が自分の使命だと感じているかを言語化しておくことはその人の行動原理を理解することでとても重要です。
そうして作成したSelf JDをもとに自分自身の期待値を作成して、その大枠についてエンジニア組織で共有を行いました。
共有会では一定のエモさを醸し出しつつ、ここは任せろ！ここは背中を預ける！という認識を既存のメンバー同士でも少しは持てたかなと感じています。

CTOや経営レイヤーとの定常的な1on1

2種類ある1on1ワークの1つ目はCTOや経営レイヤーとの1on1です。
やっていることは以下の2つです。

reporting

1個目はReportingです。
弊社は役割としてCTOがメンバーと高頻度で1on1を行う体制をとっていないので、ここで報告を行います。
このReportingではセクションをinfoとescalationに分けています。
infoはメンバーと話していること、メンバーがやっていることをサマってsyncするのが目的であり、経営レイヤーにアクションを求めることはありません。
escalationは組織として経営レイヤーが動くことでより効果的であるとEMが判断できるものです。これに対しては経営レイヤーにアクションを促したり、組織課題として扱い議論を進める判断をします。
この2つに分けることで、悪戯に肥大化すべきでない課題を肥大化させないという意識を強く持つことができます。

sync

syncではEMやCTO、CEO、PdMで全体発信の内容を改めて確認します。
ここで強く意識すべきことは、ここで情報の非対称性を担保してはいけないということです。
この場で初めて知らされる全体発信内容はあってならず、特定の個人の話を除いてEMのみぞ知る秘密の話をしてはいけません。
全体発信をメンバーとsyncするため、発信内容の1対1での確認や背景の補足を聞くことを目的とします。

メンバーとの定常的な1on1

メンバーとの1on1は高頻度を意識しており、週次30分からスタートしました。
今後、人によって頻度や所要時間・内容は変化する可能性はありますが、やっていることは以下の通りです。

全体発信内容の確認

直近のAll Handsの内容について2人で読みながら確認していきます。
その中で、メンバーが認識できていなかったことはsyncします。
発信内容で明確に足りないものがあればescalation候補に含め、足りないと感じるメンバーが複数いる場合には　発信者へとescalationを行います。

雑談・お悩み相談

この部分はメンバーによって差分がかなり大きい部分ではありますが、目的としては個人のレイヤーで課題を解決することです。個人のスコープで解決できない、明確に組織課題として扱うべき悩みがあればescalationを行います。

1人目EMがスタートアップにもたらしたと考えられるもの

前章までの行動をしてきた結果、現在までで判明しているEMの組織効果についてこの章では言語化を行います。
大分すると想定していた効果と想定外の効果がありました。
想定外の効果は嬉しいサプライズであり、EMのE意義を補強するものとして語れるものが少し増えたかなと感じております。

想定していた効果

期待値が言語化された

これは当たり前ですね、期待値を言語化したので期待値が言語化されました。
今のメンバー同士でどれくらい効いてくるかはまだ時間軸的に十分に検証できていませんが、今後検証を強めて行きたいと思っております。
また、新規メンバーについては明確に効果があると感じており、今後のオンボーディングで活用をしていきます。
一方で、期待値ワークにかける時間やどれほど期待値を公開するかについてはまだ議論の余地が大きいです。今後もブラッシュアップしていければと考えております。

全体発信の内容がsyncされており、会社として向かう方向性と個人のアラインが取れつつある

発信内容について、1on1で十分なくらいsyncすることで全体として同じ方向に向かう認識が強まってきております。
しかしながら、この部分についてはまだまだ課題があります。
発信内容について十分にsyncしきれておらず認識がズレてしまうという事件は今も起こっており、syncの手法や頻度については改善の余地があります。
また、どうしても1on1の時間に毎回発信内容の確認を行ってしまうとマネージャーからのアジェンダが増えてしまいメンバーの満足度が下がってしまう問題もあります。
更に、全体発信の内容・手法に関してもまだまだ改善の余地はあると思われ、様々な側面からも組織は今後より良くしていく必要性は強いです。
自分達はまだまだ強くなれると信じて、今後も精進していきます！

想定外の効果

コミュニケーションパスから外れたコミュニケーションの補強

1つ目の想定外の効果はコミュニケーションパスから外れたコミュニケーションの補強です。
チームに分けてレポートラインなどの情報の流れを作ってコミュニケーションを取ってプロジェクトを進めていますが、やはりそれから漏れてしまうコミュニケーションを0にすることはできません。
ミドルマネージャがそれを補強することで円滑に進む事案がいくつか発生し、一定の貢献ができたと判断することができました。
現在はEMの責務にProject Managementは含めていませんが、こういった意味ではEMがPjMを包括して担うことにも一定の恩恵があるのではないかと考えています。

個人のレイヤーで課題を解決することの重要さ

2つ目が個人のレイヤーで課題を解決することの重要さです。
個人のレイヤーで解決することで、全ての物事がエスカレーションされるのを防ぐことができると感じています。
スタートアップにとって1分1秒の時間は非常に重要で、全体の課題として扱って議論に時間を使うのではなく、ミドルマネージャーとメンバーで解決できるものは解決することで全体の議論を真に組織課題として扱うべきものにフォーカスすることができます。
特に、メンバーが増えると全員が情理的に合意できる事項は限りなく少なくなり、disagree and commitが求められる場面は増加します。
そういった課題をEMとメンバーで一定の解決をすることで、組織として真に向かうべき方向に進むことができるでしょう。

今後の展望

最後に、2024年以降の今後の展望について記して結びとします。
ここには個人としての抱負も含まれており、必ずしも実現されないものや後に読み返したら全然違った結果になっている可能性もあることをご留意ください。
直近では個人の目標設計について考えています。
個人の期待値を作成した結果、その期待値やチームの目標設計にアラインした個人目標を立てることで一定の効果があると考えられるためです。これについては改めてブログを書くかもしれません。
更に時間軸を伸ばすと、いずれは評価も始まり、ミドルマネージャーの負担は増加すると想定されます。
だからこそ、真に必要なものを見極めてそれのみにマネジメントの時間を使いたいと考えています。
EM業をフレームワーク化して、誰でも挑戦でき、スモールチーム毎にEMを置ける環境をCloudbaseで作っていくとここで宣言します。

宣伝

Cloudbaseではソフトウェアエンジニアやエンジニアリングマネージャー(候補)を全力採用中です！
少しでも興味がある方は下のページからの応募やXでのDMをお気軽にお願いいたします。
https://herp.careers/v1/cloudbase
https://twitter.com/marimo_manta