これは Mayaa Advent Calendar 2015 の12日目です。昨日は「Mayaaの拡張ポイントベスト5」でした。

Spring Boot再挑戦記事は準備中です。今日はまだ間に合わないので、まったりトークでつなぎます！

（Mayaaアドベントカレンダーは毎日参加者を募集しています）

MayaaのBefore / After

さて、僕の発表スライドでこんな図を出したことがあります。

釣りっぽい画像ではないかと思われているかもしれませんので、今日は実際問題どうなのかを書こうと思います。

ただし、僕、エンジニア目線です。

Mayaa導入以前の孤独な日々

僕はシステム会社の一プログラマーで、ECサイトを作るときは、デザイナーさんがHTMLで書いたモックを提供してくれるので、それをJSPに埋め込む仕事をしていました。まだ大学生のアルバイトでプログラマーをしていましたが、業務と言ったらこの業務が多かったです。

当時tableレイアウト全盛なので、気が遠くなるほどネストしたtableタグやスペーサー画像を駆使したレイアウトは慣れてます。

こういう単純業務の存在は、大学生で未経験の僕にも仕事ができたチャンスであったとも言えたかもしれません。しかし、いつまでもこんなことをしているのかと思うと残念な気持ちでした。

デザイナーさんは、会社にいたりいなかったりしました。いる時もいない時も、話したことはほとんどありません。SEの方は話すのかもしれませんが、末端のプログラマーとなると、まあ、そんなものでしょう。

Mayaaを導入した日何が起きたか

そんなわけで、テンプレートエンジンが必要だとなりまして、作ります。作ってる時は、JSPからの単純移植なので、まだデザイナーさんとは話しません。

一通り移植できたところで、当時社内に一人だけいたデザイナーさんが呼び出されました。

「これは今うちではいしがみくんしか使えない技術なんだけど、これからはきみがこの技術を使ってサイトを作っていくことになるから、二人で使いやすいように整理してほしい」

という上司の言葉で、その日から1ヶ月ほどデザイナーさんと席を並べて、m:idの命名規則などの調整をする日が始まりました。

2人で全体を見渡してみると、m:idを組み込んだ人によって、名前付けのくせにばらつきがあることでした。結果として一番多く書いた僕のスタイルへ統一する方針になりました。

Excelスプレッドシートを使って旧IDから新IDにマッピング表を作って、これをもとに変換する一回限りのスクリプトを作って変換を行いました。（一撃で全部のmayaaファイルとxhtmlを書き換えるやつです。今思うとすごい勇ましいスクリプトですね(^^;）

その一方で今後作られるm:idは規則を守るようにルールも社内公開しました。その後、誰かが規則破りのm:idを作ったりすると、僕が気づくよりも前にデザイナーさんが怒ってくれたりします。

「いしがみくんのm:idが一番わかりやすいので、いしがみくんのに合わせてください！」

（僕がきちんと指導できなかったのが問題ですが、そんなこと言われたらちょっと嬉しかった！）

互いに理解する

デザイナーさんとしては初めて聞くシステムの言葉もあったでしょう。これは何か、これはどういう意味か、色々苦労されたようで、システム用語をなんとか分かるように説明する必要がありました。

この作業の中で、HTMLページの中で、デザインとはどの部分かという感覚が身につきました。例えばinput type="hidden"タグはデザインではないです。

デザイナーさんが優秀だったからかもしれませんが、m:id="なになに"という書式は抵抗なく受け入れてくれました。一方mayaaファイルはコメント一つ変えることも怖くてできないようでした。その結果、m:idの説明書一覧表が大変重要なポイントであり、ここを死守することが連携を成功させるのに必須であることがわかりました。

JavaScriptはどちらも苦手だけど力を合わせると最強になれる

最近はJavaScriptを使いこなすデザイナーさんが増えましたが、当時はjQuery一般的ではなかったので、デザイナーさんはJavaScriptを使えません。一方、僕はJavaScriptの文法はわかりますが、これを使って作れるウィジットにどんなものがあるのかは詳しくありません。

結局、いつも出だしはデザイナーさんが色々なところから一生懸命集めてきたスクリプトを組み合わせて、うまくいかない、僕が呼ばれてデバッグして解決する。。。ということの繰り返しでした。その過程で

「プログラマーすごい！」

などとも言われました。まじですか！仕事とはいえ、女性の方に、技術的なことで「すごい」なんて言われたことありません＞＜

僕からしたら、こんな色んな部品を持ってきてサイトを作れるデザイナーってすごいと思いますよ！

そして次第に話さなくなる

デザイナーさんと密に連携したのは初めの半年〜1年くらいでした。そこから先はお互いノウハウが蓄積したこともあって、ほとんど話さずに業務ができるようになってきました。

たまにJSPの案件の時などに、デザイナーさんの席に僕が足を運んで

「ここをこんな風にしたいのだけど、どんなタグの打ち方をするべきか？あと、ここにこういうアイコンを作って欲しいのだけどどこかに素材ありますか？なければお願いできますか？」

と言って、作業をしたりするので、JSPの方がむしろ共同作業をしているようです。

というか、こんな無理なお願いをしながらスイスイアイコンとか作ってくれるデザイナーってマジ神！

更に発展するとこうなった

さらに組織が大きくなると、デザインチームはデザイナーとコーダー、フロントエンドエンジニアに分かれ、開発はSEとPMとプログラマー、プログラマーも分担制となり。。。こうなってくると、もうテンプレートエンジン云々というより、もっと上位レイヤーの体制が必要になってきます。

JavaScriptの技術も最近の若い子の方がむしろできたりするのですが、ありがたいことに、未だに僕のところに、デザインチームの方々が質問に来てくれます。

そこでは、単純にスクリプティングのことよりも、システム上、これはできるのか？お客様からこう言われ、SEはこう言っているけどどうするべきか？という、全体的なことが多いようです。

なるほど、これはまだ若いエンジニアにはできない。

デザイナー脳とエンジニア脳のどちらも必要

これまで、いろんなデザイナーさんの質問に答えてきた経験から、ある傾向があることに気づきました。

（これは一方的な視点なので間違っていたら申し訳ないですが。）

デザイナーさんは、デザインという、結果からスタートして、手段へブレークダウンしていきます。エンジニアは技術という手段からスタートして結果という目的へ向かっていきます。

その結果、何が起こるかというと、デザイナーさんはものすごい色んなことができる一方、罠にハマるとどうしたら良いのかわからなくなってしまうことが多いように見えます。

一方エンジニア肌の人は、問題ごとを細かく切り分け、デバッグし、テストし、解決することが得意です。そのため、僕はjQueryなんとかを使って画面の表現を作ることはできませんし、デザイナーさんから質問を受けるライブラリはいつも初めて見るものばかりでしたが、最終的に全て解決することができたし、時にはライブラリにパッチを作ってGitHubでfork/pushすることもありました。

これがデザイナーとエンジニアの相性が良いと言われる所以なのかなとも思います。

まとめ

一人で両方できるのがベストなのかもしれません。

しかし、一人だけでは大きな仕事はできませんから、複数人でコラボしたほうが断然大きな仕事ができます。それにあたって、デザイナーとエンジニアというのは、良い役割分担だと思います。

両者の連携を支えるのに、テンプレートエンジンはまだまだ重要だと思いますし、そういう方向性で今後も進化し続けなければならないと思います。