Forkwell Press

SHARE

Event report

「権限移譲できてる?」エンジニアリングマネージャーのしごと 吉羽 龍太郎

エンジニアに役立つ情報を定期的にお届けします。

今回は2022年8月26日出版の最新刊『エンジニアリングマネージャーのしごと』を取り上げます。翻訳者である吉羽 龍太郎 氏は、日本企業、外資系企業でエンジニアリングマネージャーを経験。エンジニアリングマネージャーの基礎やエンジニアリングマネージャーを目指すためのノウハウなどを伺います。

エンジニアリングマネージャーの軸は、ピープルマネージメント

エンジニアリングマネージャーの定義は曖昧ですが、よく言われるのは以下の4領域です。

  1. ピープルマネジメント
  2. テクノロジーマネジメント
  3. プロジェクトマネジメント
  4. プロダクトマネジメント

ピープルマネジメントとは

組織の成熟度によって4領域へ関与する度合いが変わりますが、軸になるのはピープルマネージメントです。ピープルマネージメントは、人事評価の権限を持ち、チームメンバーのマネジメントが職務の中心にある職種のことです。

エンジニアリングマネージャーのよくある悩み

1on1を毎週やりたいけど時間がない

忙しいけどマネージャーとして成果を出せているかわからない

朝からミーティングだらけで仕事が全然進まない

みなさんは、いかがでしょうか。私自身もマネージャー時代は、忙しいのに何かをやり遂げた感覚がない……と常にモヤモヤしていました。このような状態は「稼働率100%の消防車」と同じで、あまり良くありません。火事が発生し出動が必要なのに「いや今、他に行ってます」という状態は危険ですよね。組織内で複数の業務を兼務している場合も、あまり良くない状態です。

まず、時間の無駄を省きキャパシティを確保する

EMのしごと

自分自身の整理整頓ができない人間が、チームを効果的に扱えるはずがありません。自分の記憶に頼らず、必要なときに必要な情報を探せるようにしておきましょう。ポイントは、いつも同じ方法で整理をすることです。ツールを活用しても良いしシステムを構築しても良いでしょう。有名な企業のトップが、いつも同じ服を着ていたり、いつも同じものを食べている状態に近いかも知れませんね。

ツールの使い方のヒント

カレンダーの使い方

  • 時間を管理するためだけに使う
  • 十分な休憩の時間を確保する
  • 自分が集中するための時間を確保する
  • デフォルトで公開する
  • 通知を活用する

マネージャーには考える時間が必要なので、カレンダーにブロック枠を入れておくことがポイントです。

ToDoリスト

  • 自分にあうツールを使う
  • 始業直後、終業直前に確認する
  • 繰り返しのToDoアイテムを活用する
  • リマインドを活用する
  • ToDoリストにないことはやらない

メールボックス

  • メッセージを受け取る1次ソースにする
  • 完了したものはアーカイブする
  • メールは削除しない
  • 読まない定期購読は解除する
  • フィルタールールを活用する

メールを見て、Slackを見て、と往復する時間は本当に無駄です。通知機能を活用して一箇所に集約しましょう。ちなみに本日18時時点での私のメール数は、たった6通です。同僚は1万通ぐらいでした。ガンガンアーカイブして整理しましょう。

情報記録ツール

  • いつでもすぐに記録できるようにする
  • あとでToDoリストなどに入れ替える

マネージャーとしての成果を方程式で表すと

マネージャーとしての成果が何かは色々な考え方がありますが、本書はこのように定義しています。

マネージャーのアウトプット = 

あなたのチームのアウトプット + あなたが影響を与えた他チームのアウトプット

チームのアウトプットに最終的な責任を持つ

アウトプットが少ないなら、多くできるよう改善するのもマネージャーの仕事です。

チームのアウトプットはマネージャー個人のアウトプットより重要

方程式にあるとおり、マネージャーの個人タスクよりもチームパフォーマンスを上げることを優先してください。権限移譲やメンタリング、コーチングなどに時間を使いましょう。

他のチームに良い影響を与える、ロールモデルやナッジングになる

自分のチームを守るばかりで他のチームに悪い影響を与えるとアウトプットの総量は下がるので注意が必要です。

エンジニアリングマネージャーのしごと 4分類

マネージャー業務は多岐に渡りますが、具体的に「この仕事をした!」と言い切ることが難しかったりします。この4分類を活用して「今週は何をしたかな?」といった風に、振り返ってみると面白いかも知れません。

1. 情報収集

  • メールと未読のチャットを読む
  • コーヒーコーナーで雑談する
  • 1on1で今週やっていることや問題の対処を開く

