システムアーキテクト/プラットフォーム開発本部

1,000万円〜1,500万円

東京都

「募集背景」

DMMに対して、「完成された会社」「すでに成熟しきった会社」という印象を持たれる方もいるかもしれません。
しかし実態として、20チーム超・200名超のエンジニアが運用し、年間売上3,870億円・会員数5,000万人超を支える基幹プロダクト群は、率直に言えば“カオス”な状態にあります。

技術スタックはPHP・Go・Java・Kotlinが混在し、インフラもオンプレミス・EC2・ECS・EKSが時代ごとに地層のように積み重なっている状況です。
さらに、CI/CDもCircleCI・GitHub Actions・ArgoCDがプロダクトごとにバラバラに存在しており、各プロダクト間の依存関係は複雑化しています。結果として、ドメインの責務境界が曖昧になっている箇所も少なくありません。

決済・購入領域ではTemporalやCQRS & Event Sourcingを用いたモダナイゼーションがすでに進行中ですが、個別プロダクトの改善だけではプラットフォーム全体の一貫性は保てません。

加えて、AIの活用により各チームの開発速度が上がりつつある今、整理されていないプラットフォームのままではその恩恵を十分に活かしきれません。
だからこそ、局所最適ではなくプラットフォーム全体を見渡し、設計方針を定められるシステムアーキテクトの存在が不可欠な状況です。

こうした背景のもと、CTOの渡辺が「走っている車を止めずにタイヤを変える」と表現するほどの難易度の高いミッションに向き合いながら、DMMの次の30年を支える基盤へと作り替えていくフェーズにあります。

現在、プラットフォーム開発本部には約200名のエンジニアが在籍していますが、プラットフォーム全体の設計・意思決定まで担えるシステムアーキテクト層は数％、数名程度に留まっています。

そのため今回、この“複雑で、難しくて、面白い”局面をともに前に進めてくださるシステムアーキテクトを募集します。

「事業概要」

DMMのプラットフォーム開発本部は、DMMTV／電子書籍／英会話／オンラインサロンなど60超のサービスを横断し、DMM経済圏の“心臓部”を担っています。

具体的には、ID・認証認可、決済・電子マネー、ポイント・クーポン、不正対策といった共通基盤を開発・運用し、すべてのDMMサービスが同じ土台の上でスケールできる世界をつくっています。

具体的には次の3つをミッションにしています。

 DMMの60以上の事業の成長を加速させる
新しい施策やプロダクトが出るたびに、ゼロから認証・決済・ポイント設計をやり直すのではなく、プラットフォームを使えば最短距離でリリースできる状態をつくります。
結果として、
・新規サービスの立ち上がりが速くなる
・既存サービスの改善サイクルが回りやすくなる
・「やってみたい」が即プロダクトに変わる
その土台をつくるのが私たちの役割です。

DMMの信頼を守り、事業の“守り”を固める
決済・認証・不正対策は、トラブルが起きた瞬間に信頼が揺らぐ領域であり、高い品質水準が求められます。
私たちは、
・不正を最小化する仕組み
・止まらない決済基盤
・セキュアでスケーラブルな認証基盤
をつくり、安心感を技術で支えます。

良い顧客体験を提供する
ユーザーにとって、
・会員登録
・ログイン
・決済
・ポイント利用
は“DMM体験の最初の接点”です。ここがストレスフルだと、どんなにコンテンツが良くても体験は台無しになります。
私たちは、DMMを使い始める瞬間の体験を、できるだけスムーズで心地よいものにする役割を担っています。

参考記事

本人確認システムをリプレイスした話
クーポン機能開発メンバーが語る、決済額3,000億円超えのプラットフォームの底なしの可能性
DMMの不正対策システムと運用サイクル
Speaker Deck/pospome
Speaker Deck/石垣雅人

※プラットフォーム開発本部におけるAI活用推進の取り組みに関しては、以下の記事もご参考ください

AX戦略の全体設計
DMMのプラットフォーム基盤が目指す、 AX戦略（AI Transformation）
実運用による自動化・プラットフォーム構築事例
1か月でローンチ！PF-AX流“AI自動分類”開発舞台裏
AX改善活動 チケット自動生成&Chrome拡張のPoC事例
AIエージェント「Cursor」で変わる開発マネジメントの実践論
CodeRabbitと過ごした1ヶ月 ─ AIコードレビュー導入で実感したチーム開発の進化
【AI時代の必須スキル】生成AIと未来を創る、すべてのエンジニアのための5つの鍵
DevinとClineをDMMで導入しました〜トライアルから見えた成果の共有〜
生成AIでレビュー承認業務を大幅削減 〜導入14日で6割自動化の成果〜
GPT3.5系からGPT-4o系への移行から持続可能なAI基盤について考える
「業務内容」

DMMプラットフォーム全体の設計方針の策定と最終判断を担い、20超のチーム・60超のサービスを一つの一貫したプラットフォームとして再構築していく役割です。

単なるレビューや助言ではなく、方針を定め、実証し、組織に浸透させ、実装まで伴走することを期待します。

プラットフォーム横断のアーキテクチャ設計
・プロダクト横断の共通課題（分散トランザクション、データ整合性、障害耐性、Observability等）を踏まえた中長期アーキテクチャ刷新計画の策定
・中長期アーキテクチャ方針の策定
・個別チームの設計判断の検証・最終意思決定
・必要に応じたプロトタイプ実装による実証
・ADR・デザインレビューを通じた設計方針の浸透

