🌭

エンジニアリングマネージャーのしごと備忘録

2023/01/02に公開

manager

tech

概要

エンジニアリングマネージャーのしごとの備忘録

1日の作業イメージ

TODOリスト確認と優先順位付け
MTGの準備（1on1も含む）
情報収集（主に社内。チーム内外）
- 会社で何が起きているかを観測
MTGの場でのナッジング
- 議論に対して自分の観点を提供する
- 提供することで間接的に決定に影響を与えること
- 立場が上の人の意見は暗黙的な決定バイアスがかかることに注意しないといけない
意思決定
- 休暇承認などの小さいタスクから、インフラのクラウド移行など大きなプロジェクトなど、多岐に渡って結果に対する責任権を持つ
ロールモデルとしての振る舞い
- 物事をきちんと実行し、言うべきことは言う（同僚に実例で示すこと）

アウトプットの測り方

前提として マネージャー個人のアウトプットは重要ではない
以下の方程式で表すことができる

マネージャーのアウトプット = チームのアウトプット　＋　自分が影響を与えたチームのアウトプット

チームの週次サマリーを作ることで活動内容をチェックできるのでおすすめ
経験則的にマネージャー直下の部下は7人が適切。それ以上は時間を効率的に調整するのが難しくなるとのこと。

コードを書くマネージャーもいるかもしれない。それはそれでOK。ただし、第一優先すべき職務はマネージメントであることを忘れないこと。
実際にマネージメント業務が回っていない場合は時間の使い方を考え直すべき

1on1

相手の思考を引き出すための場で、全体の70％は相手のターンが良い
- 徹底的な本音でのコミュニケーション
- 相手のことを尊重するという意思
準備すること
- Googleカレンダーで定期のスケジューリング
- Google Docsでプライベートのドキュメントを作成し共有
1on1中にやること
- コントラクティング(相手と自分との期待値のすり合わせ)
  - サポートが必要な分野はどこか？
  - どんな形でサポートすれば良いか？（テキストベース、MTG前・後？人によって異なる）
- 一緒に働く上での障害は何か？（バックエンドが主戦場だった人がフロントエンドのアドバイスできないなど）
- サポートが上手くいってないとはどうすればわかる？
考えること
- その人に合った仕事を探す手助けをする（仕事に合った人を探すということではない）
  - 効率の良い成長タスクは、学習者が支援ありでできるタスク
    - 学習者側は実践を通じて成長する
    - 支援する側はメンタリングや委譲を経験する
- 人によってモチベーションは違うことを理解する
  - 管理と安定派(開発チーム主体的) なのか カオスと変化派(誰でも自由に皆の目があれば怖くない) なのか
    - 通常人の中でも時間によって変化していくもの

委譲するということ

委譲は難しい。現場でも適切にできている人は少ないが、実行できると大きな評価にはつながる

タスクの責任を自分から移動するということ(決して丸投げではない)
タスクの説明責任は持ち続ける(実行責任は人に託す)
人によって適切な委譲レベルは異なるので見極めが大切（その人がチャレンジになるぐらいの粒度が良い）
IC(インディビジュアルコントリビューター)として成果を出してきた人はできないことが多い
- ICは人に関するマネージメントを行わず、自分の専門知識やスキルを発揮することが期待される役割のこと
  - エンジニア、QA、デザイナーなどいろいろなICがある
- マネージャーはICが満足して仕事ができており、キャリア開発の機会を増やせるようにするのが義務

外部ゴールと内部ゴールの例

委譲するとは言っても難しい。委譲したタスクが期待通り終わることに賭けないこと
コントロールできない結果（外部ゴール）は手放すことで、精神的に楽になる
一方で、今置かれている環境下でマネージャーとしてベストを尽くす（内部ゴール）を目指すと幸せになれる

新しいプロダクトを発売して成功するかを極端に心配していること(コントロールできないので、外部ゴール)
代わりに成功するためにできる限り良くするためのベストを尽くすこと（内部ゴール）

メンバーが転職を考えていて、転職を思いとどまらせたい（メンバーが決めることなのでコントロールできない）
代わりにカウンターオファーを提示したり、居心地の良い職場環境を提供できるように努めたりする（内部ゴール）

プロジェクトが遅延することを極端に恐れること（ある時点を過ぎたらどうしようもないことはある：外部ゴール）
代わりになるべく早く完了するように、スコープやリソース、納期を調整する（内部ゴール）

評価面談について

評価面談が嫌な気持ちになる背景として会社からの一方的な評価提示という印象があるから
そして給与というお金の絡むイベントだから

パフォーマンスに焦点をおいた時間として活用し、意見交換を主とする時間の使い方を目指す

