はじめに
X(旧Twitter)で話題になってたのが気になって読んだ。個人的には、2章と3章が特に良かった。この二つの章では、チーム作りや組織作りに関する話題が多く書かれており、どんなチーム構成がいいんだろうか?どんな感じでコラボレーションするのがいいんだろうか?といったことで悩んだことある人ならすごく参考になると思う。書籍で整理されまとまってるのを読むと、やっぱりこういう悩みはみんな悩むんだな、あるあるなんだなということもわかったので、それも良かった。
後半は採用や評価の話題で、アプローチ方法や考え方についての内容がしっかり書かれてたので、この領域で悩んでる人には参考になりそうだと思う。
エンジニアリングマネージャーに限らず、チームづくりやエンジニアリング組織について興味がある人におすすめできる一冊。
目次
✅ 第1章 導入:重要なパズルを解くために
✅ 第2章 組織:機能する組織を作り、維持する
✅ 第3章 ツール:変化をマネジメントする手法
✅ 第4章 アプローチ:問題解決につなげる
✅ 第5章 文化:継続的に取り組んで育成する
✅ 第6章 キャリア:同僚と自分に対して責任を持つ
✅ 第7章 さらに先へ
以下は章ごとの感想とメモ書き
第1章 導入:重要なパズルを解くために
💁🏻♂️ 感想
この本の著者は、エンジニアリングマネージメントの分野のことを、一連の優雅でやりがいのある重要なパズルと言っていて、それはつまりどういうことなんだろうか、と続きが気になった。
第2章 組織:機能する組織を作り、維持する
💁🏻♂️ 感想
チームの体制やプロセスについて考えることが多いので、成長するチームの4状態はとても参考になった。チームのサイズ感はみんな悩むんだな。
📝 memo
-  組織デザインと発展のアプローチにはどんなものがあるか? - 基本的なところだと、チームのサイズを決めること
 
-  チームのサイズを決める時の指針にはどんなものがあるか? - 本書によると5人から8人が安定すると書いてあるが、オンコールの対応を考慮した人数になっていそうなので、組織によって適切な人数は変わりそう。
 
-  小さなチームはチームではないとはどういうことか? - チームの重要な要素のひとつは、個人が構成している複雑性(個人の特性や能力)がチーム単位で抽象化される点にある。4人未満のチームは抽象化に漏れが多く、個人で動く場合と見分けがつかない。
 
-  既存チームが運用で身動きが取れない場合、イノベーションのために別のチームを作ることはよくあるやり方ですが、チームを分けず既存チームでイノベーションをおこす方法にした場合のメリットはなんですか? - 高い士気と学習する文化が作られる
 
-  成長するチームの4状態とは? -  遅延 - バックログが毎週伸びてる状態
- 改善策は、人を採用する
 
-  現状維持 - 重要な仕事は片付けているが、技術的負債の解消には取り組めていない、あるいは新規プロジェクトには取りかかれないといった状態
- 改善策は、仕掛かりを減らす
 
-  負債返済中 - 負債返済中
- 改善策は、時間を増やす
 
-  革新 - 技術的負債が少ない状態
- 改善策は、ゆとりを増やす
 
 
-  遅延 
-  ゆとりが必要な理由とは? - チームが余剰能力を大いに活用して次第に、そして革新的な方法によって、チーム内を改善できることである
- 余裕があるチームは組織のデバッガー機能する
 
-  ゆとりを生むためにはどうしたら? - チーム間でスコープ動かし、チームは維持すること。人を動かすことはコストが高い。
 
-  システムの再実装後マイグレーションが生産性を下げるのはなぜですか? - マイグレーションが失敗すると、システム再実装のループが拡大するから。
 
-  組織的負債とは何か? - 技術的負債の組織版
- 偏見を抱えた面接プロセスや不公平な報酬の仕組みなど
 
第3章 ツール:変化をマネジメントする手法
💁🏻♂️ 感想
普段の仕事でこういう時どうしたらいいんだろうなと思ってることがたくさん書かれてた。キャリアのこと、リーダーシップのこと、社内学習コミュニティーの話など。特に、マイグレーションについては、最近気になってたトピックだったので、すごく参考になった。
📝 memo
-  変化を外側から主導するリーダーの役割とは? - 幹部へのプレゼン
- モデル、ドキュメント、シェアを使った改善
 
-  移行期間中に接着剤として内側から機能する役割とは? - 戦略やビジョンを考える
- マイグレーションの戦略を考える
- 組織再編を行う
- キャリア開発について考える
- 学習コミュニティを作る
 
