キャッシュレス決済サービス「PayPay」は、いまや「生活に欠かせないインフラ」と言えるほどに普及しています。その成長を支える重要な組織の一つが、社内向けの業務系システムの開発・運用を担うSystem Development部です。「金融系システムの開発」というと、レガシーな技術を用い、開発スピードが遅いイメージを持つ読者も多いかもしれません。しかし、System Development部ではローコードツールなどのモダンな技術も積極的に採用しており、時には数週間という短期スパンで新システムをリリースすることもあります。また、今後はAI Agentic IDEの活用も視野に入れています。System Development部 部長の藤田文彰さんに、開発方針や組織の取り組み、今後の展望を伺いました。参考記事：<a href="https://whatweuse.dev/article/paypay_system_division" target="_blank" rel="noopener noreferrer nofollow">生成AIやデータ分析も取り入れた内製開発の魅力。PayPayの事業成長を支える社内業務システム</a><h2 id="h3e52d94190">「内製開発」に徹底的にこだわる</h2>――System Development部の役割や業務内容について教えてください。私たちは、「PayPay」の事業を運営するうえで必要な業務システムの開発・運用を担う部署です。たとえば、マーケティングや営業、顧客対応といった社内業務を遂行するために必要なシステムを作っています。金融領域で事業を展開するうえで欠かせない、審査機能の構築も私たちの担当です。法人向けの審査に加え、ユーザーのeKYC（オンライン上での本人確認）システム、サービス利用中の途上審査、不正取引のチェックなどの仕組みを開発・運用しています。――金融系のシステム開発では、社内システムを外部委託するケースもありますが、内製での開発・運用を行う意図は何でしょうか？いくつか理由があります。まず、外部業者に委託する場合、プロジェクトの初期フェーズで要件を確定させる必要があるため、後からの仕様変更が難しくなってしまいます。PayPayの事業では、数カ月ほどでサービス企画や仕様が変わることも珍しくありません。柔軟なシステム開発が求められるため、外部委託では対応が難しいです。もう一つの理由は、事業運営に直結するシステムだからこそ、トラブル発生時に迅速な対応が求められる点です。開発を外部業者に任せすぎると、緊急時の即時対応が難しくなるだけでなく、システムがブラックボックス化して、自分たちで対応できなくなるリスクがあります。こうした理由から、私たちは内製化を推進しています。<h2 id="hf2ee354594">大切なのは「事業価値の創出」。それに適した技術を採用する</h2>――System Development部が、技術選定において重視していることは何でしょうか？私たちは技術を「事業価値を生み出すための手段」として捉えています。そのため、基本的には開発・運用のしやすさを重視し、チームメンバーにとって扱いやすく、実績のある技術を選定しています。一方で、特定技術を導入することでより大きな価値を創出できると判断した場合には、新しいものも積極的に採用しています。――具体的には、どのような技術を用いていますか？前提として、私たちの部署ではスクラッチ開発とローコードツールによる開発という2つのアプローチを取っています。そして、スクラッチ開発では、メインの言語としてJava、フレームワークにはSpring Bootを使用しています。インフラはAWSで、コンテナ技術を活用しておりAmazon ECS上でシステムを運用しているのが特徴です。また、AI関連技術としてAmazon SageMakerも導入しています。マネージドサービスを用いることで運用コストを抑えつつ、システム開発の速度向上や品質改善に注力しています。 一方、ローコードツールによる開発では、「OutSystems」というプラットフォームを使用しています。「OutSystems」はドラッグ＆ドロップでUIを構築できるほか、エンタープライズ向けシステムに必要なセキュリティ機能やAPI連携機能なども備えています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/88369ef440304cbda2f616ca88fd9ad6/image3.jpg" alt="" width="1999" height="1334"></figure>スクラッチ開発とローコード開発は、主に用途に応じて使い分けています。社員向けのツールでは、ローコード開発を選択することが多いです。ローコードでアプリのデータモデルと画面を構築したうえで、社内のニーズやユースケースに合わせてカスタマイズしています。一方、スクラッチ開発は大規模かつ複雑性の高いシステムに適用しています。また、開発の効率化を目的に、生成AIの利用も進めています。各プロジェクトでGitHub Copilotを導入し、コード補完やリファクタリングの自動化によって開発スピードを向上させています。さらに、AIエージェントのClineも社内で一部利用が認められており、今後さらに活用を進める予定です。ただし、金融領域での開発であるため、やみくもに導入を進めるのではなく、セキュリティやプライバシーとのバランスもかなり重視して方針を検討しています。<h2 id="hca36a368a5">必要最小限の機能を見極め、場合によっては“作らない”選択を</h2>――開発において大事にしている指針はありますか？開発の優先度を明確にし、必要な部分から段階的にシステムを成長させることです。たとえば、新しい取り組みを始める際に、最初から100点満点のシステムを目指し、業務フローも抜本的に変えようとすると、完了までにかなりの時間がかかります。まずは、システムが30点程度の状態でも、プロセスが回るならば十分だと考えています。そこから段階的にシステムを作り込み、100点にしていくイメージですね。これは、スピードと品質を両立するための戦略です。真の意味でシステム化が必要な箇所と、そうでない箇所を見極め、最小限の機能からスタートして段階的に開発を進めています。――具体的に、これまでのプロジェクトでどのような事例がありましたか？この考え方に沿ったプロジェクトとして、2024年に行った寄付・お賽銭の事例をご紹介します。もともと私たちは「PayPay」を通じて、「商品やサービスの対価としてお金を支払う」「個人間で送金する」といった機能を提供していました。そこからさらに、「寄付などのための送金機能を設ける」という構想が立ち上がりました。このプロジェクトでは、金融に関する各種法令を遵守しながら開発を進める必要がありました。加えて、既存の仕組みよりも厳格な審査プロセスの設計が求められました。資金洗浄や詐欺といった不正な取引に悪用されるリスクがあるためです。しかし、すべての要件を一度に実現しようとすると、大掛かりなプロジェクトになり、スピードが落ちてしまいます。こうした構想が進む中で、本サービスの利用を予定されていた最初のお客さまから、利用スケジュールについてのご相談がありました。そのスケジュールに間に合わせるために、サービスインのために最低限必要な機能を定義し、それ以外の部分は既存の仕組みを流用するとか手作業で補うという方針を取りました。具体的には、このプロジェクトでは個人情報や機密情報を扱うため、セキュアな環境で書類を扱うことが必須でした。これを、既存のシステムの仕組みを活用し、運転免許証やマイナンバーカードの画像をストレージに保存することで、開発工数を抑えたのです。その結果、予定通りのスケジュールでサービス稼働を間に合わせ、PayPayから募金を行えるようになりました。もう一つ、類似した事例として過去に取り組んだ自治体のキャンペーンがあります。このプロジェクトでは、「特定の県に住む人・働いている人」を対象としており、住民票や就労証明書を提出してもらう必要がありました。しかし、これまで「PayPay」には、こうした書類を受け取る仕組みがありませんでした。加えて、施策を実行するにあたっては設計や実装を2週間程度で終わらせる必要がありました。このプロジェクトには、大きく分けて「県内在住・勤務者から書類を受け取る」「書類を審査し、ストレージに格納する」「条件に合致する人を対象にキャンペーンの抽選を行う」という3つの処理が必要でした。すべてをシステム化すると2週間では間に合わないため、一度きりの処理は手作業でカバーし、何度もくり返し処理する部分のみを優先的にシステム化する方針を採用したのです。このプロジェクトでは、テックリードのメンバーを中心に、少数精鋭でシステム構築を進め、予定通り約2週間で開発を完了しました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8ec9c2fdd82d4c54a537db50c63f5adf/image5.png" alt="" width="1854" height="887"><figcaption>証明書アップロードから抽選、本人確認書類の審査、抽選結果通知までの業務フロー</figcaption></figure>――いずれのプロジェクトも、かなりのスピード感ですね。そうですね。かつ、スピードがあるだけではダメで、金融系サービスである以上はセキュリティやプライバシーの担保も欠かせません。そのバランスを常に考えながら開発を進めているのが、私たちの部署の特徴です。<h2 id="h040e1e0b2e">これまでの常識にとらわれず、積極的に越境してほしい</h2>――今後、System Development部として特に注力したいことはありますか？圧倒的な生産性向上です。前回、<a href="https://whatweuse.dev/article/paypay_system_division" target="_blank" rel="noopener noreferrer nofollow">システム本部長 兼 システム本部 AI活用推進室長の岡田が出演したインタビュー記事</a>でも解説していましたが、私たちは生成AIに注目しており、開発プロセスに取り組むことに積極的です。2025年度は、生成AIの活用を前提としてプロジェクトを推進したいです。余談ですが、生成AIの普及に伴い、エンジニアの役割もこれまでの「製造する」フェーズから「創造する」フェーズへと進化していると感じています。過去のやり方に固執せず、世の中の変化に適応しながら働く意識が重要だと考えています。――他の金融系サービスの企業と比較して、System Development部だからこそ得られる経験はありますか？まず、「PayPay」自体の事業成長のスピードですね。2018年にサービスを開始してから、現在はユーザー数7,000万人（2025年7月時点）を突破しています。これほどの速さで成長を続けている事業は、なかなかありません。また、System Development部では、ビジネスプロセス全体を俯瞰しながら開発を進めています。ビジネスの変化を最前線で体感しつつ、システムを開発・運用する経験を積めます。一般的に、金融系の企業は新技術の導入に慎重な姿勢を取ることが多いですが、PayPayでは柔軟にチャレンジできる環境が整っています。新しい技術に挑戦できる環境を求める方にとっては、非常に魅力的な職場だと思います。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/2518ad5f0c7d4a9e82cad6ff32b23d90/image4.jpg" alt="" width="1999" height="1334"></figure>――どのようなマインドの方が、System Development部にマッチするでしょうか？「今まで当たり前だったことを、当たり前だと思わない」という姿勢を求めています。要するに、これまでの慣習や成功体験にとらわれず、新しい領域に果敢に挑戦できる方。そのほうが、入社後に大きく成長し、パフォーマンスを発揮できると考えています。また、「自分の技術を過信しない」ことも重要です。自分の持っている知識やスキルが、今後も必ず正しいとは限りません。次々と新しい技術が登場するなかで、それらをどのように活用し、価値を生み出せるかを考えられる人であってほしいです。――最後に、読者へメッセージをお願いします。「PayPay」を盛り上げる気持ちを持つことに加えて、常にチャレンジする姿勢を大切にする方であればPayPayで活躍できると思います。また、メンバーには「私はエンジニアだからシステム開発以外はやらない」と考えるのではなく、積極的に領域を越境してほしいです。既存の役割だけに縛られてしまうと、将来的なキャリアの可能性が限定されてしまいます。新しいことに挑戦したいと思ったら、どんどん声を上げていくような積極性を持つ方と、ぜひ一緒に働きたいです。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

