ARFES

私は、「エンジニアリングマネージャーお悩み相談室」という本を読みました。

この本は、悩みを抱えるエンジニアリングマネージャーからお便りが寄せられてくるという形式で、17個の悩みとそれに対するアクションやアドバイスについて書かれています。

目標の立て方や自律的なチームの作り方といったチーム内部のことから、そのチームの成果を周囲に認めてもらえるような働きかけといったチーム外部との関わり方。また自身のキャリアの進め方に至るまで、EMとして働いていく上での幅広い悩み事について書かれており、将来的にEMとしてのキャリアを目指している自分にとってとても参考になる内容でした。

私はこの本を読んで、EMに求められている要素の１つは「GraphQLになること」なのではないかと感じました。
そう思った要素は２つあるのですが、１つ目は「様々な人の間に入るインターフェースになる必要がある」ということです。

この本ではピープルマネジメントに関連する内容として「翻訳」という単語が何度か登場します。それは一般的な「他の自然言語へ言い換える」という意味ではなく、「異なる立場の人間が理解し合うためにお互いが分かる言葉に変換する」といった意味です。

異なる立場と一口に言っても、「チーム内のエンジニア同士」であったり、「開発と営業」であったり、「上司と部下」であったりと非常に様々です。
そしてそれぞれの立場や視点が異なることによって、思わぬ不和ややすれ違いが発生し組織のパフォーマンスが無駄に低下しまう事があります。

「双方に悪意が無かったとしても、コミュニケーション不足によってお互いを『悪意のある人間』と評してしまう」「チームの成果を上手く他チームや上司に理解してもらえない」

こういったコミュニケーションが原因となって発生する組織の問題を解消するために、EMが間に入り、お互いが理解できる言葉に翻訳し、組織が円滑に回る様に動くのが責務の一つであると理解しました。

例えば、営業側にリファクタリングの重要性を伝えるために工数とリターンを見積もって定量的に伝えてみたり、チームの成果を周囲に認めてもらうために日々のメンバーの活動を定期的に外部にも発信していくなどの行動を取って相互理解を深めていくことが重要だと感じました。

EMに求められている要素の１つが「GraphQLになること」だと思った２つ目の理由は「スキーマを公開するかの様に、自分にできることを周囲に示す必要がある」と感じたからです。

今回この本を読んで一番印象的だったのですが、「EMとしての自分には何ができて何ができないのか」を示すことというのは、考えている以上に大事な要素なんだと気付かされました。

当たり前ですが、それぞれのメンバーの出来ることには限りがあります。知っている知識、積んできた経験、現在のタスク量は短期間で変えることができませんし、それによって出来ることの多さや幅は無限ではありません。

その限界を越えることは非常に困難ですし、時間や労力を多大に消費する可能性が高いです。

しかしそこで自分の外部からその足りない何かを補える要素を取得することができれば、より困難なタスクに対処できる様になるかもしれません。その様な意味でEMはできる事、出来ないことを周囲に示すことが求められていると思いました。

例えば、「この技術に関しては困っていたらヘルプに入ることができる」「自分には出来ないけれどそれに詳しい人を紹介したりできる」などと言った項目(=エンドポイント)をGraphQLスキーマの様に周囲に示しておけば、EMを通して組織の能力を拡張することができます。

これは単にチームのステータスが上がるというだけに留まらず、周囲の組織に対する安心感を向上させることもできるのではないかと思います。
「この人に頼ればこれに関しては何とかなる」と思えていればストレッチなタスクにも挑戦しやすくなりますし、「チームのためにこれをやりたいけど、自分1人ではやり切れない」と思っているメンバーのアクションの後押しにもなるため、組織にとって非常に重要な行動だと感じました。

この様に誰かと誰かを繋ぎ、自身にできることを周囲に発信することで、組織の成果を少しずつ大きくしていけるのではないかと思いました。

また読みたいです。

---

https://www.shoeisha.co.jp/book/detail/9784798189840

https://note.com/ar_tama/n/n4cbfc63bc3b8

著者のあらたまさん