仕事の愚痴、あるいはフロントエンジニアの必要性について

当記事は100%単なる個人的な愚痴です。

弊社にはフロントエンドエンジニアが居ない。
社内にいるのは「デザイナー」と「バックエンド寄りのフルスタックエンジニア」(※「何でもできる人」ではなく「何でもやらされる人」)である。フルスタックエンジニア(笑)の中にインフラ整備が得意な人と設計が得意な人と、私のようにちょっとデザイン方面(SCSSとか)をかじったような人間がいる。私だってデザインが得意だとは言えないけど、文字色が違う(#222と#444)ことに気がついて驚かれたりしたので、バックエンドエンジニアに比べたら得意な方なのだろう、たぶん。

そもそも論としてエンジニアがデザイナーを軽視しているのはよくあることだ。今の上司もデザイナーの仕事を「見てくれの調整」としか思っていないらしい。それはそれでひどい話だ。どうして自分にできない仕事を軽視するのか?といつも思うが、何のことはない、「何をしているのか知らないし知ろうともしないしその自覚もない」のだ。愚かなり。そんなだから禿げるのだ。そんなに塩タブレット食べてると死ぬぞ。
まあそれは置いておいて、何がアレかっていうと、「エンジニアの仕事がわかるデザイナー」「デザイナーの仕事がわかるエンジニア」がほぼ存在しないため、その間にものすごい軋轢、断崖絶壁が発生してしまっている。
実際よくあることだとは思う。HTMLにスタイル直書きされたうえ!importantとか付けられてデザイナーがキレるとか、きれいなだけの実装できないデザインを作られた上にエンジニアの前に顧客に確認取られてしまって現場が火を噴くとか。円を七分割したメニューをユーザーのクリックに合わせて回せ(選択したものが上に来る)と言われたときには私だって頭を抱えた。
あれあのときは「どうせえっちゅうんじゃデザイナーさんは割り算もできないのか」と思ったけど、今思えば配列に回転後の画像角度突っ込んで固定しちゃえばよかったな。律儀に毎回同じ角度で回そうとするからわけわかんなくなってただけで。
閑話休題、問題はそこではない。なんで一緒に設計作業やってるのにデザイナーとエンジニアが没交渉のまま営業とデザイナーがコンセンサス取ってきちゃうんだよとかそういう話ではない。そこも問題だけど。

Railsさんフロントエンドと仲良くする気無くない?

実際のところ、バックエンドについて言えばRailsは優秀だと思っています。でも自動で吐かれるビューがアレで、いやアレもアレでこう、エンジニアが作るサイトとしては必要十分なんだけども、デザイナーさんのデザインを当て込もうとするとそこそこ地獄。そんでデザイナーさんが「動くHTML見本」を作ろうとするとjQueryが確定で入ってくる。jQuery、LPくらいまでならまだしもがっつり動かすもんじゃないと思うのよね……いや六、七年くらい前まではめっちゃ便利と思ってたんだけど……。
弊社ではHTMLの作成はデザイナーの仕事である。Xdで作ったデザインをHTMLに落とし込み、それがエンジニアのところに来る。その時点でjQueryがバグってたりこのDOM構造じゃそもそも動かないだろみたいなのがあったりするんだけどそれは一旦横に置いて、デザイナーさんに作ってもらったHTMLをerbに貼り付けて変数を埋め込んだりしていくのが大体の仕事の流れである。
個人的に聞いた話、弊社デザイナーさんたちの中ではpugが流行っているらしい。ほうと思って使ってみたが、あれはなかなか良いものだ。十年以上HTMLを書いているのでまだまだ違和感はあれど、BEMを省略できるのがいい。(詳細はここを参照)
なにしろBEM記法、スタイルを書いてるぶんには楽なのだけど、HTMLを書こうとするとクラス名が長すぎてダルい。ただでさえ<%=%>とかが入って可視性の低いerbファイルがますます散らかる。そんでうちのデザイナーさんが書くHTMLはネストが深いのでクラス名がヤバいことになり、erbファイルは混沌を極めるのである。というかあれpugでも相当散らかってんじゃないかって気がするけど。
とはいえpugはRailsでコンパイルできない。Railsのプリコンパイラに合わせてpugもコンパイルしようねとかくっそダルい上にたぶんこれやっても社内で評価されない(需要として認識されていない)し変な責任だけ飛んでくるハメになる。そこまで身を捧げる気はない。slimも触ってみたけどクラス名の省略ができないのでデザイナーてきにもエンジニアてきにもイマイチ得が無い。

Railsがフロントエンドと仲良くしてくれないのでじゃあいっそバックエンドを完全にAPI化しちゃえば?とか思うんだけどそれもそれで、ajaxでの画面処理ができる人間がほぼほぼいないのね。いやたぶんjQuery.ajaxはみんな書けると思うんだけど、あれ割とサクッと地獄になっていくじゃない?
VueでもReactでもAngularでも何でもいいんだけどjsフレームワークが入ればまだマシなんだけど結局うちにフロントエンドエンジニアはいないという話に戻るというか、つまるところjsフレームワークをやる人が居ない。
そこで「じゃあ俺が!」とならないのは、デザイナーさんとの共闘の道が今まだ無いからなのよね。だってデザイナーさんてきにはjQueryをCDNで読み込んじゃうのが一番楽なんだもの。
だから道を作るならまず

  1. 現在の問題点、デザイナーとエンジニア双方の苦痛(会社的には「省略できるコスト」)の共有
  2. 顧客折衝から始まる設計作業のフロー見直し
  3. jsフレームワーク導入(少なくともデザイナーさんが動作確認に使える状態にしないといけない)

くらいのことは必要。(正直モックの時点で動く必要あんま無いと思うんじゃが)(Xd便利だしそっちでやってくれよと思う)(common.jsとかに半端に動作詰めるのやめてくれ)
これがとても面倒くさい。社内政治にがて。んでうちの社長あんまりコスト意識はっきりしてないし……だるい……
手数が多いのを愚直にこなすのが誠意と思ってる人間を説得するのって面倒くさい。手数が減ればバグも減るのに。

現状、弊社では「デザインモックの作成」と「設計書(と私は認めない、あれは仕様書だ)の作成」が並行で行われていて、だからDB構造とDOM構造が噛み合ってなくてデザイン当て込みの時点で遅れが発生するのが毎回のパターンなんだけど、そもそもデザイナーさんはフレームワークの動きを知らないのにエンジニアからデザイナーに文句言えない状態がまずい。そりゃもうまずい。MVCの連携をデザイナーさんがぶち壊してくるのがまずい。でもデザイナーさんにMVC理解しろとは言えない。
だからせめてスタイルとか入れる前のモックアップとか画面遷移とかだけでもエンジニアにやらせてほしいんだけども、それって結局デザインとカブってくるエリアでもあって、こういうのをちゃんと会議すればいいものを、ろくでもない進捗会議とかああいうのいらないっての。日報で済むやろ。日報書いてバックログ書いてそのうえ進捗会議とか何重にコストかける気だ。

っていうかrails g controller hogeで吐いたhoge.scssが他のコントローラでも無差別に読み込まれるのアレはマジで何なの?何の意味があるの?コントローラごとに分けられないなら吐かんでいいっちゅうの。
あとデザイナーさん、SEOとかまったく埒外なのはわかってるけど、div乱舞やめよう……。HTMLタグ自体にも意味があるの……HTML5書こう……