PayPay株式会社のSystem Development部ではローコードツールなどのモダンな技術も積極的に採用しており、時には数週間という短期スパンで新システムをリリースすることもあります。また、今後はAI Agentic IDEの活用も視野に入れています。System Development部 部長の藤田文彰さんに、開発方針や組織の取り組み、今後の展望を伺いました。

フルスクラッチだけではなくローコード開発も駆使。AI Agentic IDE利用も見据える。なぜPayPayの社内システム開発はスピードと品質を両立できるのか？

なぜ“優秀なメンバー”がTVerを選ぶのか？月間ユーザー数4,120万、今まさに再構築フェーズにあるサービスの舞台裏 民放公式テレビ配信サービス「TVer（ティーバー）」は、創業以来、右肩上がりで成長を続けてきました。2024年12月には月間動画再生数が4.96億回を突破し、2025年1月には月間ユーザー数（ユニークブラウザベース）で4,120万を記録*。名実ともに日本最大級の動画配信サービスのひとつとなっています。<blockquote>*…自社調べ。出典：「<a href="https://tver.co.jp/news/20250109.html" target="_blank" rel="noopener noreferrer nofollow">[TVer] 2024年12月の再生数　過去最高の4.96億回を記録</a>」「<a href="https://tver.co.jp/news/20250210.html" target="_blank" rel="noopener noreferrer nofollow">【TVer】2025年1月の月間ユーザー数 過去最高の4,120万MUBを記録</a>」。</blockquote>一見すると、事業・システム・組織のすべてがすでに整っているように見えるTVerですが、サービスプロダクト本部 副本部長 兼 バックエンド部部長の脇阪博成さんは「課題がたくさんある。むしろその課題こそが魅力でTVerに来た」と語ります。放送局・広告会社出身者に加え、メガベンチャーやスタートアップで実績を積んだ多種多様なバックグラウンドのメンバーが集まる企業。なぜ“優秀なメンバー”たちはTVerを選ぶのでしょうか。脇阪さんに、開発組織の現在の取り組みやこれからの挑戦について話を聞きました。<h2 id="h83cbd36c36">事業基盤が強固、かつエンジニアリングで解決できる課題が多い</h2>――脇阪さんはこれまで、株式会社ディー・エヌ・エーのエンジニアリングマネージャー、株式会社ZOZOの開発本部長、スタートアップのCTOなど、要職を歴任されています。なぜ、次なる挑戦の場としてTVerを選ばれたのでしょうか？前職のスタートアップでは、予算やリソースが限られた中でエンジニア組織の強化を進めていましたが、なかなかうまく成長させることができませんでした。それに加えて入社時に想定していた事業の方向性も変わったため、自身のキャリアを再考し、次なるチャレンジの場を探していました。複数の企業と採用面接を行いましたが、エージェント経由で紹介されたTVerの“課題”に強く興味を持ったことが大きな決め手でした。通常、採用面接では担当者が企業の良い面を話すものですが、TVerは「うちはここができていない」と赤裸々に語ってくれました。――具体的には、どのような課題だったのでしょうか？プロダクトはすでに一定の認知があり、事業の方向性も固まりつつあります。ですが、開発組織はまだまだ発展途上で、「成長を支えるマネジメント人材が足りない」という課題が伝わってきました。前職では、開発組織を大きくできなかったという反省があります。これは自分の力不足でもありますし、事業を軌道に乗せられなかったことも要因のひとつです。TVerはすでにプロダクトの成長が見込める状況にあるため、組織づくりに集中できると考えました。経営陣の多くも「現状に満足せず、さらにプロダクトを成長させたい」と語っており、そこにも大きな魅力を感じました。また、友人や元同僚にTVerの印象を尋ねてみると、「普段から使っているし、良いサービスだけれど、ここを改善してほしい」といった反応が多く寄せられました。ユーザーの生活に根ざしていて、かつ多くの要望がある。つまり、エンジニアリングが力を発揮できる余地がたくさんあるということです。私はもともと、難しい課題を解くのが好きな性格なので、課題の多い環境のほうが面白いと感じます。だからこそ、TVerは自分に合ったチャレンジができる場所だと思いました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/3b8c6d9e4c314222b6e1f4776a24c7de/image3.jpg" alt="" width="1999" height="1334"></figure>――入社後、開発組織ではどのような方針を掲げましたか？「品質とスピードの両立」をミッションとして掲げました。というのも、現在のシステムには古いコードも多く、手を加えると他の部分にバグが発生してしまうケースがあります。その結果、障害が起き、影響範囲の調査や修正対応、場合によっては謝罪対応まで求められることになります。こうした対応により、ユーザーへ価値を届けるまでの時間が長くなってしまう。これが大きな課題でした。そこで現在は、「技術」「組織」「開発プロセス」の3つの切り口で改善を進めています。まず「技術」面では、フロントエンド・バックエンド・インフラのリアーキテクチャに取り組むとともに、自動テストの追加やQAの強化を進めています。QAについては、いわゆる「シフトレフト」を実践し、要件定義の段階から品質やセキュリティを意識しています。次に「組織」面です。これまではプロジェクト単位で人が集まり、終われば解散するという流動的な体制だったため、ナレッジの蓄積が困難でした。今後はチームをある程度固定化し、プロダクトマネージャーやデザイナーも含めたクロスファンクショナルな体制で、チーム単位にミッションを持たせて動く方針に変えています。最後に「開発プロセス」について。以前はプロジェクトの進め方が各メンバーに委ねられていたため、ばらつきによって進行に支障が出るケースがありました。そこで、ドキュメントの標準化や開発プロセスの整備を進めることで、最終的には品質とスピードの両立につなげたいと考えています。<h2 id="hca9f7c9703">現場の裁量の高さゆえに、リアーキテクチャの決断も高速</h2>――それらの改善について、具体的な事例をピックアップしてお話しいただけますか？システムのリアーキテクチャについてお話しさせてください。社内で「枠切れ」と呼んでいる事象があります。これは地上波放送の番組が終了した後、「TVer」で引き続き視聴できる場合に、ユーザーからのアクセスが一斉に集中する現象のことです。これに対して同時接続数を事前に予想し、多めのサーバー台数を立ち上げて待ち構えていたのですが、それでも突発的なスパイクには耐えられなかったり、または逆に想定していたよりもアクセスが来ずコストの無駄が大きくなったりして、この状態を継続するのは厳しいと感じていました。また、アプリケーション内ではパフォーマンス向上のためにキャッシュ処理を導入していたのですが、その処理も次第に複雑化していました。対応方針を考えていたところ、CTOから「より良い設計になるように、作り直したらいいんじゃない？」という提案があったんです。「それ、アリですか？ ではやります！」となり、現場のリーダーたちと集まって方針を議論し、翌週にはリアーキテクチャを直ちに開始することが決まりました。一般的に、ある程度の規模のサービスではリアーキテクチャの決断に至るまでの計画段階で相当な時間がかかります。こうしてスピーディーに動けたのは、TVerの開発組織における柔軟性や現場の裁量の高さが影響しており、大きな方向転換も即断即決で進めることができました。――たとえばインフラがどのように変わるのか、ピックアップしてお話しいただけますか？現状、インフラの技術スタックとしてはAWSのマネージドサービスを主に活用しており、アプリケーションサーバーはAmazon ECS、データベースはAmazon Aurora MySQL、検索にはAmazon OpenSearch Serviceなど、オーソドックスな構成です。ただし、現在のアーキテクチャでは急激なスパイクが発生した際にオートスケールが間に合わないケースがあるため、リアーキテクチャ後はCDNによるキャッシュ構成の導入を検討しています。前述のアプリケーション内でのキャッシュは実装が複雑になるという課題があったので、そちらの課題を合わせて解決するという狙いもあります。CDNキャッシュも万能ではありませんが、「TVer」のトップページは、一部ユーザー向けの出し分けはあるものの、基本的には同一のコンテンツです。だからこそ、キャッシュが効果的に機能すると考え、このようなアーキテクチャにすることに決めました。また、これとは別に急激なスパイクにもスケールが可能なように、インフラ面でのリアーキテクチャも検討しています。<h2 id="h3cc0f74fce">「チームとしての目標がない」状態からの、SREチーム再構築</h2>――他の事例についても教えてください。直近の半年ほどで、組織体制を変更していった事例についてお話しします。私がバックエンド部の部長に就任したのは2024年4月です。就任後しばらくして、SREチームには「チームとしての目標がない」という課題があると感じました。目の前の必要なタスクには対応できていたものの、チームとして何を重視し、どのような状態を目指すのかが明確になっていなかったんです。とはいえ、私自身はもともとSREのバックグラウンドがあるわけではなく、どんな目標を設定すればよいか迷っている状況でした。そんなとき、採用活動に注力していたところ、2024年10月にマネージャー候補のメンバーが入社しました。その方と議論を重ねる中で、「今の組織の状況を踏まえ、まずは品質改善に注力しよう」と方針を決定しました。2024年度の上期に発生したトラブルを、Slackの投稿やポストモーテムの記録から洗い出した結果、半年間で相応の件数の配信トラブルが起きていたことがわかりました。実際には、より小規模な障害も数多く発生していたはずです。サービスの信頼にも関わる部分ですし、一度ここで「血を止める」必要があると感じました。そこで、「配信トラブルを○○件まで減らす」「トラブル発生時の影響時間を○○まで短縮する」といった具体的な目標を立て、その実現に向けて「アラート情報の整理」や「重要情報のログ出力」といったタスクへ落とし込んでいきました。この施策を進めている間、SREチームのリソースが不足し、開発チームからのインフラ関連の要望に応えられなくなる可能性もありました。そこで、開発チームにAWSのIAM権限を付与し、組織全体の生産性に影響が出ないような方針を取りました。――この記事はSRE候補の方も読まれるはずです。そうした方に、どのような役割を期待されていますか？お願いする内容は、その方のスキルセットによって異なりますが、大きく3つの領域があります。1つ目はインフラ構築で、DevOpsチームの強化を進めています。2つ目はオブザーバビリティで、ダッシュボードやSLOの整備が課題です。3つ目はセキュリティで、セキュリティ関連業務の標準化・自動化や、脆弱性対応をリードできる方を求めています。また、インフラだけに特化している方よりも、アプリケーション開発の経験がある方が望ましいですね。TVerのSREチームは、今後ものすごく大規模にする予定はありません。だからこそ、個々のエンジニアの役割を完全に分けるのではなく、必要があれば領域を越境するような体制にしていきたいと考えています。SREのメンバーにも、アプリケーションのコードを読み、ときには修正してPull Requestを出せるような方に来ていただけると理想的です。<h2 id="h6492f2051a">優秀な人たちにとっての「ちょうどいい」チャレンジの場</h2>――ではここから、採用候補者向けの質問です。いわゆるWebサービス系の企業と比べたとき、TVerならではの面白さや特徴があれば教えてください。TVer社内には、放送局や広告会社出身の人や、放送局や広告会社から出向で参画している方が多く在籍しており、一般的なIT企業とは少し毛色が異なるところがあります。一方で、中途採用で入社してきた方々は、メガベンチャー出身者やスタートアップでCTOを務めた経験のある方など、幅広い経歴の持ち主が集まっています。この規模の会社としては人材の多様性が際立っており、それがTVerの組織としての面白さだと思います。サービス面では、ユーザー数の多さがやはり特徴です。日々、フィードバックが山のように届くんですよ。自分たちの取り組みの影響範囲が大きいですし、TVerという会社でしか見えない世界があります。――有名企業を経験してきたような、いわゆる“優秀な人たち”が、TVerに惹かれる理由は何でしょうか？やはり、課題が多いという点に惹かれる方は多いですね。余談ですが、最近入社した開発組織のマネージャーたちに話を聞いたところ、「TVerはいろんな意味でちょうど良い」と言っていました。要するに、組織のサイズやサービスのフェーズが程よく、なおかつ社会的意義のある事業を提供している。それらを魅力に感じているようです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b2e818f622cc4cc3a2e1f12dd1cd52bf/image1.jpg" alt="" width="1999" height="1334"></figure>――どういった要素を持ったエンジニアを、組織としては求めていますか？私が採用基準として重視しているのは、笑顔があることです。これは単にニコニコしているという意味ではなく、「相手とより良い会話をしようという気持ちがあるかどうか」です。良いプロダクトをつくるには、さまざまな方と協力することが不可欠ですから、そうしたやり取りを自然にできる人を求めています。そして、「TVer」というサービスと真剣に向き合い、成長させていきたいという思いがあること。そのために必要な手段は問いませんが、自分の専門領域はしっかり持っている。そういう人と一緒に働きたいと思っています。また、エンジニアはつい「要件をはっきり決めてください」とか「納期はいつですか」と言いがちですが、そうした考え方をしないこと。未確定な要素があるのであれば、みんなで一緒に考えていくというスタンスが大切です。他にも、できればtoCサービスの開発経験がある方が望ましいです。要するに、事業会社で自社サービスを開発・運用した経験があること。受託開発とは異なり、サービスは出して終わりではなく、そこからがスタートです。ユーザーの声を聞きながら改善していく経験が重要だと考えています。――TVerにジョインしたエンジニアが得られる成長機会について教えてください。TVerでは、裁量を持って自ら考え、自ら動くことができます。自分の担当領域にとどまらず、周囲を巻き込みながら動ける。それが大きな成長の機会になると思います。そして何より、社会的な影響力の大きいサービスの中で、それを実践できるという点が魅力です。組織としても失敗を許容しながら前に進む文化がありますし、優秀なマネージャーがそろってきているので、チャレンジしやすい環境が整っています。きちんと自分で動ける方であれば、ご自身が描くキャリアをTVerの中で実現できると思います。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

