Zenn
Closed28

エンジニアリングマネージャーのしごとを読む

#
book
#
em
Sota SugiuraSota Sugiura

「エンジニアリングマネージャーのしごと」を読んだのでスポットスポットで気になったところやまとめておきたいところを雑に整理する

https://www.oreilly.co.jp/books/9784873119946/

人の参考になるように書いてないが、もし読むなら本書を手に取りながら読んでください。

Sota SugiuraSota Sugiura

1.1 最初の週を始める

インポスター症候群

https://www.hrpro.co.jp/glossary_detail.php?id=102#:~:text=「インポスター症候群」とは,と呼ばれることもあります。

  • 個人的にめっちゃわかる
  • Managerにアサインされたときは「俺には無理や…」と言う不安の方が大きかった
  • この章に書いてある通り、「一定の信頼があるから任された」とひとまず頭で理解するのが建設的だし、逆の立場に立つとManagerのアサインはリスクの大きい選択肢だと思うので、一定の信頼や期待があると思えると良い
Sota SugiuraSota Sugiura

1.2.2 チーム全員と週次1on1を予約しよう

作り手のスケジュール、マネージャーのスケジュール

  • 「ManagerのタイムボックスとICのタイムボックスは違う」「ICは時間の総量より、連続的なまとまった時間をいかに確保できるかが大事」といった感覚的に感じてたことを具体的な切り口で解いたいいセクションだと思った
  • ここではManagerは1時間単位、ICは半日単位でタイムボックスを管理するのが生産的になるとしている
  • Managerとしてはメンバーの時間を抑えるときは半日単位での空白が確保できるように意識するとよさそう
Sota SugiuraSota Sugiura

1.2.4 自分のスナップショットを作成しよう

  • 自分、上司、チームの3つのそれぞれの認識を整理し、ベン図の形で整理する
  • 下に対するコミュニケーション不足, 上に対するコミュニケーション不足, 誤った思い込み, 認識の一致の4つに整理する

どれがどこにあたるのかは本を読んでほしい

感覚的にやっていた情報整理やコミュニケーションのカバレッジを満たすためにいい考え方だと思った
自分が実際に経験した例は以下

  • 下に対するコミュニケーション不足
    • 会社の方針を伝えきれず、チームとしてやりたいことが会社のベクトルとずれている
  • 上に対するコミュニケーション不足
    • チームとして持っている危機感を伝えきれず、Issueが会社・経営までraiseしきれない
  • 誤った思い込み
    • あまり経験がない、いろんな情報を足元から組み上げる意識があればあまり起きなそう
    • メンバーや上司とコミュニケーションせずに「これがいいに違いない」でことを進めた時に初めて発生すると思う
  • 認識の一致
    • チームの目標と会社の目標がAlignしてる、かつ自分と上司の認識が揃っている状態がこれ
Sota SugiuraSota Sugiura

2.1.1 ツール１：カレンダー

際限なくミーティング等突っ込まれないよう、集中タイムの時間をカレンダーに入れておいてBLOCKしておこう、と言う話

  • 自分はやらなかったなと思ったが、やればよかったと思った
  • 別章でマネージャーのタイムボックスは1時間となっていたが、とはいえMTG5, 6連続とかなると厳しい
  • あとはリモートワークの特徴として、休憩がなくなるので意図的なブロックによる休憩時間の確保は必要
  • あとは脳みそをリセットするために空っぽにする空白の時間が欲しい
Sota SugiuraSota Sugiura

2.1.2.2 どのソフトウェアを使えばよいか？

TODOアプリとしてAsanaが紹介されてた

https://asana.com/ja?&utm_campaign=&utm_source=google&utm_medium=&gclid=CjwKCAiA7IGcBhA8EiwAFfUDscKEpbwqffnox46b65iPbMnNRHMKATbRBfnW2G57AypjkrZXPLZVmRoC78cQAvD_BwE&gclsrc=aw.ds

