【Aモデル録 フェーズX プログラミング基礎 思考設計編】
主軸：アプリは製造業
ここでは、
思考が壊れやすい“典型的な事故ポイント”
を、製造業の構造そのままで確認します。
結論から置きます。
設計中に製造を始めると、
その時点で「何が壊れたのか」が分からなくなる
これは技術力の問題ではありません。
工程の順序違反です。
製造業では、当たり前の前提があります。
設計図が確定してから
製造ラインを動かす
この順序は、絶対に逆にしません。
なぜなら、
設計は「考える工程」
製造は「再現する工程」
だからです。
考えながら作り始めると、
どちらの工程も成立しなくなります。
設計が固まっていない状態で、
コードを書き始めると、工程はこうなります。
書きながら仕様を決める
実装しながら要件を変える
動いたから「一旦OK」にする
一見、進んでいるように見えます。
でも製造業的に見ると、これは、
設計変更が、製造ラインの中で常時発生している状態
です。
本当にまずいのは、ここです。
設計のミスなのか
実装のミスなのか
そもそも仕様が違ったのか
切り分けができなくなる。
製造業では、
不具合が出たら
原因工程を特定し
修正し
再発防止策を入れる
これが基本です。
でも、
設計と製造が混ざっていると、
「どこを直せばいいのか」が分からない
アプリ開発では、こう言われがちです。
とりあえず作ってみよう
動かしながら考えよう
コードを書けば見えてくる
これは、
設計を省略していい理由にはなりません。
製造業で言えば、
図面を描かずに部品を削り始める
のと同じです。
たまたま合うことはあっても、
再現できません。
ここで整理します。
設計
→ 立ち止まって考える工程
→ 判断を固定する工程
製造
→ 判断を使って作る工程
→ 迷わず流す工程
この二つは、役割が真逆です。
だから、
設計中に製造を始めると、
思考が常に引き戻される
結果、
疲れる
進んでいる感がない
全体像が見えなくなる
という状態になります。
設計を飛ばして作ると、
早く動く
手応えがある
ように感じます。
でも後から、
全体を直す
意図を思い出す
仕様を書き直す
ことになり、
トータルでは確実に重くなります。
製造業的に言えば、
初期検討を省いて、
後工程で全数手直しする状態
です。
設計と製造は同時進行しない
設計は「止める工程」
製造は「流す工程」
混線すると、原因追跡ができなくなる
アプリを製造業として見るなら、
考える時間を削ると、
作る時間が必ず増える
これは、
経験則ではなく 構造の話 です。