『エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド』を読んだ

エンジニア職において、ポジションや役割ごとの責務をあらためて理解するために手に取った。

とてもわかりやすい図があったので引用させていただく。

【読んでみた】エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
https://www.nogawanogawa.work/entry/management_career

読後まとめ

各役割などをまとめる

• メンター
  • メンタリングプログラムは投資
    • メンターの如何によってその会社のオンボーディングの質が決まるため重要
  • メンター自身にとっても、あまり気負わずマネジメント経験が積める機会となる
• テックリード
  • 複数人が担う職責群
  • 部署間をまたぐコミュニケーションスキルや、マネジメントスキルも重要な、エンジニアチームの技術上のリーダー
  • チーム全体の向上を図る立場
    • チームスキルの向上、障害物の除去、各人にとって納得できる視点の提供など
• 人の管理
  • 定期的な1on1による関係性の構築とそのドキュメント化
  • 各メンバーの得意不得意の見きわめと強化
  • キャリアアップ、進捗状況、改善領域、功績の報奨などのフィードバック
• チームの管理
  • プロダクトロードマップと、技術的詳細に関わる作業を推し進める責務がある
    • チームの意思決定を主導する権限があるのみ
  • チームの意思決定やプロジェクトの結果を振り返り、学習を蓄積する
  • 手早い即席の見積もりと、具体的なプロジェクト計画の立案の両方こなせることを期待される
• 複数チームの管理
  • 直属のテックリードが3,4人いる技術部長
  • 重要と緊急の違いを見抜き、バランスをとりつつ組織的にこなしていく
  • 単純かつ頻繁ではない仕事は自ら巻き取り、何を委任するか判断する
  • 直属の開発チームの健全性を見きわめる
• 複数管理者の管理
  • 複数チームの健康度に目を光らせ、目標設定を支援する
  • 問題を丹念かつ先を見越して掘り起こす
  • 機能不全に陥った組織をデバッグする
• 経営幹部
  • 情報を収集共有しながらときに注意喚起し、不確実な状況でも進路を決める意思決定をしながら、自らロールモデルを示す
  • チームが持続可能かつ効率的なやり方で極力最善の判断を下していける後押しする
  • CTOは広範な戦略と社内での技術部門の位置付けにフォーカスし、VPは管理責任を負いながらアイデアの実現にフォーカスする
  • CTOは技術部門の最上位ランクではないし、技術系の役職ではなく、第一に経営幹部たるべき
  • 影響力のある立場となることを理解して行動しロールモデルとなる
• 文化の構築
  • 文化とはあるコミュニティで共有されている暗黙のルール
    • インフラと同様にチームの成長発展に必須のもの
  • 構造が重要なのではなく学習が重要、プロセスを守ることが重要なのではなく透明性が重要
    • 無構造の価値と無構造での損失を天秤にかけて判断していく
  • 構造は長期視点での課題解決をスケールさせるためのもの
    • 正常に作動する単純なシステムから徐々に進化していく
  • 作業プロセスは、チームメンバーが完璧に従わなくても価値の得られるリスクマネジメントシステム

推薦の声

• 技術系管理者の職責を詳細に解説している
• 「一介のエンジニア」から始めて、キャリアの梯子を登りながら解説を進めていく
• 経験年数に関わらずあらゆる管理者に大変有益

まえがき

• エンジニアリングマネージャーはエンジニアリング組織を健全に発展させるという役割
  • ソフトウェア開発に対して技術を駆使し難局を打開していくのと共通する面白さがある
    • 人嫌いには向かないが、もっと多くの人に興味を持たれていいキャリアパス
• 日本はJD（Job Description）を明示していないことが多い
  • メンバーシップ型雇用
    • 営業マネージャーが技術部幹部になることもある
• JD型雇用
  • キャリアラダーが重要
    • 幹部でも技術力が求められる
• 「話してみる」というテクニック
  • ただオープンドアポリシーは機能しない
    • 仲のいい人はさらに仲良く、疎遠な人はさらに疎遠となる
• 評価と採用
  • コアバリューや行動指針を評価と結びつける
    • 評価基準とする
      • さらに採用基準とする
• 製品や事業の成功に責任を持つのがPMで、それを支える組織にコミットするのがEM
  • 車の両輪
• エンジニアリングマネジメントはソフトウェア開発に似ている
  • デバッグに似ている
  • ソフトウェア開発も昔は工学とは程遠い職人芸だった
    • その後、設計パターンであるデザインパターンやアンチパターンも広まった

はじめに

• 「自分の経験、助言、提言とそれを伝えたい自分」と「創造的なはけ口を求めている自分」が本書という形で結実した
• 技術的な仕事と管理の仕事の交差点で、難問が多い
• 技術系管理者は、エンジニア経験ののち管理者の役割を引き受けている
  • そうあるべき
    • 現場の実践で身につけた専門知識と勘が信頼度を高めるから

本書の構成

1. 管理術のABC：部下としてどう動くか、上司に何を期待すべきか
2. メンター
3. テックリード
4. 人の管理
5. チームの管理
6. 複数チームの管理
7. 複数の管理者の管理
8. 経営幹部
9. 文化構築、変更、改善

1: マネジメントの基本

• 上司に何を求めるか
  • 無策の策を取る上司も悪くはない
    • 他の選択肢にもっと悪いものがあるから
      • 一切のフィードバックやヘルプなしに成果を否定する上司
      • マイクロマネジメントして権限を一切移譲しない上司
      • 普段は任せっきりなのにいきなり爆発する上司
    • ただ、よりよい選択肢はある
      • フォーカスすべき要点に気づかせてくれる上司
  • 1on1
    • 人間的なつながりを作る方法
      • お友達関係になるのではない
        • 人間性を疎外しない
          • 弱みを見せられる状況を構築していくことで心理的安全性が高まる
    • 要検討事項について上司に1対1で定期的に話し合える
      • 現状把握だけならチャット共有する
        • 空いた時間で別のトピックを話し合うようにする
  • フィードバックの提供
    • 失敗や成功に対するフィードバック
  • トレーニングとキャリアアップ
• 管理のされ方
  • 何を望んでいるのか
    • モヤモヤの時期には本当は何をしたいのかをしっかり考える
  • 望むものを表明する
  • 立場が上がるにつれ問題点の報告ではなく、解決法の提案を求められるようになる
• 自己診断用の質問リスト
  • 「できる上司」とはどんな行動をとり、どんな業績を上げる人か答えられるか
  • 1on1の議題は上司が提案しているか、現況報告だけになっていないか
  • 私生活の重大な出来事を上司に抵抗なく話せるか、それは理解されるか
  • 上司が適切なフィードバックをおこなっているか、不適切か不十分あるいは一切ない関係か
  • 仕事上の今年の目標を立てるときに、上司は手助けをしてくれたか

2: メンタリング

• メンタリングの意義
  • 指南するメンターがいることで、新人が自分でも活躍できると理解できる
    • 無能なメンターだと有望な新人が辞めたり転職したりもする
  • メンターの務め
    • メンターはあまり責任を負わずにマネジメント経験を積める機会
    • インターン
      • 伴走して2~3日で完成しそうな機能を一通り流してもらう
        • 明確、具体的で、急を要しないもの
      • メンターとしては傾聴スキル、明確な伝達スキル、対象への反応適応スキルが養われる
    • 新入社員
      • オンボーディングとして非常に重要
      • メンターにとっては新人のフレッシュな目を借りて自分の会社を見つめ直す好機となる
        • 不文律を含めてどんなルールがあるか
          • 気づくと明確に説明できるようになる
    • メンタリングに対する期待や目標を明確に示すことが大切
• アルファギーク
  • いわゆるbrilliant jerk
    • メンターになってから発現する人も多い
