こんにちはエンジニアリングマネージャの山元です。

この記事はVoicyアドベントカレンダー 23日目の記事です。

最近社内の特にPMチームで自分の役職を説明している記事が増えていて、確かにマネジメントって言語化しないとわからないよなあ〜と思って影響されて自分も書き出してみたいと思いました。ぜひプロダクトチームのみなさんの記事も見てください (文面真面目人間なので、キャッチーな文章かけて羨ましいです！)

PMの長のぶんたさんの記事

note.com

PMMのDさんの記事

note.com

この記事ではEM歴6ヶ月の自分が、「EMってなんだ？」から「こういうことやってるよ〜」となった思考のプロセスをつらつら書いていますぜひ以下のような人にぜひ！

EMになりたいエンジニア
EMのことを理解したい人
EMやっていて他社事例を知りたい人

EMが何かを定義しよう

まさかのここからです笑。

本などを読んで初めて知ったのですが、「EMが何か」は実は世の中の人はちゃんと教えてくれなくて、まるっと「適材適所だよ〜」と書かれています。 EMになったらまずEMの定義を作るのが仕事かもしれません。

前提としてマネジメントの言葉の定義を決めておくとドラッガー氏の「組織に成果をあげさせるための道具、機能、機関」が良いと考えています。

ではエンジニアリングマネージャは何をする人でしょうか？ソフトウェアファーストによると以下です。

実装を担当するソフトウェアエンジニアを取りまとめる役割です。及川卓也. ソフトウェア・ファースト (Japanese Edition) (Kindle の位置No.3124-3125). Kindle 版.

ここではエンジニアという人のリソースで成果を上げているマネージャですね。ピープルマネジメントで1on1してそうだな〜なんてやることが想像つきますね。そしてソフトウェアファーストにもしっかり適材適所ですよと書かれています。

これらはあくまで筆者が一般的な開発にあてはめて職種と役割を言語化したものなので、当然、企業や開発するプロダクトの性質によって細かい役割の違いがあっても構いません。大事なのはこうした職種を置くことではなく、それぞれがきちんと役割を全うし、機能させる環境を整えることにあります。及川卓也. ソフトウェア・ファースト (Japanese Edition) (Kindle の位置No.3131-3134). Kindle 版.

では適材適所がVoicyだとなんだろうと言う話になります。

世の中のEMの人が何をしているか検索してみましょう！

チームで1on1をしている人もいれば、PdMのようにプロダクトビジョンを設計してる人もいれば、開発している人もいます。彼らは包括的に考えるとどんな役割が必要なのでしょうか？

この辺りは広木さんの記事がEMの必要な知識体系をまとめてて、どのような役割が求められているか非常に参考になりました。

qiita.com

広木さんの記事にも書かれているように組織が作っているプロダクトがSoEかSoRかでも必要なスキルが変わったりします。チーム内でプロダクトマネジメントの力が足りてないのであれば、強いEMとなりそこに注力をする必要があるかもしれません。

さて必要な役割が揃ったところでようやく「VoicyのEMとはなんでしょうか？」という問いに答えられる材料が揃った気がします。結論を言うと

エンジニアリングでプロダクトの成果を最大化すること

がVoicyのエンジニアリングマネジメントと定義しています。当たり前では?という声も聞こえてきそうですが、広めな定義になったのは理由もあったりします。

半年前の状況を書き出すと

PMチームは揃っていてプロダクトマネジメントやプロジェクトマネジメント能力が足りている
一方元技術者がPMチームにおらず、テクニカルな面でのマネジメントが足りていない
ボードメンバーでエンジニアがいない

という形だったので、誰かしらかがエンジニアリング面でもリードをして舵取りをしていく必要になりました。そのため広くてかつ本質を外さないEMの定義となりました。

上記のような課題からVoicy×エンジニアリングでレバレッジが効きそうな項目を分析して役割を明確化すると以下になりました

長期的な技術戦略の策定(プラットフォームプロダクトマネジメント)
開発チームの効率最大化
エンジニアの成果最大化
品質マネジメント
組織開発

役割や実際にやっていることについてざっと説明します。

長期的な技術戦略の策定(プラットフォームプロダクトマネジメント)

これからプラットフォームビジネスとして成長していくと、ユーザは増えていきデータが溜まっていく中で、機能開発も簡単に行えるようになっていないといけません。今まではPMFで作成したプロダクトを成長を止めないような設計にするには機能開発だけでなく、リファクタリングなどそのためのタネを作っておく開発も必要です。そういった開発をどのタイミングで行えば間に合うか、それを前提とした足元の開発などが必要です。それはPMチームのプロダクトマネジメントには出てこない話題のため、EMが入ることで開発の優先度に入れ込むなどを考慮する必要があります。

開発チームの効率最大化

とにかくチームで開発するにあたって最大効率を出すためにはどうしたらいいかは考えなければなりません。まずはVoicyはSoEで不確実性の高いプロダクトであることもあり、スクラムがあっていると考えて全社でスクラムの導入をしました。これもまずは細かいルールよりも、現場のコミュニケーション量を増やして改善がとにかく回るようにすることと、ナレッジを浸透させることを重要視して行っています。実際に現場から改善が出てくるようになっているので、このナレッジを元にチームを分けて裁量を与えていくことなどを検討中です。

エンジニアの成果最大化

これはいわゆるピープルマネジメント。エンジニアにはやっぱりコードたくさん書いていて欲しくて深海まで潜って欲しいですが、そのコードがどんな風に事業に繋がるのかとか、皆がVoicyにいて成長してそれが事業の成長に繋がるを実感してほしいなんて思いながら話してたりしてます。また現場の課題は一番の宝と思って、課題が出てきたら

品質マネジメント

PMFに走ってた時はなかなかスピード重視でなかなか品質の担保が難しい中でそうもいってられなくなりました。ソフトウェア品質属性と言われるように品質の高いソフトウェアを作るためにはそれなりの知識が必要で、継続的なコミットが必要です。自分の翻訳した「Pythonではじめるソフトウェアアーキテクチャ」も参考になるので見てください(宣伝of宣伝)

www.kyoritsu-pub.co.jp

テスト書かれてないところにテスト書こうだとか、性能高く作ろうとか、失敗が起こらないように開発の仕組みを是正しようだとか、そういった開発のリソース配分をPMチームと一緒に考えて優先度整理をしていたりします。

組織開発

HRチームと話しながら、成果を上げるためにはどのような人材が何人必要か、どういったチームが最適かそういった話をしています。人事面接は多い時で毎日2回あります。一緒に働く仲間をさがすためにもワークサンプルテストなどかなり丁寧に採用選考を進めていたりします。またエンジニアカルチャー情勢のための取り組みも行っています。