別にAsanaじゃなくてもいいと思うけど、これを読んでAsanaに乗り換え & 2ヶ月程度使ってみた
結論としてはGood

  • Pros
    • 使いやすい、操作方法に迷うことがない
    • 繰り返し予定を気軽に突っ込める
    • 無料プランでも十分
  • Cons
    • レビュー待ち, 返事待ちみたいなステータス管理はできない(課金すればできる)

ちなみにAsanaの前はNotionでカンバン作って管理してたが管理が追いつかないのと繰り返し予定がなかったり、タスク量が増えた時にViewabilityが下がったので途中から活用できてなかった

Asanaがいいぞ、と言うより大事なのは継続的に使える要件を満たした好みのTODOアプリを見つけようねって話だと思う

Sota SugiuraSota Sugiura

2.3 マネージャーとしてのアウトプットを測るには

アウトプットの方程式として以下を提示している

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

  • ブログにも書いたけど、これはManagerをやりながらかなり悩んでたのが腹落ちできてよかった
  • 何で悩んでたか
    • ICと違ってわかりやすい測定可能なアウトプットがない
    • 取り組むIssueの性質、求められるアウトプットが目まぐるしく変わる
      • 採用計画を立てるときがあれば評価制度をひたすら考える時もあるし、プレイングマネージャーをしてる時もある
    • 自分が関わったIssueで成果が出ても、大半はそれにメインで取り組んだチームやICがおり、ICの時よりも自分でやり切った感を感じづらい
  • 特に自分でやり切った感を感じづらいというのが結構悩みだったんですが、マネージャーの責務は自分が成果を出すことではなく、チームが成果を出すことであり、そのためにどうチームメンバーや他チームに関わっていくかを考えるのがミッション
  • それを意識した上でこの公式を覚えておくと自分がどう振る舞うべきかを忘れずに済むし、自分は何もできてないんじゃないかという錯覚に陥りづらくなるんじゃないかなと思ってる
Sota SugiuraSota Sugiura

3.1.1.1 適切な媒体を選ぶ

コミュニケーションの内容に合わせて媒体を選ぼうね、という当たり前っちゃ当たり前の話。

  • 当たり前なんだけど、意識的に自分の中でシーケンスフロー図を組めてないかも、と思ったのでピックした
  • ざっと言語化すると以下の感じかなと思ってる
    • 1on1(Closedなコミュニケーション)
      • ビデオOnでのVideo call
      • 物理的に出社してる場合は対面でやる
    • メンバーの業務を進めるにあたり必要なコミュニケーション
      • テキストベースでpublicに行う
    • 評価
      • ビデオOnでのVideo call or 対面で行う
      • 事前にテキストベースで情報を共有すべきかは会社の制度と合わせて考える
        • この本では事前共有を推奨してるが、会社の制度によって変えるべきだし個人的には共有は最小限にとどめたい
        • 理由として、メンバーが意図しない解釈をした時にモヤモヤする期間が生まれてしまうから
        • 意図しない解釈ができる評価をするな、という話もあるがいざ取り組んでみると評価というのはなかなか難儀なプロセス、自分はまだ口頭での補完なしで伝えたいことをきちんと伝え切る技術はないと思ってる
Sota SugiuraSota Sugiura

3.1.1.2 自分のエネルギーをマネジメントする

自分自身のコンディションが悪い時、それを一番最初に相手に伝えましょうという話

  • これは、マジで明確にやるべきだったなと思った
  • Managerは忙しいし、タフなIssueに悩まされることもあるし、タイミングによっては結構疲れてることがある
  • そういうタイミングで1on1があったりするといつもと同じテンションで臨めなかったことが思い返せばあったと思う
  • こういう時、メンバーとの関係値があったとしても「なんか今日テンション低いけどダメなことしたっけ…？」みたいに思われる可能性はメンバー - Managerの関係上思われる可能性は高いし、強く意識すべきだった
  • Managerも人間なのでいつでも完璧にこなそうとせず、ダメな時は真摯に伝えながら進めていけるといいなと思った
