feb19.jp

Nobuhiro Takahashi
Designer / Engineer

デザイナーはコードを書くべきか

デザイナーはコードを書くべきか

date
2021.9.11(Sat.)
tags
Column

諸事情で締め切りまでに歌詞を考えないといけないのですが、全く思いつかないので、表題の駄文を書き始めてしまいました。

とある IT の事業会社でインハウスデザイナーのマネージャー、エンジニアのマネージャーをそれぞれ短い期間ですが数年経験した身として、ふとした場でこの話が聞こえてくることもあるので、考えをまとめてみました。あくまで IT 系のデザインの話ですのでご注意ください。

デザイナーや、デザイナーに関わる誰かの参考になりましたらと思います。

UI や Web に関わるデザイナーはコードを書くべきか

まず、これをデザイナーに言えるのは以下のパターンです。

  • 社長、経営者(給料を出す人)
  • そのデザイナーのマネージャーや、先輩デザイナー(キャリアを導く人)
  • そのデザイナーが入るプロジェクトマネージャー・エンジニアの「お願い」(猫の手を借りたい人)

「一般論として『デザイナーはコードを書くべき』とは言えない」と認識しておく必要があります。

「エンジニアはウェブサイトに使う写真を選ぶべき」「営業はサーバーのセットアップをすべき」と同レベルのべき論なので、デザイナーがこの言葉で嫌な気持ちになった、ということがあれば気にする必要はありません。

逆に「なんでデザイナーなのにコード書いてんの」という声もデザイナーのあなたがやるべきと思ってやったことだと思うので、気にする必要はありません。

結論

自分としては

  • 書けるに越したことはないが、どっちでもいい

と思います。

  1. コードを書いたことがあるデザイナーと、そうでないデザイナーがアプリケーション開発のチームに居るときのエンジニアとの相性のよさ、話の速さには影響が出ているとは感じました。
  2. ただ、コードを書かなくても、デザインファイルや命名を整理し UI に留まらずアプリ・IT サービスの研究をおこたらない UI/Web デザイナーがいるチームは非常に円滑な開発が行われていました。
    1. ここはディープリンクするようにできますか、 Pull To Refresh 入れなくていい?、ここ OS の標準コンポーネントの *** を使いましょう、みたいな会話ができる人たちのことです。
  3. シニアな Web/UI デザイナーに求めるスキル領域はディレクターを兼ねることで、マーケティング・ブランディングの戦略立案設計とその実行のために紙・映像・音声・文言制作・資料制作・そして Web/UI の設計・制作・他社やフリーランスの方との折衝・競合/SNS/トレンド調査などがあり、フルスタックなので、コードを書くという代わりの効く(あえて悪い言い方です、すみません)仕事は他のメンバーに任せたいかなと思います。
    1. アプリケーションエンジニアの工数も使いたくないから SuperZendeskStudio とかで代替できそうであれば活用したいですね。
  4. 紙や映像や資料制作などをやりたくなく、企画や UX デザインはせず、ワイヤーフレームがあってからデザインを起こすような UI/Web の制作を中心にしたいデザイナーはコードが書けたほうが単価は上げられるからいいかな、と思います。
  5. エンジニアの手が足りなくて単にデザイナーも書いてくれーというだけのケースが多いと思います。この場合はデザイナーに責任を押し付けるのではなくチームに相談するといいと思います。

以下さらに駄文

画像中心のデザインはウェブデザインと言えない、こともない

ユーザビリティ、アクセシビリティや Google Chrome Developer Tools の点数が悪くなるから、画像を中心にしないといけないデザインはウェブデザインとは言えない、というとこれも

  • どっちでもいい

と思っています。

基本的に、事業からいかにお金を産み出すかを考えないといけなく、できるスケジュール、リソースの中から最小のコストで目的に一番添うことや信じることを、優先度の高いものから実現していくのが事業開発なので、一枚画像を貼って、テキストが生きてねーぞ!みたいな HTML であっても、SEO は不利ですが、コーディングのコストが不要なので一考の価値ありと思います。

「アクセシビリティ」「Chrome の点数を良くする」が事業のその地点の目標と合致しているのであれば良いと思いますが、あくまで一要素でしかなく、ターゲットの顧客が納得するための手前のプロモーション写真・画像や動画や体験談その他諸々が刺さってそっちの方が効くのであれば、ローディングが短ければ短いほど良いわけでもないわけです。

