2021年10月から、サービス・機能開発の基盤を強化するRFSプロジェクトを始動したメルカリ。

RFSとは「Robust Foundation for Speed」の略で、メルカリグループ全体の非連続的な成長を支えるため、ビジネスの共通基盤に潜む複雑な技術的課題の解決と抜本的な強化を図るのが、RFSの目的だ。

プロジェクトスタートから1年以上が経ち、いまプロジェクトはどのように進捗しているか。本プロジェクトの責任者を務める塚穣（Director of Developer Productivity Engineering）と、木村俊也（VP of Platform Engineering）、ふたりのキーマンに話を聞いた。当初はプロジェクトにおける課題やボトルネックはなんだったのか、そしてそれをどのように解消していったか…という、いわゆる「プロジェクトの裏側」を聞き出すことを想定してましたが、この1年を振り返って語られたのは、技術基盤強化そのものよりも組織の進化への手応えだった。

関係値を構築するために必要なのは「相手が受け取りやすい文脈をつくる」こと

──いま、RFSというプロジェクトはどのように進捗しているのでしょうか？

＠mtsuka：プロジェクトそのものの進捗というより、関わっているメンバーの視点の話になるのですが、マインドセットを変えていこうというのは、プロジェクトがスタートした当初から願いとしてありました。それはwakasaさんやkimuraさんにも同じような考えがあったと思います。

「マインドセットを変えていこう」とはどういうことかというと、「自分たちがやりたいからやろう」という考え方ではなく、「ビジネスの貢献のためにやっていく」ということです。そういう前提のもと、クォーター、半期ごとの成果を意識してきましたし、それをエンジニア組織のメンバーはもちろんそうですし、外側にいるメンバーにも伝わるようにしなくてはならないと考えています。

いまそれが十分に伝わる状態になっているかと言ったら、まだまだというのが正直なところなのですが、エンジニア組織のメンバーたちの間でも、みんな意識的に言語化するようになってきました。

いままでエンジニアはビジネス貢献について上手く言語化できていないところもあったと思うんですけど、視点を高めてもらえたということは一定評価ができるのではないでしょうか。仕組みとしてかなり成立してきたと思いますが、やはり定性的な部分なので、もう少し定量的に計測していきたい。

あと、テックPMの人たちが議論にフラットに参加してもらえるようになってきたのは大きい、僕もチームビルディングに呼んでもらえるようになりました（笑）。それはけっこう良いことだと思っている。私たちとしては、「自分たちの理想郷をつくる」ということを目指しているのではなく、事業に貢献する強いエンジニアを採用していきたいし、そういう人たちにとって興味を持ってもらえる状態で有り続けたい。

塚穣（@mtsuka）

＠kimuras：なるほど。外部から理解を得るために、どのようなことが大切だったのでしょうか？たとえば、チームビルディングに呼んでもらえるようになったのは、「関係値をつくった」ということなのかなと思うのですが。

＠mtsuka：抽象的にいうと「相手が受け取りやすい文脈をつくる」ということだと思います。「なるほど、それはいいね」と相手に思ってもらえる状態をつくる。やっぱり人は自分が理解したいようにしか理解しないですよね。本来的には、職能はどうあれ、みんな共通の目的を持った仲間として働いているわけですよね？だけど、追っている数字や、責任を持っている数字が当然違う。仲間なんだけど、エンジニアとは異なる理論や前提においての相互理解を築いていくことだと思います。wakasaさん（メルカリCTO）は「相手がわかるように伝えよう」とたびたび言ってますよね。

＠kimuras：RFSがはじまった時といまのいちばん大きな違いは、プロジェクトの主体性なのではないかと思います。最初はエンジニアが主体のプロジェクトだったので、どうしても「エンジニアがやりたいこと」を進めているイメージがあったと思うんですけど、そこは大きく変わったなと。ある時期から、テックPMが計画を推進してくれるようになったじゃないですか？システムのファンデーションの改善案をPMが主体的につくるというのは簡単にできることではないと思います。なぜなら、エンジニアとPMの役割がはっきりと分かれてしまっていることが多いからです。

いまのRFSの状況としては、「エンジニアがやりたいこと」というより、PMと一体となって同じ方向を見て進められるようになりましたよね。

＠mtsuka：確実に「一緒にやっていくんだ！」というマインドになりましたね。

＠kimuras：そう。same pageになりましたよね。お客さまに価値を届けるには、一緒になってファンデーション開発することが必要で、その土台ができたと感じています。これが構築できたひとつの要因としては、さっきtsukaさんがおしゃっていたように「言い続ける」ことが重要で、どんな規模の組織でもそこに一定の努力が必要だと思います。

