【Aモデル録 フェーズX プログラミング基礎 思考設計編】
主軸：アプリは製造業
ここは、第3章の中でもかなり重要な分岐点です。
理由は単純で、
多くの人がここで 「仕様」という言葉を誤認したまま作っている から。
仕様は「やりたいこと」ではありません。
仕様は「守らなければならない条件」です。
この時点で
「え？」となったら、今日は正解です。
多くの現場では、こういうものが混ざっています。
ユーザーの要望
自分のやりたいこと
思いついた改善案
将来こうなったらいいな、という希望
これらをまとめて
「仕様」 と呼んでしまっている。
でも、製造業ではこれは あり得ません。
要求：
「こうしてほしい」「これが欲しい」
仕様：
「最低限、これを満たしていなければ出荷不可」
要求は変わります。
仕様は 固定されます。
ここが第3章の核心につながります。
製造業では、
試作で壊す場所
改良で触る場所
実験で遊ぶ場所
は、最初から 決まっています。
そして同時に、
絶対に壊してはいけない場所
も、明確に定義されます。
それが 仕様 です。
入力できる形式
出力の意味
データの整合性
操作の前提条件
これらは、
書きやすいかどうか
実装が楽かどうか
思いつきで変えたいかどうか
とは 一切関係ない。
要求は感情と一緒に動きます。
やっぱりこうしたい
こっちの方が良さそう
思ったより違和感がある
要求は、製造中に変わる前提です。
それを仕様にしてしまうと、
仕様が揺れる
守るべき基準が消える
壊していい場所が分からなくなる
結果、
実装中に、どこを直しているのか分からなくなる
これが
「仕様変更地獄」
「作り直しループ」
「モチベーション崩壊」
の正体。
製造業での仕様は、
判断に迷ったとき
仕様書に立ち返る
それを満たしているかだけを見る
という 冷たい基準です。
感情は入りません。
仕様は、作る人を守るための柵
でもある。
コードを書く前に、こう考えられるか。
これは要求か？
それとも仕様か？
これは壊していい場所か？
それとも固定すべき場所か？
この問いが出てくるようになったら、
第3章を進む準備は整っています。
次は、
仕様が揺れたとき、
なぜ全工程が不安定になるのか。
この章で扱う
「固定すべきもの」と「可変でいいもの」
その入口に入ります。