アーカイブ動画

SFA&CRM部の組織、ミッション、PayPayのシステム開発体制などを紹介

PayPay株式会社
Product統括本部システム本部SFA&CRM部
部長 徳久 晶子氏

最初に登壇したのは、SFA&CRM部 部長の徳久晶子氏だ。大手IT企業にてSalesforceなどの大規模システムの開発や運用に従事した後、2022年6月にPayPayにジョイン。現在はSalesforceやMulesoft を用いた開発などを手がけるSFA&CRM部を率いている。

年々増加傾向にあるキャッシュレス決済。特にコード決済の増加割合が顕著であり、中でもPayPayの利用割合は約3分の2を占める。登録ユーザー数は約6700万人（2024年12月時点）を超え、スマホユーザーの約3人に2人以上が利用する決済プラットフォームにまで成長している。

近年は友人や同僚との飲み会などでの割り勘に活用される送金サービスにも注力。コード決済における同サービスのシェアは95％であり、今後は決済を入り口とした、スーパーアプリに成長することを目指している。

「技術でPayPayグループの成長に貢献する」というミッションを掲げるシステム本部。その傘下にあるSFA&CRM部は5チームに分かれており、PayPayの加盟店や営業に向け、審査や申し込みなどに関する機能などを、SalesforceやMulesoftを用いて開発する業務を担当している。

社内外のシステムや部門との連携も多く、PayPayのサービスと事業がスムーズに運ぶために必要な、各種業務システムの開発や改善施策に特化した部門であるとも言える。

年間約600件もの改善要望が寄せられるという。全て対応するのは難しいため、四半期を一区切りとし、利益アップもしくはコスト・リスク減などの効果を投資と比較検討した上で、取捨選択しながら取り組んでいる。

開発においてはスピードを重視している一方、「法令対応やセキュリティレベルの高い案件などでは、スピードよりも品質に重きを置くなど、プロジェクトごとに異なります」と、徳久氏は柔軟な開発体制であることを述べた。

2018年にサービスを開始して以降、着実に利用者と加盟店数を伸ばし、さらには送金など関連サービスを展開するなど、業容を拡大してきたPayPay。SFA&CRM部は、まさにこのようなPayPayの躍進に対して、成長の度合いに応じて貢献してきた。

最初のステージでは、顧客基盤の拡大を目指した。次のステージでは、加盟店に向けた新規サービスの開発や、Sales CloudやService Cloudを用いることで、それまでバラバラになっていた顧客管理の一元化を実現させた。

今後のステージでは、Marketing Cloudや生成AI、MulesoftやSalesforce Connectなどを活用しながら、金融事業のさらなる拡大を目指す。さらには、冒頭で紹介したスーパーアプリに成長するという展望の実現に向け、現在のシステムやツールのさらなる質向上や拡充にも力を入れていく。

LWCを活用し、Salesforceのモバイルアプリを独自でスクラッチ開発

PayPay株式会社
Product統括本部システム本部SFA&CRM部Dev3
吉崎 陽紀氏

続いて登壇したのは、プロジェクトマネージャーとして開発を行っている吉崎陽紀氏だ。新卒でSalesforceベンダーに入社し、要件定義から開発・運用保守など、一通りの業務を経験した後、2022年9月PayPayにジョイン。現在は、アーキテクトとしてSalesforceの開発における仕組み作りも推進している。

PayPayでは以前からSalesforceを活用し、営業活動の業務管理などを行っていた。しかし、加盟店の情報が点在・不足するなどの理由から、情報の可視化などデータに基づく営業マネジメントができていなかった。「以前はレポートを作成するのも一苦労でした」と、吉崎氏は述べた。

Salesforceの利用がブラウザベースであることもネックだと考えていた吉崎氏は、スマホ上で営業の成果をすぐに報告でき、上司やメンバーも同じくスマホですぐにその結果を確認できる、そのようなモバイルアプリを開発することを決意する。