木村俊也（@kimuras）

──同じ方向を見られるようになったことは、エンジニアにとって開発しやすい状況だと言えると思うのですが、PMとの協働は開発組織としてあまり実現していないのでしょうか？

＠mtsuka：実現したいんですよ…みんな。多くのエンジニアと話していると、「エンジニア組織は…」と主語を大きくして、組織論を話しがちなんですけど、彼ら一人ひとりはみんなビジネスに貢献したいと真剣に思っている。でも、どうすることが最善の方法かわからずにいるというジレンマがあったと思います。いまはようやく点が線につながりつつある状況になってきました。

＠kimuras：メルカリのユニークなところとしては、RFSのようなプロジェクトの技術的な進捗をエグゼクティブミーティングで定期的に報告しているんですよ。tsukaさんは苦労されていると思うんですけど（笑）。一般的に経営層は必ずしも技術に精通しているわけではありません。だから、継続的に説明をし続けないと、ある日「なんでこんなにリソースがかかっているのか？」という話になりやすいんですね。

＠mtsuka：お互いにサプライズが起きる（笑）。

＠kimuras：エンジニアからすると、この手の話を経営層にするのは勇気がいるんですよ。技術的に難易度が高いトピックですし、価値を正確に伝えるのはとても難しいので。

＠mtsuka：そう。その価値がきちんと理解されないと、「もっと早くできないのか」とか言われてしまいがちですからね…。

＠kimuras：あと、なにも質問がないとか（笑）。でも、メルカリの場合はディテールまでちゃんと質問してくれるから、そこはやっぱりけっこうユニークだなと。定期的にwakasaさんやtsukaさんが、エグゼクティブミーティングでプロジェクトをレポートして、適宜承認を得てきているからこそ、いまの状況があります。最初は基盤構築への大規模な投資に対して懐疑的な場面がなかったわけではありません。しかし、いまでは経営層がサポートし、後押しをしてくれている。Jeff（メルカリジャパンCEO）からも「全社一丸となってRFSに注力していこう」というメッセージが発信されている。これはエンジニアにとってすごく幸せなこと。

＠mtsuka：shujiさん（上級執行役員 SVP Strategy）もAll Hands（全社会議）で、「短期の誘惑にとらわれず、長期的なことに投資していく」というメッセージを出していましたね。経営としての意識をさまざまな場面から感じることができます。なかなかないと思いますよ、こういう会社は。

＠kimuras：ひとえに言い続けたことですね（笑）。

＠mtsuka：そうですね（笑）。タグラインを年単位で維持するのが、けっこう重要だったかもしれないですね。

数値化すべきはアクティビティではなく“状態”

──このRFSによって、どんな変化が組織としてあったのでしょうか？

＠mtsuka：いまの世界的な経済状況があまり良いとは言えないなかで、改めて根本的な機能や体験を見直す機会が増えた気がします。そうしたときに、これまで良くも悪くもスピード重視でやってきたことが明らかになるんですね。こうした積み重ねによる「負債」を、場当たり的に直していくべきではない、ではどうしていくのが未来への投資となるのか、いまは立ち止まって考えるようになってきていています。まさに自分たちの持っているコンポーネントをユーザー体験ベースで見直して、本質的な改善に向かっています。

これまではスケジュール前提で議論を詰めきらずに実装をしてきたところは否めません。いまはより本質的な改善のためのコミュニケーションができるようになり、組織として進化してきたと感じています。

少なくともRFSで推進していることに関しては、いったんリクワイアメント（機能要件）は満たします、ただし本質的な改善も平行して進めていきます、というようになってきました。PMとの合意形成のもとに計画が成り立っている。

＠kimuras：継続的に仕組みやリファクターを改善していくことによって、すぐに新たな変更に着手しやすくなっているんですよね。それは、エンジニアにとってもPMにとってもwin-winなケースとなっていきます。いまは、領域的に「CS Tool」と「Transaction」「Logistics」といったシステムを集中的に取り組んでいるんですけど、ある程度デカップリングが進み、マイクロサービス化され、技術的な貢献が目に見えてわかりやすくなってきているから、各所での理解を得られやすくなってきましたね。そうしたこともあって、PM陣も計画にRFSのことをあらかじめ組み込んでくれるようになった。それは自分たちのメリットとして理解できるようになってきたから。

──それは組織の成熟といえるのでしょうか？それとも個々人の成長というべきでしょうか？

＠mtsuka：端的にいうと「歯車が噛みあった」ということです。これまではスピード重視でもなんとか成立していたというか、言葉を選ばずにいうと「誰かが無茶苦茶がんばらないといけない」仕組みだった。それが「誰かが無茶苦茶がんばらなくても」仕組みとして回るようになってきた。あまり好きな言葉ではないですが、「技術的負債」がそのままになりにくくなった。

