SDD
AgentOSは「AI」よりもワークフローエンジンに近い ワークフローエンジンとは何をしているのか 開発は直線ではなくグラフとして扱われる イベント駆動で動作している LLMの役割はワーカーに近い なぜこの構造が必要なのか 実際の動作の流れ 注意点：すべてが…
「仕様を書いたら実装が始まる」は比喩ではない 仕様から直接コードは作られていない 実際の内部フロー 仕様解析：最初に行われる処理 タスク生成：実際に何が作られるのか タスク依存関係の構築 実装生成のタイミング 「仕様からタスク生成」が意味するもの…
従来の開発ツールはどこを支援していたか 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(仕様駆動開発)は人間関係を改善する手法ではないが、結果として衝突は減る なぜPMとエンジニアは衝突するのか 従来開発における仕様の位置 よくある摩擦 SDDにおける仕様の定義 衝突が減るメカニズム 責任の所在が明確になる 見積もりが現実的になる 注…
SDD(仕様駆動開発)では「レビューの質」がプロジェクトを決める なぜチェックリストが必要になるのか チェックリスト設計の基本方針 入力仕様のチェック項目 出力仕様のチェック項目 エラー仕様のチェック項目 状態遷移のチェック項目 並行処理のチェック項…
SDD(仕様駆動開発)はTDDを置き換えるのか TDDが解決しようとしている問題 SDDが解決しようとしている問題 両者の関係を整理する なぜTDDだけでは不足するのか SDDを導入するとTDDは不要になるのか よくある誤解：SDDはテストを増やす手法 導入時の注意点 現…
SDD(仕様駆動開発)における回帰テスト自動化とは何か なぜ回帰テストが必要になるのか 仕様テストはそのまま回帰テストになる 手動回帰テストが増える理由 自動化の対象を間違えると失敗する 回帰テストが機能する条件 CIと回帰テストの関係 よくある誤解：…
SDD(仕様駆動開発)でE2Eテストが増えすぎるのはなぜ起きるのか E2Eテストが増殖するメカニズム SDDにおけるテストの本当の粒度 なぜE2Eに頼ってしまうのか 回避するための設計：アプリケーションサービスの分離 E2Eテストの正しい役割 目安となるテスト比率 …
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は魔法ではない よくある誤った導入 最後に…