ただここは個人的には多くの顧客が利用するようになる前にテキスト部分はちゃんと生のテキストになるように改修しておきたいポイントではありますし、他国ではアクセシビリティ非対応であると訴訟で罰金を受けるケースなどもありますし、適宜見直せるぐらいの余裕を持った開発が行えるようになっていくと良さそうですよね。(そのために費用対効果の高い事業を生み出して外国の方にも使ってもらえてリソースが多く使えるような開発になること願うばかり)

ウェブやモバイルのアプリ向けのデザインは OS 標準や CSS フレームワークなどのデザインシステムの活用が良い

マーケティングを目的としたウェブサイトや汎用的なメディアサイトではサイトを開いたタイミングでおおよその目的が達成されたり、目的のためのボタンがページのどこかにあることをおおよそのインターネットユーザーは知っているので自由でいいと思います。

日々仕事のために使用したり、ある課題解決のために手に取るアプリケーションは、 OS 標準や CSS フレームワークを使ったデザインが有効です。

ただ CSS フレームワークはあまりいい出来のものが無いのが実情なので特にパソコン向けのサイトでは Atomic Design のような考え方を取り入れて小さなデザインシステムを作ることを工数に入れちゃうのが一番いい気がしています。

OS 標準や CSS フレームワークは「他のサイトやアプリでも見慣れた UI」にできるので、学習させるコストを最小に抑えられますし、追加開発でもおそらくこういう UI だろうなという予測が立って開発が効率化されるので、初期にこういう「デザインの選択」を行うのは有効です。

リリース後やシステムパッケージ販売後のお問い合わせ対応やメンテナンス工数を減らしたり、顧客ごとにカスタマイズする場合も容易にすることができると思います。

これらの挙動や仕組みを理解するためにコードを書くことは良いデザインシステムを作る上でも学習になると思うので、コードを書くのはとても良いと思います。

ゲームやエンタメ要素の強いアプリケーション

UI もアートワーク・世界観の一部と捉えることができ、没入させたいという目的が働くと思うので、OS 標準や CSS フレームワークじゃない方がいいんじゃないかと思います。

  • 翻訳したときに文字数制約やコンテンツ・メニュー追加とかの運用コストのこと
  • 常に表示しないといけないグラフィックスが減ってメモリ効率は良くなるといったこと
  • なるべく汎用だけど世界観を台無しにしないようにというバランスを考えること

ゲーム体験のさまざまなことを考える必要があるので、コードを書くよりも制作を優先された方がいいのかなと思います。

様々な用語や開発について理解するために UE や Unity などのツールやスクリプトを触ってみるのは良い学習になると思います。

1px のズレを見逃したくない

こういう場合はデザイナーがコードを書いた方がいいと思います。

そうで無い場合は、あの手この手で説明したり効率的なワークフローを整備したり、あるいは根回しをしたりするといいと思います。

  • レスポンシブウェブデザインを使う場合は、「○○比によって表現する」などの図面を書いたり、「このデバイスの場合」など最低 3 程度以上のデバイスを考慮したデザインカンプを作成する
  • FigmaZeplin などを使い、エンジニアが重く感じるデザイン専用アプリケーションをインストール・起動させることなく確認することができる状態にする
  • その他デザイントークンをまとめたドキュメントを作成し、別の画面ならエンジニアだけで想像して組めるぐらいの状態を作っておく
  • エンジニアのリーダーやプロダクトマネージャーと交渉する

しかし、デザイナーのこの主張を実現して評価するエンジニアのマネージャーが多くはないことをエンジニアは知っているので、他のところにコストを使いたいとエンジニアは考えることもあります。

これを実現しようとするエンジニアは希少種ですので、いっぱい労ってあげるのがいいと思います。

デザイン会社のコーディング担当としてこういう方にいていただくというケースがあると思いますが、今やフロントエンドエンジニアとして高い給料を出してよりエンジニアリングスキルの伸ばせる場を提供する会社は多いので、何かしらの方法でしっかり捕まえておく必要がある気がします。(私には高い給料あげる以外のアイデアがない)

この主張をするデザイナーは手段が目的になってしまっているので、事業会社には向いてないと思います。(自分もこういう時期はあったが...)

ただし 10px 以上ズレている、色が明らかに違う、デザインカンプに全く沿っていないなど、大幅に崩れている場合(あくまで例ですが)は、フロントエンドをそのエンジニアは任せない方がいいので、PM やリードエンジニアやマネージャーに相談しましょう。

デザインもコード好きだから書く

ああもう最高です、好きが産み出すものは圧倒的に強いです。周りから色々言われてもほんと無視してください。

コードを他のエンジニアと共有する場合は、ちゃんとエンジニアチームのシキタリを尊重する必要があるので、責任もってその部分をやり切ってさえいただければと思います。

