天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

エンジニアリングマネジャー入門 - Forkwell Library#62に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第62回目では、『エンジニアリングが好きな私たちのための エンジニアリングマネジャー入門』を取り上げます。 エンジニアとしてキャリアを積んできても、マネジャーという立場になった瞬間に扱う対象が「コード」から「人」へと変わります。それは職種自体が変わるようなもので、多くの方がその大きな違いに戸惑い、困難にぶつかってきたことでしょう。 「人と関係性」に焦点をあてた本書は、エンジニアリングマネジャーが困惑しやすいトピックを解説し、メンバーと協力して一緒に共通の目的に向かうために読むべき一冊となっています。

会の様子

iwashiさんの講演

書籍の位置づけ

本書の位置づけとして、

  • エンジニア出身のマネージャー(Googleの有名ディレクター)が著者である
  • 実践によった本であり、学術研究などはそんなにない
  • 人の内面や文化などに寄り添っている本であり、読んですぐに現実が変えられるような話はない

の紹介がありました。

書籍の読み方

基本的には順序性はないものの、Chapter2までは順番に読んで、その後は好きなChapterから読むのがおすすめだという話がありました。

目次

以下の目次が紹介されました(Chapter8でPart1が終了、Chapter15でPart2が終了、Chapter19でPart3が終了)

  1. 自分のチームを大切にする
  2. 価値観の価値
  3. 信頼と弱さ
  4. 自分のチームは「彼ら」ではなく「私たち」
  5. 幸せとやる気の原動力
  6. 長期的な従業員のケア
  7. キャリアラダー
  8. 重要な1on1
  9. マネジャーとしてのコミュニケーション
  10. チェンジマネジメント
  11. フィードバックの与え方
  12. フィードバックを受け取る
  13. 良いミーティング
  14. 対立のマネジメント
  15. クロスチームとオープンソースのコラボレーション
  16. チームの仕事の優先度付け
  17. プルリクエストのスコープを絞る方法
  18. 実行の速度
  19. プロダクトとエンジニアリングの時間配分
  20. ハイレベルでの優先度付け
  21. 日々の優先度付け
  22. 境界線を設定する
  23. まず自分を大切にすること
  24. 自分を信じること
価値観ワーク

最初にiwashiさんが印象的だったトピックとして、多数の価値観から3-5つピックアップする価値観ワークを実施しておくとチームの仕事がスムーズになるということでした。

会える環境を作り出す

次に、お互いに顔を合わせる機会の重要性をアパートの交友関係を例に話しているということで、信頼構築に関する重要な洞察があるということでした。

プライベートスペースの重要性

チームが自分たちだけの場所を持つことが重要だという話があり、フルオープンではなくオープンとプライベートのバランスが重要だという話は印象的だったそうです。

主語は「私たち」

「幹部が言っているので〜」とかではなく、あくまでも自分たちは何をしたほうが良いのか?というのを話すのが重要だということでした。

フロー状態

フロー状態が幸福を招くことは多くの書籍で語られていますが、フロー状態は不満への耐性が高まるという話もありました。

また、フロー状態を作る具体的な方法もあるそうで、例えば以下のようなものがあるということでした。

  • 仕事の前提や目的が合っていること
  • 仕事が困難ではあるが不可能ではないこと
  • 同僚やチームで一体感がありお互いをサポートしていること
  • 頑張った結果として、給与やボーナス、昇進が得られること
  • ...
ネガティブバイアス

なにかの出来事が起きた時に、自然と悪い記憶が呼び起こされてしまうという話があったそうです。

そのため、事実を確認したり、ポジティブな要素に集うようにすることでミラーニューロンに立ち向かったり、結果を見直すようにするのが重要だということでした。

1on1

1on1は不確実性を減らす機会だと考えているそうで、部下の優先付けやアクションアイテム作成やビジョンの明確化をするのが重要だと話がされているそうです。

口を出さない

実現方法はチームメンバー次第にすることが重要だということです。

特にアーキテクチャや開発手法にはアドバイスをしたくなりがちなので、基本は質問をするのみでやり方に言及しないことの重要性が書かれているということでした。

何かを定着させるために「繰り返し」が必要

同じメッセージを別の方法で繰り返し伝えることが定着のコツだということです。

透明性

透明性が大事=他者が情報を隠していることを見たくない、という場合が多いという話が書かれているそうです。ただし、透明の中には愚痴など有害なものもあるので、「他の人やグループにこの発言を聞かれても恥ずかしくないか?」という観点で話すと良いとされているそうで、iwashiさんとしてはSNSの活用方法と似ているように感じたそうです。

チェンジマネジメントの注意点

