10X×広島の老舗スーパー「フレスタ」システム全面刷新の裏側

2024年4月。10Xは、以前よりStailerを活用いただいていた広島の老舗スーパー「フレスタ」と協力し、フレスタが運用するネットスーパー「エブリデイフレスタ」のシステムを全面的にStailerに切り替えるという大規模プロジェクトの完了を発表しました。

https://10x.co.jp/news/fresta-renewal/

規模感も、開発期間も、開発内容も、10Xにとって初の試みだらけだったこのプロジェクト。どんな困難があったのか。また、どうやって乗り越えてきたのか。無事にリリースできた秘訣はなんだったのかーー。

2年の月日をかけて挑戦を続けてきた、フレスタリプレイスプロジェクトのメンバーに話を伺いました。

様々な職種のメンバーでプロジェクトチームを結成

ーー10Xとしても類をみない、大規模プロジェクトとなったフレスタリプレイスプロジェクト。期間や予算はもちろん、関わった人数もこれまで経験がない規模だったと聞いています。まずは、みなさんの本プロジェクトにおける役割を教えていただけますか？

松本：このメンバーでは私が一番昔から関わってきました。プロダクトマネージャーとして、このプロジェクトが本格稼働する少し前の2022年3月から関わりはじめました。店舗型からセンター型に移行するにあたって、どのような開発が必要か、そのためにどのくらいの予算や期間が必要になるか、10Xとしても初めての経験で検討がつきませんでした。そのために、まず最初に約1ヶ月現地に赴いて調査をしましたね。

石田：松本さんの次にこのプロジェクトにジョインしたのが私です。2022年5月に、ソフトウェアエンジニアとして関わり始めました。松本さんと一緒に現地調査をして、見積もりや要件定義を考えましたね。

八木：私は石田さんの次、2022年8月にプロダクトデザイナーとして関わり始めました。私がジョインしたときには、松本さんと石田さんが作った要件定義がありました。でも、詳細な仕様までは決まっていなかったので、どこからどう開発するかを検討しました。

吉開：その次が私ですね。2022年10月から、プロジェクトオーナー兼プロダクトマネージャーとしてジョインしました。私の時点では、何を作るかざっくり整理されていたので、本格的に要件定義の作成をスタートしました。仕様書を詰めたり、スケジュールを調整・合意したり、他チームと連携したりと、プロジェクトオーナーとしての業務がメインでしたね。

三宅：私がジョインしたのは吉開さんと同時期です。ソフトウェアエンジニアとして、モバイルアプリの開発からWebの開発まで、様々な開発に携わりました。

宮川：私はQAエンジニアとして、2023年4月から参加しました。ジョインした前半は作ったものが仕様書通りに動くかの確認を。後半は、ユーザーにとって本当に使いやすい機能かどうか、仕様書を越えてテストを行っていました。

インタビュー風景

「センター型」や「電話注文」……10X初の試みだらけのプロジェクト

ーーでは、フレスタのリプレイスプロジェクトについて詳しく教えてください。まず、どのような開発スケジュールだったのでしょうか。

松本：10Xとフレスタさんとの関係は、2020年の秋まで遡ります。最初は、ネットスーパーを利用するお客さま向けのモバイルアプリの提供からスタートしました。ただ、ネットスーパーの需要拡大によるさらなる事業成長を見込んでいること、事業成長のためには業務システムの刷新・改善が不可欠だったことから、「いずれStailerに全面刷新したい」という要望は当初からいただいていました。

2022年の4月にリプレイスプロジェクトが発足。そこから2年後の、2024年4月にプロジェクトが完了し、4月6日からリプレイス後のネット注文がスタートしました。

ーーそもそも、これまでのStailerと今回のリプレイスで開発したものは、どのような違いがあるのでしょうか。

松本：大きな違いは、「店舗型」と「センター型」です。店舗型とは、スーパーの各店舗から商品を配送する、ネットスーパーの仕組みのこと。一方センター型とは、ネットスーパー専用の倉庫から配送する仕組みのことです。これまでのStailerは前者、今回リプレイスで開発したものは後者になります。

