エンジニアリングが好きな私たちのための エンジニアリングマネジャー入門を読んでみて

背景と目的

年齢的に、今後のキャリアとしてマネージャとしての役割も意識するようになりました。
その中でも技術力が根底にあるエンジニアリングマネージャについて興味をもち、

• そもそもエンジニアリングマネージャとは？
• 私に足りないことは？
• すぐ実践できることもあるのはず

そんなモチベーションを背景に、次の本を読み進めています。
エンジニアリングが好きな私たちのための　エンジニアリングマネジャー入門

本記事では、本書を読み進める中で、現在～未来の自分に当てはめながら、技術力をもったマネージャとしてこれから必要なこと・どうなっていきたいかを整理することを目的とします。
注：Chapは歯抜けになっています。

Part1 自分のチーム

chap2: 価値観の価値

• 個人間の価値観の共有が互いの理解を深めるということ

  • キックオフの前にメンバ全員が自分のもつ技術スタックの共有がその後の仕事のやりやすさに繋がると経験上理解していましたが、それに加えて価値観を共有することは他者の行動背景の理解に役立つようです。

• 組織の価値観

  • 組織が掲げる価値観を組織の選択として体現できているのか、またその選択と自分の価値観が合うのか、は常に問いつづけること、その不一致は結局自分を苦しめるのものであることを理解しておく必要があるようです。

chap3: 信頼と弱さ

• 弱みをさらけだす

  • 技術的な要素でもよいし、パーソナリティでもよいので、メンバー間で自身の強味・弱みについてさらけだす。そのことが、他人を頼りやすい環境が信頼を構築していく。

• チームの時間

  • 雑談やくだらない冗談のくだけた雰囲気から仕事のやりやすさ・スムーズなコミュニケーションが発生する。

chap4: 自分のチームは「彼ら」ではなく「私たち」

• チームの成功
  • チームが何か成功したらそれはメンバーのおかげ、失敗したらうまくリードできなかった自分に責任がある、こうした姿勢にリーダーとしての力量が出るし、自分ごとに落とし込んでの反省無しに改善は無い、そう戒めてこれからも実践していきたいと思います。

chap5: 幸せとやる気の原動力

• 動機付け
  • 私自身もそうですが、エンジニアリングが好きな周囲の人たちは内発的動機付けで仕事に取り組んでいます。当人が面白いと思えない仕事で高収入だとしても満足を得られない、そんな人達ばかりな気がする。チームだけでなく組織としても、そうしたエンジニアの価値観を理解する文化が求められると感じます。

chap6: 長期的な従業員のケア

• メンバーのスキル
  • 自分がいなくても彼らがうまくいくように支援する、誰にどんなスキルが必要かを考え伝えていくのが役割と考える。
• チームの文化の強さ
  • 閉じられたチャットルームでさえ、悪口が許容されるチームであれば、その程度の文化レベルのチームに成り下がることを肝に銘じる。

chap7: キャリアラダー

• 評価基準
  • 基準を個々人に当てはめるだけでなく、当人の価値観も鑑みたうえで、要求内容と照らし合わせていく。その価値観は会社内だけに閉じる必要はなく、外で活躍できる可能性も許容する。

chap8: 重要な1on1

• 1on1の目的
  • 双方がチームの一員としてのつながりを強化し、意図を明確にすることで、不確実性を減らす場であり、空いてに「自分に価値がある」・「つながりがある」と感じてもらうこと。
    • 不確実性を減らす方法
      • 優先度付け：最重要部分からの着手を手助けする
      • アクションアイテムの作成：大きすぎるタスクの分解とどこから着手するかを手助けする
      • ビジョンの明確化：目の前の仕事の意義や価値を感じられるように手助けする
  • 上記のような明確な目的のある仕事であることを理解する。目的のない1on1がなんと多いことか...

Part2 コラボレーション

chap10: チェンジマインド

• 変化を起こすには
  • みんなに理解してもらう必要があり、理解しようと努める
    • これからに向けた大きな共有ビジョンの提示、そしてリスク等があることを正しく評価（理解しようとする）が必要＝意思決定プロセスの透明性。不透明性を残さぬよう。
  • そしてその変化に伴う失敗への責任は自分がとる。私はチームの味方であり続ける姿勢が大切。

