ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■リーダーシップとチームマネジメント
2022.10.11 2024.06.28 約5分
今回は2022年8月26日出版の最新刊『エンジニアリングマネージャーのしごと』を取り上げます。翻訳者である吉羽 龍太郎 氏は、日本企業、外資系企業でエンジニアリングマネージャーを経験。エンジニアリングマネージャーの基礎やエンジニアリングマネージャーを目指すためのノウハウなどを伺います。
エンジニアリングマネージャーの定義は曖昧ですが、よく言われるのは以下の4領域です。
組織の成熟度によって4領域へ関与する度合いが変わりますが、軸になるのはピープルマネージメントです。ピープルマネージメントは、人事評価の権限を持ち、チームメンバーのマネジメントが職務の中心にある職種のことです。
1on1を毎週やりたいけど時間がない
忙しいけどマネージャーとして成果を出せているかわからない
朝からミーティングだらけで仕事が全然進まない
みなさんは、いかがでしょうか。私自身もマネージャー時代は、忙しいのに何かをやり遂げた感覚がない……と常にモヤモヤしていました。このような状態は「稼働率100%の消防車」と同じで、あまり良くありません。火事が発生し出動が必要なのに「いや今、他に行ってます」という状態は危険ですよね。組織内で複数の業務を兼務している場合も、あまり良くない状態です。
自分自身の整理整頓ができない人間が、チームを効果的に扱えるはずがありません。自分の記憶に頼らず、必要なときに必要な情報を探せるようにしておきましょう。ポイントは、いつも同じ方法で整理をすることです。ツールを活用しても良いしシステムを構築しても良いでしょう。有名な企業のトップが、いつも同じ服を着ていたり、いつも同じものを食べている状態に近いかも知れませんね。
マネージャーには考える時間が必要なので、カレンダーにブロック枠を入れておくことがポイントです。
メールを見て、Slackを見て、と往復する時間は本当に無駄です。通知機能を活用して一箇所に集約しましょう。ちなみに本日18時時点での私のメール数は、たった6通です。同僚は1万通ぐらいでした。ガンガンアーカイブして整理しましょう。
マネージャーとしての成果が何かは色々な考え方がありますが、本書はこのように定義しています。
| マネージャーのアウトプット =
あなたのチームのアウトプット + あなたが影響を与えた他チームのアウトプット |
アウトプットが少ないなら、多くできるよう改善するのもマネージャーの仕事です。
方程式にあるとおり、マネージャーの個人タスクよりもチームパフォーマンスを上げることを優先してください。権限移譲やメンタリング、コーチングなどに時間を使いましょう。
自分のチームを守るばかりで他のチームに悪い影響を与えるとアウトプットの総量は下がるので注意が必要です。
マネージャー業務は多岐に渡りますが、具体的に「この仕事をした！」と言い切ることが難しかったりします。この4分類を活用して「今週は何をしたかな？」といった風に、振り返ってみると面白いかも知れません。
情報収集は自分の意思決定の土台になります。組織の内外を問わず、常に情報を集めることが重要です。
マネージャーの意思決定は大きな権限の一つです。細心の注意を払い、結果に責任を持つことが重要です。本書では「2回測って1回切る」という大工さんがよく使う格言で喩えています。1回間違うと修正が効かないので、2回測って注意して切りましょうという意味です。
議論に対して自分の観点を提供して、決定に影響を与えることです。
物事をきちんと実行し、言うべきことを言う。 これを実例で示す
組織が求めるリーダー像を体現し、周りに行動で示していくことです。例えば「持続可能なペースで働きましょう」と語るマネージャーが、ものすごく残業や休日出勤をしていたらどうでしょうか。全く行動で示せていないですよね。マネージャー自身が見本になるのも仕事です。
| マネージャーのアウトプット =
あなたのチームのアウトプット + あなたが影響を与えた他チームのアウトプット |
マネージャーのアウトプットを最大化するためには、なんでも自分自身でやらず、権限移譲することが大切です。ただし「移譲できるのは実行責任まで」というポイントを忘れずに。説明責任は委譲できないので結果や経緯はマネージャー自身が説明できる状態でないといけません。
上記の図のように、権限移譲にはグラデーションがあります。人ごと・タスクごとに段階がありますのでメンバーのスキルなどに合わせ、権限移譲の度合いを設定しましょう。どのタスクをどの程度、移譲するかの選択はマネージャーの責任になってきます。委譲すると時間とともに学習が進みチームのアウトプットが増えるのでマネージャーとして成果が出たと言えるようになります。
何も支援しなくてもできることを移譲するだけでは不十分です。相手のスキルのちょっと上をいくチャレンジをさせてみるのが良いでしょう。現状のスキルや能力と、あまりにかけ離れている移譲は、相手が精神的に壊れたりなど大きなリスクが考えられるので見極めが必要です。
マネージャー本人が説明責任を取らず、タスクそのものを忘れてしまい、ある日突然大事件……なんてことがないようにしましょう。
我々エンジニアは、ソフトウェアを作ります。製造業の生産ラインではないので、進め方は人によって違います。自分の進め方と全く同じ方法を相手に期待しないようにしましょう。そもそも、やり方を固定してしまうと改善の機会も失われてしまいますのであくまで成果で見ることを意識しましょう。
一度、権限移譲したタスクを合理的な理由なく取り上げるのはやめましょう。やっぱり自分がやった方が早いということで取り上げると、本人のモチベーションが下がります。
権限移譲の重要さを理解しつつも、やっぱり不安になりますよね。
重要なのは、すべてをコントロールしようとしないことです。全部が自分の思い通りになることはないと割り切りが必要です。自分がコントロールできないことについて、ストレスを溜めることはやめましょう。
コントロールの三分法をご存知でしょうか。この分類を活用し、皆さんの結果に対する向き合い方を変えると良いかも知れません。
例えば・・・
新しいプロダクトをリリースする場合
成功するかな？と心配しても、コントロールできません。コントロールできるとすれば、チームがベストを尽くすという内部ゴールに対し、全力で向かうことだけです。
メンバーが転職を考えている場合
外部ゴールでコントロールできません。代わりにカウンターオファーを出したり、環境改善するなどベストを尽くすことがゴールです。
チームメンバーの欲求を満たせるよう多くの機会を作ることが、マネージャーとしての責任です。なるべく本人の希望に沿うような形を提案することでモチベーションが上がり、スキルが上がり、チームパフォーマンスも上がります。
メンバー本人が目指す将来像（自己実現欲求）を実現できるよう支援するのもマネージャーの仕事ですが、このときに役立つのが「発達の最近接領域」です。これはタスクの難易度を3分割し、図の中央にあるように「支援があれば自分でできるタスク」を割り当てましょう、という考え方です。発達の最近接領域を使ってメンバーの目指す将来像を実現するために、どう段階を踏んでいくべきか？を1on1などで話し合うのが良いでしょう。
1on1の活用は重要です。チームメンバーの育成やパフォーマンス改善、チームのアウトプットを増やすことを目的にする場合、月1程度の1on1では、厳しいです。最低でも、2週間に1回程度の頻度が好ましいでしょう。
リチャード・ブランソンの名言があります。
転職できるぐらいに人を訓練し、転職したいと思わないくらいに厚遇せよ
ソフトウェアやプロダクトは、人がいなければ作れません。人を大事にして、人に成長してもらい、パフォーマンスを発揮できるようにすることが、マネージャーとしての本当に一番重要な仕事だと思っています。
ここまでの話をまとめると、結局マネージャーはメンバーのために存在するんですよね。
時間がないから 1on1 は月に1回だけだったり、評価面談で「今期どんな仕事してた？」と聞いてしまったり、こんなことがないようにチームメンバーに奉仕していただくと良いのかなと思います。
こちらをセットで読んでいただくととても勉強になるかと思います。ぜひご覧ください。
 |
 |
