📑

仕様駆動開発をチームに導入したい話

に公開
仕様駆動開発
Spec Kit
decisionrecord
idea

Spec Kitを導入してみたけれど

Spec Kitを仕事のプロジェクトに導入してみましたが、チーム内での広まりは限定的でした。
導入のきっかけは、AIエージェント開発におけるプロンプト設計の属人化を解消し、品質向上を目指すためでした。
しかし、チームメンバーの多くが従来の個人タスク中心の作業に慣れていたため、新しい手法の価値を実感しづらかったのかもしれません。また、仕様駆動開発の効果は即座には見えにくく、そのため導入に対して抵抗感や戸惑いがあった可能性もあります。
この記事では、仕様駆動開発って良さそうだなと思った人がチームに導入提案できるようにDecision Recordの例を紹介します。それを通して仕様駆動開発が何を解決するのか示したいと思います。

Decision Record: 仕様駆動開発 (SDD) 導入提案

Decision Record: 仕様駆動開発 (SDD) 導入提案

Status

提案中

Context

Claude CodeやCodexといったAIエージェントを開発に取り入れているが、プロンプトエンジニアリングが属人的になっている。
人によってはAIの出力が期待通りにならず、レビュー負担が大きいという課題がある。

Decision

仕様駆動開発 (SDD) を導入する。
ツールとしてSpec Kitを採用する。

Consequences

メリット

  • 仕様を共有することで、人間にもAIにも分かりやすく、隠れた前提や曖昧さをなくせる
  • 仕様が『生きたドキュメント』として機能し、メンバーが変わっても知識や合意が失われにくくなる
  • セキュリティや設計ルール、法規制の要件を仕様に組み込めるため、エンタープライズや厳しい環境でも活用できる
  • 仕様をsingle source of truthとして扱い、ツールやAIエージェントが生成・検証・テストに利用できる
  • プロンプトやコード生成のプロセスに一貫性をもたらし、属人性を減らす
  • 曖昧なAI任せの開発から脱却し、仕様を起点に再現性のある開発を進められる

リスク・懸念

  • 仕様を生成するために要件を定義するコストが初期段階で発生し、初動が遅くなる可能性がある
  • 個人視点では「余計な作業」と感じられ、抵抗感が出る恐れがある
  • 価値を実感できるまでに時間がかかり、継続的な取り組みが必要となる
  • Spec Kitを採用するリスク
    • 学習コストがかかり、新しいツールに慣れるまで時間を要する
    • ツール自体が未成熟であり、頻繁なアップデートに追随する必要がある

References

まとめ

私のチームの場合では、仕様駆動開発の広まりが限定的だったという事実を振り返る必要があります。
その主な原因は、ツールから入り価値を十分に共有しきれなかったことにあります。ここで例に挙げたようなDecision Recordを使って、まず「なぜやるのか」を合意するところから始めれば良かったのかもしれません。

仕様駆動開発は単なるツールではなく、価値を言葉にしてチーム全員で合意する営みです。浸透には手間と時間がかかりますが、まずは小さく試し、仕様の粒度を調整しながら、チーム全体で目的を共有することが重要です。

あなたのチームなら、どんなDecision Recordを書きますか？

Discussion