エンジニアにとってデザインとは思考することである

エンジニアとデザインは、一見、無関係のように思うかもしれないけれど無くてならない関係を持っているし、その関係も密接しているのです。では、そのデザインがエンジニアのどこで接するかと言えば、もちろん、すべての工程になるのです。エンジニアがかかわるすべての工程にデザインがかかわるといってももしかしたらぴんと来ないかもしれないのでよりわかりやすい工程名称を挙げれば、ズバリ、設計工程と言えば

「なんだ。そんなの知ってた。」

と言うかもしれないけれど、でも、製造工程だって、試験工程だって、デザインはついて回ってくるのです。

思考しないエンジニアは伝書鳩でしかない
古臭い言い方だけど、ウォーターフォールだろうがアジャイルのスクラムだろうが、エンジニアがプロセスの中でインプット情報を得て、WBSのアウトプットを生むためにはエンジニア自身がインプットのデータをアウトプットの形式に加工しなければならないわけです。入ってきたものを出しているだけの伝書鳩なのだとしたら、その仕事は鳩にやらせておけばよくわざわざエンジニアがやる必要はないんですよね。

そのプロセスの中での仕事がデザインそのものなんですね。そのデザインの仕事の粒度は仕事によってサイズが大なり小なりあるかもしれないけれど、それでもやっぱりどのように加工するかはデザインして加工するための設計図面を書かなければならないわけです。

その設計図面もウォーターフォールだとたくさんの様式を使って表現するかもしれないし、アジャイルのスクラムならUMLかもしれない。試験工程なら試験設計かもしれない。その加工するプロセスを表現する方法はそのプロジェクトごとにさまざまなのです。

デザインが思考である理由
設計がデザインであるというのはなぜかと言えば、それは、そのプロセスの中でエンジニアが加工するための図面であるということは先に記したけれど、デザインが思考である理由はなぜなのか。

それはエンジニアがプロセスの中において、プロセスを取り巻く制約や前提事項を加味したうえで考え出したアウトプットを構成する骨格だから、なのだと思うのです。骨格は、どのように配置され、どのように動くから、そうしたエンジニアの想いが、そのプロセスのアウトプットで求められるものを実現するか、それを表現しているから。

そう、エンジニアが考えた想いが形となって表れているから、です。ただ、そのデザイン力が弱いエンジニアが実際には以外に多くて困るんですね。

デザインできないエンジニア
ところで、ワタシがファッション通信を観ていたときの感覚では、被服のオートクチュールもプレタポルテでもデザイナーがザックリしたイメージスケッチを作って、それを職人のお針子さんたちが縫製すると思っています。そのデザイナーのようにざっくりした方向性を決めるようなデザインをできないエンジニアが多くて多くて。

「いや、それはお前の周りだけだよ。特殊だよ。」

なんていわれちゃうと悲しいですけど。エンジニアにとって、システムを実現するコードを書くことはエンジニアリングの観点からとても大事なことですが、全体の方向性をデザインすることだってとても大事なことです。それを説明すると聞いているエンジニアは「わかりました。」と言うのですがその割には何度もチャレンジしても実現するコードは実装できても、その土台となる方向性をデザインするところで間違えちゃうので、実装するコードをお披露目してから間違いに気づいてそれを直すという遠回りをすることになるんです。そんなループを何とも見ていると、この人「自動人形なのではないか？」なんて心配せずにはいられないです。

デザインを訓練するには
そういったエンジニアは実装する力はあるのです。だから、方向性を示すような設計のデザインをできるようになれば、それはもう、古臭い言い方ですが鬼に金棒です。鬼ぃちゃんと幼女から呼んでもらること請け合いです。

鬼ぃちゃんと呼んでもらうためにも、その力を付けたいところですが意外と簡単な方法で訓練できます。

“A3の紙に頭の中で思っていることを手書きで描く”

これを続けることです。誰が観てようが気にせず、書き損じたら何度も。広いA3を使うのがいいです。余白を十分配置して。細いペンよりは中くらいのサインペンなどの方がいいです。万年筆でも中くらい以上の太い方がいいです。かっこうは気にせず、兎に角、頭の中に入っていることをワーっと出してしまう。

描くのだって、自由に描く。何らかのお作法があっても自由に。お作法に足を取られてスピードが落ちるくらいなら、それは後にして、清書のときに。フリーハンドでたくさん書いたうちの100枚の内の1つでもしっくりするものがあればいいんです。

頭の中で思いついた思考をデザインとして、設計図面として表現しよう。