この記事はEngineering Manager Advent Calendar 2024の5日目の記事です。
すでに12月も半ばですが、メンバーからEMアドカレ枠余ってるので何か書きませんか？と急遽言われたので、急いで執筆しています。とりとめもない文章になっていたらすみません。
これは何か
筆者は文系卒データ畑の人間ですが、この夏よりひょんなことからエンジニア組織のマネージャーをすることになりました。
一般的にEMと言えば、SWE→TLみたいな段階を踏んでからなるようなイメージがあり、実際色々調べてみても自分と同じような経歴の人はあまり見つけられていません。
自分自身この役割に対して適切な人間ではないのではないかと日々インポスター症候群に陥りながらも、とりあえずなんとかやっていこうと試行錯誤してきましたが、専門性が低い中どのような方向でバリューを出していけば良いか、なんとなく方向性が見えてきそうなので、自分の思考整理も兼ねて年末の勢いで記事を書きたいと思います。
※大前提、マネージャーがやるべきことは、組織の状態や規模、フェーズなど数多の外部要因によって左右されるため、あくまで今のAntwayにとっての話であり、一般化できる話ではないという認識です。加えて、Antwayも今後人が増えてフェーズが変われば、また求められる役割も変わってきそうです。
ここらへんはエラスティックリーダーシップが非常に参考になりました。
前提
▼筆者の簡単なプロフ
- 経済学部卒、新卒はマーケティング組織でデータ分析など
- スタートアップで1人目データ人材としてジョインし、組織立ち上げから基盤開発、ML開発、データ分析など幅広く対応
- データエンジニアの範囲でコードは書くが、低レイヤーのことなど何もわからない
▼組織の簡単な状況
- アプリケーション開発からデータ基盤開発まで幅広く対応（アプリ開発とデータ開発の2TMに分かれている）
- ソフトウェアエンジニアもデータアナリストも在籍
マネジメントの役割をながめる
まず、そもそもマネージャーとは、特にEMとは何をしたらいいのか、リサーチすることから始めました。
Antwayでのマネジメントの役割
Antwayではマネージャーが果たすべき職責として以下の観点が定義されています。Antwayでマネージャーたるために、まずはこの辺りを徹底する必要がありそうです。
| 観点 | 職責 |
|---|---|
| ストラテジーマネジメント | ・未来の企業価値を最大化する提案を行う ・予算やシナリオプランニングにおいて、未来観点でレビューを行う |
| ピープルマネジメント | ・心理的安全性の担保を行う ・エンゲージメントの担保を行う ・チームワーキングを実行し続ける |
| リソースマネジメント | ・コスト/人員の分配を適切に行う ・コスト/人員の獲得を適切に行う |
| ナレッジマネジメント | ・知識/知見を自部署や自分に閉じずに組織や会社全体に共有する活動を行う |
| バリューチェーンマネジメント | ・他組織調整・影響担保、横断リスク対応を行う |
| アウトプットマネジメント | ・成果物、成果の担保 ・非機能要件観点でのクオリティ担保 (特にコンプラや法務、セキュリティなど) |
| プロセスマネジメント | ・会社として正しいプロセスを踏んでいるのか担保 ・公的な意思決定、稟議などのフロー ・コンプライアンス、法務 ・バリューや会社としてのベストプラクティスに則っているか |
| セルフマネジメント | ・バリューの体現者としての振る舞い、コンディションを保ち続ける |
一般のEMの役割
また、一般論としてEMがやるべきことも眺めてみました。この辺りは皆さんが参照されている広木さんの記事を参考にしました。
色々重複はしながらも、一旦AntwayのEMとしては、自社の定義+テクノロジーマネジメントをやる人、みたいなざっくりの解釈をしました。
やること・やらないこと
ストラテジーマネジメント→やる
一番大事。エンジニアリソースが希少なので、事業に最もレバレッジが効く分野に注力したいです。
経営からだと見えない部分（開発生産性の低下や技術負債による長期的なアジャイラビリティ、スケーラビリティの毀損など）について、エンジニア起点でボトムアップで経営戦略にFBしていくことが重要と考えています。
▼愛読書たち
ピープルマネジメント→やる
メンバーが楽しく成果を出してキャリアアップしてほしいので、目標設定から評価・FBまで、かなり時間を割いています。
現在は、週次の1on1（メンバー主体で相談など）と月次の1on1（EM主体でFB）を行っています。また、D2Cというビジネスモデルでは、ソフトウェアとデータ&AIの両輪を回していくことが大切だと考えているので、一見遠いこの2TMで、情報の非対称性を限りなく少なくし、コラボラティブな文化を作れるようにチームビルディングを行っています。
リソースマネジメント→やる
スタートアップにおいてはとにかく人が（ry なので、1人エンジニアを採用することのレバレッジが高いです。
一方で、会社の認知度が低く採用力が弱いので、足で稼ぐ必要があります。スクラム採用とは言っても現場のエンジニアが割ける時間には限界があるので、マネージャーの頑張りどころです。
▼参考になった本
ナレッジマネジメント→やる
エンジニアの功績は社内の人間からしても分かりづらい、アピールしづらいと感じています。
個人的にはテックブログを発信することで、社内の人間に何をやったかを間接的に伝えつつ、社外にも採用コンテンツとして打ち出すことができ、加えてエンジニア自身のキャリアアップにもつながるので、組織的にアウトプットをサポートする制度を作りたいと考えています。
また、SRE・DevOps・ドメイン駆動設計などのエンジニア特有の考え方が、全社的に応用可能であると考えており、輪読会や勉強会などでこういう知識を他部署にも還元していくことで、事業成長につなげていきたいです。
▼こういうの読み合わせしたい
SRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本: Googleが実践している新DevOps方法論
バリューチェーンマネジメント→必要であればやる
会社としては、マネージャーを通さずにメンバー自身が他部署調整を行うことを推奨しているので、調整難易度が高い場合など、必要に応じてやるようにしています。システムの影響範囲なども現場が理解し、影響報告を自走できている方が健全ですよね。
アウトプットマネジメント、プロセスマネジメント→やらない
職責なのにやらないとかあるのかという気もしますが、ここは現メンバーがみんなシニアなので、基本は信頼してお任せしています。
知識が浅い中でドキュメントやコードのレビューなどのすべてに自分が入ってしまうと、自分自身がボトルネックになってしまいますし、時間対効果としてはかなり低いので、週次の定例で進捗を確認する程度しかやっていないです。
円滑に進捗を出してくれるメンバーに感謝。
テクノロジーマネジメント→ほぼやらない
自分が見ていたデータ周りは引き続きレビューしますが、アプリケーションのコードは上と同じで、シニアメンバーに任せています。ただし、大規模なリファクタリング・リアーキテクチャなどは、投資承認を得るためにある程度把握する必要があるので、メンバーにも細かく説明してもらいつつ、時間を使って理解するようにしています。
また、広木さんの記事でも、
マネジメントは様々なスペシャリストと対話をしながら適切な意思決定をしていくための機能です。なので、スペシャリストとの会話ができるような各分野への関心とリスペクトを持ち続けることが最も重要です。
とあるように、現場の課題感を理解する上でも、幅広く好奇心を持ってインプットしまくることを大事にしています。（ピープルマネジメントをする上でも重要）
例えば、メンバーとの1on1で出てきたワードを拾って、関連本を読むなどしていました。
セルフマネジメント→当たり前のようにやる
自分がやっていないのに、他者にやってほしいということはできないですよね。
まとめ
立ち上がりはわからないことだらけですごく大変だったが、4ヶ月経ってそれなりに組織として回るようになってきました。
多機能組織ですべての領域に精通することは物理的に難しく、どこかの分野では素人にならないといけません。そうした中で周囲からの信頼を獲得するためには、やはり理解しようとする姿勢をどれだけ真摯に見せることができるかなのではないかなーと思います。幸いそこの好奇心・モチベーションだけはまだあるので、来年以降も引き続きやっていきたい。
参考になったコンテンツ
▼とりあえず最速で王道を理解し、アンチパターンを踏まないために読む本 ウィル・ラーソンはなんかyoutubeのインタビュー動画とかまで全部見た。
▼組織の目標設定むずいなーって思った時に読む本
▼組織構成を考える時に指針となる本
▼ICとかTLのキャリア考える時に役立ちそうな本。今後キャリアラダーとか考える時に参照したい。
Discussion