エンジニアリング組織の設計と実践──「メルペイ」の事例から学ぶ、組織とアーキテクトの関係性とは？

2017年末、メルカリからメルペイが設立された。メルカリ関連のお金まわりはもちろんのこと、独立した金融会社として、決済など各種金融サービスを展開していくためだ。

そして会社設立から約1年半で、サービスをローンチ。その裏側にはどんなストーリーがあったのか。技術と経営をつなぐアドバイザーとして数多くの企業の経営支援を担う、レクターの広木大地氏をモデレーターに迎え、メルペイCTOの曾川景介氏、同じく同社VPoEの木村秀夫氏との対談から考える。

【組織設計論】プロジェクトベースからマトリックス型組織に──その結果は？

広木：メルペイはメルカリのアプリに組み込まれる形で利用でき、お客さんから見ると単一のサービスには見えます。しかし実際には会社も違えば組織も異なります。互いの組織間で行う目標設定の調整は苦労があったのではありませんか。

▲株式会社レクター取締役広木大地氏

筑波大学大学院を卒業後、2008年に株式会社ミクシィに入社。同社のアーキテクトとして、技術戦略から組織構築などに携わる。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、多数の会社の経営支援を行っている。著書『エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング』。

木村：おっしゃる通り、エンジニアリング組織はメルカリとメルペイでは異なっていて、両社にCTO/VPoEがいます。目標設定においても各社それぞれが設定。ただどちらも達成目標（Objectives）と成果（Key Results）をリンクさせたOKRの手法を取り入れている点では共通しています。

いきなり暗い話題になりますが、実は開発当初、メルペイ側の開発リソースが足りなくなりました。具体的にはエンジニア不足です。そこでグループのエグゼクティブに相談すると、メルカリが掲げている目標を下げてまでもメルペイのサービスに注力しようと。結果として、メルペイのプロジェクトにメルカリのメンバーをアサインし、ともにプロジェクトに取り組むことになりました。

▲株式会社メルペイ執行役員 VP of Engineering 木村秀夫氏

1996年 interQ 株式会社（現GMOインターネット株式会社）入社。独立起業、株式会社KDDIウェブコミュニケーションズを経て、2009年 株式会社ディー・エヌ・エー入社。同社Japanリージョンゲーム事業本部プラットフォーム本部長執行役員、システム本部長執行役員などを歴任。2018年5月より現職。

広木：つまりメルペイの開発は、当初の計画通りに進まなかったと。それは、なぜでしょう。

木村：開発当初はプロジェクトごとにマネージャーを置き、その下にエンジニアを配置する体制で進めていきました。しかし思ったような成果が出ませんでした。主な課題は以下です。

◆エンジニア

専門性を正しく評価、正しいアサイン、正しいキャリア形成されていない不安がある。
工数の見積り、リリース決定にエンジニアの観点が足りず、スケジュールの不確実性が高まっている。
セキュリティ対策や技術負債へのアサインが疎かになる可能性。

◆PM（ProductManager）

ピープルマネジメントに忙殺されていてプロダクトのことを考えられない。
プロジェクト間のアサイン調整においてエンジニアの取り合いが起こる可能性。

そこで8カ月ほど経ったところで、組織を刷新。プロジェクトごとに動く縦軸に、横軸連携できる職能型別人材を配置するフローに変更しました。

広木：Googleなどが採用しているマトリックス型組織ですね。

木村：ええ。バックエンド、フロントエンドなど各領域で高い専門性を持つメンバーをエンジニアリングマネージャー（EM）として配置。さらにPMと交差する部分に、両者の橋渡し的な存在のテックリード（TL）を配置しました。

そして各メンバーの役割分担を明確化。PMはプロダクトの部分、「WHY（なぜ）、WHAT（なにを）、WHEN（いつまでに）」にコミットし、EMはマネジメント、メンバーアサインの部分「WHO（だれが）、WHERE（どこで）、HOW（どうやって）」やるのか。そしてTLは「WHAT（なにを）、HOW（どうやって)、WHEN（いつまでに）」といった現場業務に注力する体制に変えました。

広木：そのような組織改善をしたことで、開発はうまくまわるようになったのですか。

木村：いえ…。それが組織設計を変えても、再びいろいろな問題が生じました。大きくは2つです。1つ目は開発要件（機能）が多すぎるという問題でした。私は2018年の5月にジョインしたのですが、エンジニアの誰に聞いても「短期間でのローンチは無理」と口を揃えていました。

もうひとつはフィンテックビジネスならでは、ステークホルダーの多さから生じる不確実性要素の積み上がりです。銀行、店舗、関係省庁、外部開発会社など。各ステークホルダーとやり取りしていると、どうしてもリスケや要件変更など、スピーディーに開発を進めていくことが難しいとの問題にぶち当たりました。