＠kimuras：「技術的負債」の解消ってビジネス的な価値がわかりにくいんですよね。tsukaさんが「歯車が噛みあった」と言ったのは、「技術的負債」の解消がちゃんとビジネス貢献になったということだと思います。バリューを生むためのひとつの施策になった。

＠mtsuka：「負債」というとネガティブな表現に聞こえますが、ずっと言い続けているのはシステムの「メンテナビリティ（保守性）」を維持しましょうということ。メンテナンスしやすい、みんなが取り回ししやすい、それが重要なんです。自分たちの営みのなかで保守性が高い仕組みをつくるのはプロとして当然、ということをメンバーには言い続けています。ひとことで「システムの保守性が高いとみんな幸せだよね？」という感じに、それぞれの役割の文脈のなかで理解され、プライオリティが上がってきたという実感があります。

＠kimuras：tsukaさんに改めて質問したいんですけど、見えてきた課題はそうした「貢献の数値化」だと思うんですよね。とはいえ、数値化は難しいですよね？そこに対しての考えを聞いてみたいです。

＠mtsuka：おっしゃるとおり数値は難しいですね…。どうしてもアクティビティを数値化しがちなんですけど、実際にはそれだけじゃないとも思うんです。結果から考えた時に、メンバーがプロダクト開発ないし、事業会社がサービス運営していくときに、「自分の仕事に満足できていますか？」という“問い”がまずあると思うんですよね。あと陥りやすい問題としては、ある意味エンジニアらしいというか、精緻な数値をとらなくてならないと思い込んでいるフシがあるのですが、プロジェクトの“状態”が上手くいっているのかを可視化できればいいということもある。もちろん、正しく見なければいけないポイントもあるので、濃淡をつけながら計測できるといいのがヘルシーだなと思っています。

＠kimuras：tsukaさんが別の記事で「計測なくして改善なし」という宮坂さん（東京都副都知事）の言葉を引用していましたけど、計測するためのシステムを作ることも容易ではないので、なんでもかんでも計測すればいいというわけではないんですよね。

＠mtsuka：そうなんです。データドリブンの観点で意味のある数字を取らないといけない。

＠kimuras：やっぱり数値化しなくてはいけないのは「状態」ですよね。もちろん、僕らも一緒になって考えていかなくてはならないんだけど、現場のいちばん詳しい担当者がKPIをつくっていけるようになるのが理想です。

これはすごい大事な議論なのですが、RFSのメンバーが、「ビジネス貢献から考えるとこれは必要ない」とか「いまは優先順位として着手しなくてもいい」と、はっきりと言ってくれるようになったじゃないですか？明らかに「これは本当に必要なのか？」と考えるマインドに各チームがなってきていますよね。プロジェクトに関わるメンバー全体がすごい洗練されてきている。やみくもにリファクタリングするのではなく、ビジネス的に価値が高いところから優先的にやっていこう、あるいは内容によってはあきらめることも必要、そう考えられるくらいメンバーたちが増えてきている。tsukaさんが数値化したいといっているのはそこですよね？

＠mtsuka：そうです。私たちは基盤構築に対して時間を使っていいと言われているのですが、その時間にはもちろん人件費などのコストも発生しているので、いわばこれは投資なんです。この投資に対して妥当性があるのか、上手くいっているのか、あるいは上手くいってないのか、説明していく責任がある。その文脈のなかで諸々の議論をしていくことが、現場でも腑に落ち始めていると思うんですよね。

＠kimuras：PMとエンジニアがよく議論したからこそだと思いますね。ちゃんとプライオリティを自分たちで決められるようになっている。

RFSとはなにか…？改めて意味と意義を問う

──さまざまな議論を経てきたからこそ…という視点で、ほかに課題と感じていることはありますか？

＠mtsuka：あえていうとOKRの弊害みたいなものは少なからずあります。目標を持つ以上、やっぱり、自分たちのエリアしか見えなくなりがちです。もっと高いレベルの話にしていくのであれば、グループの中期経営計画はこうなっていて、Roadmapはこうなっている、それを達成するのはこういう準備をしていく必要がある…というレベルでリードする人が出てくると、組織として強くなりますよね。

＠kimuras：歯車は噛み合ってきているのは確かですが、計画に対する論理的な詰めに甘さはまだあると思います。「なぜいまそこに着手しているのか」「なぜこの順番なのか」、ここはもっと磨き上げられるとと思っていて。それが中期経営計画に従ってプライオリティを決められて、実現していけたら、本当に完成ですよね。PMも理解しているし、経営も理解している、エンジニアも価値を理解している、三位一体の状態。

