1. はじめに

こんにちは。DMM.comでプラットフォーム開発本部の副本部長をしている石垣です。

本記事では、DMM.comのプラットフォーム開発本部のAX戦略（AI Transformation）についてご紹介します。

プラットフォーム開発本部は、約200名のエンジニアを擁する組織としてDMMサービス全体のプラットフォーム基盤を支える役割を担っています。
サービス側が共通して利用するID基盤や決済システムを中心とした機能提供を行っています。私たちの役割の詳細についてはプラットフォーム開発本部の採用資料でも紹介していますが、約200人規模の開発体制を持つ組織として、機能特性から見てもその安定性と効率性はDMM全体のサービス品質に直結しています。

2. プラットフォーム開発本部のAX戦略について

AIのプロダクト導入に関しては2023年から始まっています。

inside.dmm.com

www.itmedia.co.jp

そのため、すでにAIを使った活用は一定のノウハウを蓄積していましたが、Vibe coding（AIを活用してできるだけ自然言語でコーディングする手法）については各チームが個別に取り組んでいました。

developersblog.dmm.com

詳細については上記の記事に譲りますが、当然そのままではノウハウが溜まっていかず、車輪の再発明になるため、本部の人数規模の利点を活かして本部全体で統一的なアプローチを取っていこうと意思決定をしました。具体的には、共通して動くべき部分は本部で横断的な仕組みを提供し、個別最適化が必要な部分についても支援する方向性をとっています。

3. 組織マインドを醸成する「目標と目的」のセッティング

目標設定及びAIコストへの投資対効果ですが、目標と目的だけ決めて走り出しています。暫定の目標が無いと走りにくいため、フレキシブルな状態を前提に本部全体の目標として以下を掲げています。

目標「人でやっていた業務の50%をAIに置き換えた（協働）うえで、開発リードタイムへの変化を観測する」

まずは、目標の解像度を低く抽象的に置いておくと組織が自律的にその方向性に思案し始めるので、この効用を使っています。この半年間は、業務の50%を目安にAIとの効果的な協働の実現に注力します。AIへの単純な置き換えではなく、人間の判断やクリエイティブな作業を補完・強化するパートナーとして活用していきます。結果としての開発リードタイムがどう変化するかは、実際の導入と計測を通じて随時アップデートしていく予定です。

また、AIツールの投資対効果については、置き換えていくプロセスごとに計測、もしくは撤退ラインを決めるのが良さそうだと思っています。例えば、Vibe Codingについては、適切に協働できる箇所（品質特性）は見極めながら適応していきます。その結果として、生産性の指標であるSPACEでいうところのPerformance（パフォーマンスと開発速度）はどうなっているのか。または開発者体験のSatisfaction and Well-being（開発者の満足度と健康状態）の満足度を撤退ラインとして持っていてもよいでしょう。

4. AXは、プロセスを"AI"に置き換えるのではなく、"AI"前提のプロセスに作り変える

目的のセンターピンとして、プロセスを"AI"に置き換えるのではなく、"AI"前提のプロセスに作り変えることを意識します。 AIを導入するにあたって、よくある間違いは、既存の業務プロセスにそのままAIを当てはめようとしてしまうことです。このやり方では、かえって大きな工数が発生します。

その際、BPR（ビジネスプロセス・リエンジニアリング）による抜本的な業務フローの見直しに加え、TOC理論（制約理論）の視点を取り入れることで、より効果的な改善が可能になります。流れとしては、TOC理論の考え方で「組織やプロジェクト全体のボトルネック（制約）」を特定し、その制約の中でAIをどのように活用できるかを検討します。次に、BPRのアプローチで、AIを活用することを前提に業務プロセス全体をゼロベースで再設計し、制約の解消や全体最適化を目指します。このように、TOC理論で現状の課題や制約を明確にし、BPRでAIを組み込んだ新しい業務プロセスを構築することで、単なる部分最適ではなく、組織全体の生産性向上や価値創出につなげることができます。

引用 : https://speakerdeck.com/i35_267/kai-fa-huezudakedehanai-aidao-ru-hadonoyounijin-meteikubekika?slide=10

まず着手しているのが所属する人数から算出される約200人月の工数分析です。普段行っている業務は各プロダクト・チームごとに違うため、可視化を行い、どのような業務がAIに置き換えられるかの筋道を立てていきます。また、対象はエンジニアだけではなくPdMやデザイナー、運営といったすべてを対象としています。できるだけAIに任せられる部分は任せながら、よりクリエイティブな部分を人が行うことを目指します。

具体的には、以下の観点で業務プロセスを分析し、下図のような形で整理しています。

開発区分
- 新規・エンハンス開発、保守開発、運用工数、管理、その他
プロセス
業務プロセス
業務プロセスの目的
課題
AI置き換え可能性
毎月の工数(人日)

業務プロセス

この分析に基づき、具体的なプロジェクトを立ち上げ、各チームからAI活用の熱量と活用実績があるメンバーをアサインしたタスクフォースチームを組成します。

5. 25年4月現在、進行中のプロジェクト

すでに動いているプロジェクト例としては以下の3つがあります。

プロジェクト名	概要
pj-vibe_coding	AIスキルの標準化・育成を行う生成AIの活用におけるノウハウの分散やスキルのばらつきを防ぎ、無駄な検証やコストの発生を抑えます。場当たり的な活用を回避して継続的な生産性向上を実現するため、組織として戦略的かつ効果的なAI活用の仕組みを目指します
pj-ai_cost	AIコストの見える化と計測を行う AIにかけたコストの見える化と効果の計測を統一したフォーマットで提供します
pj-inq_automation	顧客応対品質の向上を目指すプラットフォーム基盤として機能を顧客に提供しているため、質問や要望がSlack経由で月130件ほど来ます。これを現在はすべて人が対応しているため、AIを使い自動で振り分け、自動で返信することを前提にAI化することで顧客及び所属エンジニアのエンゲージメントを向上させていきます。同時に応対品質を維持するために、AIと人の回答を評価する仕組みを作り込んでいきます
prj-doc_as_code	コードとドキュメントの距離を近くし、AIリーティングしやすい状態にするドキュメントの形骸化及び運用コストを限りなくゼロに近づける
prj-ai-pdm_pm_mg	PdM/PM/開発マネージャー領域のAI活用要件定義、書類選考、競合調査、進捗報告（prj doc as code）をAI化し、マネジメントコストを削減していく

まだ走り出したばかりですがVibe codingについては価値提供のリードタイムに大きく影響を与えていくので力を入れて進めていく予定です。また、分析してみると運用コストによって開発工数が割けていないチームも多いためプロジェクト化してコストを下げていく予定です。

6. 今後の注力テーマ「コードとドキュメント（prj-doc_as_code）」

今後においては、業務プロセス分析の結果を見ても「コードとドキュメント」の領域においては大きな可能性を感じています。コードとドキュメントの距離を近づけることで、AIによるリーディングが格段にしやすくなります。これにより、従来議論されてきた「不要なドキュメント更新問題」も解消され、常に最新の情報を保つことが可能です。さらに、AI AssistantやMCP Serverのような仕組みを活用することで、ユーザー体験の向上にもつながります。ドキュメントとコードが密接に連携することで、開発者だけでなく利用者にとっても、より分かりやすく使いやすいサービスを提供できるようになります。