アーカイブ動画
PayPayシステム開発部の組織体制とミッション
PayPay株式会社
システム本部 システム開発部 部長 藤田 文彰氏
最初に藤田文彰氏から、システム開発部の組織体制や業務内容について説明が行われた。 藤田氏は2019年10月に、金融事業の未来創世に尽くしたいという思いからPayPayに入社。2022年8月より、業務システム開発部門にてマネジメントも担当している。
「PayPayの登録ユーザー数は、2022年10月時点で5200万人を超えており、2021年度の1年間の決済回数は36億回にもおよぶ決済サービス。さまざまなサービスを搭載するファイナンシャルプラットフォームとして、さらなるスーパーアプリ化を目指しています」（藤田氏）
PayPayでは、PayPayカードやPayPay銀行、PayPay証券、PayPayほけんなど、PayPayブランドのさらなる拡大を目指し、約40の国と地域から多国籍で多様なプロフェッショナルが集まり、連携しながら取り組んでいる。
システム本部では「技術でPayPayグループの成長に貢献する」をミッションに、事業成長を支える社内業務システムやITサービスを提供している。
「PayPayサービスを下支えするセールス/BizOps、プロダクト/BizDev、コーポレートの全領域をIT化する部署です」（藤田氏）
システム本部は「コーポレートIT部」「システム開発部」「データマネジメント部」「IT戦略室」の4部門で構成され、PayPayの事業成長を下支えする社内業務システムやITサービスの提供を通じて、さまざまな部門と連携して課題解決に取り組んでいる。
藤田氏が率いるシステム開発部は、「PM」「アプリケーション」「インフラストラクチャー」「DevOps」「SFA＆CRMプロモーション」「SFA＆CRMデベロップメント」の6つのチームから構成されている。
「さまざまなシステムと連携する事業運営のための業務システム基盤を開発している」と藤田氏が言う通り、企業マスタ管理やキャンペーン管理、顧客管理、加盟店審査などの仕組みを作っているというわけだ。
「開発スピード」を意識した業務システム開発の裏側
PayPay株式会社
システム本部 システム開発部 渡邉 俊平氏
続いて登壇したのは、PayPayのバックエンドエンジニア渡邉氏。2020年4月に入社後、ローコード開発基盤での開発とAWS上でのスクラッチ開発に並行して従事。2022年6月より内製アプリケーション開発チームをリードしている。
PayPayにおける業務システム開発体制は、大きく分けると内製開発と大規模開発の2つのパターンがある。内製開発パターンはアプリケーションエンジニア（以下、アプリエンジニア）とインフラエンジニア、リードエンジニアなど、小規模なメンバーで開発を進める。
リードエンジニアはタスクの分解や進捗管理、コードレビュー、設計などを担当し、アプリエンジニアは設計から担当するケースもあれば、実装から担当するケースもある。
大規模開発パターンでは、5～10人ぐらいの開発者がチームを組み、数カ月かけて開発を行う。そのため、専門のPMOやPMが案件を担当する。
「案件規模によっては、パートナーに入ってもらうこともあります。プロジェクト初期は大規模開発パターンで開発を進め、その後、内製開発パターンに移行していきます。初期開発の段階から基本方針や開発ポリシーに沿っているかを社員がレビューすることで、内製開発に移行しやすくしています」（渡邉氏）
業務システム開発における第一の特徴は、「手段を目的化しないこと」を常に意識して開発に取り組んでいることだと、渡邉氏は語る。第二の特徴は、事業運営部門と一緒に開発を進めることだ。システム開発中だけではなく、運用開始後もビジネスフロー構築に入り、必要であればビジネスフローの見直しを行っている。つまり、BizOps/BizDevと協働して開発を進めているのだ。
この背景にあるのは、PayPayの事業が急速に拡大していることだ。例えば、事業の立て付けをしながらシステム化を進めるケースも珍しくないという。一方で、手戻りが発生する可能性も高い。そこで事業運営部門と連携し、システム側でフローやオペレーションを検証しつつ、ビジネスの方向性が固まった時点でシステム化するやり方を採用している。
「まずはPoC的に回してみて、検証しながらシステム化します。システムのデリバリー速度を落とさずに手戻りを少なくし、ムダな機能開発や要件漏れをなくすことを狙いとしています」（渡邉氏）
PayPayサービスにおける業務システム開発の歴史
2018年10月にPayPayがローンチされて以降、PayPayではさまざまな業務システムがリリースされてきた。2020年4月にリリースされた加盟店審査システムでは、当初二人体制からスタートし、社内システムの内製チームとしての方針や手法のベースを作成したと、渡邉氏は振り返る。
「加盟店審査システムは、Salesforceをフロントシステムとして開発しました。ポイントは、既に存在している画面を基盤として利用したことです。Salesforceの機能要件とPayPay側のセキュリティポリシーが合わないところは、スクラッチで開発しました」（渡邉氏）
システム監視については外部委託とし、風評被害チェックなどのクローリングシステムは外部パッケージを利用して工数を削減。同システムはリリースされて約2年が経過し、事業の拡大とともに求められる機能も増えている。現在、業務面・システム面、両面での刷新プロジェクトが進行中だ。
この開発をベースに、現在のマイクロサービス開発保守方針が作成された。その後、営業向けツールの移管・統廃合、架電業務向けシステムの導入、与信債権管理システムをリリース。複数の初期開発案件の同時進行がデフォルトになった。また、与信債権管理システムでは、画面基盤も作成した。
2021年にはインフラ基盤の更改が完了。アラート通知など外部に委託していたものを内製化した他、AI Platformをリリースし、AIを本格的に利用し始めた。同年後半にリリースされたのがeKYC（本人確認）システム、キャンペーン管理、顧客管理（CDD）システムだ。
「この頃にはプロジェクトの形態も多種多様になりました」（渡邉氏）
eKYC審査システムとは、PayPayアプリ上で免許証などを使って本人確認を行うための審査の仕組みである。免許証など機微な情報を扱うシステムのため、既存のシステム基盤ではセキュリティ要件が適合しないこともあった。
「プロダクト側の基盤でアプリケーションを構築する対策を行いました。システム側で共通化されたアプリケーションはそのまま利用できたため、手戻りなどが発生することはありませんでした」（渡邉氏）
コストやサーバー管理などで課題の多かった機械学習・AIのシステム基盤はSageMakerで構築。SageMaker上で行われる学習・再学習の仕組みについても、セキュリティを担保できるような形で構築されている。
2022年にはメンバーも案件もかなり増えてきたことから、チーム内での職掌を整理。現在はCI/CDや内製基盤の更改など、これまで取り組めていなかったところに取り組んでいる。
「開発方針としては、マイクロサービービスアーキテクチャがベース。基本的な構造は変えずに、開発フレームを改良していく方針を採用しています」（渡邉氏）
例えば、画面開発は当初Salesforceのフロントを利用していたが、スクラッチ開発をするようになり、現在は速度改善やデザイン刷新にも取り組んでいる。内製画面基盤共通化も行ったが、システム要件によっては個別のデザインにせざるを得ないこともあるため、ある程度各プロジェクトで選択できるように改良した。
さらにAIモデルの実行環境などは、納期を優先してEC2で構築したが、ランニングコストがかかるため、今はSageMakerで構築するよう方針変更している。
渡邉氏はこのように技術を取捨選択できる理由を3つ挙げている。1つは「マイクロサービス化」、2つ目は「セキュリティレベルが担保できる開発体制」、3つ目は「変化に寛容な文化がある」ことだという。
取捨選択をした集大成のシステムとして紹介されたのは、「CS業務効率化ツール」である。CS業務効率化ツールとは、通話内容をリアルタイムでテキスト化し、AIによってカテゴリ分けすることで、CS部門のオペレータの対応業務を支援するためのツールだ。
「外部のパッケージ製品やAIなど必要な要素技術は外部から取り込むことで、スピードを意識した開発ができている」と、渡邉氏は説明する。
「PayPayではスピード感を持ってシステム開発が行われている。その大きな要因は、セキュリティが確保されているシステム基盤があることです」（渡邉氏）
「高いセキュリティ」を意識した業務システム基盤構築の裏側
PayPay株式会社
システム本部 システム開発部 菅野 修平氏
金融事業で求められる高いセキュリティを確保したシステム基盤を、PayPayではどう構築しているのか。業務システム基盤構築について語ってくれたのが、続いて登壇した菅野氏である。現在はAWSエンジニアとして、PayPay社内業務システムのインフラ開発・運用に従事している。
PayPayの社内業務システム基盤では、AWSをベースに図のようなさまざまなサービス群を利用して開発を行っている。
例えばフルスクラッチで開発しているシステムでは、マイクロサービスアーキテクチャを採用している。バックエンドのインフラ構成も非常にシンプルだ。フロントにALB（Application Load Balancer）、バックエンドにEC2、データベースにAuroraという構成を基本セットとし、それをサービス毎に並べていくことが基本的な考え方となっている。
セキュリティに関しては、IAMをはじめとした各種サービスを使い、セキュリティのベストプラクティスに則って非常にセキュアな環境を構築している。監視については、Cloud Watchで検知したアラームを通知する一般的な構成を採用している。
サーバーのシステムログやアプリケーションログの管理については、CloudWatch Logsに転送、Kinesis Data Firehose経由でS3に保管するような構成となっている。3年以上ログを保管するポリシーのもと、Amazon S3 Glacierなどを使い、コストも意識しながら長期保管を行っている。
「システム開発部ではPM、アプリケーション、DevOps、インフラストラクチャーの4チームとはもちろん、各種業務部門やビジネス部門、一般ユーザー向けのアプリケーション基盤を開発しているプロダクト本部、PayPay全体のセキュリティポリシーの策定や監査をミッションにしているCISO室と、密に連携しながら開発を進めています」（菅野氏）
高いセキュリティを確保する各フェーズにおける取り組み
高いセキュリティを確保するため、システム基盤開発・運用フローの各フェーズではさまざまな取り組みを行っている。要件定義フェーズでの取り組みとしてまず挙げられるのは、「CISO室へのセキュリティ相談」だ。
システム開発部は、業務部門から既存業務の課題を引き出し、機能要件・非機能要件を確認する。要件が固まったら、システムアーキテクチャの基本設計に入る。システムで扱うデータの機密性や保管場所、アクセス権などの観点から、適切なセキュリティ対策を講じるために、CISO室に相談しながら開発を進めていく。
基本設計フェーズの取り組みとしては、「社内セキュリティガイドラインを踏まえたアーキテクチャ設計」「多角的なアーキテクチャレビューの実施」がある。PayPayでは遵守すべきセキュリティ規則があり、情報管理規則やデータベース管理規則、ネットワーク管理規則などはその一例だ。
「セキュリティ要件をしっかり把握するとともに、AWSが推奨しているベストプラクティスにも則り、設計を行っています」（菅野氏）
アーキテクチャレビューはテックリードのレビュー後、システムの基本設計が固まった段階で、AWSのソリューションアーキテクトにレビューしてもらう。AWSのベストプラクティスと照らし合わせて適切なシステムデザインになっているか、チェックしてもらうためだ。
セキュリティ観点ではCISO室がチェックする。下流工程での手戻りをできるだけ少なくし、開発スピードの担保につなげている。
詳細設計フェーズでは、「IaC（Infrastructure as Code）ツールを用いたコードのセキュリティチェック」を実施する。
具体的にはAWSの各リソースをTerraformで管理。Terraformのコードについては、GitHubのプライベートリポジトリで管理している。IaCツールを用いたコードのセキュリティチェックは、次の図のようなフローで実施される。
IaCツールによる自動処理では、「Atlantis」というTerraformのCIツールを活用。Atlantisの中でポリシーを定めれば、それに基づいたコードチェックもできる。例えば機密性の高い情報が含まれているかどうかをチェックし、アラートを出すことも可能だ。
構築/テストフェーズの取り組みとしては、「AWSアカウントの分離と複数AWSアカウントの一元管理」「AWSサービスを用いたセキュリティチェックの実施」を行っている。AWSアカウントのガバナンスには、「AWS Organizations」を活用。Organizationsの管理アカウントはプロダクト本部側で管理し、各システムや環境ごとにAWSアカウントを作成し、一元管理し、セキュリティ的にベストプラクティスに則った構成になるように、SCP（Service Control Policy）を利用している。
「セキュリティチェック」では、AWS基礎セキュリティのベストプラクティスとCIS AWS Foundations Benchmarkを活用。「構築が完了した時点で、構築済みのリソースに対してAWS Security Hubでチェックを行い、これらのセキュリティ基準に違反している箇所がないかどうかを確認しています」（菅野氏）
サービス開始後の取り組みとしては、「セキュリティ診断の定期的な実施」「本番環境に対する各種アクティビティの監査」が挙げられる。PayPayでは年に1回、すべてのシステムに対してセキュリティ診断を実施し、最新の脆弱性情報を踏まえたセキュリティチェックおよびセキュリティ対策の強化を行っている。
CISO室が診断を実施し、結果をシステム開発部に報告。システム開発部ではその結果をもとに対応し、その結果をまたCISO室に報告するフローを定期的に回す。「アクティビティの監査」もCISO室が主体となり、不審なアクティビティについて早期検知・対応可能な体制を整備している。
渡邉氏・菅野氏のセッション終了後、藤田氏は次のようにまとめた。
「PayPayでは開発スピードと高いセキュリティを両立させるため、Biz+Dev+Ops+Secが四位一体となって取り組んでいる。これがPayPayの特徴であり、この考えはこれからも大事にしていきたいと思います」（藤田氏）
【Q&A】15分間にわたって繰り広げられた濃厚な質疑応答を紹介
セッション後は、参加者からの質問に登壇者が回答した。その一部を紹介する。
Ｑ．事業運営部門を巻き込む際に、意識していることは何か
渡邉：プロジェクト自体のコミュニケーションの立て付けを整備しておくことは意識しています。例えば、要件をドキュメント化して認識合わせをする。認識合わせをしながら進めていくことが大事だと思います。
菅野：非機能要件を確認していくときも、確認したいポイントをシステム開発側で整理をした上で、意識齟齬がないように資料を作っておくことも一つの手です。
Ｑ．スピード感と堅牢なシステム設計の両立、スピード感を維持するために行っている対策、考え、方針について
菅野：守るべきポリシーがたくさんあると大変ですが、IaCを活用することで助かっています。過去にセキュリティを担保して構築したシステムをうまく活用し、新たな要件があればそこに追加して検討したりすることで、新たな要件にも柔軟に対応しています。
Ｑ．技術負債の管理はどのようにしているか
渡邉：バッグログやタスク管理ツールに記載し、開発者の手が空いたときに片付けるようにしています。技術負債が溜まってきた際は、プロジェクト化して解決することもあります。画面基盤の刷新やCI/CDの導入など、これから取り組んでいきたいことをプロジェクト化し、返済しています。
Ｑ．IaCの導入を決めた背景について
菅野：もともとは手動構築でしたが、規模が大きくなるにつれて、各サーバーに対して一律でセキュリティ対策を設定したり、設計変更を入れたりする作業は工数もかかり、作業ミスも発生しやすくなります。そこでIaCツールを導入し、コードベースで管理することで、変更をミスなく容易に反映できるようにしました。
過去に開発した資産を活用する観点でも、システムをIaC化しておくことで、開発環境を過去に作ったものから立ち上げることもできます。これらがIaCを導入するモチベーションとなりました。
Ｑ．アプリケーションマイクロ化の構成、作成後の評価プロセスについて
渡邉：アプリケーションマイクロ化の構成は、システマチックにできているとは言えません。非機能要件、SLAが異なると分けています。また、データをどのように保持しておくかという観点で決めることが多いですね。
PayPay株式会社
https://about.paypay.ne.jp/
PayPay株式会社の採用情報
https://about.paypay.ne.jp/career/
関連するイベント
