サービス終了のタイミングで振り返る──メルカリとオープンロジは、いかにして同じ熱量で「あとよろメルカリ便」の構築に向き合ったのか？

こんにちは、メルロジで事業開発を担当している@kimchanです。

お客さまが出品した商品を倉庫に送ることで、商品が売れた後倉庫のスタッフがお客さまの代わりに梱包・発送をおこなうサービス「あとよろメルカリ便」をご存知でしょうか？

かねてから、メルカリへの出品のハードルだった「梱包・発送の手間の削減」という課題を解消すべく、物流フルフィルメントプラットフォームを提供する株式会社オープンロジ（以下、オープンロジ）とともに提供したサービスです。これまで多くのお客さまにご利用いただきましたが、2022年3月28日をもって、サービスの新規申し込み受付を終了しました。今後は、サービス提供を通じて得られた知見やいただいたご意見を、メルカリの品質向上や新たなサービス開発に活かしいきます。

2社にとって大きなチャンレンジだった、「あとよろメルカリ便」はいかにして構築されたものだったのか？そして、そこで得たものとはなんだったのか？

メルカリからプロダクトマネージャーの@kirinと物流輸送企画の@kodai_gr、オープンロジの事業開発担当の相澤 景介さんとプロジェクトマネジメントリーダーの桐生佳祐さんが集まり、サービス終了のタイミングで改めて振り返りました。

セラーUXを第一に、物流現場での作業との最適なバランスを模索

──2022年3月に「あとよろメルカリ便」のサービス提供が終了しました。

@kirin：お客さまにはご迷惑をおかけして大変申し訳ないのですが、2022年3月28日をもって、サービスの新規申し込み受付を終了することになりました。サービス終了が残念だという声をTwitterなどのSNSで見て、「あとよろメルカリ便」を新規立ち上げた意味は大きかったと感じています。今後はメルカリグループ全体で経営資本を集中していく中で、学びを生かして出品者の販売体験をより良くするサービスを仕込んでいきます。

オープンロジ・相澤：サービス終了はオープンロジとしても残念でしたが、オープンロジには個人利用者向けのサービスの提供経験があまりなかったので、たくさんの学びがありました。特にメルカリさんのお客さまへの向き合い方は大きな学びでした。また、今回の特殊オペレーションやデータの可視化ツールなど、本プロジェクトで作りあげたものは、形を変えて自社サービスに応用しているところもあり、事業にポジティブな影響が大きかったです。

──そもそも、オープンロジと一緒に取り組むことになったきっかけはなんだったのですか？

@kirin：以前から「メルカリアプリはダウンロードいただいているが、出品経験のないお客さまに出品していただくにはどうすればよいか?」という課題を解決できるアプリ内機能やサービスを検討していました。オープンロジさんと協業することで、出品に対しての一番大きなブロッカーになっている梱包・発送作業を取り除くサービスを提供できると考えました。

@kodai_gr：オープンロジさんとの取り組みは「あとよろメルカリ便」が初めてではなく、ブランド製品をメルカリで買取をするサービス「メルカリNOW」で在庫管理システムを提供していただいたという経緯があります。

「メルカリNOW」ではシステム提供だけでなく、ロケーションや機材などの相談にものっていただきました。保管や管理といった倉庫的なことだけでなく、システムや機材などのテック的なことも総合的に対応いただける会社だという印象が強く残っていました。そこで、サービスの提供のための物流を中心としたバックエンド業務の体制とフロー構築について、オープンロジさんと一緒に取り組むことになりました。

オープンロジ・相澤：お話をいただいて、オープンロジだけでは取り組むことができない規模のチャレンジに取り組めるチャンスとして、即決・即答で協業をスタートさせていただきました。「メルカリNOW」ではシステムのみの提供でしたが、今回はオペレーションの設計と運用も担当させていただく形だったので、とてもやりがいがありましたね。

──サービスの設計はどんな手順で行いましたか？

オープンロジ・相澤：メルカリさんのお客さま向けの利用フローは洗練されていますので、まずは、そのフローに合わせ、お客さまが楽になるようなサービスをどう組み込んでいくかというところからスタートしました。どのような形で倉庫に出品した商品を送るのが楽なのか？倉庫に届いた商品をどうシステムで紐づけて入庫すればお客さまのUX的に負担がかからないのか、という観点から議論を繰り返し、フローを組み立てました。

