メルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ

IT技術は進歩のスピードが速い領域です。だからこそ過去から現在、そして将来に向けた変化を理解することは、ITエンジニアとしてキャリアを構築していく上で必要な考察となるでしょう。ときには、こうあるべきという将来像を描くこともあるかもしれません。

株式会社メルカリでプラットフォームチームのテックリードを務める中島大一（@deeeet）さんは現在、メルカリが2年ほど前から進めているマイクロサービスへのアーキテクチャ移行において、そのインフラ自体や、そこで開発するエンジニアに向けたツールセットの提供などを行っています。

エンジニアとしてキャリア7年になる中島さんですが、2年目の2015年には同じような当時の若手インフラエンジニア（@ryot_a_raiさん、@rrreeeyyyさん、@yuuk1tさん、@hfmさん、@catatsuyさん）との集まりで、「ある若手インフラエンジニアの現状確認」と題した発表をしています。

ここでは大学時代からその時点までのキャリアを振り返り、現状を分析しつつ、インフラの技術的な展望などを語っていました。それから5年が経過し、展望の多くは現実のものとなり、中島さん自身が考察していた先進的なインフラプラットフォームをリードする立場となっています。

5年後の今あらためて現状を確認したなら、どのようなアップデートがあるのか？あの頃の未来に立っているのか？中島さんが5年のうちに選択したこと、それによって変わったこと、変わらないことをお聞きしました。

GoもKubernetesも誰より使える自信があった
扱う基盤が大きくなると一人でできることには限界がある
Howからではなく、まずWhyを中心に考えること
長期的な視点を持ち、メンバーと共有する
海外のコミュニティから学んだ開発のフィロソフィー
次の5年はKubernetesネイティブ世代が活躍できるよう

GoもKubernetesも誰より使える自信があった

── 中島さんがメルカリに入社したのは2017年でしたよね。

中島　はい。僕は新卒で楽天に入社し、Cloud Foundryを用いた社内PaaS基盤の開発に携わりました。ただ、楽天って幅広いサービスやプロダクトを抱えていただけに、自分が携わった基盤の機能改善がサービスやビジネスにどれくらい影響を及ぼしたか、手応えが掴みにくいところがあったのも事実です。よりサービスに近いところでインフラをやりたいなと考えて、メルカリにSREとして入社しました。

── けれど、実際のところSREではなく、マイクロサービス化のプロジェクトに携わることになったわけですね。

中島　3カ月くらいはSREとして働いていたんですが、メルカリUSがマイクロサービス化するという話を耳にして、自分から手を挙げました。

　メルカリはモノリシックなPHPサイトだったんですけど、Goというモダンな言語やKubernetesといった新しいインフラを使ってバックエンドを刷新するプロジェクトが新たに始まったと聞いて、面白そうだし、GoやKubernetesについては他の誰より使える自信もありましたから。

　それに、社内の信頼を得て、この先自分がやりたいことをできるような実績を出したいという気持ちもあって飛びつきました。その経験があったことで、日本でもマイクロサービス化を進めることになったときに「お前、やってこい」となりました。

── 転職時点ではPaaS基盤からモノリシックなPHPサイトなので、よりサービスに近くても技術的には保守的になったはずが、むしろより先進的な環境を選択することになったんですね。

中島　メルカリという会社自体が、これまでの日本にはないスピードで成長しているため、社内の技術スタックや組織のあり方もものすごいスピードで変わっています。3カ月も経てば全く違うことが始まる感じで、そこはかなり特殊な経験かなと思います。

── エンジニア組織に特徴があるのでしょうか？

中島　なかなか言葉にするのは難しいんですが、「テックカンパニー」を志向する姿勢というか、テクノロジーによってプロダクトをよくできることをみんなが分かっているところですかね。最近では、エンジニア一人一人が意思決定してプロダクトを開発できるようにする「Micro Decision」を強く打ち出しています。

── 日本のメルカリをマイクロサービス化するとなると、かなり規模が大きく難しいように思いますが、どこから手を付けたのでしょうか？

中島　最初にマイクロサービスとしてリリースしたのは、機械学習（ML）技術を活用して、出品物の写真を元にタイトルなどの情報を自動的に補完する「AI出品」です。これはこれで難しい挑戦だったんですが、新しいサービスによるサブシステムとして実装したため、マイクロサービスとしてはそれほど困難ではありませんでした。

── 完全な新機能だったので最初からマイクロサービスとして実装できたということですね。既存の他の部分はどのように進めているんですか？

中島　USのマイクロサービス化で実績のあった「ストラングラーパターン」による段階的な移行を日本でも採用しています。クライアントとアプリケーションの間にAPIゲートウェイというレイヤを挟む形にして、モノリスの機能を少しずつ切り出して、段階的にマイクロサービスに移行します。このAPIゲートウェイが日本では必要だったので、これも一から書きました。

