グルーとしてのエンジニアリングマネージャー
はじめに
これはQiitaのEngineering Manager Advent Calendar 24日目の投稿です。
エンジニアリングマネージャー（EM）の役割
EMというロールの定義は組織によって異なりますが、共通項としては「チームのパフォーマンスを最大化すること」があります。
チームのパフォーマンスを最大化するためには様々な打ち手が考えられます。
チームのイネーブルメント
チームメンバーの採用、育成、評価の実施
キャリア形成支援
パフォーマンス・マネジメント
ロードマップに沿ったスケジューリング、チーム内の体制最適化
技術的リーダーシップ
技術的意思決定への参加
技術的課題の解決への貢献
コミュニケーション
コミュニケーションパスの設計
チームのAPIとしての機能
プロセス改善
予算管理
チームの規模や会社のフェーズ、そこにいる人々の特性によってとるべき打ち手は異なってきます。
私が今所属している会社では、チームのイネーブルメント、パフォーマンス・マネージメント、コミュニケーション、プロセス管理がメインのフォーカスです。私が現在進行系でどのようにEM業と向き合っているかはこちらのブログにまとめているので、よかったらご覧ください。
EMにとって信頼貯金は生命線
EM（というか◯◯マネージャーというラベルが貼られている人）にとって信頼貯金は生命線です。チームのパフォーマンスを最大化するためにはタフなコミュニケーションが必要になる場面や、ドラスティックな意思決定を下し大きな舵取りをする場面。そういったときに、信頼のおける関係性であるかどうかが成否を分けていきます。
EMというロールが所属する組織における公式の役職である場合、ある程度の権限を有しているためポジションパワーを活用して人に動いてもらうことも可能ではあります。でも人が主体的に動いていくには、ポジションパワーではなくパーソナルパワーにより能動的に信頼を得て、その信頼に基づき行動してもらう必要があります。
信頼を集め、「あの人がいうならやってみよう」「あの人に相談してみよう」と思ってもらえる関係性を多くの人と作る。ある種のGuru（導師）的側面がEMにはあります。
信頼はいかにして作られるか
では、その信頼はどのように集めるのか。EMとして求められるファンクション、「チームのパフォーマンスを最大化する」を愚直に実践していくしかありません。
糊になる
組織とメンバーをくっつける
チームメンバーが評価されるのは、所属する組織が向かう方向と合致したアウトカムを獲得したときです。いくら優秀でも組織が期待する成果とは真逆のベクトルでアウトプットを出しているのであれば評価されませんし、まだ発展途上のエンジニアであっても組織の目標達成に寄与することができたなら、それは評価に値します。
優秀だけどなかなか組織の方向とマッチングできず評価されづらいエンジニアがいたとします。そのエンジニアを正しく方向づけし、本来勝ち得るべき評価を勝ち得ることができたとしたら、それは会社にとってもエンジニアにとってもうれしいことです。
OKRなどをうまく活用しこのアラインメントを行う糊としての作用は、信頼を得るための有効な手段の一つです。
チームメンバー同士をくっつける
チームがパフォーマンスを発揮するためには、それぞれの持ち味を活かしながら同じ方向を向いていくことが望ましいでしょう。適切なチームビルディング、コミュニケーション設計、役割分担を行うことでハイパフォーマンスなチームをつくることができます。
また、チーム内において異なるロール間の期待をマッチングさせることもエンジニアリングマネージャーの大切な仕事のひとつです。
プロダクトオーナー/プロダクトマネージャーの期待。デザイナーの期待。
それぞれが普段使っている言葉、話し方の相互の翻訳。
「相互の翻訳」について少し掘り下げます。書籍「リフレクション」ではメタ認知を手助けするフレームワーク「認知の4点セット」が紹介されています。認知の4点セットでは、事実や経験に対する判断や意見を次の4つに分類します。
意見 あなたの意見
経験 その意見をもつ背景にある経験
感情 その経験が紐づく感情
価値観 意見、経験、感情からみえてくる大切にしている価値観
同じ物事、状況に対して持つ感情や意見は人によって異なります。
たとえば慎重なエンジニアは、スプリントに対してコミットメントするときに「うまくいかなかったらこうなる」というリスクをリストアップしてくるでしょう。
たとえば「目標達成を強く信じていれば必ず達成できる」という成功体験を積んできたビジネスパーソンは、必ずうまくいくのだから、わざわざ「こうなったらうまくいかない」というリスクをリストアップしたことなどなかったりします。
このエンジニアにとっては予めリスクを挙げておき対処可能にするための行動だったりするのですが、このビジネスパーソンからすると「間に合わないってこと？」という不安を喚起させるものだったりします。
EMとしては、それぞれの価値観から意見の差分が出ることを理解しておき、このときにリスクは確かに存在すること、ただ必ず起きるわけでなく予めリストアップすることで迅速な対処を可能としていること、なのでおそらく達成はできるはずだと考えていることなどを解説し、不安を取り除いていきます。
この不安を放置すると過剰な進捗報告が求められる→エンジニア側から不信感が生まれる→なぜ報告を嫌がるのか、と不信感が生まれる・・・というループになる可能性があるので、しっかり対処してチームをくっつけていくことが大切です。
このように様々なアプローチからチームをくっつけて、「チームがいい方向に変わった」とメンバーが感じることができたなら、またそこに信頼が産まれていることでしょう。
チームとチームの外をくっつける
適度に疎な関係を保ちながら、自身を基本のインターフェースとしてチーム内外のコミュニケーションを行うことは役割分担による効率化とコラボレーションの活性化を両立させます。
チームの業務に集中しながらも、チームの外側にも眼差しを向け働きかけていく。そんな動き方ができたなら、もはや信頼はあなた個人だけではなくチーム全体が勝ち取ったものになっていきます。
では、他チームとの接点はどのように持つのが適切なのか。チーム外とのインタラクションには様々な形があります。チームトポロジーのインタラクションモードがわかりやすいのでそれをもとに考えてみます。
多くのチームはX as a Serviceの関係にあります。コラボレーションはほぼなく、そのチームが提供しているものを利用するときに接点がある程度。
このとき、接点をもつ頻度が高まっていたり、接点をもつタイミングで問い合わせが頻繁に発生しているようであれば、X as a Serviceからコラボレーションモード/ファシリテーションモードへの移行を検討します。
自分たちが提供しているものを利用するためのスキルを身に着けたいチーム相手であればファシリテーションモードに、どうやら提供しているものをベースに新しい価値を創出したいようであればコラボレーションモードに、といった具合に転換していきます。
この転換を素早く行うためには、チームに対してどのような問い合わせが発生しているかを観察しておくとよいでしょう。また、チーム外で決定された戦略や取り巻くビジネス環境なども、インタラクションモードの転換に影響を及ぼします。こういったチーム外の状況にアンテナを貼っておくことも、グルーであるEMにとっては重要な仕事です。
GlueになってGuruになる
このように様々な断面で「Glue」として働きかけることで信頼関係が築かれ、だんだんと「Guru」のようなEMになっていきます。
周囲をふりまわすような独善的なGuruにはなってほしくありませんが、良き相談相手となりよき意思決定者となるGuruはEMとして目指す価値のある地点だと、私は考えています。
この記事が気に入ったらサポートをしてみませんか？