これは何
積まれまくっていた『スタッフエンジニア マネジメントを超えるリーダーシップ』を今さら読んだので、自分用の備忘録です。色んな人が書評を書いているので、全体像が知りたい人はそちらを探してください。
読んだきっかけ
前々から積んでいたことに加えて、マネジメントといわゆるスタッフエンジニア (IC) で取り沙汰されるリーダーシップの境界がいまいちわからなくなっていました。マネジメントと IC 両方に興味があるため、その区別をはっきりさせておきたかったからです。
個人的に学びがあった・覚えておきたいこと
スタッフエンジニアの典型的な分類
スタッフエンジニアと一口に言っても大まかに 4 種類 (テックリード・アーキテクト・ソルバー・右腕) があり、役割・スコープだけでなく組織上の配置、必要となる事業タイミングなども大きく異なると紹介されていました。一方でこの 4 分類に固執することも危険とされており、柔軟に自分と組織に合ったポジションを見つけることが重要だと認識しました。
参考
- 第 1 部 (第 1 章)
スタッフエンジニアとして能動的に意識すべきこと
具体的には以下のような項目が挙げられていました。ありきたりではあるものの、これを一覧として定期的に見返すのは重要だなと。
- 重要なことに力を注ぐ
- エンジニアリング戦略を立てる
- 技術品質を管理する
- 権威と歩調を合わせる
- リードするには従うことも必要
- 絶対に間違えない方法を学ぶ
- 他人のスペースを設ける
- ネットワークを築く
参考
- 第 1 部 (第 2 章)
スタッフエンジニアに求められること
なぜか補章のしかも面接についてのセクションに追いやられていましたが、客観的にスタッフエンジニアに求められていることが書かれていて参考になりました。以下の問いに答えられるかで客観的に自分に足りていないことが見つけられると思いました。
- 自己認識: ミスの責任を認められるだろうか？など
- 判断力: 困難な問題に取り組む際にリスクを減らせるだろうか？など
- コラボレーション能力: 地震よりも経験の浅い人々と付き合っていけるのか？など
- コミュニケーション能力: 他人が指摘する内容をよく聞き、理解できるだろうか？など
- 発展力: リーダーになれば「組織のベンチマーク」は成長するだろうか？など
参考
- 補章 スタッフになるための情報源 - スタッフプラスの面接ループ
リーダーシップとは
リーダーシップは職種 *1 に拘らず実践可能な アプローチ であると紹介されていました。またリーダーに求められる特性を整理すると以下のようになりました。
- 物事の理想な状態を詳細に理解していること
- 理想と現実のギャップを見極められること
- 理想と現実のギャップに関心を払い続けられること
- 理想と現実のギャップを埋めるために必要な行動を導き出せること
- 理想と現実のギャップを埋めるための行動ができること
参考
- 第 1 部 (第 2 章) リードするには従うことも必要
効率的なコミュニケーション
本全体でいくつか紹介されていたものからのピックアップです。
- 話を聞き、明らかにし、空気を読む: アメリカだとローコンテキスト・ドライが前提かと思っていましたが、ローコンテキスト (目的を明確にする) もありつつ、意外とハイコンテキスト・ウェットな面 (空気を読む) も重要視されるんですね。ここで紹介されているアクティブリスニングのような行為は、普段からしているつもりだが今まで以上に意識したいと思いました。
- SCQA フォーマット: 個人的に Background, Objectives, ... のようなちょっと論文に影響されたようなフォーマットで文章を書くことが多いですが、このあたりはまだ改善の余地があるなと感じたところです。それと、改めて結局根回しは重要なんだなと。英語の wikipedia ページ があるのも面白い。
- うまく事が運ばなかったミーティングの直後にフィードバックをもらう: 早めに改善ループを回そう。
参考
- 第 1 部 (第 2 章) 絶対に間違えない方法を学ぶ
- 第 1 部 (第 2 章) 経営幹部の前で
- 第 2 部 (第 5 章) ドミトリー・ペトラシュコ
自己評価
自分の業績評価を三人称で書くというアプローチは面白いですね。そうすることで批判より称賛が多くなるからと書かれていますが、それ以上に自然と客観的になれるというメリットが想像できました。
参考
- 第 2 部 (第 5 章) ラス・カサ・ウィリアムズ
マネージャーとスタッフエンジニアの行き来
紹介されているほとんどのスタッフエンジニアはマネジメント経験があるもしくはマネジメントに関心があるようでした。マネジメントとスタッフエンジニアは排他的なものではなく、相互に影響がありうまく使いこなしている人が多い印象でした。エンジニアリングを活かしたマネジメントもマネジメントを活かしたエンジニアリングもあるべきで、特に「マネージャーとして計画が不十分なプロジェクトでエンジニアが苦労することを知っていることが、IC としてプロジェクトが良くない方向に進み始めたときにどんな警鐘を鳴らせばよいか知っていることがそれぞれ有利に働く」というストーリーは想像しやすかったです。
参考
- 第 2 部 (第 5 章) ダン・ナ
まとめ
個人的にこの手の本は眺めてもそりゃそうだよねという感想しか出ないことが多いのですが、この本は比較的多くの新しい視点を与えてくれました。
なんかてきとうに書き留めていったら歪な日本語文章になってしまった。悲しい。
*1:「職業」と訳されていたが「職種」と捉えたほうが良さそう