── この取材時点（2020年4月）ではまだ移行は完了されてなかったですよね。

中島　まだ完了はしていませんが、かなり見えてはきてると思います。ちなみに後発の「メルペイ」も同じ基盤上で、こちらは最初からマイクロサービスとして稼働しています。

扱う基盤が大きくなると一人でできることには限界がある

── マイクロサービス化のプロジェクトで、中島さんはGoやKubernetesに強いインフライエンジニアとしての働きをされているのでしょうか？

中島　始めて1年くらいは実装や仕組み作りなど自ら手を動かすことが多かったんですが、後にテックリードになってからは、個人としての働きよりもチームとしてどう動くかであったり、チームの効率を上げることを考えるようになりました。

　初期のプラットフォームはチームとしてのプロジェクト管理などもなく、基本は個人で動いており、チームで動いている感じはありませんでした。例えば自分はGoが得意だったこともあり、APIゲートウェイの実装やGoの開発環境の整備などに注力していました。初期はスピード感も必要だったのでそれでも回っていました。

　しかしチームが拡大し、プラットフォームが拡大していくにつれて、個人プレーで動くには限界がきました。個々で動いているのでプロジェクトの並列数は高くなってましたが、全体としてのアウトプットはそこまで高くなく、変更のレビューのコストもかなり高くなっていました。

── チームが拡大することで起きたそれらの課題をどう解決していったのですか？

中島　課題を解決するために、自分が手を動かすことをより少なくして、プロジェクトの進め方やプロジェクトの管理の仕方を整えるなど、チームとしてのアウトプットの改善にフォーカスするようになりました。APIゲートウェイも、重要なコンポーネントにもかかわらず自分しか触れず、SPOF（単一障害点）になりつつあったので、このときに適切なチームに移譲するよう進めました。

　何かブロッカーがあればそこに突っ込んでいって、それをなくすために自分で手を動かしたりすることはありますが、基本は全体を幅広く見渡しつつ、時間軸も目の前のことよりも、より先のことを考えるように働き方を変えてきました。

── エンジニアの方には「いいコードを書けて、すごい実装ができてナンボ」という考え方もありますが、そうじゃなかったわけですね。

中島　「個人として尖っていること」ももちろん重要ですが、扱う基盤が大きくなってくると、一人でできることには限界があるということを実感するようになりました。メルカリは大きなプロダクトです。そのインフラをちゃんと動かすには、いかにチームとして、組織として動けるかが大事だということを、マイクロサービス化を進める中で学びました。

── それは楽天からの転職や、マイクロサービス化に取り組むことになったことより大きな変化ですね。

中島　メルカリに入って一番良かったのは、テックリードとしてチームと技術をリードする経験ができたことだと思います。

Howからではなく、まずWhyを中心に考えること

── 組織やチームについて中島さんがいま取り組んでいることは何でしょう？

中島　最近は、プラットフォームの組織をどう拡張していくかを考えてデザインをしてました。この4月からは、実際にその新たなデザインに基づくチームで動きはじめています。マイクロサービス化を始めた頃は数人程度だった1チームが、現在はプラットフォームグループ全体で16人、3チーム体制になっています。新しいチームにそれぞれテックリードを立てて任せつつ、プラットフォーム全体として同じ方向を見て動けるような体制作りを進めています。

── 自身の経験を踏まえて、テックリードに必要なことは何でしょうか？

中島　2つあります。1つは、HowよりまずWhyを中心に考えること。「何が問題か？」を見極めることですね。もう1つは、2年後、3年後といった中長期的な視点を持つことです。

── 1つずつ詳しく聞かせてください。まず、HowでなくWhyということについてお願いします。

中島　自分が若かった頃はいつも「どういう技術を使うか？」「どんなイケてる言語を使うか？」といった具合に、とにかくHowのことばかり考えていました。けれど本当に大事なのは、まずWhyを考えることです。「なぜこれをやるのか？」「解くべき問題は何か？」を見極めないと、最適なHowを導くことはできません。

　例えば、3年前になぜマイクロサービス化の話に飛びついたかというと、やはりGoやKubernetesといった技術が面白かったからです。だから当時は、マイクロサービスの基盤をどういう技術を使って作るかとか、ゲートウェイはこう書いたらいいんだとか、そういったことばかりを考えていました。けれど、本当に考えなくてはいけなかったのは、そもそもなぜマイクロサービス化するかということでした。

── なぜなのでしょう？

中島　マイクロサービスに取り組む大きな理由は、「組織をより拡大していくこと」にあります。サービスを分割し、チームを分割することによって、組織が大きくなっていっても各チームが独立してプロダクトの開発・デリバリをできるようにするところにマイクロサービスの本質的なWhyがあります。