実際に開発したモバイルアプリのUI、イメージ図も紹介された。ホーム画面ではスケジュールやToDoの確認や管理が行える。

「最も重要だと考えた」と吉崎氏が話す営業実績においては、マンダラートのフレームワークを採用。中央に最も達成すべき目標を表示し、まわりに関連する子要素を配置するデザインとした。

また、個人だけでなく、チーム・拠点・マンスリーといった単位での営業実績が確認・管理できるページも用意した。

吉崎氏はER図も紹介し、「BigQueryなどの巨大なデータベースからデータローダーを使い、日毎の実績データをSalesforceに投入しています」と、構成とデータの流れを説明した。

アプリの画面レイアウトや数値の管理についても触れた。どちらの場合も、コードを調整する必要は一切ない。以下スライドで示すように色や行列で管理されており、それらを調整することで、希望するレイアウトやレコードが構成・表示される。

訪問件数などのプロセス指標がグラフで視覚的に示される個人ページも、構成やデータの流れは基本的に同じだ。

なお、プロセス指標の要素である行動や案件においては、Salesforceの標準オブジェクトから取得している。

ただ先ほどと異なるのは、プロセス指標、つまり営業活動の実績に関するデータにおいては、リアルタイムで自動的に集計されている点だ。

「巨大なデータベースではなく、Salesforceに存在している標準データを利用することで実現しています」と、吉崎氏は述べた。

営業担当のモチベーションアップのために、成果に応じてバッジを獲得できる機能も設けた。

こちらにおいては取得バッジ、バッジマスタなどそれぞれの要素に応じた新規のカスタムオブジェクトを作成し、月ごとで集計する仕組みとした。

なお、取得バッジの状態はリアルタイムで更新・表示する必要があるため、Apexトリガーを活用することで実現している。

紹介してきた画面は、Salesforceが提供するアプリケーションの開発手法、LWC（Lightning Web Component）を使用することで、実現している。ただし、「単なるLWCではない」と吉崎氏は言う。

LWCにReduxやredux-sagaのライブラリを加えることで、状態管理のデータフローモデルであるFluxを採用したアーキテクチャとなっているからだ。そして、このようなアーキテクチャで開発を行った理由を、次のように述べた。

「Salesforceの場合は、アーキテクチャがModel View Controllerという形になっているため、1つのデータソースに対して、複数箇所から操作するようなサービスに向いてないからです。そのためVisualforceやLWCのみで開発を行うことは、とても難易度が高いと思いました」（吉崎氏）

全体の処理の流れをイメージした図も示した。利用者がアクションを起こすことで、何らかの処理が実行され、必要に応じてサーバー上の情報が取得され、ビューで示される。3つの大きなメリットも紹介した。

1つ目が、アプリケーション内の複数のコンポーネント間で、状態やデータ、アクションなどの各種資源を共有できる点だ。2つ目は、ミドルウェアや統一したアーキテクチャの使用による拡張性と再利用性。3つ目は、アプリケーションの挙動を予測でき、状態管理が可能な点である。

吉崎氏は最後に、コンポーネント構成の一例を挙げ、アクションを通じてデータが得られること、データの流れが必ず一方向であること、ビューが細分化されていることなどを解説し、セッションを締めくくりました。

Mulesoftの活用でAWSデータのリアルタイム連携を実現。審査業務の効率化に貢献

PayPay株式会社
Product統括本部システム本部SFA&CRM部Dev2
HNIN PWINT PHYU氏

続いて登壇したのは、HNIN PWINT PHYU氏だ。SIerにてSalesforceの開発や外部システムとの連携などに従事した後、2022年にPayPayに入社し、現在はSalesforceとMuleSoftの開発支援などを担当している。

PayPayでは加盟店に対し定期的に法規遵守も含め、PayPayの加盟店として継続利用が可能かどうかの途上審査を実施している。大きく2種類の審査からなるが、どちらも年間252万件、6600万件とかなりのボリュームであり、オペレーションコストなどが問題となっていた。