情報収集は自分の意思決定の土台になります。組織の内外を問わず、常に情報を集めることが重要です。

2. 意思決定

  • 面接した人の採用を決める
  • 誰を面接に呼ぶか決める
  • プルリクエストのレビューをする

マネージャーの意思決定は大きな権限の一つです。細心の注意を払い、結果に責任を持つことが重要です。本書では「2回測って1回切る」という大工さんがよく使う格言で喩えています。1回間違うと修正が効かないので、2回測って注意して切りましょうという意味です。

3. ナッジング

  • メールの返信で自分の考えや知識を共有する
  • 自分のチームの取り組みを説明し同じようにすることを提案する
  • 経験が少ない人も採用候補にするようにCTOに提案する
  • 1on1 で次の仕事の取り組み方をアドバイスする
  • ログ収集のベストプラクティスについて話す

議論に対して自分の観点を提供して、決定に影響を与えることです。

4. ロールモデル

  • 新しい機能を作った人に、ユーザーの評価が高いことを伝える
  • TechTalkの準備をする

物事をきちんと実行し、言うべきことを言う。 これを実例で示す

組織が求めるリーダー像を体現し、周りに行動で示していくことです。例えば「持続可能なペースで働きましょう」と語るマネージャーが、ものすごく残業や休日出勤をしていたらどうでしょうか。全く行動で示せていないですよね。マネージャー自身が見本になるのも仕事です。

なんでも自分でやるのは無理、権限移譲しよう

マネージャーのアウトプット = 

あなたのチームのアウトプット + あなたが影響を与えた他チームのアウトプット

マネージャーのアウトプットを最大化するためには、なんでも自分自身でやらず、権限移譲することが大切です。ただし「移譲できるのは実行責任まで」というポイントを忘れずに。説明責任は委譲できないので結果や経緯はマネージャー自身が説明できる状態でないといけません。

権限移譲には段階がある

EMのしごと

上記の図のように、権限移譲にはグラデーションがあります。人ごと・タスクごとに段階がありますのでメンバーのスキルなどに合わせ、権限移譲の度合いを設定しましょう。どのタスクをどの程度、移譲するかの選択はマネージャーの責任になってきます。委譲すると時間とともに学習が進みチームのアウトプットが増えるのでマネージャーとして成果が出たと言えるようになります。

権限移譲のポイントは「今のスキルのちょっと上」

何も支援しなくてもできることを移譲するだけでは不十分です。相手のスキルのちょっと上をいくチャレンジをさせてみるのが良いでしょう。現状のスキルや能力と、あまりにかけ離れている移譲は、相手が精神的に壊れたりなど大きなリスクが考えられるので見極めが必要です。

権限移譲 3つの注意点

  1. 丸投げ

マネージャー本人が説明責任を取らず、タスクそのものを忘れてしまい、ある日突然大事件……なんてことがないようにしましょう。

  1. 他の人のやり方が自分と同じであることを期待すること

我々エンジニアは、ソフトウェアを作ります。製造業の生産ラインではないので、進め方は人によって違います。自分の進め方と全く同じ方法を相手に期待しないようにしましょう。そもそも、やり方を固定してしまうと改善の機会も失われてしまいますのであくまで成果で見ることを意識しましょう。

  1. すぐに取り上げない

一度、権限移譲したタスクを合理的な理由なく取り上げるのはやめましょう。やっぱり自分がやった方が早いということで取り上げると、本人のモチベーションが下がります。

コントロールできない部分は割り切るしかない

権限移譲の重要さを理解しつつも、やっぱり不安になりますよね。

  • 締め切り直前に大事故が発生するのではないか
  • 権限移譲したタスクの進捗が心配
  • 期待した品質でないときにイライラする
  • イライラや不安が私生活に影響する

重要なのは、すべてをコントロールしようとしないことです。全部が自分の思い通りになることはないと割り切りが必要です。自分がコントロールできないことについて、ストレスを溜めることはやめましょう。

心配しても仕方がないこともある

コントロールの三分法をご存知でしょうか。この分類を活用し、皆さんの結果に対する向き合い方を変えると良いかも知れません。

  • 私たちがコントロールできるもの・・・結果について心配する
  • 私たちが全くコントロールできないもの・・・結果について心配しない
  • 私たちがある程度コントロールできるもの・・・内部ゴールを設定しベストを尽くす

例えば・・・

新しいプロダクトをリリースする場合

成功するかな?と心配しても、コントロールできません。コントロールできるとすれば、チームがベストを尽くすという内部ゴールに対し、全力で向かうことだけです。

メンバーが転職を考えている場合

