この記事は、Merpay Advent Calendar 2021 の 5 日目の記事です。
@1000ch です。最近はメルペイのエンジニアリング部門にて、Android・iOS・Web を含むクライアントエンジニアリング全般を担当しているので、その話をします。
メルペイクライアントサイドの責務
メルペイのクライアントサイドはどのような領域を担当しているのか、俯瞰してみます。メルカリグループには、C2C マーケットプレイスを担うメルカリ、金融決済事業を担うメルペイ、メルカリ Shops を担うソウゾウ、フットボールクラブを運営する鹿島アントラーズ、暗号資産事業を担うメルコイン、物流事業を担うメルロジがあります。
一口に金融決済事業のクライアントサイドと言っても非常に様々で、いわゆる「iOS と Android のメルカリアプリのうち決済に関わる機能実装」だけで完結するほど単純ではありません。例えば、メルペイで決済できる加盟店さま向けのアプリとして店舗でスタッフさまとお客さまが決済オペレーションをするための iOS と Android アプリであったり、実際の売上や従業員の情報を管理する Web アプリなどがあります。他にも、社内のメンバーが加盟店さまを含むお客さまとやり取りするための Web アプリであったり、業務オペレーションのためのツールなども作っていたりします。また、メルカリ Web が新しくなったことは、iOS と Android アプリでしか実装されていないメルペイの機能を Web でも提供していく良い土台になりました。このように、非常に多岐に渡る領域へコミットする機会があり、これらのクライアント部分の実装をメルペイの Android・iOS・Frontend のソフトウェアエンジニアが担当しています。
メルペイのエンジニアリング部門では、この Android、iOS、そして Web という 3 つのプラットフォームをエンジニアリング部門のうちクライアントとして括っています。いわゆる Web 系の事業におけるエンジニアリングは、お客さまの端末で動作するソフトウェアを実装するクライアントサイドと、対比としてはサーバー上で動作するソフトウェアを実装するサーバーサイドとして大きく2つに分類されると思います。メルカリグループにおいてそのサーバーサイド部分は Backend と呼称しており、その対比という意味では Frontend が自然ではありますが、Web アプリケーションの Frontend を強く想起させるため Client というネーミングに落ち着いています。
もう一步引いてメルカリグループという視点で見ると、会社単位で分かれていることで意思決定を早めている側面がありますが、節々に発生しているサイロ化や、そもそもお客さま向けには単一のアプリを提供している事情など、グループ全体として足並みを揃えるべき所も存在します。Robust Foundation for Speed で挙げられているようにアカウント ID 基盤やメルカリグループで統合された CS ツールなどはわかりやすい例です。こうした全体最適に向けても、適時リソースのバランスを取りながらコミットしていく必要があります。
クライアントエンジニアリングでやりたいこと
メルペイのエンジニアリング部門では技術的な中長期目標を設定しクオーター毎の OKR や人員計画に活かすことを目的とし、エンジニアリングロードマップを運用しています。それに伴い、Android・iOS・Frontend における中長期的なフォーカスを抽象化したものをクライアントエンジニアリングのロードマップとして定義しました。分類すると大きく 3 つの領域があります。
品質
1つ目のキーワードは品質で、これはこれまでもエンジニアリング部門の OKR としても設定してきましたが、お客さまが利用するクライアントサイドとして担保できる非機能要件を掲げています。パフォーマンスやアクセシビリティといったものもそうですが、今年は特に Codecov への不正アクセスを起点としたセキュリティインシデントを受けて、会社そしてチームとしてシステムリスク管理体制の強化に取り組んできました。
こうしたセキュリティ対策の一環として、例えばサポートが終了している古いバージョンの OS をどのように扱うかという議論があります。サポートを終了している OS を使い続けることは、当然ながらお客さまにとってもリスクなので、OS アップデートを促していきますが、中には新しい OS がサポートしていない端末を使っている人もいます。その数はメルカリのユーザー規模からすると少なくありませんが、先のようなインシデントを未然に防いでいくための判断として慎重に議論していく必要があります。
生産性
2つ目のキーワードに生産性があります。品質と近しい話ではありますが、技術的負債の返済・優れた技術の採用・新しいコードベースへの移行などのトピックをここに分類しています。iOS チームは SwiftUI を、Android チームは Jetpack Compose を段階的に採用していくことを計画していますし、新しいメルカリ Web の話で触れているようなデザインシステムをメルペイの Android・iOS・Web アプリに適用していくことも、中長期的な生産性に影響していくでしょう。
負債も継続的に返済してきていますが、現在も新しい認証やログの基盤への実装移行などが積まれているように、リファクタリングのようなタスクは発生し続けるのが常であり、ここに計画的に対応できる組織体制を議論しています。案としては Client Architect チームのような「プロダクト開発に依存しないコードベースのあるべき姿に対して責任を持つチーム」を組成し、アーキテクチャの改善や負債の返済計画などを担当する中で持続的にカバーしてもらうことを検討しています。
組織
最後のキーワードは組織です。これはクライアントエンジニアリングに限らない話が多く含まれますが、できる限り多様性を高めて組織を強固にし、優れた意思決定をしていくとともに、対内外に魅力的な組織づくりをしていくことを掲げています。冒頭で述べたようにメルカリグループは分社化されているため、同じクライアントサイドのエンジニアリングでも人材が 1 つの組織に固定化しがちです。この点は、エンジニアが持つスキルやナレッジを循環させて個々の WILL を活かすために、そして組織そのものの自浄作用を高めるために、組織間の人材流動性を高める Internal Hiring のような仕組みを作る必要がありそうです。
Diversity & Inclusion は既にメルカリの経営戦略に組み込まれており、今後より多くの世界中の多様で優秀な人材を採用していかなくてはなりません。そのステップの 1 つとして English speaker を受け入れられる環境作りは依然として重要です。昨年書いた Merpay Frontend のこれまでとこれからでも触れていますが、組織としても英語力のボトムアップに長らく取り組んでおり、ロードマップの重要事項の1つに含んでいます。また、先日メルカリは LGBT＋に関する企業評価指標 「PRIDE指標2021」にて「ゴールド」を受賞することができましたが、利用言語に留まらない Diversity & Inclusion を組織へのインストールしていくことも続けていきます。
現状と目指す姿とのギャップ
これらの中長期ゴールを中心に各チームができることをそれぞれが考えてアクションしていますが、上手くいくこともそうでないことも多々あります。
複雑化するグループ間の連携
いわゆる toC のお客さま向けのアプリとしてメルカリを提供しており、単一のアプリに非常に様々な機能性を含んでいます。冒頭で述べたようにメルカリグループは事業領域に応じて分社化して、それぞれの会社にエンジニアリングチームがあり、単一のアプリにコミットしています。1 つの会社にある複数事業部間の調整だけでも大変ですが、会社を隔てていることがコミュニケーションを更に難しくします。意思決定を分けるという意図と相反するからです。
基本的にはアプリケーションは提供価値の設計に沿っているべきであり、ソフトウェアアーキテクチャの制約をなるべく受けないことが望ましいでしょう。とはいえ、現実問題としてはスムーズな運用のためにソフトウェアの責務を分けることが必要であり、ソースコードを分割して SDK のような形でメルカリアプリ本体に組み込むといったような工夫もしています。そして今後も複数のチームや組織が増える場面に備えて、柔軟に対応できるアーキテクチャにソフトウェアを刷新していくことも検討していかなくてはならないでしょう。
ソフトウェアのアーキテクチャだけではなく、コミュニケーションもそうです。Merpay Frontend のこれまでとこれからで触れている Client Platform Group という組織横断の繋がりを持つためのバーチャル組織がありますが、まずはこの立て付けで組織間の連携を強めて、メルペイとしてだけでなくメルカリグループのクライアントサイドとして取り組むべき課題の解像度を高めていかなくてはなりません。
包括的な組織に向けた更なる英語化
メルカリでは 2018 年 10 月にインド最強学生を受け入れてから、紆余曲折を経て急速に英語化が進んでいました。メルペイではこうした大きなモメンタムはありませんでしたが、メルカリの流れを受けて English speaker の採用が徐々に始まったり、メルカリとのコミュニケーションなどの機会において必要性が生まれるなど、緩やかに英語化が前進してきた印象です。
言語学習は一朝一夕で成果が出るものではありません。しかし、社内における Diversity & Inclusion が継続的に啓蒙されて浸透してきたり、English speaker がジョインしたりする中で、各チームの英語力は着実に前進しています。例えばチームミーティングで英語を使い続けた結果、初期と比べると明らかにスムーズになっていますし、ミーティングとしても成立しているという実感があります。定量的にも、社内で提供している CEFR に準拠した英語能力を測るテストの結果が1年前に比べると大きくボトムアップされており、A1-A2 レンジの成績が目立っていたのが、A2-B1 レンジに分布するようになりました。
自立してコミュニケーションできるレベルとして B1 に到達している意味は大きく、英語を話すことに対する躊躇がなくなっているので、あとは英語を使う環境を増やしていければ自然と改善されていくでしょう。例えば 2019 年始の時点で English speaker を受け入れることは難しかったかも知れませんが、2021 年末の今では大きく状況が異なっています。日本語を話せない English speaker も続々と入社していますし、これによって更に英語化も推進されていくでしょう。
ソフトウェア改善への恒常的な投資
ロードマップでも触れていますが、プロダクトの機能開発だけでなくソフトウェア品質の改善もエンジニアリングの責務として求められます。純粋なる機能開発だけを続けて負債が蓄積していくことになれば、やがてエンジニアリングが立ち行かなくなることは、様々な事例や我々の実感として明らかだと思いますが、@oinume さんのインタビュー記事にわかりやすい例えがあります。
例えば一軒家を建てたとします。 そして建てた後に2階にトイレを付けたいと思ったら、最初に建てた一軒家を改造しないといけません。その場合にいかにトラブルなく適切に改造していくかが問題になるんです。トラブルがあったらそれを直す時間を取らないと、どんどんその問題が悪化していく。
メルペイも会社設立から丸 4 年が経過し、様々な機能開発を繰り返す中で少なからず負債が蓄積しており、クライアントサイドも例外ではありません。もちろん、機能開発以外のことにエンジニアリングリソースを割いて来なかったわけではありませんが、今後も組織の規模化と複雑化が続く状況に於いて、より計画的に投資をしていくべきでしょう。ここはリソース采配について組織として合意形成すること、そもそものエンジニアを採用して数を増やすこと、の 2 点が必要です。
採用はその時々でオープンしているポジションが変化しますが、2021 年 12 月時点では Software Engineer (Frontend) と Software Engineer (iOS) を募集中です。各チームのマネージャやソフトウェアエンジニアと話したい等があれば適時中継しますので、ご安心ください。皆さんの応募をお待ちしています！