• メンターを管理するコツ
  • 計測する
    • 計測可能で明確なゴールを設定する
      • メンタリングプログラムは投資
        • 社員の人脈の拡大
        • 新人研修の迅速化
        • インターン生が増える
  • 落とし穴
    • メンタリングは低レベルな感情労働ではない
    • タイプや相性を固定化する
      • 性別や人種など
• メンターの重要な心得
  • 新しい視点という想像力を得ることができる
    • 普段は気づかない隠されたパターンが見えてくる
  • 相手の言葉をよく聴き、相手の言葉で話す
  • 人脈を作る
• 自己診断用の質問リスト
  • インターシップ制度があり、メンターになることを希望することができるか
  • 新人研修にメンターを付けているか、メンターになることを希望することはできるか
  • すばらしいメンターはどんなことをしてくれる人か
  • メンター/メンティーにおいて成果が上がらなかったケースとその教訓はあるか

3: テックリード

• テックリードはエンジニアチームの技術上のリーダー
  • エンジニアとしての腕
  • 部署間をまたいだコミュニケーション力
  • 優先順位を付ける力
• 複数人が順次一時的にそのすべてを担う職責群
  • ひとりが長期的に就く職位というわけではない
    • ランクのひとつではない
• チーム全体の向上を図る立場
  • 必ずしももっとも経験豊富、優秀なエンジニアというわけではない
    • 対人スキル、プロジェクト管理スキルも重要だから
  • チームのスキルの向上
  • 障害物の除去
  • 各人にとって納得できる視点の提供
  • 自分個人としてのプログラミングから、チーム全体のニーズへの対応に変化する姿勢
• テックリードの基礎知識
  • 主な役割
    • システムアーキテクトとビジネスアナリストの役割
      • プロジェクトを推進するため、常に対局的な視点を失わないこと
        • 見積もりや作業指示の土台となる一定の骨組みを作ること
    • プロジェクトプランナーの役割
      • 作業をデリバリ可能な単位に大まかに分割する
        • 参考にすること
          • そのシステムの事情通からの助言
          • 影響範囲を知っている人からの助言
    • ソフトウェア開発者兼チームリーダーの役割
      • コードは書くべきだが自分でやり過ぎは禁物
        • 他のメンバーに任せられる作業を見つける
• プロジェクトの管理
  • アジャイルであっても完遂にかかる時間の見積もりは必要
    • 専任のプロジェクトマネージャーに頼るのは好ましくない
• すごい上司、ひどい上司
  • プロセスツァー（process czar）：特定のプロセスや手順、手法の信奉者
    • ケースバイケースというゆらぎを許容しない
  • 卓越した指導者ち共通する最大の資質はコミュニケーション能力
    • 文章力も読解力もある
    • 人前で話すことにも長けている
    • 復唱、言い換え要約のスキル
• 自己診断用の質問リスト
  • テックリードという職があるか。JDがあるか。なければどう定義するか
  • 引き受ける準備があるか
  • 上司はテックリードにどんなことを期待するか
  • テックリードへの不満はどんなものか

4: 人の管理

• 人の管理で求められる主な仕事
  • 直属の部下との関係の構築
  • 定期的な1on1
  • キャリアアップ、進捗状況、改善領域、功績の報奨などのフィードバック
  • 各メンバーの得意不得意の見きわめと強化
• 直属の上下関係
  • 信頼感と親近感の構築
    • 重要なフィードバックは書面がいいか口頭がいいか
    • チームへの希望、意欲、期待
    • どんなものに不愉快となるか、それを事前に知っておくべきか
    • 耐え難い上司の振る舞いはあるか
    • キャリアアップの明確な目標があるか
    • チームにジョインする前に何か言っておきたいことがあるか
  • 今後の1カ月、2カ月、3カ月の計画を立ててもらう
  • 新人研修用のドキュメントの更新を担当してもらう
    • 現状との変化を反映する
    • わかりにくく感じた箇所を指摘してもらう
  • ポリシーや要望をはっきり伝える
    • 何を期待しているのかを明確にする
    • 判断基準も示す
  • 新人からもフィードバックを得る
    • チームに対する感想や意見をできるだけ表明してもらう
      • 既存メンバーでは気づきにくい視点
• チームメンバーとのコミュニケーション
  • 定期的な1on1はエンジンオイルの交換と似ている
    • 怠ると最悪のタイミングでエンストする
  • 定期的な1on1は必要
    • 標準は週1
      • その部下とは週何回1on1以外でやりとりしているか
      • どの程度コーチングが必要か
      • その部下は報告が得意かどうか
      • 普段良好な関係かどうか
      • チームや会社の不安定度はどれくらいか
  • 口頭ベースが理解が深まるようなトピックを話す
    • 複雑なコンテクスト
    • 微妙なニュアンスを含む
  • セラピー（心理療法）にならないように気を付ける
    • 純粋な人間関係の問題を話すかどうか
  • 相手を知るための機会とする
  • 1on1の議事録はドキュメントで作成する
    • 相手と共同編集する
• すごい上司、ひどい上司
  • 納期遅延への不安からマイクロマネジメントしてしまう
    • ベストメンバーだったテックリードが、一夜にしてローパフォーマーとなる
    • 信頼がないと管理したくなってしまう
  • 委任と放任は違う
    • 放任してあるとき急に怒り出す上司
    • 目的、自律、習熟
• 効率よく仕事を任せる
  • 優れたリーダーとは任せ上手
  • まずはどういった方法で成功の度合いを測っているのかを明確にする
    • 指標と目標
    • システムから取得する
  • フェーズによってフォーカスする箇所が変わる
  • ガイドライン・クライテリアの指針を決める
  • 情報は良きも悪きもオープンに共有する
• 継続的なフィードバックの文化を作る
  • 基本情報を知る
    • 目標や長所や短所など
  • 観察する
    • 長所や功績を見つける
      • 継続的な粗探しではない
  • 深刻な話題も日常レベルのフィードバックでさらりとする
  • コーチングはそれを必要とし、傾聴する気が十分にある人のために使う
• 勤務評価
  • 直近の2、3カ月ではなく過去1年全体に目を向ける
    • 1on1ドキュメントで成長や変化に気づく
  • 具体例をあげ、皆のフィードバックからの引用も使う
  • 功績や長所の報奨にはたっぷり時間をかける
  • 要改善点については焦点を絞る
  • 部下を驚かせてはならない
• 自己診断用の質問リスト
  • 直属の部下と1on1を計画した経験があるか
  • キャリアアップについて最後に部下と話したのはいつか
  • 先週部下にフィードバックを与えたか
  • 最後にチームのひとりを皆の前でほめたのはいつか
  • 訓戒を要する言動をチームの誰かが最後にしでかしたのはいつか。その言動に対する批判的なフィードバックを与えたのは、どの程度の時間が経過してからか
  • これまで受けた勤務評価のうちムダだと感じたものはあるか。どう改善すべきか
  • これまで受けたフィードバックのうち一番有益だと感じたものは何か。どんな形で与えられたか
  • 会社の昇進の規則や手続きはあるか。誰かに詳しく説明をもらうことはできるか

5：チームの管理

• チーム全体の責任を負う管理者の職務内容
  • 個々の部下を管理する仕事の総和ではない
    • ガラリと変わる
• チームの人々を後押しすること
  • 最強の技術力ではない
• 技術者の勘をどう維持するか
  • 多少なりともコードを書くことは続ける
