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

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

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

趣味、写真。

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

• https://name-less.space
• https://www.slideshare.net/slideshow/nameless-deepdive/238647594

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

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

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

What is Spec-Driven Development 13/76

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

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

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

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

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

• https://service.shiftinc.jp/column/4850/

Development Environment for nameless 19/76

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

New features 21/76

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

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

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

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

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

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

組写真 28/60

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

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

New features UserStory Mapping with Claude Desktop 31/76

32/18

Vive Coding Prompt?

大きな価値提供

小さな価値提供

1機能

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

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

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

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

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

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

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

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

• 過去の写真メタデータをスキャンしてカメラ・レンズ一覧を自動生成できる ■ 概要 ■ 受入基準（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

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

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

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

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

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

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

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

New features Specs and Develop 53/76

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

55/76

56/76

機材管理 • 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

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

59/76

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

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

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

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

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

組写真 65/60

これで８割完璧 66/76

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

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

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

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

まとめ

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

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

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

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

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

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

• http://c-mitsuba.hatenablog.com