広木：つまり組織設計を変えたけれども、それでもうまくいかなかったと。それに対して、どのような対策をとられたのですか。

木村：要件については一度フリーズし、スペックをそれ以上にしないと決断しました。また後者においては、一度にまとめてリリースしようと考えていた計画を断念。ステークホルダーごと、それぞれのサービスごとにリリースしていくフローと変えました。

またそれに伴い開発スタイルも一旦ウォーターフォール型とし、まずは一つひとつのサービスを急いでリリースするのではなく、しっかりとした形でローンチしようとの結論でまとまりました。

広木：OKR目標を下げてまでも協力してくれたメルカリ側は、すんなり納得してくれたのですか？会社同士の交渉では、多くのトラブルがあったんじゃないでしょうか。

木村：自社の経営陣をよいしょするわけではありませんが、特に技術面の問題については、きちんと事情を説明すれば、理解してもらえました。もちろん散々各所で頭を下げました（苦笑）。

広木：なるほど。経営陣は理解してくれたんですね。でも、現場のエンジニアやセールスからは、それこそ厳しい声もあったのではありませんか。

木村：正直、私も辛かったです。でもセールスに事情を説明し頭を下げると「仕方がない、待ちますよ。ただし、いいものを作ってほしい」と言われ、その言葉を聞いたときは、さすがにぐっとこみ上げてくるものがありました。

広木：それに加えて、組織の拡大スピードもめちゃくちゃ早かったように思います。そのことで、しんどかったことはありますか。

木村：弊社では1マネージャーに対しエンジニアが8名ほどまでの2ピッツァルールを取り入れていますので、とにかくマネージャー層、特にEMが足りなくて苦労しました。実際、初期には1マネージャーに20ぐらいのエンジニアがいるプロジェクトもありました。

トップダウンかボトムアップか

広木：先ほどご紹介いただいたような課題や問題が出たとき、メルペイではマネージャーなどのトップからの指示やアイデアで解決に向かったのか。あるいは現場エンジニアからの声で変わっていったのか。トップダウン、ボトムアップについてはどうでしたか。

曾川：基本はマネージャー同士が話し合い決めていきますが、そんなに簡単に結論にたどり着くわけではありません。VP、EM、TLだけで解決できない問題も多くありますから。ですから実際にはプロジェクトに携わるメンバーの一人ひとりが、目の前の課題に対して真剣に向き合った結果、良き施策やアイデアが出てきたと考えています。

▲株式会社メルペイ取締役CTO 曾川景介氏

京都大学大学院情報学研究科システム科学専攻修士課程を修了。2011年にIPA未踏ユース事業に採択。大学院修了後にシリコンバレーの FluxFlex社にてWebPayを立ち上げる。ウェブペイ株式会社の最高技術責任者（CTO）としてクレジットカード決済のサービス基盤の開発に従事、LINEグループに参画しLINE Pay事業を経験。2017年6月メルカリグループに参画。

木村：フェーズによっても、ボトムアップ、トップダウンは異なると思います。たとえば私が18年5月に入社したときはボトムアップでした。しかしお互いが依存しているようにも見え、プロジェクトを仕切るリーダー、指揮者が欠けていると。そこである時からトップダウンに変えました。そして現在はグロースフェーズですので、再びボトムアップで開発は進んでいます。

広木：ぶっちゃけエンジニアの価値観としては、ボトムアップ信仰が傾向として多いと思います。トップダウンな意思決定や変化を選択するときに、現場のエンジニアとのハレーションはどのように対策されたのですか。

木村：全社会議のときに、先にお話したようにこれまで何度も失敗があったこと。このままでは本当にリリースが難しいことを繰り返し、強調して伝えました。若干のハレーションはありましたが、多くのエンジニアは納得してくれたと思っています。

広木：あのフェーズでは、仕方のない選択だったと捉えてもらえたということですか？

木村：そうであってほしいと思っています（苦笑）。

【アーキテクチャ設計論】40以上のマイクロサービスで構成

広木：メルペイの技術的なアーキテクチャは、マイクロサービスを採用していると聞いています。チーム構成やエンジニア人数と関連の深いアーキテクチャだと思うのですが、現在はどのようなチーム体制および、技術スタックを採用しているんですか。

木村：新たな金融サービスを実装したいとの強い想いがありましたから、開発当初からマイクロサービスでいこうと決めていました。メンバーはソフトウェアエンジニアが最も多く35％、そのほかはスライドの通りです。

またエンジニアの属性においては、バックエンドエンジニアが最も多く39.5％、次いで品質保証を担うQAエンジニアが13.2％、マネージャー9.9％といった具合です。

言語などの技術スタックは機密事項のため全ては公開できませんが、バックエンドであれば、Go、PHP、Python、gRPC。フロントエンドでは、HTML、CSS、JavaScript、TypeScript、Vue.js/Nuxt。マシーンラーニングでは、Python 3、Scikit-learn、Tensorﬂow、Airﬂow、BigQuery。インフラでは、Kubernetes Engine、Cloud Spannerなど。ツールにおいては、GitHub、Slackといったあたりの技術を使っています。

