要件定義書が読めない問題は「動くもの」で潰せる
— 書類で合意しない。プロトタイプで“ズレ”を最短で消す
概要
システム開発でよくある悲劇がこれです。
- 要件定義書を見せられる
- なんとなく「はい」と言う
- 半年後、出来上がったものが“思ってたのと違う”
- 改修地獄が始まる
社長が悪いわけではありません。
要件定義書は、発注側が理解しにくい表現で書かれがちだからです。
私（伊藤翔太）は、この問題を“書類の改善”で解決しようとはしません。
結論は、動くもの（プロトタイプ）を最速で出して、ズレを潰す。これです。
なぜ要件定義書は「分かりにくい」のか
1) 人間は文章より“体験”で理解する
「画面遷移」「入力」「例外」「通知」など、システムは体験の集合です。
文章で理解するのは、構造上ムリがある。
社長が求めているのはこういうことです。
- その画面、現場は3秒で使えるのか？
- 例外が出たとき、誰が何を見るのか？
- 抜け漏れをどう防ぐのか？
- “手間が増える”ポイントはどこか？
これ、文章だと見えません。
実際に触ると、一発で分かります。
2) 発注側の想像と、開発側の解釈がズレる
社長は「これぐらい当然できる」と思っている。
開発側は「そこは要件に書いてない」と解釈する。
このズレが一番高くつきます。
そしてズレは、納品後に発覚するほど修正コストが上がります。
「動くもの」で潰すとはどういうことか
要件定義書を捨てる、という話ではありません。
要件定義書は作る。残す。納品もする。
ただし、合意の中心を“書類”に置かない。
合意の中心を「動くもの」に置く
→ だから、ズレが最小になる
→ 現場導入がスムーズになる
→ 改修地獄を避けられる
私がやる進め方（30〜60分 → 3日 → 1〜2ヶ月）
株式会社IIWAYO（2026年1月設立）の基本スタイルはこうです。
1) 30〜60分の面談で聞くのは「機能」より「成果」
私が最初に聞くのは、画面や機能ではありません。
- 最終ゴールは何か（売上・利益・組織・Exit）
- 何ができれば事業が伸びるか
- 現場の詰まりはどこか
- 現在使っているツールは何か（スプレッドシート/フォーム/チャット等）
- 絶対に変えたくないルールは何か
これが揃うと、プロトタイプが作れます。
2) 3日以内に「だいたいこういう感じ」を出す
ここで重要なのは完成度ではなく、認識合わせの速度です。
- 画面の流れ
- 役割（社長/店長/スタッフ）の違い
- 通知の行き先
- 入力の少なさ
- 例外時の確認フロー
“触る”ことで、社長も現場も一気に腹落ちします。
3) 1〜2ヶ月で現場導入レベルまで磨く
システムは細部です。
本当に使えるかどうかは、細かい挙動が決めます。
- 入力の必須を最小化する
- 選択式・音声入力で迷わせない
- 例外時だけ責任者に飛ばす
- 現場に「AI導入」と言わない（※これは別記事で詳しく書きます）
この“磨き”までやって、初めて導入が成功します。
「要件定義書が読めない」社長がやりがちな失敗3つ
失敗1：分からないのに「はい」と言う
分からないことを認めるのは悪いことじゃありません。
ただ、分からないまま進むと、後で必ず痛い目にあいます。
失敗2：現場を巻き込まずに進める
社長だけで合意すると、現場導線が死にます。
だから私は、早い段階で現場の人の声を取りにいきます（短時間で十分）。
失敗3：「完成＝導入」と勘違いする
現場が回るには、運用設計が必要です。
“作った”だけでは回りません。
じゃあ社長は何を準備すればいいのか？
難しい準備はいりません。
まずはこれだけでOKです。
A4一枚の棚卸しテンプレ
- この業務は誰がやっているか？
- いつ発生するか？
- 何を入力しているか？
- どこに記録しているか？
- どこでミス/漏れが起きるか？
ここが見えると、プロトタイプは一気に早くなります。
私の結論：書類で合意しない。体験で合意する。
要件定義書は、開発側の都合で必要な書類です。
社長にとって大事なのは、そこではありません。
- 現場で使われるか
- ミスが減るか
- スピードが上がるか
- 収益が伸びるか
そのために最短なのは、動くものです。
次回予告
次は「AI導入」と言った瞬間に失敗する理由と、
現場がAI頼りにならない運用設計について書きます。
“AIを見せない”は、単なるマーケティングではなく、
現場導入の成功率を上げるための設計思想です。