従来の開発ツールはどこを支援していたか LLMが変えたもの なぜ「SDD」になるのか SDDツールが担う役割 実際の開発で起きている変化 リスクと注意点 今後どうなるか ここ1〜2年で、SDD（仕様駆動開発）関連ツールが急に増えました。 Agent系ツール、仕様管理…

仕様がドキュメントであると何が起きるか Spec as Codeの本質 ― 同期の強制 なぜ文章のままでは難しいのか よくある誤解 実際に起きる変化 リスクと注意点 どう考えるべきか Specification as Code（Spec as Code）という言葉は、最近SDD（仕様駆動開発）の…

SDDツールを分類する3つの層 実行層 ― AgentOS系ツール 管理層 ― Speckit系ツール 基盤層 ― Backstage系ツール なぜ混乱が起きるのか よくある失敗パターン リスクと注意点 どう考えるべきか SDD（仕様駆動開発）の話題になると、最近は必ず「ツール」の名前…

なぜ組織構造が重要なのか SDDが機能するチームの基本構造 よくある失敗パターン ― 仕様責任者が存在しない 役割分担の具体例 仕様責任者（Specification Owner） 実装責任者（Implementation Owner） 検証責任者（Validation Owner） SDDがうまく回るコミュ…

形式化とは何を指しているのか なぜ開発が遅くなるのか ― 決定待ちが増える もう一つの遅延要因 ― 承認プロセス 仕様の完全性と探索のトレードオフ 現場で起きる具体的な問題 リスクと注意点 どうすれば速度を落とさないか SDD（仕様駆動開発）を導入したの…

SDDは1つではない ― 3つの「仕様」の正体 設計崩壊パターン1：振る舞い仕様と業務仕様の衝突 設計崩壊パターン2：業務仕様と構造仕様の衝突 設計崩壊パターン3：振る舞い仕様と構造仕様の衝突 なぜ混在が起きるのか 危険な兆候 注意点とリスク ではどう整理…

SDDで起きる最も危険な状態 ― 「仕様が読まれない」 アンチパターン1：仕様が設計ではなく説明書になる アンチパターン2：仕様が更新されない（凍結仕様） アンチパターン3：テストが仕様の代替になる アンチパターン4：仕様が巨大化する（過剰仕様） アンチ…

エラー処理は実装ではなく「仕様」の中心に置く なぜエラー仕様が必要なのか よくある誤解 エラーの分類 1. 業務エラー（Business Error）** 2. システムエラー（System Error）** 仕様として書くべき内容 例：支払い処理 テストとしてのエラー仕様 API設計…

ログは運用のためではなく「仕様を固定するため」に書く なぜログが仕様になるのか よくあるログの問題 SDDにおけるログ設計 テストとの関係 実務での書き方 注意点 ― ログをデバッグ用途にしない 運用上のメリット まとめ ― ログは最後に書くものではない …

Storybookは「UIカタログ」ではなく「実行可能な仕様」にできる なぜStorybookがSDDと相性が良いのか 間違った使い方 正しい書き方 ― 状態をストーリーにする テストとの連携 APIとの接続 実務での運用手順 注意点 ― Storybookの落とし穴 まとめ ― Storybook…

フロントエンド主導開発は可能。ただし条件を満たさないと破綻する フロントエンド主導開発とは何を指すのか 成立しないケース 成立する条件 1. クライアントの状態モデルが存在する** 2. API契約が先に定義される** 3. ビジネスルールの責務分離** SDDとの…

ワイヤーフレームは仕様ではないが、仕様を壊す力を持っている なぜワイヤーフレームは仕様に見えるのか ワイヤーフレームが表現できないもの 例：承認フロー ワイヤーフレームを仕様にすると何が起きるか SDDにおける正しい位置づけ 実務での扱い方 よくあ…

プロトタイプは仕様を決める道具ではなく「仕様の誤解を減らす道具」 プロトタイプが優れている点 プロトタイプが仕様にならない理由 例：注文処理プロトタイプ よく起きる失敗 SDDでの正しい扱い方 実務的な変換方法 注意点 ― プロトタイプの危険な副作用 …

画面仕様書は「丁寧に書くほど危険」になりやすい なぜ画面仕様書は仕様に見えるのか 画面仕様書が失敗する構造 例：プロフィール編集 もう一つの問題 ― 実装順序を縛る 画面仕様書とSDDの衝突点 よくある誤解 では画面仕様書は不要なのか 実務での改善方法 …

