第5章 チームリーダー入門
5.1 マネージャーとテックリード(とその両方)
最もハイレベルなところでは、エンジニアリングマネージャーは、チームが担当する製品がビジネス要件を満たすことを保証しつつ、その上でテックリードを含むチーム内の全ての人員の成績、生産性、満足度について責任を持つ。ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れないため、このことがマネージャーを難しい立場に置く可能性がある場合が多い。
さらっと書いてあるけどめちゃくちゃ難しそう...
今年の10月から社内の異動でプロジェクトマネージャーとピープルマネージャーが異なる経験を多分社会人人生で初めてしているが助かるなーと思う
開発/保守の人員割り当てと個人の希望で自社のマネージャも苦労しているイメージ。最初から配属するチームが明確な状態で採用できていないと希望との差異が埋まりにくいので。
人数と主戦力の分散
主戦力を固定しちゃうと異動が必要なときに困る
大半のTLは ICでもあるので、自身で何かを手っ取り早くやってしまうか、それをチームメンバーに任せて(場合によっては)より時間をかけて行わせるかのどちらかの選択を強いられる。チームの規模と力量が増大するにつれ、ほとんどの場合に後者がTLにとっての正しい選択となる。
自身で手っ取り早くやってしまいたくなることが間々あります。「自分でやったほうが早い…」と思ってしまう場面があるのでチームの規模・力量をまだまだ伸ばす余地があると思って頑張っていきたい。
特に協力会社の方の指導しながらやっていると、その傾向が強い
急に戻されちゃったりもする
5.2 IC役職からリーダーシップ役職への異動
その方法は、一定期間自分の現在の職務レベルを上回る業務を遂行す る(すなわち、自分の現在のレベルでの「期待を超える」)ことを、そのレベルへ昇進する前に社 員に要求するというものだ。
今日お話ししてたやつですね
自社の評価制度では、職位ごとの振る舞いが明文化されていて、1つ上の職位の振る舞いをこなせるあたりで昇進するようなロジックになっていますね
自ら上司の仕事を奪いに行かないと昇進できない仕組みになっている
規模の大きくない会社だとマネージャー層はたいていオーバーワーク気味なのでこの仕組みが回っている
たとえ絶対にマネージャーにはなるまいと自分に誓っていたとしても、キャリア上のある時点 で、自分がリーダーシップ役職に就いているのに気づくというのは十分にありうること
人員管理のマネジメント系を回避してたら、知らない間にチーム全体の品質周りのチェック等々技術的な側の役割が回ってきていたってことはありました。
≒テックリード
サーバントリーダーシップ
そういえば、「いい兄貴問題」なんてのが昔あったなあと思いました
「何よりも、管理しようという衝動に抵抗せよ」
5.3 エンジニアリングマネージャー
4文字単語
いわゆるfワード
5.4 アンチパターン
アンチパターン: 押しに弱いものを採用する
同じようなことが『ピープルウェア』にも書いてあったなあと思いました
引っ張る者なしでは動けないチームとなるだろう。(中略)自身はおそらく、休暇を取れなくなる
マネージャーがそう思いこんでいるだけのケースも往々にしてある気がしている
イレギュラー対応を一手に引き受けて常時忙しいので、マネージャーがいなくても大丈夫な仕組みがあっても心理的に休みづらくなる
ある意味、メンバーを見くびっていることになるので信頼して任せるの大事
こういうコミュニケーションのすれ違いとか、思い込みってマネージャーとメンバーみたいな1対多数だと起きがちだよなーって改めて思った。
どこから手を出すべきか
逆に、信頼して任せていたらあまり成長しなかったパターンもあるので、塩梅がむずかしい
そのケースでは、時間に追われて(実際はそこまで切迫してないのに)立ち止まって考えたりできることを広げたりを自分からやっていなかった
実のところは、チームのメンバーは誰の成績が悪いのかを痛切に認識している。
そうなのかもしれないけど、怖いな〜と思った
子供のように振る舞う従業員たちや、安いオフィスサプライ用品を正式な手順を踏んで依頼するのに貴重な時間を浪費しなければならない従業員たちを抱えるコストについてはどうだろうか
信頼が一番安くつく
コミュニケーションコスト、セキュリティのコスト
信頼されている関係であれば往復も減るし、マネジメントも細かくしなくて済むのでその通りだと思います。
5.5 建設的パターン
アドバイスを求めてきた者に問題の精緻化と探究を行うよう努めさせることで、その者が問題を自信で解決する手伝いができる
「脳はこうして学ぶ」という本に「学習の四本柱は注意・能動的関与・誤りフィードバック・定着」と書いてあった
「注意」は「適切な着眼点」的な意味
このアプローチは「定着」以外を満たしているなーと思った
何が言いたいかというと、ここに書かれているのはメンバーを成長させるための効果的なふるまいであるということ
(メンターに)主に必要なものは3つだ。それは、チームのプロセスとシステムについての経験、他者に物事を説明する能力、メンティーがどれだけ助けを必要としているか推し量る能力だ
「エンジニアリング組織論への招待」にはメンタリングのコツは「傾聴・可視化・リフレーミング」と書かれている
傾聴は3番目(どれだけ助けを必要としているか推し量る)、可視化は2番目(他者に物事を説明する)として、リフレーミングにあたるものがない
本書で想定しているメンタリングはかなり受け身の姿勢で、積極的なメンタリングを志向しているのが「エンジニアリング組織論への招待」といえる
実際、第2章がまるまる割かれている
メンタリングに関してはエンジニアリング組織論への招待を参考にするのが良いかも
褒め言葉のサンドイッチ
やりがち
ネガティブフィードバックをするときは、「相手の悪意を想定してない」ことを示すように気をつけています
「下げて上げる、上げて下げるのどっちが良いのか?」は相手を不快にさせないほうが目的なので、問題解決のためには明確かつ悪意を持たずに指摘するのが良いのかも
「不快にさせない」のも無視はできないですよねー
感情のぶつかり合いは仲裁する人が一番胃が痛い
少し前に仲裁をお願いされる側になったのですごくわかる…思ってた以上につらかった…
問題vs.私たちに持っていっておけば、ぶつかり合いがあっても目的は揃っているので建設的
障害を取り除く助けになる答えの全て を知っている必要はないが、答えがわかる人々を知っているとたいてい役立つ。多くの場合に、適 切な人物を知っているというのは、正しい答えを知っていることよりも価値があるのだ。
マネージャーとして答えを知っている必要はないが、知らなすぎてもダメだよなあと思っていたところ、「適切な人物を知っている」というのはバランスのいい落とし所だよなと思った
5.5は全体的に人間的な成熟(?)のようなものが必要そうな印象で、身につけるための手段に捉え所がないなあと思った
5.6 予期しない質問
仕事場の外でのチームの満足度も意外と大事だよなあと確かに思った
プライベートが大変な中で、集中して仕事するのも難しいだろうし
5.7 他のヒントや秘訣
移譲する、しかし手は動かす
これは「手を動かせるようにしておく」という意味でもある
「両方」やらなくっちゃあならないのが「マネージャー」のつらいところ
実際コード書かなくなっても手を動かして検証しつつコードレビューしているのが、メンバーの信頼を得るのに重要だと感じている
そのぶん現場を離れるのがちょっと怖い
どこかで見せる場を作らないといけない
アーキテクトやCTOになると、「広い選択肢を知っておく」という形になる
波風を立てるべきときを心得る
この判断が難しいなと思う(自分はマネージャーじゃないけど)
「いい兄貴」になっているだけではダメなんだよなあと思う
5.8 人は植物のようなものである
最高に人の満足度を高め生産性を上げる方法は、外発的動機付けではないと説く
かといってお金はほしいし尖らせるとブラック企業の理屈になる
内発的動機づけがある人を採用せよという話、カルチャーフィットを重視するのがこれ
「やりたいこと」だとポジション変わったらやめがち、「目標」が一致しているとやめにくい
キャリアパスの明確な人ほどやめやすい
内発的動機付けの支援をするのがリーダーシップだっていうのめっちゃわかるなー。成長している人とかチームは内発的動機付けがうまくいっている傾向が大きい。内発的動機付けのために1on1をやるっていうのもあるよな。。。
内発的動機付けの話めっちゃわかるんですけど、自分がマネージャーになったとしてメンバーの内発的動機付けできるかと言われるとめっちゃ難しいなぁ。。。
本人の内発的動機を1on1などで聞き出しておいて、なるべくそれに沿う(チームの目的にも沿う)仕事をお願いしていく、という理解です
「他人の内発的動機づけを行う」というのはそもそも矛盾している気がする
チームを作っていくのを「ガーデニング」と例えた本をどっかで読んだ気がするので、本当に植物なのかもしれない
北風より太陽
動機付けと方向づけの2つでチームへの働きかけを考えるのは整理としてわかりやすいなと思った
5.9 結論
優れたソフトウェアエンジニアは必ずしも優れたマネージャーとはならず、それで問題ない。
リーダーやマネージャーに昇格していくのは開発者として優秀な人からになりがちだけど、マネージメントの適性があるかは別なんですよね…
5.10 要約
可能な場合は委譲せよ。DIYは行うな
DIYするなっていう表現好きw
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
直接は言及されていないけど評価制度の問題は大きいかもしれない? 第7章 エンジニアリング生産性の計測 にでてくる QUANTSのようなものをつかって生産性を評価したり、そこにコミットするようなデザインがGoogleにはあると思うんだけど、日本だとそういったことは見かけない気がする。 Developer Productivityが少しずつ広まったのもこのあたりの話の気がするのでこれから増えていくのかも?
現場でどこまでできているか?
今の職場だとここに書いてあることをEM専門職としてやるような規模までエンジニア組織としての規模がないからやってない。
一方で、ここに書かれてるようなリーダーシップはよく議論されたり、何らかの形で定期的にチェックしてたりするので、過渡期なのかもしれない。問題は、ここまで来たら必要だよね?みたいな基準をもってないことかもしれない。それに合わせたビジネスの戦略とかも含めて。
1チームに1人はマネージャー、もしくはリーダーは必要。となると、小規模なチームでも発生するのでは?
組織図上のリーダーでなくとも、チームにリーダーシップは必要
大きいところでも、人数増えてきたらチームは分割されるのでは?
弊社でもマネージャー職以外にも従来はなかったスペシャリストの職位が出来て何年か経ったし、他のSIerでもよく聞くようになったが、どうなるか。。。
この本があるのになぜ実践する企業はすくないのか?
経営陣にはわかりにくいからかも?どのように事業計画に加えていいのかがわかりにくい?外資だと比較的やってる部分も多い気はするが。
EM向けの教育という意味かな?
普通の管理職の人には伝わりにくい。専門性の必要が理解されにくい
テックな人が多い組織でないと難しい
それの乗り越え方はなにか?
徐々に変えていくために、ここに書かれてることを小さなパタン?プラクティスにまとめるとか?フィアレスチェンジとか組織パタンに書かれてるような感じというか。
EMの専門性が存在すること自体をもう少し広める必要があるかも
プラクティスにまとめること自体はEMの裾野を広げるのに必要
ステップを小さくするとしたらどうできそうか?
5章の内容を小さい単位にまとめ直す勉強会の開催とか
PMというとプロジェクトマネージャーとしか思われなかったが、徐々に社内でもプロダクトマネージャーというものが存在するらしいと広まりつつある。エンジニアリングマネージャーやテックリードについてもその存在を知ってもらえるような草の根的な活動(それこそRSGTのエンジニアリングマネージャーのスライドを共有してみるとか)