エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか

WillLarson / 岩瀬義昌

エンジニアリングマネジャーとして成長し続けるための秘訣を明かそう―
『スタッフエンジニア』著者が、エンジニアが活躍できる効率的でやりがいのある組織を作りたいリーダーへ贈るマネジメント本、待望の日本語版。

「人は会社を去るのではなくマネジャーのもとを去る」という言葉がある。マネジメントはあらゆる組織で重要だが、どうするべきか誰からも教わらないことが多く、構造化もされていない。複雑なマネジメントの課題に対してよい解決策を得られるか否かで、チームが満足するか不満を感じるかの違いが生まれる。そして最終的には、企業の成否を左右する。
チーム編成から、士気・成果向上、キャリア形成、プロダクト管理、文化醸成、技術継承、技術的負債、上層部との調整まで、エンジニアリングマネジメントのあらゆる課題について、よりよい解決策への道筋を示す。

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 言語・プログラミング
• 出版社: 日経BP
• ページ数: 256ページ
• 電子版発売日: 2024年05月27日
• コンテンツ形式: EPUB
• サイズ(目安): 9MB

[ブクログ · ★★★★★]

エンジニアの会社で、著者がどうマネージメントを考え、実践してきたかが記載されており、大変参考になります。

[ブクログ · ★★★★☆]

組織設計・制度設計など、マネージャー以上の役職の人には役立ちそう。
自分にはまだ早かったように感じる。

[ブクログ · ★★★★☆]

著者の経験に基づき、実践的なマネジメント手法を構造化したうえで「組織」「ツール」「アプローチ」「文化」「キャリア」に分類している。
それぞれの章においては、エンジニアリングマネージャーが遭遇する課題やそれに対する具体的な対策を解説している。後半の採用や評価に関しての話題とアクションは具体的なので、悩んだ際に参考にしたいと思う。

[ブクログ · ★★★☆☆]

第1章：導入

第2章：組織　機能する組織を作り、維持する
　6～8人のエンジニアを支援：マネージャー
　4人未満のエンジニアを支援：テックリードマネージャー
　4人～6人のマネージャを支援：マネージャーのマネージャー

　1~2人の小さなチームはチームではない
　→抽象化に漏れが多い　個人で動く場合と見分けがつかない
　　
成長するチームの4段階
　1.遅延　　　ハードワークだが進捗が乏しい　士気低い
　　→新しく人を増やす
　2.現状維持　重要な仕事はできている　士気は多少あり
　　→現在の仕事を減らす
　3.負債返済中　技術的負債の解消に取り組み、その恩恵を受けている
　　→ゆとりをもたせる
　4.革新　　　士気が高い　ユーザーニーズを満たす仕事にとりくむ
　　→さらにゆとりで、イノベーションに取り組む

チームファーストに徹する
　チームが結束するには時間がかかる。解体すると結束が初期化される
エンジニアが増えるほど問題も増える

サクセッションプランニング（後継者育成計画）を進める
　同僚が何をしているかを理解する
　ギャップを埋める

第3章：ツール　変化をマネジメントする手法
　システム思考、メトリクス、ビジョン
・システム思考
　プロダクトマネジメント：
　　エンジニアリングとプロダクトそれぞれでリーダシップが必要
　　プロダクト開発
　　　問題の発見→問題の選定→解決策の検証→実行→問題の発見→・・・

戦略とビジョンの合意形成
　戦略：具体的に、実用的
　ビジョン：方向性を示す、願望的に長期視点
　文書化し、内容を検証する、定期的に更新、シンプルに記載

メトリクス
　ゴールの定義
　　ターゲット：到達場所
　　ベースライン：現在の場所
　　トレンド：現在の速度
　　タイムフレーム：変化の期間

マイグレーション
　技術的負債の唯一のスケーラブルな解決法

リーダシップの発揮
　モデル：プロセスを繰り返し試行錯誤する
　ドキュメント：採用方法を説明する
　シェア：ドキュメント送付、プラクティス採用を義務付け
タイムマネジメント
　四半期ごとの時間の振り返り
　短期的な品質よりも長期的な成功を優先する

学習コミュニティをつくる
　簡単なプレゼン、長い議論
　経験豊富な人の参加を促す
　事前学習を任意にする
　少人数のグループに分割する
　全体のグループに学びを共有する