UI駆動型SDDは「最も分かりやすいが、最も壊れやすい仕様」になりやすい UI駆動型SDDとは何か なぜUIは仕様として扱いやすいのか UI駆動型SDDの最大の問題 ― 仕様の「因果」が逆転する 具体例：会員登録画面 UI駆動型SDDが壊れる技術的理由 UI駆動型SDDの典…

SDD(仕様駆動開発)ではなぜモックが重要になるのか なぜ実システム依存だと仕様が書けないのか モックが担う役割 モックを使うと設計が変わる モックを誤用すると起きる問題 モックが必要な境界とは モックが増えすぎる危険 モックがないと起きる現場の問題 …

SDD(仕様駆動開発)ではなぜテストコードが仕様書になるのか 従来の仕様書が信用されない理由 テストコードは「動く仕様書」になる なぜコメントではなくテストなのか SDDにおける設計の変化 SDDを導入すると何が変わるか（実際の現場） 注意点：テストが仕様…

SDD(仕様駆動開発)におけるユースケースとユーザーストーリーの違い ユーザーストーリーとは何か ユースケースとは何か 基本フロー 代替フロー 違いを整理する なぜ混同すると問題が起きるのか SDD(仕様駆動開発)での使い分け 具体例：パスワードリセット ス…

SDD(仕様駆動開発)ではなぜUI仕様を最初に書いてはいけないのか UIは仕様ではなく実装の一部 なぜUIから始めると手戻りが起きるのか UI中心開発で発生する典型的な不具合 「ボタンはあるが動作が決まっていない」 「例外処理が後付けになる」 「APIと画面の…

SDD(仕様駆動開発)で曖昧な仕様がバグを生むメカニズム ソフトウェア開発の3つのモデル 曖昧性が生む「暗黙仕様」 なぜレビューで防げないのか 状態空間爆発と仕様不足 SDDが行うこと よくある誤解：柔軟性が下がるのでは？ 現場で実際に起きる変化 注意点 …

SDD(仕様駆動開発)における受け入れ基準の書き方 受け入れ基準と仕様書の違い 良い受け入れ基準の条件 観測可能である 条件が明確である 判断が二値である Given/When/Then形式の技術 受け入れ基準が弱いと何が起きるか よくある失敗パターン UIを受け入れ基…

SDD(仕様駆動開発)とアジャイル開発は本当に対立するのか なぜ対立して見えるのか 「仕様書＝固定された契約書」という誤解 SDD(仕様駆動開発)の本質 SDDが行うこと アジャイル開発の本質 SDDとアジャイルが補完関係になる理由 実際の開発で起きる変化 SDDを…

SDDは「新しい開発手法」ではなく工程の再定義である ウォーターフォールの工程構造 SDDの工程構造 工程レベルの比較 なぜ同じに見えてしまうのか 実際のプロジェクトでの挙動 品質保証の考え方の違い 注意点 ― SDDは魔法ではない よくある誤った導入 最後に…

SDDでは仕様と設計は同じものではない 仕様とは何を指すのか 設計とは何を指すのか なぜこの分離が必要なのか 実際の開発で起きる変化 設計変更が安全になる理由 よくある失敗 ― 設計を仕様に入れてしまう 仕様の粒度はどこまで書くべきか 注意点 ― 仕様不足…

SDDにおけるSpecificationは「仕様書」ではない なぜドキュメントでは不十分なのか Specificationはインターフェース契約になる テストとの違い 実際の現場で起きる変化 なぜ契約という考え方が重要なのか 注意点 ― Specificationを書きすぎる問題 変更と破…

SDD(仕様駆動開発)では「要件定義書」を中心にしない なぜ文章の仕様は必ず壊れるのか 実行可能な仕様とは何か 要件定義書と何が違うのか 実際のプロジェクトで起きる変化 ありがちな誤解 注意点とリスク 導入のコツ 最後に SDD(仕様駆動開発)では「要件定義…

SDD(仕様駆動開発)とは何か なぜ「実行可能な仕様」が必要になるのか Gherkinによる仕様の例 SDDとTDDの違い SDDとDDDの違い SDDにおけるSpecificationは「契約」である SDD導入で起きる実際の変化 失敗しがちなポイントとリスク SDDが向いているプロジェク…

ドメインモデルは「クラス設計」からは生まれません SDD（仕様駆動開発）とは何を駆動するのか ドメインモデルの出発点は「状態遷移」 仕様から読み取るべき3つの要素 具体例：予約システムからドメインモデルを抽出する 値オブジェクトが生まれる瞬間 よく…