　けれど、僕は最初それを見失って、Howにばかり注力していました。だから、例えば、僕が書いたAPIゲートウェイは、リクエストのルーティングを設定するにはプルリクエストを送らなければならない仕様になっています。つまり、APIゲートウェイがボトルネックになっていて、各チームが独立して動けない形になってしまっているんです。

　もしあの段階で、各チームが独立して動くこと、組織を作ることが最終的なゴールでありWhyであると分かっていたら、ゲートウェイの設定の仕方をもう少し工夫して、よりよいHowを導き出せたと思います。そこは僕の失敗の1つです。

　マイクロサービスは１つのHowでしかないし、ゲートウェイも１つのHowだし、ゲートウェイの実装方法のHowもたくさん考えられる、それらのHowが最適であるかを決められるのは、Whyでしかありません。なので、まずWhyをしっかりと考えないといけない。

── そうやって「何が問題か？」を見極めるということなんですね。

中島　プロジェクトを進めていると、チームのメンバーから多くの問題が寄せられてきます。もちろんそれは実際に問題であることもあるし、単にその人の好みだったり意見だったりもします。また解くべき問題を見極めたとしても、それ自体は無限にあります。よく言われるように、「何をするか？」より「何をしないか？」という決断の方が重要になってきます。

　プロダクトや基盤を使う開発者の生産性にとって今一番求められていることを理解し、優先度を決め、今やるべきことに集中できるようにすることは、テックリードをやる上で大事になる技術だと思います。

長期的な視点を持ち、メンバーと共有する

── テックリードに必要なもう1つは、中長期的な視野ということですが。

中島　チームをリードしてプロダクトの方向を決めるテックリードが、目の前のことだけでなく、長期的な視点を持つことは非常に重要です。

　チームのメンバーとしても「3カ月後にこういうことをやります」と分かって書くコードと、知らないで書くのとでは全然違います。「次にこうするから、今はこういう実装をしておけばOK」といった意思決定ができるからです。特にインフラのように変更が容易ではない分野では、一つ一つの決断が長期的に響いてくるので、意思決定にその根拠となる要素が多いほど、良い決断ができると思います。僕自身、チームが「今後数年でどのようなことに取り組むのか？」をまとめたロードマップを作成してメンバーと共有したところ、チームの開発がかなり変わったという経験がありました。

　例えば、現在メルカリのKubernetesクラスタはマルチテナント構成で1クラスタしかなく、その上で全てのマイクロサービスが動いています。これはアベイラビリティ（可用性）の面で課題となるので、将来的にマルチクラスタ構成にすることを考え、テックリードがチームと共有しておけば、将来的にマルチクラスタ構成になることが分かった上でコードを書いたり、仕組みを整えることができます。

　今は自分のチームをリードしつつ、新しいチームではテックリードのメンター的な立場なんですが、長期的な視野でロードマップを作ること、その時間を作ることをまずはやってもらっています。

── チームメンバーがロードマップに沿ってコードの書き方を考えるというのは、先ほど話に出たマイクロディシジョン（Micro Decision）に通じるものがありますね。

中島　そういうことでは、メンバーへの権限移譲も大切です。以前の僕は「こういう技術を使って、こういうふうに問題を解く」ということまでメンバーに伝えてしまっていました。けれど、それではチームメンバーが自分と同じオーナーシップを持つことができなくなります。各メンバーが自分で考えてオーナーシップを持つことは、そのまま長期的なビジョンを持つことにつながり、また、次のテックリードになる、もしくは自発的により良い基盤を作るために各自が動くことにつながります。

　そこで、メンバーには「何をやるのか」と「なぜこれをやらないといけないのか？」というWhyを中心に伝えて、「どうやるか？」というHowの部分はそれぞれで考えてもらうようにしました。また細かなコーディングやツールの使い方などはメンバー内でレビューしあってもらうことで自分はそこまで立ち入らず、大きな方向性や全体への影響を中心に見るようにしました。もう一段高い視座から物事を見る必要があるというのは、自分自身、テックリードをしながら学んだことです。

　それから、これは当たり前ですが、継続したインプットもテックリードとしては非常に大切です。自分の専門分野について体系的な知識を学び続けることはもちろんのこと、今世界の企業がどのような問題をどのように解いているのかについても、ブログ記事やカンファレンスの発表、論文に至るまで常にアンテナを張っておくことも非常に大切です。

海外のコミュニティから学んだ開発のフィロソフィー

── エンジニアとしての考え方の変化において社外からの影響、オープンソース活動であったりコミュニティにおける情報交換などから学んだこともあるかと思いますが。

