【Aモデル録 フェーズX プログラミング基礎 思考設計編】
主軸：アプリは製造業
ここでは、
なぜ現場が地獄になるのか を、感覚ではなく構造で扱います。
仕様が揺れた瞬間、
すべての工程は「再計算」を強制される
これが起きているとき、
人は「忙しい」「混乱している」と感じますが、
実際に起きているのは 工程破壊 です。
想像してください。
製品のサイズが途中で変わる
材質が作業中に変わる
出荷先の条件が後出しで追加される
これ、どうなるか。
設計図：使えない
治具：合わない
部品：在庫がゴミになる
検品基準：意味を失う
誰が悪いか分からないまま、現場だけが疲弊します。
仕様が揺れると、コードではこう見えます。
さっき書いた処理が前提ごと崩れる
名前・構造・責務がズレ始める
「応急処置コード」が増殖する
結果、
動いているのに、直すのが怖い
という状態になります。
これは技術力の問題ではありません。
工程が壊れているだけです。
仕様は、製造業でいう 基準点 です。
設計は、仕様を前提に引かれる
実装は、設計を前提に行われる
テストは、仕様を基準に判定される
つまり、
仕様は、全工程の共通座標
ここが動くと、
全員が「今どこを作ってるのか」分からなくなります。
仕様が揺れた現場では、こんな判断が出ます。
「とりあえず合わせよう」
「後で直せばいいか」
「今回は例外で」
これ、怠慢ではありません。
基準が消えたため、
判断が感情と勢いに委ねられている状態
製造業的には、
すでに異常状態です。
コードを書く前に、
次の問いが出てくるかを確認してください。
これは「仕様変更」か？
それとも「実装の工夫」で吸収できるか？
今、動かしているのは基準点か、末端か？
この問いが自然に出てくるなら、
この先の理解へ進む準備は整っています。
仕様が揺れると、工程が壊れる
工程が壊れると、人の判断が壊れる
現場の疲弊は、努力不足ではない
仕様は「決めるため」にあるのではない
工程を安定させるためにある
次は、
「じゃあ、なぜそんなに仕様を固定するのか？」
その理由を、ちゃんと説明します。