受託制作会社のフロントエンドエンジニアから、事業会社のUI/UX担当に転職して思ったこと、振り返り

はな

こちらは「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」4日目の記事です。


こんにちは、はな（@kon_hanae）です。

つい先日、3年間勤めた受託のWeb制作会社からスタートアップ系の事業会社に転職しました。

前職はフロントエンドエンジニアとして静的サイトのマークアップやWordPressサイトの構築などを主にやりながら、クライアントへのヒアリングや画面設計あたりに手を出しつつ、ごくまれにバナー等のデザインを作ったりしていました。

現職ではUI/UXデザイナーとフロントエンドエンジニアの兼務のようなポジションを賜りまして、Reactを書いたりUIデザインをしたりジャーニーマップを作ってみたりなどしています。

IT業界に入ってまだ4年足らずではありますが、自分はずっと"デザインとエンジニアリングのあいだ"で仕事をしてきたのかなと思っています。

本記事は、受託制作会社から事業会社に転職して気づいたこと思ったことを、"デザイナーとエンジニアのあいだにいる人"目線でまとめます。

※受託制作会社と事業会社を比べて「どっちの方が良い」といった話を展開する意図はありません。あくまで「転職してからの振り返り」や「個人的な気づき」をまとめる内容（もういっそポエム）になります。

仕事への取り組み方の質が変わった

「広く浅く」から「狭く深く」へ

受託制作だと、常に複数のクライアントからの案件を掛け持ちして進めていましたが、事業会社に移って一つのプロダクトに集中して関わるようになり、仕事への取り組み方が「広く浅く」から「狭く深く」に変わりました。

制作会社で複数の案件を掛け持ちしていると、時間的な制約が厳しいので「一つの案件だけに集中してとことんやり尽くす」というのがなかなか難しかったです。また、受託という立場的な制約もあいまって、デザインに携わるといってもUXの5段階モデル（※）でいうところの「骨格」と「表層」のみのコミットになることが（自分の場合は）大半でした。一方で、多様なクライアントと関われたり、サイトの種類も色々作れるので「見分が広がって面白い」側面もあります。また、それぞれ納期を守るように効率的に進めていかなければならないので、必然的に「手が速くなる」のも受託制作のいいところだと思います。

※参考

事業会社で一つのプロダクトに集中して取り組む場合は、当然ですがプロダクトが提供する価値を突き詰めなければなりません。受託制作のときは基本的にはクライアント側に「〇〇するために▲▲のサイトを作りたい」といったニーズがあり、与えられた依頼を達成するために最善を尽くすというスタンスで仕事をしていました。しかし、事業会社に入ってみると「〇〇するために▲▲するっていうけど、そもそもの目的は〇〇で良いんだっけ？」というところから検討の俎上に載ってきます。なので、たとえ自分自身が意思決定者ではないとしても、（再びUXの5段階モデルを引き合いに出しますが）「戦略」とか「要件」のレイヤーから関わらないといけないんだなと分かりました。

正直、受託制作をしていたころは「お客さんはけっこう丸投げしてくる」感覚を持っていたのですが、今にして思うとお客さんはお客さんで「何のために何を作るか」という0→1の部分を検討した結果として「もっとよくしたいから御社手伝って」とか「ビジュアルデザインと実装は御社よろしく」と発注してくださっていたはずなので、自分の視野が狭かったことにも気づけました。


「デザイナーばっかり」から「エンジニアばっかり」の環境になった

具体的な人数比は出しませんが、転職によって「デザイナーばっかり」から「エンジニアばっかり」の環境に変わりました。

ちょっと話が飛びますが、制作会社にいたころは「画面の実装者にとって、デザインが多少不足していてもよしなに実装できるのは必須スキル」だと思っていました。画面のデザインは必ずしも網羅的に存在するものではなく、「実装側でよしなに補完する」のが会社からもデザイナーからも当たり前に期待される環境だったからです。また、規模感的に一人で全て実装できるものを作っており、コミュニケーションも自分とデザイナーとの1対1のやり取りで済むことが多かったため、実装者である自分がデザイナーの意図を推測してよしなにやってしまっても特に大きな問題は生じませんでした。

しかしながら、この感覚を持ったまま「エンジニアばっかり」の環境に転職し、他人に実装してもらう画面を自分がデザインした結果、当然の帰結として「画面のすべての状態を網羅したデザイン（ないしそれに準ずる指示書の類）を用意していないために、自分以外のエンジニアは正しく実装できない」「チーム開発で各人のよしなに依存する範囲が多いと整合性がとれなくなる」という状況に直面しました。これまで自分は「エンジニアの立場でデザイナーに配慮する」のは頑張っていたけれど、「デザイナーの立場でエンジニアに配慮する」というのはできていなかったのだと痛感しました。

これからやりたいこと

一言でいうとデザインシステムを作りたいです。

受託制作会社から事業会社に移りはしたものの、自分の主要な興味関心は一貫して「最小限の労力で、保守性と拡張性に富んだ手触りの良いUIを作り出すこと」にあります。

コンポーネントライブラリを作ったりドキュメント群を整備したりは勿論ですが、組織の中でデザインシステムを運用する人が育つ仕組みを作ることも含めて、当面はこのあたりを頑張っていこうかなと思ってます。

とりとめもなく転職してから思ったことを書いてきましたが、最後までお読みくださりありがとうございました。

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