前回、cc-sddとGeminiを使って仕様駆動開発（SDD）を試してみました。
cc-sddを使っていて、Codex CLIで使いたいと思っていたのですが、GitHubにコマンドファイルはあるものの、Codex用のインストールがなく使うことができませんでした。
なんとか使えないか試行錯誤していたところ、Spec Driven Codexの存在を知りました。
cc-sddのときも思いましたが、世の中凄い人がいるものです。その卓越した技術力、尊敬します。
今回はSpec Driven Codexを使って仕様駆動開発を行ってみたいと思います。
Spec Driven Codex とは
Spec Driven Codexはcc-sddと同様の仕様駆動開発ツールです。
cc-sddで対応していない、Codex専用のツールになります。
cc-sddにない機能もあり、洗練された非常に使いやすいツールとなっています。
要件、設計、実装の流れを一貫性をもって、Codex CLIから実行することができます。
Spec Driven Codex の使い方
導入方法
導入方法は簡単で、プロジェクトのルートディレクトリで下記のコマンドを実行するだけです。
npx spec-driven-codex init --locale jaプロジェクトに「.sdd」が作成される他に、Codexにカスタムコマンドが作成されました。
全体の流れ
GitHubのREADMEや作者さんのページがしっかりしているので、正直そちらを参照した方がよいと思います。
全体の流れは下記のようになっており、仕様駆動開発の流れを汲み簡潔な手順となっています。
- 舵取り
/sdd-steeringの実行description.mdの編集
- 要件定義
/sdd-requirementsの実行requirements.mdの編集
- 設計
/sdd-designの実行design.mdの編集
- タスク分解
/sdd-tasksの実行tasks.mdの編集
- 実装
/sdd-implementの実行
- アーカイブ
/sdd-archiveの実行
コマンドでファイルを作成 → 編集 → 次のフェーズへ受け渡し、という流れで段階的に進めていきます。
青字のコマンドはCodex CLIで実行し、ファイルの編集はVSCodeなどのエディタで行うようになります。
それでは早速、プロジェクトフォルダのルートでCodex CLIを起動しましょう。
codexCodexの承認確認をどうするか聞かれますが、今回は「１」の承認を求めずに作業できるようにします。
Since this folder is not version controlled, we recommend requiring
approval of all edits and commands.
> 1. Allow Codex to work in this folder without asking for approval
2. Require approval of edits and commands
Press Enter to continueSpec Driven Codex で仕様駆動開発
舵取り
最初にプロジェクトの全体像を作るため、下記のコマンドを実行します。
/sdd-steering続いて、今回のプロジェクトで実装したい機能を .sdd/description.md に書いていきます。
必要最低限のシステムを作ってみたいので、こんな感じで書いてみました。
# 実装したい機能
## 概要
商品と在庫数の管理を行う、在庫管理システムを構築します。
## 詳細
必要最低限の機能を実装します。
商品管理はコードと名称、単位を管理します。
在庫のロケーション管理は不要です。
商品のメンテナンス機能が必要です。
在庫の入出庫の機能が必要です。
在庫状況を照会できる機能が必要です。要件定義
次に要件定義書を作るため、下記のコマンドを実行します。
/sdd-requirements実装したい機能の内容をもとに要件が明確化され、 requirements.md が作成されました。
機能概要、ユーザーストーリー、機能要件、非機能要件に細分化されていますね。
特に修正する部分はなかったので、このまま次に進みます。
設計
要件が決まったので、次はこれを機能設計に落として行きます。
要件を基に機能を細分化し、実装するための技術的な内容に変換します。
/sdd-design処理が終わると design.md が作成されるので、内容を確認します。
気になる部分があれば修正を行います。
これは実装まで進んでから気づいたことですが、「アーキテクチャ概要」に使用する技術内容を細かく指定しておけばよかったです。
フロントエンドやバックエンドを何で実装するのか、データベースをどうするのか等が曖昧なまま進めてしまいました。
実装が終わってからでも仕様変更として再び要件定義から行えば、このあたりは解消することが可能です。
タスク分解
続いて設計内容をもとに実装計画を作成します。
/sdd-taskstasks.md が作成されました。
データモデル実装、ビジネスロジック実装、インターフェース実装、テストに分類され、作業してくれるタスクへ細分化されています。
実装
それではいよいよ実装に移ります。
タスク分割で細分化したタスクを順に実行し、プログラムを作成してもらいます。
/sdd-implementtasks.md には終わったものに「ｘ」マークがついていくので、作業状況がわかりやすいですね。
５分程度で実装が終わりました。
今回の実装で作成されたソースファイルです。
と、ここで気づいたのですがUI画面が無いですね・・・
追加実装してもらいますが、その前にアーカイブしておきます。
アーカイブ
アーカイブは作成した requirements.md、design.md、tasks.md をバックアップする機能です。
/sdd-archive.sdd/specs/archives に日付付きで保存されます。
このアーカイブ機能が個人的に素晴らしいです。
仕様部分の履歴や変遷を確認でき、作業の振り返りが容易ですね。
機能追加
アーカイブしたので、UI画面を機能追加していきます。
先ずは description.md に画面を追加してもらうよう、詳細に一行追加しました。
# 実装したい機能
## 概要
商品と在庫数の管理を行う、在庫管理システムを構築します。
## 詳細
必要最低限の機能を実装します。
商品管理はコードと名称、単位を管理します。
在庫のロケーション管理は不要です。
商品のメンテナンス機能が必要です。
在庫の入出庫の機能が必要です。
在庫状況を照会できる機能が必要です。
各機能には操作するための画面が必要です。 ←追加あとは要件定義、設計、タスク分解、実装とコマンドを流していきます。
/sdd-requirements
/sdd-design
/sdd-tasks
/sdd-implement設計、タスク分解、実装を一気に実行してくれる、「/sdd-highway」コマンドも用意されているようです。
実行結果
フロントエンドとバックエンドを実行して、動作確認してみます。
node src/server/app.js #バックエンド起動
npm run dev #フロントエンド起動
デザイン指示してないので簡素な画面ですが、動作に問題ないようです。
まとめ
Spec Driven Codexを使用してみました。
洗練されたツールで、非常に使いやすいですね。要件と仕様検討に注力できます。
今回はMVPでの新規機能を試してみましたが、既存機能への機能追加、 マイグレーションなど様々な場面への適用が期待できます。
仕様駆動開発をCodexで行うにはこれ一択です。
コメント