日本国内で7,300万人以上のユーザー（2026年3月時点）、そして年間数十億件の取引を支えるPayPay。ライブでのデータ移行や高トラフィック下の認証基盤に至るまで、エンジニアリングの意思決定には常に重大な結果が伴います。その技術基盤をさらに強化・進化させるために、2022年に設立されたのがPayPay Indiaです。発足から短期間で、インド拠点はPayPayグループにとって欠かせない開発ハブへと成長しました。
今回のIndia Dev Speaksでは、PayPay IndiaのP2PおよびUser Moduleチームで実際に設計や技術判断を担う5人のエンジニアが登場します。日本拠点のパートナーチームと協働しながら、明確な責任範囲のもとで、どのように意思決定を行い、トレードオフを評価し、失敗に向き合い、責任を通じて成長してきたのかを語ります。本記事は、組織図やレポートラインについての話ではありません。何を最適化するのかを選び、どのリスクを引き受けるのかを決め、壊れたときに学び、そして本番環境でその判断が結果として現れたときに責任を持ち続ける。そうしたエンジニアリングのマインドセットについて掘り下げます。
エンジニア紹介
Tushar:
約1年半前にPayPay Indiaへ入社し、以来P2Pチームに所属しています。P2P領域における複数の統合案件を担当してきました。
Sajal:
この1年半ほどP2Pチームで開発を続けています。直近では、不正報告システムを主導し、P2P取引における不正ケースを検知・連携するバックエンドを構築しました。
Sahil:
現在はUser Moduleチームで約1年半、認証・基盤領域の設計と改善を担当しています。
Nitin:
PayPay Indiaでは2年半以上にわたり複数のチームを経験してきました。現在はUser Moduleでレジリエンスと可用性を担当しています。それ以前はMerchant Engagement Solutionsチームで、大規模なギフトバウチャー施策の基盤構築に携わっていました。
Aman:
これまで2年以上にわたりGenAI、Payments、Pointsと複数の領域を経験し、現在はP2Pチームで外部サービスとの統合やスケーリング設計をリードしています。
同じ場所にいない環境で、オーナーシップはどう変わるのか
国境を越えて開発するようになって、何が違いましたか？
Tushar:
約1年半前にPayPay Indiaへ入社し、P2Pチームでクロスリージョン開発に関わり始めました。最初は、日本からインドに来ていたシニアエンジニアがP2Pの知識をほぼすべて持っていたので頼ることができました。その後は、完全にオンラインでのやり取りに切り替わりました。共通のチャンネルで質問すると、レスポンス自体は早いですし、レビューが遅れることもありません。ただ、自分から意図的に動く必要がありました。
Sahil:
インドでは、ホワイトボードを使ってその場で議論するのが普通ですが、日本側のパートナーチームと進める場合、すべてを構造化し、ドキュメントに落とす必要があります。入社当初関わったプロジェクトで、なかなか意思決定が進まないことがありました。会議を増やせば解決すると思っていましたが、違いました。設計ドキュメントに選択肢を整理し、図を使ってトレードオフを明示すると、意思決定は一気に進みました。
Nitin:
国を跨いだチーム間では文脈が自動的には共有されません。同じ場所にいれば暗黙に伝わる前提も、オンラインでは明示する必要があります。議論の前に課題を整理し、制約を明確にし、自分なりの方向性を提示する。アラインメントは自然に生まれるものではなく、設計するものだと感じました。
Aman:
私はPayPayの中で、ローカルに近い体制とクロスリージョンの両方を経験しました。エンジニアリング文化そのものに大きな違いがあるとは感じていません。日本側ではリモートでも働いていますし、オンラインコミュニケーションツール上での会話も行われています。ただ、時差がある環境では、都度すべての判断を待つことはできません。自分の責任範囲の中で考え抜き判断し、その理由を共有する姿勢が一層求められます。
Sahil:
日本とインドで勤務の重なる時間帯を活用しますが、それ以外の時間も開発は進みます。そこでオーナーシップがはっきり見えるようになります。迷っていると、チーム全体の進みが止まります。
Nitin:
チームは国境を越え分かれていますが、自分の担当領域の最終的な責任は明確に自分たちにあります。
7,000万人規模のサービス開発で、エンジニアはどう変わるのか
このような環境で働くことで、エンジニアとしてどんな変化がありましたか？
Sajal:
入社前は、より限られたユーザー数のシステムを扱っていました。7,000万人規模のプラットフォームに関わるようになり、単なるスケールの違いではなく「責任のレベルが変わった」と感じます。品質やスケーラビリティに対する考え方も変わりました。ひとつの変更が、PayPay銀行やPayPay証券など複数のグループサービスに波及する可能性があります。
1行のコードが、想像以上に広い影響を与えることもある。レビューや議論の密度の高さは、自分の考えの甘さに何度も気づかせてくれました。単にコードを書く力を高めるだけでなく、システム全体をどう捉えるかという視座そのものを広げてくれました。
Nitin:
Merchant Engagement Solutionsチームで、Tech Ownerとしてキャンペーン基盤を担当したのが大きな転機でした。設計を書くこと以上に、チームを合意に導き、ブロッカーを解消する責任がありました。当時は規模も比較的コントロールしやすく、一貫性やSLAが最優先でした。レイテンシは大きな課題とはなりませんでした。
ですがUser Moduleに移ってからは前提が変わりました。トラフィック量が大きく、レイテンシやスケール耐性が設計の中心になります。ある設計について、「この構造ではトラフィックに耐えられない」というフィードバックを受けました。文法や実装の問題ではなく、負荷下での挙動の話でした。以降、設計は「正しいかどうか」でなく「負荷下で壊れないかどうか」で考えるようになりました。
Tushar:
私はFinTechやJavaのバックグラウンドがありませんでした。送金処理の仕組みを理解すること自体が大きな学びでした。一見シンプルに見えても、その裏には多くのチェックや検証、リスク管理が存在します。特に送金に関わる機能では、レビューが非常に体系的です。セキュリティやQAのプロセスも徹底しています。最初は厳しいと感じましたが、今ではそれが「信頼を守る設計」なのだと理解しています。
Aman:
一言で表すのは難しいですが、変わったのは「責任の捉え方」です。前職では、とにかく早く出すことが評価される環境でした。PayPay Indiaでは、その後の挙動まで設計に含まれます。ロールバック戦略やオブザーバビリティ、長期的な保守性まで含めて考えます。ドキュメントも単なる共有手段ではなく、将来のエンジニアに向けた責任です。常に当事者として関わっている実感と、自分の判断を説明し続ける責任があります。でも、その経験が、エンジニアとしての成長を加速させていると感じています。
すべてが重要な環境で、何を最適化するのか
すべてがクリティカルな状況で、何を最適化しますか？
Sahil:
Redisのバージョンが廃止予定になったとき、単なるアップグレードではすまないと思いました。このクラスターにはセッショントークンなどのクリティカルなデータが保存されています。もし失敗すれば、ユーザーのログインに大きな影響を及ぼしてしまう可能性さえもありました。スナップショットと増分同期を組み合わせたRedis移行ツール「Riot」を使いライブ移行の検証を行いました。しかし、ピーク時の書き込みトラフィック下ではレプリケーションの遅延が増え続け、一時的とはいえ整合性を保証できない状態でした。
一見するときれいな移行方式でしたが、安全とは言えませんでした。そこで問いを変えました。「どの失敗なら許容できるのか？」最終的に、両クラスターに対してデュアルリード／ライトを導入しました。移行期間中も双方のデータ整合性を保つためです。APIレイテンシは一時的に増加し、SLOにも影響が出ました。しかし、セッションの整合性は守られました。ログインが遅くなることは許容できる。でも、ログインできなくなることは許容できない。この移行では、およそ17,000行に及ぶコード変更が発生しました。それだけの変更を本番環境に出すということは、技術的な難易度だけでなく、判断の重みも伴います。その後、移行フローの一部を再設計し、比較処理を並列化することで、当初は約3日かかる見込みだった移行時間を約2時間に短縮しました。
この規模では、不安定な状態で稼働する時間そのものがリスクになります。実装も難しかったですが、本当にチャレンジングであったのはどのリスクを引き受けるのかを決め、その判断に責任を持つことでした。
Sajal:
以前関わった不正報告機能の開発では、納期が1カ月と決まっていました。最初のスコープは「送金」のみでしたが、将来的に「リクエスト送金」や「割り勘」「定期送金」にも拡張されることが見えていたので、最初から拡張前提で設計しました。この規模で再設計するコストは大きく、将来を見越すこともトレードオフの一部です。
Aman:
意見が分かれることもありますし、納期も厳しいです。そのときは、まずユーザーへの影響が最小限で済むものを優先します。並行して、残りの論点を議論します。
Sajal:
UIの設計で意見が割れたこともあります。その場合はA/Bテストを選びました。議論だけで決めるのではなく、データで決める。それも1つのトレードオフです。
Sahil:
私たちが扱う開発の規模では、「きれいな設計」よりも「生き残れる設計」が重要ですよね。
国境を越えてリードするということ
国境を越えた体制で働くうえで、どんな難しさがあり、どんな姿勢が求められますか？
Nitin:
User Moduleのマルチテナントプロジェクトに入ったとき、私はまだドメインへの理解が浅い状態でした。設計を提案すると、多くのフィードバックを受けました。単にアイデアが否定されたわけではなく、スケールや前提条件に対する信頼をどう築くかが問われていました。正しさだけでは足りない。背景を共有し、文脈を揃える必要があると感じました。
議論の多くは非同期です。オンラインコミュニケーションツールのスレッドやドキュメント上のコメントで進みます。フィードバックを待つ時間が発生します。そこで、15〜30分程度の短いブレインストーミングを自分から設定するようにしました。コメントの意図を直接確認することで、改善のスピードが上がりましたし、信頼関係も築きやすくなりました。
Sahil:
時差によって、開発の進め方そのものが変わります。日本時間の夜遅い時間にリリース作業を行うこともあります。コミュニケーションはリアルタイムではなく、計画的に行います。
また、特定の領域を理解している人が限られている場合、知識の共有には時間がかかり、自走できる力が必要です。常に誰かが答えを持っているとは限りません。自分で考え、設計を文書化し、前提やトレードオフを明確にする。この環境では、過剰なくらいの情報共有がちょうどいいと感じています。
Nitin:
チームの関係性も自然には生まれません。スタンドアップの数分前に集まり、日常の話題で会話することもあります。些細なことですが、距離を縮める助けになります。
Aman:
クロスリージョンの環境は、誰にでも合うわけではありません。オーナーシップを取ることに躊躇があると、負担に感じるかもしれません。マイクロマネジメントはありませんが、その分、自分の判断の結果は自分で引き受けます。オーナーシップは成長を促しますが、同時に責任を可視化します。
Nitin:
コミュニケーションスタイルの違いにも適応する必要があります。沈黙を同意と誤解してしまえば、方向性はずれてしまいます。アラインメントは明示的に確認するものです。
Sahil:
国を跨いだ環境での協働は、それぞれの成長へとつながります。単にコードを書くのではなく、自立して考え、意図的に伝え、結果に責任を持つ。国境を越えていても、責任は曖昧にはなりません。
成長とその先へ
この環境で、どのようにキャリアは広がっていきますか？
Sajal:
PayPay Indiaは、決済アプリの開発にとどまりません。PayPayカードやPayPay銀行など、複数のエンティティと関わります。ジュニアの頃は実装が中心でしたが、今は設計を考え、レビューし、複雑なシステム全体を見渡す立場になりました。エンジニアとしての成長とは、関わる責任の範囲が広がることだと思います。
Aman:
以前はスピードが最優先でした。ここでは、依存関係、整合性、オブザーバビリティ、ロールバック戦略まで含めて設計します。考慮すべき前提が増える。それが成長だと思います。
Sahil:
役割が広がるにつれて、個別機能だけでなく、システム全体をどう進化させるかを考えるようになりました。メンテナンス停止を限りなくゼロに近づけることや、ライブアップグレードを前提とした設計もその一つです。AIを開発プロセスにより深く取り込むことも、単なる効率化ではなく、設計の質を高める取り組みの一部だと考えています。
Nitin:
以前は個別機能の責任が中心でした。今は、グループ全体を見渡した基盤設計に関心が移っています。共通機能の統合や標準化を考えるようになったのも、担当領域が広がったからこそです。
オーナーシップに挑むエンジニアへ
どんなエンジニアがマッチしますか、そして面白さは？
Aman:
与えられたタスクをこなす環境を求めているなら、ここではプレッシャーに感じるかもしれません。一方で、スケーラビリティや障害シナリオ、長期的な保守性まで考えたい人には、とても面白い環境です。自分でトレードオフを定義し、その判断が本番トラフィックの中でどう機能するかを確かめたい人にはマッチすると思います。
Tushar:
好奇心がある人は伸びやすい環境です。決済だけでなく、銀行や証券など複数のシステムが連携しているので大規模な金融システムがどう動いているのかを、実際のコードを通して学べます。
Nitin:
リスクを避けたい人には向かないかもしれません。本番障害で非常に重要な局面に直面した経験もあります。でも大事なのは、壊れないことではなく、壊れたときにどう向き合い、どう設計を改善するかです。失敗を分析し次に活かせる人は、確実に成長します。
Sahil:
手取り足取り教えてもらえるわけではありません。でも、その分オーナーシップがあります。任されている実感があるからこそ、考える力が伸びます。本番環境で自分の設計が動いているのを見るとやはり面白いですね。
Sajal:
不正報告機能をリリースしたとき、想定以上に利用してもらえました。実際のユーザーに使われ、影響を与えていると実感できる瞬間は、やりがいがあります。スケールのある環境で挑戦したい人には、刺激の多い場所だと思います。
Nitin:
コードを書くだけではありません。結果を引き受ける環境です。それにワクワクできる人なら、ここで大きく伸びるはずです。
※募集状況、社員の所属等は取材当時のものです。
