1プロダクトで数多いサービスを抱えている複雑性を、 ミツモアのエンジニアたちはどうやって実現しているのか？
ミツモアのサービス領域では、およそ300のサービスの見積もりを1つのプロダクトで実現しています。業種は多岐に渡り、税理士や行政書士といった士業から、庭のお手入れや水のトラブルといった暮らしのお悩みまで。各業種で全く異なる業界慣習や、見積もり条件を、どのように1つのプロダクトで実現しているのか、ミツモアのエンジニア古参・坂本に語ってもらいました。
▼プロフィール
坂本竜（@ryusaka） プロダクト部 開発3グループ
早稲田大学で情報工学を学び、インターンを経て2019年にミツモアに新卒第一号として入社。Node.js, Reactを用いてフロントエンド、バックエンド共に開発。社内にて既存プロジェクトへのTypescriptの環境構築、普及を行う。
https://github.com/ryusaka
https://qiita.com/ryusaka
2022年春におけるミツモアの概要
ーまずは、現時点（2022年4月）でのミツモアのサービスの概要を教えてください。カテゴリに分けると300もあるんですね！
坂本：最初にできた時点で、サービスの分類みたいなものはもうあって、元々200以上はありました。ただ、それぞれに対して力を入れて、その領域を大きくしていこうというのは、順番にやってきました。大きく分けると「くらしカテゴリ」と「ビジネスカテゴリ」の2つですけど、その中でも細かくいろいろジャンルが分かれていて、例えば「日程が大事なサービス」。「この日にエアコン掃除してほしい」のように、いわゆる「くらしのカテゴリ」のサービスはそういうものが多いですね。「ビジネスカテゴリ」と言われているものだと、税理士さんなど、1回というよりは長きに渡ってお付き合いしていくプロの方たち、そういう性質の方たちが分類されています。
ーミツモアで「サービス領域」と呼んでいるサービスですね。
坂本：そうです。一方「リードジェネレーション領域」と呼ばれている「ソフトウェア見積もり」という別の性質のものがあります。これは、大まかに依頼を出すと見積もりがくるというのは似てるんですけど、完全に企業向けです。例えば、社内チャットシステムSlackなどを導入するための検討および比較見積もり、というサービスになっていて、比較して見積もるという意味ではサービス領域と同じですが、事業者側としては全然違っています。「サービス領域」だと成約した時に手数料をもらうんですけど、「リードジェネレーション領域」だと、Slackに「この人Slack使ってくれるかもしれませんよ」という、いわゆるリード（見込み顧客）送客というものをしているので、送客した時点で料金をいただいています。
ー「リードジェネレーション領域」の方が後からできたということでしたね。「サービス領域」の「くらし」と「ビジネス」ははじめから分かれていたんですか？
坂本：当時「くらし」と「ビジネス」みたいな区切りは明確にはしていなかったですね。自動応募でもなかったので、一律で応募、という感じで、本当にただミツモアという一個のシステムの上に乗っていて、サービスの名前が違うだけでした。
ーそこから自動応募にしたり、成約課金にしたり、変遷してきたわけですね。
坂本：2019年12月に自動応募が登場して、応募課金から成約課金になり、その辺りから、質問に答えたものに基づいて料金を計算して出すということを始め、ビジネス側のいろんな要求が日々増えていくという状況が始まりました。そこで、何か根本的な、汎用的なものを作らないと大変なことになりそうだね、ということで登場したのがマッピングシステムです。2020年6月頃でしょうか、2020年の年始に税理士カテゴリから自動応募を始めて、税理士以外でも自動応募を展開し始めて、トータル半年ぐらい経った時に、マッピングの機能を入れたという感じですね。
複雑なビズ要求を汎用化〜マッピングシステムの導入
ーマッピングシステム導入にいたるまで詳しく教えて下さい。
坂本：そもそも、ミツモアの質問カードは結構パターンがありました。複数の選択肢から1個を選択するパターン、複数を選択するパターン、数を入力するパターン、あんまりないけど文字や写真を載せるパターン。いろんなタイプの質問ができるのですが、結局は1個答えたら、それに対しての料金が計算されるようになっていました。その頃、ビジネス側から「その組み合わせをしたい」という話がきました。例えば、「引越し」が一番複雑に使われてます。引越しは、トラックに積むのですが、トラックのサイズによって料金が変わるんですね。最初は依頼者さんに「どのトラックがいいですか？」と、聞いていたんですが、トラックのサイズを聞かれてもわからないですよね（笑）。「トラックのサイズが決まらないと、見積もりが出せないよ」という事業者側の意見があったので、じゃあしょうがないから聞こうと。
ー自分は、トラックのサイズを意識したことがないですね。
坂本：そうなんです。引越しの荷物が軽トラに載るのか、2tトラックなのか、4tトラックなのか、依頼者に聞いてもわからないんです。でも、引越し業者に聞けば引越しの見積もりを出してくれるわけじゃないですか。プロの方たちはどうやって、トラックのサイズ決めてるんだろうと深堀りして、大体物のサイズは決まっているから、何が何個、何が何個、だったらこのトラックにおさまるだろうという想像をしていると。このプロの想像を機械的にできないかという話になったんです。でも今までは一個の質問で一個の料金だったので、あんまり回答同士に関連性はなかったんですよね。例えば「ソファを運びたい」「椅子を運びたい」という回答は、お互い関係なかったんです。例えば、ソファの料金は100円、椅子は100円、だけだった。ソファの料金は椅子を選択したかによって変化はなかったんですよ。それぞれの選択肢が独立していたんですけど、トラックを決めるとなった時に、「ソファは大体これぐらいの容量だろう」とミツモアが決めて、それを答えた分だけ足し算すると、これくらいの容量です、だったら4tトラックですね、ぐらいまで計算したいと。そうなると、ソファを入れたか入れないかでトラックのサイズが変わってくる。選択肢同士の独立性をそこで失わせなければいけなかった。そこでマッピングシステムというものを導入しようということになったのです。
ー複雑ゆえの解決法がマッピングシステムだったということですね。
坂本：引越しだけ考えたら、マッピングシステムみたいな壮大なものを作らなくても、多分対応できるんですよ。ミツモアが引越しサービスだけだったら、本当にそれに特化したものを作ればいいので、マッピングシステムなんていう抽象的なものを作る必要はなかったんです。でも、300以上のサービスを展開するミツモアだとそうはいかなくて、適度に解決方法を抽象化というか一般化をする必要がある。ミツモアの機能を作る上で大事と言いましたが、単純に、開発のコードを作るコーディングや、アプリケーション開発においても抽象化するというのは、開発者のみならず、PMにも求められていることです。それができないと、引越しだけにしか使えないとんがった機能になってしまうので、汎用性がすごく下がるし、それを全サービスでやるとしたら、300パターン生まれてしまうことになる。
ー1サービス作り込むのに3ヶ月かかるから、300サービスなら75年かかるという話ですね。
坂本：例えば、エアコンのクリーニング業者は、壁掛けタイプの普通のエアコンと、天井に埋め込んでいるエアコン、それぞれの台数を聞いて料金を出しますが、合計2台以上なら一律1000円引きや、何％引きしたいという要望がある。エアコンチームのビジネス側メンバーがそういう要望を実現したいと言ってきたら、その要望を抽象化します。「回答の数を合計して一定数以上であったらN％の料金を値引きしたい」。そういう汎用性の高い、穴埋め問題みたいにしていきます。これが抽象化できてないと「2台以上で割引したい」という要望は、エアコン業界だと2台以上なんですけど、例えばカメラマンだと「5人以上だと割引したい」となるんですよ。 2と5という数字も違うし、台と人という単位も違う。2台を穴埋めにしないまま開発してしまうと、5人に対応できないシステムが出来上がってしまう訳ですね。抽象化できてないというのはそういう意味なんです。ただ、この穴埋めを穴埋めにしすぎてしまうと、試験勉強の時に、全部塗り潰しちゃって、丸暗記してしまうみたいなものと一緒です（笑）。過度に抽象化しすぎて、サービスの理想とは常にちょっとずれてるということになってしまう。
ー抽象化しすぎてもダメなんですね。
坂本：複雑な要望を繰り返していくと、それ専用のサービス、それ専門のサイト、それ専用に作ったアプリケーションよりも、単純に劣ってしまう。単体でみた時に使いづらいものになってしまうことが起りうるので、例えば、日程が大事なくらしのサービスと、長く付き合うビジネスのサービス、そこはミツモアの中でも大きめに全体の依頼の流れというものを分けています。予約型と交渉型と呼んでいるんですが、例えば予約型サービスは、話すことよりも、この日空いてるかどうかが問題です。だから、まずは日程を選びましょう、それから、話を始めましょうみたいな感じになっています。一方、交渉型というのは、あんまり日程は重要じゃない。誰に依頼したいかを、いろんなことを話した上で、じっくり考えて決めたい。そういうのは交渉しながら、誰に依頼するのか決めていく。
ーだいぶ性質が違いますね。
坂本：その二つのシステムを1個にするのは無理、という判断だったんですね。そこは一般化しすぎない。そういうところは過度に一般化しすぎないけど、特定のサービスとか領域だけに特化したものはちょっと一般化しようか、みたいな感じに考えてますね。例えば、ソフトウェア見積もりは、なんとなく全体の流れは似ているんですけど、違う部分がすごく多かったので、完全に別とまでは言わないですけど、コードの基盤自体は一緒なんですけど、存在としては、独立していて、別アプリケーションに近い感じで作っています。
まとめると、リード領域とサービス領域は、大元のコードレベルで分離したものとして作っていて、さらにサービス領域の中で、コードの塊としては同じ中にあるけど、全体的な大きな流れが違う故に違うコードがあるというのが予約型と交渉型。そこから先は、割と穴埋め問題みたいに一般化して、設定で対応できるようにする差分で収めるみたいに、枝分かれする部分を何階層か用意して、パターンが増えないようにしつつ、なるべく理想の状態に近づけるみたいなところをやってますね。
ー思っていたよりは、シンプルな構造で理解しやすいですね。
坂本：開発側に求められてることとしては、ビジネス側の「こういうことを実現したい」という要望に対して、それを噛み砕いて構造化して、本当に解決したいことを理解した上で、システムに落とし込むというのが仕事な訳なんですけど、ビジネス側に「こういう機能でどうですか」と提案するのも仕事。同じように、ビジネス側も大事なのは、開発がそれを理解して、適切に欲しかったものを投げ返してくれるようにうまく伝えること。結果としてできてくるものに大きく関わってくることなので、そっちの側面からも大事ですね。ミツモアではビジネス側と開発側が結構相談します。ビジネス側も、勘所というか、投げ方、こういう書き方をすると割と話が早く進みやすいとか、そういうのを理解してくれてます。開発側も、ビジネス側の問題とか、どういうものを抱えているのかとかいう問題を理解してあげた上で、抽象化をするというところでは、能力というか、結構腕の見せ所な部分ではあるし、僕個人としては楽しい部分ですね。
ー仕事の面白い部分なんですね！
坂本：マッピングは、僕個人としては楽しかったです。ビジネス側の結構具体的だった要望を噛み砕いて、こういうのにしたら要望を実現できるし、他のサービスにも使えて、特に開発はせずに使えますよね、と提案できた。実際マッピングはそんなに追加改修はせずに、ずっと使ってもらえているので、結構うまくいったなと思ってます。そういうのができた時、開発側としては非常に嬉しかったりしますよね。
ーいいですね！ ちなみにビジネス側はどういう風にチームが分かれているんですか？
坂本：ミツモアには各カテゴリに、カテゴリコンサルというチームがあって、それぞれのチームがそれぞれのカテゴリの数字に責任を持っています。このチームはカメラマン領域を伸ばすチーム、このチームは税理士領域を伸ばすチーム、というように分かれています。
ーざっと数えただけで30ぐらいはあるんですけど、このチームから開発に、五月雨のように要望がくるんですか？
坂本：五月雨みたいに来て大変なことになったので（笑）。昔はチームも人数も少なかったので、1カテゴリごとに力を入れていくみたいなことをやっていたので、みんなで1個ずつ対応していればよかったんですけど、いくつもチームを作ったら、一気にくるじゃないですか（笑）。そこで、開発フローの整備をしました。それぞれのチームの中でこういう要望があります、こういう機能がほしいです、それを作ることによって、どれぐらいの売り上げが見込めるかをまとめた上で、やるかやらないかを経営のレビューを通して決めてもらってます。そこから先は一本道に乗って、順番にやってくるみたいになってますね。
ーじゃあ、「エアコンと引越しの穴埋めが共通してそう」というのは、開発チームで話してやる感じですか？
坂本：ビジネス側で事前に相談があったりするんですね。「こういうのやりたいんですけど、どれぐらいでできますか」と聞いた時に「似たような話、こっちでもしてたよ」となれば、その時点でビジネス側の人たちに話してもらって、その時点である程度共通の部分をすり合わせてくれます。そういうのを、随所でやってますね。もちろん開発側が、実装レベルで共通化していることもありますが。
大規模プロダクトを効率良く開発〜Runtime Config
ー他に、坂本さんが個人的に手応えがあった取組みなどありますか？
坂本：ちょっと古いシステムにはなりますが、Runtime Config（ランタイムコンフィグ）というシステムがミツモアのプロダクトの中にあります。開発やリリースがしやすくなるリリーススイッチみたいなものですが、それは今でも汎用的に使われています。
Runtime Configは「この部分のコードは、ここに存在するけど、スイッチがオンじゃなかったら動かない」という設定ができる。そうすると、どんどん合流させても動かないのでアプリケーションとしては問題ない。実装してあるけど、スイッチが入っていないから、動かないので問題ない。テスト環境だとそのスイッチをオンにして、ちゃんと動くかどうか確かめられる。つまり、ちょっとずつ作っていけるんですね。スイッチの内側にあるので、仮に不完全な状態でも一回合流させることができるんですよ。中途半端だけど一旦ここまで作って合流させて、そこからまた作って、というように細々細々開発ができる。
そういうスイッチが、アプリケーションの中に、コードの中に何十とあって、いろんなチームがそのスイッチを使って、ある程度自由に開発してもぶつかることがない。例えば、今まで開発に1ヶ月かかってたとすると、その1ヶ月分の差分がぶつからないかの検査も必要なんですが、スイッチを使うと、言ってしまえば毎日コードを合流させてしまえるので、そんなにコンフリクトも起こりにくい。また、もしリリースをして「何か変だ、戻そう」という時に、スイッチがなかったら、もう一回リリースをし直さないといけなくて、サーバーを再起動するみたいなことが必要で結構時間がかかる場合もある。でも、そのリリーススイッチがあると、一瞬で、本当に1秒で戻せるんですよ。何かあった時に、影響を最小限にするという副次的な効果もありますね。
さらに、そのスイッチを50％の人にだけオンにするという設定もできます。ちょっと何か問題が予想できるものの場合は10％の人にだけリリースしてから、50％、100％、といったように段階的にリリースすることもできる。ABテストにも使えますね。50％の人にはこのボタンをオレンジ色で出して、残りの人は緑色で出して、どっちが数字いいか見たり。結局スイッチのオンとオフの機能なので、オンとオフをうまく組み合わせると、色んなことをコードの中で実現することができる。結構いろんなところで使っていて、開発効率やリリース効率を上げているかなと思いますね。
問題解決が好きな人求ム！
ーちょっと話が戻りますが、サービス領域の予約型と交渉型それぞれに、また細分化されているイメージですか？
坂本：予約型と交渉型に大きく分かれると言ったんですが、実はその中間型みたいなのもあります。日程を決めるんですけど「何も話さずに予約されても無理だよ」というパターンがあります。「不用品回収」や「庭木の伐採」ですね。「いきなり日にちを予約されても、どんなサイズの家かわからない」とか「どんな木が生えているかわからないからイエスとは言えない」ので、チャット機能で相談が必要だけど、日付が大事なので、カレンダー予約機能も使いたい。
予約型は、とりあえず予約したら全てが始まるんで、チャットは最初はできないんですよ。交渉型はその辺が全部オープンで、自由にチャットして、好きに人を決めてね、というスタイル。その中間型は、チャットはできるけど、決めるときは日程と共に予約してね、というシステムです。
あとは、不用品回収もトラックのサイズで料金が決まるところがあるので、引越しのマッピング機能を使いながら見積もりの精度を上げつつ、交渉と予約の中間みたいなものを作って、解決しましたね。
ー共通してる部分はあるけど、業界によっては順番が違うのですね。
坂本：そうですね。交渉型と予約型の共通部分として、チャットする、お金を払う、といった機能があります。そこはもちろん一緒のものを使います。交渉型、予約型、中間型、とは言ってるんですけど、チャットをする機能、お金を払う機能、カレンダーから選べる機能、などがミツモアの中にいっぱいあって、その中からどれをどの順番で使いますか、というのを選んで型を作っているというイメージですね。
予約型に対してこういう変更したいとなった場合、色んな領域で予約型を使っているので、全サービスで同じ変更をしても大丈夫かは調査して、予約の型のレベルで改善をしていくということは重要なことですね。結局ある改善が特定のサービスだけにしか使えないような機能だったら、他の代替案を考えたり、それは各サービスに特化しすぎてるから、あんまり売り上げ的なインパクトもないし、一旦なし、という結論になることもあったりします。
ー各業界の慣習みたいなことを、知ってるほうが開発しやすいんじゃないかなと思いますが、そういうものはエンジニアに降りてくるものなんですか？
坂本：要望や、その要望の背景などの説明はビジネス側がしてくれますね。どういう状況で使われて、誰が使って、どういう問題が起きてるのかというのを、具体的にイメージしながら、考えられる人、作れる人、そういうのが好きな人がミツモアに合ってる人かと思いますね。
ー不用品回収に詳しいエンジニアというのは貴重ですね。
坂本：だんだん色んなサービスのいろんな相談をやっていくと、そういう知識はすごい増えますよね（笑）。その辺を詳しく掘って、めちゃくちゃ詳しくなってもらう役割はカテゴリコンサルのチームの人、ビジネス側がそのプロフェッショナルなので、そこから必要な情報を僕たちにインプットしてくれます。そのおかげで僕たちもその辺のドメインの知識をちゃんと持った上で、イメージしながら考えたり作ったりできてるのかなと。それをある程度共通のイメージがないと、議論も深くならないので、その辺は確かにいろんな業界を知ることができて楽しいですし、それが楽しい人がもしかしたら多いのかもしれませんね。
ーミツモアのエンジニアは、幅広いビジネス事情を知ることができそうですね。
坂本：よく業務系のアプリケーションの場合、その業務にシステムを合わせるんじゃなくて、いいシステムを作ってそれに業務を合わせる方が良いとされてたりします。でも、ミツモアのように色んな業界の色んな人が使うサービスだと、それをやるとミツモアの考えた理想の仕事フローを作って、押し付けてしまったがために、全然使ってくれないし不満もいっぱい出てしまうので、うまく行かない。ですので、実際に使ってくれる人の具体的なイメージをして、実際使ってくれる人の体験を上げる。その上で、喜んでもらえることが嬉しい、みたいな人がミツモアのエンジニア向きですよね。ビズ側と必要な議論を徹底した上で、システムを作ろう、みたいなことが楽しい人が向いていると思います。反対に、どういう機能がいいかとかを決めるのはあんまり好きじゃなくて、ひたすらにすごいスピードでずっと開発して作っていくことだけがすごい楽しい、それが一番好きですというタイプの人は、ミツモアの文化的にも、業務的にもミスマッチになってしまう可能性が高いかもしれません。
ービジネス側との議論が好きな人、そしてそこにチャレンジしたい人が向いているのですね。
坂本：ひたすら新しいものを作って壊して、作って壊して、合ったものを見つけるというフェーズは一旦終わりというか、徐々にそういうフェーズから、今あるプロダクトの洗練度を上げていくみたいなフェーズに入りつつあるかなと。具体的にイメージを持って、それをさらに良くしていく、幸せな人を増やすところに喜びを感じるエンジニアの方、ぜひ一緒に働いてください！という感じですね。
ーありがとうございました！
（取材・執筆 字と図 吉田千枝子）
======================================
ミツモアでは、現在事業拡大を進めており、エンジニア・デザイナー・PdMをはじめ多くの職種で積極採用中です。
Wantedlyにて募集しているので、カジュアルに面談に来てみませんか？
デザイングループも所属するプロダクト部の詳しいご紹介は「ミツモア エンジニア向け会社説明資料 / about meetsmore for engineers」を公開しております。