外部ゴールでコントロールできません。代わりにカウンターオファーを出したり、環境改善するなどベストを尽くすことがゴールです。

権限移譲されたメンバーの欲求を満たす

チームメンバーの欲求を満たせるよう多くの機会を作ることが、マネージャーとしての責任です。なるべく本人の希望に沿うような形を提案することでモチベーションが上がり、スキルが上がり、チームパフォーマンスも上がります。

発達の最近接領域

EMのしごとメンバー本人が目指す将来像(自己実現欲求)を実現できるよう支援するのもマネージャーの仕事ですが、このときに役立つのが「発達の最近接領域」です。これはタスクの難易度を3分割し、図の中央にあるように「支援があれば自分でできるタスク」を割り当てましょう、という考え方です。発達の最近接領域を使ってメンバーの目指す将来像を実現するために、どう段階を踏んでいくべきか?を1on1などで話し合うのが良いでしょう。
EMのしごと

月1程度の1on1では、全く通用しない

1on1の活用は重要です。チームメンバーの育成やパフォーマンス改善、チームのアウトプットを増やすことを目的にする場合、月1程度の1on1では、厳しいです。最低でも、2週間に1回程度の頻度が好ましいでしょう。

結局、エンジニアリングマネージャーの一番のしごとって?

リチャード・ブランソンの名言があります。

転職できるぐらいに人を訓練し、転職したいと思わないくらいに厚遇せよ

ソフトウェアやプロダクトは、人がいなければ作れません。人を大事にして、人に成長してもらい、パフォーマンスを発揮できるようにすることが、マネージャーとしての本当に一番重要な仕事だと思っています。

ここまでの話をまとめると、結局マネージャーはメンバーのために存在するんですよね。

時間がないから 1on1 は月に1回だけだったり、評価面談で「今期どんな仕事してた?」と聞いてしまったり、こんなことがないようにチームメンバーに奉仕していただくと良いのかなと思います。

詳細はぜひ、書籍をご覧ください

こちらをセットで読んでいただくととても勉強になるかと思います。ぜひご覧ください。

ここからは、視聴者からの質問に答える「QAセッション」のコーナーです。エンジニアリングマネージャー(以下、EM)に関するあれこれに回答します。

Q:技術に強みのないEMは成立しますか?

—むしろ技術的に強みのない方が権限移譲に成功しそうな気はしますが、いかがですか?

吉羽:エンジニアチームのマネージャーなので、エンジニアリングの話が通じないとか発生する問題に対応できないのは厳しいですが、そのあたりの会話ができるレベルであれば問題ないとは思います。

技術に関する意思決定が必要であればテックリードがやればいいので、技術が飛び抜けている必要はないのでは?と思います。

Q:エンジニアからリスペクトされる方法は?

—技術力以外に必要な要素はありますか?

吉羽:やっぱり普段の振る舞いですよね。ロールモデルになれるような人物であること、誠実で常に安定していてロジカルな人柄であることでしょうか。誰に対しても同じトーンで丁寧に接することの重要さは書籍でも指摘しているところですね。あとはチーム間のちょっとした対立なんかが起きたときに、チームを守ってくれる姿勢があると尊敬されると思います。

Q:EMのキャリアパスについて教えてください

吉羽:書籍エンジニアのためのマネジメントキャリアパス』で詳しく解説しているので、よろしければご覧ください。エンジニアリングチームのマネージャー → その1階層上を目指す → CTO といったようなプランが書かれています。ただ、どのポジションが偉いとかは関係なく、自分自身がどうなりたいかで考えた方がいいと思います。

Q:EM / PM / PdM / テックリードの間にある責任分界点は?

吉羽:いい質問ですね。エンジニアリングマネージャーの職務って共通定義があるわけではないので、自組織の中でどう分解するかという話になるかと思います。それぞれの職務の責任分界点がどこにあるのか、お互いが合意できていることが重要です。

Q:EMのアンチパターンとは?

吉羽:PM 兼 EM のように、デリバリーそのものの責任とチームマネージメントの責任の両方を背負わせるパターンは、アンチパターンでしょう。

プロジェクトのデリバリー責任を持つと、スコープや納期を守らないといけないので、外部からのプレッシャーを受けやすいんです。そうなると、どうしてもチームを犠牲にしたくなります。だからデリバリーのプレッシャーが高い環境でピープルマネージャーを兼任するのは、僕は最大のアンチパターンだと思ってます。

Q:訓練したメンバーの転職を給与以外で阻止する方法は?

