「エンジニアのためのマネジメントキャリアパス」を読んだ
自分のキャリアパスをどうするかを最近とても悩んでいる。今まではマネジメントは絶対に嫌だー！と思っていたんだけど、ここ数年マネジメントをすることが増えて意外に楽しいかも？マネジメントの道もありなのかも？と思えてきた。
エンジニアのマネジメントの知識を得たくて、本書を読んでみた。
目次
- 1章 マネジメントの基本
- 1.1 上司に何を求めるか
- 1.2 管理のされ方
- 2章 メンタリング
- 2.1 チームの新人に対するメンタリングの意義
- 2.2 メンターの務め
- 2.3 すごい上司、ひどい上司
- 2.4 メンターを管理するコツ
- 2.5 メンターの重要な心得
- 3章 テックリード
- 3.1 優秀なテックリードなら必ず知っている、ある奇妙 な「コツ」
- 3.2 テックリードの基礎知識
- 3.3 プロジェクトの管理
- 3.4 プロジェクト管理の実務
- 3.5 決断の時──技術職を貫くか、管理職への道を選 ぶか
- 3.6 すごい上司、ひどい上司──プロセスの何たるか を心得ている上司と、プロセスツァー
- 3.7 優秀なテックリードとは
- 4章 人の管理
- 4.1 直属の上下関係
- 4.2 チームメンバーとのコミュニケーション
- 4.3 1 -1の進め方
- 4.4 すごい上司、ひどい上司──細かすぎる上司と、 任せ上手な上司
- 4.5 効率よく仕事を任せるために──実践的アドバイス
- 4.6「継続的なフィードバック」の文化をチームに根付
- 4.7 勤務評価
- 4.8 キャリアアップの取り組み
- 4.9 やりにくい仕事──成績不振者の解雇
- 4.10 自己診断用の質問リスト
- 5章 チームの管理
- 5.1 ITスキルの維持
- 5.2 機能不全に陥ったチームの「デバッグ」の基本
- 5.3 盾になる
- 5.4 チームの意思決定を主導するコツ
- 5.5 すごい上司、ひどい上司──「対立を何とか手なず けられる上司」と「対立を避けて通りたがる上司」
- 5.6 やりにくい仕事──「チームの結束を乱す人」へ の対処
- 5.7 管理者が担当するべき、より専門的なプロジェクト 管理
- 6章 複数チームの管理
- 6.1 時間の管理──何はともあれ「重要な仕事」に照 準を
- 6.2 意思決定と委任
- 6.3 やりにくい仕事──「ノー」にも言い方がある
- 6.4 コードの作成以外のITスキル
- 6.5 直属の開発チームの健全性を見きわめる
- 6.6 すごい上司、ひどい上司──「イングループ」を 作りたがる上司と、チームプレイを重んじる上司
- 6.7 無精と短気の効用
- 7章 複数の管理者の管理
- 7.1 スキップレベルミーティング
- 7.2 部下である管理者たちに責任を課する
- 7.3 すごい上司、ひどい上司──「ノー」と言える管 理者とイエスマン
- 7.4 新任管理者の管理
- 7.5 ベテラン管理者の管理
- 7.6 チーム管理者の中途採用
- 7.7 機能不全に陥った組織の「デバッグ」の基本
- 7.8 期日の見積もりと調整
- 7.9 やりにくい仕事──ロードマップにまつわる不確実 性への対処
- 7.10 技術力の点で時代遅れにならないためには
- 8章 経営幹部
- 8.1 技術系の経営幹部の肩書と役割
- 8.2 技術担当バイスプレジデントとは？
- 8.3 CTOとは？
- 8.4 優先順位の変更
- 8.5 戦略の策定
- 8.6 やりにくい仕事──悪いニュースを伝える
- 8.7 他部門を統率する幹部仲間
- 8.8 反響
- 8.9 すごい上司、ひどい上司──恐怖で支配する上司 と、信頼を基盤に導く上司
- 8.10 トゥルー・ノース（True North）
- 9章 文化の構築
- 9.1 自分の役割の見極め
- 9.2 会社や担当部署の文化の創成
- 9.3 コアバリューの活用
- 9.4 文化に関するポリシーの策定
- 9.5 キャリアラダー作成のコツ
- 9.6 職能の枠を超えたチーム
- 9.7 作業プロセス
- 9.8 意思決定のプロセスから個人的要素を排除する ──実践的アドバイス
- 10章 まとめ
1章 マネジメントの基本
1章ではいきなりマネジメントとは〜という説明が始まるわけではなく、部下の立場から見てどんな人ができる上司なのかが紹介されている。
この章では自分自身のマネジメントのやり方を教えてくれていると思った。自分で考えて動く方法、そしてどのように上司に助けを求めたら良いかが書かれている。
自分のマネジメントさえもできなければ、他の人のマネジメントもできるわけないもんな。
2章 メンタリング
2章はメンタリングの話。冒頭の「エンジニアは成り行きで誰かを指導する立場に立たされる」の言葉には心当たりがありすぎる。
メンターの心得の1つとして傾聴のスキルが紹介されている。あと人脈作りの重要性も。 メンタリングをすることになったら、そのメンタリングの目標や期待をはっきりとさせる必要がある。
3章 テックリード
3章はテックリードの話だ。テックリードはエンジニアが担う職責群と説明されている。
テックリードは技術的な意思決定だけでなく、メンバーの指導や育成役も果たすものであると。そしてチーム全体の生産性が上がるように全力を尽くさなければいけない。
テックリードはそのチームで一番経験豊富なエンジニアがなるものと短絡的に考えるのは間違いだと書かれている。テックリードになると技術的な専門知識だけではなく、対人能力がより求められるようになり、異なる分野のスキルが必要になってくるからだ。
異なる分野のスキルとして、プロジェクト管理のスキルも必要になってくるとも書かれている。なのでこの章ではプロジェクト管理についても説明がされている。
テックリードとは？の答えを一文で表現されている定義も紹介されている。
［テックリードとは］（ソフトウェアの）開発チームに対する責任を担い、最低でも自身の職務時間の3割はチームと共にコードを書く作業に充てているリーダーのこと。
やるべきことが技術以外にも増えてきたが、上記に書かれているとおりテックリードはコードも書き続けている。自分が担当するシステムのアーキテクチャを十分に理解する時間を取るべきという言葉にハッとした。理解できていなければ技術的な意思決定もできるはずない。
4章 人の管理
4章は人の管理についてだ。ロールとしてはマネージャーにあたると思う。
管理者になった時にはチーム全体を運営していくスキルと、各メンバーを管理するスキルを身につけていくことになる。
その時にまずは各メンバーとの関係を考えてみるところから始めると良いと書かれている。
ここで1on1が登場してくる。1on1についていろんなtipsが書かれているので、1on1を既にやっている方も読んでみてほしい。
また今までになかった項目として「勤務評価」について書かれている。テックリードとの大きな違いの一つではないだろうか。
5章 チームの管理
5章からはチームの管理だ。自分が今まで経験した中だと、他のロール（マネージャー）と兼務されている気がする。本ではエンジニアリングリードと紹介されている。
エンジニアリングリードの説明は以下だ。
もっとも価値のあるプロジェクトを見きわめ、そうしたプロジェ クトに自身のチームを集中的に従事させる権限を有する。そのための取り組み の一環としてエンジニアリングリードはプロダクトリードと緊密に協力してプロジェクトの範囲を調整し、技術的成果物を確実に構築する。また、エンジニアリングリードはチームに必要な人数を確認し、その確保のための計画立案と人材募集を行う権限も有する。
チーム管理をするには、技術、戦略、リーダーシップの領域に目を向けてほしいと書かれている。
ここでいう技術とはなんだろう？本章ではスキルの維持と書かれている。頑張って（ここでいう頑張っては主に時間の確保になってくると思うが）コードを書いて、エンジニアの勘が鈍らないようにしなければいけない。
また、ここでもプロジェクト管理のスキルが出てくるが、チームの管理者はより上級のプロジェクト管理のスキルが必要になってくる。自分のチームがそのプロジェクトをこなせるか、プロジェクトの作業量はどれくらいか、プロジェクトがこなせるメンバーが十分揃っているか。
プロジェクトが実現できるか、実現させるためには何が必要かを判断しなければいけないのだ。
6章 複数チームの管理
この章からは複数のチームの管理の話だ。ロールは技術部長に相当する。 技術部長のジョブディスクリプションの例の紹介で、技術部長について以下のように書かれている。
技術部長は技術チームの重要な職務に関する責任を担い、通常、複数の製品分野または複数の技術部署のエンジニアを統率する
この段階になってくるとコードを毎日書く必要はない状態になってくる。ただし、この段階に至るまでに十分にコードを書く経験はすべきだとも書かれている。
技術部長は成果物が出せるように開発やプロセスの評価、改善をする努力をしなければいけない。また、技術や組織の質の向上のためにチームに有用な目標を立てさせる責任を負っている。
あと「無精と短期の効用」に出てくる以下の考え方がとても好きだ。
「帰宅できるよう、集中して仕事をする。そして帰宅を奨励する。 そうすれば皆、絶えず集中せざるを得なくなる」─これが「できるチーム」が外さない、迅速化のツボです
7章 複数の管理者の管理
この章では複数の管理者の管理の話だが、職務内容は複数チームの管理と大きく変わらないと書かれている。大きな違いは「責任の大きさ」だと。
この段階は経営者に至る道の入り口になってくるので、新たなスキルの習得が山ほど必要になってくる。
これまではチーム全体を管理していたものが部署全体を管理することになってくる。今までと異なるのは自分と相手やチームの距離が遠くなるということ。間接的な管理になるので、実態が分かりづらくなるのだ。 とはいえ自分はチームの細かな問題に対応するのではなく、もっと大局的な問題に対応していかなくてはならない。
そのためには自分が務めを果たせるように、管理者たち自身が務めを果たせるようにならなければいけない。本章ではその支援の仕方が紹介されている。
また、距離が遠くなる点については、1on1を開くなりランチに行くなり、良好な関係が築けるように行動をしていくといいことも紹介されている。
8章 経営幹部
8章は経営幹部の話だ。CTOや技術担当VPなどの技術部門の頂点にあたる。
今までと異なる点は、経営幹部としての役割を果たすこと、そして会社が成功していくための組織を生み出していくことである。
何をするべきか、どの方向へ進むべきか、どう考え、どう行動するべきか、何に重きを置くべきかを会社に助言していく必要がある。
9章 文化の構築
最後に文化の構築について書かれている。技術系の経営幹部の職責の一つは文化の構築だと。
複雑な意思決定が必要な状況では、文化的価値観がチームを一致団結して、決断を下させることができる。だから会社が成功するためには文化の構築が必要なのだ。
感想
マネジメントというものを管理される側も管理する側の両方から考えることができた本でした。
どの段階の立場でも信頼関係をいかに築いていくかという話があり、仕事をしていく上でのベースはやはり人なんだなーと感じた。
マネジメントの辛いところをありのままに正直に辛いよって書かれているのがよかった。あーやっぱり辛いんだ、自分が辛いって思ってるだけじゃないんだって思えたので。
マネジメントなんも分からんという状態から、なんとなく分かるまで進めた気がする。自分が既に経験しているロールでも自分ができていないことの発見もできてよかった。