• 機能不全となったチームのデバッグの基本
  • デリバリにこぎつけられない
    • リリースを毎日できるようにする
  • 厄介な部下への対応
    • brilliant jerkなど
    • 問題言動はすぐに注意し、正してもらい、具体例をあげながら説明する
      • エネルギーバンパイア
  • 過労による士気の低下
    • 管理者としての職務時間の2割をシステムの持続可能性のための作業に確保する
    • 2つのツボ
      • 管理者はチアリーダーたるべし
        • 作業に加わって応援する
      • 同じ事態の再発を防ぐよう全力を尽くす
  • 協働に関する問題
    • 相手方の責任者と定期的に連絡を取り合う
• 盾になる
  • 自分たちが影響力を行使して変えられる事柄になら焦点を当てるべき
    • 変えられない事柄なら無視する
  • コンテクストは把握しておくべき
  • 盾とはなるが、親とはならない
• チームの意思決定を主導するコツ
  • テックリードとの違い
    • テックリードは技術的詳細を管理する責務がある
      • マネジャーはプロダクトロードマップと、技術的詳細に関わる作業を推し進める責務がある
    • マネジャー自ら決定を下す権限があるのではなく、チームの意思決定を主導する権限があるだけ
      • ただ、その意思決定の良し悪しはマネジャーの能力の判断材料となる
  • データ重視の文化を根付かせる
    • 推測するな計測せよ
      • データをもとに仮説ベースで考える文化
  • 顧客に対する共感を深める
    • 顧客のコンテクストを伝える役割がある
      • どこに注力すべきか見きわめる判断材料となる
  • 将来を見据える
    • マネジャーは「今、ここ」より2歩先に立って考えていく必要がある
  • チームの意思決定やプロジェクトの結果を振り返る
    • プロジェクトが完了すると仮説や前提が間違っていたかどうかの検証を忘れがちになる
      • 仮説と意思決定を検証して、学習を蓄積する
  • プロセスと日程を振り返る
    • チームとして振り返りをする
      • 定性的にチームの健全性を把握できる
• すごい上司、ひどい上司
  • 手強いが公平無私な上司
    • データをベースとして仮説検証を行い、優先順位を決めてチームを集中させる
      • ただ民主的なだけではうまくいかない
        • 仲の良さを重視し意見の相違がないふりをするようになる
  • 対立解決の方法
    • コンセンサス（複数人の意見の一致）や、投票結果だけで決定する方法だけに頼ってはいけない
      • コンセンサスが真に機能する条件
        • 「投票者全員が公明正大で、投票に生じる種々の結果に対して投票者全員がまったく同等の利害関係にあり、なおかつその投票のコンテクストに関する投票者全員の理解度が同レベルである」こと
          • 現実ではほぼ無理
    • 意思決定から個人的要素を排除するための明確なプロセスを確立する
      • 投票の目標やリスクを全員に理解してもらう手順を考える
    • 問題を見て見ぬふりをしない
      • チームメンバー内に対立や個人の問題があれば事前にフィードバックなどを与える
    • 本当に対処を要する問題だけを取り上げる
      • 個人間のちょっとした摩擦
        • 取り上げなくていい
      • チームの効率低下を招くほど深刻な問題
        • 取り上げるべき
      • マネジャーがチームのセラピストになることではない
    • 他チームへ責任転嫁は禁物
      • 外からの脅威に攻撃的な反応を示すことがある
        • 溝が深まる
    • マネジャーは優しさよりも親切を旨とすべし
      • 八方美人ではなく、耳の痛い言いにくいことも言うのが親切
    • 対立は恐れず勇気を出す
      • 対立の結果を見越して敏感に反応するのは、賢明な資質とも言える
    • 我が身を振り返る
      • 自分の行動をメタ認知する
        • 私が意思決定を任せたのは自分の意思決定に自信がないからなのか、本当にチームを信頼しているからか
• チームの結束を乱す人への対処
  • 心理的安全性
    • 組織の歯車のひとつではなく、一個のれっきとした人間だという意識を自他ともに強めること
  • ブリリアントジャーク
    • 技術力至上主義で、反対意見を辛辣に切り捨てる
      • 技術力と実装力があるので現実では切り捨てることができない
        • はじめから雇わないことが最良の策
    • 抱え込んだときは心を強く保つ
      • 本人が自覚することはほとんどない
        • ありったけの証拠を並べても変えられない
      • 好ましくない言動は断固公然と拒否する
        • 「褒めるのは人前で、叱るのは1対1で」の数少ない例外
          • その場でただちに注意し、チームメンバーが守るべき基準を明示する
          • 極力冷静に対処する
            • 綱渡り的行動
        • ブリリアントジャークの言動がチーム全体に有害であると判断された場合にしか使えない
          • マネジャー個人に対するものであれば1対1で話し合うべきとなる
  • 秘密主義者
    • 隠し事をする人
      • 秘密裏に進めて完成してから披露する
      • 無断で他の人のコードを元に戻す
      • 他の人の作業を横取りして完成させてしまう
      • コードレビューされることを嫌がる
    • 根本には恐怖心が隠れている
  • 無礼者
    • チームメイトに敬意を払おうとしない人
    • 本当にこのチームで働きたいかを問う
• マネジャーが担当するべき、より専門機なプロジェクト管理
  • 手早い即席の見積もりと、具体的なプロジェクト計画の立案の両方こなせることを期待される
  • 経験則
    • アジャイル開発するならチーム主導でやる
      • 立案プロセスを横取りしない
    • 「一定レベルの生産性が見込める週」は、1四半期、1エンジニア1名当たり10週
      • 1年間は52週、1四半期は13週
        • 集中的に取り組めるのは10週と考える
    • 「システムの持続可能性維持作業」には2割を割り振る
    • 納期間近でのマネジャーの務めはノーを言うこと
      • 期限内に完成させるために、どれなら外せるか検討する
        • チームと共に厳選する
        • 必要なら上に対しても、下に対してもノーを言わなければならない
    • 即席の見積もりには「倍増ルール」を適用し、長期的作業の見積もりには立案のための時間を要求する
      • 倍増ルール：見積もりを頼まれたら、概算し、その結果の倍の数字を提示する
      • 2週間以上の未知が多い長期プロジェクトなら身長に計画を練る
    • チームメンバーに見積もりを頼むなら厳選して
      • 見積もりを手当たり次第に命ずると気が散らされてストレスが溜まる
• 新人マネジャーの心構え
  • 誰か適任者を見つけて、システムとアーキテクチャ、テストとリリースの手順を詳しく説明してもらう
    • 研修プロセスがあればそれを活用する
  • 実際に開発のひととおりの流れをこなす
  • コードと、コードを書くプロセス、チームが毎日使っているツールとシステムをきちんと把握する
  • 技術的信頼性を身につける
• 自己診断用の質問リスト
  • チームのマネジャーになった人が新たに担う職責は何か
  • あなたのチームがコードの作成やデプロイ、サポートに関連して日々直面している課題をどの程度把握できているか
  • あなたのチームが作業完了を報告する頻度はどれくらいか
  • あなたが最後に、機能作成、デバッグ、コードの作成に手こずっているメンバーとペアを組んであげたりしたのはいつか
  • チームにひどく好ましくない影響を与えるメンバーがいるか。いる場合はどんな対策を考えているか
  • チームの人間関係はうまくいっているか
  • チームの意思決定の方法やプロセスはあるか。あなたが自信を持って下す意思決定にはどんなものがあるか
  • プロジェクトが完了した時点でレビューし、目標を果たせたかどうかの確認をあなたが最後にしたのはいつか
  • 現在進行中のプロジェクトをチームが担当している理由を、あなたのチームはどの程度理解できているか
  • あなたが最後にプロジェクトの範囲を削ったのはいつか。何を判断材料にして意思決定したか

6：複数チームの管理