Sota SugiuraSota Sugiura

3.1.1.3 2回測って1回切る

大工のことわざで2回測って1回切るという言葉がある
これはミスしないようにしようね、という話
これをコミュニケーションにおいても意識しましょう、ということを言ってる

  • 全くもってその通り
  • コミュニケーションはコードと違って、決してrevertできない
  • 特に本人へのフィードバック(1on1, 評価)や、自分が会社の代わりに何かを伝える時、一度開示してしまった情報を「やっぱなし」は決してできない
  • 別の章のどこかに書いてあったが、何をどういう形で伝えるべきかはかなり慎重に検討すべきだし、中途半端な情報は安易に伝えるべきではない
  • 疲れてる時にこのあたりのネジが緩む自覚があるので、大事なコミュニケーションを取る前は時間をブロックして「どう伝えるか」だけを考える時間を5分でも10分でも確保しておくのが大事かも
Sota SugiuraSota Sugiura

3.1.3 一貫性を保とう

さまざまな媒体間での一貫性、フォーマルさは一貫しているのが良い
例えばチャットアプリで非常に砕けたコミュニケーションを取った後、それを中断して批判的なコメントをすることは難しい。
最初は堅めに初めて、徐々に良い範囲で堅苦しさを下げていくのが良いアプローチでしょう。
一旦、砕けた側に振りすぎると元に戻すのが難しくなる

  • わかる、し経験がある
  • 私の場合はパーソナリティが影響してしまって、なるべく早く関係値を作るためにくだけた寄りにしすぎてた気がする
    • 結果的に大きなデメリットは無かったが、少なくとも意識的にコントロールできていなかった
  • 書いてある通り、徐々に振っていくのがいいと思う

マネージャーのあなたの言葉は、個人の言葉ではなく組織図の上のポジションからの言葉として、重く受け止められることを忘れないでください。

  • その通り、忘れてはダメ
  • これはオフィシャルな共有、例えば評価制度のアップデートや組織の方針変更を伝える時には意識できるが、少し曖昧なフェーズのものを伝えるときには意識できてなかったと内省してる
  • 例えばメンバーが感じてるIssueに対して、エンジニアリング組織や会社としてまさにそれを解決する取り組みを水面化で行ってるとき、マネージャーの心情としては「会社はそのIssueを認識していて、アクションも起こしてるので安心してほしい」と伝えたい
    • ただ、このときにこの気持ちを優先して内容を伝えすぎると後々、軌道修正や撤回が入ったときにメンバーとしては裏切られた気持ちになる
    • マネージャーの立場として、メンバーからマネージャーの評価が下がるだけであれば自業自得で済む(だったらいいというわけではもちろんないが…)が、本の言う通りマネージャーの発言というのは特定のコンテキストでは会社の代弁者となる
  • 自分の中での線引きをきちんとしていきましょう
Sota SugiuraSota Sugiura

3.1.4 フィードバックをするには

フィードバックの伝え方に関しての章。章全体が学び。

  • As Managerとして、いいフィードバックをする能力の不足は私の課題
  • そこに対して言語化されたGoodな章
  • 世間的には以下のことって当たり前だと思われてる
    • フィードバックがあればその場で本人に伝えましょう
    • フィードバックと批判は別、本人がNeeds to developなポイントとして明確に伝えましょう
  • 理屈はわかる、合意もするけど実際にするのむずくない？って正直思ってる
    • 私はコミュニケーションが苦手なのでむずい

章で言ってることはざっくり以下。

  • フィードバックを伝えるのに最良かつ簡潔なアドバイスは徹底的な本音
  • 話す相手を個人として気遣いコミュニケーションをとる
  • 考えていることを率直に直接伝える

