Aka Blog
Written by aka
on 

Sprouted: 仕様駆動開発の上位フレームワークとしての仮説木

#thoughts #framework #sdd #software-design
Sprouted: 仕様駆動開発の上位フレームワークとしての仮説木

どうもakaです. 新しいフレームワークを考えたぞ! ということで公開します.

アイデアなんで, 出したもんがちだよね. ということで, まだ検討するべき部分はありつつも, とりあえず公開しました. 「要求も仕様もすべて仮説」という立場から, Why/What/Howの再帰木構造で意思決定を管理するフレームワークです. SDDツールとの比較やGORE・HDD・DRとの関係も整理しています.

⚠️ 本稿の執筆にはAIを活用しています. 構造化と文章の推敲に活用し, 内容の設計・判断・最終レビューはakaが行いました.

Sprouted: 仕様駆動開発の上位フレームワークとしての仮説木

はじめに：仕様駆動開発への違和感

2025年、仕様駆動開発（Spec-Driven Development, SDD）が注目を集めている。「仕様を書いてからAIにコードを生成させる」ツールが次々と登場し、「vibe coding」からの脱却が叫ばれている。

この流れ自体は正しい。曖昧なプロンプトでコードを書かせるより、意図を明確にしてから実装に入る方が品質は上がる。しかし、実際にこれらのツールを使っていると、ある違和感が拭えない。

結局、要求が変われば仕様も変わる。

SDDツールは「仕様をソースオブトゥルースとして扱え」と言う。だが、その仕様の根拠となる要求自体が変わり得るなら、仕様を「確定したもの」として扱うことにどれだけ意味があるのか。要求も仕様も設計も、すべて仮説ではないのか。

本稿では、この考え方を「Sprouted」というフレームワークとして定義する。Sproutedは、SDDを否定するものではなく、SDDを含むより上位の構造を提供するメタフレームワークである。

SDDツールの構造的問題

SDDへの違和感を、もう少し具体的に掘り下げてみよう。2025年現在の主要なSDDツールは、いずれも線形的なパイプラインを採用している。

実際にこれらを使ってみると、いくつかの構造的な問題に突き当たる。

「要求」「仕様」「設計」の境界が曖昧

SDDツールを使っていて最初に困ったのがこれだった。どこまでが要求でどこまでが仕様なのか、どこから設計なのか、現場で明確に線を引ける人は少ない。

「ユーザーがタスクを管理できる」は要求か、仕様か。「タスクの追加・完了・一覧表示ができる」は仕様か、設計か。SDDツールは「仕様」という層を特権的に扱うが、何を仕様と定義するかで現場は混乱する。

本質は、達成したいこととそのための手段が各階層で分離できていることであって、それぞれを何と呼ぶかは本質的ではない。にもかかわらず、SDDツールは「要求」「仕様」「設計」という特定の階層名にプロセスを縛りつけている。

変更追跡・根拠管理・粒度の問題

呼び名の問題に加えて、SDDツールを使っていると他にもいくつかの壁に突き当たる。

これらの問題の根底には、ある共通の原因がある。「仕様は確定したものである」という前提だ。

確定物という幻想

すべては仮説である

従来の開発プロセスでは、「要求は確定、仕様は変わる」「仕様を固めればコードが安定する」といった前提が暗黙的に置かれてきた。SDDツールも同様に、仕様を「ソースオブトゥルース」つまり確定した真実として扱っている。

しかし、本当にそうだろうか。

「タスクを忘れて困っている人がいる」は本当か。困っている人がいたとして、「TODOアプリが最適な解決策である」と言い切れるか。要求も仕様もコードも、すべてはまだ検証されていない「賭け」だ。つまり、すべての階層は仮説である。

要求が変わったとき、仕様が変わったとき、現場では「管理が甘かった」と反省しがちだ。しかし、すべてが仮説なら、仮説が崩れること自体は避けられない。どんなに丁寧に書いても、前提が変われば変わる。要求も仕様も同じことだ。本当の問題は、仮説が崩れたときに何がどこまで影響するか見えていないことにある。

変わりやすさのグラデーション

もちろん、すべてが仮説だとしても、変わりやすさには差がある。