• 直属のテックリードが3, 4人いる技術部長（director of engineering）
• コードを書く作業に必ずしも毎日関わらなくてよい
  • マネジャーのスケジュールでは至難の業だから
  • レビューを引き受けるようにする
    • 少なくとも副レビュアーとして
      • 腕が鈍るのを防いでくれる
  • ペアプロや、小規模バグ修正、ちょっとした機能の作成などをやる
    • 現場作業を有意義な形で手伝う気もスキルもあると認めてもらう
      • 技術部長になる前にスキルが満ちていないと危険
  • 最低週に半日はまとまった時間で技術に対して時間を使う意識的な努力をする
    • 技術ブログ、講演、オープンソース
• 人を管理する道へと舵を切る前に、まずは十分時間をかけてプログラミングを完全にマスターしましょう
  • 最低1種類の言語に十分精通しておく
• 現場のエンジニアから管理職に転じると、ほぼ例外なく間違いだったんじゃないかと自問する過渡期を経験する
  • コードを書く作業ではすばやい成果（クイックウィン）をいくつも上げられる
    • 新米管理職はクイックウィンがそうそうない
  • 学生時代へのノスタルジーと同じ
• 時間の管理
  • 重要と緊急の違いを見抜く
    • 時間管理が難しくなるのは重要性の感覚があいまいになり始めるあたりから
      • 緊急でないものを緊急だと思い込んでしまうバイアスがある
        • 期日に厳密な制約がないのに制約があると考えてしまう
        • 今やらなければどんな損失があるか考える（Cost of Delay）
          • 一度やらなかった結果を想定してみることで認知のゆがみを正す
        • まず緊急度をもう一度考えてみる
    • 重要だが緊急でないこと
      • 短時間で成果を出せるMTGしかしないようにする
        • 出席者が事前にある程度準備してMTGに望むこと
        • MTGには明確な手順と予想される結果を事前に設定すること
      • 将来を考える仕事
        • 新しい職種のJDを作成する
        • 人材獲得計画を考える
        • 現行作業を再検討して目立った問題がないか確認する
        • 共通の問題点への対処法を話し合う
        • しばらく検討できていなかった問題をリストアップして焦点の当て方を把握する
  • 多岐にわたる仕事を巧みにバランスをとりつつ組織的にこなす
    • 多くの人がつまずく
• 意思決定と委任
  • 管理職が味わっている感覚は皿回しに近い
    • うまく回らないと皿が床に落ちてしまう
  • 委任するか自分でやるかの判断
    • 
  • 頻繁で単純な仕事は委任する
  • 頻繁でない単純な仕事は自分でやる
    • 頻度が低く、自分でやった方が早い仕事は自分でやる
      • 部長クラスより下の者がやるべきだと思っても自分でやってしまう
    • カンファレンスのチケットを予約、四半期報告書を生成するアプリケーションを実行するなど
  • 頻繁でない複雑な仕事は有望な管理者の訓練機会とする
    • 勤務評価の要約を書く
    • 人材募集の計画を立てる
  • 頻繁で複雑な仕事はチームの面々に任せる
    • 計画立案、システムデザイン、復旧作業
  • 問題の前兆
    • 日頃朗らかでよくしゃべり、仕事熱心な部下が突然会議では話さなくなり、皆とおしゃべりを楽しむこともなくなった
      • 個人的に大きな問題を抱えている
      • チーム再編直後なら、私は無視されたと感じている可能性がある
    • テックリードが万事順調といいながら、1-1をたびたびキャンセルし、最新状況の詳細を明かそうとしない
      • 何か隠している可能性
        • 進捗が遅延している
        • 別の何かを作っている
    • チームミーティングでPMとテックリードだけがしゃべり続けて、メンバーは黙っている
      • デスマーチになっている
      • 仕事に身が入らない状態
      • 自分は意思決定での発言権はないと感じている
    • 開発リストが顧客の気分次第で毎週のように変わる
      • 御用聞になっている
    • 小規模チームで、エンジニアが自分たちに無関係なシステムに関しては何も知らないことを認め、そのシステムに関して好奇心も公平な目も持っていない
      • 過去の出来事で発生した学習性無力感が蓄積している可能性
• やりにくい仕事: ノーと言う
  • 「はい。それでですね」
    • 肯定的に受けて、限界として実情を明示する
  • 管理者であるあなたからイエスを引き出すためのポリシーを決めておく
    • チームが事前に把握、検討できる
    • 目的、指標、最低限の制約
  • 今すぐは無理と断るときは、後日きちんと真剣に考える
  • ノーと言うときはぐずぐず引き延ばしにしない
    • 早合点でノーと言ってしまったときは素直に謝る
• 直属の開発チームの健全性を見きわめる
  • コードリリースの頻度
    • ベータテストや開発者テストなどを駆使して毎日リリースする
    • メンバーの生産性の向上を図る
  • コードへのチェックインの頻度
  • インシデントの発生頻度
    • 緊急呼び出しが多いと燃え尽き症候群を引き起こす
• すごい上司、ひどい上司
  • 既存のチームに加わった新任の管理者
    • 元職場の優秀な人材を連れてくる
      • 優越感で既存メンバーと衝突し続ける
        • いわゆるゴンゾウ
        • イングループ（内集団）の排他的チームはリーダーを失うと非常にもろくなる
        • 外部の考えやアイデアに聞く耳を持たない
        • 帝国を構築する
        • 柔軟性に欠ける
  • 排他的意識に用心する
    • 欠陥や弱点に焦点を当てるのではなく強みや長所を見きわめ、それを伸ばすようにする
  • 永続性のあるチーム
    • 全社レベルの目標を土台にして築き上げられ、会社の価値観に歩調を合わせることができる
    • 会社の使命を理解し、チームがその使命の遂行にどう関与、貢献するべきか理解している
    • 育てるべきチーム
      • リーダーやメンバーが辞めてもすぐに立ち直れる
      • 目標駆動型のチーム
      • 横軸でチームがまとまる
      • 目標達成に役立つ変化なら喜んで受け入れるチーム
• 無精、短期、傲慢はエンジニアの最大美徳
  • せっかち、無精になる
    • 今すぐせっかちに何が一番重要かを見きわめて、仕事を終えてすぐ帰宅する
      • 効率が悪そうならすぐに自問自答する
        • スループットを上げる
      • 1日の労働時間を減らして同レベルの価値を会社にもたらす
        • 管理者こそ残業せずすぐに帰宅する
        • 周りの超過勤務による燃え尽き症候群を減らす
        • あえて時間を制限することで効率化することへフォーカスできるようになる
• 自己診断用の質問リスト
  • 効果的ではない仕事があるか、過去未来の2,3週間のスケジュールを見て考えてみる
  • コードを書く作業を管理者としての職務のスケジュールにどう組み込んでいるか
  • 最後にチームのメンバーに任せた仕事はどのようなものか。それは単純か複雑か。メンバーはどの程度こなせているか
  • チームで有望な人へどのようなコーチングを計画しているか。より重い重責を追ってもらう準備としてどんな見習い作業を与えているか
  • チームでは、コードの作成、リリース、サポート作業がスムーズに行われているか。最後に顕著なインシデントが発生したのはいつか。イレギュラーなことが起こる頻度はどのくらいか。
  • プロジェクトの範囲を狭めるように最後にチームに命じたのはいつか。それはどのように意思決定しているか
  • 最後に午後8時以降や週末にメールを送ったのはいつか

7: 複数の管理者の管理

• 複数のチームに対する責任を負って、各チームの健康度に目を光らせ、目標設定を支援する
  • 複数チームを率いる管理者との違い
    • 責任の重さ
    • スキルセットの範囲外を担当するチームを管理する
    • すべて何ランクか挟まっての間接的な管理となるため実態がつかみづらい
    • 各チームの開発者全員と顔を合わせていた管理を卒業
    • ゲームのルールがガラリと変わる
