2021年1月、ソウゾウの設立が発表されました。同時に、前メルカリCTOだった名村卓はソウゾウへジョイン。次の「メルカリCTO」としてバトンを託されたのは、若狭建（@kwakasa）でした。

CTO就任以前から、VP of Product Engineeringとしてメルカリ開発組織で重要な役割を担ってきた@kwakasa。さっそく就任インタビューを…と考えたのですが、@kwakasaはVP of Product Engineering時代からメルカンに登場しており、CTOになってからもメルカリ開発組織に対するスタンスは変わっていないように感じました。

そこで今回は「CTOになってみてどうだったのか？」を探るため、“就任100日後インタビュー”を実施。「100日後に取材させてください！」の申し出に、@kwakasaは「では、100日後に！」と快諾してくれました。

さて、メルカリCTOとしての100日を経た@kwakasaが語ったのは…？就任時にメルカリの社内Slackで掲げた「Robust Foundation for Speed」「Accountable Autonomy」それぞれの意味、そして前CTOとは異なる役割──。

100日間で注力したWeb版メルカリリニューアルのローンチ、マイクロサービス化の手応え

ー@kwakasaさんのCTO就任から100日経ちました！振り返ってみて、どうですか？

そうですね…メルカリ開発組織のポテンシャルの高さ、伸び代を感じた100日間でしたね。

若狭建（@kwakasa）

振り返ると、いろいろなことがありました。例えば、Web版メルカリのリニューアルです。実はこのプロジェクト、進めたいけれどなかなか進められていなかったものでした。というのも、今やメルカリは大きなサービスです。そのため、大掛かりな技術改善をしようとなると、関わるメンバーやチームとの調整も発生する。これまでも努力を重ねてきていましたが、正直なところ、難航していたんですよね。

ですが、2021年8月にローンチすることができました。同時に、アクセシビリティ対応も大きな進捗がありました。今後進めたい多言語化などの機能改善や新機能追加のための基盤も構築できました。まだまだ手を入れるべきところはありますが、ひとまず走りきれたことは良かったと思っているんです。

もう1つは、以前からメルカリが進めてきたMicroservices migration（マイクロサービスへの移行）です。メルカリでは、創業当時のモノリシックな開発手法から、複数の小さなサービスを連携させて管理・運営を行う開発手法「マイクロサービス」への移行を進めてきました。新機能開発や改善もあるなかでの進行だったので難しいところもあったのですが、特に基盤強化のためのバックエンド開発にはしっかり注力できました。

とはいえ、メルカリの初期からこれまでのビジネスの根幹を支えてきたデータベースやロジックの移行はまだ残っているので、まだ完了したとは言えません。今どんな問題が残っているのか、何が壁になっているのかを確認するため、Microservice migration retrospectiveという大きめの振り返り会も実施しました。振り返りで挙がった内容を確認しつつ、着実に進めていくつもりです！

CTO就任時、あえて掲げた2つのキーワードの意味

ー印象的だったのは、@kwakasaさんがCTO就任時にメルカリの社内Slackに投稿していたメッセージです。

CTO就任時、@kwakasaがメルカリの社内Slackへ投稿したメッセージ

ーこのなかで挙げていたのが「Robust Foundation for Speed」「Accountable Autonomy」のキーワードです。なぜこの表現を選んだんですか？

「Robust Foundation for Speed」は「仮説検証を高速に回すための堅牢な基盤」という意味があります。本当は「急がば回れ」と言いたかったんですけど、英訳が難しくて「Robust Foundation for Speed」にしました（笑）。

僕としては、メルカリはインフラと言っても過言ではないサービス規模だと思っています。それこそ、電気やガス、水道に近しい存在になれるポテンシャルがある。なので、インフラとして、安定させて、維持管理して、スケーラブルにして、セキュリティーやプライバシーも管理して…と、社会的責任が求められます。

一方で、スタートアップ的な新たなチャレンジにも引き続き挑んでいく必要もある。何より、チャレンジはどんどんやっていきたい。「インフラとしての堅牢さ」「新たなチャレンジに挑む」という、一見矛盾しているような2つの事象を両立させていくことになります。むしろ堅牢な基盤があるからこそ、新たなチャレンジができる。そのスタンスを「Robust Foundation for Speed」と表現しました。

当然ながら、「インフラとしての堅牢さ」「新たなチャレンジに挑む」を両立させるなんてすぐにできることではないんですけれども！サービスの安定稼働やセキュリティーやプライバシーは維持しつつ、お客さまの数に比例するように、使うストレージも使うネットワークの帯域幅も増えていく。もちろん無限にコストをかけるわけにはいかないので、コスト削減のためのメンテナンスもしつつ、そのうえでチャレンジする。ここは、メルカリらしさでもあると思っています。

ーもう1つの「Accountable autonomy」は？

「説明責任ある自律性」みたいに直訳されますが、ようするに言いたかったのは「自分ごと化」ですね。「自分たちでやると決めたことは、責任を持ってやっていく」みたいなニュアンスです。

僕は「エンジニア＝問題解決する人」だと思っています。ここでの「問題」とは「ビルドが遅い」「不具合がある」といった技術的な問題だけではなく、「お客さまが増えない」「マネタイズがうまくいっていない」といったビジネス的な問題も含んでいます。

