こんにちは。メルペイのフロントエンドエンジニアの@tokuda109です。
この記事は、Merpay Advent Calendar 2023 の15日目の記事です。
Merpay Advent Calendar 2020 の「Merpay Frontend のこれまでとこれから」という記事で、メルペイのフロントエンドチームが2020年までに取り組んできたチーム組成やプロダクトの品質改善の話が紹介されました。(以下、前回の記事)
早いもので前回の記事が公開されてから3年が経ち、当時からチームの状況は大きく変わり、チームメンバーの人数が半数以下になるという危機的状況も経験しました。
この記事は、前回の記事の続編として、2020年以降にフロントエンドチームが取り組んできたことを紹介すると共に、危機的状況を乗り越えた経験から長期的に安定したチーム運営を行う上で重要だと感じたことを説明します。
Merpay Frontend のこれまで
OKRの目標分類
フロントエンドチームのこれまでを振り返る前に、OKR(四半期ごとに設定する目的とその筋道)の目標分類表を最初に紹介します。
この表は、フロントエンドチームがこれまでに設定してきたチームOKRの目標(Objective)を、いくつかの区分に分類したものになります。これにより、フロントエンドチームがどのようなことに取り組んできたかを時系列で把握しやすくなります。
フロントエンドチームのこれまでのOKRを振り返ってみて、以下の区分に分けることができました。分類した区分は長期的なチーム運営をする上で重要な要素になるため、後ほど詳しく説明します。
採用: 何人採用するといった具体的な採用活動や、社外への認知度をあげて採用につなげる活動プロダクト品質: フロントエンドチームで保守・運用しているプロダクトの品質(パフォーマンス、テスト、アクセシビリティ、セキュリティ)に関する取り組みプロダクトリリース: メルペイリリースやキャンペーン等のビジネス上の理由で開発完了時期が決まっている開発タスクの締切生産性: フロントエンドチームの生産性改善を目的としたタスクや、基盤技術を更新することで生産性の改善を図るもの。Nuxt.js / Vue.js のバージョン更新はここに含むロードマップ策定: フロントエンドチームの長期的なロードマップを策定するための取り組みチームビルド: フロントエンドチーム内のコミュニケーション改善やチーム内連携の改善する取り組み
目標分類表の見方を説明します。目標1、2、3 の番号は優先度を指し、1の方がより重要な目標であることを意味します。また、主な出来事 / 関連記事 には、その時期にフロントエンドチームに関係する重要な出来事やブログ記事、イベント登壇等の技術発表の情報を掲載しています。
| 四半期 | 目標1 | 目標2 | 目標3 | 主な出来事 / 関連記事 | |
|---|---|---|---|---|---|
| 2018/07 – 09 | 採用 | 採用 | プロダクト品質 | チーム組成期 | |
| 2018/10 – 12 | プロダクトリリース | 採用 | プロダクト品質 |
|
|
| 2019/01 – 03 | プロダクトリリース | 生産性 | プロダクト品質 | ||
| 2019/04 – 06 | 生産性 (安定運用) | 採用 | |||
| プロダクト品質 | ロードマップ策定 | ||||
| 2019/07 – 09 | 生産性 | 採用 | |||
| プロダクト品質 | |||||
| 2019/10 – 12 | 生産性 (DevOps) | 採用 | |||
| プロダクト品質 | |||||
| 2020/01 – 03 | 生産性 (CI/CD) | ロードマップ策定 |
|
||
| プロダクト品質 | |||||
| 2020/04 – 06 | プロダクトリリース | 生産性 | プロダクト品質改善期 | ||
| 2020/07 – 09 | プロダクト品質 (E2E) | プロダクト品質 (品質可視化) | |||
| 2020/10 – 12 | プロダクト品質 (E2E) | プロダクト品質 (品質可視化) | チームビルド (英語) | ||
| 2021/01 – 03 | プロダクト品質 | チームビルド (英語) | |||
| 2021/04 – 06 | プロダクト品質 (E2E) | 生産性 | |||
| 2021/07 – 09 | 採用 (認知度向上) | プロダクト品質 (セキュリティ) | |||
| 2021/10 – 12 | 採用 | プロダクト品質 | |||
| 2022/01 – 03 | 生産性 | プロダクト品質 (セキュリティ) | |||
| 2022/04 – 06 | プロダクト品質 | ||||
| 2022/07 – 09 | プロダクト品質 | 生産性 (Nuxt/Vue移行) | |||
| 2022/10 – 12 | ロードマップ策定 | チーム再組成期 | |||
| 生産性 (Nuxt/Vue移行) | |||||
| 2023/01 – 03 | 生産性 (Nuxt/Vue移行) | ||||
| 2023/04 – 06 | 生産性 (Nuxt/Vue移行) | ||||
| 2023/07 – 09 | 生産性 (Nuxt/Vue移行) | ||||
| 生産性改善 (ドキュメンテーション) | |||||
| 2023/10 – 12 |
|
目標を分類分けすることで、フロントエンドチームがこれまでに取り組んできたことを、時系列として次の3つの時期に分けることができました。
チーム組成期: 2018年〜2020年プロダクト品質改善期: 2020年〜2022年チーム再組成期: 2022年〜2023年
この3つの時期のうち、チーム組成期 と プロダクト品質改善期 は前回の記事で詳しく書かれているため、この記事では内容を簡単に振り返るだけにします。
チーム組成期
チーム組成期は2018年から2020年1月〜3月期にあたります。目標分類表から2019年2月のメルペイリリース前後で取り組みが大きく変わってることが分かります。リリース前は、採用やメルペイリリースに向けた開発が目標として設定されています。一方、リリース後は採用の優先度が少し下がり、プロダクト品質や生産性の改善が目標として設定されています。
2020年1月〜3月期には、Origamiからフロントエンドチームにメンバーが合流し、外国籍のメンバーもジョインしました。フロントエンドチームに多様なメンバーが揃ったことが、次のプロダクト品質改善期につながります。
参考: 株式会社Origamiのメルカリグループ参画に関するお知らせ
プロダクト品質改善期
チーム組成期を経て、フロントエンドチームとしてプロダクト品質の改善に取り組むことができる状況が整いました。フロントエンドチームがプロダクト品質の指標として掲げている パフォーマンス、アクセシビリティ、テスト、セキュリティ の4つの品質指標の改善に取り組んだのがプロダクト品質改善期になります。
プロダクト品質改善期には、日々の開発サイクルの中にプロダクト品質の検証をどのように組み込んだかや、指標改善の成果報告がブログ記事として数多く公開されたり、技術イベントで発表されました。
参考: メルペイフロントエンドチームで行っているパフォーマンス改善の取り組み紹介
チーム再組成期
ここからが前回の記事の続きの話になります。
プロダクト品質の改善に数年取り組み、プロダクト品質を最低限保障する体制が構築できつつあるなか、徐々にフロントエンドチームのメンバーが少なくなりました。
採用活動をしていましたが、チームを離れるメンバーの方が多く、最も少ない時でチームメンバーが最大人数の半数しかいない時期がありました。
この人数で以前と同様にマイクロサービスを保守・運用をしていくことは極めて困難であり、この危機的状況を立て直しているのがチーム再組成期になります。
フロントエンドチームがこのような状況に陥ったのはなぜなのか。当時のフロントエンドチームの状況について振り返ってみました。
- ロードマップがなく、チームとしてどのようなことに取り組んでいくべきかの話ができていなかったため、個人の優先度に基づいた行動になっていた。
- プロダクト品質の仕組みが大体完了した後、次の新しい目標を決めることができず、Flakyテストの修正といった改善系の作業を長期間やって精神的に疲弊した。
- ドキュメンテーションの品質が低く、ナレッジの属人化が発生し、開発の生産性が低くなっていた。
- 自社の技術イベントやブログ記事以外の活動ができていなかった。技術コミュニティとの関わりや外部カンファレンスの登壇等、外部情報発信が不十分でメルペイのフロントエンドチームの社外認知度が低下していた
- 採用の評価基準が整備されておらず、安定した評価ができていなかった
- メルペイリリースから数年経ち、プロダクト品質の改善も落ち着いてきて、次のキャリアを計画したり、新しい挑戦をすることを検討するメンバーが増えるタイミングだった。採用活動はしていたが、補うことはできていなかった
- チームビルディング不足で、チームメンバーが基本自宅からの作業になって、Slack上で業務報告するだけの関係になっていた。技術的な会話や、その他雑談をすることもなくなっていた。
ここに記載したものは、危機的状況に陥った原因として結びつけることができるものではありません。しかし、当時フロントエンドチームに対して課題を感じていたということは、チームとして解決しておくべきだったと言えることも事実です。
長期的に安定したチーム運営をするために必要な取り組み
先程の振り返りの内容を改めると、チームOKRと同じ分類を当てはめることができることに気がつきました。特に採用、生産性、プロダクト品質の区分に該当する目標は、これまでにチームOKRで何度も繰り返し設定されたものになります。それだけ採用、生産性、プロダクト品質は、チームとして定常的に取り組むことが重要であることが分かります。
プロダクト品質に対する取り組みは、メルペイを使う多くのお客さまの体験に直接影響するため、放置するわけにはいきません。しかし、それと同時にプロダクト品質を担保するためのチームの 生産性 やチーム力の元となる 採用活動 や チームビルド も重要です。つまり、ロードマップ から導き出される中長期視点で、これらの取り組みをバランス良く計画的に行う必要があるということを示唆しています。
ロードマップを策定し、チームの将来のあるべき姿を示した上で、採用、生産性、プロダクト品質、チームビルドに取り組むことが持続可能なチームを運営するために必要不可欠なことだと改めて知ることができました。
次に各区分毎にフロントエンドチームとして取り組んだことを紹介します。
ロードマップ
危機的状況の改善に向けて2022年10月〜12月期の目標1でロードマップの策定と、Nuxt 3 / Vue 3への移行の長期的なスケジュールが計画されました。そして、それを支えるための採用活動が計画されました。その計画の元で新しいメンバーを採用することができ、フロントエンドチームは落ち着きを取り戻すことができました。現在は新しいメンバーと共に新しいフロントエンドチームを組成し、Nuxt 3 / Vue 3への移行作業をしています。
ただ、メルペイではProgram組織という新たな組織構造に移行するのに伴い、メルペイのフロントエンドチームという組織単位がなくなりました。また、Nuxt 3 / Vue 3への移行後の計画はまだ練られていないため、いずれ計画する必要があります。
採用
新たなフロントエンドチームを組成するために、採用では次のことに取り組んできました。
- 書類選考の評価基準の整備
- スキルテスト評価システムの改善
- Vue Fes Japan 2023への参加
フロントエンドチームはチーム組成期から継続して採用活動を行ってきました。しかし、Merpay Tech Fest 2023の発表でも述べたとおり、適正な評価を行う体制が整備されていなかったため、うまく新しいメンバーを迎えることができず、チーム力を維持できませんでした。書類選考の評価基準やスキルテスト評価システムが整備されたのが、2023年になってからです。
また、チーム組成期には活発に行われていた外部イベントへの登壇は少なくなりました。自分たちのチームのことで精一杯になるあまり、Vue Fes Japan Online 2022の開催にイベントが終わってから気づくありさまです。もう少し外部コミュニティへの関わりを増やしたいと思い、2023年からVue Fes Japan 2023にイベントスタッフとして参加したり、会社としてスポンサーになることを始めました。(2018年のVue Fes Japan 2018でスポンサーになっていましたが、復活させました)
Vue Fes Japan 2023会場のクリエイティブウォール (筆者撮影): 壁面一番左にメルペイロゴを描きました
来年は自社ブログやイベント以外にも外部コミュニティに対する活動を増やしたいです。社外認知度を高めることで、メルペイのフロントエンドチームに興味を持ってもらえるようにしたいです。
生産性
フロントエンドチームが生産性の改善で取り組んだ内容は次のとおりです。
- モジュラーディレクトリ構成への移行
- Nuxt 3 / Vue 3 への移行
- GitHub IssuesとGitHub Projectsを使ったフロントエンドタスクの管理
- GitHub ActionsでWorkflowの共有化
- ドキュメントの整備
- GitHub Discussionsを使ってADR(Architecture Decision Records)を残す
- READMEフォーマットの統一
- オンボーディング資料の整備
フロントエンドチームは利用パッケージの更新に課題を抱えていましたが、モジュラーディレクトリ構成への移行によって、以前よりはスムーズに行えるようになりました。そして、今はフロントエンドチーム総出で Nuxt 3 / Vue 3への移行作業をしています。この移行作業には、GitHub IssuesとGitHub Projectsを使って進行管理をしています。GitHub Issuesに登録したタスクをGitHub Projectsに登録し、1画面で全リポジトリの進捗を確認できるようにしています。
次にドキュメンテーションですが、以前はADRを記録していなかったため、口頭で議論された意思決定が残っておらず、過去の意思決定に対する振り返りコストがかかっていました。今はGitHub Discussionsを使って議論し、チームとして決定するプロセスで運用することにしました。CIにはGitHub Actionsを使っていて、ワークフローを再利用して一元管理をしています。
ここで紹介したように、基本的に開発で必要なツールは、GitHubで提供されている機能に極力寄せたことで、ツールを横断する時のフリクションを少なくしています。
プロダクト品質
今までに沢山の時間をかけてプロダクト品質の改善に取り組んできました。一部の不安定なテストの改善が必要であったりするものの、日々の開発サイクルの中で自動的に品質の検証が行われる体制を整えられました。具体的に言うと、ソース変更をプッシュするとテストやアクセシビリティの検証が実行され、全てパスするまでマージすることができません。セキュリティに関しても同様で、セキュリティ警告の通知を担当者が処理し、どのような対応をするべきかを主導します。改善するべきところはまだありますが、最低限の品質を保障する体制は構築できています。
チームビルド
チームビルドの取り組みは、前回の記事で紹介されている通り、チーム内コミュニケーションの英語化になります。2021年1月〜3月期を最後に、チームビルドが目標として設定されていません。しかし振り返りで課題として出されたように、フロントエンドチームのメンバー間のコミュニケーション量はリモートワーク前と比べて大分減りました。これについては何かしらのアクションが必要で、単に量を増やせばいい訳ではありません。フロントエンドチームが組成された当初から、フロントエンドチームのメンバーが週に1回集まって技術的なトピックについて話したり、その他雑談をするWebWednesdayというミーティングがありますが、再度仕組みの設計が必要になりそうです。
Merpay Frontend のこれから
Merpay Advent Calendar 2023の2日目の記事で、@keigowさんからProgram組織についての紹介がありました。Program組織への移行は2022年10月から実施されましたが、フロントエンドチームは例外的に案件ごとにメンバーをアサインする形を当初取っていました。
現在はチーム状況が改善したため、2023年7月からフロントエンドチームもProgram組織へ移行し、メルペイのフロントエンドチームという建て付けは存在しなくなりました。
Program組織への移行によって、各Programが担当するドメインを深く理解し、プロダクト開発に取り組むことができます。また、Enablingは組織横断で取り組む必要がある基盤技術へのオーナーシップを持っています。Nuxt 3 / Vue 3への移行はEnablingが主導し、デザインシステムや共通ライブラリの更新を行ったり、難易度の高い技術調査をサポートしてくれます。これによって、プロダクト開発と基盤技術刷新における役割が明確になりました。(フロントエンドエンジニアも所属しているEnablingのClientチームの取り組みは、Merpay Advent Calendar 2023の18日目の記事で紹介されています。)
フロントエンドチームという建て付けはなくなり、フロントエンドチームとして設定するチームOKRはなくなりましたが、ロードマップ、採用、生産性、プロダクト品質、チームビルドはProgram組織への移行後も引き続き計画的に行っていく必要があると考えています。
最後に
この記事を書いた目的は、新しくフロントエンドチームにジョインしたメンバーに向けて、これまでのフロントエンドチームがやってきたことやフロントエンドチームの現在地を紹介するというのが半分、読者や社内のフロントエンドチーム外の方に向けては危機的状況から得られた知見を知ってもらうというのが半分になります。
長い記事になってしまいましたが、ここまで読んで頂きありがとうございます。
明日の記事は@gucciさんです。引き続きMerpay Advent Calendar 2023をお楽しみください。
