DeNAのエンジニアブログが、大規模プラットフォーム開発チームでプロダクトマネージャー・エンジニア・デザイナーがそろってClaude Codeを使いこなす実践事例を公開した。個人の効率化にとどまらず、職種間の連携や運用をAI前提で設計する取り組みを紹介している。
DeNAのエンジニアブログが、大規模プラットフォーム開発チームでプロダクトマネージャー・エンジニア・デザイナーがそろってClaude Codeを使いこなす実践事例を公開した。個人のコーディング効率化にとどまらず、職種間の連携や運用をAI前提で設計している点が特徴である。
最も注目されるのは、仕様確定から動くモックを確認するまでのサイクルが従来の2週間〜1ヶ月から1〜2日へ短縮された点だ。議事録やSlackの議論をAIに渡し、仕様書(PRD)の更新をほぼ自動化した。さらに非エンジニアが安全に使えるよう、エンジニアがガードレール付きの自作アプリを提供している。
背景には、エンジニア個人の速度が上がっても職種間の受け渡しが遅ければリリース速度は上がらないという課題がある。Claude Codeは2025年5月の一般提供から6ヶ月で年間売上10億ドル規模に到達したとAnthropicが発表しており、ツールの評価軸が個人効率からチームのリリース速度へ移りつつあることを示す国内事例である。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
Claude CodeはAnthropicが提供するAIコーディング支援ツールで、2025年5月の一般提供開始からわずか6ヶ月で年間売上10億ドル規模に到達したと公式が発表している。従来、仕様策定・デザイン・実装は職種ごとに分断され、テキスト仕様書を読み解いて画面を作り認識をすり合わせるのに2週間から1ヶ月かかっていた。DeNAではエンジニア個人のコーディング速度が上がっても、職種間の連携に時間がかかればリリース速度が上がらないという課題に直面していた。そこで週1回の職種横断でAI活用の成果を共有する場を設け、非エンジニアもツールを使いこなす文化を育ててきた。
AIコーディングツールの導入が個人の生産性から「チーム全体の開発プロセス改革」へ移行しつつあることを示す具体例である。仕様確定から動くモックを見るまでのサイクルが2週間から1〜2日に短縮された点は、AI導入の投資判断を検討する開発組織にとって参考になる。同時に「暗黙知の言語化」や「非エンジニアが安全に触れるガードレール」の整備など、成果を出すための前提条件も明示されている。
DeNAのエンジニアブログが、大規模プラットフォーム開発チームでプロダクトマネージャー・エンジニア・デザイナーがそろってClaude Codeを使う実践を公開した。最も効いた変化は、仕様確定から動くモックを確認するまでのサイクルが従来の2週間〜1ヶ月から1〜2日へ短縮された点だ。
エンジニア個人のコーディング速度が上がっても、仕様策定やデザイン、職種間のコミュニケーションに時間がかかっていては、最終的なプロダクトのリリース速度は上がりません。
地の文で開くと、この一節は「個人が速くなっても職種の受け渡しが遅ければ全体は速くならない」という問題意識である。DeNAはこのボトルネックをAI前提で組み替え、個人効率化ではなくチームの開発プロセスそのものを対象にした。読者にとっての含意は、AIコーディングツールの評価軸を「1人がどれだけ速く書けるか」から「仕様から動くものまで何日で届くか」へ移すべきだということだ。
DeNAの事例で再現の鍵になるのは、ツール選定と運用の設計である。公開された取り組みは主に次の3点に整理できる。
この3点は、AIを配って終わりにせず「誰がどう安全に使うか」まで設計している点で参考になる。ツール導入の成否は、モデルの性能より運用の設計に寄ることを示している。
この事例が効くのは、職種間の受け渡しに時間がかかっている国内の開発組織である。仕様書を読み解いて画面を作り認識をすり合わせる従来の進め方は、動くモックを1〜2日で出す組織と比べてリリース速度で差が開く。
一方で、そのまま真似ても再現しにくい前提がある。DeNAは週1回の職種横断でAI活用の成果を共有する場を設け、非エンジニアがツールを使いこなす文化を育ててきた。ツール導入の効果は「暗黙知の言語化」や「安全に触れる仕組み」という前提条件の上に乗っている。ガードレール付きアプリの内製にはエンジニアの工数がかかる点も見落としやすい。導入コストの公開数値はないが、ツール料金より運用整備の負荷が判断材料になる。読者が自分ごととして測るべきは、ツールの導入可否ではなく、自社の連携ボトルネックがどこにあり、それをAIで置き換えられるかである。
立場別、明日から動ける一手。
自社で仕様確定から動くモックを確認するまでの現行サイクル日数を、DeNAが示す1〜2日と比較できる形で測る。
議事録やSlackの議論から仕様書(PRD)を更新する範囲と、非エンジニアがAIを触れる際のガードレールの境界を定義する。
1つの機能開発でClaude Codeへ議事録を渡し、仕様書更新とモック生成にかかる工数を試す。
「仕様確定から動くものまで1〜2日」という短縮幅に対し、開発組織の関心が集まっている。
公式発表と各所の反応から編集部が要約した主な論点です。個別のX投稿そのものは下部のセクションに表示されます。
「仕様確定から動くものまで1〜2日」
個人のコーディング効率化の話が多いなか、PdM・デザイナーを含む職種横断でツールを1本に絞る運用や、議事録・Slackから仕様書(PRD)を自動更新する仕組みが、自社にどう移植できるかという論点で受け止められている。非エンジニアが安全に触れるガードレール付き自作アプリの整備コストや、成果を出す前提となる暗黙知の言語化・文化づくりへの言及が今後の争点になる。
※トレンド検出時刻付近の人気投稿を表示
