勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

「エンジニアリングマネージャが知るべき97のこと」を対話的に読む(1)

約10年前にいくつか邦訳されて話題となった「〇〇が知るべき97のこと」という技術書シリーズがある。このシリーズが最近復活したようだ。〇〇には現代的なエンジニアロールが入っているので面白そう。翻訳されるかと思ったけれど、その気配もないので原著で読み始めた、という話。

今回取り上げるのはこれ。

(なおAmazonのリンクで紹介しているが、私はオライリーのサブスクで読んでいる)

他にも新シリーズでは次のようなものがあるようだ。SREのはちょっと気になっている。

97シリーズは対話的に読むのが面白い

10年前に97シリーズを読んだ時にも感じていたのだが、本シリーズは「各エッセーにツッコミを入れていく」スタイルで読むのが面白いと思っている。

  • そうそう!同意!
  • いや、それは違うんじゃないの?
  • 同じ経験をしたことがあるよ〜
  • 参考になった。次に試してみよう

などとリアクションしながら読むと学びが深いのではないだろうか。このシリーズは実践者の短いエッセー集という体裁を取っている(むしろブログ記事アンソロジーという趣だ)。あまりかしこまって読むものでもないだろう。

実際に読んだ感想(Chapter1~20)

  • Chapter 1. Advanced PeopleOps—One-on-One Retrospectives
    • 普通の高頻度1on1をやる立場にないけど、納得。寧ろ皆さんどうしてるのだのうか。あと「おばあちゃんのハム」の話は覚えておきたい。
  • Chapter 2. Answer These 10 Questions to Understand Whether You’re a Good Manager
    • めちゃくちゃ良い記事で、感動した。稼働率とか生産性や経営KPIはEマネージャーの成功指標じゃないよという話。10の良い兆候のリスト。1つ目は「1週間休むことはできますか」それなー
  • Chapter 3. Avoiding Traps in Manager READMEs
    • いわゆる「マネージャーのトリセツ」を共有するプラクティスに関する批判。ちなみに自分は過去にトライしようとしたけど、しっくりこないのでやめたことがある。
  • Chapter 4. Building Effective Roadmaps
    • ロードマップをコミュニケーションと合意形成の為に使うポイントに関して。「何を諦めるのか」「不確実性はどこにあるか」などが答えられるロードマップが良い、ってそりゃそうだけど、イメージが湧かない。。
  • Chapter 5. Busy Isn’t Better
    • マネージャーはチームがずっと繁忙であるようにコントロールすることを求めるプレッシャーがあるけど、実際には常に余裕が必要だよねという話。全面的に同意、ただ、これをセンス以外でやれる方法を学びたいんだよなー
  • Chapter 6. Career Conversations as an Engineering Manager
    • 部下とキャリアパスに関する1on1をする方法、話すべき内容について。すごい参考になった。あと、EMはキャリアのガイドではあるが、マップメーカーではないというのも同意。そしてレポートを残すことについて。このあたりは自分の所属組織でもいろいろ改善したいのだけれども。
  • Chapter 7. Career Development for Startup Engineers
    • スタートアップ企業のエンジニアは、落ち着いてきたら人材投資しないと外に出てしまうよという話と、何をすべきか。まあSIerに入社する優秀な人も同じような気はする。有効な手の一つは「より大きなプロジェクトに取り組む機会を共有する」だけれど、なかなかそう出来ないのはなんでなんだろうー。
  • Chapter 8. Communicating with Executives
    • 経営幹部とのコミュニケーションは相手の目線に立って、相手の注意を引くように、から始まる細かなアドバイス。興味深いが、ちょっとコンテキストが違いすぎて参考にならないな。もしくは参考にならないという点が大きな問題なのかもしれないけれど。
  • Chapter 9. Communication as Craft
    • 技芸としてのリーダーシップ向けコミュニケーションTips。初めてリーダーをする人に聞かせたい良い話。リーダーとなった瞬間、コミュニケーションの意味が変わる(相手に対する意識が変わる)というのは本当にそう。何を伝えたか、じゃなくて、何が伝わったか、なんだよ。
  • Chapter 10. Connect “The What” to “The Why”
    • EMとして最もレバレッジある活動は、エンジニアの活動と理由(なぜ、やるのか)を接続すること(質問をするのではなく、説明することが必要)。そして、常にその接続を補強せよ。はい、同意しかない。
  • Chapter 11. Continuous Kindness
  • Chapter 12. Culture Is What You Do When the Unexpected Happens
    • 組織文化は、予期せぬ事態が起こった時に表出されるものであるという話。言われてみればその通りだけれども、けっこう新鮮な視点。感想というか自省だけれど、つまり表現された文化(ビジョン)などについて語り合うのはたぶん間違いで、アノ時の行動がどうだったかに着目すべきなんだな
  • Chapter 13. Dealing with Uncertainty
    • 不確実性の対処に関しての話だが、一般論であった。EMは不確実性の高い判断をする必要がある。その時に気を付けるべきことについて。う~ん自分にとってはかなり当たり前な内容なんだけど、これが新鮮な人も多いのかなぁ。
  • Chapter 14. Define Your Culture Before It Defines Itself
    • 文化を定義する話。「あなたは素晴らしい候補者だが、当社のカルチャーには合わない」といって優秀な候補者を追い返せないようであれば、文化の定義が不十分ということ。これはだいぶ難しいな・・・
  • Chapter 15. Delivering Feedback
    • 効果的なフィードバック方法について執筆者が活用しているものの紹介。ところで紹介されている"Mirror,Mirror"というゲームは何なんだろう。これかなぁ。http://www.childdrama.com/mirror-mirror.html ちょっと面白そう。
  • Chapter 16. Developing Communication Patterns
    • 製品の品質はチームのコミュニケーションに依存をしているので、チームのコミュニケーションパターンを意図的に”開発”しなければならないという話で、とっても良い。計画駆動ではなく、観察とシミュレーションと干渉。すごくいいぞ。
  • Chapter 17. Distributed Teams Are Founded on Explicit Communication Channels
    • 分散化するチームを考慮して、最初からコミュニケーションチャネルに投資すべき。そして使い分けについて。使い方のTipsは山とあるのだけど、設計と移行という観点でけっこう困ってるので参考になる。
  • Chapter 18. Do Less, Lead More
    • 「やるべきことがすべてできない状況になったとき」がエンジニアマネージャとしての成長のチャンスだという話。シミュレーションのための「Bad News Test」(上司に伝える悪いニュースを考える)というアイデアは良いものな気がする。
  • Chapter 19. Don’t Be the S--- Umbrella
    • エンジニアリングマネージャの仕事はスーパーヒーローとしてチームを保護することではなく、コンテキストプロバイダーになるべきだという話。コンテキストプロバイダー? チームに現状を理解させ、考えさせるということか。そしてチームの成長を導く……
  • Chapter 20. Don’t Elevate the Means Beyond the End
    • 高度なHOW(例えばマイクロサービスアーキテクチャの適用)をビジネスゴール超えた形で設定してはいけないという話。トレンディーなテクノロジーと、トレンディなプロセスに注意。あたりまえだけど、忘れ去られがち。

引き続き、残る57章も読んでいくつもり。
なお各章の感想は、以下のTweetにスレッドとしてぶら下げているので興味があればどうぞ。