「要求は安定、コードは不安定」という従来の見方は、実はこの性質そのままである。ただし、従来は「要求」や「仕様」といった特定の階層を特別扱いしていた。しかし、すべての階層を仮説として平等に扱えば、違いは変わりやすさのグラデーションだけになる。

最上位の仮説が崩れたときの影響は甚大だ。だからこそ、どの仮説の上に立っているのかを構造的に把握する仕組みが必要になる。

この認識に基づいて設計したのが、Sproutedである。

Sproutedの核：Why / What / How の再帰木構造

Sproutedは、Why/What/Howの再帰木構造ですべての意思決定を仮説として管理するフレームワークである。 「要求」「仕様」「設計」といった階層名を捨て、すべてのノードをWhy/What/Howという統一的な構造で扱う。

基本構造

Sproutedでは、あらゆる開発上の意思決定を木構造のノードとして管理する。各ノードは3つの属性を持つ。

ユーザーにとっては Why / What / How の3つだけ考えればよい。ただし、Whyの中に動機と制約の両方が入り得ることを意識すると、Whyの質が上がる。

階層間の接続：2本の線が階層を降りていく

Sproutedの再帰構造を理解する鍵は、階層間の接続が2本の線で構成されていることだ。

そして各ノードの中では、動機がWhatを生み、制約がHowの選択肢を絞る。

TODOアプリを例に見てみよう。

graph TD
    subgraph "第1階層"
        WM1["Why（動機）: タスクを忘れて困っている人がいる"]
        WC1["Why（制約）: スマホ利用者が対象 / 個人開発規模"]
        What1["What: タスクを記録・管理できるようにしたい"]
        How1["How: TODOアプリを作る"]
        WM1 --> What1
        WC1 --> How1
        What1 --> How1
    end

    subgraph "第2階層"
        WM2["Why（動機）: ユーザーは日常的にタスクが発生・完了・変更される"]
        WC2["Why（制約）: TODOアプリ（Web/モバイル）が前提"]
        What2["What: タスクの追加・完了・一覧表示ができる"]
        How2["How: React + SQLiteで実装する"]
        WM2 --> What2
        WC2 --> How2
        What2 --> How2
    end

    subgraph "第3階層"
        WM3["Why（動機）: 一覧表示は件数が増えると見づらくなる"]
        WC3["Why（制約）: React + SQLiteが前提。SQLのORDER BY/WHEREが使える"]
        What3["What: タスクを期限や優先度で並び替え・絞り込みできる"]
        How3["How: クエリパラメータによるソート・フィルタAPIを作る"]
        WM3 --> What3
        WC3 --> How3
        What3 --> How3
    end

    What1 -.->|"動機の連鎖"| WM2
    How1 -.->|"制約の連鎖"| WC2
    What2 -.->|"動機の連鎖"| WM3
    How2 -.->|"制約の連鎖"| WC3

    style WM1 fill:#4a9e4a,color:#fff
    style WM2 fill:#4a9e4a,color:#fff
    style WM3 fill:#4a9e4a,color:#fff
    style WC1 fill:#8B4513,color:#fff
    style WC2 fill:#8B4513,color:#fff
    style WC3 fill:#8B4513,color:#fff
    style What1 fill:#3a7bd5,color:#fff
    style What2 fill:#3a7bd5,color:#fff
    style What3 fill:#3a7bd5,color:#fff
    style How1 fill:#e67e22,color:#fff
    style How2 fill:#e67e22,color:#fff
    style How3 fill:#e67e22,color:#fff

この連鎖は必要なだけ続く。そして、どの階層も同じ構造を持つ。第1階層を「要求」と呼ぼうが、第2階層を「仕様」と呼ぼうが、第3階層を「設計」と呼ぼうが、それは自由である。構造は同一だからだ。

仮説検証サイクルとしてのノード

各ノードは「前提 → 仮説 → 検証 → 結果」の小さなサイクルと対応する。

つまり、各ノードは小さな仮説検証サイクルである。この視点を持つと、開発は「確定した仕様を実装する作業」ではなく「仮説を検証していくプロセス」として捉えられる。

選択肢の構造：1対多対多