──まずは、お客さまの課題を解決するための必要な要件を両社で整理しながら、サービスを作っていた形ですよね。

@kirin：そうですね。「コンセプトの検証のためのメルカリのお客さまの定量調査」「フィージビリティを確認するための社内テスト」「MVPを作成して実際のお客さまに試していただいたテスト」を経て、その後リリース、という進め方がしっかりできました。サービスリリース前より、社内外の様々なテストを二人三脚で実施できたと思います。

オープンロジ・桐生：コンセプトもサービス内容もシンプルでわかりやすいけれど、工程は意外と複雑です。バックエンド業務の設計では、お客さまから見えない部分に対して「どうすればお客さまに安心して納得していただけるのか」「工程づくりに合わせてUIや体験そのものが複雑になりすぎないためにはどのようにしていくべきなのか」ということをとても意識したのですが、それらを実現する仕組みづくりには頭を悩ませました。お客さま側のUXと合わせて、倉庫側の作業上のUXとの両立もメルカリさんと相談しながら考えていきました。

オープンロジ・相澤：倉庫側でのイレギュラーな処理が増えすぎないようなパターン化と、イレギュラーな場合でも柔軟に対応できるフローの構築が不可欠でしたね。

オープンロジ・桐生：倉庫側のフローを簡単にすると、お客さまに対応していただかなければならないことが増えるので、良いバランスを取るのが難しかった。

@kirin：そのバランスを考える上で、フィージビリティを確認するための社内テストを初期に実施し、プロダクトを作る前に想定フローと課題の仮設が組み立てられたのはよかったですよね。

──サービスを作る時に気をつかったこと、難しかったことはありますか？

@kirin：テストの際に「靴下1足なのに、ネコポスではなく宅配便になってしまった」という意見が社内から寄せられました。確認したところ厚手のスポーツソックスのため、ネコポスの規定の厚さを超えてしまっていたことが分りました。「靴下＝小さくて薄手のもの」という固定観念に気づきましたし、倉庫での商品のたたみ方などで、サイズが変わってしまうことは初期の課題でしたよね。

オープンロジ・桐生：メルカリさんの社内でテスト運用をしていただいたことで、さまざまな商品において「自分で送る時はネコポスで入るのに宅配便になってしまうのはなぜ？」というお客さまの疑問に対して、納得していただけるようなフローの構築が必要だとわかりました。紐付け用の商品撮影をする際に、サイズ計測器と一緒に撮影することで、お客さまがサイズ感を確認しやすく、視覚的にも納得していただきやすいフローを作りました。

また、形が変化しやすい洋服のような商品の厚さについては、作業する人によって「どれくらい押して付けて計測するか」という点でムラがあったのは事実です。また、荷物によっては、あまり押し付けてはいけない商品もあります。倉庫現場で誰が対応しても同じ対応ができるように、荷物の上に置く「一定重量の重し」をつくり、それを利用することで厚さ計測を標準化しました。

──商品を置くだけで色で大きさが分かる仕組みには感動しました。オープンロジさんが手作りされたと聞いて「これは絶対特許取った方がいい！」と思いました（笑）。

オープンロジ・桐生：発送時のサイズは大きく送料に影響するので、お客さまが販売をする前に、その送料がわかることが重要です。1点1点違う商品を計測する形になるので、その都度お客さまに細かく確認を取ることなく、納得していただきやすいフローを作ることは必須要件でしたね。

荷物の計測が一番時間がかかる上、属人化すると失敗するし、汎用化すべきものと考えました。将来的には自動計測やバーチャルな計測方法も検討していましたが、まずはアナログなものでビジュアルで誰でも分かるようにしたいと考えました。5〜6回の試作を経て、アナログなツールを完成させました。

倉庫はお客さまへ対して「発送時の梱包サイズをはかる」「サイズ確認時のエビデンスを残す」「計測基準を標準化する」の3項目を同時にハンズフリーで行うことができる

倉庫はお客さまへ対して「発送時の梱包サイズをはかる」「サイズ確認時のエビデンスを残す」「計測基準を標準化する」の3項目を同時にハンズフリーで行うことができる

──色々なノウハウが詰まったものだったのですね！

オープンロジ・相澤：ニーズ調査や課題整理から一緒に取り組んだことで、サービス開始前に想定課題に対する仕組みを整えることができ、汎用化されたフローを倉庫現場に導入することができました。オープンロジのビジネスのコンセプトが「標準化とパターン化」なので、属人性を排除したフロー構築はこだわってやっていましたね。

