プラットフォームの要件定義でハマる「境界」の引き方
プラットフォーム型のプロダクトほど、「何でもやれる」が仇になります。ドメイン駆動設計（DDD）の文脈では、境界づけられたコンテキストなど、境界を言語で縛る考え方が参照されます（Eric Evans の著書に起源）。私は要件定義で、コアと周辺、公開APIと内部の切り分けに時間を使います。 「何でもできるAPI」は、だいたい誰の責任でもない泥沼の入り口になる。
プラットフォーム型のプロダクトほど、「何でもやれる」が仇になります。ドメイン駆動設計（DDD）の文脈では、境界づけられたコンテキストなど、境界を言語で縛る考え方が参照されます。私は要件定義で、コアと周辺、公開APIと内部の切り分けに時間を使います。
境界は、一度引いたら終わりではありません。滲みを異常ではなく信号として扱うと、会議が楽になります。
境界が無いと起きること
公開APIが増えるほど、暗黙の契約が増えます。私は「この境界を越える要求は今四半期は受けない」と宣言する練習をチームとしました。
データの真実はどのチームか
曖昧なら、先に決める。データの所有者が決まらないまま機能を足すと、後から血が流れます。
ロードマップと境界の同期
売上目標だけが先に来ると、境界は都合よく引き直されます。ロードマップの各項目に、触ってはいけない境界をタグとして付けました。
「今回だけ例外」は複利で効く
例外承認に、次の是正の日付を必須にする運用を試しました。日付が無い例外は、永久例外です。
APIの読者は誰か
API仕様の冒頭に「一次読者は誰か」を一行入れました。入れると、例が増え、冗長が減ることがあります。
まとめ
境界は引いた瞬間から古い。古いことを恥じると、再交渉が止まる。
プラットフォームの要件定義で効くのは、機能の羅列より境界の言語化。コアと周辺、公開と内部、依存の方向、データの所有者、やらないこと。境界は冷たい線じゃない。チームが速く走るための柵だ。
企画会議の冒頭、ホワイトボードに一行。「いま滲んでいる境界はどこか」。書けたら半分は設計が始まっている。境界は一度で終わらない。短い儀式として繰り返す。うまくいかなかったプロジェクトほど、境界の仮説が現実を教えてくれる。恥にしないでメモしておけ。
仕上げのための自問（現場メモ）
記事にするほどではないが、私が自分用に残している自問です。全部に答えなくてよいです。
いまの議論は、次の一週間の行動に落ちるか
落ちないなら、まだ抽象度が高い。
反対意見を一行で言語化できるか
言えない反対は、ただの不安であることが多いです。
休む予定を入れたか
持続可能性はスローガンではなく、カレンダーの実装です。
参考・出典
- Martin Fowler, Software Architecture Guide, https://martinfowler.com/architecture/ （参照: 2026-04-06）
- Domain-Driven Design コミュニティの公開資料（境界づけられたコンテキストの一般解説）