WhyとWhat、WhatとHowの関係は1対多である。つまり構造は Why 1 : What 多 : How 多 だ。

一つのWhyに対してWhatが複数あり、各Whatに対してHowが複数ある。

graph TD
    W["🌱 Why（動機）: タスクを忘れて困っている人がいる"]

    W --> WA["What①: タスクを記録・管理できるようにする"]
    W --> WB["What②: タスクの期限が来たら通知する"]
    W --> WC["What③: 日常行動から自動的にタスクを抽出する"]

    WA --> HA1["How: TODOアプリ"]
    WA --> HA2["How: 付箋アプリ"]
    WA --> HA3["How: LINEボット"]

    WB --> HB1["How: プッシュ通知"]
    WB --> HB2["How: メールリマインダー"]

    WC --> HC1["How: AIによる自動抽出"]

    style W fill:#4a9e4a,color:#fff
    style WA fill:#3a7bd5,color:#fff
    style WB fill:#3a7bd5,color:#fff
    style WC fill:#3a7bd5,color:#fff
    style HA1 fill:#e67e22,color:#fff
    style HA2 fill:#e67e22,color:#fff
    style HA3 fill:#e67e22,color:#fff
    style HB1 fill:#e67e22,color:#fff
    style HB2 fill:#e67e22,color:#fff
    style HC1 fill:#e67e22,color:#fff

Whatが変わるとHowの選択肢がまるごと変わる。What①「記録・管理」を選んだ場合のHow群（TODOアプリ、付箋アプリ、LINEボット）と、What②「通知する」を選んだ場合のHow群（プッシュ通知、メールリマインダー）は、まったく別の選択肢になる。

実際の開発では、各階層で選択肢の中から一つを選ぶ。重要なのは、選ばれなかった選択肢とその理由も記録することだ。

Why / What / Howの書き方

各属性を書くときの注意点を整理する。

変更の伝播

Why / What / Howのどれかが変わったら、その下の部分木を見直す必要が出てくる可能性がある。

graph TD
    subgraph "変更前"
        B_W["Why（動機）: タスクを忘れて困っている"]
        B_W --> B_What["What: 記録・管理できるようにする"]
        B_What --> B_How["How: TODOアプリ ✅"]
        B_How --> B_C1["CRUD API設計"]
        B_How --> B_C2["React UI設計"]
        B_How --> B_C3["SQLiteスキーマ設計"]
    end

    subgraph "Howを切り替えた後"
        A_W["Why（動機）: タスクを忘れて困っている"]
        A_W --> A_What["What: 記録・管理できるようにする"]
        A_What --> A_How["How: LINEボット ✅"]
        A_How --> A_C1["Messaging API連携"]
        A_How --> A_C2["リッチメニュー設計"]
        A_How --> A_C3["会話フロー設計"]
    end

    style B_W fill:#4a9e4a,color:#fff
    style B_What fill:#3a7bd5,color:#fff
    style B_How fill:#e67e22,color:#fff
    style B_C1 fill:#ddd,color:#333
    style B_C2 fill:#ddd,color:#333
    style B_C3 fill:#ddd,color:#333
    style A_W fill:#4a9e4a,color:#fff
    style A_What fill:#3a7bd5,color:#fff
    style A_How fill:#e67e22,color:#fff
    style A_C1 fill:#f9e79f,color:#333
    style A_C2 fill:#f9e79f,color:#333
    style A_C3 fill:#f9e79f,color:#333

上位のノードほど変わったときの影響が大きく、下位のノードほど影響が局所的になる。これが「すべては仮説であり、違いは変わりやすさのグラデーションだけ」という思想の具体的な表れだ。

確信度と変更コスト

すべてが仮説なら、「どの仮説を優先的に検証すべきか」を判断する仕組みが必要になる。Sproutedでは、確信度と変更コストの2つの軸でこれを判断する。

確信度

各ノードに「この仮説はどこまで信頼できるか」を0.0〜1.0の数値（確信度スコア）で持たせる。確信度は「この仮説を支える最も強いエビデンスは何か？」という問いで測る。

