メルペイ VPoE による2019年の振り返り

こんにちはこんにちは。前回のブログでお知らせしたとおり、Merpay Advent Calendar の1日目を、メルペイ VPoE の @hidek がお届けします。

はじめに

2019年もあっという間で、12月を迎えて終わろうとしています。ということで、メルペイとしての2019年を振り返ろうと思います。お題は「何かエモい話」と雑に振られたのですが、2019年に起こったことをなるべく赤裸々に淡々と書いていきます。

f:id:hideo-kimura:20191129132739j:plain

メルペイは2018年2月くらいから開発を開始していました。最初からマイクロサービスアーキテクチャの採用、Google Cloud Platform (GCP)を使ったクラウドネイティブな環境、と比較的モダンな思想のもとでの開発を続けています。ちなみに私が参加したのは2018年5月で、2018年中にはすでに決済基盤など大きなところの開発はかなり進んでいる状態でした。が、一方でなかなかリリース日が定まらずにもがいている状況でもありました。

1月〜3月

ハイライトとして、メルペイとして初のプロダクトリリースができた時期でした。2月には NFC による iD 決済機能、バーコードによる決済機能を提供しました。今だから言える話として、実は様々な理由から何回かリスケをしての2月13日のリリースでした。

なるべく大きなリリースにならないように、機能をフェーズに分けてのリリース、永遠に膨れ上がりがちな要件・仕様をフリーズさせるマイルストンの設置など、当たり前のことですが、スケジュールオジサンと言われながらバッサバッサとナタを振るって進めさせてもらいました。

最終的に不確実性をカバーしきれず無理くりなスケジュールとなってしまい、特に後工程のQAには無理をさせてしまったことは大きな反省でした。また、初めての GCP によるマイクロサービスアーキテクチャでの大規模リリースだったので、負荷対策調整がギリギリになり、アーキテクトチームやSREチームに奔走してもらったのも反省が残りました。が、全員の協力もあり、自分たちのプロダクトをリリースすることができて、社会に対して実際に使っていただけることができました。

4月〜6月

この時期には、メルペイスマート払い(リリース当時はメルペイあと払い)とeKYCによる本人確認機能のリリース、ゴールデンウィークのキャンペーンがありました。社内のビジネス的要件として、ゴールデンウィークのキャンペーンに大きな投資をすることになっていて、その効果を最大化するためにメルペイスマート払いとeKYCのリリースが必須でした。

実はこのリリースのためにはメルペイ内で大きな問題を抱えていました。この時期にリリースするためには遡って1月から開発を着手する必要があったのですが、前述の通り2月からのリリースラッシュを控えていて、メルペイ内では到底その工数を出すことはできず、メルカリに応援を頼むことになりました。社内では「All for One 連携」と呼ばれた組織施策です。総勢30人を越えるエンジニアの一時的な異動が行われました。結果としてリリースすることができて、ビジネス的には良い結果を出して成功を収めたのですが、組織的・技術的には課題の残るものでした。

まず、メルカリ側は、異動に伴って多くの施策を止める必要がありました。その結果、着手していたものを作りきらずに、他のことをキャッチアップしてもらうという、エンジニアにとって大きなストレスをかけてしまったと思います。いわゆる組織的負債を大きく負ってしまうことになりました。私がもう少し早く調整に動いていれば、ここまで大きな工数調整にならなかったので、大いに反省が残る施策でした。

技術的な課題としては、機能追加としてメルカリの既存システムに手を加える必要があったので、本来であればマイクロサービスとして切り出してから進めるべきなのですが、それだと求められるデリバリーにミートしないため、一旦既存システムに実装を行い、後に切り出すことを選択しました。意図して技術的負債を負う選択をしたわけです。この判断自体はリリースということでは良かったのですが、負った技術的負債が想定より大きかったという課題が残りました。これについては今現在も返済中です。

この辺りのビジネス判断とのバランスがすごく難しく、何が正解だったのかはわかりませんが、これまた大いに反省が残る期でした。

7月〜9月

