🥾

1人目EMを導入する前に意識して欲しいたった1つのこと

2024/12/25に公開

はじめに

こんにちは!株式会社ispecでEMをしているshinyaです。

私自身、今年の1月から社内1人目のEMとして活動を始めてから、ちょうど丸1年が経ちました。
この記事の投稿は12/25と年末年始ということで、今年の振り返りや来年の目標を立てる時期になってきました。

そこで今回は、この1年でEMロールとして行った業務を振り返りつつ「導入前にもっと意識しておけばよかったなぁ...」と思う部分について書いていきます。

この記事の想定読者

本記事の想定読者はこちらとなっています。

  • 1人目EMを爆誕させようとしているスタートアップの方
  • 初めてEMに取り組むエンジニア
  • EMに取り組んでいるけど、価値を発揮できているか自信がない方

EM導入前に意識しておきたかったこと

それは「目的と目標を混同せず、まず“目的”をきちんと定義したうえで“目標”を設計すること」です。

目的と目標は辞書的には以下のように定義されています。

  • 目的
    • 実現しようとしてめざす事柄
    • 抽象的や理想的であるもの
  • 目標
    • そこに行き着くように、またそこから外れないように目印とするもの
    • 具体的な数字で設定できるとなお良い

もう少しわかりやすいイメージとしては、以下の画像のように「目的を叶えるためのステップとして目標がある」という形になります。


https://minchalle.com/blog/purpose-and-goal

社内1人目のEMを立てるとなった時に陥りやすい罠として「EMの導入によって解決したい課題 = EMの目的と認識してしまうこと」があるのかなと思っています。EMを導入しようと思った時には、きっと何かしらの組織課題を抱えていると思います。

例えば以下のようなものが挙げられるのではないでしょうか。

  • エンジニアの人数が増えてきて、CTOだけでは見切れなくなった
  • 採用・オンボーディングを強化したい
  • チーム内のコミュニケーションを改善させたい

弊社におけるEMの導入背景は、「PdM/CTOが持っているマネジメント業務を軽くすることで、自社事業の構築に充てる時間を増やしたい」というものでした。

私自身、その導入背景に応えるためにPdMが持ってくれていたプロジェクトマネジメントやピープルマネジメントを請け負ったり、CTOが持ってくれていた採用に関するロールを分担したりと、様々な業務を行ってきました。そしてその影響もあってか、自社事業の構想は深まっている状況ではあります。(自社事業の構想についてはCEOが書いたこちらを参照いただけると!)

しかし、"目的=抽象的や理想的であるもの"という定義であるのに対して、この導入背景は”直近発生している課題を解決したい”というものなので、目的とは異なります。どちらかというと目標の方が近そうですね。

目標や解決したい課題を設定するだけでも一定のアウトプットを出すことは可能だと思うのですが、「目的を明確に設定しておけばより動きやすかったかも」と思う瞬間がいくつかあったので、自分自身の経験を踏まえてご紹介します。

目的が曖昧なことによって起こる課題

1. 振り返りやFBの質が下がる

スクラム開発において、スプリントゴールを設定することでデイリースクラムやプランニングなどのイベントの質が上がった、という内容の記事がとても良かったので最近社内にも共有したのですが、本当に「良い振り返りは良い目標設定から」だなと感じます。

https://zenn.dev/innoscouter/articles/d5765faae2871e

ゴールが曖昧だと振り返りの時にも「なんとなく上手くいった!」「ちょっと微妙だったねぇ」といったように、振り返りがただの確認会となって次に繋がらないものとなってしまいます。

特にエンジニアとして働いていた時と比べて、EMの業務では採用やマネジメントなど誰かと働くことが増えたり、不確実性が高くなったりするので、自分の活動がアウトプットに直結しづらくなってきます。そして業務内容の幅も広がるので、結果だけを見てどれだけ自分が影響を与えられたのか、を測るのは困難でした。

