アーカイブ動画

PayPayの社内システムを担当するSystem Platform部

PayPay株式会社　システム本部
System Platform部　部長　齋藤 祐一郎氏

最初に登壇したのは、システム本部 System Platform部 部長の齋藤祐一郎氏だ。齋藤氏は2001年からバックエンドエンジニアとして従事している。前々職のスタートアップでは、高負荷対策やセキュリティ対策に向き合ってきた。前職の外資系IT企業では、スタートアップ企業担当のソリューションアーキテクトとして多数の企業に技術支援を行ってきた。

PayPayは、ユーザー数6300万人超（2024年3月時点）を抱える、日本最大級の決済プラットフォームを提供するキャッシュレス決済のリーディングカンパニーである。2022年のPayPayの決済回数は年間約47億回、国内コード決済シェアは約67％を誇る。

今や多くの人が日常的に使っている決済サービスを提供しているPayPayだが、その裏側では社内システムへの取り組みが行われている。

「決済を入り口に保険や銀行、証券など、皆さまのお金の利用を通じて生活を豊かにするスーパーアプリを目指し、日々努力しています」（齋藤氏）

齋藤氏が部長を務めるSystem Platform部は、PayPayのサービス側ではなく、社内システムやITインフラを担当している部署である。これらもすべてフルクラウドで構築している。

さまざまな社内システムを少人数で運用しているため、ソフトウェアで制御できるというクラウドのメリットを活かしている。PayPayではTerraformでコードを書いて制御しているので、構築作業自体がスムーズになるばかりでなく、コードを簡単に書き直して 試行錯誤が容易にできる。その結果、構築・運用の生産性向上に貢献していると、齋藤氏は語る。

「SaaSも積極的に活用し、社内の運用コストの削減と効率化を図っています。フルクラウドで社内システムやIT基盤を構築しているPayPayには、ITインフラの技術者として挑戦できる機会と環境がたくさんあります」（齋藤氏）

それは日本銀行が2024年1月に発表した「金融機関におけるクラウドサービス利用状況と利用上の課題について」という調査結果を見ると明らかだ。

日本の金融機関では9割超がクラウドを利用しているが、その多くはOA系や周辺のシステムが中心で、顧客情報や決済業務のシステムには使っていないからだ。

だがPayPayではフルクラウドでセキュリティおよび開発スピードを確保し、社内業務システム基盤・運用ができるように、各フェーズにおいてさまざまな取り組みを行っている。

例えば、統制を効かせるために、ゲートキーパー式とガードレール式を織り交ぜた方式を採用している。ゲートキーパー式とは、設計段階で特定のステークホルダーの人がレビューするなどの関門を設ける方式である。

一方のガードレール方式とは、「ここまではやっていいが、これ以降はやったらNG」というように、まるでガードレールを設けてブロックするという方式だ。

ゲートキーパー式が採用されている箇所は、セキュリティ相談と基本設計の部分。基本設計フェーズで複数のシステムについて毎回レビューをするのは、作業工数が嵩んでしまう。そこで、社内ガイドラインを作成。それに則った上で設計標準を作成し、チーム内で運用している。

「このようなテンプレートやガイドラインを作ることで、内部のレビューを効率化。ゲートキーパー式でもある程度のパフォーマンスを出せるポイントとなっています」（齋藤氏）

ガードレール式はセキュリティ診断などで使っている。

「クラウドの統制機能を使うことで、誤ったり脆弱な設定を仕組みで防ぐことができます。お客さまにも安心・安全に使ってもらえるインフラを構築しています」（齋藤氏）

全員が在宅勤務ながら、孤独にしない仕組み

続いて齋藤氏は、組織の話にも言及した。社内システムに携わっているシステム本部は大きく8つの部署で構成されている。組織として責任分担を明確にすることはもちろん、責任を超えて必要なことを「良いお節介」を通じて発揮するという。

例えば、System Platform部であれば、業務分野上、System Development 部やプロダクト本部、そして業務部門の人たちと密に関わることになる。その際に重要なことは責任を明確にしながらも業務の完遂に必要なことを徹底する形で全員がオーナーシップを持ち、人の間に仕事のボールを落とさないことだ。このような仕組みにすることで、システム構築を問題なく完遂させ、安定した運用を実現している。

