【ポーラ・オルビスHD】大手化粧品ブランドがMuleSoftと挑む「おもてなしの進化」

Key Takeaways

• “初めまして”をなくす接客基盤の発想
• 巨大基幹を延命でなく進化させる
• 接客DXはデータ統合で一変する
• 選定基準は機能より“手の内化”
• 短納期でも変化に強い設計はできる

ポーラ・オルビスホールディングスは、2029年に創業100周年を迎える化粧品・ビューティブランド企業グループ。基幹ブランドのポーラは顧客体験の刷新に向けて、「MuleSoft」を活用し、事業横断の「店頭カルテ」の開発や肥大化した基幹システムのスリム化、開発の内製化体制構築を同時に進めました。

プロジェクトをリードした同社グループデジタルソリューションセンター（GDSC）の田端晴美・SCMシステム企画Ⅰチーム課長と、望月雅敏・CXシステム企画Ⅱチームに、複数課題を同時に解決する手段としてMuleSoftに着目した理由と成果を聞きました。

おもてなしを支えるための新システムと新体制

──まず、2人が所属する「グループデジタルソリューションセンター（GDSC）」の役割を教えてください。

田端：当社は1929年創業のポーラ、1987年創業のオルビスを中心に「美と健康」に関わる事業を展開しており、多様なブランドとチャネルで事業を拡大しています。

ホールディングス傘下のポーラやオルビスなど各事業会社がそれぞれ情報システム部門を設置していましたが、それらを集約して2022年4月に発足したのがGDSCです。合理化に加えて、グループシナジーを活かしたDXの実行、そしてデジタルサービスによる新価値創造を手がけています。

新価値創造とは、パートナーのITベンダーに依存することなく、テクノロジーを活用して新しいサービスを世の中に提供すること。「何のためにGDSCを組織したのか」を問い直し、いわゆる「攻めのIT」を意識した動きを加速しているところです。

──その当時の大きな課題は何だったのでしょうか。

望月： コロナ禍後、お客様の来店が戻りにくい状況の中で、おもてなしを進化させるための仕組みが必要だと考えていましたが、その基盤となる顧客情報や接客プロセスのデータが十分に整っていませんでした。

また、保有しているデータの所在にも課題がありました。ポーラには路面店、百貨店、ECと複数の販売チャネルがあり、それぞれの事業部門が独立したシステムを持っています。すると初めて訪れたチャネルでは、ポーラ全体として見るとリピーターなのに部門にとっては「初めまして」になってしまう。

中期経営計画で「One POLA」を掲げ、チャネルシームレスなブランド体験によりLTV（Life Time Value）を向上させるなど、価値提供への転換に取り組む中で、この状態からの脱却は重要なテーマでした。

田端：そこで2023年、全事業のお客様を1つにつなげる統合顧客基盤を構築。そのうえで顧客基盤を活用するアプリケーションとして、事業横断の店頭接客サポートシステム（店頭カルテ）の開発を進め、事業の垣根を越えた店頭・デジタル双方の体験価値向上と、蓄積した顧客・接客情報を活かした分析の高度化を目指すことにしました。

それと並行して、IT課題の解決に向けてAPI基盤による基幹システムの「スリム化」も進めました。

複雑化・肥大化した基幹システムをAPIでスリム化

──スリム化が必要だった基幹システムは、どのような状態だったのでしょうか。

望月：主力事業の路面店チャネルを支える基幹システムは、約600画面、バッチが約4000本ある非常に大きな仕組みです。2008年から稼働しており、内外環境の変化に対応するためにエンハンスを繰り返し、複雑化かつ肥大化していました。

POSや店頭対応など周辺システムとの情報連携も年々増加し、何か改修を入れようとすると影響範囲が広く、QCD（品質・コスト・納期）の難易度がどんどん上がっていく状況でした。

田端：デジタルシフトの加速に向けて、基幹システムがボトルネックになっているのは明らかでしたが、刷新するには巨大すぎてコストメリットも見通しにくい。課題であり続けているのに手をつけられないという、悩ましい状態が長年にわたって続いていたのです。

──そこから脱却する手段として、どのようにしてAPI連携にたどり着いたのですか。

望月： 基幹システムは、販売・物流・手数料計算といった業務を一体で動かすことを前提に構築してきたため、機能同士が強固に結びついた状態でした。

そのため、部分的な変更でも幅広い改修が必要となり、開発スピードを阻む要因になっていました。これを機に、業務を切り離して再構成できる仕組みを模索しました。

田端：ただ、物理的にシステムを分けるのはコスト的にも技術的にも難しい。時間も限られている。そこで発想を変えて、基幹システムはそのままに、お客様の体験価値を上げるサービスを、スピード感を持って開発できる構造を目指しました。

基幹システムから必要な機能を小さく切り出して「部品化」し、API基盤（部品ソケット）を介して接続できるようにする。こうすれば、新しいサービスとの接続が容易になり、開発スピードが向上すると考えました。

──API連携の数ある手段の中から、なぜMuleSoftを選定していただいたのでしょうか。