@kirin：週次のミーティングでオペレーションの問題点を画像や動画で共有し、一緒に改善策を検討したり、実際のオペレーションを倉庫で拝見したりして、一緒にプロジェクトを進行していきました。オープンロジさんには、“泥臭い”オペレーション改善に一つひとつ取り組んでいただけたてありがたかったです。また、今回はオフラインを含めたサービス開発のため、オンラインだけで完結しない“手触り感”があり、そこがプロジェクトとして難しい部分でもあり、プロダクトマネージャーとしては面白い部分でもありました。

──メルカリ側では、利用者にサービスを利用してもらうことで難しさはありましたか？

@kirin：メルカリ側の運用構築では、お客さまに倉庫に送ってもらうときの梱包をどうするかを伝えるのが一番難しいポイントでした。倉庫がダンボールの中に複数入った商品のうち「どれが1つの商品単位なのか」を判別するために、「1商品＝1小分け」単位で箱詰めいただくのが理想なのですが、1商品ずつ袋に包むとなると梱包資材の準備に手間もかかってしまいます。

オープンロジ・桐生：そこで、お客さまに作業してもらうのではなくて、ルールを決めて、あとは倉庫側で対応しましょうとなりましたよね。お客さまの倉庫に荷物を送る負荷を最小限にする工夫は結構取り組みましたよね。

物流工程を考える上で、「出品者が倉庫へ送るもの」というのは、「何がいくつ届く」という情報がバーコードなどでデータ管理され、事前に共有されているのが一般的な運用です。しかし「あとよろメルカリ便」の場合は、可能な限りお客さまの使いやすさを高めるという観点から、それらの情報を一切使わずに倉庫への「入庫・保管」を実現させるというのが今までにないチャレンジでした。

@kodai_gr：倉庫で撮影した写真と、出品した商品の写真を紐付けてもらうフローだったので、同じ見た目の商品の判別なども課題がありましたね。例えば、ポスターの箱は同じだけど中身の絵柄が違うといった外見では見分けられない商品が倉庫に入庫された場合、オープンロジさんからすぐに相談いただいて、出品者側のデータを確認して連絡をして対応していただきました。

オープンロジ・桐生：そういったイレギュラーも発生が想定されていたので、入庫の際に「判断が難しいハイレベルな商品」と「通常フローで問題なく分けられる一般の商品」を分けるようなフローも構築しました。順番に入庫していくと判断が難しいハイレベルな商品の確認で時間をとってしまって、後の商品の入庫が止まってしまいます。レーン自体を分けてしまって、入庫が滞らないような工夫もしました。

@kodai_gr：難しい問題は後回しにして、解ける問題から解いていくという流れが入試問題と同じような世界だと思いました（笑）。

──サービス改善を繰り返して提供していこうという想いの源泉はなんだったんですか？

@kirin：メルカリで出品する際に、梱包・発送は手間のかかる体験になっていたので、梱包と発送をお客さまの代わりに行うサービスが何度も検討されてきましたが、実際にサービスリリースまで至ったものはありませんでした。そんな中での「メルカリあとよろ便」は、メルカリとしてとても大きい挑戦でしたし、プロダクトマネージャーとしても思い入れのあるものだったので、絶対にサービスとして世の中に提供したいという想いがありました。

オープンロジ・桐生：オープンロジとしても、一緒に取り組ませていただいて学んだことをプロダクトにどんどん反映させて、広くユーザーに使っていただけるサービスにしたいという想いがありました。また、Twitterでも意見をたくさんいただき、一気一憂しながらもプロダクト改善に直接生かすこともでき、本当に学びが大きかったです。

共通したカルチャーを持った2社だからこそできた取り組み

──では、2社での共同開発だからこその面白さについては改めてどう感じていますか？

@kirin：社内でよく話していたのが「オープンロジさんのカルチャーがメルカリに似ていている」ということです。オープンロジさんは「物流の未来を、動かす」というミッションを掲げているので、一緒に新しいサービスをつくることに本当に真剣でした。ひとつずつ小さいことにも向き合ってくれて、お客さまから問い合わせがあったときにも柔軟に対応いただきました。「お客さまの心理的／物理的ハードルになっている、“売れたあとに梱包・発送体験”をもっと楽に！」というコンセプトをベースに、サービス設計から、両社でチームとして一体感を持ってサービスを形にできたのが良かったです。