吉開：店舗型とセンター型では、1日の配送量、配送エリア、在庫管理、スタッフの人数や稼働時間帯などいろんなことが異なるんです。例えば、店舗型だと、店舗に訪れるお客さまとネットスーパーを利用するお客さまとで在庫を共有し合います。一方で、センター型はネットスーパー利用者の在庫のみを管理しています。ただ、店舗よりも幅広いエリアに配送するので、1日に配送する量は店舗型の比ではありません。このように、そもそもの業務フローや取り扱う量が異なるため、必要な機能やオペレーションが大きく異なります。

松本：もう一点、今回のリプレイスには、フレスタさんの特徴も大きく影響しています。フレスタさんは、広島県を中心に展開する老舗スーパーです。ネットスーパーも2001年から参入していて、20年以上の歴史があります。お客さまの年代は幅広く、インターネットやアプリを使えない方も多くいらっしゃる。スマートフォンやPCからの注文だけでなく、電話やカタログを利用した注文も多いのが特徴でした。

リプレイスをした後も、長年フレスタさんを支えてきたお客さまに、負担なくネットスーパーを使ってほしい。そのためには、一般的な注文方法だけでなく、電話やカタログ注文も可能なシステムを導入する必要がありました。

ーー電話やカタログ注文について、もう少し詳しく教えていただけますか。

三宅：まず電話注文について。フレスタさんではもともと、IVR（自動音声応答システム）を利用した電話注文を受け付けていました。これまでのStailerには電話注文の機能はなかったから、リプレイスプロジェクトはまずIVRによるお客様注文体験の理解から行いましたね。

実際の開発では、電話のプッシュを利用して、会員番号や商品番号を入力すると注文できる機能を実装しました。

石田：カタログ注文も電話注文と同様に、Stailerでは対応したことのない機能でした。まず、カタログを作って紙に印刷して、お客さまのご自宅に配送する仕組み作りから始めましたね。

松本：どちらも10Xでは作ったことのない機能だったのはもちろん、個人的にも「電話やカタログ注文って、どんなシーンで行うんだろう？」とイメージがつきませんでした。でも、利用者層や、利用シーンをイメージできないと、ユーザーが使いやすい機能は作れません。だから、フレスタさんにお話を伺ったり、過去に行ったユーザーインタビューの記録を確認したりしながら、仕様書を作成していきました。

期間も、人数もギリギリ。それでも、スケジュール通りに開発が進んだワケ

ーー利用者層も、利用シーンも、Stailerとは大きく異なる開発だったのですね。プロジェクト発足から開発まで2年の期間がありましたが、特に大変だったことを教えていただけますか。

三宅：大変なことはたくさんあるのですが、強いてひとつあげるとしたら、仕様書の作成ですかね……。

松本：スケジュールの関係上、2022年10月から2023年3月にかけて、40機能分という膨大な仕様書を完成させなければいけなかったんです。

今回特に大変だった要因の1つが、「リプレイス」が目的だったこと。ゼロからの開発なら、できるところから開発して、少しずつリリースしながら試行錯誤できます。でも今回は、すでにあるシステムのリプレイスです。リリース直後から、これまでと同等か、それ以上のサービスが求められています。それに応えるためには、通常よりも精度高く仕様書を作り込まなくてはいけませんでした。

吉開　時間やリソースが限られている中で、クオリティはこれまでと同等以上のものを担保しなければならない。シンプルにきつかったですね（笑）。

ーーそれでも、リプレイスプロジェクトが成功したということは、期限内に高クオリティの仕様書を完成させたということですよね。それができた理由を教えていただけますか。

宮川：物理的にはきつかったけど、心理的にはきつくなかったんですよ。それは、私たちプロジェクトチームはもちろん、別チームのメンバーや、フレスタさんも一丸となってプロジェクトを進められたからだと思っています。

松本：例えばプロジェクトチームでは、2023年1月から毎日のように朝会をしていました。そこに課題を持ち込んで、それぞれの知識や経験を持ち寄って解決策を考える。朝会だけで解決したものもたくさんあるんですよ！短い時間でも、毎日コミュニケーションが取れたのは良かったですね。

吉開：それでも、プロジェクトチームメンバーだけでは開発が回らなくて。社内の他チームの方にもかなり協力していただきました。ただ、他チームは私たちとは別のミッションを持っています。その貴重な時間をいただいて私たちのプロジェクトに協力してもらう意義やメリットは、丁寧に説明して同じ方向を向いてもらえるように努力しましたね。

