隣接するスキルを学ぶと「後ろ」が楽になる
結論
- デザインとプログラミングを両方学ぶと、変化があるのは主にデザイン側で、生産性が上がるのは主にプログラミング側
- なぜなら、デザイン→プログラミングという流れだから
とある日のサークルでの出来事
サークルで新しくInstagramのアカウントを創設するということで、1年生の子がアイコンに使う画像の案を3つ持ってきてくれました。
彼女が提出してくれたのは、大きな正方形の画像3枚でした。どれも上手にデザインされてはいるものの、Instagram上でのアイコンの見え方は「非常に小さい円形の画像」です。大きな正方形の画像3枚の状態で良し悪しを決めることもできなくはないですが、自分には後で「なんか違うな...」となる未来が見えました。
そこで自分は「実際にアプリ上でアイコンとしてはめてみて、その状態を見比べるようにしないか」と提案し、その1年生は快く行ってくれました。すると実際に画像の見え方が想定とは大きく異なり、最初に用意した3案は一旦取りやめて最適な画像を新しく作ることになりました。
生産性の鍵は”最終成果物をどれだけ意識できているか”
何でこんな話をするかというと、この件が生産性の本質に関わる出来事のように感じたからです。
つまり、「生産性の鍵は”最終成果物をどれだけ意識できているか”ではないか」といいたいのです。なぜなら彼女が最初から最終成果物（インスタ上での見え方）を意識して画像を用意できていれば、余計な手戻りは防げたはずだからです。
「これを出しときゃいいだろ」みたいな感じになって申し訳ないのですが、「イシューの解像度を高く持て」的な話です。
エンジニアリングを意識できているデザインは生産性を上げる
デザイン×エンジニアリングでもこのような考え方は当てはまると思います。つまり、最終成果物（プログラミングでどう書かれてどう動くか）を意識して作られたデザインは生産性を上げるということです。
例えば、自分はReactでの
- コンポーネントの分け方
- 命名規則
- propsの渡し方
などをある程度理解しているので、Figmaでデザインをするときに
- Reactコンポーネントの粒度に合わせてFigmaコンポーネントを作る
- コード上で実際につけられるであろう名前をFigmaコンポーネントにもつける（パスカルケースにしたりBEMを意識したり）
- propsとして扱うであろう情報をFigmaコンポーネントにVariantとして渡す（逆にそれ以外は別々のコンポーネントとして作る）
などといった工夫をして、次のプログラミングの工程の効率を上げる補助ができます。つまり、「プログラミングの知識があることで、デザイン側を工夫できてプログラミング側の生産性を上げられる」のです。
しかし、逆に「デザインの知識があることで、プログラミング側を工夫できてデザイン側の生産性を上げられる」というケースはなかなかないように思います。なぜかというと、プログラミングはデザインの後にくる工程だからです[1]。エンジニアリングを行う上で最終成果物を意識しても、デザインのためにプログラミングをどうこうしようと考えることはあまりないのです。
もちろん、FigmaやUXHubのように「エンジニアリングの力を持ってしてデザインの課題を解決する」というケースはざらにあると思うのですが、ここで筆者が言いたかったのは「隣接する工程の知識やスキルを持っていて強みとすることができるのは、より最終成果物に近い（＝「後ろ」の）工程」なのではないかということでした。
戦略的に「後ろ」のスキルを学んでおく
これがわかって何が嬉しいかというと、「戦略的にスキルを身に着けたいときに指針の1つになる」と筆者は考えています。例えば「私はソフトウェアのUIデザインで戦っていきたいから、その後の工程であるプログラミングも学んでおこう」みたいなことです。
「じゃあエンジニアとして戦っていきたいときの”後ろ”はなんなのか」と問われたらなかなか思い浮かばないのですが、「ユーザー/ドメイン理解」なんかは該当するかも知れません。プログラミングの後には「ユーザーに使われる」という工程がありますから。
筆者は新卒ではソフトウェアエンジニアになるのですが、最終的にはPMとか事業家みたいなポジションで活躍したいと思っています。ですので、たとえばエンジニア→UXデザイナー→PMみたいな感じでステップを進めていけば、ジョブチェンジしたときにも「後ろ」の工程を意識しながらアウトプットを出して差別化していけるんじゃないかなあと考えたのでした[2]。
Discussion