【Aモデル録 フェーズX プログラミング基礎 思考設計編】
ここで扱うのは、
「なぜ、コードを書いている最中に仕様を変えたくなるのか」
という現象の正体です。
これは意志の弱さでも、設計力不足でもありません。
製造業として見ると、かなり明確な原因があります。
コーディング中に仕様変更したくなるのは、
仕様が固まっていないのに、
製造工程に入ってしまったサイン
です。
コードを書いている最中に起きる違和感は、
「ひらめき」ではなく、工程異常の警告です。
製造業で考えてみます。
設計図を見ながら部品を組み立てている
途中で作業員がこう言い出す
「これ、寸法ちょっと変えた方がよくない？」
この瞬間に起きているのは、
改善提案
ではなく
設計不確定のまま製造している事故
です。
本来この判断は、
設計工程
仕様確定工程
で終わっていなければならない。
アプリでも全く同じです。
コーディング中に出てくる思考は、だいたいこれ。
「この画面、やっぱ要らないかも」
「この動き、別の方が自然では？」
「ここで入力させるの、面倒かも」
これらはすべて、
仕様の未確定部分が、
製造工程に流れ込んできている状態
です。
よくある誤解。
「コードを書き始めたから、
本質が見えた」
実際は逆。
だけです。
製造業的に言うなら、
試作品を組み立てたことで、
設計の穴が見えただけ
この衝動の正体は、
創造性
センス
成長の証
ではありません。
設計工程で終わらせるべき思考が、
製造工程まで残っていた
ただそれだけ。
だから、
正しく設計されていれば
コーディング中に
仕様を変えたくならない
ここが重要。
コーディング中に、
「まあ、ここ直しちゃおう」
とやると、
設計と製造が混線する
どこからが仕様で、どこからが実装か分からなくなる
後から 判断理由を追えなくなる
これは、
製造ラインで設計図を手書き修正する行為
と同じです。
コーディング中に仕様変更したくなったら、
製造を止める
設計工程に戻す
仕様として書き直す
仕様が確定してから再開する
これ以外の対処はありません。
コーディング中の仕様変更欲求は異常検知
「ひらめいた」のではなく「遅れて見えただけ」
設計と製造は混ぜない
仕様変更は必ず設計工程で行う
アプリを製造業として見るなら、
仕様は設計図
コードは組立作業
ひらめきは検査結果
この役割は、
工程を越えてはいけません。