フロントエンドエンジニアから、デザイナーさんに意識してほしい10のこと｜Pittan｜note
そうでない会社もあるだろうけど、私の仕事ではこれはデザイナーの領域ですよ。文言についてはグレーだが、逆にそうであれば依頼する前にディレクターに聞くなりするべきで他人に仕事を押しつける話しではないわけで
幾つかの意見に分類できるが、一部の人はルールで縛られているような感じや、また、そこまでデザイナーがしなければならないのかという意見で反発も少なからずあるようだ。
が、そもそもデザインを完遂させる事はデザイナーの仕事であって、それ以上でもそれ以下でもない。
デザインと一言でいっても、ベースのデザインの作成で終わる案件もあれば、色彩の調整からフォントのサイズ指定、レイアウトパターンの定義まで行うような具体的な作業を含むものもある。
どれが一般的とはいわないが、冒頭のものはデザインの中でもデザイン案の作成であって記事にあるようなケースの話しではない。
また、記事を読めば書かれているが、今までも何度もコミュニケーションを行っており、且つ、そもそも記載されている内容はデザイナー側からもそういったものをまとめ共有するればいいかもね、というアイデアがあり行っているもので、コミュニケーションによる賜でしかない。
これが所謂「言語の共通化」というもので、別にこの方法に限らないし、他の組織・チームではまた異なったルールや手法により実現しているかもしれない。
が、この記事で重要なのは「双方が仕事をしやすいルールを作成する」という事であり、中身が自信の仕事と一致するかしないかという事は粗末な問題でしかない。
そもそもデザインツールや流れが違えば幾つかのルールは不要であるものもあるし、それを言い始めれば、もはやあらゆるルールや手順はネットに書くべきではないという事になる。
デザイナーが求められているものと、エンジニア（フロントエンジニア）が求められているものは違う。
だからこそ、それぞれがそれぞれの役割のエンドポイントで情報を受け渡す時点で一定の品質や情報量を満たした上で次の工程に作業を引き継がなければならない。
例えば、挙動の定義が未定義であるなどというのは、極論いえば他の画面も含めた共有のルールや定義が存在しないという事で、そもそもデザイン作業としては完遂していない。
仮にそれがデザイナーの仕事ではなく、ディレクターなり他の人の仕事であるというならば、そもそもデザインパターンが必要数を満たしているのかどうかをディレクターに確認する必要があるわけで、その時点でデフォルトの挙動で良いといわれればデザインしない、任意のパーツを実装してほしいといわれればデザインをする、それだけでしかない。
何れの話しもデザイン作業の一環であるわけで、その組織のルールにより分業先が異なるのであればそれを明示するなりすればよいだけの事。
この話しは別にデザイナーだけではなく、エンジニア内でも同様であって、もっと言えば、事務職でも同じ事。
ある作業を複数人がそれぞれの役割でこなす必要があるとき、自分の作業は何処までなのか、何が含まれ、何が含まれないのかを明確にすることは当然のことでしかない。
その作業はだれかがやってくれる、わけではなく、自分の作業を誰かに引き継ぎ時点で自分の作業は完遂している事を説明できなければならないし「知りません」では次の工程の作業は開始できない。
この記事を読んで「そんなものはデザイナーの仕事ではない」というのであれば、現代のフロントエンドというものは技術的要素以上にデザインの影響が多分にあるわけで、その中心にいる人間としてはかなり不適格だと言わざるを得ず、自分の将来を考えても永遠にストレスから解放されない（おおよそ常に、なんでそんな作業を私が、それはエンジニアが決めれば、あれは誰だ、これは知らない、誰か決めてもらえますかなどなど）となる事は目に見えているので、他のもっと役割を自分ではっきりできるもの（例えばライン作業等は明確になると思われる）に変えた方がよいと思う。
相手も不幸になるが、おそらくそれ以上に自分が不幸になると思われるので。