そこで、オペレーションコストの削減はもちろん、品質安定も目指し、システムの大規模な刷新を実施することになった。しかし、データ連携やセキュリティ面など、大きく3つの課題が生じた。

HNIN氏は課題解決に向けた取り組みの紹介に際し、まずはシステムの構成図を示した。

左側がSalesforceであり、画面レイヤーを、右側がAWSでありデータレイヤーを、それぞれ担う設計となっており、両者のデータ連携ではMulesoftを利用した。HNIN氏は以下のように、システムの特徴や設計時の工夫を述べた。

「利用者が操作する際の柔軟性は保ちつつ、大量データを効率よく管理できるような設計としました」（HNIN氏）

データ連携では、Salesforceをデータ保存の基盤として活用し、参照や更新機能を提供するSalesforce Connectも採用。これにより、大量データの連携において、コピーが難しいとされるデータも効率的に扱える仕組みを目指した。

Salesforce Connectではいくつかのアダプターが利用できるが、今回はHTTPを使って、サーバーとクライアント（ブラウザ）間などのデータのやり取りを行える、Odataを採用した。

OdataはOpen Data Protocolの略であり、マイクロソフトが策定したプロトコルだ。メタデータの提供や、さまざまなデータソースとの統合が可能といった特徴を持ち「業務効率化や、よりスムーズなシステム連携に貢献すると思いました」と、HNINは採用した理由を述べた。

続いては2つ目と3つ目の課題、セキュリティについてである。閉域網を実現するために、AWS PrivateLinkを利用。さらに、安全な接続を提供するSalesforce Private Connectも採用した。これらの技術の採用により、AWSとSalesforceのVPC間で、プライベートなデータ転送が可能になり、セキュリティ強化につながった。

HNIN氏はネットワーク構成と最終的な構成図を示すと共に、SalesforceのアプリケーションからSalesforce Private Connectを通り、AWSの領域に流れていくセキュアなデータの流れも紹介した。

続いてはSalesforce製品の制約と制限についても言及した。レポート機能、画面表示機能で大別することができ、前者では特定のデータ型が検索条件として使用不可。後者においては動的リストが利用不可、といった制約があるという。

Private Connectにおいては、1時間あたりに利用できるレートが約215MBとなっていることも説明した。同制約を超えた場合には接続はストップするが、特にエラーなどは発生しないため、「モニタリングやアラートを工夫する必要があります」とHNIN氏は語る。

実際、Mulesoftを使って10分ごとにレートを確認しているという、具体的な対策方法も、合わせて紹介した。

さらに、Salesforceで外部オブジェクトにクエリを発行すると、エラーが発生する事象についても語られた。調べていくと10万字との文字制限はあるが、エラーの原因は文字数ではなく、URLの高さだとHNIN氏は言う。

そして、項目名を簡略化する、オブジェクトを1つにまとめるのではなく複数に分ける、などの対策を行うことで防ぐことができると、こちらも対策方法と併せて紹介した。

外部オブジェクトでは、ページレイアウトにおいて参照項目を配置すると4つまでしか表示できないといった、レポートの検索時に発生するエラーについても言及した。こちらもデータ型を変更するなどの対策を示した。

新しい製品だったため情報が少なく、トライアンドエラーを繰り返しながらの開発であったとHNIN氏は振り返った。エラー発生時の問題は、設計や実装側なのか、それともSalesforce側なのか切り分けも難しく、かつセッションでも紹介したように、制限の多さにも苦戦した、と続けた。

一方で、そのような壁を乗り越えてきたからこその想いを述べ、セッションを締めた。

「制限を克服しつつ、どうやって要求を満たすか。今回の開発で得た糧を今後のプロジェクトでも活かし、スムーズに進めていきたいと思います」（HNIN氏）

【Q&A】多くの質問が寄せられたQ&Aタイム

