見出し画像

フロントエンドエンジニアがデザインできるようになると何が嬉しそうか

今年の春ぐらいから独学でデザインを練習し始めたのだが、そもそもやり始めた自分のモチベーションと、実際やってみて「こういうところがフロントエンドエンジニアとしての業務にも活きそう!」と感じたことを言語化しようと思う。

ここで言う"デザイン"とは何か

はじめに、デザインと一口に言っても主語が大きいので、イメージがずれないよう具体的に述べると、いわゆるUXの5段階モデルの「表層」と「骨格」をイメージしている。

具体的なDoで言うと「実装者がUIを作る時の指針となる成果物としてのデザインを作ること」、もっとざっくり言うとFigmaなりSketchなりで本番でも使われるデザインを作ること。

思うに構造より上のレイヤーの"デザイン"はプロダクト開発に携わる人なら普段からある程度やっているのではないかと思う(もちろんかける時間の比重はデザイナーやPdMというロールを持っている人の方が多い)。

個人的にそもそも勉強し始めたモチベーションとしては「実装レイヤーの仕事をとにかく前に進めるため」という目的が強いため、自分が勉強している領域は一旦「表層」と「骨格」に絞って考えている。

何が嬉しそうか

それでは前置きを長々と語ったところで、本題である何が嬉しそうかを考えてみる。ちなみに「嬉しい」ではなく「嬉しそう」と表現している理由は、まだ道半ばで仮説でしかないので予防線を張っているためだ。

1. コミュニケーションが 1 往復 減る
個人的にはこれが一番の目的。実装を進めていてデザイナーが考慮しきれていない状態や、気づけていなかった仕様・仕様変更などは少なからず出てくる。そんな時普通はデザイナーにデザインを作ってもらって、その間はエンジニアは違うタスクをやって、デザイナーが修正したものを作ってくれたらまた同じ機能の実装に戻る。

これで個人的に問題だったのが実装者のコンテキストスイッチ(違う種類のタスクを行うことによって生産性が落ちる)。要するに、デザイナーから修正が来るまでは他のことをせざるを得ないので、複数のタスクを並列して実行しなくてはいけない。そして、デザインを実装者がこなせることによってこれをなくせる。

画像1

(点線の部分がコンテキストスイッチです)

もちろんチーム全体としての業務量は変わっていないのだが、作業者である自分のコンテキストスイッチが減って生産性が上がる効能はあると思うし、プロジェクト管理としても一個一個の機能がリニアに完了していくので読みやすくなるだろう。これはデザイナーのリソースがカツカツであればあるほど顕著になると思う。

ただ、全ての状況でこの進め方が正しいとかは思っていなくって、デザイナーのリソースが余ってるならどんどんお任せした方がいいし、上記で言う A の機能を終わらせるためのリードタイムが短いのであれば分業した方が速いこともある。

2. よりデザインの意図を実装に反映できるかも
具体例はあまり思いつかないのだが、少し前にちょいバズしてたこの記事が割と言いたいこと感ある。

そもそも複数のデバイス幅を対応する時点で、ピクセルパーフェクトと言うのは無理なので、ある程度デザインの意図を汲んでよしなにする力がフロントエンドエンジニアには求められていると思う。

マージンから「この情報たちは同じ文脈なんだな〜」とか「違うから離しておきたいんだな」とか、割とデザイン通りのピクセル数と比率に従っておけば大外しはしないと思うが、デザインの意図通りに構造を作れておくと後の変更にも強い実装が作れると思うので、コードの品質向上にも繋がるのではないかと期待している。

3. デザイナーと仲良くなりやすい気がする
これしなくてもデザイナーとフロントエンドエンジニは業務上関わりが多いので仲良くなりやすいと思うが、やっぱり同じ分野の勉強をしている人と話せるのは楽しい。

4. プロトタイピング、動くプロダクトでの仮設検証を高速に行える
一個大きく役割持てそうと思っているのが、エンジニアなため状態を持った動くものも作れるので、1人でそこそこの品質のデザインとともにプロトタイプの作成が行えるのではないかと期待している。

プロダクト本腰入れて作るかも分からない仮設検証の段階では、むしろ人数が少ない方がいいと思うので、そういったフェーズにおいて一人で一貫して物作りができる力というのは輝くのではないかと思う。

ただ、これには最初に触れたデザインの定義意外のUXリサーチのスキルなんかもプラスアルファで必要になりそう。

5. デザインシステム作成時にエンジニア視点、デザイナー視点、その両方が持てるかも
デザインシステムエアプなので若干妄想は入るのだが、デザインシステムは最終的な成果物としてデザインと実装の2つがあり、その両方が継続的にメンテナンスされていくものだと思う。

なので、両方の運用の辛みが認識できているといい感じの進め方とか提案できるかもしれない。具体的な例で言うと自分でデザインやってみて、デザイン自体の生産性向上のためのコンポーネントとか作りたいことがあって、実装の粒度とは全く別物なのでただのコンポーネント集に頼っちゃあかんなとか思った。

おわりに

以上が私が思うフロントエンドエンジニアがデザイン勉強すると嬉しそうなこと、な訳だが、正直な気持ち今のところめっちゃ価値出せるようになるかというと自信ない。デザインよりバックエンドめっちゃできるようになった方がいいんじゃね?みたいなことも常に感じる。組織やプロダクトにもよるだろうけど。

ただ、Twitterとか眺めていてもデザインができるフロントエンドエンジニアというのは強く求められているように感じるし(みんなが具体的になにを期待しているのかは分からんけど)、何より自分が日々実装する対象を理解することは悪いことにはならないはず。

これを読んで自分と同じ方向性で努力する人が増えたら嬉しいばかりです。

この記事が気に入ったらサポートをしてみませんか?