デザイナーとエンジニア、ついでにプログラマー
エンジニアとITエンジニアとプログラマー
ITエンジニアはエンジニアの一部に過ぎない
ITエンジニア（情報処理技術者、あるいはより狭義にWebエンジニア）のことを単に「エンジニア」という言論をみると少なからず違和感を持つ。ITに限らず各分野にエンジニアは存在していて、彼らへの敬意が無いかのように感じられるからかもしれない。
単に省略しているかその論者の世界が狭いというだけかのどちらかだろうから、特にどうということもないといえばない。
プログラマーはエンジニアではない
ただ、プログラマーとエンジニアを混同するような言説には断じて違う、と思ってしまう。
エンジニアは総合的な問題解決を行う役割を担うものであり、プログラマはプログラミングの作業をする役割だ。
もちろんプログラマーを担当できるエンジニア（この場合、ITもしくはソフトウェアエンジニア）もいれば、エンジニアリングの能力はあるがその時その場所では専任でプログラムだけやっているという者もいるだろう。
しかし、役割としてのそれらは分けて論じるべきだ。混同したりプログラマという言葉を拡大解釈するメリットは全くない。
そういえば、下記のブクマしたが、この記事にはエンジニアは一人も登場していない。QCDの概念がなく単にプログラミングする人、はエンジニアではない。
【エンジニアは神だと思う】エンジニアの「できる」と、非エンジニアの「できる」は違う | HRナビ
全くプロマネできない自称ディレクターというのが存在するのだな、という衝撃。誰もプロマネできないプロジェクトが失敗しても何の不思議もない。それ以前に責任の所在が不明確だから組織の体をなしてない。
エンジニアとデザイナー
どちらも本質的には課題解決者という意味では同じ
エンジニア（この場合、広義のエンジニア）もデザイナ（同じく広義の）も共にデザイン・設計をする人で本質的には違いがない。
デザイン・設計というのは課題解決である。
システム×デザイン思考で世界を変える 慶應SDM「イノベーションのつくり方」
- 作者: 前野隆司,保井俊之,白坂成功,富田欣和,石橋金徳,岩田徹,八木田寛之
- 出版社/メーカー: 日経BP社
- 発売日: 2014/03/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
それぞれ課題解決のアプローチが違う
エンジニアの課題解決のアプローチ
多くの場合、要件をブレイクダウンしていくというものだ。
そして最も大事な使命でありエンジニアのエンジニアたる所以はQCDを適切に落とし込むことだ。
ソフトウェアなら課題をブレイクダウンしてプログラムが書けるようになるまで細かくして行く。
細切れにした作業は工数として見積もれ、それがほぼコストになりガントチャート等で納期が割り出せる。（簡単には行かないが、、、）
1回の作業でQCDが丸く収まることはほとんどない。
エンジニアは要件を出す（企画などの）サイドに「優先度決めてよ」という。
要件の項目に優先度をつけて、Qを落とすことでCDも落としてバランスさせることができるためだ。
デザイナの課題解決のアプローチ
デザイナが解決すべき領域の場合、要件が明確でないということも多い。
そのため課題解決能力以上に課題発見能力が必要になる。
ところで、エンジニアの場合、要件は満たしてるんだからこれで良いじゃん、となりがち。なのでヘボデザインを放っておく、ということになる。
デザイナは、プロダクトとしての要件を満足し、プロモーションやプレースなどの領域も考慮する必要がある。つまりマーケティングの領域もオーバーラップしてくる。
課題発見までして解決すべき課題を肥大化させた後に、しかしデザイナー自身がそれを解決しなければならない。
そこで行われるのはそれぞれの課題に対して個別にデザインの理屈・方法論・パターンを当てはめてそれらを寄せ集めるようなエンジニアのブレークダウン的なアプローチではなく、それらの問題を一つの大きな問題に構造化するアプローチを取る。
エンジニアリングが発散思考的であるのに対して、デザインは収束思考的だ。
そこでは結論が先に出る。それは構造化された問題を解く「たった一つの方法」になる。
左脳的な論理の力ではなく、右脳的な直感の力による。（あくまで比喩）
直感といっても知識がない状態で出る結論は後で見ても理屈に合わない。
知識が身になっている状態で問題が構造的に理解できていてはじめて後になって理屈に照らしても概ね正しいという答えが得られる。
両方できるハイブリッド
二つのアプローチを述べたが普通はどちらかが得意という人がほとんどだろう。
しかし、先ほどは極端に書いたが100%どちらかということはなくて、両方の思考・アプローチが必要だし、誰でも多少は実行しているものだ。
まれに両方得意なハイブリッド型の人がいるが、稀だからいないものと思って良いと思う。
うまく分担すべき
もちろん両方できたらその方が良い。しかし、組織としてみたとき、無理に目指すことはないだろう。非効率だ。
大抵は、うまく分担する方が良い。
そのとき、先に述べたようなアプローチの違いは知っておくと良い。
エンジニアはどのようなスキルを身につけるべきか
デザイナーは大きな答え、解決策を提示できるが必ずしもQCDが丸く収まるということはない。
そのデザインの意図をくんでQCDを収めるのはエンジニアの役割だ。
デザイナー（あるいは企画、営業）が無茶な要件を出す、と怒ったりするのはある意味でエンジニアの役割を放棄している。
最適なQCDを提示するのが、それができるのがエンジニアだから。
とは言え、QCDを同時に満足させようとすると要件と工数を落としたらお終いというわけにはなかなかいかずにデザイナ的な思考も必要であったりもする。
あれ、じゃあ、やっぱり必要ということになるね。
でも、あんまり言い出すと、企画ができた方が良いし、マーケティング、経営戦略、財務、プログラミングもテストも品質保証、品質工学、、、
それぞれできた方が良い。
何度も繰り返すがエンジニアの本分はQCDの管理だ。
企画もデザイナも研究者もプログラマーも誰もQCDのことを気にしてはくれない。
エンジニアだけがそれを担うんだ。
プラスアルファはあった方が良いが、QCDを収める本分を全うした上で好きにすれば良いと思う。
デザインは一つの道にしか過ぎないけど、広い意味でのデザイン思考は色々な場面で役に立つというのは確かだろうと思う。
本記事を書くきっかけ
