エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
オライリージャパン
売り上げランキング: 712
ソフトウェアエンジニアのマネジメント系キャリアについて包括的に扱っている本。はじめはメンバーとしてのマネージャとの付き合い方の話からインターンのメンターに始まり、テックリード、エンジニアチームのマネージャ、CTO・VPと、各段階を順に扱っている。それぞれの職種の役割をジョブディスクリプションで説明し、注意すべき点やコツが紹介されている。
一定期間ソフトウェアエンジニアをやっていると、多少なりともマネジメントやチームビルディングに関わったり、悩むことが出てくる。そういう時にこの本は助けになると思う。チームで働くあらゆるエンジニアにとって学びが得られるが、やはり実際にマネジメントをして悩んでいる人にこそおすすめしたい本だ。
今までのこの手の本は、ほとんどがソフトウェアエンジニアとしての技術的な成長にフォーカスしていた。マネジメントはスムーズに働くために誰かがやらないといけないものだ。積極的にマネジメントに取り組むエンジニアは相対的に少ない。スキルの掛け算で市場価値を高めるのはキャリアパスを考える上で大切だが、技術とマネジメントの掛け算は、エンジニアが生き残る上で有力な選択肢の一つだと思う。
的確で実践的な本なので、あるあると共感できたり、悩み事のヒントが見つかったり、自分ができていないことを発見できて身につまされたりする。そんな内容なので、読む人によって、刺さるポイントが違うと思う。現時点の自分の場合、コードを書くこととマネジメント職の関係性の話、開発チームが会社の要望の単なる実行部隊になってはいけないが、なぜそうなりがちなのかという話、学習はシンプルな状態から徐々に複雑化しないうまくいかないという話が印象に残っている。
（以下は、それぞれ結構行間を読んでいるので、好意的解釈・ポジショントークが結構入っている。）
- マネジメント系のポジションを進むにつれて、コードを書く時間は減る。でも少しでも技術的なことに取り組むべきだ
- 例えば、小規模な技術的成果物の作成。バグ修正、小さな機能の修正、生産性を上げるタスクに積極的に関わる
- このような小規模のコーディングがなぜ大切なのか。それで現場の感じ方・痛みがわかるから。システムの細部まで理解するには手も動かす必要があるから。長いキャリアで技術力が枯渇を防ぐために。
- 言い換えると技術系のマネージャは適切な見積もりのためにシステムのディテールを理解し、技術的負債を感知するために手を動かし、今後のロードマップや自身のキャリアのために積極的に技術力を磨く必要がある。
- マネジメントのポジションに付く前に十分にスキルをつけておく。筆者は10年は現場の開発者だった
- プロダクションのコードを書かなくなったとしても、時間を作って個人プロジェクトや課外活動で技術力を高めるべき
- 開発チームがプロダクトの要望に応えるだけの「実行部隊」化するのは良くないが、何故そうなるのか。
- スタートアップ初期は組織構造がなく、メンバーみんながなんでもやる。立ち上がりはこの形が合理的。
- 規模が大きくなると組織構造を整理されないと意思決定と執行を適切にできなくなる。が、うまく回っているものはなかなか変わらない（変える必要がない）し、立ち上げメンバーの気質的にも、いきなり組織っぽくする事は難しい。
- その結果として「創業者など明確に権限がある人の影響力が高くなる」か「暗黙的な組織の力学ができていて、それに従って仕事が進む」ようになりがち
- 相対的にボトムアップの仕事が進めづらくなる
- 同様にスタートアップ初期の進め方だと、ひとりの職務範囲が広く、タスクに忙殺され中長期課題に集中できなくなりがち
- 創業年数が長く慣例が多くなり、自由度が下がるから
- 事業ドメイン的に制約条件が多く、自由度が下がるから
- ボトムアップを促す目標設定制度が無いから
- 以上、ボトムアップ文化は自然にはできないから、そこを気にして見る人が要る
- スタートアップ初期は組織構造がなく、メンバーみんながなんでもやる。立ち上がりはこの形が合理的。
- 課題感が出てから、組織への施策を行う方が良い
- 現状分析と改善案の立案
- 過去の成功事例をそのまま適用してもうまくいかない。現在のチームで起こっている問題と原因に向き合って改善する
- ジョン・ゴールという人が “Systemantics” という本で述べたこと。
- すべての複雑なシステムは、最初の単純なシステムから進化した。いきなり複雑なものを作ってもうまくいかない
- 一見遠回りに思えても、納得して身につけながら進んだ方がよい。個人にもチームにもあてはまる真理だと思う