具体を重ね、試行錯誤する

デッサンとシステムズエンジニアリング[1]に共通する「物事を形作る上での普遍的なアプローチ」について考察するシリーズの第4回。今回は、シリーズの締めくくりとして、「具体による試行錯誤」について考えてみたい。


「試してないなら、考えていないのと同じことだよ」

コミュニティのみんなで、ちょっと背伸びをして石膏像を描いた時のことである。講師の方にそう言われて、私は思わず笑ってしまった。その指摘が、あまりに的を射たものだったから。

その時私は、石膏像の立体感が出せずに苦労していた。苦労していたというより、正直途方に暮れていた。なぜって、白い紙の上に、白い石膏像を黒い鉛筆で描くのだ。そんなことが、デッサン初心者の私に簡単なわけがない。おまけに手前にせり出したその肩と二の腕は、やわらやかな光に照らされ白く鈍く輝いている。鉛筆で書き込めそうな影などひとつも見当たらない。こんな真っ白い物体を、白い紙の上にどう立体的に描けと言うのか......?

案の定講師の先生には、「二の腕の立体感が捉えられていない」と指摘を受け、私はつい、「この辺に影が入るといいのかなとも思ったんですけど...」と言い訳のように言ってしまった。そうしたら言われたのだ。「そう思ったなら試してみた? 試してないなら、考えていないのと同じことだよ」、と。

そうなのだ。手探りでも描いてみて、ダメなら消せばよかったのだ。影ひとつない白い物体を前に頭を真っ白にしている暇があったのなら。だってデッサンは、描いて消すことができるのだから。描いて消して試行錯誤することで、よりよい表現を見出すことができるのだから...。

デッサンやシステムズエンジニアリングにとどまらず、議論や思考など日常の様々な場面において、プロセスごとのアウトプットを「具体」に落とし込んでおくことの重要性には、おそらく多くの方が首肯されるのではないだろうか。

私自身描き続ける中で痛切に感じているのは、見て触れて改善できる「具体」を常に携えておくというシンプルな行為の積み重ねの、ずっしりとした重さであり底力だ。

デッサンもシステムズエンジニアリングも、記述することがすなわちプロセスを前進させることであり、各プロセスのアウトプットは、自ずと、目で見て触れられる具体となる。そうした具体を持つからこそ、デッサンもアーキテクチャも、他者と共有することができるし、分析して改善点を見出し、試行錯誤を重ねることができる[2]。抽象から具象に至るまで、必要な密度で対象を描ききることができる。対象や、描き手自身の意思に対する理解を深め続けることができるし、適切な判断がサポートされ続ける。

もちろん、「具体」であれば何でもいいわけではない。少なくともここで紹介したような、抽象度のコントロール(第1回)や視点によるプロセスの分解(第2回)、明確なテーマやミッションをすべてのプロセスに反映させること(第3回)は必須となるだろう。これらのポイントが抑えられているからこそ、具体による試行錯誤が、単なる右往左往や暗中模索で終わらずに、「狙い」を実現するための有効なプロセスとなる。たとえ、その過程に多くの紆余曲折があったとしても。

さらに言えば、これらは「物事を形作る上での普遍的なアプローチ」だから、適用先はデッサンやシステムズエンジニアリングに留らない。たとえば議論の場においても、「議論の目的が見えないな」と思ったら、一度詳細に捉われるのをやめて、ちょっと引いて全体を見た上で議論の位置づけや目的を確認することができるし、「どうも議論が噛み合っていないな」と思ったら、ひとつの視点を選んで固定して議論するよう調整することができる。思考が堂々巡りをしているように感じたら、とりあえず文字にして、できれば構造をもたせて整理してみるといい(今回)。それだけで、それまで見えていなかった景色が見えてくるはずだ。

さて、ここまで4回にわたり述べてきた、デッサンとシステムズエンジニアリングに共通する「物事を形作る上での普遍的なアプローチ」。ともすると無機的で退屈なものと捉えられてしまいがちなシステムズエンジニアリングが持つ力と魅力とをお伝えできればと、私なりにまさに試行錯誤を重ねてここまで書いてきた。

こんなささやかな記事でさえ、表現したいことを伝わるように表現するのは至難の技で、出口の見えなくなるような瞬間が幾度となくあった。試行錯誤が奏功し、読者のみなさんに何かしら得るものがあったなら、本当にうれしい。

"デッサンが上手な人と私のような素人との間には、無数の点において歴然とした差がある。"

第1回で述べた。このシリーズで考察してきたような「プロセスの質」が重要なのはもちろんだが、優れた描き手とそうでない者の差は、当然ながらそれだけではない。各プロセスにおけるアウトプットの質、最後にはそれが、デッサンそのもの、アーキテクチャそのものの質を決める。

これからも、小さなプロセスひとつひとつの質を高めていけるよう、私自身日々格闘していきたいと思う。時々は、デッサンも楽しみ続けながら。

文:佐竹麗
イラスト:斉藤重之


●脚注●
[1] シリーズ初回の「全体をぼんやりと見る」でも述べとおり、システムズエンジニアリング(Systems Engineering)とは、「transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.」(INCOSE,2021)と定義される方法論で、日本語では、「システムの実現を成功させることができる複数の専分野にまたがるアプローチおよび手段 」(最新システムエンジニアリング情報館,2021)と訳される。慶應大学大学院システムデザイン・マネジメント研究科では、仕組みづくりの方法論としてその基礎を学ぶ。
[2]システムズ・エンジニアリングでは、このようにプロセス間を行きつ戻りつして設計に磨きをかけていくことを、iterationやreccursionと呼んでいる。INCOSE systems engineering handbook version 4, 25, (David D Walden, Garry J Roedler, and Kevin Forsberg, 2015).

●参考文献●
INCOSE. Systems Engineering Handbook Forth Edition A Guide for System Life Cycle Processes and Activities. WILEY, 2015.