＠mtsuka：これができるようになれば、会社としてはより効率的に事業を伸ばすことができる。また、事業にわかりやすく貢献していることにだけ注力していくのでは、途中からスケールしなくなっていくので、次のフェーズへの投資ができるようになってくるということなんだと思います。

＠kimuras：だいぶ整理されてきたからこそ、こういう議論ができるようになりましたね。最初はもう暗中模索の期間で、ようやく「なにをやったらいいかわからない」から「なにをやればいいかが明確になってきたきた」に明らかに変わってきた。計画を洗練させるところにいま向かっている。ここまで話してきて、究極的な問いかけとしてメルカリにとって「RFS（Robust Foundation for Speed）とはなんなのか？」、これをtsukaさんに聞いてみたいです。

＠mtsuka：エンジニア的な表現でいうならば、自分たちがビジネスイネーブルメントであるための約束事ですね。全社的な視点でいうならば、エンジニアがビジネスに加速器として貢献するための投資。RFSはまっとうな合理性があるプロジェクトだし、組織づくりという観点からも難しい問題に取り組んでいる。

＠kimuras：ある意味、イネーブリングするためのメタ的なきっかけみたいなものですかね？

＠mtsuka：僕はそう思っています。象徴的なものだと思うんですよね、オーソリティそのものというか。でも変に権威化してしまうと、すぐに手段が目的化するから、「メンタルモデル・アップデート・プログラム」とでも言うんですかね…。

＠kimuras：僕の解釈だと「カルチャーのアップデート」なんですね。僕らはこれまで高速にいろんなものをPOCを繰り返し、実験をしながらサービスを改善してきたけど、どこかしらのタイミングでそのやり方のままだと破綻してしまうんですよ。それが破綻する前に、組織としてのやり方、これまで自分たちがいいと思っていたことを、アップデートしていかなくてはならない。新しいことを始める時って、どうしても軋轢が生じたり、前例を踏襲したくなると思うんです。2年間ぐらいこうしたことを言い続けてきて、はじめてカルチャーになってきたという実感がある。それがカルチャーになってしまえば、極論をいうと「RFS」なんてお題目は必要ないんですよ。自然にみんなが行動を取るようになるから。いま、兆しとしてそうなりかけてきている。

＠mtsuka：若干慣れてきたというか、やりきった感すら出てきているので、「いやいや、これは無限に続くので…」というところを、また巻き直すんだろうなという感じもしています（笑）。

──では、こうしたカルチャーのアップデートの先に、どのようなことを組織として重視していくのでしょうか？

＠mtsuka：これは何度も各所で言っていることですが、基本的にエンジニアの仕事は問題を解くことです。僕はエンジニアは「problem solving」が仕事だと言い切っていて、やっぱり難しい問題を解くから価値があるわけじゃないですか？本来であれば「難しい問題」を解きたいけど、事業会社にいると「難しくない問題」を解き続けなくてはならないことがあります。メルカリの場合は「かんたんな問題をかんたんに解くのはあなたの仕事ではない」と言えるカルチャーになってきた。それはエンジニアにとってすごく幸せなことだと思っています。翻って、エンジニアにとってインパクトを出しやすい状況をメルカリではつくれはじめているということです。

＠kimuras：これについては話したいことがいっぱいありますね（笑）。インパクトの出し方って、会社のフェーズによって違うじゃないですか？いまのメルカリのフェーズでは小粒のことをやってもインパクトが弱いんですよね。それよりも全体最適が重要なので、そういうマインドチェンジが必要になってきましたね。

＠mtsuka：昔はプロダクトマーケトフィットに貢献できたとか、売上に直接貢献できたとかいう話になるんですけど、おっしゃるとおり全体最適になんらかの形で貢献できたというのが、すなわちインパクトを出すことに直結してくると思うんですね。メンバーが増えてきて、事業が複雑になってきたから、全体最適することでいろんな意味でコストパフォーマンスがよくなる、そういう話になっていく。

一方で、地道に粛々とやっていく世界観でもあると思うんですよね。そういったことが評価される環境もつくられはじめているのはいいこと。

＠kimuras：やっぱり表層“だけ”をつくった人たちが評価される世界観はあってはよくないと思っています。その表層のものを、いかにスムーズに安全に提供していくかというプラットフォームの観点があることが重要です。僕はエンジニアは全員プラットフォームの観点を持つべきだと思っていますし、RFSを通してプラットフォームを全員でつくっている感覚が醸成されたこと、それがいちばんの価値だと思っています。