-  システム思考とは? - 問題をシステムとして全体をとらえ、解決を目指す思考方法
- システム思考の基本的な考え方は、イベント間のリンク[各事象の関連性]は見かけよりも捉えにくい
- 前もって準備しなくても、「物事がどのように機能するか」についての仮説をすばやく検証できる
 
-  開発者のベロシティとは?(開発に関する物事の速度) - デリバリーのリードタイム
- デプロイメントの頻度
- 変更の失敗率
- サービスの復旧時間
 
-  組織が大きくなった場合のチーム間のアプローチを調整するための効果的なアプローチとは? - 個々の案件に深く入り込む対応はスケーラブルではない。
- 戦略とビジョンについてチームと合意形成するアプローチが効果的。
 
-  戦略とは? - 特定の課題を解決するためのトレードオフと行動が記された、基盤となるドキュメント
- 特定の課題の制約に対処するための、特定の行動を推奨するもの
-  3つの工程 - 診断
- 基本方針
- 行動
 
-  具体例 - 他チームとの連携方法、エンドツーエンドのAPIのレイテンシー[遅延]の管理方法、インフラストラクチャのコスト管理の方法といった戦略
 
 
-  ビジョンとは? - 密に協力していない個々人が整合性のある意思決定を下すことを可能にする、目指すべき理想を示すドキュメント
 
-  良いビジョンを成り立たせるための項目とは? - ビジョンステートメント
- バリュープロポジション
- ケイパビリティ
- 将来はなくなる制約
- 将来の制約
- 参考資料
- ナラティブ
 
-  良いビジョンを書くためのポイントは? - ドキュメントを検証する
- 定期的に更新する
- 現在形を使う
- シンプルに書く
 
-  悪いゴールとはどんなものですか? - 単なる数字と区別できないゴール
- 例「ビルド時間を2秒以下にする」や「8つの大きなプロジェクトを完了する」など
 
-  良いゴールとはどんなものですか? -  以下の要素を含んでる - ターゲット(到達したい場所を示す)
- ベースライン(現在の場所を示す)
- トレンド(現在の速度)
- タイムフレーム(変化の期間)
 
 
-  以下の要素を含んでる 
-  効果的なゴールか確認する方法とは? - その領域をあまり知らない人でも、ゴールの難易度を感じとれるかどうか
- もうひとつはゴールの達成を後から評価できるかどうか
 
-  メトリクスを使って組織変革に導くアプローチとは? - 探索
- 深掘り
- 属性付け
- 文脈化
- ナッジ
- ベースライン
- レビュー
 
-  技術的負債の唯一のスケーラブルな解決法とは? - マイグレーション
 
-  なぜマイグレーションが重要なのか? - 技術的負債に対して意味のある進歩を遂げるために利用できる唯一の方法だから。
- 新しいソフトウェアに移行する能力は全体の速度を決める制約になりやすい。
- マイグレーションは、企業とコードが成長するにつれて、技術的負債を効果的に管理するための唯一の仕組みで、ソフトウェアやシステムをうまくマイグレーションできなければ、技術的負債で苦しむことになるから。
 
-  なんのためにマイグレーションをするのか? - 技術的なレバレッジを作るため
- 技術的な負債を減らすため
 
-  なぜマイグレーションのスケジュールは議論の的になるのか? - マイグレーションは、将来的なゆとりの確保につながる反面、目前に迫った締め切りの仕事への取り組みが手薄になるというジレンマを抱えているから
 
-  良いマイグレーションを実行する方法とは? -  リスク除去 - デザインドキュメントを書いてその内容を検証する
 
- イネーブルメント
- 仕上げ
 
-  リスク除去 
-  組織の成功に多大な影響を与える2つのマネジメントスキルとは? - 技術的なマイグレーションコストの抑制
- 組織再編
 
-  組織とは? - 人の集合
- 組織を構成する個人と切り離されたアイデアの具現化
 
-  キャリアラナティブとは? - (キャリアについての)個人の視点とマネジャーの視点との交点
 
-  キャリアラナティブの運用方法とは? - 1時間かけて、次の1~5年で成し遂げたい事柄をできるだけ多く書き出す
- そのリストを優先順位付けし、次の3~6か月で集中したい項目をいくつか選ぶ
- 次回の1on1で上司と共有する
- 具体的な行動を書く
 
-  なんのためにキャリアラナティブを書くのか? - 自分にとって特別な価値がある方向に進むため
 
-  権限がない状態でリーダーシップを発揮するために驚くべき効果を出すスタイルとは? - モデル、ドキュメント、シェア
-  モデル - チームの健全性の測定し、改善のためのアプローチを行う
 