PayPayでは、在宅勤務が採用されている。在宅勤務は集中して業務ができる一方で、同僚との縁を作りにくいとも言われている。そこで同社では『孤独にしない』をキーワードに、組織全体でサポートする仕組みを用意していると、齋藤氏は強調する。

それが1on1やチーム会、部の全体会、ハイブリッド部会、Slackでの雑談などだ。「組織全体に対する効果を見通しながら、技術の力を使って効率的な業務が遂行できる環境を整える」というミッションからもわかるように、System Platform部は技術だけではなく、組織全体に対するパフォーマンスを大切に考えて活動している。

「オーナーシップの発揮を通じて、風通しの良い組織コミュニケーションの実現。孤独にしない組織として行動できる仕組みと文化を浸透させています」（齋藤氏）

System Platform部が担当する「公式コーポレートサイトの移行プロジェクト」

PayPay株式会社　システム本部
System Platform部 リーダー 申 賢燮氏

続いて登壇したのは、System Platform部 Cloud Engineering4リーダーの申 賢燮氏だ。申氏は金融、NFC/Felica、ゲーム、教育系Webサービスなど、さまざまな業界・分野にてソフトウェア開発のバックエンドエンジニアとして活躍。PayPayではAWSインフラエンジニアとして業務に従事している。

申氏が所属するSystem Platform部では、PayPayの「公式コーポレートサイトの移行プロジェクト」を実施している。

PayPayの公式サイトは大きく2つある。1つがサービス内容とお知らせが掲載されるサービスサイト、もう1つは会社情報や利用規約などが掲載されているコーポレートサイトである。いずれの公式サイトも、ほぼ同じAWS構成を採用している。

公式サイトは、Amazon CloudFrontとALB（Application Load Balancer）とAmazon S3で構成。ALBのバックにはWordPressが載っているEC2があり、コンテンツを保存するためのS3Bucketがある。リージョン障害に備えて、S3のリージョン間でレプリケーションが設定されている。

PayPayでは、どのようにしてこのようなベンダーに依存しない体制を作っていったのか。課題だったのは、Terraformコードはあるものの、ドキュメントがなく全体像を把握することができなかったことだ。隠れ仕様やベンダーのみが知っている情報もあったという。

そこでプルリクエストのレビュアーとしてコードをレビューし、一部は直接コードを実装することで仕様の理解を深め、その理解した内容をまとめてドキュメント化する戦略を採用した。

具体的な施策としては、以下の3つである。

1. コードレビューを通じて仕様を理解し、ドキュメントに落とす
2. 実装の背景をヒアリングし、コードに表れていない内容を確認
3. ヒアリングした内容を鵜呑みにせず、コードと実際動作を確認した上でドキュメントに落とす

この施策を採ったことで、システム構成の全体像が明らかになり、コードから読み取りにくい隠れた仕様、およびプログラムの挙動も把握できるようになった。

「インフラチーム全員がコードレビューやヒアリングなどの情報をドキュメントで閲覧できるようになったことで、情報の把握が進みました」（申氏）

出てきた課題をどう解決したか

だが、内製化後にも課題はいくつか出てきた。その1つが意図しないオートスケールの挙動による安定稼働を阻む問題である。

ヘルスチェック猶予期間15分の設定に対し、EC2インスタンスの初期処理が15分以上かかっていたことで、インスタンスが起動・停止を繰り返し、システムが不安定になっていたのだ。

この問題に対応するため、まずは原因を調査して一次対応を決定。チームで案出しやフラットな立場で議論し、対策案を決定。実装してテストを行った。

次に、根本的な問題（真因）を解決するための対策を議論。恒久対応を行うという流れで対応を実施した。暫定対応としては、ヘルスチェック猶予期間を30分に延長。それによりオートスケールの挙動が安定したという。

また、真因を探るためにユーザーデータのスクリプトコードを確認し、どこで時間がかかっているかを特定した。すると、EC2のミドルウェアインストールに時間がかかっていることが分かった。

そこで、一部のミドルウェアはインストールした状態でAMI（Amazonマシーンイメージ）を取得。ユーザーデータで一部のインストール処理を省くという恒久対応を取った。

もう1つの課題が、Terraformモジュールの実装がPayPay運用ポリシーと合っていないこと。Terraformコードのモジュールの依存関係が深くなっており、各環境間で同じモジュールを使用していた。

「各環境の固有の値はterraform.tfvarで切り分けてはいましたが、PayPayの運用とは合っておらず、改善する必要がありました」（申氏）

