はじめに
こんにちは、メルカリの日本リージョンのCTOを担当している@kimuras と申します。2023年4月にCTOに就任して現在Marketplace、Merpay、Mercoinの技術的な責任者を担当しています。本稿では、この１年間で注力してきた、Engineering Roadmapの作成についてお話したいと思います。内容によっては、ある程度の組織の規模感にならないと適さない内容となってしまうかもしれませんが、サービスの方向性やそれに合わせたエンジニアリング組織の作成について、今後整理しなければならない局面でご参考にしていただけたら幸いです。
メルカリのロードマップとは
メルカリには、グループ全体の指針となるグループロードマップ(以下ロードマップと呼びます）があります。このロードマップのおかげで、私たちは今後進むべき方向が明確になり、社員全員が提供したい価値についての共通の認識を持つことができます。ロードマップは単なる実現したい事項のTODOリストではなく、私たちのミッションやビジョンを正確に理解するための重要なツールです。メルカリのロードマップについては、こちらのメルカンの記事を参照してください。
Engineering Roadmapの必要性
ロードマップがうまく運用されていることで、わたしたちはこれまでに多くの新しい価値を提供してきました。その中にはメルカードやMerpayのような時間もかかり、難易度も高いプロジェクトも含まれています。しかし、エンジニアリング組織としては、このロードマップに対してより先行して技術的な準備ができていたら、より高速かつ計画的にビジネス展開をできたのではないかと感じることがありました。
事業の未来がロードマップで示されているので、エンジニアリングとしてはその道標に対して、それを実現するためのFoundationやPlatformを事前に提供できることが理想的です。しかし、これまでメルカリグループでは各Divisionごとに個別のEngineering Roadmapが存在していたものの、全社横断でのものは存在しませんでした。(※ 12/26 10:30 初稿ではロードマップが一切存在しないようにとれる表現になっていましたが、正しく修正しました)
メルカリではビジネスや開発者をスケールさせるためにMicroservices Architectureを導入したり、インドの開発拠点を作ったりと、チャレンジングなことを通じて継続的なエンジニアリングの改善を行ってきました。しかし、事業のロードマップに対して、Engineering Roadmapも同時に用意することで、よりエンジニアリングも含めたVisionがクリアーになり、効率性が上がるのではないかと考えました。
Engineering Roadmapがあることのメリット
前提として、私たちの開発のレイヤーは主にProduct、Foundation、Platformの3つのレイヤーに分かれています。Product開発は主にBFF、BackendやFrontendの開発を含めたFeature開発となります。そのひとつ下のレイヤーであるFoundationはLogisticsやTrsansactionやPaymentなどのProductとは疎結合ではあるものの、さまざまなサービスから呼ばれる重要なバックエンドのAPI群となります。そして、Platformはさらに一番下のレイヤーであり、Microserviceを容易に作るためのMicroservices PlatformやCI/CD、Infrastracture、Networkなどのすべてのサービスを支える基盤となっています。したがって、下のレイヤーになるほど支えているサービスが多くなるため、PlatformやFoundationは上位レイヤーのことを考慮しなくてはならないことが多く、開発や変更の時間軸は長くなってしまいます。
このような私たちの状態を前提として、Engineering Roadmapが存在することの意義を以下に述べていきます。なので、序盤にも述べたように、スタートアップのような開発の初期段階のフェーズやFoundation領域が小規模なサービスでは、本稿で述べるEngineering Roadmapの作成する意義や戦略とは違った打ち手の方が良い可能性があることをご容赦ください。
スケジュールに対する期待値調整が容易になる
抽象的な表現となってしまいますが、何か新しい価値提供を実現するためのリアーキテクチャや、新たにFoundation/Platformを開発をするには、想定以上に時間がかかってしまうことが一般的に多くあります。開発を計画的に行わず、間に合わせでライブラリを少し修正するだけですませてしまったり、本来であればアーキテクチャを改修しなければならないところを、改修せずに無理に既存のアーキテクチャに新機能を詰め込んでしまったがゆえに、後のメンテナンス性が落ちてしまったり、リファクタリングが困難になることが起こりがちです。
したがって、エンジニアリングとしては極力新しい要件仕様に対して、適切なFoundation/Platformを新規で開発したり、リアーキテクチャをしたうえで新規機能を実装することが理想的です。しかし、これらの開発には調査や設計、実装方針について関係者とコンセンサスをとるなど、実現するのに数日どころか数ヶ月、あるいは年単位で時間がかかってしまうという問題があります。
このため、新規サービスの開発を始めるタイミングで、Product開発と並行してリアーキテクチャやFoundation/Platform改善をおこなうと、時間軸が合わなかったり、スペックの調整をしながら開発することで要件漏れや大きなバグを作ってしまうことの原因となってしまいます。加えてProduct開発に対してFoundation/Platform側の対応が遅れてしまい、リリーススケジュールに悪影響を与えてしまうこともしばしば発生してしまいます。
ただ、上述のように事業のロードマップが示されている状況においては、エンジニアリングとしてもそれを実現するためのFoundation/Platform開発を事前に計画性をもって行うことができれば、よりスムーズに開発することができるし、メンテナンス性や安全性もより担保された開発を行うことができます。
Engineeringの改善施策のコンセンサスを得ることができる
上述のようにリアーキテクチャやリファクタリング、Foundation/Platform開発などのエンジニアリングに関する改善施策は中長期にわたることがしばしばあります。このため、明確な目的意識を持って施策を実施しなければ、途中経過でプロジェクトの意義を問われることや、プライオリティを下げざるを得ない状況となってしまうことが、残念ながらよく発生します。エンジニアリングには各改善プロジェクトの意義について説明責任はあるものの、事前にコンセンサスがとれておらずに説明の難易度が上がったり、プライオリティが変更されてしまうことは生産性に悪影響があるし、モチベーションにも大きな影響を与えてしまいかねません。
しかし、エンジニアリング主導の改善施策についても、始める前にそれぞれの意義やゴールを明確化して、かつロードマップにアラインできていれば、たとえ中長期な開発であってもステークホルダーからも賛同を得られ、サポートを得ることができるはずです。時には事業のロードマップにアラインすることが難しい中長期の改善施策、例えばMicroservices Architectureの根本的なアーキテクチャの改善や、BCPの改善などについても、ゴール設定と得られるメリットを明確化して、Engineering Roadmapとして事前にステークホルダーや経営から同意を得られていれば、ストレスなく改善プロジェクトを継続することができます。
先を見通したアーキテクチャを作ることができる
基本的にシステムアーキテクチャはビジネスの成長やエンジニアリング組織の規模感、ビジネスの方向性などにあわせて常に改善を続けなければなりません。加えて、極力メンテナンス性や拡張性を高くすることで継続的に新たなニーズに応えられることが理想的です。
しかし、ビジネスの方向性が定まっていなければ、ある程度は想像でシステムの拡張性を担保しなければならず、仮にニーズを満たすことができなれけば、近い将来にリアーキテクチャを実施しなければならなくなります。
一方、事業ロードマップやEngineering Roadmapが作成されていれば、3年ほどの近い将来については概ね方向性がわかっているため、拡張性の観点で確度の高い設計をすることができます。これは、設計を担当するアーキテクトやTech Lead(技術的なリーダーのことであり、以下TLと呼ぶ)に限らず、エンジニアが日々のコーディングでの細かい意思決定を手助けすることができるため、すべてのエンジニアが意識的に将来を見据えた設計を心がけられるようになることが好ましい。
例えばIDに関する設計をしているときに、将来的にどのような事業展開をするのか、またパートナー企業が存在するようなビジネスをするときにパートナーアカウント、あるいはID連携が必要になる事業計画がある、といった計画が事前にわかっていれば、それらのニーズに合わせたアーキテクチャの設計ができます。これはFoundation/Platformやインフラストラクチャなどさまざまな要素技術にとっても重要であり、ビジネス成長には欠かせないことです。
Visionに対する解像度が深まる
Visionを作ることは、組織にとってとても大事なことです。Visionを示すことによって、これから先に新たにお客さまに提供したい価値や、組織のありたい姿などを掲げて、組織で一体感を持ってタスクに取り組むことができます。
しかし、Visionだけではそれをどういう手順や手段で実現していくかはわからず、説明される方もうまく咀嚼できないことがあります。ありたい姿をVisionで示し、それに対してどのようにそれを実現していくかをEngineering Roadmapに記載することで、Visionに到達するまでのストーリーが各エンジニアにも伝わり、より理解を得ることができます。
これは説明する側のコストも下がりますし、ミスコミュニケーションを防ぐためにも重要だと考えています。
Engineering Roadmapを作るためのTips
Engineering Roadmapの必要性や効果がわかったところで、次に実際にロードマップを作るためのTipsについて説明します。ここでは主に2通りのアプローチを突き合わせる手法について紹介します。
まずは大胆な理想像とVisionを作る
自分の場合は、あまり多くのことを気にしすぎて進められなくなるよりも、まずは実現可能性や周りの考えなどは考慮せずに、大胆な理想像を決めてしまいます。
実際にVisionやEngineering Roadmapを作ることは容易ではありません。理想的なゴールは何なのか、ステークホルダーはどのようにゴールを考えているのか、お客さまは何を求めているのか、それを実現することが可能なのか。それらの多くの関連する要素を考慮すると、なかなかVisionやロードマップを定めることができなくなってしまいます。
ただ自分は、あえて実現することが難しいのではないかと思うくらいの大胆で理想的なゴールを決めます。それから、それを実現するためのロードマップを作りながら実現可能性を考慮して、Visionを少しずつ現実的なものに落とし込んでいくことで、多少難易度が高いが、納得感のある形に落ち着くことができます。万人には当てはまらないとは思いますが、まずはあまり固くならずに、大胆で理想的なVisionを書き出してみると良いと思っています。
TLとのコミュニケーション強化
ある程度の組織規模のCTOの立場になると責務のスコープが広くなり、開発現場での解くべき課題や理想的な状態などが把握しづらくなってしまうことがあります。
普段からVPoEやEMとのコミュニケーションを取ることで、組織課題を把握することができますが、より開発現場に近い課題感を把握するためにはTL(TLを指定していない場合はエンジニアチームをリードしている立場の方が良いでしょう）とのディスカッションをすることで情報を得ることができます。
TLとEMとのディスカッションをすることで開発現場でも納得感の高く、かつ的確に組織課題を捉えたRoadmapを作成することができると、自身の経験から強く感じています。
理想は「現実的でワクワク感」があること
ここまで2つのアプローチについて紹介しましたが、進め方としては、まずはフィージビリティを気にせずに、技術的にチャレンジングでかつビジネスに貢献するようなVisionを「トップダウンのアプローチ」で作成してみます。しかし、これだけでは現実離れしすぎてしまうかもしれませんし、本質的な開発現場の課題をとらえられず多くのエンジニアから共感を得られないかもしれません。そこで、各領域での本質的な課題を把握しており、強いVisionを持っているTLや、組織課題を理解しているVPoEやEMからの「ボトムアップ」の意見をぶつけあうことで、チャレンジングでかつ現実的なVisionやEngineering Roadmapを作成できることが理想的です。
このトップダウンとボトムアップの意見をすり合わせることによって、私たちのこれからの開発を一人一人のエンジニアが自分事として捉えて、積極的にコメントをくれるようになり、かつコミットしてくれるようになります。CTOとしては、エンジニアがこれまでに挑戦したかったけど、挑戦できなかったような難しくもおもしろい課題に挑戦するための理詰めを支え、最終的にその挑戦に対してスポンサーとなって一緒に実現しようとする姿勢が大事なのだと思います。このように難しい課題であっても、みんなで同じ方向を見て、一緒に解決していくことで、エンジニアたちのワクワク感が生まれ、結果的に自信を持って自分たちで誇りに思える技術を使い、お客さまに新たな価値を提供できるのだと信じています。
最後に
最後までお読みいただき、ありがとうございました。Engineering Roadmapは作っただけではなくて、今後どのように運用していくか、進捗させていくか、あるいはEngineering Roadmap自体を更新していくかもとても大事だと思います。運用していく中での困難や発見があれば、また記事にしてまとめてお伝えしていきたいと思います。