広木：サービスの初期ローンチからマイクロサービスで作っていかれたと。でも、どこに機能改修が発生するか見えないフェーズにマイクロサービスを採用すると、サービスをドメイン境界ごとに切っていく設計をうまく想像しながらやっていく必要があります。、これには難しい判断が多々あったり、途中で間違いに気がつくこともあるのではないかと思うのですが、この点、どのようにアプローチしていったのでしょうか。また、大きな失敗はなかったのでしょうか。

曾川：経緯からお伝えすると、そもそもメルカリは大きなモノリシックのPHPアプリケーションでした。そのモノリシックの中で、決済サービスとしてのメルペイはマイクロサービスアーキテクチャで開発を進めていました。

次第にサービスが複雑化していき、APIなどが増えていきました。つまり作りたい、提供したいサービスにあわせて、マイクロサービスが増えていったというのが、正直なところです。

そして成否に関しては、先ほど木村が説明した通り。開発から最初のサービスローンチまで1年以上かかっていますから、必ずしも成功したとは言えないでしょう。正直、マイクロサービスは難しいと考えています。

広木：難しいというのは、どのような点なのでしょうか。単一のサービス改善が難しいということなのか、それとも１つの機能開発に複数のサービスをいじらないといけないケースが多かったりするのでしょうか。

曾川：複数のサービスが揃わないとリリースできない場合が多いですね。そのことが分かってからは、複数のサービスをグルーピングし、チームで見る体制としました。そしてチームの中で完結すれば、ローンチできると。

木村：どんどんグルーピングしていった方が、すっきりしますし、開発しやすいと現在もこの手法で行っています。

フィンテック領域にマイクロサービスは適しているのか

広木：チームに権限委譲され、柔軟に改善できるのがマイクロサービスのハッピーなところだと思います。一方でフィンテック領域は、ステークホルダーも多く柔軟に変更できる種類のサービスではありませんよね。この点、どのように最適化していったのでしょうか。

曾川：良い質問だと思います。私はこれまでLINE Payなど、スマホ決済事業に8年ほど携わってきました。

メルペイは、メルカリのお金まわりから派生したサービスという特徴があります。これはメルカリ事業を通して感じたことでもありますが、お客様のお金を預かることが、いかに大きな責任を伴うのか。そしてその責任が担保されなければ、本業を続けていくことも難しくなるだろうと。

そしてこのような想いからメルペイ事業を展開する際には、より強固な決済サービスを構築する必要があるのだと。それはもちろん、自分たちのビジネスを守ることでもあります。ただ結果として、お客様のためになると。そしてそのような強固なサービスを構築するために苦労が多かったとしても、マイクロサービスがベストだと考えたのです。

ですからこれからは、私たちが独自に構築したシステムやノウハウを省庁や切磋琢磨する金融事業者に伝えることで、決済サービスのリスクをより減らすることにも貢献できればとも考えています。

技術スタックは誰が選ぶのか

広木：マイクロサービスというと一般的に「技術的異質性」がポイントとしてあげられます。これは必要に応じて、個々のサービスごとのチームが技術スタックを選定できることを意味しています。現状のメルペイさんでは、技術スタックの選定は、どなたがされているんでしょうか。。先ほど組織設計論のところでも出ましたが、技術スタック決定のトップダウン、ボトムアップについて、複数の技術スタックを使うメリットデメリットについてもあわせて聞かせてください。

木村：フェーズによって異なるというのがひとつ。もうひとつはぶっちゃけて言えば、ひとつの技術に特化した方がエンジニアは集まりやすいので、採用面から考えると楽だと思っています。一方でエンジニアにとっては新しい技術スタックを取り入れないと、チャレンジングな環境でなくなりますからね。今は緩やかに新しい技術スタックを取り入れているフェーズです。

曾川：トップダウンで決めているというよりは、各チームが合理的な判断で選んでいる状況です。ただ真新しい技術を使ったチームは、やはり困難な状況になるケースが多い印象です。一方で、標準的な技術スタックを使ったチームは、それほど苦労なく開発が進んでいる。

ただ失敗を経験したチームからも、新たなアイデアが出て、その技術で新しい進化を遂げているようなケースもありますから、やはり現場メンバーが主体的に技術スタックを選定し、そこから何かを気づき、どう改善していったのか。自ら責任感を持ち開発していることが、結果としてサービスをローンチしたときのクオリティに繋がっているのだと思います。

木村：失敗ではなく、学ぶことができたと捉えてもらえればと考えています。また自発的に気づいてもらえれば、私たちがトップダウンでその技術スタックを採用しない説明をする必要もなくなりますからね。