なので、”抽象的な目的を達成するために直近で達成する目標”を事前に設定した上で振り返りに望めると、

  • そもそもの目的・目標設定が正しいか
  • 目標を達成するための適切なアクションが取れているか

という多角的な視点から質の高い振り返りを行うことが出来るので、結果として1人目EMでも道を迷わずに進むことが出来るようになると思います。

2. 業務の優先順位がつけづらくなる

EMが持つマネジメントの領域は4つに分けられると言われていますが、組織ごとにEMの責務は大きく変わります。どの領域まで持つかによって、強いEM / 弱いEMという定義もあったりしますね。


https://qiita.com/hirokidaichi/items/95678bb1cef32629c317

この領域のどこまでをEMが持つかは、目的によって大きく変わるかなと思います。そして、目的が明確でないと何をすればいいか分からずあれこれ手を出す状況になったり、逆に1つの領域ばかりに注力してしまったりするのかなと。(特にTechLeadからEMに移行するパターンだと、テクノロジーマネジメントに注力しがちのイメージ)

実際に私も「開発業務を持たないEM」としてPJに入った時に、どこまで & どうやってチームに介入すればいいのかが分からなくなってしまった時期があったのですが、「このPJのEMとして、最終的にどういうチームを作りたいのか」という問いをCTOから1on1で聞いてくれたことがきっかけとなり、4領域のどこに注力してチームに関わるかを決めることができました。いつも助けてくれるCTO(yamadさん)には感謝でいっぱいです...!

3. 中長期的な取り組みが後回しになりがちになる

"目標"だけが決まっている状態で日々のEMとしての業務を行なっていると、どうしても目の前のタスク(リリースや採用、マネジメント上の急務)に集中してしまいがちです。以下の重要度と緊急度のマトリクスで表すと、AとCに対応をしている感じですね。


https://teamhackers.io/what-is-the-importance-and-urgency-matrix/

しかし、EMの責務には以下のような内容にあたる中長期的な組織づくりや技術基盤の強化も入ってくるかなと思います。

  • チームビルディングのための定期的なワークショップや1on1の設計
  • エンジニア自身のやりたいこととキャリアパスを紐づける目標管理の設計
  • ユーザーへの価値を上げるためのスクラム開発フローの見直し

同じく重要度と緊急度のマトリクスで表すと、Bの緊急度は低く重要度が高い箇所になります。


https://teamhackers.io/what-is-the-importance-and-urgency-matrix/

目的・目標が明確になることで、重要度が高い取り組みへの意識づけが出来ると同時に、緊急度の高いタスクをメンバーに委譲することが候補に入りやすくなると思います。

もちろん直近のタスク・プロジェクトを問題なく終えられることも大切なので、緊急度の高いタスクを全て委譲して重要度が高いものに取り組めばいいということではありませんが、緊急度の高いタスクばかりになっていると気づいた時に「中長期的に開発組織の価値を最大化するために、組織全体として今自分は何に取り組むべきだろうか?」と考えられると委譲の判断がつきやすくなるかもしれませんね。(この辺はまだまだ出来ていないところなので、来年から明日から頑張るぞ)

まとめ

これからEMを導入したい/EMを導入してみたけど合っているか分からないという方は「EMを導入することによって叶えたい目的はなんだろう?」と改めて考えてみることで、EM自身のパフォーマンスを最大限発揮し、それに伴った開発組織全体の成長につながると思います。この1年の自分の経験が、これからEMを導入する方や、初めてEMに挑戦する方の参考になれば幸いです!

また、本記事はispec初のアドベントカレンダー企画の最後の記事になりましたが、みなさんのおかげで無事に最後までやり切ることができました。参加してくれた皆さんありがとうございました!そしてお疲れ様でした!🍻

ispecは来年も発信を続けていく予定ですので、今後の発信もどうぞよろしくお願いします。
それでは、良いクリスマス&年末をお過ごしください!

ispec inc.

Discussion