プログラムにおける設計と、イラスト制作におけるラフ構築の、類似性についての思考

概要

「設計(プログラミング) ≒ ラフ(イラスト)」という関係性の構築ができそう。
設計(もしくはラフ)をしっかり行わないと、手痛い品質低下が見込まれる。

前提

プログラミングとイラストの類似性について述べるために前提を設定します。
プログラミング - Unity+C#でのゲーム開発
イラスト - キャラクターを主体とした1枚絵(or立ち絵)作成

上記前提をベースに話の展開を行いたいと思います。

実装設計 ≒ ラフ構築？

開発では新規実装を行うときに、UMLを用いて設計を行います。
のちレビューを貰って詰めを行った後に実装をします。
これにより手を動かしている最中にミスに気づき、手痛い技術的負債を少なする狙いがあります。

エンジニア的には「設計をしっかり詰めて、あとは書くだけ」だと手戻り少なく結果的に短い時間で高い品質の実装が行える気がします。

「設計フェーズ ≒ ラフ構築」
これは、最近「イラスト描いても、個人的に心地よい絵が描けたり描けなかったりするなぁ」という課題があったのですが、これは「ラフ(実装における設計)の練りが低いためにムラが出る」のではないか？という仮説から端を発しています。

正直本職のデザイナーではないのでビジネス世界のイラストワークフローは知らないのですが、「ラフをしっかり詰めて、あとは描くだけ」みたいな状態の方がスムーズに物事が運ぶと体感的に予測できます。
事実ラフ段階で構築が甘いと、そのまま線画・着彩しても確かに上手く描けた試しがありません。

各分野での構築フロー

エンジニアリングとイラスト制作のフローをちょっと書き出して、類似点を洗ってみたいと思います。

プログラミング：
UML設計初稿作成　→　レビュー会　→　修正　→　実装

イラスト：
初稿ラフ作成　→　レビュー　→　修正稿作成　→　清書

レビューと修正は1回で終わる可能性もありますし、複数回行う想定もあります。(今回の記述は1回だけの例です)

これ、思考の共通化できそうですね。

叩きの作成　→　他人の目を用いた抜け漏れ探し　→　修正　→　本構築

になりそうです。

コンセプトの設定をお忘れなく

もちろんコンセプト(≒評価軸)が無ければ軸がブレて、まともなレビューになりません。
各職のコンセプト例は以下があります。(デザインは憶測です、すいません)

プログラム：
仕様書の要件をすべて満たす
エラーケースを網羅する
独立性を上げたい
仕様変更によるコード変更量少なくしたい
etc...

イラスト：
要件をすべて満たす
世界観に合わせる
想定クオリティを満たす(想定クオリティはチェックリストがある前提)
キャラを全面的に見せたい
物語性を全面的に見せたい
etc...

毎度高い期待値で良い絵を描くには？

「ラフをしっかり詰める」

ラフと言っても、大ラフ、詳細ラフ、着彩ラフなど種類があるので自分が描きたいものを意識しながら相性の良いラフを選択すると良いかもですね。

ラフ選択例：
構図を詰めたい　→　大ラフ(構図分かる程度に)
完成の色バランスを詰めたい　→　着彩ラフ

余談(イラストにおける資料活用のタイミング)

プログラム実装の時に「APIリファレンス」などの資料を用いるのは実装フェーズ(設計段階の時はアーキテクチャルール確認を、たまににする程度)。
(上記から転じて)イラストの「資料を用意して、活用する」は、ラフ構築が終わった後、清書や詳細を描くときに初めて利用する？

と言っても詳細ラフ作成の場合は、結構資料見ないといけない気がする…。
そこんところどうなんだろ…。