【Aモデル録 フェーズX プログラミング基礎 思考設計編】
主軸：アプリは製造業
この回は、
コードを書ける人ほど混線しやすいポイントです。
今やっている変更は、
ロジック変更か？
それとも仕様変更か？
これを感覚ではなく、工程として判別できるようにします。
ロジック変更
→ 製造方法の変更
→ 実装工程の話
→ いくらでもやってよい
仕様変更
→ 製品定義の変更
→ 設計工程に戻る話
→ 勝手にやってはいけない
同じ「コード変更」でも、属する工程が違う。
手順を変える
処理順を入れ替える
アルゴリズムを改善する
無駄を削る
速く・安全にする
👉 同じ製品を、より良く作る方法
製品は変わっていない。
できることが増える／減る
振る舞いが変わる
境界条件が変わる
入力や出力の意味が変わる
👉 製品そのものが別物になる
これはもう、製造じゃない。
ここ、超重要。
「ちょっとロジック直しただけです」
例外の扱いを変えた
条件分岐の意味を変えた
仕様に書いてない挙動を追加した
👉 それ、仕様変更です。
次の問いを使ってください。
この変更で、
仕様書に書いてある文章は
1文字も変わらないか？
変わらない → ロジック変更
変わる → 仕様変更
これが、工程判断の物差し。
理由は単純。
コード＝全部実装
実装＝全部ロジック
ロジック＝自由に触っていい
こう一段に潰して考えているから。
でも実際は、
仕様（固定）
↓
構造（固定）
↓
ロジック（可変）
↓
コード（可変）
ロジックは「可変」だけど、自由ではない。
上の工程を侵した瞬間、仕様変更になる。
次の言葉が頭に浮かんだら、黄色信号。
「この方が使いやすい気がする」
「仕様、ちょっと古いよね」
「ついでにこれも直しとこう」
これは全部、設計工程の言葉。
実装工程で出てきた時点で、
工程が混線しています。
コードを変える前に、必ず一度止まって聞く。
これは
作り方を変えているのか
製品を変えているのか
この区別が瞬時につくようになると、
「暴走しない実装者」になります。
次は、
この判断をさらに安定させるために、
「仕様を触っていいタイミング」と
「絶対に触ってはいけないタイミング」
を整理します。