内容紹介
IT業界でのマネージャーに向けた技術部門をリードするための本!
テックリードからCTOになった経験を持つ著者Camille Fournierが、自らの体験を元にエンジニアからテクニカルマネジャーになるための道のりの各ステージについて解説する書籍です。人のメンタリング(育成・指導)、テックリードとしてのプロジェクトの管理、複数のチームの管理、マネージャーを管理する方法、CTOの役割など、技術者からマネージャー、リーダーと立場が変わる際に求められる役割と考え方について紹介し、具体的なアドバイスを紹介しています。
このような方におすすめ
IT企業(大企業からスタートアップまで)に勤める開発者、マネージャ。
目次
詳細目次
推薦の声
まえがき
はじめに
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章 まとめ
索引
続きを見る