常に分岐している

職業エンジニアでなくても、時にはちょっとしたコードやスクリプトを書くことがあると思う

そのコードが期待通り動作しない場合、対処が2種類に分岐する

1. 目の前のものを直す

そのまま

リファレンスを再読したりする

エラーメッセージが出る＝直すべきものが明確

2. もっといいやり方がないか探る

1のやり方がよくなかったので、余計な手間が発生している可能性

1を直すよりも簡単で早い場合がある

「依然として1で正しい」が平等に存在する

この1・2が常に両方発動しているのが、よりよいものを作るのに必要

うっすらとでもいいので

特定のやり方を動的に変更しづらい

ラフ→線画→色塗り→...のように定型作業になっているとき

前段階が完璧であることが次段階の開始条件になりやすい

「○○の描き方」に収まる

工業製品なら、工程に従うことが求められるが、その絵はどうなのか

コードは塊の中の部分

全体（プロダクト、実行ファイル）の完成よりも前段階、過程における模索をする

描き方の模索自体はみんなやっているだろうけど、判断のために毎回1枚描き上げる必要がある

効率に限界がある

試行回数、判定回数を増やすために速く描くなら、それは常に手段である

目的化することが多い

過程が失われやすい

「速く描くという目的」は、撮影、生成で満たせる

対処方法が1種類しか存在しない状況であるから、その中でバッティングする

根本的な、完成品で判断する / される風潮が後押ししている