PayPayのコーポレートエンジニアが語る、新機能開発・分析基盤・CRM基盤の開発舞台裏とは

アーカイブ動画

PayPayの事業を支えるエンタープライズエンジニアリング部

PayPay株式会社　コーポレート統括本部　経営推進本部
エンタープライズエンジニアリング部　部長　岡田寛史氏

最初に登壇した岡田寛史氏は、まずPayPayの事業とエンタープライズエンジニアリング部について説明した。

PayPayはヤフー、ソフトバンクグループの合弁会社という印象が強いが、インドのQR決済サービスのトップ企業であるPaytm社から技術アドバイザリーを受けている。

「PayPayの年間決済回数は20億回を超えます。ただ、我々としては単なる決済サービスだけでなく、金融、O2O、ソーシャル、P2Pなどと連携することで、スーパーアプリに成長させる構想を描いており、ブランドの統一などを進めています」（岡田氏）

PayPayには、40カ国以上の国籍から構成される多様なメンバーが集まっている。社内の公用語は日本語と英語。外国人の割合が日本人より多い部署もある。

社内のコミュニケーションは英語・日本語両方で行われており、大きな会議では翻訳メンバーが立ち会い、翻訳を専門に行うチームもある。資料は英語・日本語両方で作られるので、英語が苦手なメンバーでも、特に苦労することはない。

エンタープライズエンジニアリング部は、社員約50名から構成され、チームは7つ。日本人が多い部署とのやり取りが多いこともあり、日本人の割合は85％ほどだという。

特徴的なのは、2018年の会社設立後、ここ数年で一気にメンバーが参画していること。実際、岡田氏ならびに本日の登壇者も含め、、ここ1～2年で40名ほどが新しくジョインしている。

「我々の部署はセールス、コーポレート、プロダクトの開発・運用部門、すべての部署とコミュニケーションし、それぞれが事業を進める上で必要な社内業務システムやITサービスの開発を全社横断的に担っています。社内ではEE部と呼ばれています」（岡田氏）

マイナンバー連携における大量審査を短期間で対応可能に

続いては、具体的にどのような取り組みで全社の事業推進に貢献しているのか。各部署のケースが紹介された。

まずは、開発2チームが取り組んだeKYCの効率・内製化について、引き続き岡田氏が紹介した。eKYCとは「electronic Know Your Customer」の頭文字を取った言葉で、オンライン上で本人確認を行う手法や技術を意味する。

「以前は免許証などの本人確認書類と、顔認証による審査方式のみで、ユーザー自身でスマホのカメラを使って、様々な角度から顔写真を自撮りする手間がありました。また、審査工程のサーバーをサードパーティに依存していたため、申請から承認までに数日かかっていました。このままでは年末年始に実施するキャンペーンに対する、大量の申請処理は難しい状況だと予測しました」（岡田氏）

そこで開発2チームは、ICチップが内蔵してあるマイナンバーカードを利用した審査方式システムの開発に取り組んだ。さらに、外部に出していたサーバー連携、審査工程を内製・効率化することで、最終的な人による目視審査のボリュームを減らすことにも成功した。

「取り組みの結果、申請から承認までがわずか数分というリードタイムに削減され、1日数万件を超える申請・審査に対応できました。この取り組み以外でも、様々な業務システムの内製化を進めています」（岡田氏）

PayPayの大量データを捌く分析基盤とアーキテクチャの裏側

PayPay株式会社　コーポレート統括本部　経営推進本部
エンタープライズエンジニアリング部　データマネジメントチーム　三重野嵩之氏

続いてはデータマネジメントチームの三重野嵩之氏が登壇。システムアーキテクチャを紹介するとともに、PayPayならではの特徴を語った。

「BigQueryは初期から導入しています。アプリからのデータはもちろん、コールセンター、Google Analytics、Salesforceなどからもデータを取得し、Airflowで管理・モニタリングしています」（三重野氏）

スライドにはLooker、Data StudioといったBIツールが示されているが、SQLや直接データを扱えるリテラシーの高いユーザーが多いそうだ。

パフォーマンスとコストの兼ね合いで重要な指針である、スロット（リソース）管理についても説明された。以下のグラフの色の違いは、プロジェクトやリソースの消費量である。

