エンジニアリングマネージャーガイドライン
マネジメントという役割に向き合う上で、日頃から何度も関わるメンバーに言っている (気がする)ことや大事にしていることを本や記事で参考にした観点も交えてまとめていきます。エンジニアリングマネージャーの立場として書いていますが、ほとんどがエンジニアに限定しない内容だと思います。
継続的にアップデートしていく (かもしれない)！
マネジメントの仕事4分類
マネジメントの仕事は状況によってどこに特に注力すべきかは変わるが、大きくは以下の4点である。
情報収集
メール、未読チャット、1on1、雑談など
自分の意思決定の土台になる情報の収集
意思決定
マネージャーが持つ大きな権限の1つ
細心の注意を払い、結果に責任を持つ (メンバーに任せるのも実行責任)
採用、アサイン、設計など重要な意思決定
ナッジング (意思決定などを後押しすること)
議論などに対して自分の観点を提供して、意思決定に影響を与える
自分の考えを共有する
自チームの取り組みを紹介し、他チームに提案する
1on1で次の仕事の取り組み方をアドバイスする
ロールモデル
リーダーとして組織が求めている人物像を体現する、まわりに行動で示していく
自分がまずカンファレンスに登壇して、メンバーの登壇へのチャレンジを支援するなど
マネージャーとしてのアウトプット方程式
まずマネージャーとして出すべきアウトプット・成果の考え方について。
マネージャーのアウトプット = 自分のチームのアウトプット + 自分が影響を与えた他チームのアウトプット
ポイントとしては
担当するチームや組織のアウトプットに対して最終責任を持つ
チームのアウトプットはマネージャー個人のアウトプットよりも重要
よって、自分のタスクをこなすより、権限移譲、メンタリング、コーチングなどに時間を使うべき、となる場合が多い
他チームにも良い影響を与えるのが重要
ロールモデルになる
ナッジング (後押し)
なるべく影響範囲を広げて、アウトプットの総量を最大化することが重要
1on1
1on1はよく本に書いてあるような「部下のための時間」としてではなく、組織の成果を最大化するための時間と捉える。
闇雲に傾聴やコーチングなどの小手先の技術を取り入れるのではなく、相手や状況に応じてアプローチを変える。
雑談
情報共有 (自分から・相手から)
相談 (自分から)
議論
ヒアリング
ティーチング
フィードバック
コンサルティング
コーチング
...
ここで注意事項として、「相手から相談してもらう」ということをこちらから意図的に行わないこと。
これを意図的にやってしまうと、メンバーに対して別に相談したいことがない状態で「何か相談しなければ、、」と考えさせることになり、本来気になっていなかったことまで気になり始めてしまう。もちろんメンバーから相談されることがあれば相談に乗る。
1on1は組織成果の最大化に向けて、
メンバーの掲げるストレッチ目標の達成支援 (目標設定については後述)
上司である自分とメンバーの持つ前提条件や情報の同期
のために行うものと捉えると良さそう。
メンバーの目標設定と振り返り
目標設定
メンバーの目標設定の考え方について。思想はOKRをベースにしているつもりだが、あまり形にこだわってはいない。
まずマネージャーとして、
組織の成果を最大化すること
メンバーに成長してもらうこと (メンバーに役割を拡げてもらうこと)
そのためにメンバーを支援すること
を別々に考えたくないし、何かを切り捨てたくもない。
これは
https://note.com/nishiba/n/nf2f32b83ea2d
の内容にとても影響を受けている。
そこで、以下のような捉え方をしていく。
メンバーにストレッチ目標を立ててもらう
メンバーが自身でその目標の意義を語れるようなものにすること
ストレッチ目標達成のためには従来のやり方では突破できなかったり、スキルが不足している状況に陥る
その結果、メンバーの目指す成果の水準、そのための行動が変化しなければならない
その状況を突破するための支援をし、目標を達成してもらうことがマネージャーの役割として重要になる
メンバーの日々の行動が変化しているかを共に確認していく、変化するための観点を提供していく
これによって全てが繋がる構造が作れるので、「メンバーにストレッチ目標を設定してもらうこと」でマネージャーがやるべきことが結果的にシンプルになる。達成可能な目標を立てて達成を繰り返すような動きは、できることで飯を食っているだけで、一向にそのメンバーの成長につながらない。それでは結果的に組織からの出力の総量も圧倒的には増加しない。
私はメンバーに目標設定をしてもらう上で、「役割を広げる」というふわっとしたテーマをより考えやすくするために
自身が責任を持てる時間軸の長さ
自身の影響力・影響範囲
の2軸からなる領域の面積を大きくしていくイメージを持ってもらうことを推奨している。
影響力は
個人で完結するJobを完遂できる
後輩メンバーのサポートをしながら、個人のJobも完遂できる
チームに対して、自分の意見を述べ、メンバーのその後の行動に影響を与えることができる
チームをリードし、チームの成果に責任を持つことができる
複数チームに対して、横断的に影響力を発揮し、各メンバーのその後の行動に影響を与えることができる
...
時間軸は
1日程度で完結するようなJobを完遂できる
1週間程度で完結するようなJobを完遂できる
1ヶ月程度で完結するようなJobを完遂できる
数ヶ月程度で完結するようなJobを完遂できる
半年後、1年後のプロダクトロードマップ・事業計画に対して、行動計画を定め、その成果と実行に責任を持つことができる
...
のようなイメージである。責任を持てる時間軸を伸ばすことが自身の影響力に寄与するし、影響力を発揮するからこそ、より長い時間軸のミッションを期待されるようになっていく。
メンバー自身のまわりの先輩メンバーなどを参考に、今より1段上の自分が扱うべき時間軸の長さ、影響範囲をイメージしてもらいながら、
「何をどうやって達成するか」
といった問いに答えるような形で目標を設定してもらう。
その際、特に水準を明確にすることが重要で、例えば「ただ10kmを完走すればいいのか」、「10kmを1時間以内に走り切るのか」、によって取るべき行動計画が変わってくる。高水準の目標を設定し、その達成に向けて実行強度高くやり切ってもらうことが重要である。
(目標に対する) 振り返り
メンバーとの(目標に対する) 振り返りについて。
例えば月次で振り返りを実施する場合、以下のような形を取ることが多い。
目標に対して、次の1ヶ月で注力するテーマを設定してもらう
振り返り期間内での自身が出した成果結果と実行結果について、それぞれ晴れ・雨・曇り / 100点満点評価、などで自己評価してもらう
その理由や内訳を振り返ってもらい、メンバー自身の変化を一緒に解釈していく
振り返りは箇条書きではなく、文章で言語化することを推奨
将来のメンバー自身、他人とで解釈がズレやすいため
後述のようなフィードバックをベースにネクストアクションを立ててもらう
あるあるな注意点としては、ただの進捗共有みたいな振り返りにしないこと (目標が達成可能なチェックリストを埋めるような、そもそもストレッチではないものになってしまっているケースが多い)。
「メンバーにとって良い変化、行動変容が生まれているか」を相互に確認することが振り返りの目的なので、「xxのリリース完了しました」みたいな成果共有は事実としては受け止めつつ、その内訳 (メンバーがそこにどう寄与し、どういう行動、解釈の変化が生まれたか）が重要である。
そういった意味でも評価を正しくつけてもらうことが重要で、メンバーが達成可能な目標にチャレンジして、達成した場合、一見100点のように見えるが、「すでにできることを行い、成果を出した」とも言える。それはメンバーの役割の広がりの観点で見ると、100点とは言えないだろう。
権限委譲
権限委譲の考え方について。
いきなり説明責任 (結果責任)は委譲できない (自分が担うべき責任）ので、実行責任からメンバーに委譲していく。
委譲には段階がある。
委譲なし (自分でやる)
自分がやり方を示す
相手が行い、自分がガイドする
相手が行い、自分が頻繁にチェックする
相手が行い、自分が時々チェックする
終わったら相手が知らせてくる
完全な委譲 (相手がやる)
委譲すると一口に言ってもどの水準の委譲をしているのか、どのタイミングで委譲水準を変えるのか、を常に意識することが重要。
その他気をつけていること
メンバーの視座を上げるための問い
https://note.com/nishiba/n/n26dc026f7d0e
がとても参考になったので、日々意識している。
「上司として私にしてほしいことはありますか？」とメンバーに問いを投げかけることで視座が上がるきっかけを作ることができる。
この質問をすると何故かメンバーの視座が上がる。メンバーから「組織内でこういうことが起きているので解決してほしい」とリクエストを受けることにつながり、そのリクエスト自体、メンバーが組織全体に対して考えた結果であることが多い。
さらにメンバーの期待通りに動くために「それを上司である私にどのように解決してほしいですか？」と深堀りをしていく。そうするとメンバーが「あ、何か自分で出来るような気がしてきました。やってみます。」となるケースも多い。
メンバーにしてはいけない問い
メンバーの視座を上げる問いの逆で、「大丈夫ですか？」、「いけますか？」みたいな問いは「大丈夫です。」、「いけます」と答えてしまうのが人間なので、基本的にアンチパターンだと思っている。
「何か私にできることはありますか？」
「何か気になっていることはありますか？」
「ネクストアクションは見えていますか？」
など、相手がリクエストや不明点を正確にこちらに伝えやすい問いを立てることが重要である。
フィードバックについて
フィードバックとは「メンバーの成果創出や成長にとって役立つ情報を伝えること」と定義する。
その上でフィードバックには
ポジティブフィードバック
承認する
相手の行動や変化について伝えること
チェンジフィードバック
内省支援
相手に「なぜその行動をしたのか」を考えてもらう
がある。
ポジティブフィードバックは承認すること、相手の行動や変化について伝えること。チェンジフィードバックはメンバーの内省支援であり、相手に「なぜその行動をしたのか」を考えてもらうこと。
チェンジフィードバックは
事実のすり合わせ
事実を確認する
意味のすり合わせ
事実について、自分はどう思っているか・相手はどう思っているかをすり合わせる
その他ステークホルダーの立場に立った時、どんな意味を持つか
「xxさんだったらどう思うか？」、「xxの立場で見たらどう思うか？」、「xxに対してリスペクトがある行動か？」
その行動は自分にとって得だと思うか？損だと思うか？
期待のすり合わせ
「xxにこうなってほしいんだけど、」と期待を伝える
意図が伝わったか、納得感を持ってくれているかを確認する
行動のすり合わせ
アクションプランを設定してもらう
上司として自分が支援できそうなことを確認する
で進めていく。
フィードバックをする際のアンガーマネジメント
以前どこかで怒りという感情は自分の「べき」という信念から生まれるという話を読んだ記憶がある。
例えば
自分は「レスはなるべく早く返すべき」だと思って徹底しているので、レスが遅い・レスを疎かにする人間に怒りを覚える
自分は「不満がある時は自分なりに改善アクションを取るべき」だと思って徹底しているので、ただ不満や愚痴だけを言っている人間に怒りを覚える
などである。
メンバーが良くない振る舞いをしている場合、本来は前述のようなチェンジフィードバックをしていくべきだが、ここで自分の「べき」という信念が邪魔をし、怒りに任せたフィードバックになってしまうことがある。
怒りに任せたフィードバックは「改善してほしい、内省してほしい内容そのもの」よりも「怒られたという体験やそれに伴う負の感情」のほうが記憶に残りやすいので、むしろ逆効果になる。
この特性を理解した上で、冷静さを欠くことなく、チェンジフィードバックが行えるよう注意することが重要である。
参考
この記事が気に入ったらサポートをしてみませんか？