エンジニアには面倒かもですが、そのデザイナーは圧倒的に希少種なので、エンジニアチームにも歓迎してあげて、相互に丁寧に教えあっていただけたらいいチームになっていくと思います。

営業をしながら企画考えてスケジュール管理をする人や、医者をやりながら IT 会社の社長をする人、企画をしながらテックリードをする人、子の親をしながらリーダーしながら管理画面のサーバー開発をする人、インフラもサーバーもフロントもやる人、デザイナーとエンジニアのマネージャーをする人、世の中は二つ以上の役割をやる人は少なくないので、デザインとコードの組み合わせが何も特別なことではないと思います。

学習リソース

入門書やチュートリアルを完了したら、デザインをコードで実装するストリームを見ながら写経したりするのは結構いいかもです。特に海外のがいいです。

React や SwiftUI や Jetpack Compose あたりは今なら良さそうですね。

Vue とか Storyboard や Android XML layout、Flutter もいいし、もうちょっと基礎的に Bootstrap や Wordpress もいい気がしますが、日本語の動画は本頁と同じくダラダラ余計なことを喋るのであんまりオススメしませんw

終わりに

なんてエラそうな文章なんだ。ひどい。読んでいただいた方ほんとすみません。ありがとうございます。

オンスクリーンデザイン界隈、大きくないのに複雑でシキタリや縄張り多い気がしてます。最近。なんでこんなことで喧嘩してんのみたいな。(あ、これ念の為、特定の会社や集団のこと言ってるんじゃないですよ)

ところで自分先月ぐらいにぬるっと転職してソフトウェアエンジニアになりましたので、そこで浮いた時間に UI/Web デザインの改善をしれっと実装したあと提案して、差し込ませて頂くというような感じでやっており、楽しくやっております。役割ゆるふわにやれる会社で、今のところいい感じな気がしています。

誰となくですが、コロナが明けたら飲みにいきましょう(明けるのか?)。

これ歌詞にできないかな(無理)。


(追記 9.12)一応補足

なんかもうほんとすみません。折角なんかコメントらしきものもいただいていて、一部誤解なきように、コメント返ししてみます。

あくまで規模や状況や案件はそれぞれで、視点がそれぞれ違うのだと思います。上の記事もレスも、あくまで一般論ではなく私の持論ですので悪しからず。

“コードを書くという代わりの効く(...)仕事は他のメンバーに任せたいかなと思います”これ要するに「上流工程やりたいから手を動かしたくない」という話で、デザイナーかどうかは無関係では
https://b.hatena.ne.jp/entry/4708196039597448546/comment/newnakashima

そうじゃ無いですよー。その前の文に書いてあるように、エンジニアが関わらない案件(紙・映像・文言制作、ほかには写真の加工やバナー制作にスタンプの制作とか)もあるので、デザイナーさんにはデザイナーさんにしかできない仕事をやってほしいというマネジメントをすることがあるということです。

デザイナーは上流下流行ったり来たりできる状態にマネジメントしておくとすごくチームが良くなるケースがあると思います。

UIデザインを突き詰めようと思ったら、ただセオリーを学ぶよりも、自分でコードを書いたほうが理解が深まると思うんだけどなぁ。
https://b.hatena.ne.jp/entry/4708196039597448546/comment/daigo0117

その気持ちはわかりますねー。自分もコードを書いたほうが理解が深まると思う派です。ただもっと効率のいい学び方をしていかないといろんなツールやプログラミング言語に触れていたら(他の仕事もあるし)学習コストも枯渇してしまうので、セオリーから学んでいけるようにしていくスマートな動きも必要なのかも思います(自分にも耳の痛い話)。

ところで「UI デザインを突き詰める」ってのは手段が目的になっちゃってるかもですね。UI 研究者ならアリかも。

びっくりするくらい組み込みづらい事があるから、一緒に仕事する人なら書いて(理解して)ほしい。
https://b.hatena.ne.jp/entry/4708196039597448546/comment/koda3

(推測ですが)ウォーターフォールだと組み込みづらいのが上がってくるとキツイですよね。デザインが始まる段階からコミュニケーションできるといいんですが、場合によってはデザインやり直してもらったり省略してもいいか相談してみてはと思いました。それがどのぐらいの組み込みづらさなのかはわかりませんが。

コードを書ける必要は無いが、どういうデザインをするとコストがかかるかは分かっておく必要があると思うなぁ。
https://b.hatena.ne.jp/entry/4708196039597448546/comment/nori__3

逆に「コストを下げるデザイン」を得意とするデザイナーが居てもいいですよね!コストのかけどころと抜きどころのバランスでいいもの作りたいですね。