不公平な意思決定はプライベートなチャンネルやチャットで炎上が起きるため、その点は注意してほしいと言う話があるということです。

フィードバックを与える前に

フィードバックの好みを開示しておくことが重要だという話があったそうです。

フィードバックのもらい方

特定のPJや出来事に関するフィードバックを求めたり、1on1でフィードバックを事前に求めるようにしておいたり、匿名でフィードバックをもらうようにすることが重要だということでした。

気まずいミーティング

「あれ?気まずい感じだったな...」で終わるMTGは、人が多すぎたり適切な人がいないことが多いというお話がありました。

この場合、誰かの感情を傷つけることが怖いことが動機としてあるそうですが、これは役割と責任が不明瞭なことに起因することも多いと書かれていたのは、特に印象的だったそうです。

また、皆が言わないことは自分から口火を切るのが重要だそうです。

良いミーティングにはDRIがあるそうで、皆で意思決定を下さずに最終的な結果に責任を持つ人を尊重することが重要だそうです。

偽りの調和

同意しているように見えて口をつぐんでいる場合が多くあるのに注意したほうがいいということでした。

また、マネジャーは現場から遠ざかりがちで真の問題に気が付かないことも多いので、この状態を作らないことは本当に重要だと考えているそうです。

メトリクスの限界

仕事で重要なものはビジネスにとって正しいことに取り組んでいるかどうかなので、異常値に関して話したりケイデンスを把握したりすることに価値があるということでした。

MVPの危険性

中途半端にリリースすると、対象顧客の信頼を失うことになるため、あまりにもしょぼいプロダクトをリリースするのはリスクがあるという点が印象的だったそうです。

プロダクトとエンジニアリングの時間配分

割合を宣言するのではなく、ステークホルダーに共有可能な一枚の情報を持っておくことが重要だという話が書かれているそうです。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

EMの成長の仕方や学びのステップは?

EMのマネジメントの本を読んだり、EM歴が長い人やメンバーにフィードバックをもらいにいく。

質問で気づきを与えるようなやり方は角が立つこともある気がするが、どうするか?

本当に間違っている場合は突っ込むけど、相談スタンスでその他の場合はいく。

プライベートチャンネルの炎上はどう気がつくのか?

色々な情報チャンネルに入っておく。そのうえであまり良くない発言は確認しておく。また、もちろん周りの関係性も含めて聞けるような信頼性構築が重要だと思える。

物事をはっきり伝えるのはパワハラになることもあるのだが、どれくらいの感じで伝えるのか?

事前に相手に対してどういうフィードバックがほしいのかを聴いておく。

EMとして転職する場合どういったスキルや経験を評価されるのか?

EMによる。

メンタルヘルスの維持方法は?

めちゃくちゃ寝る。あとは寝る時間をずらさない。

A案かB案にするかを伝えるとき、強権的な決定はメンバーの当事者意識を阻害しそうなので同意を求めがちなのだが、どうするといいか?

メンバーの話を聴いたうえで決めているよというのが分かるようにする。例えば、「Aさんはこういう理由でA案といってくれたけど、こういう理由からB案にするよ」など

プレイングマネージャーでプレイ比重が多すぎる時どうするか?

短期的にはめちゃくちゃ採用をする。また、1,2ヶ月は作業止まるけど長期的にはこちらのほうがいいと思うのでこうします、というのを話す。

若手社員でやる気のない人にどうするか?

モチベーションを聴いて異動してもらったり、チームで一番モチベーションが上がるような作業をしてもらう。

エンジニアリングマネージャーになったとき、3冊読むとしたら?

エンジニアリングマネージャーのしごと、エンジニアのためのマネージャー入門、今回紹介した本

チームメンバーがこの本に書かれているような内容に興味を持つように導くといいのか?

マネジメントの仕事の一部を移譲して、楽しさを実感してもらう。

1on1嫌いなエンジニアたちが辞めない方法はあるのか?

1on1で辞めるというのは見たことがないので、1on1の中身を見てみたい。1on1はあくまでも手法なので無理にやらなくてもいい。

EMとしてフィードバックをもらいたい時、どう聴くのか?

「あなたがもっと成果を出すためには私はどうしたらいいですか?」と聴く。

報酬設計などEMという立場で解決が難しい問題にはどう立ち向かうか?

素直に権限がある周りに相談する。

会全体を通した感想

今日の話を聴いている限りだと本のタイトル通り入門的な書籍でそんなに新しい話は書かれていないかな?と思いつつ、具体的なフレーズや事例レベルで話が書かれているのは、引き出しが増えそうで良いなあと感じました。

また、技術的な内容がそこまで言及がなかったので、このあたりは現代のトレンドのひとつなのかなーと思って話を聴いていました。