宮川：例えば、テストは私一人ではなく、他チームのテストエンジニアにも手伝ってもらいました。40個ある機能を限られた時間で検証するのはかなりきつかったけど、私だけでなくみんなで苦労した。今振り返っても、物理的にはきつかったけど、心理的にはきつくなかった、という感想ですね。

吉開：フレスタさんにもたくさん協力いただきましたよね。何度も話に出ているように、今回のプロジェクトは10Xとしても初めての事だらけでした。でも、分からないことは提案できないし、機能も作れません。

もともと利用していたシステムを触らせていただいたり、既存のオペレーションを詳しく教えていただいたり。フレスタさんの協力があったからこそ、スケジュール通りに進みました。

松本：日々の業務で忙しいはずなのに、朝質問したことは、昼には返ってくるんですよ。「一緒にいいものを作りたい！」という想いが伝わってきて、私たちも嬉しかったですね。

プロジェクトメンバーでの懇親会の風景

リリース当日に「何も起こさない」のが、プロジェクト成功の鍵

ーーいくつもの困難を乗り越えて、2024年4月に無事にリリースとなりました。リリース前後で印象に残っているエピソードを教えていただけますか。

八木：機能が出揃ったタイミングからリリースまでの間、毎月のように「プロダクトを触ろう会」をしていました。仕様書通りに作った機能を、みんなでパートナーやお客さま目線に立って触ってみる。例え仕様書通りだとしても、実際に触ってみると「お客さまは使いづらいかも？」と思うこともあります。その場合は、課題としてみんなで議論し、解決策を考える。リリースまで毎月このサイクルで課題解決を行えたから、よりパートナーやお客さまに寄り添ったシステムが作れたと思っています。

プロダクトを触ろう会のアジェンダ

ーーでは、切り替えがスタートした2024年4月6日前後の話も聞かせていただけますか。

吉開：4月6日にリプレイス後のシステムでの注文がスタートするため、前日の4月5日から私、松本さん、宮川さんの3人で現地で見守り対応をしていました。ただ見守ると言っても、倉庫の朝はとても早く……。朝4時から業務が開始するので、3時には現地入りして、システムがちゃんと可動しているか、スタッフの方々がオペレーションで困っていないかを確認していましたね。

三宅：当日の朝7時に、現地メンバーから「今すぐ直してほしいものがある」と修正依頼の電話がかかってきたのを覚えています（笑）。その場で修正して、すぐにリリースして。おかげで、実際の配送には影響がありませんでした。

吉開：私は、「スタート時にトラブルを一切起こさない。そのような気概で仕事をする」のが大事だと思っています。もし初回にトラブルがあった場合、その後の工数が大きく変わってくる。信頼も失ってしまうかもしれません。そうならないためにも、私たちプロジェクトメンバーがフレスタさんよりも常に先回りして確認を行い、万が一不備があったら本格稼働する前に軌道修正を行う。それを全員で徹底していました。

細かい部分で予想外のことはありましたが、リリース当日から滞りなく全ての注文に対応できたのは、この体制があったからだと思っています。

倉庫にてオペレーションのチェック

初回の稼働確認後の1枚

Stailerはより、一つ一つのパートナーに合わせた提案ができるようになる

ーー改めて無事リプレイスが完了した今、この大規模プロジェクトが成功した理由を教えてください。

宮川：いちプロジェクトメンバーとしては、プロジェクトオーナーの吉開さんが「タスク」ではなく「ゴール」の話をしてくれたのが、理由のひとつだと思いますね。「プロジェクトのゴールはどこか」「そのために、今月末はどうなっていたいか」と逆算して考えていくから、忙しい中でもぶれることなく、自分のやるべきことに取り組めました。

吉開：10Xのメンバーは、宮川さんのような人たちばかりだからプロジェクトも順調に進むんですよ……（笑）。成功した理由は、やっぱりチーム一丸となってプロジェクトを進められたから、ですね。チームというのは、プロジェクトチームはもちろん、協力してくれた他チームのメンバー、フレスタさんも含みます。

ーーありがとうございます。10Xとしても、大きな挑戦となったフレスタリプレイスプロジェクト。今後、どのような展開を考えていますか。

吉開：今回の開発で、これまでのStailerでは対応していなかった「センター型」や「電話・カタログ注文」も活用できるようになりました。この仕組みはフレスタさんだけでなく、他のスーパーでも横展開できるはず。これまで以上に、そのスーパーにあった仕組みを提案していきたいですね。

これからもエブリデイフレスタを支えます