基幹プロダクト群の設計・改善
・ID／認証基盤：スケーラビリティと安全性の両立
・決済・電子マネー基盤：高可用性・整合性の担保
・ポイント・クーポン基盤：事業拡張に耐える設計
・不正対策基盤：リアルタイム検知と耐障害性の両立

モダナイゼーションのリード
・オンプレ → GKE/EKSへの移行設計
・PHP／Java → Goへの段階的リアーキテクチャ
・Temporal／CQRS & Event Sourcingを活用した分散設計の統括
・eKYC導入・新規決済手段追加の設計統括

共通の設計基盤づくり
・SLI/SLO設計、信頼性目標の標準化
・Observability設計（障害検知・原因特定の高速化）
・API設計規約、データ整合性ルールの整備

組織レベルの設計リーダーシップ
・複数チームにまたがる合意形成の主導
・レビューやADRを通じた設計文化の醸成
・局所最適 → 全体最適への転換をリード
「ポジションの魅力」

5,000万人が毎日使う“DMMの心臓”を、動かしながら作り替える
認証・決済・ポイント・クーポン・不正対策といった基幹領域は、止めることが許されないシステムです。無停止での移行、データ整合性の担保、分散トランザクション設計、障害耐性設計など、他では得難い規模・制約の中で設計力を磨けます。

プラットフォーム全体の“設計の最終判断”を担う
単なるアドバイザーではなく、プラットフォーム全体の設計方針に対する最終判断権限を持ちます。個別チームの判断を束ね、DMM経済圏としての一貫性をつくる中心的役割です。

0→1 / 1→10 / 10→100 が同時に走る、希少な環境
DMMには、
・これから立ち上がる新規サービス（0→1）
・PMF後にスケールするプロダクト（1→10）
・数千万ユーザー規模の基幹サービス（10→100）
が同時に存在します。
「新しさの自由度」と「巨大基盤を守る責任」の両立という、極めて挑戦的で面白い環境です。

モダナイゼーションの最前線をリードできる
決済領域ではすでにTemporalやCQRS & Event Sourcingを活用した刷新が進行中。
これを個別最適に終わらせず、プラットフォーム全体の一貫性あるアーキテクチャへ拡張していく中心人物になれます。

AI時代の“次世代プラットフォーム設計”に挑める
I活用により各チームの開発速度が上がる中、
・仕様書駆動開発（Spec Driven Development）
・AIコストの可視化・標準化
・プロンプトインジェクション対策を踏まえたセキュリティ設計
など、AIを前提とした開発プロセス設計にも関与できます。
ただし、AIはあくまで手段。安全性を担保しつつ開発速度と品質を両立させる設計が本質です。
開発環境/チーム体制

開発環境

マイクロサービス
- 言語：Go
- クラウド環境：AWS・GCP
- コンテナオーケストレーション：Kubernetes
- CIツール：CircleCI
- CDツール：Spinnaker
- メトリクス/監視：Datadog
- 構成管理ツール：Terraform
- DB：Aurora、DynamoDBなど

レガシーサービス
- 言語：Java、PHP、Kotlin
- オンプレ環境：CentOS6、CentOS7
- クラウド環境：AWS・GCP
- CI/CDツール：Jenkins
- メトリクス/監視：Datadog
- DB：MySQL

共通
- プロジェクト管理：ZenHub、JIRA
- バージョン管理：GitHub、Bitbucket
- 情報共有：Confluence、Slack
- その他：Re:dash、PagerDuty

  チーム体制

プラットフォーム開発本部は、在籍200名以上／20〜25チーム規模で運営されています。
各プロダクトチームは、マネージャー／チームリーダー／メンバーを中心に5〜6名規模のケースが多く、オーナーシップを持ちながらユーザー/事業フィードバックを元に改善を継続します。

アーキテクトは、特定の1チームに閉じる役割ではなく、プラットフォーム全体を横断して関与する立場です。個別最適ではなく、複数チーム・複数プロダクトをまたいだ“全体最適”をリードします。

横断的に関与する領域

設計方針の策定・整合：認証・決済・ポイント・不正対策のアーキテクチャ方針を定義
依存関係の整理と責務境界の再定義：複雑化したプロダクト間の依存関係を可視化し整理
移行・モダナイゼーションの推進：オンプレ→GKE/EKS、PHP/Java→Goの基盤刷新を主導
品質・信頼性の底上げ：SLI/SLO、Observability、リリース運用、設計ガードレール整備

横断基盤チームとの連携

Microservices Platform：マイクロサービス基盤の提供・推進
Design System / FEエコシステム：デザインシステム・モノレポ基盤の提供・推進

意思決定の場

マネージャー会（週2時間）：プロジェクト・組織課題の解決
Tech Lead MTG（週1時間）：技術課題の解決（チームリーダー中心）
アーキテクチャレビュー / ADR：システムアーキテクトが中心となり設計方針を言語化

合同会社DMM.com

東京都港区六本木3-2-1住友不動産六本木グランドタワー24F

正社員

健康保険 雇用保険 厚生年金 労災保険

2026/06/16