本では「心から相手を気にかける」x「言いにくいことをはっきり言う」の2軸でフィードバックの性質を4象限に分けてる。
例えば「心から相手を気にかける」x「言いにくいことをはっきり言わない」は「過剰な配慮」になる(私はこれになってしまってることがあると思う)。

  • 頭でわかってることを図と言語で整理され、直感ではなく理屈としていいフィードバックを認識した
  • 「そもそもフィードバックをすべきなのか」に関してはManagerの立場であれば明確にYesで、普段フィードバックする機会を逃し、評価の時期に悪い評価をするのは誠実でない
    • メンバーの立場で考えれば当然で「じゃあその時言ってくれよ」案件でしかない
  • いいフィードバックに関して脳内整理がついたところで、「フィードバックを言い出すタイミングと切り出し方」は残課題な気がしていて、この本では答えが見つけられてない
    • これは定式化するのがかなり難しいと思う
    • 模範解答は1 on 1で言いましょう、になると思うが普段の業務で感じたところはメモしないと忘れてしまうのでメモしておく癖をつけたほうがいいかも
    • あとは正直、トライして経験するしかないのではとも思ってる
Sota SugiuraSota Sugiura

3.2.2 説明責任は委譲できない

委譲をするためにまず説明責任と実行責任の差を理解する必要がある。

  • 説明責任: タスクを求められる品質で完了させる責任を持つ
  • 実行責任: タスクを実際に自分で行う

この前提のもと、委譲とはタスクの実行責任を他の人に託しつつ、説明責任を持ち続けること

  • とてもいい言語化
  • 感覚的にやっていた、やるべきだと思っていたことを簡潔に文章化している一文
  • 今後、委譲に関して人に説明するときはこの言い回しを使いたい
Sota SugiuraSota Sugiura

3.2.3 委譲の物差し

委譲とコントロールをトレードオフとして図式化したものがある。

これを暗に意識しながら各メンバーにどのタスクをどれくらい委譲するか意思決定できると自分の脳内がうまく整理できそう。

Sota SugiuraSota Sugiura

3.2.4 委譲でやるべきこと、やってはいけないこと

全面同意な内容。

やるべきこと

  • 委譲すること
  • スタッフにとってチャレンジになるくらい委譲すること
  • タスクの重要性に応じて適切なコントロールを保持すること

やってはいけないこと

  • 丸投げ
  • 他の人のやり方が自分と同じであると期待すること
  • 渡したタスクを取り返すこと
  • 概ね同意
  • やったことはないけど「やってはいけないこと」の3つ目は強く意識すべきだなと思った
  • やるべきことの「タスクの重要性に応じて適切なコントロールを保持すること」は結構大事だなと思ってる
    • これはメンバーにとっても大事
    • 「結局、マネージャーレイヤの情報共有とか意思決定も関与するじゃん」みたいなタスクをメンバーに任せすぎるとメンバーもストレスが溜まる
  • 渡したタスクが変性して行ったときに、察知して委譲度合いを変えていくのも大事なんじゃないかなと思う
Sota SugiuraSota Sugiura

3.2.3 パフォーマンスについて語ろう

上司と自分の話。
上司から見たときに自分のパフォーマンスとは何か、そのパフォーマンスは何に依存しているかを明らかにしましょう。

もし曖昧な答えしか得られないのであれば、より明確に定量的にするいい機会。

  • 確かに
  • Managerに期待される振る舞いはなかなか抽象的だし、目まぐるしく変わる
  • 一番最初に握って、1 on 1でトラッキングしつつ軌道修正していくといいかもしれない
  • 会社の制度として目標設定みたいなものがある場合はそこで吸収できると良い
Sota SugiuraSota Sugiura

3.3.4 サマリーの力

