---
title: Experiment and Adapt  the Spec-Driven Development Process  with nameless - 仕様駆動開発のプロセス試行と既存プロダクト開発への適応 -
tags: 
author: [蜜葉](https://convert.docswell.com/user/mitsuba_yu)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/VJNY1Z4878.jpg?width=480
description: https://kddi-agile.connpass.com/event/384249/
published: February 20, 26
canonical: https://convert.docswell.com/s/mitsuba_yu/ZVMQXJ-2026-02-20-123649
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/VJNY1Z4878.jpg)

Experiment and Adapt
the Spec-Driven Development Process
with nameless
- 仕様駆動開発のプロセス試行と既存プロダクト開発への適応 -
@mitsuba_yu


# Page. 2

![Page Image](https://bcdn.docswell.com/page/YE9P5ZQXJ3.jpg)

GitHub Copilot Agent
with Azure Boards MCP Server
カンバンからコミットまでを、エージェントで。
@mitsuba_yu


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GE8DY1G9ED.jpg)



# Page. 4

![Page Image](https://bcdn.docswell.com/page/LELM4QGM7R.jpg)

趣味、写真。


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4JMYK1Q6JW.jpg)



# Page. 6

![Page Image](https://bcdn.docswell.com/page/PJR9XL8N79.jpg)



# Page. 7

![Page Image](https://bcdn.docswell.com/page/PEXQ6W88JX.jpg)



# Page. 8

![Page Image](https://bcdn.docswell.com/page/3EK91VKLED.jpg)

nameless
• https://name-less.space
• 割と真面目に作った完全自作のPhoto Portfolio CMS
• 2020年に開発して、継続開発・運用中（当時 .net core 3.1）
• Lightweight ArchitectureとNoDBをコンセプトに
Azure DevOps + Azure Entra ID + Azure WebApps + Azure Blob
+ asp.net core mvc（.net 10）+ Cloud areで実装
• 開発秘話はこちら
[nameless ある沼にDeepDiveした人のポートフォリオ]
fl
8/76


# Page. 9

![Page Image](https://bcdn.docswell.com/page/L73WQMZ675.jpg)



# Page. 10

![Page Image](https://bcdn.docswell.com/page/87DK96RMJG.jpg)

Today’s Takeaway
• namelessに仕様駆動開発で機能追加した話
↓
• 最近話題の仕様駆動開発のプロセスについて
• 既存プロダクトへの仕様駆動開発の適応例
• 仕様駆動開発で、できあがる成果物ってなに？
10/76


# Page. 11

![Page Image](https://bcdn.docswell.com/page/VJPKZYWQE8.jpg)

Caution
今日、駆け足になるので細かいところは飛ばしながらお話します。
資料は公開するので、気になるとこがあれば資料を眺めてみてください。
今日の話はすべて個人的見解です。
これが正しい、あれがダメとかいう話ではないです。
聞きたいことがあれば
なんらかの方法で連絡とってもらってもOKです！
11/76


# Page. 12

![Page Image](https://bcdn.docswell.com/page/2EVVWG8PEQ.jpg)

Agenda
• 仕様駆動開発 is 何？
• 開発環境
• つくった機能と出来上がったもの
• 機能をつくるまでに準備したこと
• 試した方法と最終的なプロセス
• まとめ
12/76


# Page. 13

![Page Image](https://bcdn.docswell.com/page/57GLD85QEL.jpg)

What is Spec-Driven Development
13/76


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4EQY19ZWJP.jpg)

What is Spec-Driven Development
• 教科書的に言えば
「コードを書く前に、まず人が『何を作るか』という仕様を厳密に定義し、
その仕様自体を開発の核（ソース）とする」手法
• SDDを実践するための代表的なライブラリとして、cc-sddやSpec Kitがある。
14/76


# Page. 15

![Page Image](https://bcdn.docswell.com/page/KJ4WRX3171.jpg)

What is Spec-Driven Development
1. 要件定義・構造化: 何を作るかを具体的に定義し、システムが満たすべき条件を文書化する。
2. 仕様の決定: AIに読み込ませる形式で、仕様書（スペック）を定義する。
3. 設計・タスク化: 仕様を基にAIが詳細設計やAPIスキーマ、タスクリストを作成する。
4. 自動生成・検証: AIがコーディングとテスト生成を行う。仕様とテストの不一致を防ぐ。
15/76


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LE1YQN157G.jpg)

What is Spec-Driven Development
• 実務的に言えば、
小さくない規模のプロダクト開発、複雑な要件の実装に
コードの品質やアーキテクチャを担保した状態でAIに開発をさせたい手法
• PBI：「ユーザーとして、〇〇をしたい。なぜなら××だからだ」という
ストーリーと受け入れ条件を定義
• SDD：受け入れ条件をゴールとし、
要件・仕様を定義 -&gt; 実装工程の合意 -&gt; 実装
16/76


# Page. 17

![Page Image](https://bcdn.docswell.com/page/GEWGM48WJ2.jpg)

Spec-Driven Development vs Vibe Coding
• AIに全てを委ねて開発させるVibe Codingは小さい規模の開発に向いている
• Vibe CodingにSpecという
ードレールを敷いて、実装方法を人間が合意しながらAIに
実装させるために中間ドキュメントを作成しながら開発する手法
• 言い換えれ
、AIに働かせたいがために、
多くのドキュメントを人がチェックをすることになる。 -&gt; つらい
ガ
ば
17/76


# Page. 18

![Page Image](https://bcdn.docswell.com/page/47ZLQ282J3.jpg)

WaterFall-Development ?????
• プロダクトレベルですべての仕様を完全に決めた状態で作るのではなく、
機能提供や価値提供レベルで仕様を作成し、開発、レビューからFBをもらって
リリースへつなげる（アジャイル型）
• １度しかレビューせず、ループを回さないウォーターフォールやV字モ
ルとは違う
• プチウォーターフォールなのでは？？？
18/76
デ
https://service.shiftinc.jp/column/4850/


# Page. 19

![Page Image](https://bcdn.docswell.com/page/YJ6W6VK6JV.jpg)

Development Environment for nameless
19/76


# Page. 20

![Page Image](https://bcdn.docswell.com/page/GJ5M6DP5J4.jpg)

Development Environment for nameless
• Windows , Visual Studio , GitHub Copilot
↓
• Mac , Visual Studio Code , Claude , Azure DevOps MCP Server
• 公私ともに普段使いがMac。C#書く時だけWindows（というかVS）を使っていた。
• 正直いちいちWindows起動するのめんどう。
お仕事でもC#を書くことがあるので、この際Mac環境に移行。
• そもそもIDEの機能に頼らないといけないほど、自分でコード書かなくなった。
20/76


# Page. 21

![Page Image](https://bcdn.docswell.com/page/LE3WQM35E5.jpg)

New features
21/76


# Page. 22

![Page Image](https://bcdn.docswell.com/page/8EDK964Y7G.jpg)

New features
• 仕様駆動開発で追加した新機能
• 機材管理
• 写真一括アップロード
• 組写真
22/76


# Page. 23

![Page Image](https://bcdn.docswell.com/page/V7PKZYM2J8.jpg)

New features - 機材管理
• 過去の写真メタデータを集計して、
機材の所持状況を管理したい。
• マウント別に整理したい。
23/60


# Page. 24

![Page Image](https://bcdn.docswell.com/page/2JVVWG9XJQ.jpg)

New features - 機材管理
• 機材名を選択して、その機材名が
使われている写真を一覧で表示したい。
• いままで機材名の入力が手入力だった。
そのせいでブレがあるので統一して
修正したい。
24/60


# Page. 25

![Page Image](https://bcdn.docswell.com/page/5EGLD8ZRJL.jpg)

New features - Bulk Upload
• いままでは写真を１枚ずつ選択して
カメラ情報やレンズ情報を入力して
アップロードして公開していた。
• 旅先で多くの写真を撮っては１枚ずつ
アップロードするのは面倒だった。
25/60


# Page. 26

![Page Image](https://bcdn.docswell.com/page/4JQY19LY7P.jpg)

New features - Bulk Upload
• 複数枚の写真をとりあえず一括
アップロードできるようにした。
• アップロードした写真はデフォルト
非表示。
• カメラ情報などメタデータを入力
して表示状態に切り替えることで
初めて公開するようにした。
（非公開・編集機能は既存機能）
26/60


# Page. 27

![Page Image](https://bcdn.docswell.com/page/K74WRXDZE1.jpg)

New features - 組写真
• 単一の写真では表現できない、
ひとつのテーマやストーリー、時間軸や視点
などを複数枚の写真で表現する手法
• 以下２機能で構成される
• Adminで組写真としてアップロードしたい
• 公開ページで組写真として表示したい
27/60


# Page. 28

![Page Image](https://bcdn.docswell.com/page/LJ1YQNZDEG.jpg)

組写真
28/60


# Page. 29

![Page Image](https://bcdn.docswell.com/page/GJWGM49872.jpg)

機材管理、
一括アップロード、
組写真
の３機能をつくった話です。
29/76


# Page. 30

![Page Image](https://bcdn.docswell.com/page/4EZLQ29973.jpg)

- 仕様駆動開発のプロセス試行と既存プロダクト開発への適応 -という副題どおり
しかも自作仕様駆動で。
30/76


# Page. 31

![Page Image](https://bcdn.docswell.com/page/Y76W6VKD7V.jpg)

New features UserStory Mapping
with Claude Desktop
31/76


# Page. 32

![Page Image](https://bcdn.docswell.com/page/G75M6DP874.jpg)

32/18


# Page. 33

![Page Image](https://bcdn.docswell.com/page/9J29M86VER.jpg)

Vive Coding Prompt?


# Page. 34

![Page Image](https://bcdn.docswell.com/page/DEY4X69QJM.jpg)

大きな価値提供


# Page. 35

![Page Image](https://bcdn.docswell.com/page/VJNY1ZL278.jpg)

小さな価値提供


# Page. 36

![Page Image](https://bcdn.docswell.com/page/YE9P5Z4DJ3.jpg)

1機能


# Page. 37

![Page Image](https://bcdn.docswell.com/page/GE8DY1Q5ED.jpg)

UserStory to Product Backlog Items
• UserStoryからPBIを起こすとこんなかんじ
37/76


# Page. 38

![Page Image](https://bcdn.docswell.com/page/LELM4QX37R.jpg)

UserStory to Product Backlog Items
• UserStoryからPBIを起こすとこんなかんじ
38/76


# Page. 39

![Page Image](https://bcdn.docswell.com/page/4JMYK1LMJW.jpg)

UserStory to Product Backlog Items
• UserStoryからPBIを起こすとこんなかんじ
39/76


# Page. 40

![Page Image](https://bcdn.docswell.com/page/PJR9XLKL79.jpg)

Product Backlog Refinement
• PBIの中身はこんなかんじ。
• これで仕様と呼ぶにはちょっと…
もう一声がんばってほしい。
• そこでPBIをよりよくするために
既存コードから
プロダクト概要を作成して、
• PBIの粒度を指示して、
リファインメントする。
40/76


# Page. 41

![Page Image](https://bcdn.docswell.com/page/PEXQ6W56JX.jpg)

nameless-sdd
• まずはプロジェクト全体の既存コードを
読み解いて、PRODUCT_SPEC.mdを作らせた
41/76


# Page. 42

![Page Image](https://bcdn.docswell.com/page/3EK91V6GED.jpg)

nameless-sdd
• まずはプロジェクト全体の既存コードを
読み解いて、PRODUCT_SPEC.mdを作らせた
42/18


# Page. 43

![Page Image](https://bcdn.docswell.com/page/L73WQM6575.jpg)

Product Backlog Refinement
• PRODUCT_SPEC.mdをつかってリファインメントしたPBIが。
43/76


# Page. 44

![Page Image](https://bcdn.docswell.com/page/87DK96VYJG.jpg)

Product Backlog Refinement
• こちら。もちろんAzure DevOps MCP Server経由で更新してくれます。
44/76


# Page. 45

![Page Image](https://bcdn.docswell.com/page/VJPKZYV2E8.jpg)

• 過去の写真メタデータをスキャンしてカメラ・レンズ一覧を自動生成できる
■ 概要
■ 受入基準（Acceptance Criteria）
管理者がAdmin画面の機材一覧ページから「スキャンして更新」ボタンを押下し、
■ スキャン機能
Azure Blob Storageに保存された全写真のEXIFメタデータをスキャンして、
Admin画面に機材一覧ページ（/Gallery/EquipmentList）が存在する
使用されたカメラ・レンズの一覧を自動生成・表示できるようにする。
「スキャンして更新」ボタン押下でAzure Blob Storageの全写真メタデータがスキャンされる
スキャン結果からカメラ名・レンズ名が重複なく（OrdinalIgnoreCase）抽出される
■ 背景・目的
写真管理CMSに蓄積された写真（現在377枚）のEXIF情報には、
撮影に使用したカメラ・レンズの情報が含まれている。
これを自動集計することで、手動管理なしに正確な機材リストを生成し、
管理者が所有機材の全体像を把握できるようにする。
歴史的な「カメラ名 / レンズ名」形式のメタデータが正しくカメラとレンズに分離される
■ 一覧表示
カメラ一覧・レンズ一覧がそれぞれアルファベット順で表示される
最終スキャン日時とスキャン写真総数が表示される（例：「377枚の写真をスキャン」）
スキャン結果がequipment.jsonに永続化される
■ 機能詳細
Admin画面のナビゲーションから機材一覧ページ
データ未取得時（初回アクセス時）はスキャン案内が表示される
■ スコープ対象外
（/Gallery/EquipmentList）にアクセス
マウント別グループ化表示: #855で対応
「スキャンして更新」ボタンを押下
所持/非所持ステータス管理: #856で対応
Azure Blob Storage上の全写真Blobのメタデータを走査し、
Camera・Lens情報を収集
機材別写真一覧: #853で対応
■ 前提条件
重複排除（大文字小文字区別なし）してカメラ一覧・レンズ一覧を生成
Azure Blob Storageに写真がアップロード済みであること
結果をwwwroot/data/equipment.jsonに保存し、画面に一覧表示
写真メタデータにCamera/Lens情報が含まれていること
■ 関連情報
親Feature: #849（機材管理）
• これを全PBIにSubAgentで並列実行
関連: #855（マウント推定）、#853（機材詳細）
実装参照: EquipmentService.ScanAndUpdateAsync()、EquipmentList.cshtml
45/76


# Page. 46

![Page Image](https://bcdn.docswell.com/page/2EVVWGZXEQ.jpg)

やっと、
小さい価値の定義
= 仕様
= PBI
= 開発がReadyにできた！
46/76


# Page. 47

![Page Image](https://bcdn.docswell.com/page/57GLD84REL.jpg)

SDD documents
• 前提：Spec Kitやcc-sddを膨大なドキュメントが生成される。
例えばSpec Kitならこんなかんじ。
ドキュメント
生成コマンド
役割
constitution.md
/speckit.constitution
プロジェクト全体の原則・ルール（TDD必須、コーディング規約など）
spec.md
/speckit.specify
機能仕様書（ユーザーストーリー、要件、成功基準）
plan.md
/speckit.plan
実装計画（技術コンテキスト、プロジェクト構造、設計）
tasks.md
/speckit.tasks
タスクリスト（フェーズ別・ユーザーストーリー別に分解）
checklist.md
/speckit.checklist
カスタムチェックリスト（レビュー用など）
• 全てに目を通すのは正直重い。レビューしんどい。
• なので、過不足がないであろうと考えた
仕様駆動プロセスとSpecフォーマットを自作した。
47/76


# Page. 48

![Page Image](https://bcdn.docswell.com/page/4EQY19GYJP.jpg)

nameless-sdd
• 自作仕様駆動の流れ
• 目的
• 原則
• 実装フロー
• Specの承認
• Spec作成ルール
48/18
48/76


# Page. 49

![Page Image](https://bcdn.docswell.com/page/KJ4WRX5Z71.jpg)

nameless-sdd
• 単一機能を作るときの
specを作るための
テンプレート
• １機能１.mdしか作らない
• 個人的にこれぐらい
書かれてあれば十分だと
思えるものが記載されて
いればOK
49/18
49/76


# Page. 50

![Page Image](https://bcdn.docswell.com/page/LE1YQNWD7G.jpg)

nameless-sdd
• そのSpecテンプレートで
Specを作成してくれる
skillを作成。
50/18
50/76


# Page. 51

![Page Image](https://bcdn.docswell.com/page/GEWGM468J2.jpg)

nameless-sdd
• そのSpecテンプレートで
Specを作成してくれる
skillを作成。
51/18
51/76


# Page. 52

![Page Image](https://bcdn.docswell.com/page/47ZLQ2Y9J3.jpg)

PBIs to Specs
• skill化したので
Spec作成も
SubAgentで
並列実行
52/76


# Page. 53

![Page Image](https://bcdn.docswell.com/page/YJ6W6VDDJV.jpg)

New features Specs and Develop
53/76


# Page. 54

![Page Image](https://bcdn.docswell.com/page/GJ5M6D38J4.jpg)

New features - 機材管理
• カメラ・レンズのマウント別管理と
メタデータ正規化
• 過去の写真メタデータをスキャン
してカメラ・レンズ一覧を自動生成
できる
54/60


# Page. 55

![Page Image](https://bcdn.docswell.com/page/9E29M8ZV7R.jpg)

55/76


# Page. 56

![Page Image](https://bcdn.docswell.com/page/D7Y4X6RQEM.jpg)

56/76


# Page. 57

![Page Image](https://bcdn.docswell.com/page/VENY1ZD2J8.jpg)

機材管理
• Release2
• カメラ名・レンズ名
のブレを正しい名前
PBI
概要
管理者が機材一覧画面から、カメラ名・レンズ名の表記ブレ（例：大文字/小文字の違い、スペースの有無等）を正しい名前に一括変更できる
ようにする。変更は該当する全写真のBlobメタデータに反映される。
背景・目的
EXIFから自動抽出された機材名には表記ブレが存在する場合がある（例：「SIGMA 45mm F2.8 DG DN」と「45mm F2.8 DG DN |
Contemporary 019」）。これらを統一することで、機材一覧の正確性を高め、写真検索の精度を向上させる。
画面フロー
1.
機材一覧画面（#852）で変更対象の機材名を選択
2.
3.
「一括変更」ボタンを押下
新しい機材名を入力
4.
影響範囲が表示される（例：「51枚の写真に適用されます」）
5.
確認ダイアログ「○○枚の写真のメタデータを変更します。よろしいですか。」が表示される
6.
「OK」押下で一括変更が実行される
受入基準（Acceptance Criteria）
一括変更操作
に一括変更できる
•
•
•
•
[ ] 機材一覧画面から機材名の一括変更操作が可能
[ ] 変更前に影響を受ける写真の件数が表示される
[ ] 確認ダイアログが表示され、OKで実行・キャンセルで中止できる
[ ] 変更実行後、Azure Blob Storage上の該当写真すべてのCamera/Lensメタデータが更新される
データ整合性
• [ ] カメラ名の変更はCameraメタデータフィールドに適用される
• [ ] レンズ名の変更はLensメタデータフィールドに適用される
• [ ] 変更後、equipment.jsonが更新後の名前で再保存される
• [ ] 変更後、Cloud areキャッシュのパージが実行される
スコープ対象外
• マウント情報の変更: #857で対応
• 変更履歴の記録: このPBIの範囲外
前提条件
• #852（機材一覧の自動集計表示）が完了していること
• #855（機材詳細情報の表示）が完了していること（影響範囲の写真確認のため）
関連情報
fl
•
•
•
•
親Feature: #849（機材管理）
前提: #852、#855
関連: #858（機材情報の一括編集）
実装参照: GalleryController.BulkUpdateEquipment()
57/76


# Page. 58

![Page Image](https://bcdn.docswell.com/page/Y79P5ZGDE3.jpg)

機材管理
• Release2
• カメラ名・レンズ名
のブレを正しい名前
に一括変更できる
58/76


# Page. 59

![Page Image](https://bcdn.docswell.com/page/G78DY1V57D.jpg)

59/76


# Page. 60

![Page Image](https://bcdn.docswell.com/page/L7LM4Q53JR.jpg)

あとClaude実装よろしく！
60/76


# Page. 61

![Page Image](https://bcdn.docswell.com/page/4EMYK13MEW.jpg)

New features - 機材管理
• 過去の写真メタデータを集計
して、機材の所持状況を管理
したい。
• 機材名を選択して、その機材
名が使われている写真を一覧
で表示したい。
• 機材名の入力が手入力だった
せいでブレがあるので統一し
て修正したい。
61/76


# Page. 62

![Page Image](https://bcdn.docswell.com/page/PER9XLQLJ9.jpg)

New features - Bulk Upload
• 複数枚の写真をとりあえず一括
アップロードできるようにした。
• アップロードした写真はデフォルト
非表示。
• カメラ情報などメタデータを入力
して表示状態に切り替えることで
初めて公開するようにした。
（非公開・編集機能は既存機能）
62/60


# Page. 63

![Page Image](https://bcdn.docswell.com/page/P7XQ6WR6EX.jpg)

New features - 組写真
単一の写真では表現できない、
•
ひとつのテーマやストーリー、時間軸や
視点などを複数枚の写真で表現する手法
以下２機能で構成される
•
•
Adminで組写真としてアップロードしたい
•
公開ページで組写真として表示したい
63/60
63/76


# Page. 64

![Page Image](https://bcdn.docswell.com/page/37K91VRG7D.jpg)

New features - 組写真
単一の写真では表現できない、
•
ひとつのテーマやストーリー、時間軸や
視点などを複数枚の写真で表現する手法
以下２機能で構成される
•
•
Adminで組写真としてアップロードしたい
•
公開ページで組写真として表示したい
64/60
64/76


# Page. 65

![Page Image](https://bcdn.docswell.com/page/LJ3WQM85J5.jpg)

組写真
65/60


# Page. 66

![Page Image](https://bcdn.docswell.com/page/8JDK96MYEG.jpg)

これで８割完璧
66/76


# Page. 67

![Page Image](https://bcdn.docswell.com/page/VEPKZYR278.jpg)

９割 = 8割 + Vibeで修正
67/76


# Page. 68

![Page Image](https://bcdn.docswell.com/page/27VVWGRX7Q.jpg)

のこり１割の失敗
• 仕様の複雑さを紐解けず、シンプルに要件定義できなかった。
• 要件に対して技術選定が適していなかった。
• 難しい問題に仕様駆動開発でアプローチするのであれば、
素直にSpec Kitなりcc-sddに頼るのがよい。
• というか共存してて、nameless-sddはSpec Kitベースで実装してる。
68/76


# Page. 69

![Page Image](https://bcdn.docswell.com/page/5JGLD8MR7L.jpg)

のこり１割の失敗
• 前提を縦積み横並びのレイアウトで、全体比率を横3:縦1とした時、
• クロッピングの枠が横長になってほしい。
• が、追従しない…
69/60


# Page. 70

![Page Image](https://bcdn.docswell.com/page/47QY19RYEP.jpg)

のこり１割の失敗
• 静的なHTMLテンプレートで実装されているasp.net core mvcで
インタラクティブな要件を実装するのは不向き。
• おそらく裏で
すごいVanillaJSが
書かれてそう….
• Previewみながら
レイアウト決めてるけど
使いにくい。
• でも最低限は動いてる。
70/60


# Page. 71

![Page Image](https://bcdn.docswell.com/page/KE4WRX8ZJ1.jpg)

まとめ


# Page. 72

![Page Image](https://bcdn.docswell.com/page/L71YQN2DJG.jpg)

Conclusion
• ユーザーの振る舞いと価値提供の単位で仕様駆動しよう。
• 仕様こそVibe Speci cationしよう！
（というと荒っぽいので、AIと対話的に仕様作りしよう） -&gt; SDD
• システムとしての振る舞いから仕様を考え出すと、ウォーターフォールのように膨大
な要件を考えることになる。
• ユーザーストーリーマッピングからPBIへ。PBIからSpecへ。Specから実装へ。
このプロセスがおすすめ（特に既存プロダクトの場合、基本設計がもうあるので）
fi
72/76


# Page. 73

![Page Image](https://bcdn.docswell.com/page/G7WGM4R8E2.jpg)

Vibe or SDD GRADATION
• その機能要件の実装に、Spec Kit、cc-sdd、本当に必要ですか？つらくないですか？
Vibe
Coding
Plan
mode
nameless
sdd
AIの考えた
実装方法を人向けに
すべてを
AIの実装方針を
ノリと雰囲気で
AIに聞いて
AIに完全に任せる
AIに任せる
レポートさせて
必要があれば
AIと対話的に変更、
実装はAIに任せる
雑、手軽、
AI任せ、
とりあえず速い
レビューが
軽微
手戻りがあったとき
に振り返りにくい
大体これでいい
たまに困ったら
コードみる程度
Spec Kit
cc-sdd
AIの考えた
実装方法をAI向けにレポート
させて
必要があれば
AIと対話的に変更、
AIを見守りつつ
適宜軌道修正
丁寧、
ステップ多い、
レビュー大変、初速
めっちゃ遅い
73/76


# Page. 74

![Page Image](https://bcdn.docswell.com/page/4JZLQ2R9E3.jpg)

Conclusion
• 仕様駆動開発もソフトウェアアーキテクチャと一緒で程度問題がある。
• 全てをフルスペックの仕様駆動開発のプロセスを通さなくてもよい。
• でないと、軽微な実装にも時間がかかりすぎる
• とはいえドキュメントは残したい。
• そのために、プロダクトの寿命や重要度、エンジニアの技術の理解度に合わせて、
プロダクトに合った仕様駆動開発設計しよう。
74/76


# Page. 75

![Page Image](https://bcdn.docswell.com/page/YE6W6VRDEV.jpg)

Conclusion
• 趣味プロダクトでは、キミだけの仕様駆動開発設計をしよう！
• どこまで丁寧に詳細にやれば自分のイメージとAI出力が合致するか、
どこまで手抜きしても、思っているモノが出力されるか
（それが機能なのか設計かコードなのかとしても）
日々試していくことがAI駆動開発時代の学習方法としておすすめです。
75/76


# Page. 76

![Page Image](https://bcdn.docswell.com/page/GE5M6D88E4.jpg)

Experiment and Adapt
the Spec-Driven Development Process
with nameless
- 仕様駆動開発のプロセス試行と既存プロダクト開発への適応 -
@mitsuba_yu


# Page. 77

![Page Image](https://bcdn.docswell.com/page/9729M8KVJR.jpg)

Profile
•
Yuki Izumoto a.k.a 蜜葉
•
@mitsuba_yu || yu-izumoto@kddi-agdc.com
•
Microsoft MVP for Developer Technologies (15th)
•
Designer / Developer / Photographer
•
https://c-mitsuba.hatenablog.com
•
Scrum Master at KAG
•
内製化支援として、チーム育成なども担当してます。
•
今日の話をきいて、
「うちのチームでもできるようになりたい」と思ったなら、ぜひご連絡ください！