• 問題を丹念かつ先を見越して掘り起こすのが管理者のつとめ
  • オープンドアにしても誰も来ない
    • リスクを承知で上司に問題を知らせる部下はよほど勇気ある部下
• スキップレベルミーティング
  • 2ランク以上離れた部下を管理する
  • 例: 1on1を四半期に1回の割合で開く
    • 部下を生身の人間として見られるようになる
    • しかし、いつかは無理な人数に達する
  • スキップレベルランチ
    • 1四半期に2,3回ずつ
    • チームの近況を話し合う
      • 1on1に近い効能が得られる
      • 現場の人の意見を聞ける
  • お互いによく知った仲だからと油断すると失敗する
    • 意識的な努力が必要
• 部下である管理者たちに明確に責任を課する
  • 管理者はチームの健全性と生産性に関する責任を負っている
• すごい上司、ひどい上司: ノーと言える管理者とイエスマン
  • お人好しのイエスマンで好かれるいい人だが、問題は置き去りのまま
    • セラピスト系のイエスマン
      • 話を聞くし問題も知っているが、一向に解決されない
• 新任管理者の管理
  • 働きすぎの兆候
    • 委譲の見きわめを学ぶ
    • 急に仕切り屋になってしまうこともある
  • 1on1とステップミーティングで状況を把握する
• ベテラン管理者の管理
  • マネジメントは文化に根ざした仕事
  • 別のカルチャーを持っていることがよくある
    • 文化と反するサブカルチャーを作られると困る
  • 自分の業務を委譲していく
• チーム管理者の中途採用
  • スキルを持っているか、カルチャーフィットするか
  • スキル評価
    • 直属の部下になる予定のメンバーに擬似1on1をしてもらう
      • シニアエンジニアに直近の問題をデバッグしてもらうのと同じ
      • やりにくい場面をどうさばくかを評価してもいい
    • 管理者はチームそのものに内在するバグを解消できなければならない
    • 経営哲学を語ってもらう
    • シンプルな技術面接
  • カルチャーフィット評価
    • まず自分が会社価値観をきちんと理解する
    • サーバントリーダーシップの文化なのにトップダウンの管理者を雇うと不適合となる
    • データでなく声の大きさで意思決定する志向があるなど
    • フィットしない人を雇った場合
      • 管理者自身が辞めてしまう
      • チームメンバーの大半が辞めて、その管理者自身も辞めてしまう
  • 文化の価値とは
    • きわめて複雑かつ不明確な状況下で、意思決定者が自分ではなく自分の属するグループのためを思って決断を下すファクターの一つとなりうるもの
• 自分がうとい分野のチームの管理
  • 未経験の分野は焦点の当て方が把握しにくい
    • 手遅れになるまで気づかないこともある
  • 常に好奇心を絶やさないこと
    • 歯を食いしばってでもうとい分野を知るための時間を捻出する
      • 各チームの管理者とメンバーに尋ねる時間を設ける
• 機能不全に陥った組織のデバッグの基本
  • デバッグの名手はバグ発生の理由を執拗なまでに探求する
  • 複数チームの管理は、複数の複雑なブラックボックス間の一連のやり取りを管理する仕事
    • 入力と出力は監視できる
      • 蓋を開けて確かめることも必要
  • デバッグが必要な状況とは
    • チームメンバーはうまくやってそうなのに、辞めていく人があまりにも多い
  • デバッグ
    • 仮説を立てる
      • コンテクストを明らかにして仮説を立てる
      • 再現できる仮説であればなお有益
    • データをチェックする
      • インシデント対応に大幅に時間が取られている
      • 体調を崩しているチームメンバーが多い
      • コードレビューのコメントでコーディングスタイルに文句を付け合ってはいがみ合っている
      • タスク管理のチケットの書き方が極端にあいまい、細かい
      • チームがチャットでビジネスライクなやり取りしかしていない
      • 週に何時間もMTGしている
      • 管理者が1on1をやっていない
    • チームを観察する
      • MTGは健全か、一方的に誰かだけ話していないか、退屈でないか
        • 観測行為が影響を与えることを考慮する
    • 質問をする
      • なぜ今その目標を掲げているのか
        • 理由を説明できるか
          • 一本の槍になっているか
            • リーダー（管理者、テックリード、プロダクトマネージャー）の責務
            • モチベーションにとって重要な要件
    • チームの人間関係をチェックする
      • プロ意識の非常に高いグループでも、メンバー間にある程度の絆があるのが普通
    • 支援に乗り出す
      • 厄介なシステム障害のデバッグを手伝う
      • チームのデバッグも手伝う
    • 常に好奇心を失わない
      • なぜを究明することに好奇心を絶やさない
        • 一定のパターンや教訓が見つかる
• 期日の見積もりと調整
  • 技術系の管理者がしょっちゅう受ける質問の中でとくに癪にさわるのが「なんでこんなに手間取ってるのか？」
    • 管理者の管理者だと間接のため詳細につかめなくなる
      • 見積もりの期日を大幅に遅れているときは説明責任がある
      • 技術部長はスケジュールの見積もりに関しては強気で押し通すべしが鉄則
  • ソフトウェア開発の見積もりは難しい
    • さまざまな見積もり手法をチーム全体で試して、自分たちの役に立つものを選ぶ
      • 見積もり作業をチーム全体で習慣化する
  • アジャイルに失敗から学ぶ
    • 先を見越した形で見積もりを修正していく
    • 機能を削ぎ落とすことも時には必要
• やりにくい仕事：ロードマップにまつわる不確実性への対処
  • ロードマップが上から降りてくる
    • 技術的負債解消などをどう優先順位付けすればいいか
      • 優先順位付けプロセスさえ確立されていない
  • ロードマップにまつわる不確実性に対処する戦術
    • 会社規模や成長段階に合わせて、方針転換の可能性を現実的に受け止める
      • 半期で完了しないような作業をチームに確約するのを避ける
    • 大きなプロジェクトを一連のより小規模な成果物に細分化する
      • 状況は一変するので常にフォーカスを絞って再検討を繰り返す
    • 技術プロジェクトを「そのうちきっとやる」と、チームへ安請け合いしない
    • チームのスケジュールの2割はシステムのメンテナンス作業に割り振る
      • 大規模なリファクタリングはできないが、2割は確保しておく
    • 技術プロジェクトでも、本当はどの程度重要なのかを厳密に検討する
      • 規模、重要性、価値、完遂した場合にチームにどんな良い影響があるか
      • 大規模な技術プロジェクトも、なるべく製品部門の企画提案と同じような価値を提示する
        • 理解者が増える
• 技術力の点で時代遅れにならないためには
  • どんな技術的責任があるか
    • 技術的投資の監督
      • 開発言語、フレームワーク、インフラ、ツールなど
    • 情報収集のための質問
      • 進行中のプロジェクトとイレギュラー事象とボトルネックの把握
    • 技術と事業のトレードオフの分析と説明
      • エンジニアたちが事業の全体像と将来的なぷロダクトロードマップとを十分理解した上で意思決定できるように計らう
    • 明確で詳細な要求を
      • 自分の組織の技術を十分把握しておくべき
        • リライト中なら増員しても効果が薄いので、新規APIをより早期に公開する作業に割り当てるなど
    • 経験で培った独自の勘を拠り所に
      • 技術部長はソフトウェア工学やテクノロジーにまつわる難題やトレードオフを理解して行う専門的な仕事
      • コードを読む
        • コードレビューやプルリクエストにざっと目を通していく
      • 自分がうとい領域は詳しいエンジニアに解説を仰ぐ
        • ペアプログラミングしてもらう
      • ポストモーテムに同席する
        • ソフトウェアの作成とデプロイのプロセスに関する詳細が多く扱われる
      • ソフトウェア開発のプロセスに関する業界のトレンドを常に把握する
      • 社外でも技術系の人脈作りを
      • 学びは決してやめてはならない
