アーカイブ動画
WEBと店舗の連携で顧客体験の向上を目指すOMOプロジェクトの開発舞台裏
株式会社ポーラ・オルビスホールディングス
グループデジタルソリューションセンター
事業管理システム企画チームリーダー 望月 雅敏氏
最初に登壇したのは、ポーラ・オルビスホールディングスの望月雅敏氏だ。望月氏は、SIerで金融系システムの開発を経てポーラに入社後、主力事業の基幹システムエンハンス開発を軸に、さまざまな業務システムの導入開発を経て、現在はポーラ・オルビスホールディングスのグループデジタルソリューションセンター・事業管理システム企画チームにて、グループ会社であるポーラの基幹システム全般の運用開発を管掌している。
2029年に創業100周年を迎えるポーラ・オルビスホールディングスは、「POLA（株式会社ポーラ）」や「ORBIS（オルビス株式会社）」といったビューティーブランド企業グループで、お客様との直接的つながりを核としたダイレクトセリングを強みとしている。
顧客と直接やり取りすることで得た情報を、研究開発拠点が持つデータなどと組み合わせることで、一人ひとりの顧客にマッチした商品や肌のケア方法を提供する。「プロダクト、お客様、どちらも当社の強み」と、望月氏は胸を張る。
グループの主観ブランドであるポーラでは、国内シェアナンバーワンを誇るBtoB事業のホテルアメニティの他、エンドユーザー向けに主力事業であるサロン、百貨店、オンラインストアと3つの販売チャネルを持ち、それぞれが基幹システムを保有している。
そのため、同じ顧客であってもIDが異なる状態となっていた。そこで、これまで通りダイレクトセリングを基盤としながらも、3つの販売チャネルがシームレスに繋がるOMO （Online Merges with Offline）戦略を実行する中で、新たなデジタルプラットフォームを開発。2023年4月から稼働している。
「新たなデジタルプラットフォームの開設に向けては、IDの共通化、アプリの統合など4つのDXプロジェクトが同時に進んでいました」（望月氏）
IDの共通化が実現すれば、どのチャネルで購入しても同じ顧客だと認識できるようになる。その結果、チャネルを横断しての顧客データの蓄積やコミュニケーションが活発になり、「お客様の買い回りが容易になることをはじめ、お客さま一人ひとりに最上のおもてなしを届けることを目指す」と望月氏。ID共通化は各チャネルの基幹システムと常時連携する「統合顧客基盤」を配置することで、実現させた。
望月氏は4つのDXプロジェクトを示すとともに、改めて対象システム数やかかった工数なども紹介した。大規模プロジェクトであったため、多くの課題や壁にもぶつかることになった。
望月氏は「社内的にこれまでの概念にないプロジェクトを進めていくにあたり、事業・システムの両側面から多くの課題が山積した」と語った。
ピックアップした問題や課題の真因を追求し、プロジェクトを適切に進めていくための「事業とシステムの役割を明確化する」「4つのプロジェクトを横断するプロジェクト推進事務局が必要」という結論に至る。
そして、以下スライドで示されたA～E5つの取り組みを実施していく。まずAの体制明確化においては、各部の役割と担当者を明確化した。
Aの（体制明確化）実施においては、過去のサロン向け販売管理システム刷新プロジェクトにおいて、現場から使い方が分からないといった問い合わせが殺到した経緯を重視。
IT部門はシステム構築、マーケティング部門は顧客体験や業務検討、各事業部は教育推進を主管するといった具合に、各部門の役割を明確化した。
マスタースケジュールにおいても、各部門の役割に応じたフェーズごとのタスクを詳細化し各部の責任範囲を明らかにした。
Bの決定プロセスの明確化では、稼働判定までのプロセスを例示。マイルストーンを複数設けるとともに、あらかじめ何を・どの部門が・いつ・どのような状態であるかチェックを行うのかを明らかにした。
Cは、プロジェクト横断推進事務局設立に向けての取り組みである。対象となるシステムは20種以上、協力会社は10社以上といった規模で、当プロジェクトから新たに参画する会社も数社含まれた。そのためプロジェクトごとのスケジュールや会社間でシステム開発工程の呼び方が違うなど、ギャップが多数発生していた。望月氏は、各プロジェクトが合流するシステムテスト工程を見据え、各ギャップの整理も含めて、同事務局の設立理由を改めて述べた。
続いては、Dのシステムテスト推進である。ここではDのプロジェクト横断推進で設立した事務局が全体のスケジュールからテストケース策定、タスクの分類や管理、さらにはバックログの管理までリードした。
Dのシステムテスト推進では、毎日朝晩2回のミーティングに加え、週に一度の全体会議を設けることで、協力会社10社とのコミュニケーション醸成も努めた。
全体への伝え方はシンプルにし、込み入った情報の場合は個別にミーティングルームを設けるなど、望月氏は会議における工夫を紹介し、オンライン会議体の重要性を強調した。
そして最後のEは、システム移行である。20システムの移行タスクは350以上あり、それを20時間ほどで完了させる必要があったため、事前のタスク管理や指示の徹底に加え、万が一の事態が発生した際に備えるべく、コンチプランをいくつか用意した。
移行当日はデータの移行が長引くなどの状況が発生し、用意していたコンチプランの一つに切り替えることで、無事に新システムの稼働に至る。
望月氏は次のような展望を述べ、セッションを締めた。
「今後は顧客DXだけでなく、接客や営業といった販売現場のビジネスオペレーションも変革していきたいと考えています。今回のプロジェクトは序章であり、OMO戦略を遂行していくために、さまざまなプロジェクトにも取り組んでいきます」（望月氏）
EyesTechのリーディングカンパニーへ。JINSのグローバルOMOとアーキテクチャとは
株式会社 ジンズ
グローバルデジタル本部
ITデジタル部 佐藤 拓磨氏
続いて登壇したのは、ITコンサルティング会社を経て、JINSのデジタルサービス企画、ウェアラブルデバイス開発、グローバルITインフラ移行などをリード。現在は、ITアーキテクト・テックリードとして、システム全体の設計を担当している佐藤拓磨氏だ。
JINSでは、視力矯正用のメガネの他、花粉をカットしたり、保湿を担う機能性メガネも多く手がけるなど、世界一のアイウェアカンパニーを目指している。実際、国内で483店舗を展開する他、アジアを中心に海外にも積極的に店舗を展開。売上高でも国内トップクラスを誇る。
JINSではこれまで、アプリを使って自分好みのメガネをデザインする。購入したメガネの保証を電子サービス化する。このような各種デジタル戦略ならびに、実際のプロダクトやシステム開発を行ってきた。
コロナ禍を経た現在ではデジタルはあくまで手段であり、大きく6つのテーマで事業変革に取り組んでいる。その1つである「最高の顧客体験の実現」では、チャネル横断でシームレスなサービスの提供に取り組む。
その他のテーマ「クラウドネイティブなアーキテクチャへの刷新」では、CNCF（Cloud Native Computing Foundation）のロードマップを参考に、システム基盤とアジャイル開発による内製化という、大きく2つのポイントで推進している。佐藤氏は実際に取り入れている技術や環境の詳細、目指すべき姿も紹介した。
佐藤氏は「あくまで私の考えです」と前置きした上で、システム開発プロジェクトは規模や性質によりいくつかの種類に分けることができ、それぞれ特徴やポイントが異なることを指摘する。
その中から、要件の自由度が高いため要件管理が重要となってくる、特定のサービス企画を実現するプロジェクト、公式アプリの開発の勘所について詳しく述べた。
現在約1400万人の会員数を誇るJINSのアプリは、2017年にリリースされた。電子保証書など大きく6つのサービスからなる。
開発当初から「お客様のニーズはもちろん、ヒト・モノ・カネすべてを把握することが重要だが、それはとても困難だと考えていました」と佐藤氏。どのような内容を意識していたのかを語った。そして実現に向けては、「多段階ロケット計画（自称）を実行した」と、述べた。
多段階ロケット計画とは、段階的に計画を実行していく手法であり、JINSのシステム開発プロジェクトに重ねれば、起源は2014年に遡る。
JINS MEMEの発売やその後のデジタルサービスを見据え、統合ID（アカウント）の設計に着手した。なおJINS MEMEとは、鼻が当たる部分のセンサーを搭載したメガネ型ウェアラブル端末である。
その後は、UXの強化、ソーシャルアカウントとの連携、CRM基盤、カスタマーサポート基盤の構築など、まさに多段階でロケットを打ち上げていくように、順を追ってプロダクトやサービスを発射（ローンチ）していった。
佐藤氏は長年にわたるプロジェクト管理を通じて得たこと、逆に感じた課題、さらには生じたトラブルについても赤裸々に語った。
「理由はいろいろありましたが、主にはプロジェクトオーナーを務めていた代表取締役CEOから『お客様が本当に求めていることを考えきれていないのではないか』との厳しい意見をもらい、プロジェクトの進め方を根本的に見直すことになったためです」（佐藤氏）
当時はデザイン思考やカスタマージャーニーといったキーワードを軸に、UI/UXを意識する開発手法が主流であり、佐藤氏のチームでも取り入れていた。しかし、プロジェクトオーナーが首を縦に振るまで、多くの時間を要していたのだ。
コストは大幅にかかったが、結果としてより良いサービスになったと佐藤氏。一方で、もっと早い段階で改善サイクルを回せたかもしれないと、「どちらが正しかったのかは、今でも判断がついていません」と、正直な気持ちを述べた。
また、MVP（Minimum Viable Product）についても、考えられるきっかけになったと、振り返る。というのも、メガネは一度製造したら改修することが難しい物理的なプロダクトである。一方、デジタルサービスにおいては、開発の速さが求められるからだ。
「両方の思想の違いをうまく扱う必要があると感じていました」（佐藤氏）
続いては、一転してアーキテクチャ設計の重要性について述べた。
システムアーキテクチャやビジネスアーキテクチャなど、さまざまな表現がされているアーキテクチャだが、JINSではさまざまなドメインをアーキテクチャと広義で定義している。
左側が技術スタックや開発環境領域であり、これらのアーキテクチャに右側のいわゆるビジネス領域が、横断的に携わるシステムアーキテクチャの考え方をしている。
「アーキテクチャを考える理由は、ビジネスに対してシステム設計や開発活動がマイナスの影響を与えないようにするためです」と佐藤氏。具体的にはシステムが変化したり、複雑化したりすることで、ビジネスの変化に対応できないといった事象を防ぐためだ。
佐藤氏は、パブリッククラウドの活用についても言及した。JINSでは2014年から利用しており、「JINSの事業戦略実現に適しているからです」と理由を述べた。
また、パブリッククラウドを活用する具体的なメリットも紹介。中でも②のシステムコストが変動型であることは大きいと語った。
一方で、システムが簡単に構築できる反面、事業に寄与しないシステムが乱立するマイナス面があることから、「定期的に棚卸しをする必要があります」と、補足した。
佐藤氏は続いて「アーキテクチャのデザインとプロジェクトのデザインを解いているユニークな本」と、プロジェクト管理とアーキテクチャ設計の連携に関する参考本を紹介した。
最後に佐藤氏は、技術負債の管理について言及した。完全に防ぐことはできないが、なぜそのような意思決定をしたのか。その結果、どのような設計やアーキテクチャとなったのか。
いわゆる「ADR（Architecture Decision Record）」を作成することが重要であり、「JINSもまさに今、チャレンジしているところです」と述べ、セッションを終えた。
大規模プロダクトにおける組織作りで、加速度的なプロダクトの成長を実現し続ける
株式会社リクルート
ビューティー領域エンジニアリング部長 中里 直人氏
続いてはWebサービス会社でアプリ開発に従事した後、2017年にリクルートに入社。ホットペッパービューティーのモバイル開発を経て、現在はビューティー領域のエンジニアリング部長を務める中里直人氏が登壇した。
ヘアサロンやリラクゼーションサロンといった、ビューティー系サロンの検索・予約サービスを提供するホットペッパービューティー。2007年にWebサービスがスタートし、現在は年間1.8億回予約される国内最大級規模のサービスに成長している。
しかし、サービスローンチから10年以上経った頃から、システムがレガシーで複雑な状態に陥っていく。携わるエンジニアの数も150名以上になり、さらなる成長に向けて取り組みたいものの、莫大な工数がかかってしまう。学習コストの高さからエンジニアが活躍するまでの時間がかかるといった課題も生じるようになっていた。
そこで当初は外部に開発は委託していたが、2012年頃よりエンジニアを採用し内製化を進めた。また、その他の技術的な改善にも積極的に投資していく。その中から中里氏は3つの事例を紹介した。
まずは、「モバイルアプリのリプレイス」である。アプリの提供を開始したのは、Webサービスのローンチから3年経った2010年であった。
以降、アプリの利用者が増えるにつれ、デッドコードが多いなど技術負債が溜まり、開発スピードが鈍化。2016～2018年にかけてリプレイスが行われた。
コードはJavaからSwift／Kotlinに変更し、コード量も4割ほど削減。人材要件や開発プロセスも見直すことで、高速な開発体制が整備された。
開発体制が整備されたことで、2018年から「モバイルアプリ向けAPIのリプレイス」にも取り組んだ。そして、こちらのプロジェクトも2021年にすべてのAPIのリプレイスが完了した。BFF（Backends For Frontends）アーキテクチャを設置するなど、CVRの大きな向上に寄与する。
2022年からは、「Webサイトのリアーキテクチャ」にも着手する。それまでは別々のシステムであった構成を、バックエンドのAPIを共通化することで仕様を統一させた。
要件の検討や問い合わせ対応の工数を削減するとともに、これからの開発においても快適となり得るアーキテクチャの基礎を作り上げた。3つの取り組みを振り返り、中里氏は次のように手応えを口にした。
「内製化が進んだことで、アジャイルで柔軟な開発が進められるようになりました。新規メンバーもすぐに活躍できるようになり、エンジニアが増えても開発スピードも落ちなくなりました」（中里氏）
続いて中里氏は、技術的改善に投資し続けるための仕組みに対して、どのような考えや指標で進めていったのか、5つのポイントを紹介した。
まずはベースとなる考え方として、技術的改善の目的はプロダクト価値の最大化であり、今後の開発スピードを向上させるための投資であると位置付けた。
その上で技術的改善を行った結果、プロダクトの価値や売上に短期もしくは長期で繋がることを常に考えており、長期的にも繋がらない場合には、考え直すことを繰り返すことで目的設定を行っていった。
方向性においては、再利用性の高いAPIベースのアーキテクチャ志向とし、市場変化に応じてスピーディーにプロダクトを進化させるための土台である、と考えた。
「ターゲットとスコープの選定が必要」と中里氏は語る。プロダクト価値向上に最も繋がるのはどこかを考えた上で、選定していくことが大事だと続けた。
一方、スコープの選定においてはあまりに大きく設定するとコントロールが難しかったり、プロジェクトを終わらせることも同じく難しくなってしまうため、コントロール可能な範囲とする。
あるいは分割することを考慮した。
また、「短期的に成果を得ることを大事にするQuick Winとの考えも重要視しています」と、続けた。というのも、プロジェクトは取り組んでいるうちに市場の変化やメンバーの脱退など、状況は変化するからだ。
そのため、「スタートとゴールを設定しておくだけではリスクが高い」と、中里氏は指摘する。そこで、中継地を設けることとした。
中継地はステークホルダーに対するマイルストーン的な意味合いもあるし、仮にプロジェクトが頓挫した場合でも、中継地までの成果は得られるメリットもあるからだ。
「ただし、中継地は多く設けることは当然コストがよりかかることになりますので、逆に効率が悪くなる場合もあることを考慮しながら進めることも重要です」（中里氏）
続いて中里氏は、2つの技術的改善の評価方法を紹介した。技術的改善により削減できた工数をそのままコスト削減に繋げる「コストアプローチ」、削減できた工数を再投資し新たな価値に繋げる「インカムアプローチ」である。
「前者は悲観的な予測として、後者を楽観的な予測として活用しています」とも続けた。
先述した3つのプロダクトの改善事例でも、実際にこのようなコスト計算が行われた。一方で計算に要するコストも高いため、普段は全体の2～3割の工数を改善活動に充てるとともに、半年ごとに改善活動を評価し工数を得る流れとしているという。
最後は組織と文化についてである。外部に開発を委託するとどうしてもシステムがブラックボックス化したり、市場の急激な変化に対応できなかったりするため、内製化を進めていった理由を中里氏は改めて述べた。
そして内製化を進める際には、技術的改善への投資と相関しながら、プラスとなるサイクルを回していくことが重要だと続けた。例えば、内製化することで課題が特定され、技術的改善の投資がさらに進むといった具合だ。
ただし、このサイクルを回すためには「エンジニアもビジネスやプロダクトの理解を深めることが重要です」と中里氏は語る。
そこで、エンジニアとビジネスサイドが普段からディスカッションをしたり、定期的にワークショップなどを開催している。
「エンジニアも企画組織も同じビジネス目標に対して会話できるという状態を作っています」（中里氏）
中里氏は最後に大規模プロダクトの技術的改善のポイントをまとめ、次のように述べてセッションを締めた。
「個人的には、やりたいことの半分もできてないのが正直なところです。先ほど説明したように技術的改善と組織的成長のループを回し続けることで、加速度的なプロダクトの成長を実現し続けたいと考えています」（中里氏）
【Q＆A】参加者からの質問に登壇者が回答
セッション後は、イベントを聴講した参加者からの質問に登壇者が回答した。各社ごとに抜粋して紹介する。
●ポーラ・オルビスホールディングス
Q．システム間連携の仕組みはどの部署が担当し、どのように進めていったのか？
望月：現行で活用しているアーキテクチャを軸に、すべて我々IT部門が定め、構築しました。実装は協力会社にお願いしています。
Q．稼働判定の回数は元々決まっていたのか？
望月：以前はリリース直前に判定するなど、決まっていませんでした。そこで同じ轍を踏まないために、長いスパンで目標を設けてステップを踏むフローを定めました。
Q．50人が参加するZoom会議は、どのように円滑に進めたのか？
望月：バックログをチケット管理することで、遅延が発生しているものを中心に拾っていくような場としました。その上で個別に相談したい事項があれば、気軽にミーティングを行えるようオンライン会議を設けたり、必要に応じて対面で行ったりなどの工夫をしました。
Q．移行プランは誰がどのような流れで計画したのか？
望月：IT部門で計画しました。まずは色々なシナリオのパターンを想定し、一度出し切りました。そこから、大量データの移行が遅れた際のプロセスなどに絞っていくことで、決めていきました。
Q．推進事務局を設ける際に体制づくりで工夫したことは？
望月：マネジメントするだけの組織にはならないように、担当に近いメンバーを加え、利用部門にしっかりとアプローチし、より具体的な話ができる体制づくりを心がけました。
●JINS
Q．JINSメンバーのドライブ力とは？
佐藤：プロジェクトの推進スキルです。その他サービス企画など、サービスプロセスを言語化して設計まで繋ぐことができる、上流工程のスキルを意味しています。
Q．プロダクトオーナーとのギャップについての詳細を伺いたい
佐藤：サービスの方向性は一致していましたが、スタート時のサービスの数や内容でギャップがありました。具体的には視座の違いで、メンバーはまずはコアサービスのみで市場投入しようとしていました。一方オーナーは、コアサービスだけでは中途半端だと考えていました。お客様のペインポイントはたくさんあるからです。
課題ポイントを改善する機能を素早く開発し、早く提供した方がいいだろうと考えたんですね。代表はお客様、店舗オペレーションなど全体設計を見ていましたが、プロジェクトメンバーはそこまで見ていなかったと今では思っています。そのため、お客様の一連のカスタマージャーニーが整った段階で、代表からもゴーが出ました。
●リクルート
Q．役職者であっても事実や詳細を把握していることは重要か？
中里：すべてを常に把握しているのは難しいとは思いますが、役職者も元々はエンジニアとの考えが基本としてあります。また、タスクフォースの際などは自分もエンジニアとしてチームに入り、手を動かすこともあります。
株式会社ポーラオルビスホールディングス
https://www.po-holdings.co.jp/
株式会社ポーラオルビスホールディングスの採用情報
https://engineer.po-holdings.co.jp/
関連するイベント
