読書メモ: エンジニアのためのマネジメントキャリアパス (1 - 6 章)
1 〜 6 章の読書メモ。
7 〜 10 章はまたの機会に読みます。
書籍名
エンジニアのためのマネジメントキャリアパス - テックリードからCTOまでマネジメントスキル向上ガイド
著者
Camille Fournier [著]
武舎 広幸 / 武舎 るみ [訳]
及川 卓也 [まえがき]
書籍リンク
https://www.oreilly.co.jp/books/9784873118482/
おすすめ度
★★★★☆: できれば読んでおきたい
読書メモ
1 章: マネジメントの基本
1-1 のミーティングには目的が 2 つ
ひとつはあなたと上司との間に人間的な「つながり」を作ること
第 2 の目的は「要検討事項について上司と 1 対 1 で話し合う定期的な場を設けること」
1 on 1 の時間は大切にしていて、特にひとつめの人間的なつながりを作ることを重要視していると思う。
雑談 30 分で終わってしまうこともあるけれど、さほど問題が発生していなければ個人的にはそれでも良い派。
自分の正すべきところ、伸ばすべき能力に関する建設的な助言など、フィードバックは積極的に求めましょう。それが得られたら、たとえ異論があっても感謝の念をもって傾聴すべき
学校と違って日常的にフィードバックをもらえる機会は少ないので、自分自身を少しでも良くしていくためには重要。
ドクターメイトでは 3 ヶ月に 1 度、グループオーナーとの面談でこれらのフィードバックをもらう機会が用意されていて、すごく良い仕組みだと思う。
2 章: メンタリング
インターンのメンタリング
まず準備する必要があるのは期間中インターンにやってもらうプロジェクト
プロジェクトを準備してあげないとインターンは何をやったらよいのか途方に暮れて、「恐ろしく退屈な夏」に
研修が始まって最初の 2、3 習慣、インターンに手慣らしをしてもらう
一昨年、自分がインターン生を受け持ったときに何をしてもらうかで結構迷ったんだけれど、
初めに Next.js で簡単な ToDo アプリを作ってもらうプロジェクトを用意した。
単に作るだけだと面白くないので、Figma でデザイン起こしとプロトタイプ作成も経験してもらった。
いま考えると結構大変だった気もするけれど、みんな優秀だったのもあって何とかなってたなぁ。
最終的には Next.js + Firebase Realtime Database 構成でチャットツールを作成するプロジェクトを立ち上げて、
自分が少しフォローを入れながら完成させるところまで到達できたので、良い 4 ヶ月だったかな。
傾聴
「傾聴」とは、指導相手が「口にする言葉だけを耳で捉える行為」ではない
これすごく大事だと思う。
声の抑揚とか顔の表情、ジェスチャーとかで伝わってくる些細な情報で汲み取れる要素があって、
ここにシグナルが隠れていることが多いので、それを見逃さないように高い集中力を持って聴く。
アルファギーク
人間の特性の中では何よりも知性と技術力を重んじ、その 2 つの点で抜きん出た者こそが意思決定者となるべきだと固く信じています
アルファギークでなくとも、こういった思考に陥らないように気をつける。
3 章: テックリード
「テックリードには、誰よりも経験豊富なエンジニアを任命するべきだ。最高に複雑な機能でも難なくコード化できるエンジニア、誰よりもすばらしいコードが書けるエンジニアを」という勘違い
技術的なプロジェクトのリーダー役を果たし（個人ではなくチームという）より大きなスケールで自身の専門知識を駆使してチーム全体の向上を図る、という立場にあります
本書では極端な例を挙げているけれど、あながちそういった思考のもとジャッジしているチームや組織が多いのも事実。
とにかく特定のプロセスや手順、手法を崇め奉り、その手法を正しく実践しさえすればチームの抱える難題は漏れなく解決できると信じて疑わない人
「スクラムを導入すれば開発は上手く行く」と思っている人も多い。決して銀の弾丸ではなくて、それを適切なタイミングで導入して、運用できるチームを醸成しないことにはスクラムも腐る。
4 章: 人の管理
1-1 の議事録は共有ドキュメントの形で作成し、管理する
これも結構大事。振り返ったときに、あのときこんな話したな〜ってなるし、1 on 1 の中で出てきた課題をどのくらい改善できているかも把握しやすいと思う。
優れたリーダーとは任せ上手
耳が痛い。何でもかんでも自分でやろうとしない。
エンジニアの苦戦やプロジェクトの停滞を前にして、その主な責任をエンジニア本人やプロジェクトの管理者など個人に問うてしまうと、その人がそれを批判と受け取り、その後あなたに報告するどころか、さらなる批判を避けたいがために、手遅れになるまで報告しない
上手くいかないこと / 失敗すること = 悪という構図が根付いてて、それによって自身の評価が落ちると思い込んでいる可能性がある。
チームメンバーが上手くやっているように見えてくると尚更で、自分一人だけがダメなんじゃないかと感じていると、かなり危険。
チームや組織で上手くいったこともいかなかったことも等しく共有できる文化が良い、と個人的な経験では思っている。
チーム開発であれば、個人の献身や努力に任せるのではなくチームで取り組める仕組みを作るべき。
5 章: チームの管理
IT スキルの維持
ボトルネックや問題点はメトリクス分析の結果を見ればわかるでしょうが、管理者自身がコードの作成に積極的に関与していれば、はるかに容易に察知できます
自分自身がチームメンバーとして開発に従事するときに、管理ポジションの人がプロダクトコードや技術に疎いのはちょっと怖いな～と思ってしまう。
プレイングマネージャーとまではいかなくても、いま我々が提供しているサービスやプロダクトの構造を理解して、デリバリにどのような影響を及ぼしているかは知っておきたい。
管理者が目指すべきは「心理的安全性」
人間関係が良好なチームは雰囲気も明るく、結束力も強まりやすく、しかるべき成果を上げられる可能性も高い
踏み込みすぎは良くないけれど、多少なりともプライベートの話ができるような関係性を築いておくのは良いと考えている。
ミーティングの時間になったら、すぐ本題に入るのではなく軽くアイスブレイクを入れてから始めるといった工夫はするようにしている。
納期間近での管理者の努めは「ノー」と言うこと
なんでもかんでも「はい、できます」は簡単にチームが崩壊する。
6 章: 複数チームの管理
「重要と緊急の違いを見抜く」
『重要だけれど緊急ではないこと』『重要ではないが緊急であること』のバランスは大切だと思う。
特に後者は目が行きがち。
「無精」「短気」「傲慢」はエンジニアの三大美徳
「プロジェクトに関してはせっかちと無精を発揮」―――これは管理者がぜひとも押さえておかなければならないツボです
これはちゃんとできるようになりたい。
様々な要素が絡み合う中から、短い時間で焦点をしっかりと見極められるようにする。
帰宅してから夜間や週末に部下にメールを送るのも一切やめましょう。無理矢理にでも仕事から自分自身を切り離すことが、あなたの精神衛生上、不可欠なのです
アルティメットわかりみしかない。