3部構成でMTG進める
- これまでの期間のふりかえり
- 将来について話す前向きな対話
- 達成可能な目標を作る協調的な時間
高いパフォーマンスを出す人の方が恩恵を受けるという雰囲気作り
- 低パフォーマンスの人の軌道修正をするような重箱の隅を突くようなフィードバックは良くない
ピアフィードバックは良いも悪いも深堀りできるテーマのかけらを探すために利用する

自分からの質問例

実績
- この半年間の自分の実績について考えてください(大きくても小さくても良い）。自分が成し遂げたことで満足しているものは何ですか？それはなぜですか？
ふりかえり
- 現在の自分の役割についてどう思いますか？前回の面談から、よくも悪くも変化しましたか？
成長
- この期間中で、もっともうまくできたと思うことはありますか？自分の成長のためにどんなスキルを身につける必要があると思いますか？
支援
- 将来自分の望む場所に到達するためにどんな支援を必要としていますか？

ピアフィードバック例

実績
- この人が半年でやったことの中で、あなたを感心させたことは何ですか？あなたから見て最大の実績は何だと思いますか？
成長
- この人物が集中して伸ばすべき部分はどこだと思いますか？どんな特徴やスキルなら取り組めそうですか？またはそこに到達するために、あなたが手伝えることは何ですか？
ピアフィードバック
- この人物へのピアフィードバックで重要なテーマは何ですか？お互いがすでに知っていることを補強するものですか？それとも新しい見解ですか？

採用

カルチャーフィットとは自分の感性に似た人を探すではない
才能ある人が多すぎるとある点からパフォーマンスは低下する(チームの調和が損なわれる傾向がある)
- 個々はそこそこだけど高い協調性を持つチームに劣る
チームにどんな人を入れたいかを考える
- チーム全体の力学を考えてベストな職務レベル
- チームに欠けている能力
- 持っているべきスキル

辞めるということ

従業員が辞めるのは普通のことであると理解すること
（必ず人は去るものであるということ）

辞めると言っても種類がある

良い離職：新しい機械を求める、報酬が良い、家族のことを考えて
悪い離職：報酬が良くない、同僚との人間関係、キャリアアップ、挑戦が欠如
パフォーマンスによる解雇

パフォーマンスによる解雇には手順があることを知ること
タフな仕事ではあるが、新しい人を迎えることでチームのパフォーマンス改善されるという良い面につながることを理解しよう

PIP(業績改善計画)

最終手段であり、他の方法がない場合の選択肢
実施機関は１〜３ヶ月
- 双方が合意して署名をしていること
毎週進捗について議論し、PIPに反していることへ警告を出し、証拠と共に上司やHR部に共有
作り方
- 職務内容の概要をまとめる
- 現在のパフォーマンスやふるまいの問題を検討
- PIPを通過するために設定できそうなゴール
- ゴールに必要な支援の必要性
- 個人的な状況への配慮（永久には続けられないことも考慮）

コーチング

相手が答えに辿り着けるように方向を誘導する質問をする場。
コーチ側が答えを特定しないことが大事。
実は、構造化された会話の型を繰り返すことで成り立つものでもある。
以下GROWモデルという型を使い、脱線しそうになった場合に参考にするのが良い

GROWモデル
- Goal: このセッションのゴールは何か？
- Reality: 今どんな状況？
- Options: 問題に対処するために考えられる方法は？
- Wrap-up: 出てきた選択肢の確認、コミット方法、サポートの有無の確認
2モードを適宜切り替え
- 指導モード: 相手が答えに辿り着けそうにないという場面で
- 興味に従う: 会話の各ポイントで相手が答えを絞り込んでいるかを意識し、相手がそうなるまで耳を傾け、示唆し続ける

人間の難しさ

マネージャーとしてメンバーの振る舞いで以下に遭遇することがあるので、対処方法について知っておく必要がある

ダニング＝クルーガー効果（自分の無能さ加減に気づいていないため、自信過剰にふるまってしまうこと）
- ジュニアエンジニア：過剰な自信さゆえに不適切な判断をするなど
- シニアスタッフ：現場から離れすぎてプロジェクトの達成可能性が直感的にわからなくなっているなど
- 対処法：懐疑的なものの見方をコーチングすることでインプットする。シニアほど自信満々なので受け入れるのが難しい
インポスター症候群（能力あるがそれを内向的になりアウトプットしてくれない）
- ジュニアエンジニア：シニアに囲まれているがゆえに相対的に自分の能力が低いと思いこんでしまう
  - 対処法：シニアとペアプロするなどして、時間をかけて自尊心を育む
- シニアスタッフ：自分の知識や努力以外によって成功が成り立つと思いこんでしまい、豊富な知識や経験を伝播させることができてないなど
  - 対処法：意見を吸い上げて現場に展開することで、生きた知識や経験であることを気づかせる

マネージャーは害となりうる問題の最終防衛ラインとして働く

社内政治的な問題だったり、人間的な要素を含むストレス高い課題だったり
マネージャーとして上にいくほど、抽象度の高い、不確実な課題が降ってくるので

組織上の立場があがっていくほど、好む好まざるに関わらずロールモデルとして会社の価値観を体現する役割が暗黙的に期待されていくものである

プロジェクト

生産性の低下について考える

人数が増えたからといって生産性は必ずしも上がらない
- 知的労働は簡単にタスク分解できない。コミュニケーションが必ず発生する。つまりコミュニケーションのオーバーヘッドにより遅れるリスクが増す。
  - ブルックスの法則
うまくいっていると仕事が増えるというジレンマ。これも生産性を低下させる要因
- ユーザーはより良いSLAを期待する。オンコール体制の強化。監視・アラートの改善、アーキテクチャの見直しなどが増える
レガシーコードを扱う機会が増える
- 昨日の新機能は今日の技術的負債である。つまり負債と向き合う機会が必然的に上がるのである
コミュニケーションとプロセスのオーバーヘッドが増す
- 3人のコミュニケーションパスは三角形で単純、8人のコミュニケーションパスはかなり複雑。それ以上はもう理解が億劫になる。
- 大企業のリリーススピードとスタートアップのスピードの違いの主な要因はこれ。人が増えることで承認プロセスが複雑になるのは避けられない

スコープ

MoSCoW法を使って優先順位をつけておくことで、マイルストーンが明確になり、チームが遭遇する負担を減らせる

MoSCoW法は、タスクをMust、Should、Could、Won'tにラベリングしておくパターン
Mustはリリースまで必達
Shouldは2回目以降で対処するリリース
Couldぐらいになるとストレッチゴールとして定義するのが良い

情報の取り扱い

マネージャーになると立場上嫌が応にも接する情報が増える
その中にはセンシティブだったり、組織上機密な情報も含まれる(1on1で内密に相談してくるとか)
だから扱い方を考えておく必要がある

機密性の高い情報例

報酬
パフォーマンス問題
会社の変革
余剰人員の削減

機密性のレベル

完全機密
密閉箱
開放箱

完全機密や開放箱レベルの情報の判断は比較的容易
密閉箱レベルの基準としては それを知っていると皆の役に立つ場合に限って周知する ただし全容を公開しないが良い

ふるまい
- スパイとして振る舞うよりもゲートキーパーとしてふるまう
  - 必要以上に機密情報を知ろうとするのではなく、他人が知る必要があるときに知る必要がある情報を共有する
- 社内政治を有効に利用する
  - 同じ課題を解決してくれそうなチームとつながる

良く手入れされたチームや部門を作るために

ギルドを活用して横断的な知見の共有を行う(サイロ化を壊す)
- ギルドはなぜ必要かという観点だとサイロ化を防ぐため
- 会社で言語を縛っていると、それぞれのチームで車輪の再発明をしているケースは多く、実際サイロ化してしまっている状態になる
- ある分野におけるベストプラクティスの議論や進化
- 複数チーム間の情報共有
- 例
  - 部門での特定のフレームワークの使い方の標準化
  - lintのconfig
  - セキュリティの重要性と可視化
  - デザインやUX手法の統一
  - 採用プロセスにおける基準の明確化(多様性やカルチャーマッチなど）
テックトークの文化を持ち込む
- チームから初めて部門に広げていくのが良い
問題を解決するためのドキュメントとしてアーキテクチャ決定記録（ADR）を作る
- コードベース管理（PullRequest）が活用の観点から良さそう
- GoogleDocsでも良い
チームを守る
- 自分がロールモデルとして率先して理想形を体現することが大事
- 労働時間を常識的な範囲にする（仕事は生活の1部にすぎないと意識する）
- 失敗したとしても実施したことを喜ぶ
- 重要でないことに対してNOを言うこと(集中と効率を保ち目標達成すること)

マネージャーのポジションの探し方

スタートアップの初期投資フェーズ or VCラウンドにポジションが転がっていることが多い
初期投資フェーズの場合はマネージャー第一号になれるチャンスがある

CTOとの違いとしては、CTOはプロダクトの開発に注力する。最初のマネージャーは、社内プロセスや採用、コミュニケーション、デリバリーのマネージメントを担当する。いわゆるVPoE。
(エンジニアたちのパフォーマンス、網羅的なラインマネジメント、1on1、評価面談、プロジェクトのリソース配分と優先順位付けなど)

スタートアップは失敗することがほとんど、しかし、スタートアップでの経験は市場において需要が高いので、次の仕事に困ることは少ない
（意欲的で、自発的、協力的で学習が速いとみなされるから）

そんな中マネージャーとして得られる経験は汎用性が高く、他の組織に移ったとしても活用できることを理解しておく

概要