オープンロジ・桐生：両社とも「ここからは御社の担当」といった線引きをせずに、チームとして一体感を持って取り組めたことはとてもありがたかったですね。また、メルカリさん側の対応でも、ビジネスサイド・エンジニア・リーガルといった枠にとらわれることなく、一丸となってサービスをマネジメントいただけたことで、オープンロジとしても検討や提案がしやすかったのは大きかったです。

オープンロジ・相澤：通常、オープンロジで対応している一般的なEC物流とは違い、メルカリは「すべての商品が1点もの」というを特性のサービスだからこそ、様々なケースを想定した運用構築は難しかったですが、だからこそ面白かったですね。トライアンドエラーや判断を繰り返しながら、ここまでのスピード感と同じ熱量でオペレーションづくりを行える機会はなかなかないと思います。

@kirin：もちろん2社で協業しているからこそ難しい部分もありましたが、他にないサービスで参考になる事例も少ない中で「お客さまの対応の範囲」と「満足度の高い料金体系」については、合意に至るまでは膝を突き合わせた話し合いを重ねる必要があり、かんたんではなかったです。

@kodai_gr：一番感謝しているのは、本来はメルカリがやらなければならないオペレーションの一部を、オープンロジさんが引き受けていただいたことです。オペレーションの特性上、メルカリ側で対応することがどうしても難しい部分があり、そこをオープンロジさんに引き受けていただけけなかったら、オペレーションが回らずサービスが継続できない…なんてもことになったかもしれません。　

オープンロジ・桐生：何度か「本当にできませんか？」というやりとりもありましたよね。バチバチまで詰めあってから、「よし、やろう！」と受け止めました（笑）。　

@kodai_gr：外部の企業様ではなく、同じプロジェクトの一員として、遠慮なしで熱く相談させていただきました（笑）！

「あとよろ便」で得た経験を次のプロダクトに

──ここまでサービス構築の話をしてきましたが、今だから言える「ここはもうちょっとうまくできたのでは…」と思うことは？

@kirin：お互いのシステムが、複雑なアーキテクチャになってしまったと思っています。基本的にはメルカリ側がオープンロジさんのAPIを利用する形になっていて、メルカリ側の実装・作業にプロジェクトの進捗が依存する形になってしまいました。「両社のエンジニアが開発し合えるような仕組みにしたら、二倍速にできたのでは？」とは今だから思います。

また、「最低ラインのミニマム機能」が本当にミニマムすぎて、使えるといえば使えるのだけど、使いやすくはないという結果になってしまいました。これまでメルカリが外部にAPI提供したことがなかったことと、実証実験を早くして学びたいという考えがあったため、「最低ラインのミニマム」で進めたのですが、それが結果としてイレギュラーな仕組みを生みやすくしてしまったのかもしれません。

オープンロジ・桐生：イレギュラーをうまくパターン化はできていた部分もあると思いますが、ソフト面とハード面の両方でバランスよく改善しなければならない部分については、もっとブラッシュアップしていきたかったという思いは正直あります。

@kirin：メルカリとしては、保管期間を延ばす機能や、複数回利用機能など、「プロダクトとしての魅力向上機能」と「UXにおける負荷の軽減機能」の実装バランスを考えるのは、限られたリソースと優先順位づけの中での難しさがありました。お客様に魅力的と思ってもらうプロダクトにするために、使う前と使った後の体験の改善について考えることと、プロジェクト自体の推進を別々にすべきだったかなというのは反省点ですね。

@kodai_gr：「出品をしたことがないお客さまに使ってもらえるサービス」をコンセプトで始まったけど、「また利用したいというお客さまに対してのサービス」としての観点も必要になってたのかもしれませんね…。

@kirin：「あとよろメルカリ便」はサービス終了となってしまいましたが、このプロジェクトで経験したことを学びにして、お客さまの出品・販売体験をより良くするサービスの提案に引き続き挑戦していきたいと考えています。

オープンロジ・相澤：今回の協業ではスタートからサービス終了まで、一連のサービスライフサイクルを経験させていただき、とてもたくさんの学びがあり、メルカリさんには本当に感謝しかありません。また、ご一緒できるような機会をオープンロジからも提案していきたいと思ってます！