確信度は子から親にも伝播する。子ノードの確信度が高ければ、親の確信度の足を引っ張らない。ただし、子がすべて実証済みでも親が自動的に実証済みにはならない。親自身の仮説が間違っている可能性は残るからだ。

例：確信度スコアと伝播の計算

確信度スコアの実装は自由だが、1例としてNASA TRL（技術成熟度レベル）の思想を借りた4段階を定義する。

段階確信度スコア定義例
Proven（実証済み）0.8〜1.0本番環境・実データで実証本番で3ヶ月稼働、KPIが目標達成
Tested（検証済み）0.5〜0.7PoC・ユーザーテスト等で部分的に検証PoC作って動いた、ユーザー5人にテストした
Reasoned（論拠あり）0.2〜0.4調査・外部事例で裏付けあり。自分の文脈では未検証技術調査で比較した、有識者に聞いた
Gut（直感）0.0〜0.1根拠は直感・経験のみ。未検証「こうすべきだと思う」

子から親への伝播も定式化できる。以下は参考例の一つである。

C(parent) = C_self × C_children

積にすることで、仮説自体が間違っていれば（C_self = 0）、子がいくら証明されても親は0になる。例えば、C_self = 0.8 の親にAND関係の子が2つ（0.9と0.5）あれば、0.8 × min(0.9, 0.5) = 0.40 となり、確信度0.5の子がボトルネックだと分かる。

変更コストと優先順位

木構造の利点は、変更の影響コストを定量化できることだ。あるノードを変更したとき、影響を受ける部分木の深さ（何階層下まで影響するか）と幅（同じ階層でいくつのノードが影響を受けるか）で、変更コストの大きさが見積もれる。

確信度と変更コストは独立した2つの軸である。この2軸を組み合わせると、どの仮説を優先的に検証すべきかが見えてくる。

変更コスト小変更コスト大
確信度高安定。放置でよい基盤。崩れにくいが崩れたら甚大
確信度低気軽に試行錯誤できる危険。真っ先に検証すべき

最も注意すべきは確信度が低く変更コストが大きいノードだ。まだ検証されていないのに、その上に大量の仮説が積み上がっている状態。この組み合わせを見つけたら、他の作業より優先してそのノードの検証に取り組むべきだ。

確信度をどう上げるか

確信度を上げるアクションは、現在のスコアによって変わる。先程のNASA TRLの例を用いると以下となる。

重要なのは、すべてを1.0にする必要はないということだ。変更コストが低い仮説は低スコアのまま走ってよい。変更コストが高い仮説だけ、意図的にスコアを上げる。2x2マトリクスの右下だけに検証コストを集中させるのが、実務的な使い方だ。

ただし一つ注意がある。確信度の低い仮説の上に、確信度の低い仮説を積み上げてはいけない。 個々のノードの不確実性は小さくても、連鎖すると全体の確信度は掛け算で下がる。0.3以下のノードが2階層以上連続していたら危険信号だ。仮説木がなければこの状態に気づくことすら難しい。

SDDの問題をどう解くか

ここまでがSproutedの説明だ。冒頭で挙げたSDDの問題に対して、Sproutedは以下の構造的な解を提供する。

SDDの問題Sproutedのアプローチ
「要求」「仕様」「設計」の境界が曖昧階層名を捨て、すべてのノードをWhy/What/Howで統一
仕様が確定物として扱われるすべてのノードが仮説。確信度によるグラデーション管理
Whyが構造に組み込まれていない各ノードがWhy（動機+制約）/What/Howを持ち、Whyが起点
変更の伝播が手動木構造により影響範囲が部分木として自動的に特定される
粒度の柔軟性がない木の深さで粒度が自然に決まる。深く掘るか浅く留めるかは自由

重要なのは、SproutedはSDDを否定しないということだ。SDDツールは「仕様→コード生成」という葉ノードレベルの変換に優れている。Sproutedは、その上位にある「なぜその仕様を書くのか」「その仕様は本当に正しいのか」「仕様が変わったらどこに影響するのか」を構造的に管理する。

Sproutedの木構造の葉ノードが十分に具体的なHowになったとき、それは既存のSDDツールが受け取る「仕様」と同等のものになる。つまり、Sproutedは既存のSDDツールを置き換えるのではなく、その上に乗るメタフレームワークである。