絶対に落としたくないクエリ、落ちてもよいクエリでプロジェクトを分離し、リソースも割り当てており、Flex Slotsも利用。リソースを大量に消費するクエリを自動で落とすなど、運用が楽になったと三重野氏は言う。

クエリの監視においてはLookerを活用。リソースを消費しているクエリのトップ50を可視化している。なお、クエリ監視においては、BigQueryの常設機能INFORMATION_SCHEMAも併用している。

「データマートが大きくなるにつれ、どのデータを使って分析を行っているのか、トレーサビリティが難しくなってきます。そこで我々はツールを活用し、BigQueryの実行ログからデータの経路（テーブル）を可視化することで、データリネージしています」（三重野氏）

データリネージのlineageとは、日本語に訳すと系統や血統を意味する。データの軌跡が一目で分かるデータマネジメントにおける手法であり概念ともいえる。

「データリネージを作成していると、障害が起きたときにどのダッシュボードやテーブルに影響があるのか、依存関係も含めて一発で分かります。データマートの設計時に役立つなど、様々なメリットがあります」（三重野氏）

また、データマネジメントチームの主業務、大半を占めるデータエンジニアの役割については以下のように紹介された。

335万店以上で利用される法人向け機能のバックエンド開発の舞台裏

PayPay株式会社　コーポレート統括本部　経営推進本部
エンタープライズエンジニアリング部
セールスフォースチーム　リーダー　藤田文彰氏

最後の登壇は、セールスフォースチームの藤田文彰氏。まずは、PayPayにおけるセールスフォースを活用した大規模CRMシステムの概要図を示し、次のように語った。

「Salesforceの領域では、大きな法人から個人商店のような加盟店と、PayPayの利用者のサポート情報をまとめて管理しているのが特徴です。また、大手飲食チェーンといった加盟店の場合は、一つひとつの店舗での管理も行っています。大きな法人の場合は、管理はセールスフォースで行いますが、実際の商談は担当営業が直接行うことが大半です」（藤田氏）

スライド右側の領域は自社のインフラであり、業務システムや管理システムは岡田氏が紹介した開発2チームの担当領域。ビッグデータ領域は三重野氏が紹介したDWHであり、こちらもSalesforceとAPI連携している。

さらには、外部のサードパーティアプリとも連携している。サードパーティアプリ連携においては、高いセキュリティを意識。いわゆるIDとパスワード認証ではなく、認証基盤と連携し、情報の暗号化を行うなどSSL認証を導入した。ファイルのダウンロードやアップロードもスキャンなどで徹底した上で、すべての営業活動はSalesforceを軸に行っている。

チームで開発したSalesforceアプリの中から代表的な３つが紹介された。

「加盟店審査アプリはいかにもSalesforceらしいアプリですが、PayPayでは加盟店が記入するページだけでなく、内容を審査するオペレーターのアクションも同一ページ内で行うといったカスタムを施しています」（藤田氏）

「SCナビ」は個店営業が出先で申請や確認、営業向けの通知情報などが簡便に確認できる。PCではなく、iPadでの作業を念頭においたポータルアプリだという。

包括代理店PTNサイトは名称通り、加盟店を包括的に取りまとめる代理店向けのアプリだ。パートナーである加盟店はこのアプリを使えば、Salesforceでの複雑な操作をすることなく、審査依頼や結果を確認できる。代理店は、Salesforceでその状況を確認することができる。

セールスフォースチームでは、主に3つの役割を担うメンバーから構成されている。PM/PMOはビジネスサイドと要求を擦り合せたり、開発工程管理などを行う。エンジニアはそのSalesforceアプリの開発を担う。ただ、外部アプリやシステムとの連携があるので、各システム担当者とのやり取りも多いそうだ。

サービスデスクは、実際に社内でSalesforceを使う社員からの問い合わせに対応したり、Salesforceに関する各種課題を解決していく。

「ここまでの歩みはスピードを重視していたため、スクラッチ開発で各種アプリを開発し、実装してきました。しかし、今後さらに事業をスケールするためには、CRMの高度化が必要となります。そこで、一元管理できるSalesforceの標準ツールを採用することも考えています」（藤田氏）

具体的には、営業支援向け「Sales Cloud」やカスタマー向けの「Service Cloud」であり、後者においてはプロセスの自動化、CTI連携、ナレッジマネジメントなどにもチャレンジしていきたいと意欲を示した。