1月〜6月のリリースラッシュで溜まってしまった技術的負債の返済をテーマに掲げた期でした。昨年の11月辺りにデリバリーをロックしてリリースを続けることを決定した時点で、技術的負債が貯まることは予見できた、または意図して負債を借りていたこともあり、4月くらいから、リリースが一段落したら技術的負債の返済に工数を充てたいということを社内全体に繰り返し伝えていました。

幸いなことにメルペイ経営陣にはIT業界二周目のメンバーが多いこともあり、理解を得ることができて、この期の会社全体のOKRに「技術的負債の返済」を入れることができ、推進することができました。前もって分かりやすく繰り返し唱えることは結構重要だなと思いました。

技術的負債と言っても利子を払い続けたほうが良いものもあるので、会社としてリスクが大きいもの、部署横断で意思決定が必要なものの二軸で施策をピックアップして進めました。
例えば、比較的古いマイクロサービスのストレージ移行や、メルカリモノリスに大きく実装しているもののマイクロサービス化、iOSやAndroidのリファクタリング、DevOpsの整備などを行いました。

今回は一旦大きく負債を抱えてしまったこともあるので、トップダウンで大きく返すフェーズを設けて会社全体の目標に入れたのですが、結果として技術的負債というものの理解がエンジニア以外にも進んだのは良かったと思います。今後は各プロジェクト単位で常に借りては返すプロセスを息を吸うように行える文化になるといいなぁと思っています。

10月〜12月

幸いなことに、今の所メルペイでは決済が全て止まってしまう、といった大きな障害を出すことなく運用できているのですが、実は小さな障害は日々起こっていて、その対応にエンジニアが追われる問題が顕在化してきました。

前期の技術的負債返済施策で全て返せればよかったのですが、大きな負債ほど返すのに時間がかかるわけで、その後遺症が残ってしまっているとも言えます。すでにシステムは稼働していて日々の運用の中で細かな障害が出て、その対応にエンジニアが追われてしまい、新しい機能追加ができないというジレンマに陥ってしまいました。

これに対して、期初に会社全体の目標にインシデントレスポンスの向上を入れて、新しい機能追加よりも本質的な解決や再発防止をする仕組み作りを優先することになりました。また、リリース時に設定したSLOも運用を経て変更する必要があったので、このタイミングで見直しをかけています。

今後

2019年は、1月〜6月をリリース7月〜9月を技術的負債の返済10月〜12月をインシデントレスポンスの向上、とそれぞれ技術的なお題を設けて来たのですが、全てメルペイとしての会社のOKRに入れることができて推進できたのはテックカンパニーっぽくて良かったと振り返っています。

来年のキーワードとして、最近社内のあらゆるところで呪文のように唱えているのが、プロダクティビティです。

今までスピード優先で開発・運用をしてきた中で、ある意味人の数で解決してきたところがあります。このまま人を増やすことだけで解決するのはテックカンパニーとしてイケていないので、テクノロジーで生産性を向上することをテーマにしようと思っています。自動化、省力化、共通プラットフォーム化みたいなものを Development Productivity (開発生産性)が向上するもの、Operational Productivity(運用生産性) が向上するものと整理して、両輪で進めていこうと思っています。これらも全社で意識するために、会社全体の OKR に入れて推進できたらいいなーと考えています。

というわけで、淡々と2019年を振り返りました。ホットな事業環境なので今年も想定外のことがたくさん起こってかなりエキサイティングでしたが、来年もこの状態は続くと思います。そんな中でビジネスとエンジニアリングのバランスを取りながら、同じゴールを目指す仲間たちと世の中に様々なサービスを届けて、なめらかな社会を実装できればと思います。もしこの振り返りを見て、面白そうな会社だなと思った方は、ぜひキャリアサイトをのぞいてみてください。

来年もよろしくお願いします!

f:id:hideo-kimura:20191129132838j:plain

というわけで、2019年 Merpay Advent Calendar のはじまりはじまり!

明日のMerpay Advent Calendar 執筆担当は、Frontend チームで Tech Lead と Engineering Manager を兼務している @1000ch さんです。引き続きお楽しみください!

  • X
  • Facebook
  • linkedin
  • このエントリーをはてなブックマークに追加