• 自己診断用の質問リスト
  • ステップミーティングをどんな形でしているか。先を見越した形でチームを支援するためにどんな方法を取っているか
  • 率いている技術者の責務をJDを見ないで書き出してみる
  • JDと責務の認識について乖離があるか
  • コーチングや自己研鑽が必要な領域はどこか。次の1on1で話すべきことは何か
  • 自分のうとい領域の作業が順調に進んでいるか、どの程度の頻度で確認しているか。その領域で働くチームを理解するために過去3ヶ月に新たに学んだことは何か
  • 他のチームよりも明らかにスムーズに運営できているチームがあるか。その理由がわかっているか
  • チーム管理者の採用面接でどんな手順を取っているか。チームメンバーとも面談させているか
  • 組織の四半期の目標は何か。それを技術的な目標とどうすり合わせているか。各チームは所属部署の目標を理解できているか

8: 経営幹部

• 経営幹部の職務内容は会社によって大きく変わる
  • 情報の収集・共有
    • 大量の情報から不可欠な情報を選り分け、それを第三者にも理解可能な方法で共有する
  • 注意喚起
    • 命令ではなく質問することによって相手に責任事項を想起させる
    • 組織全体の脱線を防ぎ前進させる
  • 意思決定
    • 組織全体に影響が及ぶことを承知の上で、相容れない見解や不完全な情報も踏まえて針路を決める
  • ロールモデル
    • 会社の価値観を内外に知らせ、率先して職務を遂行し、気の進まない場面でもチームに最良の模範を示す
• CS専攻ではない技術部門の管理者の事例
  • 求められているのは、チームの中で一番の切れ物になることでも、正しい判断を下すことでもない。チームが極力最善の決断を下し、それを持続可能かつ効率的なやり方で実現できるよう後押しすること
    • 最新の開発言語やフレームワークを追いかけることでも、脚光を浴びている最新技術を導入することでもなく、顧客のために最高の製品を創造、製造できるツールと特性を兼ね備えたチームを育て上げること
• 技術系経営幹部の肩書きと役割
  • 研究開発（R&D）
  • 技術戦略
    • 業界や技術の傾向に基づいて意思決定を導く
  • 組織化
  • 執行
    • 組織化と兼務する
    • ロードマップの連携、計画立案、広範な事業の調整
  • 技術部門の対外的な顔
    • クライアントへ売り込みへの参画
    • 技術ブランドの確立
  • 社内の技術インフラとその運用
  • 事業化
    • 自社の属する業界に精通し、技術以外の主要部門も把握する
    • 開発ニーズと事業拡大ニーズのバランスをとる
• 技術担当VP（VPoE・VPoT）とは
  • 技術系管理者のランクの最上位
    • CTOとの違い
  • 大企業では各部署のミニCTO
  • VPは現場の詳細に通じながら、下位レベルの作業完遂を促す影響力を持つ
    • CTOがより広範な戦略と、社内での技術部門の位置付けにフォーカスする
    • VPがアイデアの実現にフォーカスする
  • VPは管理責任も負う
    • 開発ロードマップと雇用計画をすり合わせる
  • 担当部署の健康度をチーム代表として他の経営幹部へ報告する
    • VPはチームを心底気遣い、自らスポットライトを浴びることよりも有能な組織を育て上げることを優先する優れたエンジニア
• CTOとは
  • かなり定義はあいまい
    • 就任の経緯も職責も千差万別
      • 共同創設者のひとりであるエンジニアなど
    • CTOとは、その会社が現在の成長段階で必要としている戦略的技術系幹部
      • 長期視点で、未来とそれを可能にする要素とを計画する作業を支援する仕事
        • 戦略的思考の成果を実現、運用可能にする作業を支援する
          • 問題を細分化し、その対策を部下に実行させる仕事
  • CTOではないもの
    • 技術系の役職ではない
      • 技術部門のランクの最上位ではない
      • コード書きやアーキテクチャ、奥深い技術系デザインをこよなく愛する人々が一般的に楽しめるような職種ではない
      • 必ずしも社内でもっとも優秀なエンジニアとは限らない
      • コンピュータおたくのボスではない
  • CTOとは
    • その会社が現在の成長段階で必要としている戦略的技術系幹部
      • 長期的視点で、事業の未来とそれを可能にする要素とを計画する作業を支援する仕事
        • 戦略的思考の成果を実現、運用可能にする作業を支援する
          • 問題を細分化し、その対策を部下に実行させる仕事
  • 具体的な職務
    • 事業を理解し、技術というレンズを通して事業戦略を立てる
    • 第一に経営幹部たるべきで、エンジニアであることは二の次
    • 技術チームがニーズやアイデアを活かせない単なる実行部隊にされてしまわないようにCTOが守る
    • 複数の技術担当VPを雇って直属の部下を持たないようになってはいけない
      • 責任を果たさずに権限を手にすることはできない
        • 残るのは組織側の善意と自身の2つの手だけとなってしまう
    • CTOは何よりも事業戦略に関わる仕事を最優先すべし
• CTOと技術担当VPとの区別がつかない
  • 場合によりけりと言うしかない
    • 企業によって職務がかなり違う
  • どちらのポストがいいか判別する質問
    • CTOに向いている
      • いつか仲間と企業してみたいか
      • 技術的なアーキテクチャの監督作業やプロセスや指針の策定がしたいか
      • アーキテクチャを実現すべく事業サイドも深く理解したいか
      • 対外的なイベントや、顧客への売り込み、エンジニアの人材募集を担当する意欲があるか
      • シニアエンジニアの管理やメンタリングに関わる意欲があるか
    • 技術担当VPに向いている
      • 人を管理する仕事は好きか
      • 技術的なプロセスの効率アップを図る仕事は好きか
      • 大局的な視点から見て、チームの作業の優先度付け作業に関わりたいか
      • 組織の構造に強い関心があるか
      • PMとの協働は得意か
      • 技術的な詳細からチーム全体の能率に焦点の当てかたを移すことに抵抗感はないか
      • アーキテクチャのレビューMTGより、ロードマップの計画立案MTGに出席したいか
    • CTOへの最短ルートは技術系の共同創業者になること
    • 技術担当VPへの最短ルートは規模が大きめの企業で管理経験を積み、その後成長中のスタートアップへ移る
    • 「CTO（や技術系VP）になりたいという状況は、とにかく結婚したくてしようがないという状況と似ている。肩書きだけじゃなく、会社や社員だって重要だ」
• 優先順位の変更
  • ある朝CEOが素晴らしいアイデアを思いついて、その事業が最優先となることもある
    • この最優先事項をチームのみんなが理解していないのはなぜか
    • 実際にこれを最優先する場合、チームはどんな作業を削らないといけないか
  • 技術系幹部が忘れがちなこと
    • 他の幹部は、技術チームの仕事内容や理由といったことを詳細に理解しているわけではないということ
  • 最優先事項に取り掛かる前に何を完遂しておくべきか見きわめる
    • 上や下へ明確に伝える
      • 価値、現況、完遂までの予想スケジュールなどの可能な限りの詳細
  • 重要事項は相手の意識に刻まれるようにする
    • 伝達方法や回数を工夫する
      • 3回説明するなど