なお、Sproutedの思想は既存の学術的アプローチ — Goal-Oriented Requirements Engineering（GORE）の構造性、Hypothesis-Driven Development（HDD）の仮説管理、Design Rationale（DR）の意思決定記録 — と接点を持つ。これらとの詳細な比較は付録Bを参照されたい。

共通化の罠

SDDの問題を構造的に解決した上で、実務で陥りやすい罠を一つ取り上げる。

開発者は共通化したがるバイアスを持っている。似たような機能を見つけると、「これは一つにまとめられるのでは？」と考える。しかし、Howが同じに見えるだけで、WhyとWhatが異なるものを共通化すると、どちらの目的にとっても中途半端になる。

複数の親から同じHowに到達するケースがある。例えば「タスク忘れ防止」と「チーム進捗の可視化」という異なるWhyから、どちらも「TODOアプリ」というHowに到達するケースだ。しかし、WhyやWhatが異なればHowの詳細も微妙に変わる。安易に共通化すると、どちらの目的にとっても中途半端なものが出来上がる。そしてWhyが違う以上、片方のWhyが変わったときの部分木の切り替えが、もう片方の木に意図しない影響を与えてしまう。

典型的な失敗パターンとして、あるメモアプリが「メモ」「タスク管理」「ドキュメント管理」を一つのアプリに詰め込んだケースを考えてみよう。Sproutedで構造化すれば、これは3つの異なるWhyから生まれた異なる木であることが明確になる。Why①「思いついたことを忘れたくない」、Why②「仕事を整理したい」、Why③「資料をまとめたい」。それぞれが異なるWhatとHowを持つ。これが可視化されていれば、「本当に一つのアプリにすべきか？」という問いが立てられたはずだ。

Sproutedでは、共通化すべきかどうかの判断基準が構造的に定まる。

逆に、異なる場所に似たノードが出現したとき、Why / What / Howのすべてが完全に一致しているなら、それは同じものであり使いまわしてよい。一つでもNoなら、たとえ似ていても別ノードとして管理したほうがいい。どれかが変わったときに片方だけ切り替えたいのに、共通化していると巻き添えになるからだ。

サンクコスト

ただし、理屈の上では「部分木を丸ごと切り替える」のが合理的でも、現実にはそう簡単にはいかない。すでに設計が進んでいたり、コードが書かれていたり、チームがその方向で動いていたりする。サンクコストは現実に存在する。

だからこそ、Sproutedで木構造を可視化しておくことに意味がある。切り替えるかどうかの判断をするとき、「今どこにいて、何が影響を受けるのか」が見えていれば、感情的な判断ではなく構造的な判断ができる。全部切り替えるのか、一部だけ再利用できるのか、影響範囲はどこまでか。それを見た上で「サンクコストを受け入れてでも切り替える」のか「このまま進む」のかを選べばいい。

Sproutedは「常に正しい選択をする」ためのフレームワークではない。正しい選択かどうかは事後にしかわからない。ただ、今どんな仮説の上に立っていて、何が変わったら何に影響するのかが見えていれば、最善を尽くすことはできる。Sproutedは、そのためのフレームワークだ。

展望：LLMとの親和性

ここまでSproutedの構造と実務上の注意点を述べた。最後に、このフレームワークが実用的に機能するための鍵となるLLMとの親和性について論じる。

Sproutedは、LLMの登場によって初めて実用的になるフレームワークでもある。

Design Rationaleが50年間解けなかった問題

実は、Sproutedに近い構造を持つアプローチは過去にも存在した。1970年に提唱されたDesign Rationale（設計根拠、詳細は付録Bを参照）は、「なぜこの設計にしたのか」を構造的に記録するアプローチであり、Question/Option/Criteria（QOC）という構造はSproutedのWhy/What/Howと驚くほど近い。

しかし、Design Rationaleは50年間にわたって実務での普及に失敗してきた。その原因は明確に分析されている。

これらの失敗原因は、すべて「人間が手動で構造化する」ことに起因している。

LLMが構造化コストを解消する

LLMの登場により、この50年来の課題に解が見えてきた。