上司に、自分の見てる世界や仕事の進捗を知ってもらうために定期的にサマリーを取るのがGood。
うまく書けない場合は4つのP(Progress, Problemss, Plans, People)で書くといい。

  • サマリーを定期的に書く、はまぁよさそう。現実的には定期的な1 on 1の前にまとめてそれをベースにコミュニケーションしていくと良い
  • フォーマットとして4つのPは結構よさそう、試したい
Sota SugiuraSota Sugiura

4.3.1 コントラクティングとは何か？

一番最初の1 on 1の際に行う単純な質問一式。会話を誘発する役割がある。
そのうち、「①いちばんサポートが必要な分野はどこか？」という質問がある。

  • この質問、次からやりたいと思った
  • メンバーによって様々な切り口、視点で回答があり得る質問
  • 詳しくは本読んでください(サマるにはちょっと長い)
Sota SugiuraSota Sugiura

4.4.1 あなたではなく、相手のためのミーティング

1 on 1の全体の70%の時間は部かに話してもらうようにしてください。

  • いい塩梅、自分は数字感まで意識できてなかった
  • 1 on 1に慣れるまでは自分で振り返りして意識的に調整してみてもいいかもしれない
Sota SugiuraSota Sugiura

4.4.2 沈黙は金なり

1 on 1の際、相手が黙ったときに無理に間を埋めないようにしましょう。

  • これは明確に意識したい
  • 自分は性格上、埋めようとしちゃってると思う
    • 1 on 1はメンバーのための時間。メンバーが思考してる時間は尊重して、何か喋るのをきちんと待つ
Sota SugiuraSota Sugiura

5.3 大聖堂とバザール

「管理と安定」によってモチベーションが高まる人もいれば、「カオスや変化」によってモチベーションが高まる人もいる。
これにいい悪いもなく、個人的な好みとモチベーション。マネージャーとしてメンバーと会話しながら各メンバーの特性を見抜く。

  • これは確かに、と思った
  • この章の冒頭にもあるがマネージャーは「仕事に合うメンバーを探す」のではなく、「メンバーにあった仕事を作る」と書いてある
  • それをするにはメンバーのモチベーションや特性、もっと言うならキャリアプランや特技まで考慮した上で仕事をアサインしていくのが良い
  • ただ現実問題としては会社のフェーズによってこの自由度は下がっていくし、メンバーに変化を求めなければいけない場面もあると思う
  • その辺は現場でよしなにやる必要がある

5.3.3では、そのメンバーが自分の得意分野を活かしてコンフォートゾーンで取り組むのが好きなのか、知らないことにチャレンジして未知の領域に飛び出すのが好きなのか、きちんと認識すべきと書いてある。

  • その通り
  • 自分は変化を好む小さい組織に身を置くのが多いので、「変化をしていくのが楽しいはず」と言う先入観を持つ危険性がある
  • なんならそれが正義という雰囲気を作ってしまうリスクさえある
  • 自分がその危険性を持ってることを認識して、メンバーと関係値を作りながらどちらのタイプなのかを掘り下げていくことが必要だなと思った
Sota SugiuraSota Sugiura

7.2.2 スタイル、トーン、ジェンダーニュートラル

ジェンダーバイアスについて。その中でも職務記述書(Job Description)の書き方によって無意識に候補者を除外する可能性があるという事実について。

  • 恥ずかしながら知らなかった
  • 例えば要求スキルのリストが長いと、男性は60%を満たせば応募するのに対して女性は全てを満たさないと応募しないという行動が報告されてる
  • 自分の会社の現状と照らし合わせて、ギャップがあるところはフィードバックしたい
  • 詳しい内容は本を読んでくれ
Sota SugiuraSota Sugiura

8.2.1 良い退職理由

メンバーが退職した時に考えるべきこと。

