アーカイブ動画
2人1組のタッグチームなどの組織体制で、クラウドインフラをスクラッチ開発
PayPay株式会社
Product 統括本部 システム本部
System Platform 部
部長 齋藤 祐一郎氏
最初に登壇したのは、バックエンドエンジニアとして約20年のキャリアを誇る、齋藤祐一郎氏だ。大手SIerのグループ会社、スタートアップ、メガベンチャー、大手クラウド事業者などでエンジニアとしてはもちろん、テックリードや組織づくりといったマネジメント業務も経験。PayPayへは2023年に入社し、現在はSystem Platform部の部長を務める。
2018年のサービス開始以降、現在でもユーザー数が伸び続けているPayPay。2024年12月時点の登録者数は6700万人。国内におけるコード決済のシェアの約3分の2を誇る、名実共に日本最大級の決済プラットフォームである。
一方で、「決済サービスはあくまで入り口であり、デリバリー、金融、保険などお客さまの生活に密着したサービスをさまざま提供する、スーパーアプリを目指しています」と、齋藤氏は語る。
PayPayではサービス側のアプリケーションだけでなく、内製の社内システムのクラウドインフラなども含め、全てをクラウドで構築している。
クラウドは Infrastructure as Code (IaC)によるソフトウェア制御のため、試行錯誤や変更がスピーディに行える。その結果、全ての開発がスピーディに行われる、と齋藤氏は説明した。
実際どのような社内システムを構築しているのかも紹介された。また、これらのシステムは内製かつスクラッチで開発し、運用も自社で行っているという。
開発フローの詳細も紹介された。業務部門などから挙がってきた要件定義に基づき、設計、構築、テスト、運用保守など。全ての領域の業務を一気通貫で手がける。
また基本設計までのフェーズでは、齋藤氏のような特定の人物が内容を精査するゲートキーパー方式とする一方で、以降のフェーズでは取り組みの境界を設けるガードレール方式を採用している。
「このように開発統制を使い分けることで、セキュリティと開発スピード、両方を担保しています」と、齋藤氏は語った。
組織の詳細についても紹介された。System Platform部はシステム本部内に8つある部門の1つであり、クラウドインフラを担当している。
さらに5つのチームに分かれ、この後登壇するメンバーはそれぞれ、System Operationチーム、Cloud Engineering2 チームに所属している。
System Platform部では、一人ひとりがOwnershipのマインドを持つことを掲げており、良いおせっかい」「落ちそうなボールは拾う」 と、齋藤氏は表現した。
在宅勤務が基本のため7つの仕組みを設け、リアルなコミュニケーションに劣らない、メンバー同士の関係構築や悩みが生じた際などの対応を整えている。その1つが、リーダーと現場メンバーが2人1組以上で業務に臨むタッグ体制である。
「分からないことがあった際にはリーダーにすぐ聞けますし、どちらが休んだ際でも業務が滞ることもありません」（齋藤氏）
齋藤氏はこのように、メリットを話した。
その他、毎日開催されるチーム会は30分ほど行われ、メンバーが自主的に議題を持ち寄り相談すると共に、情報をメンバー間で共有する。
さらに毎週行われる部の全体会では、PayPayを取り巻く外部環境などを理解すると共に、それぞれのメンバーが担当している業務の役割を改めて確認する。
齋藤氏はこのように風通しのよい組織であることを紹介し、次のメンバーにバトンを渡した。
オペレーション作業を75%削減した運用改善の舞台裏
PayPay株式会社
Product 統括本部
システム本部 System Platform 部
System Operation チーム
リーダー 野田 万里江氏
続いて登壇したのは、決済・金融系システム領域において、開発や運用改善から、企画やプロモーション活動、マネジメントまで。さまざまな業務や役職を経験してきた、野田万里江氏だ。PayPayへは2023年に入社し、現在はSystem Operation チームのリーダーを務めると共に、Cloud Engineering3チームリーダーも兼務し、データ分析基盤に関する業務にも携わっている。
先述した組織図でも示したように、System Operationチームでは定型業務ならびに最適化を進めている。2023年の7月時点で、アカウントの作成などマニュアル化された繰り返し作業（トイル）は約51種類あり、10人月分のオペレーターを確保し、行っていた。
野田氏はこのトイルを約38種類に削減することで、工数も約2人月にまで減少させることに成功したプロジェクトについて、詳しく解説した。
まずは、ステップ1として、トイルはどのような業務なのか、工数も含めて見える化し、削減すべき業務の優先順位をつけていった。
削減対象の業務が決まったら、次はステップ2で具体的にどのような方法で行うのか、施策を検討した。そして、実行するのがステップ3である。このようなステップ1～3の取り組みを、半期ごとに回していった。
各ステップの詳細ならびに工夫も紹介された。ステップ1では、当時は新規のサービス開発が優先されている状況であり、改善の優先度は低く扱われていた。そこで野田氏はPMO（Project Management Office）や開発チームに、別軸で工数を確保してもらうよう相談する。
相談する際には、削減業務の優先度選定においては金額ベースの工数で比較すると共に、Must、High、Lowと選別した資料や、今期の対応ならびに削減目標などもあわせて提示した。
手作業の削減は運用自動化ツールなどを開発し置き換えることで、実現していった。ただ当初は先述したとおり、目の前の業務が忙しいといった理由から、開発部門の人たちには実情を理解してもらうことに苦心していた状況だったという。
そこで野田氏は「紹介した3つの内容を丁寧に説明し、理解してもらうよう努めました」と、当時の苦労や工夫を述べた。
ステップ2では、効率化施策について語られた。大きくは「廃止」「アプリ改修もしくはツール開発」「RPA化」と、3つのパターンで進めた。
各チームがどこまでをどのように担当するのか、スケジュールも含め議論すると共に、まとめた。例えば、日次連携のような業務はバッチ処理を行うようなツールを、開発チームにお願いし作成してもらった。
ステップ3の施策実行フェーズについては、具体的な事例を示した。
まずは、CSVファイルの連携を、オペレーターを介し手動で行っていた業務の効率化である。スライドを見ると一目瞭然だが、業務担当者にAmazon S3へのアクセス権限を付与することで、オペレーターを介することなく、業務がまわるようになった。
そしてここでも丁寧なマニュアルを作成し、データ移行が失敗した際にはSlackでアラートが飛ぶように設定を行うなど、業務部門の苦労や心配を削減する取り組みを施した。
2つ目は、それまではオペレーターが手動で行っていたCSVファイルのマージならびにデータ移行を、AmazonのAppFlowやLambdaといったサービスを利用することで、自動化した事例だ。事例1と同じく、バッチ処理が失敗した場合はSlackで通知するなどの設定を行った。
3つ目はオペレーターが手動で作成していたデータベースサーバへのログイン用のアカウントを、自動で作成するシステムを構築した。申請フォームから Webhook の機能を使いAPIを叩き、AWS Lambdaを動かすといった設計で、作業終了後はアカウントを自動削除する仕組みも加えた。
「単に手動作業を廃止するだけでなく、セキュリティの観点を入れることもできました」と、野田氏はプラスアルファの成果も生じたことを、述べた。
また、その他の施策も紹介。改めて野田氏は、業務を削減する必要性を理解してもらうこと、協力を得ることが最も苦労したと振り返ると共に、そのような苦労を乗り越えたからこそ、組織全体としての意識改革に繋がったと語った。
System Operation チームがオペレーションの設計やツールの開発も担うようになったと、ここでも工数削減はもちろん、さらなる成果を得たことを繰り返した。そして次のように述べ、セッションを締めた。
「マニュアル作業はゼロにし、オペレーションの設計やツール開発、保守業務をメインにするのが最終的な目標です」（野田氏）
OSのEOL対応を他部門と連携し、アプリケーション障害ゼロを実現した取り組み
PayPay株式会社
Product 統括本部
システム本部 System Platform 部
Cloud Engineering 2 チーム 猪野 真大氏
猪野氏は、EOL（End of Life）が間近に迫ったOS、Amazon Linux2の移行プロジェクトについて解説した。該当する領域は以下スライドの赤枠で示された部門やシステムであり、対象となるサーバーの台数としても規模の大きい状態 であった。
規模の大きいプロジェクトであったことと、期限も限られていることから、こちらも赤枠で囲まれた他部門のチームと連携、協業するかたちで進められた。なお当初EOLは2025年6月30日とアナウンスされていたが、現在は2026年6月30日となっている。
最初に取り組んだことは、OSのEOL移行プロジェクトの肝を改めて確認し、整理したことだ。具体的には、期日までに終了させる、該当OSを利用している全ての社内システムの移行を実現する、といった内容だ。
続いて工程を明確にすると共に、どの時期にどの工程を行うのか、スケジュールを作成した。各工程の詳細も紹介した。まずは「移行計画の策定」である。
抜け漏れなく全ての対象サーバーで移行を実現するために、サーバーの洗い出しを行うと共に、スプレッドシートに一覧表を作成し、記載していった。その際にはシステム名や重要度、移行の難易度なども合わせて書き込んだ。
一覧表ができあがった後は、システムの特性や移行の工数などから、「廃止」「コンテナ移行」「OS刷新」と3つに分類。それぞれ判断基準も明確に設けた。規模数や期日の制約があり、結果として大多数がOS刷新に分類された。
プロジェクトを進めていると、手動管理しているAWSリソースやサーバー設定が存在しており、構築工数や認知負荷がかかっていることが分かった。そこで、IaC化を進めることとした。
AWSリソースにおいてはterraformのコード生成機能、サーバーにおいてはAnsibleを活用し、それぞれIaC化を実現した。またGitHub Actionsを用いて、CI/CDの仕組みも構築。OSの設定反映と構成管理を統合し、1つのワークフローで遂行できる環境も整備した。
続いては先の取り組みを、複数システムへと横展開していった。手戻りを少なくしたいとの考えから、「ファーストペンギンは外部システム数が少ないシステムとし、最初に成功事例をつくることを意識しました」と、猪野氏は工夫を述べた。
動作検証においては責任分担を明確にした上で、他チームの実施内容を把握し、観点漏れを少なくするよう意識した。具体的には、リリースにおいてアプリとインフラに分けた際、全体のリリース手順として整合性が取れていない箇所があれば必ず確認するように意識した。
「特に、アプリとインフラの境界は認識齟齬が起きる要因になりがちであるため、他チームのタスクを把握すると同時に、不明点や観点漏れがあれば物怖じせずに質問や指摘をすることを心がけました」と、猪野氏は述べた。
本番リリースに向けた準備フェーズでは、スライドで示したようなマトリクスを作成し、障害が発生しうるポイントを明確化。リカバリ方針なども同時に整理、明記した。
このような事前の入念な準備により、細かな障害は発生したものの、「業務に影響をおよぼすようなアプリケーション障害はゼロに抑えることができました」。猪野氏はこのように成果を述べ、セッションを締めた。
さまざまな質問が寄せられたQ&Aタイム
セッション終了後はQ&Aタイムが設けられた。抜粋して紹介する。
Q．効率化を実施する際、上司の理解や了解を得るために行った施策でよかったものは？
野田：上司の理解は最初からありましたが、セッションで紹介したように他のチームの理解を得ることが、当初は課題でした。
そこで一度、各チームや部門のリーダーや部長が集まって議論する場を設けてもらいました。その場で私は現状の苦労を紹介したんです。そうしたら各部門の管理者が大変な状況を理解してくれ、運用改善に協力してくれるようになりました。
齋藤：上司としては、労働時間、工数、未来の3つを意識しています。野田さんのケースでは労働時間は深夜や早朝も含め、よろしくない状況でした。工数もそれなりにかかっていました。そして未来。新しいことをするには今のことを整理する必要があります。そして、野田さんの熱意もありました。
Q．既存作業の洗い出しはどのように行ったのか？
野田：オペレーション業務の担当者にヒアリングを行い、何のための業務なのか、業務時間はどの程度なのか測定するなど、一つひとつの業務を泥臭く洗い出していきました。
Q．業務効率化プロジェクトの社内承認について
齋藤：組織全体としては社内にPMO部があり、その部門がプロジェクトの優先度や投資対効果などを評価し、決定します。今回は投資対効果があると評価され、工数を確保して取り組むことができました。
Q．役割分担の議論では押し付け合いにならないか？
猪野：なぜ、そのチームが行うのかを短期・長期の軸で分けて説明しました。例えば、短期目線でインフラチーム側が担ってしまうと、長期的に開発チーム側で運用できないなどです。
齋藤：協力してもらいやすいチームを探すのもポイントだと思います。実際、猪野さんのプロジェクトでは、System Platform部といい意味で縁の深いチームに最初に協力してもらい、結果を出すといった地ならしをしていたからです。
Q．移行方式の決定では何を基準に判断したのか？
猪野：難易度の他、対応コスト、インフラコスト、運用コストなどを軸として考えました。計画当時は規模数と期限の関係上、対応コストを重視する結果になりました。
Q．業務の属人化に対する対策は？
齋藤：セッションで紹介したタッグ体制が該当するかと思います。
猪野：Terraformでコードを書くときも、リーダーとレビューをしています。また、関連のあるメンバーには共有するなど、人による冗長化も意識しています。
Q．工数計算が難しいタスクなどはどのように金額換算したのか？
野田：オペレーターに泥臭く計算してもらいました。またSlackでできる依頼や見えない工数などはチケットに換算し、それらを実際の作業数で割り、一工数あたりのコストを算出しました。
齋藤：工数を可視化するための仕組みを事前に作ったこと。その上で工数を勘定できるように取り組んだのが肝だと思います。
PayPay株式会社
https://about.paypay.ne.jp/
PayPay株式会社の採用情報
https://about.paypay.ne.jp/career/
PayPay株式会社のオウンドメディア「PayPay Inside-Out」
https://insideout.paypay.ne.jp/
関連するイベント