セッション後は、参加者からの全ての質問に登壇者が回答した。抜粋かつ、テーマごとに整理して紹介する。

Q．Mulesoftを選定した理由とは？

徳久：Informatica Cloudなどと机上でスペック比較した際に、Mulesoftの方が優れていると感じたからです。

Q．AWSやSalesforceのアップデートがあった際の対応は？

HNIN：更新を確認し、サンドボックスで検証しています。ただ、リアルタイム連携の影響はMulesoftも含めてほぼないという認識です。そのため変更点があった箇所の取り込みを行っています。

Q．Mulesoftの他の使い方事例は？

HNIN：複数システムを中間連携するような際に使っています。今後はAPI的な活用でも利用していきたいと考えています。

Q．HNINさんの取り組みを他領域でも展開する計画はあるのか？

HNIN：実際に今、SalesforceやMulesoftを別案件でも活用していて、今後も取り組んでいく予定です。

Q．モバイルアプリをSalesforceで開発すると決めた理由は？

吉崎：CRMをSalesforceで管理していたからです。AWSで開発する方法もありましたが、CRM的な体験をアプリで提供したい、との思いもありました。そもそもSalesforceを利用しているのはPayPayの特徴として成長が早く、開発も迅速にする必要があるため、データベースなどを一から開発するのは厳しいとの背景からでもありました。

徳久：スピード感を出したいため、グループ会社で導入事例があったSalesforceを活用することにした、と聞いています。一般的にはSales Cloudなど、製品を指定して利用する企業が多いと思いますが、PayPayの場合はプラットフォームとして導入しました。そのため実際に開発が早いという評価を得ていますし、新規機能をSalesforceで作りたいという声が多く挙がっています。

Q．LWC開発のメリットは？

吉崎：従来のVisualforceと比べると、肌感ですがコード量は10分の1から20分の1に削減できています。反応速度も速く、改修もしやすいです。このようなメリットには、理由があります。GoogleがGoogleマップの開発をLWCで行っていて、技術投資も含めてアーキテクチャを確立してくれているからです。Googleが保証している技術である、とも言えるでしょう。

Q．LWCでアーキテクチャを開発する際の苦労や悩みごとは？

吉崎：コンポーネントの単位を試行錯誤しています。拡張性を意識しているのですが、優先するとコンポーネントの数、参照すべきライブラリが増えるからです。

Q．LWCの情報はどのようにキャッチアップしているのか？

吉崎：日本での事例はほぼない、と思います。そこでアメリカの情報をピックアップしています。具体的にはSalesforceのコミュニティにおける、英語のやり取りです。ただ技術のベースはJavaScriptなので、知りたいことも同じくJavaScript関連になります。こちらについてはYouTubeなども活用しています。

徳久：PayPayでもまだ全員がLWCに詳しいというわけではありません。そこで吉崎さんとHNINさんを中心に勉強会などを実施していて、今後は開発の中心手法にしていこうと考えています。

Q．勉強会の開催などノウハウのシェアについて

吉崎：勉強会は週一必須で行っていて、実際に開発で得たLWC知識などをメンバーに共有しています。

徳久：吉崎さん、HNINさんの他に2人ほど勉強会で登壇するメンバーがいて、ローテーションでまわしているような流れで、メジャーアップデートの際などはシェアを行います。

HNIN：アップデートの情報共有は実際に調査を担当した方が登壇して、シェアすることが多いですね。Mulesoftの場合も同様で、特別な事例があった際などに勉強会などで情報をシェアしています。

徳久：その他、大きな案件をリリースし、既存の機能でも大きな改修を行った際には、開発案件共有会を開き、他のメンバーも情報や技術をキャッチアップできるような体制としています。

PayPay株式会社
https://about.paypay.ne.jp/

PayPay株式会社の採用情報
https://about.paypay.ne.jp/career/

PayPay株式会社のオウンドメディア「PayPay Inside-Out」
https://insideout.paypay.ne.jp/