エンジニアリングおよび各部門の検証結果を、サービス品質のSLO指標へ反映
――技術的負債もそうですが、品質向上についても上限なく行うことができます。そのレベルはどのように判断されているのでしょうか。
木村：確かにサービス運用の理想は、24時間365日とも障害もなく完璧に動くことですよね。でも、実際にはさまざまな理由で障害が起きるのが現実で、障害が起きることを見越した運用が求められます。
これを担保するには、まず「正しい状態」を定義し、その状態でないことにいち早く気づき、さらに同じ問題が起きないように対策することが必要です。この「正しい状態」を定義するのに、メルペイではSLO（Service Level Objective）の指標を使っています。例えば、iDの機能で「100%は正しく処理されることは難しくても、99％ならば正しいとする」というように、それ以下に下がるようであれば対応するという指標を設けるわけです。当然、技術だけでなく、ユーザーや市場の捉え方などビジネスの観点も重要なので、プロダクト側の意見も取り入れ、双方がコミットすることが必須条件となります。
また、新しい機能を導入する前には、社内のUXリサーチチームがユーザーに使いやすさを検証してもらったり、ABテストを行ったり、リリース前にできるだけ望ましい品質・機能を担保できるようにしています。リリースされてからも、実際の利用状況をアナリティクス部門が分析し、それぞれからフィードバックをもらいます。いずれにしても、プロダクト側から一方的に決定されるのではなく、エンジニアリング側からのフィードバックやユーザーテストの結果などによって適性な品質レベルを可視化し、双方の納得の上でSLOを決定するようにしています。
このSLOを定義して監視することで、インシデントについて報告があれば、起票してトラッキングするという流れをOKRに入れ込むようにしたところ、運用対象は増えながらもインシデントの発生は抑制され、対応についても１週間以内に完了できるようになりました。
――今後については、どのようなことに取り組んでいかれる予定ですか。
木村：新機能の品質向上を自動化できるような仕組みは、すぐにでも実現させたいですね。例えば、ABテストの自動化なども検討中です。
そもそもメルペイは、メルカリとの連携による独自のサービスが、他の決済アプリとの差別化ポイントになっています。メルカリでモノを売り、そのお金を使ってメルペイでモノを買うというサイクルは、メルペイだけができること。さらにメルカリとの連携を深め、付加価値を高めていきたいと思っています。別会社でアーキテクチャが異なるなど、違いは多様性という強さでもあるので、統合する必要はないと思うのですが、エンジニアリングに関してはノウハウの共有や情報連携などで協力し合う関係を深めていきたいですね。
究極はスペシャリストとして「信じ合う」こと、信頼を獲得するための小さな成功と真摯な説明
――開発から運用、改善まで、時として利害が相反することもあり、エンジニアリングの知識のない人に説明し、理解してもらうことは難しいと思います。その際のコミュニケーションで意識されていること、工夫されていることなどはありますか。
木村：1つは時間的な感覚の共有でしょうか。プロダクト側は「いつ出すべきか」という判断が、ユーザーや市場動向、ステークホルダーの意向など、事業的成功を意識した外部条件からなされます。マーケティングなどの部門もどちらかと言うとビジネスの観点ですよね。しかし、エンジニア側は、リソースや技術的観点から、実際に「いつできるか」という実現性の担保を意識して考えます。いわば内部的な積み上げから考えるわけです。それを互いが実感として持ちつつ、すり合わせて、どこから作るのがいいのか、どこまでシンプルな機能にできるかと具体的なスケジュールに落とし込むわけです。
もちろん、ひとりが経営的観点と技術的観点を両方併せ持って判断していくのが理想的ですが、プロダクトが大きくなればまず無理でしょう。メルペイの場合、メルカリや銀行など外部のステークホルダーとの連携まで行う必要があり、分担はどうしても必要になります。そして、それぞれの代弁者でもあるので、彼らを通じてステークホルダーに伝えてもらうことも意識しながら、できるだけわかりやすく説明するようにしています。
――調整役、推進役としての意味で、エンジニアリングマネージャー、そしてプロダクトマネージャーにはどのようなマインドやスキルなどが求められるのでしょうか。
木村：まずは「誰もひとりではできない、補完し合う必要がある」ことを意識し、相手の考え方を尊重し合うことが大切だと思います。
そのためには、言われたとおりに従うのではなく、互いが話す内容を理解できるレベルの知識は不可欠でしょう。例えばプロダクトマネージャーにエンジニアリングの知識や経験があれば、エンジニアリング側と話をする時にも通じやすくなります。「厳しい要件だけど……」などと、理解と共感を持って交渉できれば強みになるでしょう。逆にエンジニアリングマネージャーがプロダクト側と向き合う際には、エンジニアリング観点のロジックだけでは、平行線をたどるだけです。エンジニアリング側にもやはりビジネスの観点を理解する力は不可欠であり、それを踏まえた上で折衝・調整する力が必要だと思います。
とはいえ、利害関係が絡めば、お互いのロジックを完全に理解し合うことは難しく、とことん突き詰めてやろうと思えば、コミュニケーションコストは増大します。必要とあらばやらざるをえませんが、お互いにスペシャリストとして信頼関係が構築できたら、「任せること」も必要でしょう。そうした関係を築くためには、元に戻るようですが、しばらくは相手の見解への理解を示しつつも、自身の見方を丁寧に説明し、成果を出すという方法で、少しずつ信頼を獲得するほかありません。そのためには、誰にも負けない専門性に加え、相手の領域まで理解できるような幅広い見識を身につけることです。こればかりはマネジメントやプロダクト側との折衝など経験がモノを言いますが、メルペイではミッションステートメントに触れる機会が多いためか、エンジニア側もビジョナリーな人が多いように思います。
プロダクト側についても、エンジニアリングの知識や経験があった方がいいと述べましたが、たとえない場合であっても「エンジニアリングを軽視して失敗した」経験をすると、エンジニア側との連携を重視するマインドが醸成されるように思います。おそらく小さな失敗であっても、振り返りを正しく行うことで、伝え方のコツや勘所をつかめるのではないでしょうか。幸いメルカリ、メルペイのプロダクトマネージャーにはエンジニアに近いところで仕事をしてきた人が多く、創業者の山田進太郎も元エンジニアで、技術に対してリスペクトする文化が醸成されています。それが組織としての強みになっているように思います。
――「テックカンパニー」を標榜するメルカリの文化を引き継ぐメルペイもまた躍進が続いていきそうですね。プロダクト開発における、エンジニアリングマネージャーの考え方や振る舞いなど、大変参考になりました。ありがとうございました。