第4章：アプローチ　問題解決につなげる
　ポリシーに従う、例外に従わない
　よいポリシーは制約をもたらす
　優先順位の確定
　　すべての要求を文書化する
　　タスク選択するための原則を作る
　　原則に基づいて選択したサブセットを共有する
マネジメントの哲学
　強い関係性はどんな問題にも勝る
　プロセスよりも人が大事
　困難なことからすぐ取り込む
エンジニアリングマネージャーが行き詰まる
　部下または上司だけをマネジメントする
　関係構築に時間を費やさない、または使いすぎる
　局所最適化する
　
第5章：文化　継続的に取り組んで育成する
　機会とメンバーシップを提供する
　ルーブリック（評価指標）を持ちいる
　定期的に開催されるイベントを設ける
　ヒーローを作らない、頑張りすぎをやめる　
第6章：キャリア　同僚と自分に対して責任を持つ
　キャリアナラティブを紡ぐ
　　去年の出来事の振り返り
第7章：さらに先へ
　他書籍の紹介など

[ブクログ · ★★★☆☆]

個人的には３章と４章が一番ハマる章で良かった。改めてみるやることがとても多いと改めて思う。会社の状況を見て人や組織を育てることは難しい、しかしそこにマネジメントはそこにやりがいがあると感じる。

[ブクログ · ★★★☆☆]

正直読みづらい。
技術者というよりはエンジニアマネージャーのやってきたこと書に近く感じる。
しかし、エンジニアリング組織を運営するためのタスクが列挙されているので、傍らに置いておく価値がある。
また、1番最後にシステム系の論文の紹介がされており、システム系論文のとっかかりを探す人にとっては非常に有用。

[ブクログ · ★★★☆☆]

マネジメントに悩んだので流し読みました。書かれていることとは異なりますが、いまの自分にとってマネジメントのボトルネックはエンジニアリングであると自戒しました。

[ブクログ · ★★★☆☆]

概要:

本書は、システム・エンジニアリング分野におけるチーム・マネジメントの教科書として位置づけられる。ヌケモレなく、マネジメントに必要な基本が淡々と述べられており、筆者の主観的な経験談や感情的な記述はほぼ見られない。そのため、良くも悪くも読み物としての面白さは期待できないが、マネジメントの基礎を体系的に学ぶには最適であると言える。逆に言えば、本書の内容がピンと来ないと感じるマネージャーは、その職を再考すべきかもしれない。それほどまでに、基本に忠実で網羅性の高い内容となっている。

特に印象に残った点:

エンジニアのマネジメントも、結局はマネジメントの基本の組み合わせであるという原則は改めて認識させられた。しかし、実務においては、エンジニア一人ひとりの多様性を無視することはできない。それぞれの個性やスキル、興味範囲だけでなく、仕事へのスタンスも大きく異なる。特に、私の経験が異業種のメンバーが混在するプロジェクトが多かったため、その多様性の大きさを痛感している。ソフトウェア開発の現場では、ある程度の役割分担やスキル構成の前提があるかもしれないが、多様なバックグラウンドを持つメンバーをまとめ、成果を出すためには、より個別に向き合う必要性を強く感じる。

本書の内容と自身の経験:

本書に書かれている原則は理解できるものの、それを多様なメンバーに対してどのように適用し、具体的な成果に繋げるのか、という点に大きな課題を感じている。教科書的な知識だけでは解決できない、個々のメンバーとのコミュニケーションや動機づけ、そしてチーム全体の方向性を示すリーダーシップが不可欠であると改めて認識した。特に、異業種のメンバーとの協働経験が多い私にとっては、本書のような普遍的な原則だけでは対応しきれない場面が多いと感じる。

今後の課題と疑問点:

本書で得られた知識を、実際の多様なチームでどのように活かしていくかが今後の大きな課題である。理想としては、本書のような普遍的な原則をベースにしつつ、個々のメンバーの特性や状況に応じた柔軟な対応策が示されていると良かった。具体的なモデルやソリューションが提示されていれば、より実践的な学びになっただろう。

深層心理の反映:

本書の網羅性と客観性は評価しつつも、どこか物足りなさを感じているのは、私がマネジメントにおいて、単なる知識や原則だけでなく、もっと人間味あふれる、泥臭い部分も重要だと考えているからかもしれない。また、教科書的な正しさを求める一方で、現実の複雑さや多様性に対する理解も深く、そのギャップに苦悩している様子が伺える。過去の異業種混合チームでの成功体験から、多様性を活かすマネジメントへの強い願望がある一方で、具体的な方法論を見出せていない現状への焦りも感じられる。普遍的な知識だけでは解決できない問題に対し、具体的な解決策を強く求めている。