見出し画像

とあるEMの回顧録

しんくう

この記事はEngineering Manager Advent Calendar 2023(シリーズ2)  3日目の記事です。だいぶ過ぎてますが、空いていたので入れました。


現在はEMという職にいないが、過去1年ほどEMだったときに考えていたことを備忘録として書き出しておく。

前提としての当時求められた内容

当初EMを拝命されたときに求められたことは以下のようなことだった。

  • 4つのプロダクトに対してそれぞれ対応する形で開発チームがあり、各チームの支援

    • リーダー不在のチームに関しては一部チームのリーディング機能も代替していた。

  • それぞれのチームに点在する正社員メンバのピープルマネジメント

  • チームの大きな技術的な意思決定のサポート、また各プロダクト同士が連携するような技術的な意思決定

  • 事業方針に準じたメンバアサインの検討

EMをやりながら意識していたこと

当時意識していた事を書き出すと以下のようなことがあった。

自分のやることを整理し、人にお願いすることを意識する

EMを拝命してすぐにやらなければいけないタスクで溢れた。そのため定番ではあったがやらなければいけないことを緊急度と重要度の四象限に分けつつ、その中でも可及的速やかに手を打たないといけないことに関して対応するということを心がけてきた。（なお、序盤で緊急度の読み違えで大きな不可逆の失態を犯したのでそれ以降は急ぎ手当をするということは非常に意識するようになった）

また、4つのチームの現状を事細かに拾い上げるのは無理なので、週1の1on1で状況把握につとめ、困りごとを拾い上げて策を一緒に考えることに努めた。また各チームにいわゆるプロダクト企画を考えるメンバーがいたので、そちらからの要望なども拾い上げながら各チームがよい方向に進むように動いた。

4つのチームの状態は様々で、拝命当初は「課題はあるが自立して動くことができるもの」から「リーダーが不在でほぼ進んでいないから本当に危険な状態」というものまで様々だったので、4つのチームを束ねる事業責任者と相談しながらどれからトリアージをしていくべきかという合意を取りながら進めていった。

全部に関して全力投球はできないので、「今すぐ対応しないとクリティカル」というものから拾い上げて、瀕死の状況のものはそれ以上ダメージを負わないように踏ん張ってもらう、のようなことを進めてなんとか動いていった。

ROI

事業部と開発組織が密接に絡む組織構造であったので、費用対効果というのは強く意識した。特に新規の開発におけるアーキテクチャの意思決定の場で「コスト」は強く意識した。具体的には以下のような内容で頭を悩ませた。

  • 内製開発をするよりSaaSを使うほうがイニシャル開発コスト、運用コストを比較したときにどうか？

  • AWSの使い方で一番ローコストで運用が楽な組み方はどのような組み方か

  • イニシャルコストと運用コストのバランスが良い作りはどれか

1on1の喋りやすさを保ち、相手のことを中心に考える

EM拝命時にもともと関係性がしっかりあったメンバもいれば、全然いないメンバもいた。そのため、1on1は以下のことを意識した。

  • 原則、1on1で喋ったことは墓まで持っていく。もし他の人に言う場合は当人の許可を得てから喋る。

  • 相手の困りごとを中心に話す。

  • EMに対してネガティブフィードバックがあれば手心なく伝えてほしいと伝えた。

  • 相手の給料が最大化する方法を常に意識して話す。

    • 給料があがる = 個人の能力と会社のめざすべきところがマッチしている状態 と捉えて、その人がどうすれば一番活躍できるかを考えた。

事業的に目指すところをなるべくエンジニアメンバーにも伝える

これもありきたりの話ではあったが、メンバー全員の目線を合わせるということはかなり意識して行った。

特にEM拝命時は4つのプロダクトのシナジー効果を考えて大きくしていこうと構えていたフェーズだったので、一つ一つの行動がゴールにつながるようにしないと、どんどんズレていってしまうおそれがあったので、極力事業の目指す状況がどうであるかというところを伝えるのに努めた。

やってきた中で教訓となったこと

EMをやってきたなかでいくつか印象に残ったフレーズがあるので書き留める

拾いやすいタスクを拾うのではなく、真に重要なタスクを拾う

自分自身が落ちているボールを拾いがちなタイプなので、そのボールを拾いすぎて自滅していたことがあったときに、ちゃんと重要度を意識してものごとにかかれと言われたことがあった。

これは自分自身の行動にも問題があったが、社歴が長いために「とりあえず聞いてみよう」というタイプの質問も受けてしまい、タスクとして作業をすることが多かったので、意図的に拾わない、別の人に渡すというところを強く意識して動いた。

どうしても人は感謝されるとその行動をしてしまうが、感謝される行動がその組織の状態において一番すべき行動かというとそうでもないタイミングもあるので、気をつけなばいけないと感じた。

期限を切る

当たり前の話だが、重要度も緊急度も高いタスクが並ぶと自然とすべて「なるはや」になってしまうので、それを防ぐ意味でも一旦期限を切る。上から順にこなすとしても少なからず決められた期間でやれそうなことを宣言する。

振り返るとスプリント内でやれることをスプリントバックログに乗せる感覚と同じで、急ぎではあるが一定のタイムボックスでどこまでやるかを決めるということが大事だったように思える。

内容、状況、相手にあわせてコミュニケーションツールを使い分ける

フルリモートに近い状態であったため、出社すること自体が稀の状況だった。そのためオンラインのコミュニケーションが大事だったのだが、内容・状況・相手の状態によってコミュニケーションスタイルはかなり変えていた。雑に箇条書きをすると以下のようなものがある。

  • コンテキストが複雑な内容を話す場合はインプットする材料が多いので、対話を持ちかける側はある程度文章で整理し、それをもとに同期的な会話で行い、ネクストアクションだけどこかにテキストで書き残して合意形成をする

  • ブロードキャストで連絡することはテキストで周知し、確実に見てほしい人には見た旨のレスを求めるようにテキスト内に盛り込む

  • 障害対応など緊急性を要する話は集まる場（GoogleMeetのURLなど）を用意して、入れる人から入ってもらう

  • アジェンダを持ち寄るタイプの定例ミーティングなどでは事前にアジェンダを書いて、当日10分読み込みと質問事項を書く時間を設けてディスカッションの時間を確保する（Googleドキュメントに事前にアジェンダを書いて、当日はコメントを使って疑問点の整理をしていた）

手助けすることの意義を考えながら動く

「誰かの手助けをするということは誰かの時間を奪っているということ、それでチーム全体のアウトカムが増えている場合はいいが、ただの労働力の横移動をしているだけなら意味がないし、労働力を渡した人(=手伝った人）が疲弊するだけなので、そうなっていないかを気をつけて動け。他人の善意を搾取するな。」という旨の話をされた。

これは見方によっては「親切心でやっていることに対して、そんなうがった解釈をするものではない」というような見解もあるかもしれないが、優しい人が疲弊して倒れていくのはこのパターンであることが多いと私自身も思っているので、無意識に発生する搾取される/搾取することには注意しないといけないと感じた。


当時を思い出しながらつらつらと書いたが、他にももっと多くの学びがあったと思っている。また思い出したら投稿したいと思います。



この記事が気に入ったらサポートをしてみませんか？