要件を積み上げる整理と、コアドメインから考える整理

なぜこれを書くか

SaaSのプロダクトづくりをしていると、こういう場面に何度も出会います。

• 顧客や業種ごとの要望を一覧にしたのに、議論が収束しない
• 要望を足すたびに仕様が変わり、「結局これは誰のための機能なのか」が説明できなくなる
• 「他に漏れはないですか？」という問いが無限に続く

これは誰かの能力の問題ではなく、整理の型が場面に合っていないときに構造的に起きます。この記録では二つの型の違いを言語化し、SaaSではなぜ順序が変わるのかを整理します。

ふたつの整理の型

観点	要件を積み上げる整理	コアドメインから考える整理
問い	何が求められているか	この業務の本質は何か
成果物	要望・機能の集合（リスト）	概念と規則（モデル）
正しさの確認	言われたことが入っているか	未知のケースを位置づけられるか
最大のリスク	抜け漏れ	抽象が実業務から外れること
強い場面	対象顧客が確定していて、その要求を満たしきる必要があるとき	対象が増え続け、長期に運用し続けるとき

積み上げ型は、目の前の顧客の要求を漏れなく満たせるという明確な強みを持ちます。抜け漏れが即失敗につながる領域では、まず全部並べるのが唯一まともな順序です。この訓練を積んだ人の網羅性は、構造から入る癖のある自分には簡単に真似できません。

一方SaaSでは、作った機能がリリース後もずっと維持され続けます。だから「入れるか / 入れないか」を判断する軸が先に必要になり、その軸が業務の構造になります。

リストとモデルは何が違うのか

ここがいちばんの勘所です。「コアドメインを先に決める」が「必須機能リストを先に作る」になっていたら、それは順番が違うだけの積み上げで、得られるものは変わりません。分かれ目は、リストを作るのか、モデルを作るのかです。

	リスト	モデル
中身	要望・機能の並び	概念と、それらの関係・規則
新しい要望	都度ゼロから議論する	モデルに当てはめて位置づけられる
「入れない」の意味	優先度が低い（いつか入れる）	この層の関心事ではない（別の場所で吸収する）
誤り方	間違えることができない。抜けているかどうかしか言えない	反例で壊れる。壊れたら直せる
蓄積	判断が蓄積しない	一度の判断が次の判断を決める

リストは、書かれた項目にしか答えられません。モデルは、まだ書かれていない項目にも答えを出せます。

モデルかどうかを判定するテスト

1. 未知の要望テスト — まだ聞いていない要望を持ってきて、「これは幹のどこに当たるか」を答えられるか。答えられないなら、それはリストです。
2. 反証テスト — 「この構造が成り立たないケースを挙げてください」と頼めるか。頼めないなら、それは主張ではなく願望です。

二つめは特に重要です。リストは網羅性しか議論できないので、会話が「他にありませんか？」のループになります。モデルは反例が出れば壊れる。壊れたら直す。これは前進です。

判断コスト

実務的な効き目はここに出ます。

• 積み上げ型 — 判断コストが要望の数に比例して増え続ける。要望が来るたびに関係者を集めて議論し直す
• モデル型 — 最初の一回に判断コストを集中させ、以降をほぼ定数時間にする

どちらも合計コストを払う点は同じです。違うのは、払うタイミングと再利用できるかどうかです。長期運用するプロダクトで差が出るのは、この再利用性です。

未知の要望テストと反証テストに加えて、実務ではもう一つ見ます。

3. 判断コストテスト — 項目が2倍になったとき、判断時間も2倍になるか。なるなら、それはまだリストです。

定石のフレームワーク

この考え方には既に名前がついたものが複数あり、だいたい同じことを言っています。車輪の再発明をしないために置いておきます。

フレーム	出どころ	言っていること
コアドメイン / サブドメイン	Eric Evans『Domain-Driven Design』	競争力の源泉になる領域を特定し、モデリングの労力をそこに集中させる。周辺は汎用実装で済ませる
ユビキタス言語	同上	用語の定義を一つに揃える。顧客ごと・業種ごとに言葉が違うまま作ると、設計もそのまま分裂する
Product vs Project / Feature Factory	Marty Cagan『INSPIRED』	要望を順に実装する組織は受託に近づく。プロダクトは「何を作らないか」の判断で成立する
Jobs to be Done	Clayton Christensen	顧客の属性（業種・規模）ではなく、片付けたい用事で捉える。業種は用事の代理変数にすぎない
Configuration over Customization	SaaSアーキテクチャの一般原則	顧客差分はコード分岐ではなく設定・パラメータで吸収する。分岐は永続的な保守債務になる
80 / 20 ルール	SaaS一般	共通8割を製品で持ち、残り2割は設定・運用・パートナーで埋める

いずれも「先に幹を決める」ことの価値を、別の角度から述べています。

定石だからこそ知っておく失敗

抽象化が早すぎて外す。 Evans自身が「モデルは具体のドメイン知識から蒸留される」と書いている通り、コアドメインは机上では作れません。実在する業務を見ないまま抽象化すると、汎用的すぎて誰にも刺さらないモデルができます。具体の収集を飛ばす言い訳にしてはいけません。

抽象化しすぎて差別化を失う。 バーティカルSaaSでは、業種特化の深さそのものが競争力です。「業種差分は常に枝」と一般化すると、水平SaaSに近づいて強みを削ります。どのレイヤーまで共通化するかは毎回の設計判断であり、原則から自動的には決まりません。

「決めない」を明文しない。 「これは入れない」を言語化せずに進めると、周囲からは「意図的に外したのか、単に漏れているのか」が区別できません。積み上げ型の視点を持つ人にとって、これが最大の不安要素になります。PRDの「フォーカスしないこと」を埋めるのは、そのための装置です。

実務でどう分担するか

二つの型は、対立ではなく分業として組むと機能します。

役割	やること	なぜその型が向くか
幹の定義・取捨選択	業務の構造を定義し、どの層で何を吸収するかを決める	軸を持つ人が一人でないとブレる
具体の収集	顧客・業種ごとの実業務を漏れなく集めて構造化する	網羅性の訓練を積んだ人が圧倒的に速い
反証	「このケースでは幹が成り立たない」を突きつける	積み上げ型の視点が最も価値を出す場所

ここで大事なのは、具体の収集と反証は、幹の定義と同じくらい欠かせないということです。反例のないモデルは検証されていないモデルであり、それは単なる思い込みです。

チェックリスト

自分の整理がリストで止まっていないかを見るための3つ。

• 名詞と規則で書かれているか（機能名の羅列になっていないか）
• まだ聞いていない要望を当てはめて、収まる / 収まらないが判定できるか
• 「反例を挙げてください」と人に頼める形になっているか

議論を始める前に決めておく2つ。

• 今日決めることと、決めないことを冒頭で宣言したか
• 参加者に求めているのは「網羅性」か「反例」かを伝えたか

まとめ

• 要件を積み上げる整理と、コアドメインから考える整理は、目的が違う道具である。優劣ではない
• SaaSで先に必要なのは機能のリストではなく、判断の基準になる業務の構造
• 「幹を先に固める」は要件を絞ることではなく、判断を再利用可能にすること
• モデルは反例で壊れることに価値がある。だから具体を集める力と反証する力が不可欠
• 幹をどこまで共通化するかは原則から自動で決まらない。毎回の設計判断として議論する