• 戦略の策定
  • 戦略は欠くべからざる要素
  • 広範な調査と熟慮
    • 技術チームのペインポイントがどこか
      • ボトルネックはどこか
  • 調査の結果と自分なりのアイデアの紐付け
    • 調査データのモデル化とともに将来像を描く
  • 技術戦略の草案作り
    • 対社内、対顧客、将来の展開をふまえてシステムをどうしていくか
  • 経営陣特有の流儀
    • 長期的戦略
    • 事業発展の推進力となるものは何か
    • 事前にしっかり目を通されるので情報を不足なく載せておく
• やりにくい仕事: 悪いニュースを伝える
  • レイオフ、チーム解散、方針転換
  • べし・べからず集
    • 大きなグループに地の通わないメッセージを一斉送信するのは禁物
      • 2番目に好ましくないのは、全員を一堂に集めて知らせる方法
        • 血が通わないから
    • できる限り個別に話す
      • 反応したり質問したりするチャンスが与えられる
    • 言語道断だと思うようなメッセージなら、伝達役を立てても構わない
      • とんでもない方針変更、理不尽なチームの分割
      • 一種の大人のやりかた
    • その悪いニュースが招きそうな事態を直視する
    • 自分ならどのように告げてほしいのか想像してみる
• 他部門を統率する幹部仲間
  • 幹部仲間こそチーム
    • 必須の要素として信頼がある
  • あなたが仲間の縄張りを荒らさず、仲間もあなたの縄張りを荒らさない
    • その人の管理のしかたやスキルの応用のしかたに賛同できなくても放っておく
      • 助言を求めてこない限り極力口出ししない
        • 相手の技量に敬意を払う
    • 「エンジニアこそ誰よりも頭の冴えた人種」ではない
      • 思い込みをなくす
  • 幹部の間で生じた意見の相違や衝突は外部へは持ち出さない
• 影響力のある立場となる
  • もといたチームとは適切な距離をおくべき
    • 飲み会では皆を残して一足先に帰る存在となる
    • 程よく距離を置いていないと、特別扱いのそしりを受ける恐れがある
      • 仕事がやりづらくなってくる
      • 「仲良くなるということで良くない影響が発生することがある」ということを理解していく
    • 距離を置いていないと、気のおけない仲間の発言なのかトップからの命令なのか、部下は判断に苦しむ恐れがある
  • もはや技術チームのブレインストーミングの一員にはなれないことを理解する
    • 参加すると自分の意向を反映したものに変わっていってしまう
      • 発言力が強すぎる
  • 態度やふるまいが社員のロールモデルとされる
    • 人を怒鳴ると怒鳴ってもいいんだ、ミスを認めて謝罪すれば、ミスをしても大丈夫なんだと理解される
  • 適切に距離を置きながら、社員を人として絆を育む
• すごい上司、ひどい上司: 恐怖支配の上司と信頼で導く上司
  • 恐怖支配
    • 部下を萎縮させ、リスク回避の行動をとる方向へ向かわせ、隠蔽文化を促進する
      • チームの自律性を削ぐ
    • 恐怖の文化は他のことがすべてスムーズに進んでいる環境では問題視されずに存続してしまう傾向がある
      • 一定の敬意を払い、会社は成長し、チームはやりがいのある問題解決に励んでいる
        • これに踊らされてはいけない
        • 当面は何とかやれるが、恐怖支配は長くは続かない
          • ましな職場へ優秀な人材が転職する
          • 問題が発生してくると一気に崩れる
  • 信頼で導く
    • 心を通わせる習慣をもつ
      • リスクを冒そうがミスをしようが平気（心理的安全性）を作り出すこと
    • 謝罪の文化
      • ミスをしたら謝る
      • チャレンジして謝罪するというロールモデルになる
    • 常に好奇心をもつ
      • 好奇心によって率直に質問する
    • 責任はあるべき場所へ
    • 信頼の文化は構築に時間がかかるがそれだけの価値がある
• True North
  • CTOやCFOのような幹部が自身の担当部門に対して果たすべき役割
    • その部門で真に卓越した手腕がどのようなものか、その基準値を自ら示すこと
      • これがTrue North
      • 技術者の勘
        • 常に磨いておく
  • 各部門で微妙に異なるので全社レベルでは健全な緊張関係ともなる
    • PMは顧客体験を重視しがち
    • 財務部門は可用性よりもインフラコストを重視しがち
• 自己診断用の質問リスト
  • 経営陣でもプロのコーチからコーチングやメンタリングを受けることは賢い投資である
  • コーチの指導以外に社外の助け合いネットワークを持っているか
  • とくに敬愛する技術系の幹部がいるか。どこがすばらしく、どこを見習いたいか
  • 直近の優先順位決めはどのようにしたか。どうチームに伝えたか。次同じことをする場合変えたいところを考える
  • 会社の近い将来目指す方向をどの程度理解できているか。そのために必要な技術戦略を把握しているか。チームが焦点を当てるべき領域はどこか
  • 首脳陣との関係はどうか。仲間はその関係性を理解しているか
  • 首脳陣が到底受け入れられない決定を下しても、いったん自分の意見を置いておいて、皆の決断を支持できるか
  • チームのロールモデルとなれているか。会議で一方的に話していないか。傾聴できているか
  • 定期的に顔を合わせることのない部下に声をかけて、職場以外での関心事について最後に尋ねたのはいつか
  • シニアエンジニアに対して守ってもらいたい基本原則は何か。管理者たちがチームを率いる際に守ってほしい管理上の基本原則は何か

9: 文化の構築

• 技術系幹部の職責のひとつが担当部署の文化（カルチャー）の構築
  • チームに文化を明示し、以降も常に配慮を怠らない
    • 新人のCTOはこの仕事の重要性を過小評価しがち
      • インフラと同様に、チームの成長発展に必須
• スタートアップ企業文化の信奉者にとっては、構造やプロセスは無意味や有害に映ることが多い
  • 大企業病に見える
    • 構造ではなく学習が重要
    • プロセスそのものが重要なのではなく透明性が重要
• しかし基本セオリーは仮説検証のために必須
  • 無構造の暴政となりやすい
    • https://www.jofreeman.com/joreen/tyranny.htm
    • 組織構造を嫌って無構造を装う集団には隠れた権力構造が生じがち
      • スタートアップにもよくある
    • 無構造でもうまくいくこともある
      • タスク志向の集団
        • カンファレンス開催、新聞の発行など集団の果たすべき機能が明確に限定されている
      • 比較的均質なメンバーから成る比較的小規模な集団
        • 微妙なニュアンスを嗅ぎ分けられるほどまで全員がよく理解し合えている
      • コミュニケーションが密な集団
        • 集団の規模が小さく、共同生活とも呼べるような状態でタスクの重要な局面をこなしている
        • 5人程度
          • その限度を超えて、一部の意思決定に参加できないメンバーがいても構わないという集団
      • スキルの専門性が低い場合
        • どのメンバーもある程度まで交換可能な部品となっている状況
    • いずれ陥る可能性
      • 自律性の低下
      • 隠れた階層と権力の力学に振り回されるようになる
      • 技術的な意思決定やプロセスで壁に突き当たる
        • 交換可能なメンバーで構成されたチームが、とりあえず目の前の課題をこなすためにコードを書く
          • スパゲティコードになりがち
  • 構造は長期的視点での課題解決をスケールさせるためのもの
    • ただ構造の導入を早まると弊害も起きる
• スタートアップをマネジメントするたとえ
  • 草創期のスタートアップはF1
    • 制御しているのは自分で急な進路変更も思いのまま、すべてが飛ぶように進んでいく
    • 車の動きも地面から直に伝わる
  • 会社が大きくなると旅客機の操縦
    • 地面ははるか下にある
    • 多くの人命が自分の肩にかかっている
    • ただ操縦桿を握っているのは自分で、比較的早い方向転換も可能
  • 最終段階は宇宙船
    • すばやい動きは無理
    • 飛行ルートは事前に決められている
    • しかし大変な数の人を乗せ、はるか遠くまで飛ぶことができる
