こんにちは。アイレット デザイン事業部でディレクターをしている ivanov です。

AI時代のデザイナーにも必要な「仕様駆動開発」という視点

AIを活用した開発において、デザイナーであっても「AIを操作するスキル」に加え、「要求定義」「要件定義」「仕様作成」のスキルが不可欠だと感じています。 これからの時代の開発手法として「仕様駆動開発（SDD）」が注目されていると聞き、『仕様駆動開発2.0』を読んでみました。以下、その学びと考察です。

仕様駆動開発（SDD）とは？

仕様駆動開発は、アジャイル開発に適合したソフトウェア分析とテストの協調的アプローチです。 主にテストで利用される「Given When Then」というGherkin記法を用いて具体例を記述します。ビジネス担当者、開発者、テスターといった多様な役割のメンバーが、現実世界の利用事例を共通言語として用いることで、暗黙の了解を排し、「何を構築し、どうテストすべきか」の認識を合わせることを目的としています。

従来の、文脈が欠如したままAIにコードを書かせる「Vibe Coding（バイブコーディング）」は、手戻りや過剰な設計を引き起こしがちです。仕様駆動開発は、明確で構造化された要件を通じてこれらの課題を解決します。

本書からの学び

本書では事例を交えて、主に以下の重要性が説かれています。

① 構造化された仕様の作成

仕様は開発における「ガードレール」の役割を果たします。仕様が曖昧だと、ドキュメントと実際のコードとの間に齟齬が生じ、後の混乱の原因となります。そのため、目的・入力・出力・制約条件を明確に記述する必要があります。

② 小さく作る（段階的イテレーション）

システムを小さく作ることで作業効率が向上します。また、仕様変更の際にも、テストコードの自動生成やモデルの修正を効率的に行うことができます。

③ 「仕様作成 ⇒ コード化」の正しい循環

仕様は修正されるものであり、コードも進化し続けるものです。 最初から大きく作ってしまうと、変更時の影響範囲が見えにくくなるだけでなく、仕様と実装コードの間で乖離（かいり）が起きやすくなります。 Vibe Codingの時代だからこそ、開発者全員が参照できるMarkdownなどの「AIも理解しやすい記法」で仕様を明文化し、チーム内での認識齟齬を防ぐことが重要です。

④ 要件を分解し、優先度を設定する

私が普段参加するプロジェクトでは、お客様と合意の上で「要求定義」を行うことがあります。これは「作りたいシステム」を言語化し、必要な機能とその優先順位を決め開発方針に活かす作業です。 本書でも同様に、要件を小さな単位に分解することの重要性が記されています。各機能ごとに「入力・出力・制約条件」を明確にすることで、開発の道筋が見えやすくなり、前述の「小さく作る」ことにも繋がります。 また、要件の分解はテストの容易性も高めます。「コア機能」から優先的にテスト設計を行い、段階的に拡張していくことが可能になるからです。要求定義において優先度は「ビジネスベネフィット」「技術的容易性」「組織受入態勢」で決定しますが、仕様駆動開発では、「コア機能」の開発を最優先とし、「ビジネス価値の最大化」「ユーザーへの影響」「開発コスト」を総合的に評価しながら優先度を判断します。

⑤ 仕様レビューとチェックポイントの設計

仕様レビューでは、開発者が理解可能な記述かを確認し、チーム内で共通理解を確立させます。 また、機能ごとに「入力・出力・制約条件・例外処理」が満たされているかを確認する「チェックポイント」を設計します。これは「どんな条件・入力で、どんな値を返すか」を定義することと同義であり、そのままテストに利用可能です。 このチェックポイントに基づきテストコードを作成するため、粒度が細かすぎるとレビューやテストの負荷が増大します。機能単位や操作単位で設計し、必要に応じて補助的なポイントを設けるバランスが重要です。 これらはAIによる自動化と相性が良く、Spec Kitやcc-sddなどのツールを活用してテストコードやチェックポイントを自動生成することで、人的ミスを削減できます。

⑥ ドメイン駆動設計（DDD）との融合

仕様駆動開発においても、ドメイン駆動開発と同様にシステムの中心にドメインモデルを据え、開発者とドメインエキスパート間で共通認識を形成することが可能です。 従来のドメイン駆動開発はモデル設計に時間を要し、素早いリリースが難しい側面がありましたが、仕様駆動開発と融合させることで、ドメイン駆動開発の思想を維持しつつ、柔軟かつ安全に小さな単位でのリリースが可能になります。

感想

本書を通じて、実践的な開発の流れを学ぶことができました。 「小さく作っていくこと」の本質とは、単なるスピードアップではなく、「開発者とチームが安心して、効率的に、そしてクリエイティブに価値を生み出す環境を作ること」だと理解できました。また、AI時代の開発はAIの特性に合わせた新しいコミュニケーションの形を作ることが大事なのだなと考えるようになりました。お客様とご相談の上で「要求定義」を行うことで、お客様の「なんか違う、これじゃない」を極力小さくするよう努めていますが、仕様駆動開発と組み合わせることで、さらにお客様が思った通りの形に近づけるのではないかと思いました。（※お客様のご予算や希望納期などのご都合に合わせて「要求定義」を行わない場合もございます）

今後は、優先度決定のための「インパクトマッピング」や、テスト設計の核となる「Gherkin記法」についても深く学んでいきたいと思います。