藤田氏は、今後の顧客データのマスター管理に対する取り組みについても触れた。というのも、これまでは顧客に対する営業のアプローチや商談内容が多様で、各企業の特徴が見えづらいという課題があった。

「特定企業の情報を一元化したマスターデータと、管理を行える基盤をSalesforce内に構築することで、さらなる顧客管理の高度化を実現したいと思っています。この取り組みは、BPRの一環でもあります」（藤田氏）

【Q＆A】視聴者からの質問に答える質疑応答セッション

セッション後は、登壇者が視聴者からの質問に答える質疑応答が行われた。

Q．大規模システムにおいて、機能要件の意思決定スピードを上げるための工夫は？

岡田：大規模システムに限らず、意思決定スピードのアップはPayPay全体で大事にしているカルチャーです。工夫としては、意思決定者を増やさない。Slackのチャットでコミュニケーションを頻繁に、それも現場からマネジメント層までがフラットな状況で行えるようにする。リソース配分、案件管理、プライオリティづけなども意識しています。

Q．AI・機械学習を活用している開発事例について

岡田：eKYCでの自撮り画像やテキストの分析などは、いわゆるAI、OCRの技術を使っています。そのほか、お客様からの問い合わせの電話音声をテキスト化し、分類しています。不正取引をしている人の特徴をAIが抽出するなど、様々な場面で活用しています。

Q．内製開発における課題は何か

岡田：たくさんあります。我々に限ったことではないのですが、まずエンジニアリソースが不足しています。そのため協力会社の力を借りることもあります。事業部との認識ギャップも課題であり、生じないように意識的にコミュニケーションしています。

Q．機能の大小も含めたリリース判定の基準とは

藤田：大規模な機能については最終的にはビジネスサイドがUAT（User Acceptance Test）を行い判定し、リリースします。小規模で影響の少ないケースでは、私が承認した後、リリースマネージャがリリースを行っています。

岡田：大規模な機能変更などの場合は、説明機会を設けて、ドキュメントもしっかりと作り込んで対応しています。逆に、小規模の場合はクイックにリリースすることを意識しています。どちらもバッグログなどの管理ツールを使い、リリースのエビデンスを残すようにしています。

Q．大量のトランザクション流入などトラブル対応はどうしているか

岡田：キャンペーン時などは、大量のトランザクションが入ってきます。一方で、PayPayのトランザクションは我々一社で完結しているわけではなく、様々なパートナーと関与しています。そこで、普段から関係者と負荷テストを行い、トラブルが発生した場合にはどこに連絡し、誰が担当するのかといった緊急連絡体制を整えています。また、小さな失敗は少なからず経験しているので、その学びをフィードバックすることも意識しています。

三重野：プロジェクトごとにクエリーを分けているので、トラブルを起こしそうな間違ったクエリーが飛んできたとしても、システム全体が落ちるような設計にはなっていません。

Q．BigQueryでFivetranを採用した理由

岡田：当時はETLツールの知識が乏しかったため、一般的なツールを調べて候補を挙げました。その上で、Salesforce、GCPとの相性や実際に導入している他社の評判を参考に導入を決めました。利用して約半年経ちますが、細かい障害を除いては概ね満足しています。

Q．絶対に落としたくない、落としてもよいクエリーの分類はどうしているか

三重野：難しい質問ですが、重要度よりは緊急度を意識しています。例えば、本日中に絶対に配信しなければいけないクエリは落とせないなど。逆に、3日前の情報でもよければ、再度クエリを流すこともしています。経営判断に直結するクエリーも重要視しています。

Q．Salesforceの個人・法人に対するレベルの違いも含めたセキュリティ対策

藤田：当然、分けて考えています。具体的なセキュリティ対策としては、個人情報は特定のメンバーしか見れないようになっています。自宅からアクセスする際には、VPNなどのセキュリティ技術を導入し、取引先情報は閲覧できますが、個人ユーザーの情報は見れないようになっています。

岡田：CISO（Chief Information Security Officer：最高情報セキュリティ責任者）など、全体のセキュリティポリシーを設計している担当者とも連携しながら、より強固なセキュリティを意識しています。

※注* 登壇者の所属はイベント当時のものです。