放送局・広告会社出身者に加え、メガベンチャーやスタートアップで実績を積んだ多種多様なバックグラウンドのメンバーが集まるTVer。
サービスプロダクト本部 副本部長 兼 バックエンド部部長の脇阪博成さんに、開発組織の現在の取り組みやこれからの挑戦について話を聞きました。

なぜ“優秀なメンバー”がTVerを選ぶのか？月間ユーザー数4,120万、今まさに再構築フェーズにあるサービスの舞台裏

1994年に初代のコンソールが発売されて以来、世界中のゲームユーザーから愛される製品となったPlayStation。PlayStation事業に欠かせないものとしてPlayStation Networkがあります。これはPlayStationから接続できるオンラインネットワークサービスであり、世界中のプレイヤーとのオンライン対戦や協力プレイ、デジタル版のゲーム・追加コンテンツの購入・ダウンロード、他のプレイヤーとのやりとりなどが可能。オンラインの強みを活かした機能を有しています。PlayStation Networkは世界でも有数のユーザー数やトラフィック規模を誇るネットワークサービスであり、開発・運用に携わるエンジニアの腕が試される環境です。また、自分たちの作ったネットワークサービスを世界中のユーザーに使ってもらえるという、やりがいの大きい仕事でもあります。今回はPlayStationのハードウェア、ソフトウェアおよびサービスの企画・開発・製造・販売を手掛ける、株式会社ソニー・インタラクティブエンタテインメントの方々にインタビュー。PlayStation Networkにおけるユーザー向けアクティビティサービスのサーバサイド開発のシニアマネージャ―の西海持 雅隆さんとパートナー向けサービスのプロダクトオーナー・チームリードの宗像由さん、パートナー向けサービスのテックリードの半田祐一さん、プッシュ通知やキャッシュ機構のサーバーサイドエンジニアの濱野拓人さんに、プロジェクトの事例や仕事の面白さなどを聞きました。<h2 id="h8e0fd8cb05">ハードウェア・コンテンツ・ネットワークという3本の柱</h2>――ソニー・インタラクティブエンタテインメントの事業の特徴をお話しいただけますか？西海持：ソニー・インタラクティブエンタテインメントは、PlayStationのハードウェア・ソフトウェアおよびサービスの企画・開発・製造・販売を手掛けており、現在は2020年にローンチしたPlayStation 5と2024年に発売したPlayStation 5 Proを重点に提供しています。PlayStationのビジネスにはハードウェア、コンテンツ、ネットワークという3つの重要な要素があります。私たちの部署はネットワークの要素を担当しており、オンラインでのマルチプレイやダウンロードコンテンツなどで付加価値を提供し、新たなユーザー体験を作り出すことが、私たちのビジネスの強みであると考えています。2024年9月30日時点で、PlayStation Networkの月間のアクティブユーザー数は1億1600万人を超えており、相当に規模の大きなネットワークとなっています。――どのような組織体制で開発を行っていますか？西海持：私たちの開発拠点は、グローバル各地に展開されています。本社はカリフォルニア州のサンマテオ市にあり、拠点はカリフォルニア州の別の場所とロンドン、東京をはじめ各国にあります。PlayStation Networkのサービス開発は、グローバルなチームで密にコミュニケーションをしながら進めています。宗像：さまざまな文化・国籍の人が所属していますし、家庭環境もそれぞれ違いますから、すべての人が働きやすいようにダイバーシティ、エクイティおよびインクルージョンの推進にも積極的です。私自身が2児の母なのですが、育児と仕事のバランスを取りながら生活できています。規模の大きな会社ですと「エンジニアの技術的な裁量があまり無いのでは」と思われる読者もいるかもしれませんが、決してそんなことはありません。たとえば、PlayStationの開発に合わせてアーキテクチャを抜本的に変えたことも過去にはありましたし、サーバーサイド開発だけをやっていたエンジニアがインフラにも携わったりするなど、チャレンジの機会が数多くあります。<h2 id="h4aea5ad969">クラウドネイティブなアーキテクチャへの刷新</h2>――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的・組織的な意思決定の事例について語っていただいております。みなさんそれぞれから、エピソードをいただけますか？<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/071ab74b0888493699a5a6163e37ea6b/image5.jpg" alt="" width="2000" height="1334"><figcaption>半田祐一さん</figcaption></figure>半田：先ほど宗像から技術的な裁量の話がありましたので、関連する話をさせてください。私の担当する「サブミッション」というサービスは、ゲームを開発するデベロッパー（ゲーム開発者）の方々からゲームパッケージを受け付けて、ファイルの変換処理を行い、世の中にゲーム発売するという一連の流れを担当します。かつては、オンプレミスのサーバーを100台規模で抱え、処理に余裕がなくなればさらにサーバーを購入・調達するという運用を行っていました。この運用はサーバーの物理的な管理が非常に大変なので、アマゾン ウェブ サービス（AWS）のAmazon Elastic Compute Cloud （Amazon EC2）が使えるようになったタイミングで、サーバーのクラウド移行を実施しました。ただ、ここでは単に物理サーバーが仮想マシンに置き換わったというだけで、まだまだ改善の余地がありました。そこで、PlayStation 5がリリースされるタイミングで、クラウドネイティブなアーキテクチャへと刷新することを決めました。アーキテクチャのうち一部分をピックアップして説明しますと、デベロッパーの方々からパッケージを受け付ける箇所はAWS Transferで対応しています。受け取ったパッケージはAmazon Simple Storage Service（Amazon S3）で管理。それらに対してバリデーションやファイル変換などの処理を行うわけですが、そうしたワークフローはAWS StepFunctionsで構築しています。実際の処理は、規模の小さなものはAWS Lambda、規模の大きなものはAmazon Elastic Kubernetes Service（Amazon EKS）で対応していて、スケールしやすい仕組みです。仮に処理の量が増えても、エンジニアがサーバーを増強するなどの対応をする必要はありません。私はこのプロジェクトに携わる前までは、インフラの構築・運用の経験がなかったものの、そうした領域に携わるチャレンジができました。――濱野さんからもアーキテクチャ関連の事例をお願いします。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/747e9b7872114150a031c8d4786b5dd0/image1.jpg" alt="" width="2000" height="1334"><figcaption>濱野拓人さん</figcaption></figure>濱野：私たちのチームはキャッシュサーバーの開発・運用に携わっています。PlayStation Networkには1億1600万人の月間アクティブユーザー（2024年9月30日時点）ユーザーがいますから、もし仮にデータベースのマスタデータに毎回アクセスする仕組みにすると、システムの負荷が高くなってしまいます。そこで私たちは、キャッシュサーバーにマスタデータの情報などを蓄積し、キャッシュを返却する仕組みを構築しています。キャッシュサーバーは歴史のあるサービスであり、もともとはAmazon EC2でAPIを動かし、キャッシュはMemcachedに蓄積していました。ですが、このアーキテクチャですと運用の負担が非常に大きいんですね。そこで去年、アーキテクチャの移設を行いました。Amazon EC2からAmazon EKSに置き換えて、かつキャッシュもMemcachedではなくAmazon ElastiCache for Redisに蓄積する方針を選びました。これだけだと「ただ採用する技術を入れ替えるだけか」と単純な話に聞こえるかもしれませんが、実はそうではありません。このキャッシュサーバーには、10万rpsを超える規模のアクセスがあります。万が一、移設に際してトラブルが起きると影響が大きいんです。――10万rps……。一般的なWebサービスの運用ではまず経験できない規模ですね。濱野：そこで移設前に検証用の環境で本番環境相当の負荷を実際にかけて、問題なくパフォーマンスを発揮できるか負荷試験を行いました。うまく性能が出ない部分については、チーム内外の優秀なエンジニアたちに相談をしたり、サーバー監視サービスで細かくメトリクスを見てパフォーマンスチューニングをしたりして改善を重ね、何十回もの負荷試験を経てようやく十分な性能に達しました。世界中で使われるPlayStation Networkの開発・運用に携わるからこそ、こうした経験を積むことができています。<h2 id="h799f644dfe">各国のチームと力を合わせ、ユーザー体験を改善する</h2>――宗像さんや西海持さんには、組織運営やプロジェクトマネジメントに関することをお聞きします。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/7ab8a0a3bea34320b0bc3096370bcfd7/image3.jpg" alt="" width="2000" height="1334"><figcaption>宗像由さん</figcaption></figure>宗像：「サブミッション」サービスの改善についてお話しさせてください。かつて、初代PlayStationやPlayStation 2の時代にはゲームのダウンロード販売は行っておらず、ゲームを開発するデベロッパーの方々からゲームの情報が入ったDVDなどのメディアを郵送してもらい、納品を行っていました。PlayStation 3になるとデジタル配信を行うPlayStation Storeができて、納品フォーマットもダウンロード用のデジタルデータとディスクといったように種類が増えました。効率的に運用をするために、PlayStation 4ではバラバラだった納品用のパッケージフォーマットを、1つにして提出可能にするプロジェクトを推進したんです。ただ、これでもまだデベロッパーの方々の大変さは軽減されていませんでした。それはどういうことか説明すると、世の中はグローバル化が進んでおり、PlayStationで遊べるゲームも世界の複数の国で発売されるケースが増えています。過去の「サブミッション」サービスはそれぞれの国・地域ごとにシステムが分かれており、複数の場所でゲームを販売したければそのすべてに納品用のパッケージを作成し、提出する必要がありました。また、国や地域によって法律なども違うので、ゲームそのものの中身を変える必要も生じます。――かなり煩雑な対応が求められたわけですね。宗像：そこで、PlayStation 5からは、日本だけではなく世界各国の拠点とも連携を取りながら、運用を効率化できるよう、システムの仕様を考えていきました。この事例が典型的な例なのですが、私たちは日常的に国内外のメンバーとコミュニケーションを取りながらプロジェクトを進めます。多種多様な人たちと働きたいとか、グローバルで使われるプラットフォームを開発したいという方には、すごく適した環境です。また、ゲームのエンドユーザーだけではなくゲームを開発するデベロッパーの方々にとっても、使い勝手が良くユーザー体験に優れたシステムの提供を目指しているのも、大きな特徴になります。PlayStation 4では、デベロッパーの方々は3カ国でゲームを販売する場合に3種類のパッケージを作成する必要があったのが、PlayStation 5からはゲーム情報の共通部分と各国の差分をまとめたファイルを1つだけアップロードする、より効率的な仕組みになりました。――西海持さんはいかがでしょうか？<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/50019bf1ecb54eccb0a16ecd7201fc34/image2.jpg" alt="" width="2000" height="1334"><figcaption>西海持 雅隆さん</figcaption></figure>西海持：PlayStation 5のホーム画面でコントローラーのPSボタンを1回押すと、画面の下にメニューが表示されます。これはコントロールセンターという機能なのですが、このなかにユーザーがどのような行動を取れるかを示すアクションカードがあります。PlayStation 5のリリース前の段階で「PlayStation Networkでイベントが発生してから、アクションカードに反映されるまでの速度を速くしたい」という要望が、社内で挙がりました。目標となった時間は具体的な数字はお伝えできないのですが、ユーザーの快適さを実現するために野心的な数字を目標値としています。この数値を改善するのはかなり大変でして、なぜならアクションカードへの反映までに複数のチームのシステムが関与しているからなんです。イベントを発行するシステムや、それをリソースに反映するシステム、そのイベントを誰に届けるかを判定するシステム、プッシュ通知によってユーザーに情報を知らせるシステム、実際にユーザーのアクションカードに情報を届けるシステムなどがあり、それらを別々のチームが開発・運用しています。このプロジェクトにおいてソニー・インタラクティブエンタテインメントの強さを感じたのが、それぞれのチームが自己組織化されているということです。アーキテクトが実現したい目標について共有し、方針策定をしたところ、特定のメンバーだけではなくみんながオーナーシップを持って「このような方法があるのではないか」というアイデアを提案し、改善を続け、最終的には無事に目標数値を達成できました。<h2 id="h2961ca933b">エンジニアの仕事を通じて世界中にインパクトを与えられる</h2>――ソニー・インタラクティブエンタテインメントでは、サーバーサイドエンジニアを積極的に採用していると伺っています。優秀なエンジニアにとって、PlayStation Networkの開発・運用に携わる面白さはどのような点にあるでしょうか？濱野：今回の事例でもインパクトのある数字がいくつか出てきましたが、これほど規模の大きなデータやトラフィックを扱える会社はあまり多くはありません。それから私が入社して感じたのは、これはエンターテインメントの会社であることも影響しているかもしれませんが、優秀かつフレンドリーな方が多いということです。困ったときはみんなでアイデアを出し合うので、チーム全体で成長して成果を出す文化が醸成されています。西海持：システム開発だけではなく、ビジネス環境の変化もすごく速いです。変化を受け入れて、それを楽しめる人にとってはすごくおすすめです。また、自分のやった仕事が真の意味で世界中にインパクトを与えられるのは貴重な体験ですね。そして私にとって何より大切なポイントは、妻もゲームが好きなので、私たちが何かを作るとそれを家族に喜んでもらえるということです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/a5a49a0abf1e4d1c82a248307123a752/image4.jpg" alt="" width="2000" height="1125"></figure>――ソニー・インタラクティブエンタテインメントならではの魅力がたくさんありますね。では最後に、御社への応募を考えている方に向けてメッセージをお願いします。半田：新しい技術を積極的に取り入れて、自分たちのサービスをさらに改善しようという思いを持ったエンジニアたちが働いています。優秀で向上心を持った方と、一緒に働いて成長していきたいです。宗像：この会社ではフルスタックな開発が経験できますし、先ほどの話にもあったようにグローバルで密に連携を取りながらものづくりができます。私もそうであるように、多種多様なライフスタイルの方が働きやすい環境がありますし、各々の意見が重視される文化も魅力的です。濱野：PlayStation Networkのように、世界規模で使われるネットワークサービスの開発は非常に面白いです。自分の携わった仕事が世の中に影響を与えていると実感できるので、興味を持たれた方はぜひ応募してみてください。西海持：みなさんが言ってくれたように、この会社だからこその魅力があり、そこに共感していただける方と一緒に働きたいです。エンジニアとしてチャレンジしたいこと、今後のキャリアで実現したいことがあるならば、ぜひ力を発揮する場所としてソニー・インタラクティブエンタテインメントを選んでください。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

