デッサンとシステムズエンジニアリング[1]に共通する「物事を形作る上での普遍的なアプローチ」をみなさんと共有する試み全４回（たぶん...）シリーズ。第３回目の今回は、明確な"狙い"（テーマやミッション）を持つこと、そして、記述に"狙い"を落とし込む際の抑えどころについて書いてみたい。
「このデッサンの中心はどこですか？」
これも、デッサンの練習会で講師の方によく聞かれる問いのひとつだ。
「はて、デッサンの中心とは？？？」
初めてそう指摘された時、私の頭はクエスチョンマークでいっぱいになった。目の前のものを正確に紙に落とし込むのがデッサンではないのか？
だが考えてみると、現実すべてを写しきるなどそもそもできようもない。自分がそんなことに本気で挑戦しようとしていたとも思えない。デッサンとは本物どおり嘘偽りなく描くものだとの思い込みを持ちながら、実際には、漠然と、でも必死に、描いては消し描いては消ししていたのだ。こうして文字にしてみると、自分の滑稽さに笑ってしまうのだが...。
さて、講師の言う「デッサンの中心」、それは、「何を表現したいか」、この記事で言うところの「狙い」だ。
では、デッサンではどのように「狙い」を表現するのか。
神は細部に宿ると言うし、表現はあらゆるディテールに及びうるものだけれど、講師の方たちのアドバイスを聞いていると、「狙い」が最も象徴的に現れるのは、「構図」と「密度」らしい。
構図とは、「構成要素」と「レイアウト」との掛け合わせで組み上げられる画面構成である[2]。「構成要素」とは描かれるアイテム（モチーフ）であり、光や影、アイテムの質感や重量感、照り返しや映り込み等の、アイテム間、または、アイテムとそれらが置かれている空間との相互作用も含まれるだろう。そして、それらをどのようにレイアウト（配置）して、狙いが最も表現されやすい画面構成にするか。それがすなわち構図を決める作業と言える。
一方の「密度」は、文字通り描写の密度だ。それこそ作品の狙いや作風にもよるのだろうけれど、基本的に、狙いを表現しようとすれば必然的に関連する箇所の描写は密になる。結果的に、表現したい箇所により視線が集まり、狙いが伝わる一枚になるという。
拙作で恐縮だが、図1は、今年の春に、箱、白い布、りんご、ワイングラスをモチーフとして、「グラスに集まる光」を表現したいと、私が初めて明確に「狙い」を定めて描いたものだ。このデッサンの狙いは、読者のみなさんに伝わるものになっているだろうか。
ではシステムズエンジニアリングにおける「狙い」とは何か。
それは、システムの「ミッション」、つまり、「何を実現したいか」だ。
ミッションをどうアーキテクチャに反映させるか。システムズエンジニアリングの研修等をしていると、どこかに正解でもあるかのような質問を受けることも少なくはないが、実際には正解なんてものはない。「アーキテクト」の由来である建築と同じように、ひとつのミッションに対してであっても、解としてのアーキテクチャはいくらでも存在しうる。
システムズエンジニアリングには多様なプロセスが含まれるが、設計段階においてシステムアーキテクト[3]は、システム内の構成要素とそれらの関係性を、前回、前々回と述べてきたように、複数の抽象度や視点で記述していく。デッサンのように1枚の絵としての「構図」を見ることはできないが、それらの記述には、構成要素とそれらの関係性とが、構造を伴って描かれることになる。
またシステムズエンジニアリングでは、構成要素をmake, buy, or reuse、つまり作るか買うかリユースするかを判断できた時点でプロセスは次に進む。そしてmake（作る）と判断された構成要素についてはさらに詳細な設計を行っていく[4]。だから、デッサン同様に、「狙い」が込められた、そのシステムに特有の領域に関する記述は、必然的に密になる。
当然ながら、「ぼんやりとしたイメージで漠然と描く」のでは、アーキテクトの仕事は満足にはできない。狙いを定めて、多様な抽象度と視点からその狙いをアーキテクチャとして記述していく。そうした行為が繰り返され磨かれて、初めてシステムに生命が宿る。
ピカソのゲルニカやモネの睡蓮、あるいはテスラのように、パワフルな世界観やブレないフィロソフィーを持つ作品やシステムの存在は圧倒的だけれど、一片のデッサンだって人の目を奪い、心を変化させる力は持つし、市井の小さなしくみだって、私たちの日々の暮らしのなかで、時に大きな意味を持つ。
規模の大小に関わらず、設計・構築するしくみのひとつひとつに明確な狙いを込め、あったかな血の通ったシステムを生み出し、育んでいくことができたなら、世界は確実に一歩豊かに、未来はより希望に満ちたものにアップデートされていくはずだ。
文：佐竹麗
イラスト：斉藤重之
●脚注●
[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] OCHABI Institute. コンセプトが伝わるデザインのロジック. 第三版. 東京: 株式会社ビー・エヌ・エヌ. 2021
[3] 「システムアーキテクト」は国家資格も存在していて日本では流通している言葉だが、実は定義が複数あるので「システムアーキテクト」という言葉がどういったことをする人を指しているかは、都度確認する必要がある。システムズエンジニアリングの国際団体INCOSEでは、Systems Engineerという呼び方をすることが多い。ここでのシステムアーキテクトはINCOSEのSystems Engineerに準じ、その実践者の意味で用いている。
[4] システムズエンジニアリングのTechnical Prosesesにおいては、各プロセスは、作るか、リユースするか、購入するかの意思決定が可能になるまで繰り返される。作る決定が下された構成要素は続くプロセスにおいてさらに詳細に設計がなされることになる。David D Walden, Garry J Roedler, and Kevin Forsberg, "INCOSE systems engineering handbook version 4: Updating the reference for practitioners" (paper presented at the INCOSE International Symposium, 2015).
●参考文献●
OCHABI Institute. コンセプトが伝わるデザインのロジック. 第三版. 東京: 株式会社ビー・エヌ・エヌ. 2021
Walden, David D, Garry J Roedler, and Kevin Forsberg. "Incose Systems Engineering Handbook Version 4: Updating the Reference for Practitioners." Paper presented at the INCOSE International Symposium, 2015.