中島　それで言うと、どちらかといえば海外のコミュニティをずっと追いかけていて、GoやKubernetesにおける開発の手法や、リーダーの動向にはけっこう影響を受けています。

　Goは長いこと使っていますが、Goのような巨大なプロジェクトの中でロブ・パイク（Robert C. Pike）やラス・コックス（Russ Cox）といった錚々（そうそう）たる開発者がどのように振る舞い、どんなフィードバックをしているかなどはずっと見てきました。

── いわゆる「本家」のコミュニティということですね。どういった影響を受けたのでしょう？

中島　例えば、世界中のユーザーを巻き込み、クリアに説明し、変更を加えていくやり方です。たった1行の変更なのに、「なぜこの変更をするのか？」についてPRにものすごい量のディスクリプションを書いていたりします。

　Kubernetesもそうですね。大きな変更を加えるときには、KEP（Kubernetes Enhancement Proposal）というデザインプロポーザルを書く文化があり、それでコミュニティで合意をとって動いている。そういう文化や考え方からもかなり学んでいます。これは、Whyを重視する考え方にも直結している気がします。

── 日本語圏ではなく海外コミュニティの動向を追っているのは、何か理由があってでしょうか？

中島　昔から、グローバルに出て戦えるサービスに関わりたいという気持ちが強くあったんです。楽天やメルカリを選んだのも「グローバルで戦える企業」が理由の1つでしたし、実際にどちらもチームにさまざまな国のエンジニアがいて英語でのコミュニケーションが必要です。

　グローバルで戦うには、グローバルで使われている技術を使う必要があります。そういう技術の潮流は、基本的に英語圏からきますよね。だから、この5年ほど、技術に関する情報については、全て英語でインプットすることを心がけてきたんです。それが大きいかもしれませんね。ドキュメントも英語が中心ですし、本やPodcastなど、基本的に英語のみです。最近は、日本語で学んだコンピュータサイエンスの基礎を再び英語で学び直して、語彙を付け直すこともしています。

── 中島さんが若手エンジニアの頃は、コンテナやInfrastructure as Codeといったインフラに対する新しいコンセプトが、まさに英語圏から流れ込んできた時期でしたね。気になるプロダクトなどもあったのではないでしょうか。

中島　やはりHashiCorpと、CEOであるミッチェル・ハシモト（Mitchell Hashimoto / @mitchellh）ですね。僕らが若手だった頃に、Vagrant（2010年リリース）に始まり、Terraformなど、さまざまなインフラ自動化ツールをオープンソースでリリースしてきました。

　彼らからインフラそのものの考え方をかなり学びましたし、後で同世代だと知ってさらに衝撃を受けました。僕ら世代のヒーローだと思います。

次の5年はKubernetesネイティブ世代が活躍できるよう

── 今はテックリードの立場にいる中島さんですが、5年前のプレゼンテーションのように「これからインフラ領域でどのような変化があるか？」を予測することはできますか？

中島　うーん、前のようにはできませんね。やるとしても、あくまでメルカリのサービスでこういうことが求められているから、こういう技術を使っていくというWhyの視点から切り取ることになるでしょう。5年前の僕のプレゼンではそういった視点が全く欠けていますが、今はそれが大事だと思っています。

── それでかまいませんから、あえて今の視点で上げるとするならどうでしょう？

中島　前ほど尖った内容ではなくなり、面白くないかもしれませんが、今後5年で当たり前になってほしいことを挙げるとすれば、Netflixなどが導入しているカオスエンジニアリング（chaos engineering）があります。

　マイクロサービス化を進めて分散システム化が進むと、システムはより複雑になり、全てをテストだけでカバーすることは難しくなります。カオスエンジニアリングの手法で、実験として障害を自発的に起こすことで、未知の問題を探し出すことができます。それによって、サービスの信頼性を高めていくといったことやっていきたいですね。

── あくまで「サービスの信頼性を高める」というWhyの視点があってこそなんですね。

中島　それからKubernetesについては、この先もっと「見えない」存在になっていくと思います。今でいうLinuxのように、ベースとして動いているかもしれないけれど、開発者からレイヤとしては見えなくなっていくんじゃないかな。なので、Kubernetesの細かな機能だけではなく、Kubernetesによって「これまでのオペレーションがどう変わったのか？」「分散システムの作り方がどう変わったのか？」といったことをちゃんと理解しておくことが、次に進むためには大切だと思っています。

── Kubernetesがあって当たり前な世界ですね。次はそんなKubernetesネイティブ世代が、現状を確認したり技術的展望を語ったりするのかもしれませんね。

中島　Kubernetesが当たり前という世代は、僕らの世代とは異なる視点を持てると思うので、新しいものを生み出してほしいですね。そういうアイデアを伸ばせるよう、若者を助けていけるようになりたいと思っています。