PlayStationのハードウェア、ソフトウェアおよびサービスの企画・開発・製造・販売を手掛ける、株式会社ソニー・インタラクティブエンタテインメントの方々にインタビュー。プロジェクトの事例や仕事の面白さなどを聞きました。

月間アクティブユーザー数・1億人以上。世界規模のネットワークサービス開発の妙味

登録ユーザー数6,700万人以上*。日本の人口の約2人に1人以上が利用するキャッシュレス決済サービス「PayPay」は、いまや「生活に欠かせないインフラ」と言えるほどに普及しています。加えて、決済にとどまらずクレジットカードや銀行、証券、保険などを「PayPay」ブランドに統一し、金融Platformとして事業を拡大しているのです。そんな「PayPay」の特徴として、社内システム開発組織であるシステム本部の強さがあります。社内業務システムの開発・運用や各種ツールの導入、コーポレートIT業務などを担うこの部署は、企業の体制強化をけん引し、事業成長を支えてきました。また、フルクラウドのインフラ構築や業界最先端技術によるeKYCシステムの開発、AI・機械学習やデータ分析、ローコード開発プラットフォームを活用した高速アプリ開発など、数々の技術的な挑戦も続けています。PayPay株式会社のCIO Product統括本部 システム本部長 兼 システム本部 AI活用推進室長である岡田寛史さんに、部署の魅力やこれまでの事例、今後の展望を聞きました。*…2024年12月末時点。<h2 id="h72ffa142a7">社内システムの改善を通じて、事業の成長を支える</h2> ――システム本部の構成や、各部署の役割について聞かせてください。システム本部のなかには、Corporate IT部とSystem Development部、PMO部、System Platform部、SFA&amp;CRM部、Data Management部、AI活用推進室、IT戦略室という8つの部署が存在しています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/7352cc1b0c0f4f6991afaf3395abc5d9/%E7%B5%84%E7%B9%94%E5%9B%B3.jpg" alt="" width="1200" height="648"></figure>Corporate IT部は社員が使用するPCやiPhoneなどのデバイスキッティングや社内の問い合わせ対応、会計/人事システムの構築運用、各種SaaSツールの導入・運用といった、全従業員が使用するツールやコーポレート業務に必要なツール機能を提供するうえで必要な仕事をしています。System Development部は社内で使用する業務系システムの開発・運用を担います。インフラはAWS・GCP、主なプログラミング言語はJavaを使用して、各部門のニーズに合ったシステムを作る部署です。PMO部はSystem Development部が着手する案件のロードマップ策定やプロジェクト推進を行います。System Platform部は、いわゆるSREの役割でありシステムの信頼性や可用性に責任を持ち、マルチクラウドで構成された各種のインフラを管理しています。SFA &amp; CRM部はSalesforce活用を推進する部署です。PayPayでは大きく分けて、2種類の業務でSalesforceを使っています。まず、「PayPay」の加盟店を開拓する営業社員が営業活動を記録する用途。そして、「PayPay」のユーザーや加盟店からの問い合わせを管理するCS用途です。Data Management部は全社データ分析基盤の構築・管理、AI活用推進室は生成AIを用いた社内システム/ツールの開発や利活用推進、IT戦略室はITガバナンスの策定・実行、コストコントロールなどを担います。――システム本部は、2024年9月以前はコーポレート統括本部に属する組織でしたが、2024年10月よりProduct統括本部の配下に移られたと伺っています。この変更にはどのような理由があったのでしょうか？PayPayが設立されたのは2018年6月で、まだ人間で言えば6歳の会社です。そして、私が入社したのは2019年で、当時はまだコーポレート機能を提供するためのツールや仕組みがほとんど整っておらず、会社の成長を支えるためのシステムを早急に整備する必要がありました。参考 : <a href="https://insideout.paypay.ne.jp/2022/09/26/leader-interview_vol07-jp/" target="_blank" rel="noopener noreferrer nofollow">CIOが語る PayPayの事業スピードを支える社内業務システム開発</a>ここのところ、そうした社内基盤の整備にある程度の目途がついてきました。そして最近は、PayPayプロダクト開発チームと連携をするようなシチュエーションが増えています。たとえば、「PayPay」のユーザー情報やトランザクション情報をプロダクトインフラから安全な形で共有してもらい、システム本部側で審査アプリケーションに利用する、などです。そこで、プロダクトとの連携をより強化しようということで、2024年10月から体制を変更しました。――社内の業務からプロダクトとの連携まで、幅広い領域をカバーする部署なのですね。そうですね。他にも、システム本部の特徴として内製化へのこだわりが挙げられます。PayPayは創業当初から「事業のコアになる部分は内製する」という意識が強く、システム本部も同じような考え方をしてきました。スピードを意識した事業展開と「まだ世にないサービス」を創ることに本気な会社だからこそ大切にしている考えです。そして、2018年創業の新しい会社ということもあり、積極的にモダンな技術を採用しているのも特徴です。もちろん、内製よりも既存のSaaSを導入したほうが利点が大きい領域もあるので、そうした場合は積極的に活用しており、その方針は都度判断しています。また、最近ではPayPayカード株式会社が2022年10月にPayPayグループの一員になりましたが、私たちよりも会社としての歴史が長いため部分的にレガシーシステムも残っています。そこで、システム本部のメンバーたちにPayPayカードへと出向してもらい、先方のエンジニアとともにアーキテクチャ刷新などの技術的な改善を推進しているところです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5109fabbf2dd468484b52d2e2c8bd4eb/image1.jpg" alt="" width="1999" height="1334"></figure><h2 id="h0296da4ef9">eKYCのリードタイムを数日→数分に短縮。セキュリティ・パフォーマンスの両方が求められた</h2>――システム本部では、積極的に新しい技術を取り入れているということですが、その特徴が表れているようなプロジェクトの事例はありますか？eKYCの審査システムについてお話しします。免許証の画像などを用いる従来型の本人確認のプロセスでは、免許証に記載されている顔写真と、本人が提出したセルフィー画像を比較することで、提出者が本人であるかを確認します。この写真の真贋判定に画像認識のAIを用いたり、免許証の住所・氏名の画像情報をテキストに変換する処理にAI-OCRを用いたりといったことを創業間もない頃から行ってきました。これに加えて、マイナンバーカードのICチップに格納された情報を利用するeKYC審査システムを3年ほど前に構築しました。先ほど述べた従来型では、本人確認プロセスの一部にサードパーティー製のシステムを使用していました。業務プロセスやシステムの制約上、審査のリードタイムが数日ほどと長くなっており、ユーザーのみなさまにご不便をおかけしていたんです。そこで、ICチップ読み取り方式のシステムを業界に先駆けて導入し、本人確認リードタイムを短縮する方針にしました。この審査システムではプロダクト側のデータやインターフェース連携も必要でしたので、部署をまたいだコラボレーションが発生するプロジェクトでした。また、「PayPay」のユーザー規模は膨大なので、サーバーの負荷対策や冗長化、クエリ最適化などの細かなチューニングも行う必要があり、技術的にもチャレンジングだったと感じます。加えて、eKYCで受け取るユーザーの個人情報というのは機密性が非常に高いデータですので、厳格に管理をする必要があります。そこで、プロダクト側が管理しているセキュア環境にデータを保持し、システム本部のアプリケーションから安全に情報連携できるようなアーキテクチャを構築しました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/1d158cead2a5464e90d6a4c1bff7b8e5/image2.png" alt="" width="1189" height="538"></figure>①本人確認の申請②オペレーターによる審査③確認書類はセキュアな環境にデータを保持④AIによる審査プロセスの自動化このシステムによって、本人確認プロセスの審査リードタイムは数日から数分に短縮できましたし、この事例以降はプロダクト側と連携しながら機微なデータをセキュアに管理しながら、連携先システムで安全に業務活用するケースが増えています。<h2 id="h8045541ade">eKYCを軸とした、新サービス開発を支える業務システム作り</h2>また、「PayPay」の本人確認済みユーザーは現在3,200万人（2024年11月時点）を超えていますが、2024年2月からはこの「PayPay」アプリの本人確認済み情報と連携することで、「PayPay銀行」と「PayPay証券」の口座開設手続きが大幅に改善する<a href="https://about.paypay.ne.jp/pr/20240205/01/" target="_blank" rel="noopener noreferrer nofollow">ユーザー体験を実現</a>しています。これは、システム本部の開発した業務システムがPayPayグループのユーザー獲得に貢献できている、象徴的な機能だと思っています。加えて2024年8月から、寄付団体や寄付サービス運営企業が「PayPay」の法人向けビジネスアカウントを開設し、本人確認済みユーザーが<a href="https://about.paypay.ne.jp/pr/20240819/01/" target="_blank" rel="noopener noreferrer nofollow">オンライン寄付を行うことができる</a>ようになりました。さらに、2024年12月からは一部の神社や寺院などでの<a href="https://about.paypay.ne.jp/pr/20240819/01/" target="_blank" rel="noopener noreferrer nofollow">お賽銭でも利用できる</a>ようになりました。システム本部は、こうした一連の新サービスをユーザーに安心してご利用いただけるようにするための、企業や団体に対する厳格な審査業務や取引モニタリング、不正検知などを行うための業務システムの開発にも深く関わっています。こうした例はほんの一部ですが、いままでなかった新サービスをユーザーに届ける機会に直接的に関われることは、技術者として本当に幸せなことだと思います。<h2 id="hefdf1ec41d">生成AIを活用し、データ分析や営業業務の最適化を行う</h2>――業務プロセス改善を実施した別の事例はありますか？2年ほど前から、業務への生成AIの導入を積極的に行ってきました。生成AI活用による全社横断のプロジェクトを発足させ、各部のメンバーたちに参加してもらいました。そのうちシステム本部のメンバー数名が開発を担当し、それぞれの部の意見を聞きながら、各部のユースケースをもとにシステムを作っています。社内システムは「作って終わり」ではなく現場とのコミュニケーションを通じた改善でなければならないので、一体感を大事にしました。――すでに実現できているシステムについて、詳しく教えてください。Slackでの投稿を経由してLLMのAPIを呼び出し、DWHやRAGに格納された各種の社内データを参照して回答を返す仕組みを構築しています。営業社員が調べものをする際にSQLすら書く必要がなく、Slackで「○○店の2024年の売り上げを月次で知りたい」とか「○○に提案営業したいのですが、最適な営業ルートを教えてください」などと投稿するだけで、適した答えが返ります。現在はさらに、Salesforceの画面から生成AIアプリケーションを直接利用して業務効率化を図る仕組みを構築しています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/803ba15709e74b51be53689311b48ada/image3.jpg" alt="" width="1999" height="1334"></figure>――積極的に業務改善に取り組まれているのですね。これはPayPayの企業文化ですね。ご存じの方も多いかもしれませんが、PayPayは創業以来、とてつもないスピードで加盟店や利用者の数を増やしてきました。組織の成長よりも事業の成長のほうが圧倒的に伸び率が大きいんですよ。だからこそ、業務を常に効率化していかなければ、事業グロースの足枷になってしまいます。一方で、新しい仕組みの導入のような攻めの施策だけではなく、セキュリティを堅牢にするための守りの施策も絶対に手は抜きません。我々が扱っているのはお客様の大事な金融資産やデータなので、高いセキュリティ水準が求められます。その両方に決して手を抜かない、ユーザーが安心して使っていただける社会インフラの構築を体験できるのは、PayPayならではだと思います。<h2 id="h3ceb8f3971">日本のIT企業で、これほど恵まれた環境はそうそうない</h2>――岡田さんは、システム本部のメンバーを採用する際に、どのような要素を大事にしていますか？技術や専門性のマッチングは現場の部長陣の意見を信頼していますので、私はどちらかといえばカルチャーフィットやメンタリティを見ています。具体的には、背中を預けても大丈夫な人かどうか。たとえば、過去のプロジェクトで課題に直面したときや、失敗したプロジェクトから何を学んだかといった、ハードシングスに直面した時の行動や反応を確認するようにしています。なぜかというと、新しいことに挑戦するプロジェクトでは、トラブルは少なからず起こるんですよね。だからこそ、ある程度の失敗を受け入れつつも、被害を最小限に食い止めるために何をするか、それを次の機会にどう生かすかが大事だと考えています。それに、私はメンバーに対していつもややレベル高めのボールを投げるので、難易度の高いプロジェクトであっても前向きにがんばれる人であってほしいです。――岡田さん自身は、いま何に挑戦していますか？PayPay単体だけではなく、クレジットカードや銀行、証券、保険などの関連グループ会社を横断した金融エコシステムを最短最速で作り上げるための土台づくりとは何か？が、私にとって最大の関心事です。異なる企業同士で連携するのは大変なことも多いんですが、実現できればビジネスがグロースするのは間違いないと信じているので、やりがいを感じています。――エコシステムとは、具体的に何を実現できるのでしょうか？たとえば、「PayPay」のデータがあれば、人々がいつ、どこで、いくらの決済をしたかというお金の流れがわかります。これに加えて先日リリースされた給与デジタル払い対応サービス「<a href="https://about.paypay.ne.jp/pr/20241105/01/" target="_blank" rel="noopener noreferrer nofollow">PayPay給与受取</a>」はお金の入り口になります。つまり、お金の入り口から出口まで、一気通貫でデータがPayPayに集まるんですね。しかし、私たちはまだそれらのデータを十分に活用できていません。これらを用いれば、ユーザー1人1人に応じた金融サービスの提供が可能になります。そうすれば、新しい金融サービス体験ができるでしょうし、5年後・10年後にはいまとは違う世界観が広がっているはずなんです。そんな未来をいち早く実現したいと考えています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b207ad57e2f4478aaebb2a4497de609f/image2.jpg" alt="" width="1999" height="1334"></figure>――単なる決済サービスという枠組みを超えて、金融の未来をつくるような仕事ですね。最後に、これからPayPayの求人に応募したいと考えている方々へメッセージをお願いします。システム本部の仕事は、圧倒的なユーザー基盤を持っている「PayPay」というサービスを、業務システム開発やコーポレートITなどの仕組み作りでサポートできるのが醍醐味です。社会に対してインパクトの大きい事業に関われます。また、今回のインタビューではあまり触れませんでしたが、PayPayはとても国際色豊かな環境でもあります。プロダクト側の開発組織のメンバーは、8割ほどが外国籍なんです。事業やデータの規模が大きく、求められるシステムの品質も高い環境で、グローバルなエンジニアたちと切磋琢磨して働くことで、自分の市場価値を高められるはずです。そういう意味では、日本においてこれほど恵まれている職場はそうそうないんじゃないでしょうか。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/">株式会社Haul</a>

PayPay株式会社のCIO Product統括本部 システム本部長 兼 システム本部 AI活用推進室長である岡田寛史さんに、部署の魅力やこれまでの事例、今後の展望を聞きました。


「タイアップ広告」の記事一覧