用語解説
「見える仕様」とは？
認識のズレを、作り込む前に見つけるための仕様の形。定義・3つの条件・従来手法との違い・作り方を解説します。
定義
「見える仕様」とは、業務システムのヒアリング内容を構造化し、①図表（ER図・状態遷移図・コンテキストマップ）、②体系化された仕様書、③実際に操作できる動くプロトタイプの3点セットとして、発注者と開発者が同じものを見ながら確認・修正できる状態にした仕様のことです。
なぜ文章だけの要件定義書では足りないのか
文章は読み手の解釈で意味が割れます。「承認されたら出荷する」と書いたとき、その「承認」が誰のどの操作を指すのか、書いた人と読んだ人は別の絵を思い浮かべていることがあります。
そして認識の齟齬は、動くものを触った瞬間に露見します。従来の開発では、その瞬間が「本実装の後」——つまり手戻りコストが最大になる時点でした。
見える仕様は、この確認の時点を「作り込む前」へ前倒しするための道具です。仕様を文章として合意するのではなく、図表・文書・動くプロトタイプを一緒に見ながら合意します。
「見える仕様」の3つの条件
1. 構造が図で見える
データの関係は ER 図、業務のライフサイクルは状態遷移図、業務の区切りはコンテキストマップ。文章を読み解かなくても、構造そのものを目で確認できる。
2. 挙動が動きで見える
画面遷移・入力・承認フローを、実際に操作できるプロトタイプで確認できる。「思っていたのと違う」が、本実装の前に言える。
3. 再現性がある
同じ入力からは常に同じ仕様書・同じプロトタイプが生成される（deterministic）。だから「修正して作り直す」のではなく「構造を直して再生成する」ループが回る。
従来の手段との違い
| 手段 | 見えるもの | 弱点 |
|---|---|---|
| 要件定義書（文章） | 網羅性・契約上の記録 | 読み手によって解釈が割れる。動かして検証できない |
| 画面モックアップ | 見た目・画面の流れ | データ構造や状態遷移（承認フロー等）が見えない |
| ノーコード PoC | 動き | 本実装に引き継げず捨てられがち。作った人しか直せない |
| 見える仕様 | 構造＋挙動＋文書の3点 | 構造化の手間がかかる（DSS Studio はここを自動化する） |
作り方（DSS Studio の場合）
- ヒアリング内容を入力する。ステップ式フォームに業務語のまま入力します（ヒアリングシートのテンプレートを無料公開しています）。
- AI が構造化した結果を図表で確認・修正する。ER 図・状態遷移図・コンテキストマップで構造を見て、違っていればその場で直します。
- 仕様書と動くプロトタイプを決定的に生成する。確認した構造から、全10章の仕様書 PDF と Next.js 製の動くアプリを生成します。生成に AI は使わないため、同じ入力なら毎回同じ結果になります。
よくある質問
- Q. 要件定義書の代わりになりますか？
- 置き換えではなく前段です。見える仕様で発注者と開発者の認識を合わせ、合意した構造を正本として契約・開発に必要な文書へ落とします。DSS Studio の場合、合意した構造から全10章の仕様書 PDF を自動生成できます。
- Q. プロトタイプと何が違いますか？
- プロトタイプは見える仕様を構成する要素の1つです。見える仕様は、図表（構造）・仕様書（文書）・プロトタイプ（挙動）の3点セットであること、そして修正したら同じ内容で再生成できる再現性を持つ点が、単発で作るプロトタイプと異なります。
- Q. 発注側にはどんなメリットがありますか？
- 動くものを見て「違う」と言えるタイミングが、本実装より前に来ることです。従来は認識の齟齬に気づくのが納品前後で、手戻り費用を払う側は発注者でした。見える仕様は、その確認を作り込む前に前倒しします。
- Q. 誰がどうやって作るのですか？
- 受託開発会社や情報システム部門が、業務ヒアリングをしながら作るのが典型です。DSS Studio では、ヒアリング内容をステップ式フォームに業務語のまま入力すると、AI が構造化し、図表・仕様書・動くプロトタイプを生成します（生成そのものは AI を使わない決定的生成です）。
作りたい業務アプリを、見える仕様に。
DSS Studio はヒアリング内容から、図表・仕様書・動くプロトタイプを生成します。クローズドβ受付中。
β に応募する →