🐈

仕様駆動開発を始める前に技術調査をしよう

に公開
zennfes2025ai
idea

はじめに

仕様駆動開発って、いきなり仕様書を書き始めればいいと思ってた。でも実際やってみたら、後から「この技術使いたかったのに...」って後悔することになって、めちゃくちゃ手戻りが発生した。

今回は、技術調査を先にやってからSpecKitで仕様作成したら、めちゃくちゃスムーズに進んだ話をシェアする。

失敗例: 仕様作成から始めた場合

最初は王道っぽく、こんな流れでやってた:

  1. 要件を整理
  2. /speckit.specifyで仕様作成
  3. 実装開始
  4. 「あれ、Clean Architecture使いたいんだけど...」
  5. 仕様書を全部書き直し 😱

何が問題だったかというと、技術選定が後回しになってたこと。

仕様作成の時点では「どんなアーキテクチャにするか」なんて考えてなかったから、instructionには具体的な技術スタックが何も書かれてない。で、実装フェーズになってから「Clean Architectureでいこう」って決めたら、もう手遅れ。

作成済みの仕様書には依存性注入もレイヤー分離も何も考慮されてないから、実装タスクが仕様とズレまくる。結局、仕様書の全面的な見直しが必要になって、工数が2倍くらいになった。

解決策: 技術調査を先にやる

じゃあどうすればいいのか。答えはシンプルで、技術調査を先にやって、調査結果をリポジトリに入れること。

実践した流れ

今回、Golangでプロジェクトを作るにあたって、こんな順番で進めた:

  1. 技術調査: Clean Architectureについて調べる
  2. 調査結果を格納: document/research/clean-architecture.mdに調査内容をまとめる
  3. instruction作成: /speckit.constitutionを実行
  4. 仕様作成: /speckit.specify, /speckit.plan, /speckit.tasksを実行
  5. 実装: /speckit.implementを実行

この順番にしたら、何が起きたか。

調査結果の内容

document/research/clean-architecture.mdには、こんな内容をまとめた。

  • Clean Architectureの4つのレイヤー構造
  • Golangでのディレクトリ構成
  • Interface設計とDependency Injection
  • Mock自動生成ツール(mockery)の使い方
  • TDD実装の流れ
  • ベストプラクティス

具体的なコード例も含めて、「これから作るプロジェクトで使う技術」を事前に調べて、ドキュメント化しておいた。

SpecKitの威力

そして/speckit.constitutionを実行したら、すごいことが起きた。

instructionに、Clean Architectureの使用が明記された。

しかも、自動生成された実装タスクが全部、Clean Architectureを前提としたものになってる:

  • internal/domain/entity/にエンティティを作る
  • internal/domain/usecase/にインターフェースを定義
  • internal/usecase/に実装を書く
  • mockeryでモックを生成してTDDで進める

つまり、リポジトリに調査結果を入れておくだけで、SpecKitがそれを読み取って、技術スタックを考慮した仕様を作ってくれた。

なぜこれが上手くいったのか

SpecKitの/speckit.constitutionは、リポジトリ内のドキュメントを読み込んで、プロジェクトのコンテキストを理解してからinstructionを作成する。

だから、document/research/に技術調査の結果を入れておけば、「このプロジェクトはClean Architectureを使う」という前提が自動的にinstructionに反映される。

逆に言うと、調査結果をリポジトリに入れてないと、SpecKitは「どんな技術を使うのか」を推測できない。結果として、汎用的すぎる仕様書ができて、後から調整が必要になる。

個人開発でも使えるTips

この方法、個人開発でもめちゃくちゃ有効だと思う。

  • 学習を兼ねられる: 技術調査の過程で、新しい技術を深く学べる
  • 後から見返せる: 調査結果をドキュメント化しておけば、実装中に「あれどうだったっけ?」って時に便利
  • 仕様の質が上がる: 技術的な制約を理解した上で仕様を作るから、実装とのギャップが少ない
  • 手戻りが減る: 最初に技術選定を固めておけば、後から「やっぱこっちの技術にしよう」って迷わない

もちろん、調査に時間をかけすぎるのもよくないけど、1-2日くらいかけて主要な技術をリサーチしておくと、その後の開発がめちゃくちゃスムーズになる。

まとめ

仕様駆動開発を始める前に、技術調査をやっておこう。

調査結果をリポジトリに入れておけば、SpecKitが自動的にそれを反映した仕様を作ってくれる。結果として、実装の一貫性が保たれて、手戻りが激減する。

「仕様書を書く前に技術を決める」、これだけで開発体験がかなり変わるから、ぜひ試してみてほしい。

Discussion