職種の壁を越えて全員で Claude Code を使う（DeNA）— SDD ワークフローと週次共有会で「テキスト仕様→動く実物」を1〜2日に¶

作成日: 2026-07-18 出典 / きっかけ: DeNA Engineering Blog「エンジニアが仕掛ける『職種の壁を越えたAI活用』。チーム全員でClaude Codeを使いこなす文化と仕組み」（シリーズ「AIジャーニーの足跡」、聞き手: 田邉優斗〈データ基盤部 MLエンジニア・25新卒〉、2026-07-14） https://engineering.dena.com/blog/2026/07/claude-code-team-collaboration/ 関連: smarthr_aiドリブン開発をチームに定着させた話 / エアークローゼット_非エンジニア内製化_sandbox_mcpと議事録rag_整理 / lineヤフー_組織ax_仕様構造化と海外先行事例_整理 / sign_off_layer_ai時代の承認とオーナーシップ_整理 / ミラティブ_ashura_分析民主化aiエージェント基盤_整理 / ai駆動開発ループ_interview-dev-loop_整理

0. 要点（3行）¶

PdM・エンジニア・デザイナーの3職種が同じ Claude Code の土俵に乗るチームの実践インタビュー。芯は「仕様書というテキストを、AI が読み書きする一次成果物に格上げした」こと。人間が仕様を書き切ってから作るのではなく、超初期に動くモックを出して触りながら仕様を詰めるループに変えた。
効いている仕組みは3つ —（1）エンジニア自作の SDD（Spec Driven Development）ワークフローという Claude Code プラグイン（PRD→技術仕様→コード生成を一貫化）、（2）非エンジニアが安全に使えるよう ガードレールを敷いた自作ネイティブアプリ、（3）週1回・職種横断の共有会。ツール配布ではなく「安全な入口＋場」で普及させている。
最大の学びは「AIありき」で最初から設計せよ。実際は「既存の仕様フォーマットや運用ルールに AI を後付けで“はめ込む”」進め方をしてしまい、AI が理解・作業しやすいルールを最初からトータル設計しておけばよかったと振り返る。効果は「仕様定義→動くもの」が 2週間〜1ヶ月 → 1〜2日、モックは数分で生成、ドキュメントはほぼ人手を介さず最新化（すべて自己申告値）。

1. 誰の・どんな体制の話か¶

記事はインタビュー形式で、1チームの中に PdM・エンジニア・デザイナーが同居し、全員が Claude Code を日常的に使う状態を描いている。個々人の氏名は PdM/エンジニア/デザイナーとして匿名化されている。

職種	記事内の担当	AI 活用の要点
PdM	事業者向け管理画面と一般ユーザー向け Web の仕様調整、複数ステークホルダー対応	議事録・Slack URL を AI に渡し Notion の PRD を自動更新。仕様変更箇所の洗い出しも AI
エンジニア	SDK 開発チーム	自作の SDD ワークフロー（Claude Code プラグイン）で PRD→技術仕様→コード生成まで AI。GitHub で仕様とコードを同期
デザイナー	チーム3名。UI/UX とデザインシステム整備	モックの方向性確定後、AI に「Figma のオートレイアウト適用したデータにして」と指示して綺麗なデザインデータを出力

聞き手はデータ基盤部の ML エンジニア（田邉優斗、25新卒）。連載「AIジャーニーの足跡」の一本。

2. 何が変わったか — 「テキスト仕様」から「動く実物」へ¶

従来は 仕様を文章で書き切ってから実装していた。AI 導入後は、超初期に動くモックを出し、触りながら仕様を詳細化する順序に反転した。これがこの事例の背骨。

【従来】 仕様を文章で確定 ─────────────→ 実装 ──→ 触って初めて考慮漏れ発覚 ──→ 手戻り
          （2週間〜1ヶ月）

【AI後】 ざっくり要求 ──→ 数分でモック生成 ──→ 触りながら仕様を詰める ──→ 実装/デザインデータ化
          └ この段階で「ダイアログ外タップ時の挙動」等の細かいインタラクションを潰す（1〜2日）

観点	Before	After（記事の自己申告値）
仕様定義 → 動くものを見る	2週間〜1ヶ月	1〜2日
モック作成	—	数分
仕様書（PRD）の最新化	人手で反映	議事録/Slack を AI が吸い上げほぼ人手を介さず最新化
手戻り	実装後に考慮漏れ発覚	超初期のモックで詳細化し未然防止
デザインデータ化	手作業	モック確定後 AI が Figma オートレイアウト適用データを生成