このような状況により、各環境へのデプロイに問題が出ていた。セキュリティを重視しているPayPayでは、レビューとポリシーチェックを実施し、それにパスしたもののみをAtlantisというCI/CDツールを使って、本番環境に Applyするルールになっている。

そのため、開発（Dev）/ステージ（Stg）/プロダクション（Prod）が同じモジュールを参照すると、AtlantisはDev→Stg→Prodを同時にアプライしてしまうことが起きていたのだ。

また、依存関係にあるリソースに対して差分が発生する問題もあった。依存関係にあるモジュールを修正すると、想定していないリソースまで Change または Replace が発生するのである。

そこでリファクタリングプロセスにおいて、モジュールを使うケースと使えないケースを決め、さらにリファクタリング方法についても議論した。モジュールと連動しているリソースをどうやって移動させるかを議論。terraform state mvコマンドを使用するか、moved blockを使用するか、チーム間で話し合った。

「結果、私たちはレビューを重視しているので、moved blockを利用してリファクタリングする方法を採用しました」（申氏）

結果、Atlantisを使って「Dev実装→Dev試験→Stg実装→Stg試験→Prod実装→反映」の順で反映できるようになった。

「依存関係にあるリソースの差分の発生がなくなり、品質低下のリスクを除去できました」（申氏）

OutSystemsの社内AWSへの移行プロジェクト

PayPay株式会社　システム本部
System Platform部 斉木 顕佑氏

最後に登壇したのは、システム本部System Platform部の斉木顕佑氏だ。斉木氏は23年8月にPayPayに入社。新卒でSIerに入社し、保険業界のお客様向けにシステム開発・設計・運用・保守に従事。その後、フリーランスとして、クラウドを基盤としたシステム開発の案件に携わってきた。

現在、AWSエンジニアとして社内で活用するシステムの設計・構築・運用に従事している斉木氏が紹介したのは「OutSystemsの社内AWSへの移行プロジェクト」。OutSystemsは、ローコードのアプリケーション開発ツールだ。移行する前までは、クラウド版を利用していた。

だが、同システムを利用する社員が増えていること、開発案件も増えてきたことで、「より柔軟にパフォーマンスチューニングをしたい」「定めているデータに対するセキュリティポリシーを確保したい」というような背景があり、このプロジェクトは始まったと斉木氏は説明する。

スケジュールは3カ月という短時間。その期間内にDev、Stg、Prod、Lifetime計4環境のインフラを構築するというプロジェクトである。

プロジェクトのフローはこれまでと同じで、「PayPayでは新しいシステムを構築する場合は、基本的にどの案件もこのフローをたどる」と、斉木氏は力強く語る。

まず要件定義では、アプリ側のチームやビジネス側のチームと機能・非機能要件、データ要件、スケジュール感などについて会話する。次の基本設計では、System Platform部がAWSのアーキテクチャ図を描く。

「PayPayではMiroというツールを使って描いています」（斉木氏）

詳細設計では、Terraformコードを使ってインフラ管理のためのコードを書いていく。コード管理はGitHubで実施。GitHubにプルリクエストを上げ、レビューを実施。レビューが通ると、GitHub上でアプライのコマンドを実施し、リソースを展開して構築。その後、フローはテスト、運用保守へと続く。

このフロー内でどのようなセキュリティの取り組みをしているのか。要件定義では、CISO室のメンバーにセキュリティ相談ができる。

「どのようなセキュリティポリシーを満たさなければならないのか。それに準じるガイドラインを提供してもらったり、アドバイスを受けたりする。その後の工程で、振り出しに戻るようなことを避ける仕組みになっています」（斉木氏）

基本設計のフェーズでは、描いたAWSアーキテクチャ図のレビューを実施する。リーダーや部長だけではなく、「AWSのソリューションアーキテクトを呼ぶことも可能」と、斉木氏は語る。またその場には、CISO室のメンバーもリクエストすれば参加してもらうこともできる。

詳細設計や構築のフェーズでは、Atlantisを使い、DevSecOpsチームが管理しているセキュリティのルールやポリシーをチェックしている。

「構築のフェーズで、PayPayのシステムに最低限必要なセキュリティが担保できる仕組みになっています」（斉木氏）

テストのフェーズにおいても、CISO室のメンバーとコラボレーションし、脆弱性検査やセキュリティ診断を実施する。これらのセキュリティ試験をパスすることで、同社の認証基盤「Okta」との連携が可能になる。