• 自分の役割の見きわめ
  • 舵取りしている乗り物は何か
    • 社員数
      • 目標の設定と周知を円滑に行える構造化どうか
    • 創業からの年数
      • 長ければ長いほど慣行や慣習が定着している
        • 今後も存続する可能性が高まる
    • 既存のインフラの規模
      • ビジネスルール、事業倫理規定、物的インフラがあるか
    • リスク許容度
      • 規制が厳しいか、失策した場合の代償が大きいか
  • 年数を経るにつれ構造も成長していく
    • 「正常に作動する複雑なシステムはどれも、正常に作動していた単純なシステムから進化してきたものである。複雑なシステムをゼロから設計しても決して正常には作動せず、修正して正常に作動させることもできない。まずは正常に作動している単純なシステムから取りかからなくてはならない」 『発想の法則』
  • 無構造がチームにもたらす価値と、無構造のせいで望ましい人材を逃すことから生じる損失を天秤にかけて検討する
    • 不都合の発生という失敗を糧にして改善の好機とする
      • 新人研修プロセスが確立していないため、新人が加わるたびにチーム作業が何ヶ月も遅れる
      • 昇進や自己啓発や目安となるキャリアラダーが確立していないため、社員が次々辞めていく
      • 新人が直接DBにアクセスして重要なテーブルを削除してしまうことが3度も起こる
• 会社や担当部署の文化の創成
  • 文化とは
    • 構成員が意識しなくても自然に仕事をこなせる、そんな行動原理や行動様式こそが組織の文化
      • あるコミュニティで共有されている暗黙のルール
  • 企業文化はたしかに存在するし、途方もなく重要であるにもかかわらず、まるで理解していない人が多い
    • 文化は徐々に自然に育まれるが、注意を怠ればあっという間に懸念事項となるもの
      • 組織文化の意識的主導はリーダーの役目のひとつ
• コアバリューの活用
  • 文化を理解し育てることはリーダーの大切な仕事
    • 担当部署の文化を定義する
      • 例：多様性の尊重
        • プロ意識を第一として正規の時間できっちり働くチームや、フレックスタイムのチーム、気軽におしゃべりしたり飲みに行ったりするチームもある
          • （お店のようなもの）
    • 会社やチームの価値観をプラスの形で体現している社員をほめることによって文化を強化する
      • コアバリューにまつわるストーリーやエピソードをMTGで共有する
    • チームが重視する価値観を勤務評価の柱のひとつとする
      • コアバリューを体現する言動をしたときは、そのことと経緯を勤務評価に明記する
        • 面談でもしっかり指摘する
      • なんとなくそりが合わないという状況を深堀りできる
    • コアバリューを採用面接のプロセスに組み込む
      • 友人候補を揃えればいいというわけでもない
        • 多様性が失われる
  • 文化に関するポリシーの策定
    • キャリアラダー
      • チームのメンバーにも応援を仰ぐ
        • 関係者全員で議論を重ねる、サブグループを設けるなど
      • 実例をさらに集める
      • 細部の表現を大切にする
        • やる気を引き出し、説明に過不足なく、社風や実情に合った解説文
      • 詳細な説明と要約とを併用する
        • 各ランクの特徴が表形式で整理してある簡略なスプレッドシート
          • 昇格に伴う変化を段階を追って把握できる
          • ランク相互の関係、職務範囲、責任、スキルなどが理解できる
        • それぞれのランクを文章で詳しく説明した長いバージョン
          • ストーリーの形で詳細を補う
          • 各ランクの優秀な社員の勤務評価のような感覚で読めるもの
        • ラダーと給与の関係性を考える
          • 一定の幅を持たせて設定する
        • キャリアの初期段階では昇進の機会を増やすか
          • 新人エンジニアは入社直後2,3年間は毎年昇進させるなど
        • キャリアの初期段階の給与幅は狭くするか
          • 下層レベルでの社員間の給与格差を最低限に抑えられる
          • 隣り合ったランクの判別は難しくなる
        • ランク数の少ない層では給与幅を広くする
        • ブレークポイントに当たるランクの設定も検討する
        • 実績報奨の手段としても
        • 途中で管理系と技術系のパスを分ける
        • ピープルマネジメントスキルを中堅社員の必須条件にするという選択肢も
        • 経験年数
        • 最初から完璧なラダーなどない
• 職能の枠を超えたチーム
  • 新機能開発チームの編成の例
    • フロントエンドエンジニア、バックエンドエンジニア、PM、デザイナー、データアナリスト、CSのチーム
      • それまでは「我々 vs 他の部署」という考え方だった
        • 組織全体を「我々」とみなす視点が生まれた
          • pods, squads, pillarsなどと呼ばれる
          • コンウェイの法則
  • 職能を超えたチームとは
    • チームにとってもっとも重要で、ほかの何よりも優先するべきコミュニケーションは、製品の効率的な開発と更新を実現できるコミュニケーション
      • ただ、もっとも有効な技術を生むとは限らない
        • 技術志向のチームに比べて非効率な部分のあるシステムを生み出す恐れもある
          • 許容ラインを見定める
  • チームの作り方
    • 2種類のチームがある
      • 環境や状況に即した方を採用する
        • 主要な体制はどちらか一方とすることも大事
    • 担当分野を同じくするエンジニアだけからなる技術志向のチーム
      • 技術志向チームは技術力の優劣に目が向きやすい
    • 職能の枠を超えた製品志向のチーム
      • 技術志向のチームとはリーダーシップの焦点の当てどころが違う
        • 製品に関しての優れたセンス、迅速かつ効率的に機能開発できるスキル、他部門とのコミュニケーション力、などが評価される傾向がある
• 作業プロセス
  • プロセスが皆無というチームは規模拡大で苦労するし、チームに合わない作業プロセスは作業停滞を招く
    • チームの現在の規模やリスク許容度に見合った作業プロセスを選ぶ
  • 作業プロセスはリスク管理
    • チームメンバーが完璧に従わなくても価値の得られるプロセスとする
      • 変更やリスクをチーム全体で共有できる
• 意思決定のプロセスから属人的要素を排除する
  • コードレビュー
    • 複数のチームメンバーがコードに目を通し、変更箇所を認識しておく機会となる
  • コーディングスタイルの問題はiintで解消する
  • レビューリクエストをチーム内でどうさばくべきかよく考える
  • 稼働停止の事後検証
    • ポストモーテム
      • 学習のための検証とする
  • アーキテクチャレビュー
• 自己診断用の質問リスト
  • 会社や部署の現在の手法やプロセス、慣行やポリシーはどのようなものか。文書化したものがあるか。それを見直したのはいつか
  • 企業理念はあるか。チームでどのように実践されているか
  • キャリアラダーはあるか。どう改善できるか
  • チームや会社にとって重大なリスクは何か。そのリスクを軽減するにはどうすればいいか

10: まとめ

• 人の管理がうまくなりたければ、自分自身を管理できるようにならなければならない
  • 自分がどのように反応しているのか
  • どんなことにときめくのか、怒るのか
• すごい上司とは
  • 意見の相違や争いを解決する名人
    • 話し合いに自分自身のエゴを持ち込まないコツを身につけること
      • 対象となる状況に関する自分なりの解釈は、解釈のひとつにすぎないと理解する
        • でないとそうした資質が足枷になる
        • その状況を相手の視点から眺めてみたらどう見えるか
          • 好奇心を持つ
• ストーリーを向こう側から見つめてみる
  • 相手の視点にダイブする