ポイントは 「動くモックを、仕様を固める“前”に出す」こと。触れる実物があると、細かいインタラクション（例:「ダイアログ表示中に外側エリアをタップしたらどう挙動するか」）を早期に潰せる。

3. 仕組みの芯 — 3つの装置¶

3-1. SDD（Spec Driven Development）ワークフロー — エンジニア自作の Claude Code プラグイン¶

「自作した『SDD（Spec Driven Development）ワークフロー』という Claude Code のプラグインを活用して開発しています。PRD や技術仕様書を AI に作らせ、その仕様書を基にコードの生成までをすべて AI に任せる」

PRD → 技術仕様書 → コード生成を一本のパイプラインにし、仕様書を AI の一次成果物として扱う。
仕様とコードのズレ対策として GitHub 上でブランチ管理し、コードと仕様書を同期。「並行開発しているうちにコードと仕様がどうしてもズレていってしまう」課題への打ち手。

補足（一般化・要確認）: 「Spec Driven Development」は業界共通の潮流で、GitHub 公式の spec-kit（/specify→spec.md、/plan→plan.md、/tasks→tasks.md、/implement→コード生成、を feature ブランチ＋PR で回す）が代表例。ただし記事の SDD は DeNA エンジニアの“自作プラグイン”であり、spec-kit をそのまま使っているとは明記されていない（思想が同系統というだけ。中身は要確認）。cf. 仕様の構造化で先行する lineヤフー_組織ax_仕様構造化と海外先行事例_整理。

3-2. ガードレールを敷いた自作ネイティブアプリ — 非エンジニアの安全な入口¶

「エンジニア側で事前に『ガードレール』を設けた自作のネイティブアプリを提供」

非エンジニアが CLI で直接 AI を叩くと「誤って他のプロジェクトを壊したらどうしよう」という心理的ハードル・恐怖心が普及の律速になる。
そこで エンジニアが事前に安全柵（ガードレール）を組み込んだアプリを用意し、非エンジニアはその中で安全にタスク管理・AI 活用できるようにした。「危険な操作を物理的にできない入口」を先に作るのが要点。
同型の設計思想: 非エンジニア内製化を sandbox＋社内 MCP で安全化したエアークローゼット_非エンジニア内製化_sandbox_mcpと議事録rag_整理、承認・オーナーシップ層で締める sign_off_layer_ai時代の承認とオーナーシップ_整理。

3-3. MCP で Notion / Slack のコンテキストを吸い上げ¶

「Slack での日々の細かい議論のコンテキストを MCP 経由で AI に吸い上げさせ」「その情報をベースに、GitHub 上の詳細な PRD を AI に自動でブラッシュアップさせていく」

議事録・Slack の URL・日々の議論を MCP 経由で AI に渡し、GitHub 上の PRD を自動ブラッシュアップ。人間の転記作業をほぼ消す。
これにより「PRD の最新化」がイベントドリブン（議論が起きたら反映）に近づく。

3-4. 週1回・職種横断の共有会 —「場」がセットで効く¶

「週に1回、職種をまたいで AI の活用成果や試行錯誤を共有し合える場がセットされていた」

仕組み（プラグイン・アプリ）だけでなく 成功も失敗も持ち寄る定例を置いた点が、SmartHR 事例と共通する普及の勘所（→ smarthr_aiドリブン開発をチームに定着させた話の「週30分 MTG＋Slack で暗黙知を移植」と同型）。属人化した“使い方の行間”を職種を超えて配る装置。

4. つまずき・課題（記事が正直に挙げているもの）¶

#	課題	中身
1	細かいインタラクションの考慮漏れ	「ダイアログ表示中に外側エリアをタップしたらどう挙動するか」等が抜けやすい。→ モックを早期に触って潰す運用で対処
2	コードと仕様のズレ	並行開発でコードと仕様書が乖離。→ GitHub でのブランチ同期＋SDD で仕様を一次成果物化
3	AI 設計の後付け（最大の反省）	「既存フォーマットに AI をどう“はめ込むか”」で進めた。最初から「AIありき」でルールをトータル設計すべきだった
4	Slack で AI が文脈を判断しにくい	「いまどちらがボールを持っているか」「期限はいつか」を AI が読み取れない。→ Slack 文面の運用ルール化が必要
5	デザインの暗黙知	「どの画面でどのコンポーネントを使うか」がデザイナー間の暗黙の了解で、ドキュメント化されていない。→ 暗黙知の言語化が課題
6	非エンジニアの心理的ハードル	「他プロジェクトを壊す恐怖」。→ ガードレールアプリで入口を安全化（3-2）