エンジニアは自ら問題を見つけ、解決していくことが求められます。ベースは技術的なアプローチになるのかもしれませんが、それ以外の部分にも興味を持って解決へと導いていく。そのためには、プロダクトはもちろん、お客さまやマーケット全体に関心がなくてはいけません。「言われたことだけをやるのではなく、自分たちで問題を見つけて、責任を持って解決してほしい」という想いを込めて、メッセージにしたためました。自由には、責任が伴いますからね。

CTOになって気づいた「今まで見えていなかった部分」「可能性」

ーCTOに就任してから若狭さん自身に変化は？

僕、エンジニアリングに対してはけっこう保守的な姿勢なんですよね（笑）。前職では、OSやスマートフォン、位置情報サービスなどのインフラと呼ばれるような機能の開発に関わってきました。そのため「エンジニアリングとは、多くのお客さまがいるサービスを維持管理、改善、発展させること」という発想になりがちなところがあったんです。先ほどもキーワードとして出ていた「堅牢性」は、個人的にこだわりたいところではあります。

でも、メルカリへ入社してからは、市場の変化スピードや、そのなかでチャレンジすることの大切さを改めて感じました。可能性を探すには、新しい挑戦をするしかない。そのためには、良い意味で打ち上げ花火的にトライアルアンドエラーを繰り返していくことも欠かせません。それが成功すればインフラ側も刺激を受けて、より成長していく。どちらかを優先するのではなく、両立させていく。その難しさを痛感した100日間でもありました。

ー@kwakasaさんは、CTO以前はVP of Product Engineeringでした。以前と比べて「変わった」と感じるところはありますか？

CTOになってから大きく変化したなぁと感じるのは、コミュニケーションをする人の幅がぐんと広がったことでしょうか。メルカリの開発組織内はもちろん、メルペイやソウゾウなど各社の開発組織に所属するマネージャーたちと会話するようになりましたし、開発組織外のメンバーとのコミュニケーションも増えました。もちろん以前からも会話していましたが“より増えた”というイメージですね。おかげで、見えているようで見えていなかった部分に気づけましたし、可能性も感じました。

ー「見えていなかった部分」と「可能性」？

エンジニアやマネージャーたちと話してみて気づいたのは、みんなわりと「これからどこへ進めばいいんですかね？」となっていたことです。大きな方向性は示しているけれど、目線を合わせきれていないところがあったんですよね。だから、各々が違う方向を見ている状態にもなっていた。この目線さえ合えば、より強固な開発組織にできるはずです。

特にいい気づきになったのが、マネージャーの多くが多様性を重視していること。何より、そんなマネージャーを含めて、エンジニアの多くがメルカリというサービスを本気で良くしたいと思っているし、そのための手段を真剣に考えている。ここに可能性を感じずにはいられないですね。

「前CTOの@suguruさんとは違う役割」が求められている

…と、ここまで話しておいてなんですが、僕はまさか自分自身がCTOをやるとはあまり考えていなかったんですよね（笑）。

ーVP of Product Engineeringもやっておきながら！

いやいやいや、メルカリではあくまでも「役職＝役割」ですからね。CTOも、メルカリのなかで求められた役割の1つに過ぎません。前CTOである@suguru（現ソウゾウCTO、名村卓）さんがソウゾウにフォーカスすることになり、メルカリCTOが空席になった時期もあったんです。そのとき、個人的には「CTOはいなくてもいいんじゃないかな」と思っていたくらいです。もちろん、CTOがいなくても成立する組織だという認識があったうえでですが。

ただ、メンバーといろいろ話してみると「CTOという存在はあったほうがいい。なぜなら、コミュニケーションが楽になるから」という意見が多かったんですよね。メルカリの開発組織には、300名ほどのエンジニアがいます。その一人ひとりにメッセージを発する存在として、CTOはいたほうが良い。恐縮なことに指名されたときは「やっぱりGo Boldな会社なんだな」と思いましたね。

ーちなみに，前任である@suguruさんからは何かメッセージ的なものを受け取ったりは？

「こういうふうにやってほしい」「継承してほしい」みたいなことは一度も言われていないですね。ただ、「@kwakasaさんが必要だと思ったことをやってくれればいいです」と言われました。

メルカリは事業・組織ともに成長スピードが早く、どんどんフェーズが変わっていく会社なので、エンジニアリング部門に関しても絶対的な正解はありません。フェーズが変わればやるべきことも変わるし、CTOの役割もどんどん変わっていくわけです。そういう意味でも、「@suguruさんとは違うCTOとしての役割」が求められているんだと感じています。

ー@kwakasaさんは、メルカリCTOとしてどんな役割を求められていると感じていますか？

「Robust Foundation for Speed」「Accountable Autonomy」のマインドを開発組織に根付かせることですね。この2つが根付けば、より生産性の高い開発組織になる。そうなったら、いったん僕にとってのCTOとしての使命は果たせたことになります（笑）。その先は、また別の役割を担った新たなCTOが就任すれば、開発組織はずっとアップデートし続けられるんでしょうね。