運用保守のフェーズでも、いろいろな監査への対応や定期的なセキュリティ診断が実施される。

移行プロジェクトにおける具体的な議論の内容とは

今回の案件でどのようなことを議論したのか。その一つが、ディザスタリカバリ（DR）環境の構築についてである。もう1つはネットワークファイアウォールを導入するか否かだ。

まずはアプリケーションが求められる可用性（RPO：目標復旧時点/RTO：目標復旧時間）を確認。DR対象となり得る業務遂行上、クリティカルなシステムか、DR先での業務推進体制は確保できているのか、DRした場合のAWSコストとのトレードオフなどについて、AWSのソリューションアーキテクトにアドバイスもふまえて議論を行った。

「結果的にMulti-AZ構成のみで、DRサイトなしと整理しました。次に、基本設計のフェーズでリスク・リスクセキュリティ本部のメンバーと議論しました」（斉木氏）

具体的に扱うデータ内容を確認し、ファイアウォール導入やインフラ運用工数のトレードオフなど、ファイアウォールを導入するか議論した。アウトバウンド通信制御という細かな設定レベルでも、CISO室のメンバーと具体的に扱うデータの内容や保管場所の確認を行った。

すると、セキュリティアップデート対応には[0.0.0.0/0]の許可が必要で、機密レベルが上がった場合はセキュア環境を構築することなど、第三者のレビューを踏まえて構築できることが、高度なセキュリティを担保できる仕組みができたという。

移行後のシステム構成は、以下スライドの通りである。

セキュリティを担保するための取り組みは、それなりの負荷がかかる。そこでPayPayでは、あらゆる業務オペレーションに対する自動化・効率化への取り組みを用意している。

本番環境アクセスを受けて、承認後アクセス権を付与するフローの自動化、プルリクエスト作成に対するChatGPTによるコードの分析、EDR製品のインストール自動化、トラブルシューティングの際のAthenaクエリの汎用化などが、その一例だ。

「リスク・セキュリティ本部とのコラボレーションを通して実現する、高いセキュリティ基準と開発スピードの維持、そしてそれを実現するソフトウェア的思考の文化がある。それがPayPayで働く醍醐味だと思います」（斉木氏）

さまざまな質問が寄せられたQ&Aタイム

すべてのセッション終了後、Q&Aタイムが設けられた。いくつか抜粋して紹介する。

Q．チームビルディングで良好な関係を作るに、どんな取り組みをしているか

齋藤：大前提として、当社は在宅勤務をしています。メラビアンの法則によると、人間のコミュニケーションにおいて言語情報が7％、聴覚情報が38％、視覚情報が55％の割合で相手に影響を与えるとされています。

Slackでコミュニケーションしてもうまく伝わらないことがある。そういうときはZoomを使ったり、時間を取って直接会ったりして、気持ちを解きほぐすことをしています。もう一つメンバーに言っていることは、相手の言葉をまずは受け止めること。一旦、受け止めた上で、もしその意見と違うのであれば、自分の意見を言うようにすることを推奨しています。

斉木：メンター制度が用意されているのが良かったですね。当社はフルリモートなので、最初は誰がどの案件を担当しているのかもわかりませんでした。

申：ドキュメントもしっかり整理されているし、新しいメンバーが入ってきても既存のメンバーが緊密にコミュニケーションを取る文化ができています。私もすぐ慣れることができました。

Q．開発において、セキュリティを担保するために取り組んでいることは？

申：Atlantisを活用している話をしましたが、Terraformコードでインフラコードを管理し、CI/CDを通して反映しています。反映する前の段階で、リーダーがレビューをするほか、機械的なチェックを設けています。

Q．運用チームはテスト・運用保守など、それぞれ専門担当のメンバーなど配置しているのか。細かく専門担当など決めず、全てのメンバーで対応しているのか

齋藤：大事にしているのは、一人の担当者にすべて依存させないようにすること。リーダー+現場メンバーでタッグを組んでもらい、構築や運用に携わってもらっています。

Q．プルリクエスト作成に対するChatGPTによるコードの分析は、GitCopilotを使用しているのか？

斉木：ワークフローには組み込まれていないのですが、Terraformコードを書いたりする部分など、一部でCopilotを使用しています。かなり業務効率を上げられる可能性があるので、前向きに取り組んでいきたいと思います。

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

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

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