5. 一番の学び — 「AIありき」で最初から設計する¶

課題3が記事の核心。要約するとこうなる。

やってしまったこと: 人間向けに最適化された既存の仕様フォーマット・運用ルールを温存したまま、そこへ AI を“後付けで差し込んだ”。
あるべき姿: AI が理解しやすく作業しやすいことを前提に、仕様フォーマット・Slack 運用・デザインシステムの言語化までトータルで最初から設計する。
具体化の方向: 「人間がゼロから書くことを廃止」し「PRD 作成時に特定のコマンドやスキルを使う」ようにルール化する、Slack 文面を AI が解釈できる形に運用ルール化する、デザインの暗黙知を言語化する。

教訓: AI 活用は「既存プロセスに AI を足す（retrofit）」ではなく「AI が一級市民である前提でプロセスを組み直す（AI-native design）」。後付けは局所最適で頭打ちになる。

6. まとめ — 状況 → この事例の打ち手（早見表）¶

局面	この事例の答え
仕様の手戻りが多い	仕様を書き切る前に数分でモックを出し、触りながら詳細化する順序に反転
コードと仕様がズレる	SDD で仕様を AI の一次成果物化＋GitHub ブランチで同期
PRD 更新が重い	議事録・Slack を MCP で吸い上げて PRD を自動ブラッシュアップ
非エンジニアが怖がる	ガードレールを組んだ自作アプリという安全な入口を先に用意
使い方が属人化する	週1回・職種横断の共有会で成功/失敗と“行間”を配る
デザインが再現できない	デザインシステムを整備し、暗黙知を言語化（＋AI に Figma データ生成を任せる）
そもそもの設計	後付けをやめ、最初から「AIありき」でルールをトータル設計

一言で: この事例の新しさは「エンジニアが非エンジニアの安全な入口（ガードレールアプリ）と仕様の型（SDD）を先に用意し、週次の場で全職種を同じ土俵に上げた」こと。ツール導入ではなく “職種の壁を越える足場づくり” が主題。

7. 隣接事例との位置づけ¶

事例	共通点	この DeNA 事例の固有性
smarthr_aiドリブン開発をチームに定着させた話	週次の場で暗黙知を移植／上流をスキルで型化	SmartHR は開発チーム内。DeNA は PdM・デザイナーまで含む職種横断
エアークローゼット_非エンジニア内製化_sandbox_mcpと議事録rag_整理	非エンジニアを安全柵つきで内製化／MCP で議事録を吸う	エアクロは sandbox＋社内 MCP 基盤。DeNA は自作ネイティブアプリでガードレール
lineヤフー_組織ax_仕様構造化と海外先行事例_整理	仕様を構造化して AI が扱える一次成果物にする	LINEヤフーは全社 AX。DeNA は 1チーム内で SDD プラグインとして実装

注意・留保¶

本記事は DeNA のインタビュー体験談。数値（「2週間〜1ヶ月 → 1〜2日」「数分でモック」「ほぼ人手を介さず最新化」）はすべてチームの自己申告で、外部検証・定義（母集団・測定方法）は示されていない。
SDD ワークフローは DeNA エンジニアの自作プラグイン。GitHub の spec-kit と思想は同系統だが、spec-kit を使っているとは明記されていない（実装の中身・コマンド体系は記事に無く要確認）。
「ガードレールを敷いた自作ネイティブアプリ」の技術的中身（何をブロックするか、権限モデル、実装スタック）は記事に明記なし。
登場人物の氏名・チーム名・プロダクト名は記事では匿名化されている。

参考リンク¶

DeNA Engineering Blog: エンジニアが仕掛ける「職種の壁を越えたAI活用」。チーム全員でClaude Codeを使いこなす文化と仕組み（2026-07-14） — https://engineering.dena.com/blog/2026/07/claude-code-team-collaboration/
同シリーズ「AIジャーニーの足跡」関連: 「AIを個人で使ってるだけじゃ、もったいない——チームの文化として根付かせるための仕組みとは？」（2026-03-05） / 「SQL未経験でも即戦力に？アナリスト組織が挑む『AIネイティブ』な働き方改革」（2026-01-27）
GitHub spec-kit（Spec-Driven Development の公開ツールキット・一般参照） — https://github.com/github/spec-kit
Spec-Driven Development with AI（GitHub Blog） — https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

作成: 2026-07-18 ／最終更新: 2026-07-19