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

Sota Sugiura

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

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

Sota Sugiura

1.1 最初の週を始める

インポスター症候群

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

Sota Sugiura

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

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

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

Sota Sugiura

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

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

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

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

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

Sota Sugiura

2.1.1 ツール１：カレンダー

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

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

Sota Sugiura

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

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

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

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

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

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

Sota Sugiura

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

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

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

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

Sota Sugiura

3.1.1.1 適切な媒体を選ぶ

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

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

Sota Sugiura

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

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

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

Sota Sugiura

3.1.1.3 2回測って1回切る

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

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

Sota Sugiura

3.1.3 一貫性を保とう

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

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

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

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

Sota Sugiura

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

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

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

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

フィードバックを伝えるのに最良かつ簡潔なアドバイスは徹底的な本音

話す相手を個人として気遣いコミュニケーションをとる

考えていることを率直に直接伝える

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

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

Sota Sugiura

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

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

説明責任: タスクを求められる品質で完了させる責任を持つ

実行責任: タスクを実際に自分で行う

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

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

Sota Sugiura

3.2.3 委譲の物差し

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

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

Sota Sugiura

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

全面同意な内容。

やるべきこと

委譲すること

スタッフにとってチャレンジになるくらい委譲すること

タスクの重要性に応じて適切なコントロールを保持すること

やってはいけないこと

丸投げ

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

渡したタスクを取り返すこと

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