つまり、Design Rationaleが50年間解けなかった「構造化のコスト」問題を、LLMが解く可能性がある。Sproutedが「LLMの登場によって初めて実用的になるフレームワーク」であるという主張は、この歴史によって裏付けられる。

その他のLLM活用

おわりに

Sproutedの本質は、ソフトウェア開発におけるすべての意思決定を「仮説の木」として管理するという思想にある。

要求も仕様も設計もコードも、すべて仮説である。違うのは、抽象度と変わりやすさのグラデーションだけだ。この認識に立てば、特定の階層を特別扱いする必要はなく、すべての階層に同じ操作（分解、トレース、変更影響分析、仮説検証）を適用できる。

Sproutedというフレームワーク名は、「Whyという種から仮説が芽吹き（sprout）、木として育っていく」という開発プロセスのメタファーから来ている。種が良ければ木は健全に育つし、種（Why）が間違っていればどんなに丁寧に仕様を書いても意味がない。

SDDツールは「仕様→コード」の変換を効率化した。Sproutedは、その仕様がなぜ存在するのか、本当に正しいのか、変わったときに何が影響するのかを構造的に管理する。両者は対立するものではなく、組み合わせることでより堅牢な開発プロセスを実現できる。

すべての開発は、一粒の種 — 「なぜ」 — から始まる。

付録A：Sproutedのルールとチェックリスト

本フレームワークのルールは、RFC 2119に倣い以下の3段階で定義する。

ノード構造に関するルール

階層と分解に関するルール

選択肢と意思決定に関するルール

仮説管理に関するルール

共通化に関するルール

チェックリスト：ノードを作るとき

  1. ☐ Whyが書かれているか？ 動機がないノードは存在意義が不明
  2. ☐ Whyの動機は親のHowの言い換えではなく、親のWhatから導出されているか？
  3. ☐ Whyの制約は明記されているか？ 特に第1階層で忘れがち
  4. ☐ Whatは動機から自然に導かれているか？ 飛躍がないか
  5. ☐ Whatが複数あるとき、AND（すべて必要）かOR（選択肢）か明記したか？
  6. ☐ Howの候補は複数検討されたか？ 最低2つは考えたか
  7. ☐ 選ばなかった候補とその理由は記録されているか？
  8. ☐ ノードに複数のWhyが混ざっていないか？ 混ざっていたら分割する
  9. ☐ 確信度スコアを設定したか？ 0.0〜1.0で今の検証状態を反映しているか
  10. ☐ 変更コスト（部分木の深さ×幅）を確認したか？ 確信度が低く変更コストが大きいなら優先検証
  11. ☐ 重要なノードなら、仮説を崩しうるリスクを書いたか？

チェックリスト：ノードを変更するとき

  1. ☐ 何が変わったのか？ Why（動機/制約）/ What / How のどれか
  2. ☐ 子ノードへの影響は確認したか？ 動機が変わればWhatが、制約が変わればHowが影響を受ける
  3. ☐ 部分木全体を見直す必要があるか、一部で済むか？
  4. ☐ 変更コストを見積もったか？ 影響を受ける部分木の深さと幅
  5. ☐ サンクコストを踏まえた上で、切り替えるかどうかの判断をしたか？
  6. ☐ 共通化しているノードがある場合、他の利用箇所への影響は？
  7. ☐ 変更の理由は記録したか？ 後から「なぜ変えたのか」を追えるように
  8. ☐ 影響を受けたノードの確信度スコアを更新したか？

付録B：既存アプローチとの学術的比較

Sproutedの思想は、ソフトウェア工学の複数の分野と接点を持つ。ここでは特に関連の深い3つのアプローチ — Goal-Oriented Requirements Engineering（GORE）、Hypothesis-Driven Development（HDD）、Design Rationale（DR） — との関係を整理する。

結論を先に述べると、SproutedはGOREの構造性とHDDの仮説管理を組み合わせ、DRが50年間解けなかった実用化の壁をLLMで乗り越えようとするものとして位置づけられる。

Goal-Oriented Requirements Engineering（GORE）

GOREとは何か

