タイトルそのままのエントリーです.
気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています.
- マネジメントをする・しないを含めてキャリアパスどうする?
- マネジメントをやるとして何を教科書にしたら?
- 今どきの開発スタンス・マネジメントってどうしたら?
みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました.
以上の3冊です.
どれも良かったです, 何だったら3冊読んで良かったと思います.
というリコメンドをいい感じにしたいと思いこのエントリーを出すことにしました.
そんな当エントリーのラインナップはこちらとなります.
TL;DR
一行で言うならば,
マネジメント職種およびシニアエンジニア・エキスパートなエンジニアのメンターとしてこの3冊はめっちゃ良著.
ですね, もうちょい詳しく言うと,
- 「マネージャーをやる・やらないに悩む」「やるならシニア職として追求するぜ！」という方は「スタッフエンジニア」を読もう.
- 「マネージャーとしての自信が無い」「何から学べばいいかわからない」方は「エンジニアのためのマネジメント入門」を読もう.
- ITプロジェクト, チームのアジリティを高めるようなチューニングがしたい時に「人が増えても速くならない」がとても良いので読もう.
って所でしょうか.
対象読者
このエントリーは紹介する3冊（スタッフエンジニア, エンジニアのためのマネジメント入門, 人が増えても速くならない）が気になる方および,
既にメンバーとして一人前のエンジニアで次のキャリアが見えている方
に読むことをオススメします.
- ソフトウェアエンジニア（領域・職種問わず）
- 特に以下のキャリアが見えてきている方々
- リーダー的な役割からマネージャーが見えている
- 既にマネージャーである
- マネジメントではなく, シニア（マネジメント以外の上級職*2）系のキャリア（シニアエンジニア・シニアエキスパート的なポジション）である
- マネージャーやシニアになって社内に良いメンターがいないと感じている*3
だいたいこんな感じですかね, 少なくともエンジニアとして初心者・初級者向けではないことをご了承ください.
スタッフエンジニア
ソフトウェアエンジニアが、マネジャーやCTOといったマネジメント職に進むのではなく、技術力を武器にテクニカルリーダーシップを発揮して、エンジニアリング職のキャリアパスを登っていくための「指針」と「あり方」を示します。
※書籍の紹介文から引用
そんな紹介文通りの本です, ちなみに「スタッフエンジニア」という言葉は「超上級のエンジニア」という意味だそうです, 言葉の定義が中々独特ですが.
私個人としても前職ではシニア・エンジニア（参考記事）, ここでいうスタッフエンジニアをしていたので気になって読んでみましたが,
最も優れたエンジニアは、実在する問題に対して合意を得ること目的にミーティングへ赴き、さまざまなニーズや味方があることを理解しながら、全員の足並みをそろえるには何をすべきか見極めようとする。
※「スタッフエンジニア」の一節「絶対に間違えない方法を学ぶ」より引用
この一節を読んで, 「これだよこれ！！！」っていうのを連呼するぐらい色々と振り返り・学びができました.
言い換えると, 「スタッフエンジニア（シニア職）こそリーダーシップが大事」って事なんですよねと.
リーダーシップは大事
個人的には,
マネージャーなどのマネジメント職種は勿論, 非マネジメント職種であるシニア職もリーダーシップが求められる.
と思っています.
これは現職のマネージャー職でも当然あるのですが, 前職のシニア・エンジニア職でも,
- ビジネスの意思決定において技術系の課題の比重が重い時に上級職・専門職として意見を問われる&意見に責務を持つ.
- ジュニア*4だったり若手のメンタリング・キャリア志向に関しても「中川さん経験豊富だから」的な感じでこれまた意見を求められる&勿論責務もある.
- 上級職・専門職（&経験豊富）なメンバーとしてのシニア（スタッフエンジニア）である以上, 意見が重要になってくるのである種のリーダーシップが存在する.
スポーツで言えば監督じゃないけどキャプテンだったりリーダーだったり的な所ですかね, そういう人が芯を強くチームを率いないと結果がついてこないとかあるので*5, その視点を再確認する意味でもスタッフエンジニアは良著でした.
ちなみに本の構成的に,
- スタッフエンジニア（シニア）としての役割やスタンス, 期待値
- もっといい感じにキャリアを渡るための転職指南
- 実際のスタッフエンジニア達のインタビュー
など, ページ数の割にはコンテンツが盛りだくさん過ぎて最高に良かったです.
エンジニアのためのマネジメント入門
エンジニアのためのマネジメント入門書です。エンジニアのキャリアパスの1つに「マネジメント」があります。
エンジニアリング領域の知見を生かして、複数のチームメンバーをマネジメントする。エンジニアリングマネージャーとも呼ばれる、この仕事は、エンジニアにとっては多くの場合未知の領域です。エンジニアリングとマネジメントでは求められるスキルも異なり、仕事の進め方も大きく異なるからです。
マネジメントを成功させるには、マネジメントの知識を学び、エンジニアからマネージャーへの「転職」ともいえる大きな変化を乗り越える必要があります。
本書ではマネジメントの基礎知識や実践的なトピックを扱い、エンジニアがマネージャーとして働くための第一歩を解説します。
※書籍の紹介文から引用
意外とこのレイヤーの本が無かった気がするという意味でも良著でした, この紹介通りの本です.
私自身, 現職もそれ以前も見様見真似, 時には先にマネジメントやCxOをやってる方からお話を聞いたりしてマネジメントを学んだのですが,
- チームメンバーやステークホルダーとのコミュニケーション
- チームをいい感じにエンジニアリングする
- 組織マネジメント・戦略実現
この辺りの観点に触れつつ, 順序立てて整理した上で手法を紹介していて過去に学んだことの整理にも最適でした.
本の紹介通り, エンジニアからマネージャーへの「転職」ともいえる大きな変化 この岐路に経っている方の参考として最高だと思います.
マネジメントへの「転職」
エンジニアが初めてマネージャーになることは、今までと違う世界へ足を踏み入れる必要があり、転職すると言っても過言ではないでしょう。
※「エンジニアのためのマネジメント入門」第一章「あなたは転職した」より引用
これは本当にそうで,
- 大抵の場合, 上司や偉い人からの指名なのである日突然マネージャーになる（転職してマネージャーになるのは稀）
- プレーヤーとしてエンジニアリングをして価値を出す仕事とは期待値がまるで変わる
- 同僚間の相談先も絞られる（いいメンター・参考にすべき人が少ない）シチュエーションも起こりがちで悩ましい
マネジメント職には本当に良いメンター的な本だと思いました.
もっとも私の場合は「マネージャーがやりたくて転職してなった」という, 「転職してマネージャーという稀なケース」だったのですが, それでも
- ティーチング・コーチング・フィードバックの基礎の再確認
- チームをエンジニアリングするためのリーダーシップ・スタンスの違い（サーバントリーダーシップの使い所など）
- 戦略実現のための組織マネジメントやプランニング, 組織デザインの話
この辺が本当に面白くて読み応えありました, いいメンターが居ないマネージャーには特にオススメしたいです.
人が増えても速くならない
最後に紹介するはちょっと傾向が違う本ですがこれもマストリードな一冊です.
ユーザー数が伸びるにつれて多くの要望が出てきても、新しい機能をスピーディーに追加できなくなってきた。
ちょっとした修正のはずなのに、ものすごく時間がかかる。
――そのようなことが起こる原因は、ソフトウェアが変化に適応できないから。
※書籍の紹介文から引用
マネジメントをしているとメンバー時代以上に納期やリリースに敏感になると思います.
その時に「どうやってアジリティを高めるかな？」と悩み始めたら読んでほしい一冊です.
倉貫さんの本は「ザッソウ本」など, プロダクトマネジメントやアジャイルな視点・観点で愛読していまして,
多分出ている本は基本読んで感想を書いているはず...
私の感覚としては, 「ITプロジェクトおよびチームのアジリティを高めるヒントを得る時に読む」ようにしています.
アジリティを高めるとは
このサブタイトルはカッコつけて上手く書きましたがもうちょっと雑に言うと,
マイクロマネジメントなんかしないでいい感じにコミュニケーションしながらITプロジェクトに取り組んでさっさとデリバリーしようぜ！
ということです.
倉貫さんの思想・手法は「アジャイルなエンジニアリング&継続的に学んで価値を出すのに注力して結果提供速度を速める」事に振り切っていると私は思っていて,
- チャットなどを使って、メンバー同士でとても密にコミュニケーションしています。なぜなら、複数人でソフトウェア開発をする際は単純な分業はできないため、コミュニケーションが欠かせないからです。
- ポイントは「機能ありきで期間を見積もる」のではなく、「期間ありきで機能を見積もる」ことです。
※「人が増えても速くならない」より気になったポイントを引用
相変わらず良い言語化がされていて学びが多かったです.
またこのブログエントリーはマネジメントの話なのでそこに関する所で触れておくと,
（ソフトウェア開発は）経験値の差で圧倒的な生産性と品質の差が出てくるクリエイティブな仕事なので、むしろ1人ずつの違いを活かすような、プロスポーツのアスリートやアーティストのマネジメントに近い考え方で取り組むほうがいいでしょう。
※「人が増えても速くならない」の一節「クリエイティブな仕事の属人化を解決する」より引用
上記を代表するようなチームの生産性を高めるための考え方やバッドプラクティスにも触れていて読み応えがある一冊です.
結び - マネージャーのキャリアとは
以上, このエントリーでは
この3冊の紹介をしました, どれもマネジメントの参考になるのでオススメです.
エンジニアのためのマネジメント入門の件でも触れたように,
エンジニアが初めてマネージャーになることは、今までと違う世界へ足を踏み入れる必要があり、転職すると言っても過言ではないでしょう。
ほんとこれだと思っていて, マネジメント職種に転職したつもりで学んだり実践するのがいいのかなと思います, メンバーとは色々違うので.
マネージャーとして悩んでいる, マネージャーになりたい（なりたくない）, などなど色々あるでしょうがこのエントリーが何かしらの参考になると嬉しい限りです.
*1:私としてはマネジメントの仕事をすることに振り切りと志望がある一方, 手は動かしたい欲は常にあるので悩みは絶えないです, なので個人開発をしている訳ですが.
*2:シニア＝年が上, という意味もありますが「他のメンバーの模範となるような」という上級職という意味のほうが最も強いです, 単に年寄りなだけではシニアじゃないので注意（若い人でも優秀なエンジニアはシニアになり得ます）.
*3:これは割とあるあるだと思うんですよね, マネージャーにもメンターは必要なのですがどこにいるのかわからない問題🤔
*4:これもシニアの定義と同様, 年齢的なものとは別の視点だったりします. 私（43）より年上だったり, アラフォー・アラフィフのジュニアだっているのですから.
*5:主将やリーダーって人格はもちろん, 怪我がちだったりネガティブな人って選ばれにくいんですよ, これはエンジニアも同様かもしれない.