-  ドキュメント - 効果的なアプローチが見つかったら、解決しようとした問題、経験した学習プロセス、他のチームがそのプラクティスを採用するための詳細について、ドキュメントを残す
 
-  シェア - ドキュメントをシェアする
 
 
-  エンジニアが幹部にプレゼンする際のポイントは? - コミュニケーションのありかたは会社ごとに異なることを理解する。幹部向けにプレゼンしてる人のアプローチを研究する。
- 結論から始める。
- トピックがなぜ重要であるか理由を説明する。
- 誰しもが物語を好む。
- 脱線に備える。
- 直接的に答えよう。
- データに精通する。
- 原理から行動を導こう。メンタルモデルを提供する。
- 詳細を議論しよう。
- たくさん準備して、少しだけ練習する。
- 明確に要求する。
 
-  プレゼンする時のテンプレートはどんな構成が良いか? - トピックをビジネス価値に結びつける
- 歴史的な物語を確立する
- 明確な要求
- データに基づく分析
- 意思決定の原則
- 次のステップと完了時期
- 明確な要求に戻る
 
-  社内に学習コミュニティーを作るのはなぜ意義深いのか? - 同僚からのフィードバックが得られる
- チームの学習速度が上がる
 
-  学習コミュニティーを作る時のポイントは? - 講師でなくファシリテーターになる
- 簡潔なプレゼン、長い議論
- 少人数のグループに分割する
- 全体のグループに学びを共有する
- すでに知っているトピックを選ぶ
- 経験豊富な人の参加を促す
- 事前学習を任意にする
- チェックイン
 
第4章 アプローチ:問題解決につなげる
💁🏻♂️ 感想
上司とのコミュニケーション方法について書かれてた内容が良かった。上司に知ってもらうべきこと、上司について把握すべきことのリストは、普段の仕事でも試してみたい。上司をマネージメントするという発想がなかったのでそういう考え方もあるんだなと発見だった。
📝 memo
-  ポリシーを一貫して適用することが難しい理由とは? - 機会の範囲が狭まることを受け入れることになる
- 局所的には次善策となる(局所的には非効率につながる)
 
-  ポリシーを弱める原因は? - 例外を認めること。みんなの公平感が失われ、ポリシーを弱めてしまう。
- 例外が日常化すると、例外処理にリーダーの時間の大部分が失われてしまう。
 
-  では例外が発生したらどうしたらいいか? - 例外をエスカレーションし、エスカレーションが十分に集まったら、ポリシーを更新する。
- 実運用する際は、ポリシーを更新する時期を宣言する。そうすることで、新しいポリシーを評価するための時間を確保できる。
- ポリシーが頻繁に更新される場合、ポリシーと例外の区別がつかなくなるため、一歩引いて問題を文書化する。
 
-  意見の相違を生みがちな二つの項目とは? - 速度
- 優先度
 
-  取り組んでることではなく、終わらせてることが重要な理由は? - 部分的な完成には価値がなく、チームにとっての制約は最終段階に存在することが多い
 
-  現在の制約を明らかにするためにはどうすればいいか? - カンバンボードを使う。カンバンボードを使うことで、実行の制約になるものを説明できるようになる。
- 制約は、技術的負債やといるに帰着する。これらを説得力のある言葉に置き換えないといけない。
 
-  速度に関する議論の最高のアウトカムとは? - 重要な制約に取り組むための現実的なアプローチを特定すること。制約に対してリソースが適切に割り当てられてることで、議論を優先度に移すことができる。
 
-  優先順位の説得力のある説明を3ステップとは? - 全ての要求を文書化する(チケットの作成と同等の簡易さが良い)
- タスクを選択するためのガイドとなる原則を作る。
- ガイドとなる原則に基づいてタスクから選択したサブセットを共有する
 
-  速度と優先度についてステークホルダーに理解されない場合どうすれば? - 議論ややりたいことの内容ではなく、関係性の問題なので、ステークホルダーと密接に協力できるような取り組み行うこと
 
-  リーダーシップを発揮するための哲学とは? - 黄金律は非常に理にかなってる。
- チーム全員に各自がオーナーシップを持つ明確な領域を与える。
- 報酬と地位は高品質な仕事を成し遂げることにより得られる。
- 自分が先頭に立つ。自分がやらないことを決して誰かに依頼しない。
 
-  新人マネージャーが最初の数年で行き詰まることとは? - 部下だけをマネージメントする
- 上司だけをマネージメントする
- 上司を一切マネージメントしない
- 局所最適化する
- 採用ではどんな問題も解決しないと思いこむ
- 関係構築に時間を費やさない
- 役割を狭く定義する
- 上司が人間であることを忘れる
 
