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

マネジャーが視野に入ってきたテックリードという今の立場で必要な部分を読んだ。実際にマネジャーになったときには、4章以降を読み返したい。 Linkedinのプロフィール作成や、転職の面接試験にあたって、自分がどのようなマネジメント経験とスキルを持っているかを棚卸して説明するのにも、本書は活用できそうだと感じた。 3章　テックリード 今の立場として読んだ。 ・テックリードは、ソフトウェア開発者兼チームリーダーという役割を果たす。自分ひとりが担当する作業の計画・調整から、プロジェクト全体の計画・調整と主導へと視点を変えなければならない。 ・優秀なテックリードの特質として、アーキテクチャを把握していること、技術的な意思決定を主導（独断ではなく関与）することが挙げられる。 ※これを読んで、ここ10年の自分の経歴はテックリードであったのだと認識できた。 4章　人の管理 5章　チームの管理 次のステップへの備えとして読んだ。 ・勤務評価の時期を待たずに、常日頃から「継続的なフィードバック」をすることが重要。日頃からチームメンバーを観察し、長所や功績を見つけてあげる。肯定的なフィードバックを続けていると、否定的なフィードバックに耳を傾けてもらいやすくなる。 ・ピーターの法則を回避するために、チームメンバーをある職位に昇進させる以前から、その職務を課す。そのために必要であれば、チーム内での仕事の割り振りを再検討する。 ※その人に昇進後の職務への適性があるかを判断するためと理解した。今の上司が私に対してやっていることが、まさにこれだと納得した。 ・チームメンバーが適切な判断を下すためには、目標だけでなく、その目標がなぜ設定されたのかというコンテキストあるいは目的を把握している必要がある。 6章　複数チームの管理 役立ちそうなところを拾い読みした。 ・委任するかの判断基準 頻繁で単純な仕事は委任。 頻繁でなく単純な仕事は自分で。部下への説明に時間を取られるくらいなら、自分でやってしまった方が手っ取り早い。 頻繁でなく複雑な仕事は、マネジャー候補の訓練の機会として活用。勤務評価を書く際に見習いとして同席させたり、人材募集の計画立案時に意見を言わせたりといった工夫により、有望な後輩に伝授する。 頻繁で複雑な仕事は、有望なチームメンバーの育成に活用。このような機会を逃さず、十分に時間を割いて、マネジャーがその場にいなくても複雑な仕事を引き受けて遂行できる人材を育成する。 ・「はい、それでですね」構文は、ノーと言いづらい場面で役に立つ。「はい」と肯定で受けながら、優先度を見据えた現実的な交渉に持ち込むことを狙う。例えば、別プロジェクトの締め切りを遅らせるなど。エンジニアは「いいえ、それは不可能です」と答える習慣がついているため、このテクニックが使えると、他から一歩抜きん出ることができる。

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