吉羽:給与は大事ですよ。世の中には適正価格があってスキルが上がれば引く手数多になり、市場価値も上がっていくので当然お金は出さないといけません。エンジニアは引く手数多ですし、競争力の源泉の一つでもあります。大変ですが、給与テーブルの見直しを働きかけるといった活動もエンジニアリングマネージャーの役割になってくるかも知れません。

それ以外だと、やはり仕事の面白さですかね。福利厚生や労働時間の観点もあれど、結局は自己実現できることの価値が高いのかなと思います。逆にいくら給与が高くても、自分のやりたいことができないと転職してしまうでしょう。

Q:EM 兼 開発者のアンチパターンとは?

吉羽:まず EM として十分責任を果たし機能している状態になって、それでも時間があるならコードをかけば良いのかなと。全てが中途半端だとチーム全員が路頭に迷うので、兼務するなとは言いませんがプライマリーの職責を十分果たしてからにしましょう。

また複数役割を持つ人物の発言に対して、周りの受け止め方が困難になる問題もあります。「それってプロダクトオーナーの意見として言ってるの?」「チームマネージャーとして言ってるの?」というように聞いてる側の区別が付きづらいんです。

—本人は立場によって発言を使い分けていても「あの人言ってること違うな」と思われると、信頼感の醸成に悪影響を及ぼしますよね。

吉羽:そうですね。本人が思う以上に、実は弊害が大きいので注意したいですね。

Q:EMにとって、マネージメント以外で重要なスキルは?

吉羽:実は文章を書くスキルが大事なんじゃないかなと思っていて、自然文でチームのミッションや戦略を書いてみたりする言語化能力が重要な気がします。

—言語化能力は、どうしたら鍛えられるのでしょう?

吉羽:とにかく書かないとうまくならないです。書いてフィードバックをもらうこと、経験値を積むことです。あとは伝わりやすい文章の型もあるので、意識すると良いかも知れません。

Q:メンバーからEMになる方法は?

吉羽:段階を踏んだチャレンジ(支援があればできる業務)をこなせるようになり、今後は支援する側の人間になることでしょうか。メンターなど人と関わる仕事を増やしていき、自分ができることを見せるのは、よくあるシナリオかな。

— EM を選ぶ側の視点について伺います。CEO・CTO など経営側の人間が良い EM を専任するために、どのような目線を持つべきでしょうか?

吉羽:「エンジニアリングマネージャーのしごと 4分類」のなかでも、ナッジングとロールモデルの項目は目に見えやすいですよね。

チームの困りごとを社内に共有したときに「この人に聞いたら良いんじゃない?」と推薦があがるような人や、率先して情報提供してくれる人は、人や全体のパフォーマンスに関心を持つ人なので、そういった目線で探してみると良いのではないでしょうか。

360度評価のような評価制度だと、一緒に働いてる人からフィードバックがもらえるので、それを一つの基準にしてみるのもありかも知れないですね。

Q:ピープルマネージメントの限界値は?

—EM の仕事の中でも、ピープルマネジメントに重きをおいた場合、何名くらいまでが自分の見られる範囲なのでしょう?

吉羽:チームの成熟度にもよります。成熟していたら10人、未成熟なら5〜7人くらいでしょうか。

もし1on1に毎週1人30分あたり時間をかけると、それだけで丸一日潰れますよね。マネージャーの仕事って1on1と採用関連の比重がすごく大きいので、それに加えて組織間の問題が発生したなんてことがあれば、ワークしなくなります。だから状況にもよるのですが、まず10人以上を抱えるのは無理だと考えた方が良いのかなと思います。

Q:不確実性の高いタスクをスクラムチームにアサインする方法

吉羽:EM はスクラムチームに解決してほしい問題を伝えるところまでやれば良いんですよ。どれぐらいの規模感か、分割して着手するのか、どういう作戦なのかは、エンジニアの方がプロですからお任せすれば良いんです。全部を決めたタスクをアサインするというのは、仕事の割り当て方として、あまり適切ではない気がしますね。

登壇者紹介

吉羽 龍太郎

株式会社アトラクタ

取締役CTO / アジャイルコーチ / 『チームトポロジー』共訳者 野村総合研究所、Amazon Web Servicesなどを経て現職。Scrum Alliance 認定スクラムトレーナー(リージョナル)(CST-R) / 認定チームコーチ(CTC) / Microsoft MVP for Azure。著書に『SCRUM BOOT CAMP THE BOOK』(翔泳社)など、訳書に『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『レガシーコードからの脱却』など多数。

動画視聴はこちらから

ForlkwellPress ロゴ画像

編集部

Follow

エンジニアに役立つ情報を定期的にお届けします。

エンジニアに役立つ情報を定期的にお届けします。

SHARE

目次

目次