ウェルスナビのWebフロントエンド開発チームのEMの仕事

こんにちは！ウェルスナビのWebフロント開発チームのディレクターをしている伊代田です。
WNでエンジニアリングマネージャーを務めてます。
チームメンバーと一緒によりよいUI/UXをめざし、日々、課題定義、課題解決に取り組んでいます。
ということで今回は、WNのWebフロント開発チームにおけるエンジニアリングマネージャーの役割について、チーム構成や課題などに触れつつ紹介しようと思います。

Webフロント開発チームの構成

エンジニアリングマネージャー：１名（筆者）
Webフロントエンドエンジニア：3名（うち業務委託１名）

Webフロント開発チームの担当業務

Webフロント開発チームでは、担当業務を大きく以下の領域に分けています。

1.Web制作業務

「ユーザーに効率よく質の高い情報を伝えていくためのシステム開発」とチーム内で定義をしています。

業務例は以下になります。

サービス紹介サイト、コーポレートサイト、LPなどのコーディング（HTML/CSS/JS/Vueなど）
それらのサイトのシステムの管理・改善（WordPress/Laravel）
業務効率化のための改善・技術的負債の返却

Webディレクターやデザイナーの方と一緒に業務することが多いです。この領域について、シンプルにフロントエンドのコーディングとだけにしていない理由は、それらが乗っているシステムやトータルでみたときの業務フローの改善も視野に入れているためです。

ただコーディングするだけではなく、その先のユーザーとのコミュニケーションや深いサービス理解を持って、トータルでより良いユーザー体験を目指していきたい、という思いも込めています。

2.Webアプリ開発業務

「ユーザーの課題を解決するためのシステム開発」とチーム内で定義をしています。

業務例は以下になります。

ロボアドバイザー（WealthNavi）ブラウザ版のフロントエンド開発(HTML/CSS/JS/Next.js/TypeScript)
ロボアドバイザー無料診断ツールのフロントエンド開発（Vue.js）

PdMやデザイナー、バックエンドエンジニアと一緒に業務を進めることが多いです。
単にデザインを画面にしていくだけでなく、より良いUI/UXを追求し続けることを目指しています。

開発の進め方

チームの業務状況や携わるプロジェクトによって進め方が変わります。
チーム内に閉じる業務（リファクタリングや小規模な改善など）もありますが、業務の大部分は他チームのメンバーと協力して動くため、その案件の大小やスケジュール感に合わせて動き方が代わります。
私が直接プロジェクトマネジメント部分を担うこともありますし、メンバーが担当したり、また、別のチームがリードする形など様々です。

メンバーによって持ってるスキル、経験が違うため、得意不得意はありますが、まだチーム人数も少ないのでなるべく標準化できるように万遍なく担当したりドキュメントの整備を進めていくなどの工夫をしています。

Webフロント開発チームのエンジニアリングマネージャーの役割

私はエンジニアリングマネージャーとして自身の業務領域を大きく４つに分類しています。

ピープルマネジメント：組織戦略、チームビルディング、採用、目標設定・評価、etc..
テクノロジーマネジメント：ソフトウェア品質、技術戦略、技術選定、運用設計、etc..
プロジェクトマネジメント：アジャイル、PMBOK、リーン、デリバリーマネジメント、etc..
プロダクトマネジメント：プロダクト（システム）ビジョン、企画立案、ロードマップ、etc..

近年よく見る分類かと思いますが、シンプルに網羅されていて私は気に入っています。

エンジニアリングマネージャーによって得意領域は違うと思います。
ちなみに私は過去にWebアプリケーションエンジニア以外にもPjMやスクラムマスターを専任でやっていた時期があり、ピープルマネジメントとプロジェクトマネジメントの比重が高いタイプです。

これらの特性を活かしつつ、チームの課題を定義し、必要な領域を埋め、事業の成長に貢献していくのが私の役割です。
雑に言えば、いい感じのチームを作ることを任されているので、いかにチームとしての成果を最大化できるかを日々考えています。

特に最近は以下のことに力を入れています。

チームの戦略の立案と実行

チームが今後何を目指し、どうやってそこに行くのかを定義していきます。
事業の方向性や戦略に合わせてプロジェクトの整理や技術的な負債の返却の計画を立てています。
重視している点は、何を課題とするかです。
計画当初は意味があったけど、時間経過で意味あいが変わったものや手段が先行してしまったものは、改めて目的がはっきりするまでしっかり検討や調査をします。
これら課題の定義が完了したら事業やシステムへのインパクトを考慮し優先順位をつけて具体的な計画を立て遂行していきます。
ぱっと解決策が出るものでも、解決策が本当に問題を解決するものなのかはしっかり吟味します。

また、システムは作って終わりではなく運用・改善する期間のほうが長いため、開発されたものはいつまで使うのものなのか、ライフサイクルと運用体制の構築を考慮します。
運用面については、他のチームと連携しながら進める業務もあるので、チーム内だけの局所最適にならないようにトータルで最適なものを目指しています。
現状、チームの運用系の業務が成熟してきており、最適化されている点は非常に良いのですが、一部状況に合わせて更新が必要なものがでているため、改めて最適な形を目指して棚卸しを進めています。

メンバーフォローとキャリア構築支援

現状私含めて４人のチームのためプロセスや会議体はなるべく軽くしています。
チームとしての朝会も設定しておらず（プロジェクトによっては朝会はありますが）、チームの定例MTGは週に30分としています。
ただ、その分SlackやZoomなどを使い、必要に応じて気軽にコミュニケーションを取るようにしています。
幸い優秀なメンバーが揃っているので、困っていることがあればすぐにアラートを挙げてくれますし、担当になった業務は積極的に推進してくれているのでうまくいっています。

しかし、これも状況に合わせた形の一つではあるので、将来的にチーム規模が変わってきたときにはまた違った形を取ると思います。
ただその場合でも、なるべく効率的で効果的なプロセスの設計を模索し、特に形骸化したMTGやとりあえずのMTGみたいなものを最小にしていく動きは変わらないつもりです。

メンバーとは週次で1on1を行っています。
1on1のガイドラインをチーム用に作成し、展開しています。
話す内容はその時々で様々ですが、今後のキャリアの話を定期的に入れるようにしています。
会社の動きは日々変わっているため、個人の方向性と会社の方向性は定期的にすり合わせています。
1on1実施時に特に気をつけていることは、私がメンバーに期待していることをしっかりと明言することです。
やってほしいことは明確に伝え、必要なフィードバックはポジティブネガティブに関わらず、ちゃんと言語化するように意識しています。

キャリアについては、なるべく現実的なもので複数の形を考えられるようなヒントを提示しています。
あまり遠すぎるものだとステップが複雑になりますが、逆に絞りすぎても固定的になり広がりを持てないからです。
また、メンバーの選択肢を様々な点から広げ幅広い観点を持ってもらえることは、結果的にチームにも還元されることだと思っています。