ここからは、視聴者からの質問に答える「QAセッション」のコーナーです。エンジニアリングマネージャー（以下、EM）に関するあれこれに回答します。
—むしろ技術的に強みのない方が権限移譲に成功しそうな気はしますが、いかがですか？
吉羽：エンジニアチームのマネージャーなので、エンジニアリングの話が通じないとか発生する問題に対応できないのは厳しいですが、そのあたりの会話ができるレベルであれば問題ないとは思います。
技術に関する意思決定が必要であればテックリードがやればいいので、技術が飛び抜けている必要はないのでは？と思います。
—技術力以外に必要な要素はありますか？
吉羽：やっぱり普段の振る舞いですよね。ロールモデルになれるような人物であること、誠実で常に安定していてロジカルな人柄であることでしょうか。誰に対しても同じトーンで丁寧に接することの重要さは書籍でも指摘しているところですね。あとはチーム間のちょっとした対立なんかが起きたときに、チームを守ってくれる姿勢があると尊敬されると思います。
吉羽：書籍『エンジニアのためのマネジメントキャリアパス』で詳しく解説しているので、よろしければご覧ください。エンジニアリングチームのマネージャー → その1階層上を目指す → CTO といったようなプランが書かれています。ただ、どのポジションが偉いとかは関係なく、自分自身がどうなりたいかで考えた方がいいと思います。
吉羽：いい質問ですね。エンジニアリングマネージャーの職務って共通定義があるわけではないので、自組織の中でどう分解するかという話になるかと思います。それぞれの職務の責任分界点がどこにあるのか、お互いが合意できていることが重要です。
吉羽：PM 兼 EM のように、デリバリーそのものの責任とチームマネージメントの責任の両方を背負わせるパターンは、アンチパターンでしょう。
プロジェクトのデリバリー責任を持つと、スコープや納期を守らないといけないので、外部からのプレッシャーを受けやすいんです。そうなると、どうしてもチームを犠牲にしたくなります。だからデリバリーのプレッシャーが高い環境でピープルマネージャーを兼任するのは、僕は最大のアンチパターンだと思ってます。
吉羽：給与は大事ですよ。世の中には適正価格があってスキルが上がれば引く手数多になり、市場価値も上がっていくので当然お金は出さないといけません。エンジニアは引く手数多ですし、競争力の源泉の一つでもあります。大変ですが、給与テーブルの見直しを働きかけるといった活動もエンジニアリングマネージャーの役割になってくるかも知れません。
それ以外だと、やはり仕事の面白さですかね。福利厚生や労働時間の観点もあれど、結局は自己実現できることの価値が高いのかなと思います。逆にいくら給与が高くても、自分のやりたいことができないと転職してしまうでしょう。
吉羽：まず EM として十分責任を果たし機能している状態になって、それでも時間があるならコードをかけば良いのかなと。全てが中途半端だとチーム全員が路頭に迷うので、兼務するなとは言いませんがプライマリーの職責を十分果たしてからにしましょう。
また複数役割を持つ人物の発言に対して、周りの受け止め方が困難になる問題もあります。「それってプロダクトオーナーの意見として言ってるの？」「チームマネージャーとして言ってるの？」というように聞いてる側の区別が付きづらいんです。
—本人は立場によって発言を使い分けていても「あの人言ってること違うな」と思われると、信頼感の醸成に悪影響を及ぼしますよね。
吉羽：そうですね。本人が思う以上に、実は弊害が大きいので注意したいですね。
吉羽：実は文章を書くスキルが大事なんじゃないかなと思っていて、自然文でチームのミッションや戦略を書いてみたりする言語化能力が重要な気がします。
—言語化能力は、どうしたら鍛えられるのでしょう？
吉羽：とにかく書かないとうまくならないです。書いてフィードバックをもらうこと、経験値を積むことです。あとは伝わりやすい文章の型もあるので、意識すると良いかも知れません。
吉羽：段階を踏んだチャレンジ（支援があればできる業務）をこなせるようになり、今後は支援する側の人間になることでしょうか。メンターなど人と関わる仕事を増やしていき、自分ができることを見せるのは、よくあるシナリオかな。
— EM を選ぶ側の視点について伺います。CEO・CTO など経営側の人間が良い EM を専任するために、どのような目線を持つべきでしょうか？
吉羽：「エンジニアリングマネージャーのしごと 4分類」のなかでも、ナッジングとロールモデルの項目は目に見えやすいですよね。
チームの困りごとを社内に共有したときに「この人に聞いたら良いんじゃない？」と推薦があがるような人や、率先して情報提供してくれる人は、人や全体のパフォーマンスに関心を持つ人なので、そういった目線で探してみると良いのではないでしょうか。
360度評価のような評価制度だと、一緒に働いてる人からフィードバックがもらえるので、それを一つの基準にしてみるのもありかも知れないですね。
—EM の仕事の中でも、ピープルマネジメントに重きをおいた場合、何名くらいまでが自分の見られる範囲なのでしょう？
吉羽：チームの成熟度にもよります。成熟していたら10人、未成熟なら5〜7人くらいでしょうか。
もし1on1に毎週1人30分あたり時間をかけると、それだけで丸一日潰れますよね。マネージャーの仕事って1on1と採用関連の比重がすごく大きいので、それに加えて組織間の問題が発生したなんてことがあれば、ワークしなくなります。だから状況にもよるのですが、まず10人以上を抱えるのは無理だと考えた方が良いのかなと思います。
吉羽：EM はスクラムチームに解決してほしい問題を伝えるところまでやれば良いんですよ。どれぐらいの規模感か、分割して着手するのか、どういう作戦なのかは、エンジニアの方がプロですからお任せすれば良いんです。全部を決めたタスクをアサインするというのは、仕事の割り当て方として、あまり適切ではない気がしますね。
吉羽 龍太郎
取締役CTO / アジャイルコーチ / 『チームトポロジー』共訳者 野村総合研究所、Amazon Web Servicesなどを経て現職。Scrum Alliance 認定スクラムトレーナー（リージョナル）（CST-R） / 認定チームコーチ（CTC） / Microsoft MVP for Azure。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）など、訳書に『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『レガシーコードからの脱却』など多数。
取締役CTO / アジャイルコーチ / 『チームトポロジー』共訳者
野村総合研究所、Amazon Web Servicesなどを経て現職。Scrum Alliance 認定スクラムトレーナー（リージョナル）（CST-R） / 認定チームコーチ（CTC） / Microsoft MVP for Azure。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）など、訳書に『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『レガシーコードからの脱却』など多数。
;?>/images/ico/ico_blank.svg){kind=spacer}