田端：単に部品化を実現するだけでなく、GDSCのミッションに照らして働き方を変えていかなければなりませんでした。今まで通りパートナーベンダーにお任せするのではなく、システムを自分たちの「手の内」に置いて対応スピードを上げたい。内製化に向けて、自分たちで開発・管理がしやすいという点で、MuleSoftがベストだと判断しました。

望月：「AWS API Gateway」など他の選択肢ではいろいろなパーツを組み合わせて運用する必要がある一方で、MuleSoftなら開発から管理まで1つのツールで完結できる。そのオールインワンの強みも決め手でした。

田端：ゲートウェイ機能だけならコストを抑えられる選択肢もあるため、経営陣からは「MuleSoftでなくてもよいのでは？」という声もありましたが、MuleSoftであるべき理由を3つ挙げて理解を得ました。

1つ目は、グループとして知見を蓄積できるという考え方。グループ会社のオルビスではAWS API Gatewayを採用し、管理機能や開発ルールを手組みで構築する方式を採用しています。ポーラではそれとは異なるアプローチをとることで、比較検討が可能になり、グループとしての方向性を考える材料になります。

2つ目は、店頭カルテのプロジェクト期間がタイトな中で、セキュリティや運用監視の機能をゼロから作っていては間に合わないという現実。MuleSoftにはその機能が搭載されていますから。

そして3つ目が、内製化を前提に考えた時、ローコード開発によって高度なスキルがなくても内製ができる可能性でした。

6500万円のコスト削減効果と、6カ月の期間短縮

──導入プロジェクトはどのように進めましたか。

田端：MuleSoftの導入は、パートナーの選定から始めました。Salesforceから紹介いただいた3社を比較し、ITに強いコンサルティング会社の協力を得ることに。私たちはUI/UXに注力し、周辺システムとのデータのやり取りやバックエンドのデータ処理はMuleSoftに委ねることで、1年弱という短納期で開発できました。

MuleSoftの3層構造（＊）も貢献しました。ローンチ直前にフロント側の要件が変わったのですが、3層構造の利点を活かして1本のAPIを追加するだけで対応できた。その後も継続的な改修が入っていますが、再利用性の特性を活かして柔軟に対応できています。

^{＊MuleSoftの推奨するAPI設計手法「API-led Connectivity」では、APIをExperience API（利用者向け）、Process API（ビジネスロジック）、System API（データソース接続）の3層に分けて設計する。各層が疎結合であるため、ある層の変更が他の層に波及しにくく、再利用性と開発スピードの両立が可能になる。}

一方で、MuleSoftが各周辺システムにアクセスすることで既存システムのパフォーマンスが落ちないかという検証は、泥臭い作業の連続でした。MuleSoftを入れたからといって全てが解決するわけではありません。ただ、MuleSoftを使えば、パフォーマンスやどこにボトルネックがあるかを把握しやすいので、すぐに問題解決につながりました。

望月：基幹システムのMuleSoftによる部品化は、できれば内製したかったのですが、店頭カルテの開発と同時並行で手が回らず、日ごろ保守・開発をしていただいているベンダーに依頼しました。在庫のリアルタイム照会や受注状況の確認、販売員実績の取得など将来のユースケースを想像しながら10機能ほど先行して部品化しました。

──定量的な効果について教えてください。

田端：MuleSoftがなかった場合と比較した試算では、店頭カルテの開発では約6か月、基幹システムのスリム化では約3か月の期間短縮効果があったと見ています。

コスト面では、7本のAPIを2つのシステムで再利用したことによる効果が約3500万円。6本のAPIを内製化したことによる外注費の低減が約3000万円。合わせて約6500万円の開発コストを抑制できたと見ています。

C4E体制と内製化を推進し、初心者マークを外したい

──今後の展望をお聞かせください。

田端：まずC4E体制の構築と内製化の推進です（＊）。MuleSoft導入にあたり、約2.5か月かけて20人ほどにトレーニングを実施しましたが、PMや要件調整が主業務のメンバーが中心だったこともあり、正直なところ大半が脱落しました。

^{＊C4E（Center for Enablement）は、IT運用モデルの転換を推進する部門横断型チーム。再利用可能なAPIやテンプレートなどの資産を整備・公開し、事業部門がIT部門に頼ることなく自立的に資産を活用できるよう支援する。名称が似ているCoE（Center of Excellence）は専門知識とノウハウを一元化する点が特徴だが、情報が閉じられやすく、開発者のボトルネックになるという課題を抱えている。C4Eはこの課題を解消するアプローチ。}

習得できたメンバー数人が内製開発を担い、6本のAPIを構築して本番稼働させていますが、体制としてはまだ十分ではないため強化していきます。まずはMuleSoftの活用推進のためのC4E体制を強靭にし、内製化率もあげていければと考えています。

MuleSoftはAIによる開発効率化が進んでいて、日本語で入力するとコードを書いてくれる機能もあります。最新の機能を活用して、できる限り内製化のハードルを下げていきたいです。

望月： 他社の事例を見ると、すでにAIエージェントとMuleSoftを連携させている先進企業もあります。私たちはまだ“初心者マーク”の段階ですが、そこを脱し、手の内化を一層進めるための伴走支援に期待しています。

執筆：加藤学宏
撮影：大橋友樹
取材・編集：木村剛士