Goal-Oriented Requirements Engineering（GORE）は、要求工学の分野で20年以上にわたって研究されてきたアプローチであり、ゴール（目標）を起点として要求を引き出し、モデル化し、分析する手法群の総称である。代表的なフレームワークとしてKAOS（Keep All Objectives Satisfied）とi*（iStar）がある。

KAOSでは、最上位のゴールをAND/OR分解で段階的に具体化し、最終的にエージェント（人間やソフトウェア）に割り当て可能なレベルまで落とし込む。各ゴールは時相論理（LTL）で形式的に定義でき、ゴール達成を妨げる障害（Obstacle）の分析も体系的に行われる。i*は、組織内のアクター間の依存関係（誰が誰に何を依存しているか）をモデル化し、「なぜ（Why）」「誰が（Who）」「どうやって（How）」の次元を扱う。

Sproutedの再帰的な木構造、WHY/HOWによる分解、代替案の明示的管理は、GOREの基本的な発想と表面的に類似している。しかし、両者は根底にある認識論が異なり、対象とするレイヤーも異なる。

認識論の違い：ゴールは「正しいもの」か「仮説」か

GOREは「ゴールはステークホルダーから引き出された正しいものであり、それを漏れなく形式的に分解するのが仕事」という立場に立つ。ゴール自体が間違っている可能性を構造的に管理する仕組みはない。

Sproutedは「すべてのノードは仮説であり、確信度のグラデーションの中にある」という立場に立つ。最上位のWhyですら検証されるまでは賭けであり、崩れたときには部分木全体を見直す。

この違いは変換を試みると明確になる。KAOSでTODOアプリをモデル化すると「タスクが適切に管理される」というゴールが起点になる。これをSproutedに持ち込もうとすると、Whyが書けない。KAOSではゴール自体が起点だが、Sproutedでは「タスクを忘れて困っている人がいる」というWhyが起点であり、ゴールに相当するWhatはそこから導出されるものだからだ。

逆方向も同様で、SproutedのノードをKAOSに変換すると、確信度と仮説管理、動機と制約の2本線接続が消失する。KAOSにはゴールが「間違っているかもしれない」という概念がないため、Sproutedの核である仮説管理の構造が行き場を失う。

つまり、両者の間にきれいな双方向変換は成立しない。

レイヤーの違い：木の中の整合性 vs. 木自体の妥当性

認識論の違いは、対象とするレイヤーの違いでもある。

KAOSの形式検証は、ゴールを時相論理で定義し、システムの状態遷移モデルを記述した上で、モデルチェッカーが全経路を探索して「このゴールに到達できない経路があります」と報告する仕組みである。これは強力だが、検証できるのは「定義済みの状態空間の中の抜け漏れ」だけであり、状態変数や操作の列挙自体は人間が行う。モデルに入れ忘れた世界の抜け漏れは原理的に検出できない。

Sproutedは、そもそも「木自体が間違っている可能性」を前提にしている。KAOSが「TODOアプリでタスクを管理する」というゴール木の中の整合性を完璧にしたとしても、ユーザーの本当の課題が「忘れること」ではなく「優先順位がつけられないこと」だったなら、その木全体が無意味になる。Sproutedはこの「木自体を取り替える判断」を支援する。

つまり、GOREは木の中の整合性を検証し、Sproutedは木自体の妥当性を問う。両者は対立ではなく、レイヤーが異なる。

GOREの知見の取り込み

GOREが持つ強みのうち、Sproutedの思想と自然に接続するものはルールとして取り込んだ。

一方、以下はスコープ外とした。

Hypothesis-Driven Development（HDD）

HDDとは何か

Hypothesis-Driven Development（HDD）は、Lean Startup の思想をソフトウェア開発プロセスに直接適用するアプローチである。「要求（requirements）」を「仮説（hypotheses）」に置き換え、新しい機能やサービスの開発を「一連の実験」として捉える。

典型的なHDDのプロセスは以下の通りだ。

  1. 仮定（Assumption）を書き出す
  2. 仮説（Hypothesis）に変換する。テンプレートとしてよく使われるのは： 「We believe that [機能X] will result in [成果Y]. We will know we have succeeded when [指標Z]」
  3. 実験を設計する（A/Bテスト、プロトタイプ、ユーザーインタビュー等）
  4. 実験を実行し、結果を分析する
  5. 仮説を支持（persevere）するか反証（pivot）するかを判断する
  6. 次の仮説へ