-  経験豊富なマネージャーが行き詰まることとは? - 前の会社でうまく行ったことをする
- 関係構築に時間を使いすぎる
- 採用によって全てが解決すると思いこむ
- 委譲しすぎて姿を消す
- 現場の実情と乖離する
 
-  いかなる経験のマネージャーでも行き詰まることとは? - チームの大きさを影響力と勘違いする
- 肩書を影響力と勘違いする
- 権力と真実を取り違える
- 委譲できるほどチームを信頼しない
- 他人に時間の管理を任せる
- 問題しか見ない
 
-  上司とうまくやっていくために必要なこととは? - 上司に、あなたについて幾つか知ってもらう
- あなたが、上司について幾つか知っておく必要がある
- お互いについて、知ってることを時々更新する
 
-  上司に知ってもらうべきこととは? - どんな問題を解決しようとしてるのか
- 進捗
- どんな仕事がしたいか(適切な仕事を割り当ててもらうため)
- どれぐらい忙しいか(新たな機会を引き受けられるか知ってもらうため)
- 専門職としての目標と成長領域。退屈と挑戦の間のどこにあるか
- 評価に対する自己認識
 
-  上司とうまくコミュニケーションするためのアプローチにはどんなものがあるか? - 知ってもうらべきことが書いてあるドキュメントを更新し続け上司と共有する
- 1on1で知ってもらうべきことを話す
- 定期的に各要素をカバーする自分の振り返りを書く
 
-  上司をマネージメントするために把握すべきこととは? - 上司の現在の優先事項は何か?
- 上司が抱える問題と主要な取り組みは何か?
- 上司が抱えるストレスはどれほどなのか?どれぐらい忙しいのか
- あなたが上司を助けるためにできることは何か?
- 上層部が上司に優先して欲しいことは何か?
- 上司が改善したいことやゴールは何か?
 
-  エンジニアリングマネージャー職にはどんなタイプがあるか? - マネージャー:チームを直接マネージメントとする
- ディレクター:マネージャーのチームをマネイジメントする
- VP:組織をマネージメントする
 
-  自身の立場が変わって新たな役割が見出せない時の解決方法とは? - 自分自身で組織や自分の方向性を決める
 
第5章 文化:継続的に取り組んで育成する
💁🏻♂️ 感想
やりたいことに対する機会は公平であるべきだと思うけど、その場やチームの雰囲気で決まってしまうことも多いと感じていたので、アプローチ方法など参考になった。アプローチ方法が適切かどうか評価するためにどういった指標を追えばいいのかも書かれてたのもよかった。
📝 memo
-  組織のメンバーに機会を与える最も効果的な方法は? - 適切なプロセスを構造的に運用すること
 
-  機会を創出して分配するための施策にはどんなものがあるか? - あらゆる場面でルーブリックを用いる
- プロジェクトリーダーを選出する
- 予算を明示する
- 参加を後押しする
- 教育プログラムを作る
 
-  機会の分配するための施策の効果測定にはどんなメトリクスがあるか? - リテンション率(従業員が離職せず会社に残ってる割合)
- 使用率
- 等級の分布
- 等級の在籍期間
 
-  帰属意識を高める効果がある施策にはどんなものがあるか? - 毎週定期的に開催されるイベントでの交流
- 従業員リソースグループのコミュニティーを作る
- オフサイトミーティング
- コーヒーチャット
- チームランチ
 
-  帰属意識を高める効果がある施策の効果測定にはどんなメトリクスがあるか? - リテンション率
- リファラル率
- チームランチなどの出席率
- コーヒーチャットの利用回数と完了率
 
-  プログラマーのヒーロー問題とは? - チームではなく、特定のプログラマー個人(ヒーロー)が長時間労働とコミュニケーションコストを最小化することでプロジェクトの課題を解決した結果、ヒーローとヒーローでない人の溝が深まり、プロジェクトが破綻する問題
 
-  プログラマーのヒーロー問題を解決する方法とは? - ヒーローを育ててしまう環境をやっつける
- 燃え尽き症候群によってヒーローをやっつける
 