chap11: フィードバックの与え方

• フィードバック
  • 良いフィードバックを与えるには、相手が脅威を感じないようにすること。
  • 完璧な誤りのない立場からのアドバイスではなく、共通の目標に向かって一緒に働くパートナーとして実施する。
  • プロセス
    • 相手がフィードバックを受け取りたい方法を知る
    • フォードバックが必要かどうかを確認する
    • 自分の動機とバイアスを確認する
    • 具体的にフィードバック
    • オープンな会話の中で質問可能にする
    • 今後の期待と改善について語る
  • 具体例をあげて、人格ではなく具体的な行動について話し合う。
  • フィードバックが相手のキャリアに、レベルアップに役立つかを考える。

chap13: 良いミーティング

• 良いミーティングとは
  • ミーティングの目的が明確
  • アジェンダがある
  • コミュニケ－ションが複雑になりすぎず、かつ前に進むために必要な人がいる程度の人数
  • 秩序がある。全般に配慮を示している。
    • 攻撃と健全な対立を区別する。
  • ミーティング終わりに、結論、成果、次のアクションが明確になっている

chap14: 対立のマネジメント

• 生産的な対立
  • 異論を唱えても、個人攻撃に陥ったりしない健全な環境を作ること。
    • チームの目的に沿わない個人攻撃がある場合には、そのメンバーを外すことも必要になるかもしれない。
  • 対立が、他者の価値観とは異なる自分の価値観に根ざしている可能性があることを理解する。

Part3 チームが最高の仕事をできるように支援する

chap16: チームの仕事の優先度付け

• すべてが重要なら、重要なものは何もない
  • 別の本からの参照ですが、最も重要なことにYesというために、その他のことにはNoという、言葉があり、プロジェクトにおける優先度付けも同じことだと理解しました。
    • 優先度付けを誤るとたまに、機能要件すら満たしていないのに、非機能部分にこだわりすぎて開発が進まない、ってこともある。この場合には、個人レベルでの優先度ではなく、チームとしての優先度を共通認識とする必要があると思う。

chap17: プルリクエストのスコープを絞る方法

• レビュワーの仕事
  • コードレビュースキルと、変更がなぜ・どのように行われたかをやりとりするスキル
    • 小さなPRほどテストしやすく、イテレーションしやすい。
      • 小さく、焦点が絞られており、関心事の数が最小限に抑えられているもの
• プルリクエスト
  • 出来る限り、1つのゴールをもつべき。

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

• プロダクト側の新たな取り組みに費やす時間:エンジニアリング側の作業に費やす時間=70%:30%
  • プロダクトの成果への明確な期待が設定されてこそ↑の配分が成り立つ

Part4 自分の仕事

chap20: ハイレベルでの優先度付け

• マネージャの自分時間の優先度付け
  • 以下の4象限に当てはまるタスクを書き出しカウントが多い順に優先度が高い＆どの象限にも当てはまらないのは切り捨て対象
    • コミュニティへの貢献
    • 人のサポート
    • 充実感を得られること
    • 収入につながること

chap21: 日々の優先度付け

• 次の順番でのタスクに並び替え、大きなタスクを小さいタスクに分解する

  • 緊急事態か、期限が迫っているもの
  • すぐに完了できること
  • 時間を確保して取り組む必要があるもの
  • 将来的に取り組むかもしれないもの

• 自身でも行っていることですが、完了したタスクをリストに残しておくこともやる気の継続につながるそうです。たしかに、やりきったな自分と思える。

読み終えて

全編にわたり、他者への感謝や価値観の理解、相手を尊重、といった単語が多く見受けられました。
ビジネスだからといってそれらが不要になるわけではなく、チームとして様々なバックグラウンドをもつ人間同士が仕事をするのだからむしろ、大事にする必要がある、そういったメッセージを強く感じました。

その他、マネージャとしての心がまえ、だらだらと時間ばかり取られがちな1on1の目的とお作法、フィードバックの方法、優先付けの考え方など、具体的な方法論についても言及されておりそれらは、今すぐにでも使えるものでした。

これから自分が進む方向の一つとして、そこに何が必要かを今から知ることは、意義のあることでした。