学術的には「Hypotheses Engineering」という概念も提唱されており、要求工学が要求を扱うのと同様に、仮説を引き出し、文書化し、分析し、優先順位付けする必要があると主張されている。

Sproutedとの共通点

HDDとSproutedは、認識論のレベルで最も近い既存アプローチである。

決定的な違い：構造の有無

共通の認識論を持ちながら、HDDとSproutedには決定的な違いがある。

  1. HDDの仮説には階層構造がない。 HDDの仮説は基本的にフラットなリストとして管理される。仮説間の親子関係がないため、ある仮説が崩れたときに他のどの仮説に影響するかという構造的な分析ができない。

  2. Why/What/Howの分離がない。 HDDの仮説テンプレート「We believe that [X] will result in [Y]」は、手段（X）と成果（Y）が一文に混在している。SproutedのようにWhyの動機と制約、What、Howを分離し、動機の連鎖と制約の連鎖を追跡する仕組みがない。

  3. 変更伝播の概念がない。 HDDでは仮説が反証されたら「ピボットする」というが、何がどこまで影響するかの分析は人間の頭の中で行われる。

  4. 適用範囲が異なる。 HDDはプロダクトの成果指標（コンバージョン率、DAUなど）に対する仮説検証に特化している。Sproutedはそれより上流の「そもそも何を作るべきか」「なぜ作るのか」の構造化にフォーカスしている。

SproutedはHDDの構造化版として位置づけられる

まとめると、HDDは「仮説として扱う」という認識論は共有しているが、仮説の構造化と変更影響分析を持たない。Sproutedの独自の貢献は、HDDの仮説管理にGOREの構造性を組み合わせたところにある。

Design Rationale（DR）

DRとは何か

Design Rationale（設計根拠）は、設計の過程でなされた意思決定の理由を明示的に記録・管理するアプローチであり、1970年にW.R. KunzとHorst Rittelが開発したIBIS（Issue-Based Information System）を起源とする。以降、QOC（Questions, Options, and Criteria）、DRL（Decision Representation Language）など複数の変種が提案されてきた。

DRの基本構造は、Sproutedと驚くほど近い。

Design RationaleSprouted
Question / Issue / DecisionWhat（達成したいこと）に近い
Option / Position / AlternativeHow（手段の候補群）に近い
Criteria / Argument / GoalWhy（動機と制約）に近い
選ばれなかった選択肢の記録選ばれなかったHowとその理由の記録

Sproutedとの共通点

決定的な違い

  1. DRには仮説管理がない。 DRは「なされた決定の根拠を記録する」アプローチであり、その決定自体が間違っている可能性を構造的に管理する仕組みはない。確信度の概念もなく、「この決定は仮説であり、検証されるまでは賭けである」という認識論がない。

  2. 変更伝播の構造がない。 DRは個々の意思決定の根拠を記録するが、ある決定が変わったときに他のどの決定に影響するかを木構造として追跡する仕組みが弱い。

  3. DRは事後的記録の性格が強い。 実際には多くの場合、設計が終わった後に根拠を書き起こすという運用になりがちである。Sproutedは設計の「前」に木を構築し、木に基づいて設計を進めるという順序を想定している。

DRの50年間にわたる普及失敗の歴史と、LLMによるその克服の可能性については、本文の「展望：LLMとの親和性」セクションで論じた。

Sproutedの位置づけ

3つの既存アプローチとの関係を整理すると、Sproutedが埋めている位置が見えてくる。

Sproutedは、GOREの構造性 × HDDの仮説管理 × DRの意思決定記録を統合し、LLMによってDRが50年間解けなかった実用化の壁を乗り越えようとするものとして位置づけられる。

リポジトリ（2026/03/20 追記）

Sproutedのフレームワーク定義（SKILL.md）、AIアシスタント用システムプロンプト、新規プロジェクト用テンプレート、Sprouted自身の仮説木（実例）を公開しています。

👉 gitlab.com/akapersonal/sprouted

Loading comments...

← Top →