アーカイブ動画
単にシステムを開発するだけではない――System Development部のミッションと役割
PayPay株式会社
コーポレート統括本部 システム本部
System Development部 部長 藤田 文彰氏
最初に登壇したのは、さまざまなベンチャー企業で開発・マネジメント経験を積み、Salesforceの開発などに従事した後、「金融事業の未来創世に尽くしたい」との想いから、2019年10月にPayPayに入社した藤田文彰氏だ。
現在は社内業務を中心に、業務システム開発や業務改善など、事業を支えるエンタープライズエンジニアリング組織のマネジメントを担当している。
キャッシュレス決済の利用は年々増加傾向にあり、中でもPayPayのようなコード決済の増加割合が顕著で、コード決済においてPayPayの利用割合は約3分の2となっている。2023年には61.1億回も利用された。
このようなニーズも踏まえ、藤田氏はPayPayをスーパーアプリとして、さらに成長していく展望を述べた。
「金融や各種行政サービスなど、PayPayが入り口となることでさまざまな金融サービスとつながる。そのようなプラットフォームを目指しています」（藤田氏）
「技術でPayPayグループの成長に貢献する」とのミッションを掲げるシステム本部において、System Development部は各種業務システム開発に特化している部門である。
以下スライドのように、大きくは左右2つの部門に分かれている。左側のTech部門は、クラウド上で業務システムをスクラッチ開発にすることに注力。一方、右側3つの部門はローコード開発や生成AIなどを利用し、業務改善を推進している。
PayPayなどのプロダクトは、CRMやバックオフィス関連の各種システムやサービスとの連携も多い。藤田氏は、「全方位でつながる業務システムを開発しており、事業運営にはなくてはならない組織です」と、重要な役割を担っている部門であることを強調した。
System Development部は業務システムを開発する部門ではあるが、単に依頼されたシステムを開発するだけではない。というのも、まずは各部門から課題などの情報をしっかりと収集した上で、どのようなシステムを開発すれば課題は解決するのか。構想段階から取り組むからだ。
そのため「要望どおりのシステムを開発しないこともある」と藤田氏。スピードが重要だと判断した場合は、最低限のシステムを構築する。あるいは、セキュリティ重視のシステムを構築するなど、その時々の課題や状況、成果を加味しながら開発を進めていく。
エンジニアは基本的に1つの案件に集中するが、PMやテックリードといったポジションのメンバーは、案件の規模により複数の案件に携わることもある。
また他部門からの参画など、部門の垣根を超えた開発体制で、先のミッション実現を目指している。
さらにSystem Development部では、先述したように課題をヒアリングするフローだけでなく、自分たちからも積極的にシステム上の課題などを把握しておく。
その上で、データの活用や業務見直しなどを提案することで、課題の解決や工数削減などにも努める。藤田氏は次のように述べ、次の登壇者にバトンを渡した。
「技術的な内容に限らず、テックリードなどがビジネス側とコミュニケーションを取りながら事業を進めているのも特徴です」（藤田氏）
大規模なエンタープライズシステムを支える、PayPayにおけるテックリードの役割
PayPay株式会社
コーポレート統括本部 システム本部
System Development部 Tech1 リーダー 児玉 真一氏
続いて登壇したのは、内製アプリケーションチームのリーダーとしてチームのマネジメントを務める児玉真一氏だ。2022年に入社するまでは、SIer、Webサービス会社で、販売管理や広告配信システムなどの開発や運用に携わってきたキャリアを持つ。
PayPayへの入社は、故郷である長野に戻って仕事をしたいという希望に合致していたこと。自分のキャリアが活かせる領域であること。さらには金融業界が未経験であったため、新たなチャレンジになると感じたことだという。現在は長野在住でフルリモートワークをしており、本社への出社は3カ月に一度ほどだと、理想の働き方ができていることを紹介した。
児玉氏はまずは、System Development部が考える、「テックリードの役割」について説明した。単にシステムを開発するだけではなく、ビジネス側と一緒に、システム構成や技術観点での最適化を考えていることを、改めて強調した。
児玉氏がリーダーを務めるチームでは、マネーロンダリング対策に関連する、各種審査やリスク関係のシステムの開発を担当している。審査は法人と個人に分かれ、法人はPayPayを利用している加盟店の商品内容、日々の取引、代表者の身分証明などにおいて不正がないかをチェックしている。
一方、PayPayを利用する個人のユーザーに対しても、本人確認業務を行う。リスク管理業務も同様だ。本人確認や法人確認を行うことで、反社会的な人物がいないかを審査する。
AI開発では、審査する法人やユーザーの個人情報などを必要以上に審査担当のオペレーターなどが閲覧できないよう、マスク処理など、セキュリティ強化に関する業務を担う。
チームのなかには、児玉氏と同じように、地方在住でフルリモートワークをしているメンバーも多いという。
PayPayの個人審査においては、eKYCを利用している。eKYC はelectronic Know Your Customerの略であり、オンライン上で本人確認を行う技術とプロセスのことである。PayPayでは現在、マイナンバーカードや顔認証といった4つの手法でeKYCを実施している。
続いては、「奈良県働く人応援クーポン」における実例を紹介した。事業所等に雇用されている従業員が応募すると、抽選で奈良県内の対象店舗で利用可能な15,000円の「PayPay商品券」を10,000円で購入できるというものだ。
奈良県民であり、事業所等に雇用されている従業員のうち、国や地方公共団体に勤務する公務員などを除いた人が応募対象となる。
奈良県民かどうかの審査は先述したとおり、既存のeKYCを使えば可能であった。一方で、事業所等に雇用されている従業員かどうかを審査するには、就労証明書での確認が必要なため、新たなシステムの開発が求められた。
しかし、システム開発に充てられる期間は1カ月ほどしかなかった。そこで児玉氏は次のように考えた。
「他の案件も平行して動いていたため、リソースは限られていました。キャンペーンは期間限定ということもあり、必要十分の作り込みにすることにしました」（児玉氏）
まさしく構想段階からSystem Development部が開発をリードしていったのである。
では具体的にどのような施策で、必要十分の作り込みを実現していったのか。児玉氏は審査フローの概略図を示しながら紹介した。まずは、審査フロー全体の流れについてだ。
ユーザーは応募フォームから、就労証明書をアップロードする。PayPay側はアップロードされたデータに対して抽選を行い、仮当選者を決め、リスト化する。そのリストを担当者がチェックし、問題がなかった応募者を確定し、当選者にメール通知する。
「すべてシステム化しては期限に間に合わないと感じたため、必須ドメインを検討しました」と児玉氏。「システム化」「手運用」と大きく2つの作り込みに分けることで、工数の最小化を進めていった。
具体的には、繰り返し実施する必要がある部分や、個人情報を扱う領域はシステム化することとした。一方、データをまとめてから一括送信できるなど、実施回数が数回の作業は、手動運用することとした。スライドで示すところの前者が青色、後者が赤色で示された領域となる。
さらに児玉氏は、入り口、入力フォームのシステムにおいては、PayPayの既存ミニアプリを流用することとした。具体的なシステム構成図も示した。
さらに入り口、入力フォームのシステムにおいては別チームが手がけるPayPayの既存ミニアプリを流用することとした。具体的なシステム構成図も示した。
ユーザーのスマホからアップロードされた就労証明書の書類データは、まずはPayPayのサービスにAPI経由で入る。データの保管においても同じく、PayPayサービス側のストレージ、S3に保管される。
「PayPayでは取り扱う情報はレベルにより、セキュリティが異なっています。中でもユーザー情報は最もセキュアな領域に保存されています。今回の個人情報が記載された書類データも、まさにそのレベルとして扱いました」（児玉氏）
一方で、以降のフローは審査システム側で行われる。こちらは既存のeKYC審査システムを活用し、奈良県民であるかどうかをチェックする。通過したユーザーのIDは一覧化され、次の審査を行う担当者に配布される。
審査担当者が閲覧するデータは、こちらもAPI経由で得たS3に保管された先のデータであり、閲覧する際には参照期限が限られたURLに紐づくため、個人情報は保護されるという仕組みだ。
「個人情報はあくまでサービス側のみがデータを保持する構成であり、担当者は参照するだけです。そのため、セキュリティが担保されています」と、児玉氏は同システムが高いセキュリティを意識した設計であることを強調した。
その後の流れも先のとおり、審査を通過したIDは当選者リストとなり、次のフローに進む。もう一つの課題として、eKYCシステムは既存の汎用システムを流用しているため、同キャンペーンで使用することで負荷がかかり、影響を及ぼすことがあってはならなかった。
「Kubernetes上で稼働しているアプリケーションのため、負荷があった場合にはPodを増やすことで対応できると考えていました。実際、障害も発生しませんでした」と、児玉氏は狙いどおりの成果であったことを述べた。
System Development部は開発部門ではあるが、サービス運営会社の一部門であり、開発エンジニアはその一員でもある。そのためまずはしっかりと動くものを提供する必要がある。児玉氏はテックリードの役割をこのように述べるとともに、次のようなメッセージでセッションを締めた。
「技術は手段であり、目的ではありません。関連部署と協力して、ビジネスの成功にたどり着くこと。これが、我々の目的です」（児玉氏）
【Q&A】多くの質問が寄せられたQ&Aタイム
セッション後は、参加者からの質問に登壇者が回答した。テーマごとに整理して紹介する。
Q．コミュニケーションなど、フルリモートの働き方で工夫している点について
藤田：どうしてもコミュニケーション不足になりがちなので、3カ月に一度は会社の福利厚生の一環として、リアルな懇親会などを開催するようにしています。ただ対面の方が、コミュニケーションが高まるとは思っていません。逆に、フルリモートでコミュニケーションする際には、言葉や文字の扱いに対して、より気をつけるようになりました。
児玉：チームとしては毎日30分ほど時間を設けて、朝会を実施しています。事務的な連絡は冒頭の10分ほどで終わらせ、残りの20分は質問を受けるようにしています。また、2週間に一度の頻度で1on1を実施しています。こちらも特に内容は固定せず、業務の話から雑談まで、いろいろと話しています。さらに必要だと感じた場合には、オンラインミーティングをアドホックで開催するなど、チーム内での意識のズレがないように努めています。
Q．ステークホルダーとの情報共有について
児玉：Slackでのやり取りでは、プロジェクトごとにチャンネルを分けて、開発メンバーだけにしています。全メンバーで集まるチャンネルとそれぞれに分け、週一の頻度でミーティングを行っています。またミーティングの際には、アジェンダを時系列で追えるよう工夫しています。
藤田：フルリモートワークとなったことで、より頻繁に行うようになり、認識齟齬の改善につながっていると感じています。
Q．テックリードの役割を深堀りして語ってほしい
児玉：実は、PayPayではテックリードに関する明確な定義はなく、案件により異なるという解釈です。タイトル自体もありません。体制図を作成する際に、役割を決めるようにしています。
そのため、技術的な課題解決に努めるテックリードがいる一方で、いろいろな動きができるテックリードがいるなど、プロジェクト内容や適材適所を見極めた上で、キャスティングしています。
藤田：会社やチームの規模にもよると思いますが、特に少人数のチームの場合は、役割を固定してしまうと案件がスムーズに進まないため、しない方がよいと個人的には思っています。
一方で、役割分担するケースもあります。例えば、業務フローの洗い出しは業務を企画するメンバーに書き出してもらい、その中から取捨選択し、どのフローをシステム化するのかについて、テックリードが関わるといったケースです。
重要なことは、今与えられた役割で何をすべきかを意識することだと思っています。例えば、プロジェクトマネージャーやテックリードが実装に携わってしまっては、管理が厳かになるからです。今回のケースでは一人ひとりがロールをしっかりと意識したことで、成功した事例でもあると捉えています。
Q．技術のキャッチアップはどのように行っているのか？
児玉：新しい技術を見るよりは、社内のサービス、特に規模感の大きなもので使っている技術を見ています。その上で、自分たちの開発でもマッチするかどうかを判断しています。さらには関連していたり、似たような世の中の技術や仕組みをキャッチアップしている感じです。
Q．有意義な会議にするための工夫は？
藤田：打ち合わせ前に、何の話をするのかを主催側が参加者に伝えることです。加えて、会議で何を決めたいのか、そもそも何を決める会議なのかを明確にすることが大切だと思っています。
児玉：私にどのような質問があるかを、事前に確認しています。ない場合は参加せず、後から議事録を確認するようにしています。
藤田：最近は議事録がしっかりしているため、議事録だけで理解できる会議もあるからです。特にエンジニアの場合は、会議に参加すると工数が減りますからね。キャスティングも含め、会議に参加する人はできるだけ絞っています。
Q．情報収集する上で意識していること、役立つツールは？
藤田：要求事項が明確になっているかどうかですね。具体的にはBRD（Business Requirements Document／ビジネス要件定義書）を確認した上で、何をしたいのか、整理されているかを第一に見ています。このようなフレームワークを作るためにJiraを使っていますが、他のツールでもよいと思います。
Q．フルリモートにおけるおすすめの開発ツールは？
児玉：Asana、Backlogなどいろいろなプロジェクト管理ツールを試してきましたが、どんなことでもすぐにできる、Jiraが今は使いやすいと感じています。
Q．チームビルディングで使えるゲームは？
児玉：カードゲームですと、人の価値観を数値化し自分と他人の違いを測る「ito」というゲームがあります。アンガーマネジメントに関する「アンガーマネジメントゲーム 怒りのツボ・当て～る！」や、生成AIを使ったゲームなどもおすすめです。
PayPay株式会社
https://about.paypay.ne.jp/
PayPay株式会社の採用情報
https://about.paypay.ne.jp/career/
PayPay株式会社のオウンドメディア「PayPay Inside-Out」
https://insideout.paypay.ne.jp/
関連するイベント
