エンジニアのためのマネジメントキャリアパス の商品レビュー

カミール・フルニエ(著者),武舎広幸(訳者),武舎るみ(訳者)

2024/08/18

良書であることは間違いない
ただ分量が異常に多く読むのに3日かかった。

技術系管理職の業務を徹底的に解説している本はおそらくこの1冊、また2年後ぐらいに読みたい。

現在時点では内容が難しいのと分量の多さから読み飛ばした箇所も多い

2023/12/29

> 構造やプロセスといった概念は...「無意味」、最悪の場合「有害」と映ることが多いようです。...私はこうした「構造」を疑問視する人を相手に議論するときには...「構造」そのものではなく「学習」を、「プロセス」そのものではなく「透明性」を全面に押し出して話を進めるのです。
構造そのもの、プロセスそのものに価値があるからではなく、成功も失敗もひっくるめて経験から学びたいから、..成功例を共有し、失敗例から得た教訓を..共有したいからといったぐらいです

2023/10/26

マネジャーが視野に入ってきたテックリードという今の立場で必要な部分を読んだ。実際にマネジャーになったときには、4章以降を読み返したい。
Linkedinのプロフィール作成や、転職の面接試験にあたって、自分がどのようなマネジメント経験とスキルを持っているかを棚卸して説明するのにも、本書は活用できそうだと感じた。

3章　テックリード
今の立場として読んだ。
・テックリードは、ソフトウェア開発者兼チームリーダーという役割を果たす。自分ひとりが担当する作業の計画・調整から、プロジェクト全体の計画・調整と主導へと視点を変えなければならない。
・優秀なテックリードの特質として、アーキテクチャを把握していること、技術的な意思決定を主導（独断ではなく関与）することが挙げられる。
※これを読んで、ここ10年の自分の経歴はテックリードであったのだと認識できた。

4章　人の管理
5章　チームの管理
次のステップへの備えとして読んだ。
・勤務評価の時期を待たずに、常日頃から「継続的なフィードバック」をすることが重要。日頃からチームメンバーを観察し、長所や功績を見つけてあげる。肯定的なフィードバックを続けていると、否定的なフィードバックに耳を傾けてもらいやすくなる。
・ピーターの法則を回避するために、チームメンバーをある職位に昇進させる以前から、その職務を課す。そのために必要であれば、チーム内での仕事の割り振りを再検討する。
※その人に昇進後の職務への適性があるかを判断するためと理解した。今の上司が私に対してやっていることが、まさにこれだと納得した。
・チームメンバーが適切な判断を下すためには、目標だけでなく、その目標がなぜ設定されたのかというコンテキストあるいは目的を把握している必要がある。

6章　複数チームの管理
役立ちそうなところを拾い読みした。
・委任するかの判断基準
頻繁で単純な仕事は委任。
頻繁でなく単純な仕事は自分で。部下への説明に時間を取られるくらいなら、自分でやってしまった方が手っ取り早い。
頻繁でなく複雑な仕事は、マネジャー候補の訓練の機会として活用。勤務評価を書く際に見習いとして同席させたり、人材募集の計画立案時に意見を言わせたりといった工夫により、有望な後輩に伝授する。
頻繁で複雑な仕事は、有望なチームメンバーの育成に活用。このような機会を逃さず、十分に時間を割いて、マネジャーがその場にいなくても複雑な仕事を引き受けて遂行できる人材を育成する。
・「はい、それでですね」構文は、ノーと言いづらい場面で役に立つ。「はい」と肯定で受けながら、優先度を見据えた現実的な交渉に持ち込むことを狙う。例えば、別プロジェクトの締め切りを遅らせるなど。エンジニアは「いいえ、それは不可能です」と答える習慣がついているため、このテクニックが使えると、他から一歩抜きん出ることができる。

2023/10/15

マネジメントの基本、メンタリング、テックリード、人・チーム・複数チーム・複数管理者の管理、経営幹部、文化構築。
特にテックリードの立ち位置と人間像、チーム管理上のプロジェクトの進め方やメンバーの状態、意思決定など現時点でも共感して役立つものが多々あった。
守るべきは何か。
270冊読了。

2023/10/03

2023年10月1日読了。IT技術者が年次を重ね管理職となりテックリード・CTOなど役職を担うとき、どうあるべきか？どのような課題がありどう取り組むべきか？を説明する本。技術一本やりできたメンバーがマネージャー就任を打診され悩んだり断ったり挫折したりするケースは多々あると思う、課題にジャストフィットした本と感じた。「管理職になってもコーディングは続けるべし（もちろん時間は減るが）」というメッセージには「確かに…」と言うしかないな。結局、技術者だろうとメンバーだろうと仕事する以上「コミュニケーション」からは逃れられず、誰かがやんないといけないポジションでもあるわけで、なった以上はコミュ力を全面展開して視野を広く取り組むしかない、ということなのだろうな。著者は女性だがずっと男性と思い込んでいた、というのは私個人の「IT管理者かくあるべき」というバイアスによるものか、反省。

2023/03/18

エンジニアリングマネージャーの道を示してくれる本で、自分がこれまで直面した課題、今直面している課題、未来に直面するであろう課題が書かれている
何よりも共感できる話がたくさんあり、伴走してくれているような気になる本だった
折に触れて読み返すと思う

2023/02/08

メンター役から、さまざまなランクの管理者を経て、経営幹部に至るまでエンジニアのキャリアパスをたどりながら必要なスキルセットの変化と濃度を認識することができる一冊。
それぞれのキャリアは独立しているわけではなく、延長線に存在するので、自身の環境や役割に変更があった際に再度読み返すことで納得感は変化するだろうと思った。

特に印象深い文章は、
「構造」そのものではなく「学習」を、「プロセス」そのものではなく「透明性」を。
構造とは、複雑な長期の仕事をいかに進めるかといった仕組みや筋書き。対象がソフトウェアだろうがチームだろうがプロセスであろうと同じ。優れたリーダーはチームの基本構造や人間関係を見定めて構造を練り、それをチームの長期目標の達成を促し、個々のメンバーに最高の結果を出せるやり方で肉付けできる。

2023/01/02

春から管理職を打診されたので読んでみた。
今までは新人〜中堅あたりで管理職になるというイメージがつかめなかったが、この本を読んで気が引き締まった。
技術に集中するよりもマネジメントの方に進むのが私には向いていそうだと思った。
また職位が上がる時に読もう。

2022/09/09

2年前に読んだのを失くしたので再購入して再読しました。以前よりマネジメントの規模が大きくなってきて、後半（複数チームの管理）まで実感を持って読めました。ちょうど直接コードを書く機会は自然に減っている中で、能動的に機械をつくっていこうと思えました。マネジメントや組織論の本はだいたい途中で飽きてしまうのですが、本書は単に興味深く読めました。何度も再読したいです。

2022/05/06

エンジニアとしてのキャリアや目標が曖昧で、
なんとなくテックリードになりたいという思いだけがありました。
一度自身のキャリアプランや目標を定めたいと思い、本書を読みました。

本書では、エンジニアが管理を行う上でどのようことに注意し、
キャリアを積んでいけばよいかが書かれています。
またテックリードがどのような存在で何をすべきなのか
記述されており自身のキャリアを見つめ直す良いきっかけになりました。

管理する側だけでなく、管理される側としてもどうすべきか
ということが記載されておりますので、
エンジニアにはおすすめの1冊だと思います。