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