エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
- オライリージャパン (2018年9月26日発売)
- Amazon.co.jp ・本 (312ページ)
- / ISBN・EAN: 9784873118482
作品紹介・あらすじ
IT業界でのマネージャーに向けた技術部門をリードするための本!
テックリードからCTOになった経験を持つ著者Camille Fournierが、自らの体験を元にエンジニアからテクニカルマネジャーになるための道のりの各ステージについて解説する書籍です。人のメンタリング(育成・指導)、テックリードとしてのプロジェクトの管理、複数のチームの管理、マネージャーを管理する方法、CTOの役割など、技術者からマネージャー、リーダーと立場が変わる際に求められる役割と考え方について紹介し、具体的なアドバイスを紹介しています。
感想・レビュー・書評
-
マネジメントの基本、メンタリング、テックリード、人・チーム・複数チーム・複数管理者の管理、経営幹部、文化構築。
特にテックリードの立ち位置と人間像、チーム管理上のプロジェクトの進め方やメンバーの状態、意思決定など現時点でも共感して役立つものが多々あった。
守るべきは何か。
270冊読了。
詳細をみるコメント0件をすべて表示 -
良書である。エンジニアのキャリアプランについて、各ステップに応じて書かれた稀少な本。普段、自分の職位や上の職位の人に対して、感じたり思うこと言語化されていて、だよねぇと同意したり、グサッと刺さるナイフが飛んできたり。
「テストを攻略する時は教師向け教本を読め」みたいな話と同様で、上の立場の人たちの考えや悩みを見るのも、そこに至らない職位であっても大変役に立つ。というか、純粋に興味深く読める。
事例を交えて大変読みやすく書かれている一方、情報の密度は結構あるので、折に触れて読み直すと新たな発見があるタイプの本だろう。 -
筆者のソフトウェアエンジニアのキャリア経験を基に書かれた、技術系の新入社員から役員までにとって指標になりそうな書籍。
役職ごとに章立てし、その立場ごとの必要となる力や姿勢が示されているので、何度も読み返すことになりそう。
技術系のキャリアパスに絞って書かれている書籍は初めて読んだので貴重。 -
「エンジニアの」マネジメントキャリアパスについて論じるというありそうでなかった本。
インターンや新人メンバーのメンターから始まり、部下を持ち、経営層に至るまでの各ポイントで何を身に付けるべきか、何に留意するべきかが綴られる。
どの階層にも共通していえるのは以下。
・前の階層とはまったく違う期待がある
・よって、まったく未知の能力開発が必要となる
・コミュニケーションによる信頼関係構築は重要である
一部、日本の文化とは馴染まない部分や
近年の階層があまりない組織への適用という観点が深読みしないとでてこなかったので
その点は読み手であるマネージャーが自分なりに補完するとよい。 -
管理する対象の範囲に応じてどのような考え方をすべきか?
という観点でエンジニアリングマネージャーがキャリアップに応じて生じる問題へ対処する際の指針を提供してくれます。
オライリーから出版されている「エンジニアリングマネージャーのしごと」は、管理する対象を限定せず、求められるスキルや考え方を包括的に伝授してくれます。
合わせて読んで、実験を繰り返し、自分のスキルに落とし込んでいきたいと思いました。 -
エンジニアとしてのキャリアや目標が曖昧で、
なんとなくテックリードになりたいという思いだけがありました。
一度自身のキャリアプランや目標を定めたいと思い、本書を読みました。
本書では、エンジニアが管理を行う上でどのようことに注意し、
キャリアを積んでいけばよいかが書かれています。
またテックリードがどのような存在で何をすべきなのか
記述されており自身のキャリアを見つめ直す良いきっかけになりました。
管理する側だけでなく、管理される側としてもどうすべきか
ということが記載されておりますので、
エンジニアにはおすすめの1冊だと思います。 -
【書誌情報】
『エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド』
原書: The Manager's Path
Camille Fournier
武舎 広幸、武舎 るみ
及川 卓也 まえがき
2018年09月 発行
312ページ
ISBN:978-4-87311-848-2
本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT業界の管理職に求められるスキルを解説する書籍です。テックリードからCTOになった経験を持つ著者が、管理職についたエンジニアが歩むキャリアパスについて段階をおって紹介します。インターンのメンターから始まり、テックリード、チームをまとめるエンジニアリングリード、複数のチームを管理する技術部長、経営にかかわるCTOやVPと立場が変わることによって求められる役割について、それぞれの職務を定義しながらくわしく説明します。
さらに管理職の採用や評価、機能不全に陥ったチームの立て直し、管理職についてからの技術力の維持など、様々なハードルを乗り越えるための考え方やテクニックを多数紹介。技術系管理職の全体を視野に入れ、各段階で必要なスキルを学ぶ本書は、マネジメントのキャリアを志すエンジニア必携の一冊です。
〈https://www.oreilly.co.jp/books/9784873118482/〉
【目次】
推薦の声
まえがき
はじめに
1章 マネジメントの基本
1.1 上司に何を求めるか
1対1のミーティング
フィードバックと指導
トレーニングとキャリアアップ
1.2 管理のされ方
自分が何を望んでいるのかをじっくり考える
自分に対する責任は自分で負う
上司も人の子
上司は賢く選ぶ
1.3 自己診断用の質問リスト
2章 メンタリング
2.1 チームの新人に対するメンタリングの意義
2.2 メンターの務め
インターンのメンタリング
新入社員のメンタリング
技術あるいはキャリアに関わるメンタリング
2.3 すごい上司、ひどい上司──アルファギーク
2.4 メンターを管理するコツ
2.5 メンターの重要な心得
常に好奇心を絶やさずオープンな心で
相手の言葉をよく聴き、相手の言葉で話す
人脈づくり
2.6 自己診断用の質問リスト
3章 テックリード
3.1 優秀なテックリードなら必ず知っている、ある奇妙な「コツ」
3.2 テックリードの基礎知識
テックリードのおもな役割
3.3 プロジェクトの管理
3.4 プロジェクト管理の実務
3.5 決断の時──技術職を貫くか、管理職への道を選ぶか
私の想像していた「(部下をもたない)シニアエンジニアとしての
日々」
現実の「(部下をもたない)シニアエンジニアとしての日々」
私の想像していた「管理職としての日々」
現実の「管理職としての日々」
3.6 すごい上司、ひどい上司──プロセスの何たるかを心得ている上司と、
プロセスツァー
3.7 優秀なテックリードとは
アーキテクチャを把握している
チームプレイの大切さを心得ている
技術的な意思決定を主導する
コミュニケーションの達人である
3.8 自己診断用の質問リスト
4章 人の管理
4.1 直属の上下関係
信頼感と親近感の構築を
今後1ヵ月/2ヵ月/3ヵ月の計画を立てさせる
新人研修用のドキュメントを更新させてチームに対する理解を促す
自分の流儀や要望をはっきり伝える
新人からもフィードバックを得る
4.2 チームメンバーとのコミュニケーション
定期的な1-1は必要
1-1のスケジュリング
1-1にまつわる調整
4.3 1-1の進め方
TO-DOリスト型
キャッチアップ型
フィードバック型
経過報告型
相手を知るための機会
その他
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 管理者が担当するべき、より専門的なプロジェクト管理
管理者が担当すべき、より専門的なプロジェクト管理の経験則
5.8 自己診断用の質問リスト
6章 複数チームの管理
6.1 時間の管理──何はともあれ「重要な仕事」に照準を
6.2 意思決定と委任
「頻繁で単純」な仕事は委任
「頻繁でない単純」な仕事は自分で
「頻繁でない複雑」な仕事は有望な管理者の訓練の機会として活用
「頻繁で複雑」な仕事はチームの面々に委せてチーム全体の態勢を強化
6.3 やりにくい仕事──「ノー」にも言い方がある
「はい、それでですね」
ポリシーを決めておく
「私に『イエス』と言わせてみて」
「時間や予算を盾に取る」と「今すぐは無理」
手を組む
ずるずるべったりは禁物
6.4 コードの作成以外のITスキル
6.5 直属の開発チームの健全性を見きわめる
コードリリースの頻度
コードへのチェックインの頻度
インシデントの発生頻度
6.6 すごい上司、ひどい上司──「イングループ」を作りたがる上司と、チームプレイを重んじる上司
6.7 無精と短気の効用
6.8 自己診断用の質問リスト
7章 複数の管理者の管理
7.1 スキップレベルミーティング
7.2 部下である管理者たちに責任を課する
7.3 すごい上司、ひどい上司──「ノー」と言える管理者とイエスマン
7.4 新任管理者の管理
7.5 ベテラン管理者の管理
7.6 チーム管理者の中途採用
7.7 機能不全に陥った組織の「デバッグ」の基本
仮説を立てる
データをチェックする
チームを観察する
質問をする
チームの人間関係をチェックする
支援に乗り出す
常に好奇心を失わない
7.8 期日の見積もりと調整
7.9 やりにくい仕事──ロードマップにまつわる不確実性への対処
ロードマップにまつわる不確実性に対処する戦術
7.10 技術力の点で時代遅れにならないためには
技術的投資の監督
情報収集のための質問
技術と事業のトレードオフの分析と説明
明確で詳細な要求を
経験で培った独自の勘を拠り所に
7.11 自己診断用の質問リスト
8章 経営幹部
8.1 技術系の経営幹部の肩書と役割
8.2 技術担当バイスプレジデントとは?
8.3 CTOとは?
8.4 優先順位の変更
8.5 戦略の策定
広範な調査と熟慮
調査の結果と自分なりのアイデアのひも付け
技術戦略の草案作り
経営陣特有の流儀
8.6 やりにくい仕事──悪いニュースを伝える
8.7 他部門を統率する幹部仲間
8.8 反響
8.9 すごい上司、ひどい上司──恐怖で支配する上司と、信頼を基盤に導く上司
「恐怖の文化」を改めるには
8.10 トゥルー・ノース(True North)
8.11 推薦参考書
8.12 自己診断用の質問リスト
9章 文化の構築
9.1 自分の役割の見きわめ
9.2 会社や担当部署の文化の創成
9.3 コアバリューの活用
9.4 文化に関するポリシーの策定
9.5 キャリアラダー作成のコツ
9.6 職能の枠を超えたチーム
「職能の枠を超えたチーム」の作り方
9.7 作業プロセス
9.8 意思決定のプロセスから個人的要素を排除する──実践的アドバイス
コードレビュー
稼働停止の事後検証
アーキテクチャレビュー
9.9 自己診断用の質問リスト
10章 まとめ
索引 -
> 構造やプロセスといった概念は...「無意味」、最悪の場合「有害」と映ることが多いようです。...私はこうした「構造」を疑問視する人を相手に議論するときには...「構造」そのものではなく「学習」を、「プロセス」そのものではなく「透明性」を全面に押し出して話を進めるのです。
構造そのもの、プロセスそのものに価値があるからではなく、成功も失敗もひっくるめて経験から学びたいから、..成功例を共有し、失敗例から得た教訓を..共有したいからといったぐらいです -
マネジャーが視野に入ってきたテックリードという今の立場で必要な部分を読んだ。実際にマネジャーになったときには、4章以降を読み返したい。
Linkedinのプロフィール作成や、転職の面接試験にあたって、自分がどのようなマネジメント経験とスキルを持っているかを棚卸して説明するのにも、本書は活用できそうだと感じた。
3章 テックリード
今の立場として読んだ。
・テックリードは、ソフトウェア開発者兼チームリーダーという役割を果たす。自分ひとりが担当する作業の計画・調整から、プロジェクト全体の計画・調整と主導へと視点を変えなければならない。
・優秀なテックリードの特質として、アーキテクチャを把握していること、技術的な意思決定を主導(独断ではなく関与)することが挙げられる。
※これを読んで、ここ10年の自分の経歴はテックリードであったのだと認識できた。
4章 人の管理
5章 チームの管理
次のステップへの備えとして読んだ。
・勤務評価の時期を待たずに、常日頃から「継続的なフィードバック」をすることが重要。日頃からチームメンバーを観察し、長所や功績を見つけてあげる。肯定的なフィードバックを続けていると、否定的なフィードバックに耳を傾けてもらいやすくなる。
・ピーターの法則を回避するために、チームメンバーをある職位に昇進させる以前から、その職務を課す。そのために必要であれば、チーム内での仕事の割り振りを再検討する。
※その人に昇進後の職務への適性があるかを判断するためと理解した。今の上司が私に対してやっていることが、まさにこれだと納得した。
・チームメンバーが適切な判断を下すためには、目標だけでなく、その目標がなぜ設定されたのかというコンテキストあるいは目的を把握している必要がある。
6章 複数チームの管理
役立ちそうなところを拾い読みした。
・委任するかの判断基準
頻繁で単純な仕事は委任。
頻繁でなく単純な仕事は自分で。部下への説明に時間を取られるくらいなら、自分でやってしまった方が手っ取り早い。
頻繁でなく複雑な仕事は、マネジャー候補の訓練の機会として活用。勤務評価を書く際に見習いとして同席させたり、人材募集の計画立案時に意見を言わせたりといった工夫により、有望な後輩に伝授する。
頻繁で複雑な仕事は、有望なチームメンバーの育成に活用。このような機会を逃さず、十分に時間を割いて、マネジャーがその場にいなくても複雑な仕事を引き受けて遂行できる人材を育成する。
・「はい、それでですね」構文は、ノーと言いづらい場面で役に立つ。「はい」と肯定で受けながら、優先度を見据えた現実的な交渉に持ち込むことを狙う。例えば、別プロジェクトの締め切りを遅らせるなど。エンジニアは「いいえ、それは不可能です」と答える習慣がついているため、このテクニックが使えると、他から一歩抜きん出ることができる。 -
2023年10月1日読了。IT技術者が年次を重ね管理職となりテックリード・CTOなど役職を担うとき、どうあるべきか?どのような課題がありどう取り組むべきか?を説明する本。技術一本やりできたメンバーがマネージャー就任を打診され悩んだり断ったり挫折したりするケースは多々あると思う、課題にジャストフィットした本と感じた。「管理職になってもコーディングは続けるべし(もちろん時間は減るが)」というメッセージには「確かに…」と言うしかないな。結局、技術者だろうとメンバーだろうと仕事する以上「コミュニケーション」からは逃れられず、誰かがやんないといけないポジションでもあるわけで、なった以上はコミュ力を全面展開して視野を広く取り組むしかない、ということなのだろうな。著者は女性だがずっと男性と思い込んでいた、というのは私個人の「IT管理者かくあるべき」というバイアスによるものか、反省。