合同会社DMM.comでは、生成AIを開発現場へ本格的に導入し、業務プロセスから組織構造、さらには人材評価に至るまで、抜本的な変革を推進しています。単なるツール利用にとどまらず、「AI駆動開発」を前提とした組織へと進化を遂げる中で、どのような成果が生まれ、新たな課題にどう向き合っているのか。同社のプラットフォーム開発本部 副本部長を務める石垣さんに、AI活用のリアルな実態と、これからのエンジニアに求められるスキルについて詳しく伺いました。
目的別にAIエージェントを使い分ける、開発現場のリアル
Q.まず、開発現場では現在どのような生成AIツールを、どのように活用されているのでしょうか？
石垣さん: 現在、開発現場では複数の生成AIツールを目的別に使い分けています。主にコーディングエージェントとして活用しているのが「Cursor」と「Claude Code」です。これらはエンジニアが自分の手元でAIと対話しながら開発を進める際の補助として使います。中でもCursorは、会社としてSSO（シングルサインオン）で管理しやすいという運用面のメリットから、申請すれば誰でも利用できる形で広く導入しています。一方、Claude Codeは利用を希望する部署が個別に申請して活用している形です。
それとは別に、「Devin」やGitHubの「Copilot」のようなツールも活用していますが、これらは少しカテゴリーが異なり、我々は「完全自律型AI」と位置づけています。Slackなどを通じて「このコーディングをやっておいて」と指示を出すだけで、裏側で自律的に作業を進めてくれるエージェントです。このように、エンジニアが自身の開発を補助させるコーディングエージェントと、独立してタスクを処理させる「完全自律型AI」を、状況に応じて使い分けるのが現在の主な活用法です。
| ツール名 | カテゴリー | 主な役割・特徴 |
| Cursor | コーディングエージェント | 開発者の手元で対話的にコーディングを補助。SSO連携により社内で標準的に利用。 |
| Claude Code | コーディングエージェント | 開発者の手元で対話的にコーディングを補助。部署単位で申請し利用。 |
| Devin | 完全自律型AI | Slack等からの指示で自律的にコーディングタスクを実行。 |
| GitHub Copilot | 完全自律型AI | Devin同様、独立したエージェントとして自律的な作業を依頼。 |
エンジニアからマネジメント層まで。AIがもたらした業務密度の劇的な変化
Q.生成AIの導入によって、現場の働き方は具体的にどのように変わりましたか？
石垣さん: エンジニアにとっては、これまで一人でコードを書いていた状況から、常に横にAIエージェントがいる状態へと変わりました。手元でCursorやClaude Codeを補助として使いながら、同時に裏ではDevinのような自律型エージェントを動かしているメンバーもいます。これにより、1時間あたりの業務密度が以前とは比較にならないほど高まっているのが実情です。
この変化はエンジニアに限りません。例えば部長職やエンジニアリングマネージャーといったマネジメント層も、AIの恩恵を受けています。これまでエンジニアに確認しなければならなかった少し複雑な仕様の把握や、データ抽出のためのクエリ作成などを、AIを使って自分自身で完結できるようになったのです。自社のシステムについて「この機能はどうなっているんだっけ？」とCursorに直接質問することも可能です。これにより、コミュニケーションコストが削減され、業務が格段に楽になり、組織全体の生産性が向上していると感じています。
AI活用の深化で見えた新たな課題。「データ勝負」と「エンジニアスキルの回帰」
Q.AI中心の業務構造へ変革を進める中で、見えてきた課題や壁はありましたか？
石垣さん: 弊社では、開発の一部だけでなく、仮説立案から要件定義、デザイン、開発、運用という一連のプロセス全体でAIを活用する「AI駆動開発」を進めています。例えば、AIとペアプログラミングをしながらAIが読み取りやすい仕様書を作成し、その仕様書を読み込ませるだけで開発やテストを自動化するといった取り組みも始めています。こうした中で、大きく二つの壁に直面しました。
一つ目は、「ナレッジの負債」です。AIの生産性は読み込ませるデータの質に左右されますが、社内の仕様書が整理されていなかったり、資料のコンテキストが不足していたりと、データの整備状況が不十分でした。この負債を解消し、AIが真価を発揮できる状態にデータを整えることが最大の課題となっています。
二つ目は、一周回って「エンジニアのスキル」の重要性です。AIに不適切な情報を与えるとハルシネーションを生成するため、AIの出力を鵜呑みにせず、AIが読み取りやすいようソースコードを整える（リファクタリングする）技術がより求められるようになりました。これは、「ロボット掃除機が効率よく動けるように、まず自分たちで床を片付ける」作業に似ています。興味深いことに、AIが使いやすい状態を目指してリファクタリングを行うことで、結果としてエンジニアの内部構造への理解が深まり、スキルの向上に繋がっています。AIは単なる開発の道具ではなく、エンジニアの育成ツールにもなり得ると感じています。
「守り」の工数を「攻め」に転換。AI導入がもたらした定量的・定性的な成果
Q.開発の業務構造を改革したことで、どのような効果や成果が得られましたか？
石垣さん: 定性的な効果としては、AIを使いこなそうとすることでエンジニア自身のスキルが相対的に向上している点が挙げられます。
定量的な効果については、我々は開発リソースの配分戦略という観点からアプローチしています。仮に100人、月の開発リソースがあったとして、従来はその50%が新規開発、残りの50%が運用・保守（Ops）に割かれていました。この状況を改善するため、2つの戦略を立てました。一つは、新規開発に充てている50人月の生産性を上げ、リードタイムを半分にする戦略。もう一つは、Opsの作業をAIに置き換えて工数を削減し、そこで浮いたリソースを新規開発に再配分する戦略です。後者でいえば、月に50人かかっていたOpsの半分をAIで代替できれば、新規開発に75%のリソースを割けるようになります。
現在、この戦略を着実に進めています。例えば障害発生後のレポート（ポストモーテム）作成は、Slackのやり取りをAIエージェントが自動で読み込み、要約する仕組みを構築しました。こうした取り組みによって、Opsの工数は5分の2程度削減されると見込まれ、その分を新規開発案件に充てられるようになります。また、マネジメントコストも大幅に下がりました。目標設定や月次の進捗トラッキング、評価といった業務をAIエージェントに任せ、Google Meetの録画やSlack、GitHub、Jiraの活動データを分析させ、評価の叩き台を作成させています。
トップダウンの目標設定と、ボトムアップの知見共有が生む推進力
Q.ここまでAI活用を浸透させるために、組織としてどのような工夫をされてきたのでしょうか？
石垣さん: 本格的に組織として動き出したのは2025年の3月頃、Devinが登場したあたりからです。当初は一部の意欲的なメンバーで進めていましたが、局所的な最適化では意味がないことに気づき、トップダウンで推進する方針に切り替えました。最初に「業務の50%をAIと共同作業にするか、AIに置き換える」というシンプルな目標を掲げ、全社的な取り組みとしてスタートさせました。
一方で、画一的な教育資料を用意してトップダウンで使い方を教える、という方法はとりませんでした。明確な目標さえあれば、あとは現場のメンバーが自発的に使い方を模索し始めると考えたからです。我々が提供したのは、そうして生まれた個人の知見を組織の知識に変えるための「場」です。具体的には、月1回、全社的なAI活用共有会を開催しています。ここにはDMM.comだけでなく、AI事業を主戦場とするグループ会社のAlgomaticやAlgoage、さらにはゲーム事業のメンバーなども参加し、それぞれの知見を共有します。この場で得たヒントから新たな活用法が生まれるなど、自律的な学習と実践のサイクルが生まれています。
投資対効果が問われるフェーズと、AI時代の組織論
Q.今後の展望についてお聞かせください。
石垣さん: Ops工数の削減と新規開発のリードタイム短縮という2つの軸は、引き続き強力に推進していきます。一方で、2025年が開発AIエージェント活用の「元年」として「とりあえず使ってみよう」という雰囲気が許容されたのに対し、今後は投資対効果（ROI）がよりシビアに問われるフェーズに入ると考えています。AIエージェントの活用に数千万、数億円というコストをかけるのであれば、そのリターンがどこにあるのかを明確にしなければなりません。それは売上の向上なのか、それとも人的リソースの代替なのか。
これからの組織運営は、「人を新たに採用するのか、それともAIを導入するのか」という選択を常に迫られることになるでしょう。これまで、正社員に加えて業務委託の方々をリソースの変動要因として調整してきましたが、その役割の一部をAIが担えるのかどうかを慎重に見極めていく必要があります。AIの導入が組織のコスト構造や財務諸表にどう影響を与えるのか。会社として、より高い視座で判断していくことが求められると思っています。
AI時代に「生き残るエンジニア」の条件とは
Q.AIに仕事が奪われるという不安を持つエンジニアもいるかと思います。
石垣さん: どのエンジニアが生き残るか。それは、「エンジニアリングのスキルがしっかりある人」です。設計力があり、AIが生成したソースコードが自身の理解の範疇にあって、その内容を適切にレビューできる人。そういう人はAIを強力なツールとして使いこなせます。
これからの開発チームの理想的な構成は、もしかしたら「優秀なテックリード1人に対して、AIエージェントが10個動いている」というような形かもしれません。組織はより少数精鋭になっていくでしょう。その中で価値を発揮し続けるために必要なのは、適切なアーキテクチャを設計し、AIエージェントに対して的確な指示を出せる能力です。エンタープライズ開発では、「ゲーム作って」と一言頼んで完成するような単純な話はありえません。既存の複雑なシステムとのしがらみの中で、どう改修を加えるかという高度な判断が求められます。結局のところ、AI以前から重要だと言われてきた「設計力」が、AIの登場によってさらに、そして急速に重要性を増しているのだと考えています。
Q.最後に、この記事を読んでいるエンジニアの方へメッセージがあればお願いします。
石垣さん: これからの時代は、AIを使いこなすための基盤となる設計能力を持つエンジニアがますます重要になります。
DMM.comでもそうしたスキルを持つエンジニアの採用を強化していますので、我々の取り組みに共感し、自らのスキルをAIと共に高めていきたいという意欲のある方からのご応募をお待ちしております。
採用情報ページ：https://dmm-corp.com/recruit/
オウンドメディア「DMM inside」：https://inside.dmm.com/