Leading Snowflakes：エンジニアリングマネージャー必読ハンドブックの要点まとめ
エンジニアリングマネージャー向けの実践的ガイド『Leading Snowflakes』の重要ポイントを解説。管理職が直面する課題を明確化し、効果的なチーム運営とリーダーシップスキル向上の具体策を提示します。
本記事は AI による翻訳をもとに作成されています。表現が不自然な箇所がありましたら、ぜひコメントでお知らせください。
記事一覧
Leading Snowflakes — 読書メモ
“Leading Snowflakes The Engineering Manager Handbook” — Oren Ellenbogen
管理職として新しく着任すると、すべてが曖昧に感じられます。管理に関する知識は、これまでの仕事の経験や観察、同僚との雑談から得たもので、上司が何をしたとき部下がポジティブに感じ、何をしたときにネガティブに感じるかをなんとなく知っている程度です。そのような断片的な経験と考えしかなく、体系的な理念はありませんでした。そこで私は本を読み始め、各著者の経験を記録し始めました。同じような状況に出会ったとき、「知識の自信」があれば、慌てることもなくなります。
リーディング・スノーフレークス
作者は過去約20年間の職務経験で、元々のソフトウェアエンジニアから管理職へと一歩一歩進んできました。大企業やスタートアップのTechnical LeadやEngineering Managerを務めた経験があります。本書はエンジニアから管理職に移行する際に直面する課題と、それらを整理・解決する方法を詳しく述べています。
私の背景と非常に似ていると感じました。もともとソフトウェア開発をしていて、管理職に初めて挑戦するところです。本に書かれているポイントを通じて、多くの実践的な方法を学ぶことができました！
- 本文は個人のメモであり、一部個人的な見解が含まれています。情報が断片化している現代では、原著を自分で読むことを強くお勧めします。そうすることで体系的に本質を吸収できます。
- ノートの意味は、後で振り返るときに、復習したいポイントを素早く見つけやすくすることです。
- 一部の内容は原文から直接引用しています。
レッスン1. — 「マネージャー」と「メイカー」モードの切り替え
エンジニア（Maker）からマネージャー（Manager）への移行。
タスクを完了し、難題を優雅に解決することは優秀なエンジニアの基準ですが、マネージャーとしてはタスク完了能力で評価されるわけではありません。これはすでに証明されており、評価基準はチームをリードし、推進し、能力を向上させることに置かれます。
しかし、自分を完全にタスクから切り離し、タスクの詳細から完全に距離を置いてチームメンバーとのつながりを断つこともできません。実行結果、優先順位、信頼に関して長期的に大きなリスクが生じます。
だから、管理者になったからといってエンジニアの仕事をしなくていいわけではなく、両方に関わりながら、エンジニア（Maker）と管理者（Manager）の間でバランスを取る必要がある。
エンジニアの時は、連続して中断されない時間が欲しく、コンテキストを維持して難しい問題を解決したいと思います。しかし、マネージャーとしては、頻繁に立ち止まってチームを助けたり、メンバーを気遣ったりする必要があるため、中断されること自体がマネージャーの仕事の一部です。
しかし、同時にエンジニアとマネージャーの両方を兼任する必要がある場合、どうすればよいでしょうか？
作者は2つのカレンダーを作成することを勧めています。1つはMaker（エンジニア）用、もう1つはManager（マネージャー）用です。そして毎朝早くに15～30分を使って自分の考えを整理し、その日のスケジュールを計画します。何をすべきか、どんな会議があるか、連続した空き時間を使ってタスクを解決する（Makerとして）ことができるかを確認します。
作者のスケジュールテンプレート
私たちも集中する時間が必要です
著者によると、現在は管理者であっても、同時にタスクをこなす必要があります。利用可能な空き時間に集中することは、以前よりも重要です。
作者は、集中が必要な時間には、チームメンバーに「今は邪魔しないでほしい」と伝えるための何らかのサインを使うことができると述べています。
方法は、会議室に行く、ヘッドホンをつける、またはデスクに「ON AIR！」のスイッチライトを置くことです。
緊急でない問題の場合は、まずチームメンバーにコメントを残してもらうか、情報をまとめてメールで送ってもらい、集中時間が終わってから対応してください。
エンジニアとして自分が対応可能なタスクの評価
以前のように純粋にエンジニア（Maker）として開発に全力を注げるわけではないため、エンジニアのスケジュールに応じて自分で実行できるタスクを選ぶ必要があります。
チームの技術的なボトルネックにならないようにしましょう。私たちの使命はチームの能力を向上させ、新技術を探求し、会社の対外的および社内の技術視野を広げることです。できることとしては、技術的な問題を事前に調査し、それをチームメンバーと共有して実行を任せること、会社の技術的負債やプロセスの問題を解決して開発効率を上げること、新技術を導入すること、会社の技術をオープンソース化すること、APIを公開すること、対外的なハッカソンを開催することなどがあります。
最も重要なのはバランスです
作者は15〜20％の割合から調整を始めることを提案しています。元々は100％Makerとして働いていたのを、今は20％Maker／80％Manager（ただし実際のチームの規模やメンバーの能力によっては50％／50％もあり得る）にするということです。つまり、100％エンジニアリングに専念するのではなく、管理にも多くの労力を割く必要があります。
1:1 を有効活用する
定期的にチームメンバーと1:1を行い、お互いにフィードバックを交換し、学んだことを共有する。
もしマネージャーの仕事があなたのすべての時間を奪うなら
作者は最後に、管理するタスクが多すぎてエンジニア（Maker）としての作業が全くできず、タスクや技術から乖離している場合は、週に数日リモートワーク（WFH）をして会社から離れたり、ハッカソンに参加することを検討すると良いと述べています。
Lesson 2. — コードレビューとしてのマネジメント判断
定期的に管理者としての意思決定をレビューする。
身為エンジニアの時は、ペアプログラミング、コードレビュー、デザインパターンなど、従うだけでスキルを向上させる多くの方法やツールがあります。しかし、マネージャー、特に新人としては非常に孤独を感じます。
私たちは、上司や部下について無知であることを認めたくなく、チームの成功に責任を持つことを恐れ、技術的負債とビジネスニーズのバランスをうまく取れるか心配しています。
著者は、管理能力を向上させるために積極的に外に出てフィードバックを公開で求め、管理スキルを高める方法を探すべきだと述べています。また、管理者としてもエンジニアとしての情熱を持ち続けることが重要だとしています。
記録＆振り返りの決定
同僚や上司は、私たちがよく過小評価しがちな強力なリソースです。彼らからのフィードバックを素早く学ぶことができます。記録をしっかり残し、決定を振り返って見直す習慣をつけることで、より良いフィードバックを得られます。
著者は次のように述べています：
「正しい方法は一つではなく、トレードオフがあるだけです。」
私もそう思います。もし進退窮まった問題でなければ、あなたに尋ねることはないでしょう。尋ねるということは、チームメンバーがどう決めればいいかわからないということです。
私たちは選択肢をリストアップしてチームメンバーに決定を提供できますが、その間に行った決定も記録する必要があります。
作者が提供した記録用シートのテンプレート
記録を習慣化し、後で振り返ることができる内容にすることを確実にしてください。
作者は、毎月振り返りを行い、上司や他の管理者、同僚と意思決定を共有・議論することを勧めています（問題の少なくとも半分は共有する）。他人の意見を聞き、関係者を匿名にして、個人ではなく事柄に焦点を当て、記録を残すことができます。
振り返り時のポイント
問題について：
どれほど多くの技術的な問題を引き起こしていますか？
これは個人的な問題ですか？
単なるあるメンバーの個別の問題ですか？（単に彼が目標を理解していないだけですか？）
この問題は他のチームでも繰り返し発生していますか？
意思決定について：
この問題は本当にマネージャーが決めるべきですか？
チームメンバーに意見を聞いたことはありますか？
他に経験豊富な方からアドバイスをいただけますか？
今もう一度考え直しても、同じ決断をしますか？
レッスン3. — チームメイトに立ち向かい、挑戦する
チームメンバーにコンフォートゾーンから抜け出させ、自分自身が嫌な人間や罠に陥らないようにすること。
作者は最初、とても慣れなかったと言っています。元々は友人の同僚だった人が部下になったため、関係を傷つけることを恐れていました。そのため、すべての後始末を一方的に引き受けていました。しかし、最終的に彼は、守ろうとすればするほどチームメンバーとの距離が離れてしまうことに気づきました。なぜなら、一生懸命に自分だけで抱え込み、共有が減ったことでチームの信頼を失ってしまったからです。
振り返ってみると、著者は「チームメンバーを傷つけることを恐れる」よりも、心の中の本音を伝えるべきだと言っています。「チームメンバーを傷つけることを恐れる」というのは単なる自己中心的な想像であり、必要ありません。そして、それは管理者としての責任であり、チームを成長させ前進させることです。大局を見渡し、リスクをコントロールしなければなりません。
本音を共有することは双方にとって難しいですが、これは管理者としての責任です。
私たちは同情ではなく共感を示すべきです。彼らの仕事を本当に優れたものにするためには、私たちの客観的な意見が必要です。
著者は以下の3つの要素を示し、感情と行動のバランスを取る方法を提案しています：
私は共感を示していますか？
はい、ご期待は非常に明確に説明されています。
私は率先して行動していますか？
「この世界で何かを成し遂げたいなら、誰もがあなたを好きになるわけではないという考えに慣れなければならない。」
成果を出したいなら、誰もがあなたの考えを好むわけではないことに慣れなければなりません。
4つのよくある落とし穴：
隠すよりも、失敗経験を公開して共有していますか？（記事を書く、全員にメールを送るなど）
議論の結果をまとめるのを忘れないこと（1:1や議論の結果を記録する習慣をつける）
誤ったフィードバック手段を使用し、本当の問題を得られなかった（チーム文化に応じて適切なフィードバックチャネルを見つける、例：1:1）
不即時のフィードバック
エンジニアは自己挑戦やスキル向上を好み、同時に尊重や上司からのフィードバックも求めています。私たちの使命はチームを成長させることであり、フィードバックの機会があるたびに遅延すべきではありません。決定をしないことも決定をすることと同じだからです。また、一度フィードバックの風潮が弱まると、再び活性化させるのはさらに難しくなります。
概要
チームメンバーを励ます方法を書き留める時間を取り、上司に対してチームメンバーを過保護にしていないかどうかを確認してください。
レッスン4. — 物事を成し遂げる方法を教える
リスクを抑えてタスクを完了する方法。
率先して行動することは良い方法です。時々チームの開発に参加し、どのように計画し、良い機能を作り出すかを示して、私たちが伝えたい理念を表現しましょう。また、その際には「なぜそうするのか？」（Why?）を多く話し、「どうやってやるか？」（How?）は控えめにすることに注意してください。
著者は、極めて透明な文化がチームメンバーに完全なコンテキストを提供し、意思決定の推進力を高めると述べています。
リスクの低減
アウトプットのリスクを減らすために、著者は要求を多くの小さな機能に分割して反復的に開発することを提案しています。また、この考えを他のチームと共有し、コミュニケーションを図ることも推奨しています。
Scale and performance — always have a backup plan
この機能はパフォーマンスに影響を与えるか（または他の問題を引き起こすか）？事前に分かるか？バックアッププラン（スイッチ）はあるか？バックアッププランがない場合は、チームの信頼を損なうため、実装しない方が良い。タスクを小さなタスクに分解し、締め切りリスクを減らす
最初は難しいかもしれませんが、訓練して学ぶことができます同僚のプレッシャーを活用する
タスクをチームメンバーに分担し、協力して取り組む（コードレビューも同様）持続的に社内外でコミュニケーションを取る
社内：期待値、同期、締め切り、リソースを確実にする
社外：コミュニケーションを取り、時間が厳しい場合は重要でない会議を断ることも可能支援、バグ修正、ドキュメント
機能リリースだけでなく、カスタマーサポート、バグ修正、そしてドキュメントもきちんと行う必要があります。振り返りとタスクの委任を適切に行い、他者にリーダーシップの機会を提供する
いくつかの模範となるタスクを選ぶ
チームメンバーに学んだこと、彼らをより積極的にさせる動機、嫌いなことを尋ねる
レッスン5. — 品質や可視性を失わずにタスクを委任する
タスクを委任しながらも、品質と可視性を失わないこと。
身為管理者必須做好任務委派，作者認為委派就該設定好期待並相信被指派的隊友有能力執行並是有機會學到東西及保有發生錯誤的空間，管理者另一方面也要保護隊友來自公司的壓力。
管理者はタスクの委任を適切に行う必要があります。著者は、委任する際には期待を明確に設定し、指名されたメンバーが実行能力を持ち、学ぶ機会があり、ミスを犯す余地があると信じるべきだと述べています。一方で、管理者はチームメンバーを会社からのプレッシャーから守る役割も担います。
作者は以下の表を使って記録しました：
ここではチームの目標に重要なタスクのみを記録し、日常業務は記録しません。
- Must タスク内容を記載すること
タスクをチームメンバーに委任するかどうかについて、著者はまずそのタスクが本当に自分だけができるものであり、管理者が行うべきものかどうかを確認します。次に、そのタスクが長期的なリーダーシップの任務であるかどうかを判断します。どちらでもない場合は、チームメンバーに委任します。
委任するタスクについては、チームメンバーの経験やスキルを評価し、適切な人材を見つけることが重要です。
External 外部または上位から期待されるリソース（フィードバック／ツール）
委任する
Delegate の部分については、私たちの期待や簡単な例を説明する1ページのペーパーを提供できます。
レッスン6. — 組織内の他チームとの信頼を築く
チーム間およびチーム内の協力の息の合った連携。
作者は、組織がより多くのことを成し遂げるために、多くの小さなチームに分けて迅速な意思決定を行うと述べています。各チームの方向性の定義自体は難しくありません（例：iOSチームはiOSアプリを作る）が、すべてのチームの目標を一致させることが難しいのです。
チームが増えるほど、全員の価値観、期待、優先順位、暗黙の期待を統一することが難しくなる。
分割チームの理由や動機に注目すべきであり、成果だけに注目すると矛盾を招く可能性があります。
著者は各チームの方向性を揃えるために以下の方法を提案しています：
チームにはビジョンが必要であり、単にタスクをこなすだけではいけません
管理者は「必要なもの」と「欲しいもの」を区別する必要があります
チームがより多くのことをこなすのではなく、より速く正しいことを成し遂げるように最適化します
他のチームマネージャーとの良好なコミュニケーションの構築
著者は、2週間ごとのマネージャーミーティングでチームの状況を共有し、自分のチームの障害や課題、今後の主要なタスクとその理由を共有することを提案しています。
他のチームと優先順位の意見が異なる場合は、他の要因を説明して引き出すことができます（例：これを行うことでCSのクレームが減り、一度で済み、相乗効果が期待できる…）。
外部チームが助けを必要としている箇所を理解し、積極的に密接にフォローします
次に、私たちのチームが外部チームの支援を必要とする点を挙げます。
会議で議論すべき確認リストを作成し、話題に上がらなかった場合は、会議後に関連マネージャーと追加で話し合い、他の可能性を検討してください。
不可能な場合は、遅延の可能性や代替案を検討し、関係者に知らせること（陰での批判を防ぐため）。
- すべてはトレードオフである
さらに、チームメンバーが他のチームと密接な関係を築くための5つの方法があります：
簡単な感謝の手紙（ご協力への感謝）
チーム間の仕事の交換
社内技術年次会議でお互いに共有する
ユーザーの利用状況を一緒に観察し、共にブレインストーミングで改善策を提案する
他チームのメンバーを招待して、私たちの仕事に参加してもらう
概要
「チームAの誰かが緊急のサポート問題のためにチームBが必要とする機能を削除したとします。この優先順位の変更をチームBに伝えなければ、正当な優先順位の変更であっても信頼は低下します。」
「 トランザクショナル信頼とリレーショナル／感情的信頼の違い 」
取引の信頼と関係の信頼を理解する。
取引の信頼 — 人々が約束を守り、タスクを完了するかどうか
関係の信頼 — 人々が関係を築き、守る方法で行動しているかどうか
レッスン7. — ビジネス学習の最適化
ビジネス学習の文化を築くこと、文化を作ることではなく、スループットの最適化、価値の最適化。
過度な最適化は災害である
現在の問題の最適化を優先し、最適化のための最適化は避けること
たとえプロジェクト全体の責任者でなくても、内部運用の最適化は可能であり、大きな成功は小さな最適化の積み重ねから生まれます。
管理者として、私たちは意思決定の背後にある動機を示さなければなりません
ビジネス学習（価値）文化の構築とカルチャーの醸成（重要なのは解決策の構築ではなく、我々が解決しようとしているビジネス課題）
最適化効率 vs 最適化スループットの問題： 最適化効率：単一タスクの処理時間を改善すること 最適化スループット：一定期間内（例：一四半期）に処理できるタスク数を増やすこと
各最適化のインパクトを把握し、
自動化の重要性（時間を一度の労力で大幅に節約できる）
AARRRの原則を使った価値の最適化：
Acquisition：より多くのユーザーを獲得する方法
Activation：ユーザーに製品の価値を理解させるタスクを完了させる方法（例：アラームアプリで、新規ユーザーにアラーム設定を完了させる）
Retention：リピート率の向上、再利用回数の増加
Referrer：ユーザーやコンテンツからより多くのトラフィックをもたらす
Revenue：ユーザーがもたらす収益のデジタル評価
これら五つは密接に関連しており、Retentionが低い場合は、ReferrerやAcquisitionも同時に調整することが可能です。
エンジニアリングマネージャーとして、私たちがすべきことはコードを書き続けたり、技術に没頭したりすることではありません。時折、製品の価値を再確認する必要があります。
当製品がまだ初期段階で市場を試している状態のときは、効率の最適化（迅速なタスク解決とリリース）を主軸に、以下のプロセスを繰り返すべきです：
機能はリテンションを向上させる -> 機能をリリースする -> 学習する -> 調整＆繰り返す。
機能の評価からリリースまでの各段階で最適化できる点（設計に時間をかけすぎているか？議論に時間をかけすぎているか？）
開発時間の80%を削減するために20%の時間を投資することは可能ですか？特に苦痛を感じる部分において。
まずは最小限の対象に実験的にリリースできますか？大きな機能を一度に出しても、結局誰も使わない可能性があります。
- データ追跡をしっかり行うことで、努力の成果を把握できるようになる
「もしデータに基づいてエンジニアリングの決定ができないなら、データを生み出すようなエンジニアリングの決定を下しなさい。」
「この機能をやらなければ会社が倒産する」と「この機能は技術的負債を生む」のどちらが怖いかと言えば、もちろん前者のほうが怖いです。しかし技術的負債については、管理者として解決するための時間を確保できるなら、それを実行すべきです。適切なコミュニケーションと管理を行う必要があります。
最適化しても使われないコードにはあまり意味がありません。
草創期を過ぎて製品モデルが安定してきたら、この時点で最適化すべきはスループットです（例：与えられた X のリソースで Y の成果を得る）。
ビジネスニーズの予測可能性の提供（同上）
チームの成果を追跡する（例：「2013/01/01–2013/01/14: 大きな機能2件、中くらいの機能5件、小さな機能4件」）。長期的な統計を通じて予測が可能になる。
ボトルネックの特定と解決：
同期のコミュニケーション：例えば、製品開発プロセスで設計リソースが必要な場合、エンジニアリング開発段階に入る際に、すでに明確な仕様があり開発を実行できるのか？それとも待っているのか？または先にできることは何かあるのか？
基盤：コードを拡張しやすく、保守しやすくする
自動化：自動化を使って面倒な手作業を処理し、時間を節約すると同時にミスを防ぐことができます
ビジネス戦略は常に変化するため、最適化戦略に対してはより開かれた柔軟な考え方を持つべきです。最適化の要点はやはりビジネスニーズを重視することです。
Lesson 8. — インバウンドリクルーティングを活用して優れた人材を引き寄せる
採用について。
普段から以下のことを始めておくべきです。急に人材が不足してから始めると、従来の採用方法に戻り、面接を繰り返しても適切な人材を見つけるのが難しくなります。
社内向け：
良いエンジニアリング文化の醸成（例：コードレビュー、年次総会…）
魅力的な職場環境を作る
ブランド運営のように
チームメンバーが共に努力する
人と人とのつながりを強化する（例：誕生日祝い）
まずメンバーがチームを誇りに思えるようにすること
対外：
内部チームは毎週定期的に外部のコミュニティ質問（例：Stackoverflowなど）に回答し、露出を強化する
プログラム内に採用のイースターエッグを隠す（例：ウェブ開発者ツール）
コミュニティとチームが直面した問題とその解決方法を共有する（記事またはトーク）
ハッカソンの開催
サイドプロジェクトの立ち上げ（例：オープンソースプロジェクト）
以上の各タスクをチームメンバーに割り当て、皆で良い人材を見つけるために力を合わせましょう。
レッスン9. — 拡張可能なチームを作る
拡張可能なチームを作る。
拡張可能なプログラムを作ることは、以前エンジニアとしての責任でしたが、今挑戦すべきは拡張可能なチームを作ることです。
プログラムとは違い、人には期待やニーズ、夢を考慮する必要があります。
著者は、楽しい職場環境を作りたいと考えています。チームメンバーがお互いにタスクの期待値や新しい挑戦を理解し、その情熱を持続できるようにしたいのです。
目標の整合
個人のビジョンを会社の目標と一致させること。現在の会社の目標を理解していないと、チームの機能不全を引き起こす可能性が高い。コアバリューの整合
これは共通認識や暗黙の了解にあたり、仕事の進め方や重要なポイントに関する合意を指します。チームのコアバリューも固定的ではなく、時代に合わせて進化させる必要があります。バランス
チームメンバーの役割や成長に応じて、異なるビジョンや自主性、所有権を割り当てる。互いに協力して共に成長する（例：新人は会社の業務プロセスを理解することを期待し、ベテランはコードレビューや指導を行う）。全員が成長できる環境を持つべきである。団体のコアバリューは個人より重要
離職者が出る可能性があり、実現には時間と忍耐が必要です。また、多くの課題もあります（例：離職時にコアバリューが疑問視されること）。達成感
成果に達成感を持てるように、管理者はチームメンバーの熱意を無駄にしないようにする必要があります。
実践
チームビジョンの定義
例：著者のチームはクローラーを開発しており、チームのビジョンは「世界最大かつ最も情報量の多いプロフィールデータベースを構築すること」です。
ビジョンは短期目標ややりたくないことではないことに注意してください。チームのコアバリューを定義する
コアバリューを選ぶ際には「この価値がなければ誰かを解雇するほど重要か？」と考えるとよい。
コアバリューとその理由を書き出す。
著者が挙げているコアバリューの例：- 他のチームに後始末をさせず、自分たち（チーム）のミスは自分たちで責任を持つ
- チームの全メンバーに対して忠誠心と敬意を持つ
コアバリューがあれば、採用や解雇の判断基準が明確になり、行動の基準にもなる。
メンバーがチームやマネージャーに期待することの定義
生産的で楽しい職場環境を提供する
タスクの「なぜ（Why）」を理解し、「どうやって（How）」ではないこと
本物のフィードバックを得られること
他のメンバーをリードする機会があること
仕事の成果を共有できること
チームメンバーへの期待の定義
基本的な期待：
タスクを完了しました。
学び続ける情熱を保つ
共有と教育への情熱を持ち続ける
やるべきことの限界感覚
個人的な期待：
能力に応じた期待設定
他者の変化を促す能力がある
不平を言うのではなく、変化を促す
私たちはチームであり、チームメンバーはそれぞれの責任と成果物を持ちながら、他のメンバーと協力し助け合い、共に成長します。期待の定義は一種の契約のようなもので、同僚関係から管理者関係へと変わる中で、より良く、より目的を持ったリーダーシップを可能にします。これらの項目を定義することは簡単ではなく、時間と忍耐をもって繰り返し改善していく必要があります。
「人の行動を承認することで権限を与えることはできません。権限を与えるとは、承認が必要な仕組み自体をなくすように設計することです。」
ご質問やご意見がありましたら、こちらからご連絡ください 。
Post は Medium から ZMediumToMarkdown によって変換されました。
本記事は Medium にて初公開されました（こちらからオリジナル版を確認）。ZMediumToMarkdown による自動変換・同期技術を使用しています。