その中で「リファレンスが必要かどうかを確認する」というのがある。

  • 自分はまだ直面したことない場面だが、これは是非やりたいと思った
  • 拗れた退職でない限りは去っていくメンバーに敬意を払いたいし、協力したい
  • マネージャーの立場だとリファレンスとして協力できるのは確かに、と思った
  • リファレンスが何かわからない人は「リファレンスチェック」でggってください
Sota SugiuraSota Sugiura

10.4.1 ダニング＝クルーガー効果

  • 感覚的にはあるあるだと思っていたが、そういう研究があったのは知らなかった
  • 折り合いの付け方は10.4.4 ダニング＝クルーガー効果と折り合いをつけるに書いてある
    • 特に特別なことは書いてないが自分の中に答えがない人は読むといい
Sota SugiuraSota Sugiura

12.2.3 常に必要十分

センシティブなデータを分類することで、共有方法を決めていく。
主に3つのカテゴリに分けられる。

  • 完全機密: 存在してることも知らせるべきでない
  • 密閉箱: 存在を知るべきだが、詳細は知るべきではない
  • 開放箱：詳細を知れるべき

これらの分類、共有方針を一貫性を持たせること。必要十分を共有することが重要。

  • この3つの分類はシンプルで運用しやすくていいフレームワークだなと思った
  • 特に密閉箱と開放箱の境目は大事
  • 3.1.3 一貫性を保とうの話とも通ずるところがある
Sota SugiuraSota Sugiura

13.2.2 Rモードを活かす

スケジュールとして、何もしない時間枠を確保する。デスクから離れてミーティングも入れない。

それにより創造性を担保しましょう(良いマネージャーは創造性も兼ね備えてる、という前提)。

  • あまり意識したことがなかったけど、確かにと思った
  • マネージャーはすることがたくさんあるし細かいボールも多い
  • 効率よく詰め込んでいくと余白時間はまず取れない
  • でも私たちはSoftware Engineerとして働いてた期間に余白の大切さを知ってるはず
    • お風呂や通勤中に解決したバグの数、思い出せないくらいあるよね
  • マネージャーでも余白があることが大切でない理由ないよねと素直に思った
    • マネージャーの仕事は事務仕事ばかりでない、抽象度の高い問題解決
Sota SugiuraSota Sugiura

15.1 インディビジュアルコントリビューター（IC）トラック

影響力とは実際、何を意味するのかを7つの項目を挙げて分解している。

  • ICが書いたソフトウェア
  • 正味の貢献
  • 周囲との協調性
  • メンターシップのスキル
  • 周囲のエンジニアに対する影響
  • アイデアの革新性
  • ビジネスの最終的な損益に対する影響力
  • いい分解、これは使いたい
  • いろんな会社で社内グレードや昇進・昇給をする基準として「社内外での影響力の大きさ」ってあるあるだと思う
  • あるあるだと思う割に明確に言語化されてることってあまりない
  • これは組織が言語化をサボってるというより、状況やチーム次第で影響力の定義が変わるからオフィシャルなルールとして定義しづらい、という実情があると思う
  • それゆえにManagerとして評価する立場になるのであれば自分の中ではある程度咀嚼して、言語化しておいた方がいい
  • そのとっかかりとしてこの7つの基準は良いと思う
    • あくまでとっかかり、ICのスキルやチームの状況、事業のフェーズによって変えていく必要がある
Sota SugiuraSota Sugiura

15.4.5 キャリアトラックがどのように報酬を決定するのか

キャリアトラックは報酬の増額に関わる昇進の境目を特定するぐらいで、明確に報酬を決定することはありません。

トラックにとってどう成長するかは、キャリアとして考えることです。

  • 最近、弊社の評価制度がアップデートされた
  • まさに評価とグレードを分けようという話
  • 弊社のアップデートの後にこの部分を読んだのでシンクロしててびっくりという感じ
  • 細かいところはこの章を読む必要があるけど、この形がある程度いろんなIssueを解消しながら運用できる制度かな、と個人的には思ってる
このスクラップは2022/12/04にクローズされました