第6章 キャリア:同僚と自分に対して責任を持つ
💁🏻♂️ 感想
これまでの働き方の変化を振り返るのは、自分自身の成長やスキルの棚卸しになるのでやっておきたい。ふりかえるときに、トランジションに注目するのは、これまであまり考えたことがなかったので、いい観点になりそうだと思った。
採用の話は、この本に書かれてるステップを実践するとなるとかなり時間を費やさないといけなそうな印象。組織が大きくなり始めたら整備しないといけない領域なんだろうなと思う。採用ファネルを定義してメトリクスをとって効果検証できるようにすることが大事と書かれてたのがよかった。評価できる基盤がないと、何かためしても効果があったのか判断できない。
評価も採用と同じで、この本に書かれてるようなステップを実践する場合は仕組みや基盤を作るためにかなりの時間がかかりそうだと思う。このあたりは組織が大きくなり出したら整備しないといけない領域なんだな。
📝 memo
-  キャリアナラティブを紡ぐ方法とは? - 去年の出来事の振り返りを行う
-  働き方を変えるような変化をトランジションとして書き込む - e.g 直属の上司が変わった, チームの目標が再定義された, 大規模の差組織再編があった
 
- トランジションを乗り越えるためにどんなスキルを頼りにしたかを書き込む
- トランジションによってどんな成長機会が得られたかを書き込む
- トランジションの後、価値観や期待されてることがどのように変わったかを書き込む
 
-  良い面接を行うためのポイントは? - 候補者に対して親切であれ
- 面接官全員が求められる人材要件について共通認識を持つ
- 面接でチェックしたいシグナル(応募者が面接官に対して自分の適性、能力などを伝えるための非言語的または言語的手がかりや情報のこと)とその探し方を理解する
- 面接に十分準備して臨む
- 候補者に興味を持っていることを積極的に示す
- 面接官のためにフィードバックループを作る
- どのコンバージョンファネル(決定に至るまでの段階的な工程)でも行えるように計測して最適化する
 
-  シグナルを見つけるための効果的な面接のフォーマットとは? - あるトピックについてあらかじめ準備したプレゼンをしてもらう
- ノートパソコンで既存のコードベースに対して、デバッグや機能拡張をしてもらう
- 実在する製品や機能をデモしてもらう
- ロールプレイを実施する(e.g システムの共同設計、よくないパフォーマンスのフィードバックなど)
 
-  候補者の三大ソースとは? - 既存チームからのリファラル
- 求人ページからのインバウンド
- 企業からの積極的なアウトバウンド(ソーシング)
 
-  コールドソーシングとは? - 知らない人の直接連絡を取る方法
 
-  コールドソーシングの最初のレシピとは? - LinkedInに参加する
- LinkedInで知ってる人をフォローしてネットワークを構築する
- 辛抱強くいる
- 二次的な関係の人につながるため、検索機能を使う
- 誰かがつながりリクエストを受け入れてくれたら、プロフィールからメールアドレスを取得して礼儀正しい短いメッセージを送り、コーヒーに誘うか、電話で話したい旨を伝えよう。
- 予定の取れた相手と、コーヒーを飲みながら会話を楽しもう
- つながりを増やすために毎週1時間を費やそう
 
-  採用ファネルの主要な4つのステップとは? - 候補者の特定
- 応募させる気にさせる動機づけ
- 会社に相応しいかの否かの評価
- クロージング
 
-  業績を管理する3つの要素とは? - キャリアラダー
-  業績評価 - 特定の期間に、その等級での期待値を個人がどれだけ満たしているかを明示的に述べたものである
 
-  業績評価サイクル(パフォーマンスサイクル) - 評価に基づいて一貫した業績を割り振ることを目的として、1年で1回か2回、もしくは4回行われる。
 
 
-  業績評価の典型的な手順は? - 自己評価
- 同僚による評価
- 部下による上司の評価
- マネージャーによる評価
 
第7章 さらに先へ
💁🏻♂️ 感想
チームがうまく機能してる知るためのメトリクス収集は、やりたいなと思ってたのでやり方が気になってる。スプリントがうまくいってるか判断する基準は、チームや状況によるところはあると思いつつ、参考になった。
📝 memo
-  スプリントがうまくいってるか判断するための基準とは? - チームが何に取り組むべきかわかってる
- チームは自分たちの仕事になぜ価値があるかを知ってる
- 自分たちの仕事が完了したかどうかをチームで判断できる
- チームは次に取り組むべきことを決める方法を知ってる
- ステークホルダーは、チームが取り組んでいることを把握できる
- ステークホルダーは、チームが次に取り組む予定を把握できる
- ステークホルダーは、チームの計画に影響を与える方法を知っている。
 
-  スプリントプロセスで特に重要なものは? - バックログ
 
-  なぜバックログが重要なのか? - タスクの詳細や背景が理解しやすいインターフェースになってる
- 優先順位を決めるのに使える
 
-  チームがうまく機能してるかどうかを知るための運用のベースラインとは? - オンコールの負荷
- インシデント
- 可溶性
- コスト
 
 MEGUMI SHIMABUKURO
 MEGUMI SHIMABUKURO 
