開発プロセスの教材としてのSpec Kit

はじめに

　Spec KitはGithubが開発している生成AIを使った仕様駆動開発のためのツールです。

　仕様駆動開発やSpec Kitに関してはGithubのブログで解説されているので適宜見てみてください。

　Spec Kitを使っていく中で、これって結局人が開発する上でも同じプロセスを辿って開発してるから初学者向けの教材としても使えるんじゃ…？と思ったので、教材という視点に立ってSpec Kitで出力されるドキュメントを見ていきたいと思います。

Spec Kitで開発するときの流れ

　Spec Kitで開発を進める時も、人間による開発の時と同じようにプロジェクト立ち上げ時に開発ルールを決め（/constitution）、要件定義を行い（/specify）、どういう風に実装するか計画し（/plan）、実装するまでをタスクに分解し（/task）、実装を行う（/implements）という大まかな流れは変わっていません。以降はこの流れに従って出力されるドキュメントを見ていき、開発を行う上で考慮すべき点について挙げていこうと思います。

※コマンドは説明のため一部省略しています。実際は/speckit.constitutionのようにspeckitという接頭辞がついています。

Spec Kitで生成されるドキュメント

　Spec Kitでは各コマンドを実行すると様々なドキュメントがテンプレートを元に生成されます。フェーズ毎に出力されるドキュメントの中身は以下のような感じになっています。

/constitution

　プロジェクトの全般的な開発ルール（.specify/memory/constitution.md）が作成されます。/specify.constitutionを実行するときのプロンプトに日本語で生成するようにお願いしないと英語で出力されてしまうので、日本語がいい人はプロンプトの最後に下記の文言を追加するとうまく日本語になるかもしれません。（spec-kitの成果物を確実に日本語で作成する を参考にさせていただきました）

出力するドキュメントは適切にエンコーディングされた文字化けのない日本語で出力するようにしてください。もし文字化けがあったら修正してください。

　出力された開発ルールは下記のような構成になっています。

• コア原則
  • I. コード品質の統一 (NON-NEGOTIABLE)
  • II. 高品質テスト基準 (NON-NEGOTIABLE)
  • III. ユーザー体験の一貫性
  • IV. パフォーマンス要件
• 品質基準
• 開発ワークフロー
• ガバナンス

各項目の内容は大体下記のような形になっています。

• コア原則、品質基準
  • コードをどういうルールに従って品質を担保するのかを記載
    • 例：カバレッジ率80％以上、何ミリ秒以内にレスポンスを返す
  • 対象となる動作環境
    • Webブラウザ、モバイル等
• 開発ワークフロー、ガバナンス
  • コードを構成管理する際のルール
    • 例：マージをするときにはn人の承認が必要
  • リリースするときのプロセス
    • 例：どういう修正を入れた時にメジャー/マイナー/パッチバージョンを上げるか

どの項目も開発プロジェクトを立ち上げる際に開発プロセスを回していくために考えておかないといけない事項（実際に自分もよく頭を悩ませてます…）がまとめられています。

/specify

入力されたプロンプトを元に、具体的にどのような機能をどういう仕様で開発するかということをまとめたドキュメント（specs/XXX-<機能名>/spec.md）が生成されます。

　構成は以下の通り。

• ユーザーストーリー
• 要件
• 成功指標
• 仮定 / 前提
• スコープ外

　入力されたプロンプトからユーザーストーリーを作成し、それを実現するための機能要件がまとめられています。ユーザーストーリーは複数に分解されていて、優先度を定義することで機能の実装順を決めています。また機能の品質担保のために、応答性能やアクセシビリティのような非機能要件に関しても記載（成功指標）されています。実装する機能の要件をさらに明確化するために必要な仮定や前提であったり、スコープ外として今回の機能としては扱わない要件についても記載されます。余談ですが、ユーザーストーリーだったりスコープを意識した作り方はかなりアジャイル開発のやり方を考慮した構成になっていますね。

/plan

　どのような言語、フレームワーク等を使用して実装・テストをするかをまとめたドキュメント（specs/XXX-<機能名>/spec.md）が主に生成されます。技術選定のための調査（research.md）や設計を行うために必要なデータモデル（data-model.md）等も必要に応じて生成されます。開発で必須となるのはspec.mdの範囲になるので、spec.mdに関して見てみます。

• サマリー
• 技術コンテキスト
• 憲章チェック
• プロジェクト構成
• 複雑性トレース
• 調査計画
• 設計
• 実装準備
• リスク&対応
• ゲート評価

　/planコマンドで入力した言語やフレームワークに関して調査を行い、プロジェクトの構成や実装方法等を計画します。ほかにも実装時のリスク分析や対策の検討、コード品質を確認するルール等も決められています。

/tasks

　機能を実装する上で必要な作業をタスクに分解してまとめたドキュメント（specs/XXX-<機能名>/tasks.md）が生成されます。

tasks.mdで作成されるタスク一覧はプロジェクトのセットアップやユーザーストーリーを複数のタスクに分解して作成されていて、Spec Kit内でタスクが完了しているかどうかを管理するために使用されています。

## フェーズ1: セットアップ (共有インフラ)
**目的**: プロジェクト初期化と品質ゲート基盤
 - [X] T001 Create Nuxt 3 scaffold (if not existing) in project root
 - [X] T002 Add Tailwind CSS config in `tailwind.config.js`
 - [X] T003 [P] Add PostCSS & Tailwind directives in `src/assets/tailwind.css`
...

　また、tasks.md内では並行して着手できるタスクや、タスクの優先度を設定することでユーザーに対して価値が高い機能を効率よく提供できるにするような工夫がされています。

最後に

　生成されたドキュメントに関して一通り見ていきましたが、どのコマンドで生成されるドキュメントも人間が開発するときもしっかり検討しておかないと後々困るようなことばかり（CI/CDだったりテスト戦略だったり抜けているものもまだありますが）なので、開発を始める時の参考にしてみるのもありなんじゃないかと思います。

We Are Hiring!