デザインエンジニア組織拡大の背景ーフロントエンドとデザインの力で事業を加速

こんにちは、estieでUIデザイナーのマネージャーをしているKioです。estieには既に4人のデザインエンジニアが在籍していますが、さらなる事業成長に向けて新たな仲間を募集しています。

estieのデザインエンジニアは、フロントエンド開発やプロダクトデザインを通じて、事業の成長を牽引する重要な役割を担っています。なぜデザインエンジニアが求められているのか？その役割や魅力とはいったい何なのか？

今回は、デザインエンジニアのマネージャーをしているOmote、デザインチーム全体を統括しているVP of DesignのArakenに、estieのデザインエンジニア組織拡大の背景について詳しく話を聞きました。

なぜ今、デザインエンジニア組織を拡大しているのでしょうか？
デザインエンジニアに求められる役割について教えてください
estieに向いている人ってどんな人でしょう？
デザインやフロントエンド開発における課題はありますか？
入社された方に、どのような機会を提供できるとお考えですか？
estieのデザインエンジニアとして働く魅力や面白さについて教えてください
さいごに

なぜ今、デザインエンジニア組織を拡大しているのでしょうか？

Omote：estieにはマーケットリサーチ事業本部とエンタープライズソリューション事業本部がありますが、両方の事業部で「デザインエンジニアが必要だ」という声が上がりました。マーケットリサーチ事業本部内のチームではフロントエンド開発にあたって、2つの編成パターンがあります。

デザインエンジニアがデザインとフロントエンドの開発を担うチーム
UIデザイナーとソフトウェアエンジニアがフロントエンドの開発を担うチーム

後者のチームではフロントエンドの専門性が不足しがちなため、デザインエンジニアが必要でした。また、新しいプロダクトが次々と立ち上がっています。フロントエンドとデザインの両方に強みのあるメンバーがいることで、デリバリーをより早められるという期待があります。

Araken：エンタープライズソリューション事業本部には現在デザインエンジニアが在籍しておらず、マークアップやスタイリング、JavaScriptでの実装をメインで担うメンバーがいないという危機的な状況です。現在約100人のメンバーのうち、デザインチームに所属するメンバーは10人います。一見すると、デザイナー比率が高いように感じますが、デザインチームにビジュアルデザイン・UIデザイン・フロントエンド実装をする者がおり、デザインエンジニアは4人です。estieのソフトウェアエンジニアは40名近くいるのですがその多くはバックエンドに強みがあるため、フロントエンドに強みのあるメンバーをこれからさらに増やしていきたいと思っています。

デザインエンジニアに求められる役割について教えてください

Omote：estieのデザインチームのメンバーは全員、HTMLとCSSを書くことができます。デザインエンジニアには、それに加えてJavaScriptやTypeScriptを扱います。また、Next.jsを利用して開発する能力が求められます。デザインエンジニアには「デザイン」という言葉が含まれていますが、全員がFigmaでUIを作成している訳ではありません。しかし、全員がより良いユーザー体験やUIの実現・画面設計に関心を持ち、デザインに関与しています。

Araken：デザインエンジニアの役割は企業によって様々ですよね。フロントエンド開発に特化し、デザイナーとエンジニアの橋渡しやデザインシステムの構築を主なミッションとしているケースもあります。estieのデザインエンジニアはフロントエンド開発に加えてプロダクトのデザインを考える役割も担っていますよね。

Omote：はい。最近、面接で「デザインエンジニアはユーザーとの接点を作る面白みがある。やりがいのある仕事ですね。」とおっしゃった方がいました。実際、デザインエンジニアはユーザー体験を作り上げ、事業の成長や価値創造にも深く関わる重要な職種です。一般的なフロントエンドエンジニアと比較すると、UIデザイナーが作った画面とソフトウェアエンジニアが開発したAPIをつなぐだけではなく、ユーザーに最適な体験を提供するためにあらゆる手段が求められます。デザインエンジニアには、ユーザーと直接向き合うことが欠かせません。

estieに向いている人ってどんな人でしょう？

Omote：先ほど話にあったように、顧客やユーザーに関心を寄せられる人です。私がデザインエンジニアのマネージャーとして大事にしているのは、各人の「自律性」です。皆、一人でもプロダクトを作る能力があります。その上で、幅広いスキルで得られた気づきを用い、他のメンバーと助け合い、チームを主語にして事業を前に進めてほしいです。

Kio：商業用不動産は馴染みのない分野なので、興味を持てるかどうかも大きなポイントですよね。

Omote：そうですね。ジョブディスクリプションにもプロダクトを創ることだけでなく、ドメインを理解して課題や解法を考えることが言及されています。また、estieが持っているたくさんのデータの中には、構造化・正規化されていない生のデータも存在します。時には、デザインエンジニアが適切に情報設計・モデリングする必要があります。技術力を発揮するためにもドメイン理解が欠かせません。

Araken：中には「不動産に全然詳しくないけど大丈夫？」と心配される候補者の方もいらっしゃるのですが、不動産のバックグラウンドは不要です。開発メンバーのほとんどが業界初心者でしたし、未知の分野を楽しみながらキャッチアップできるかどうかが重要だと思います。事前に専門書を読む必要もなく、気軽に入社してもらって大丈夫です。

Kio：社内の業界経験者にも聞けますしね。estieにはたくさんのデータもあるので、それを見て理解を深めることもできます。

デザインやフロントエンド開発における課題はありますか？

Omote：デザインシステムをはじめ、フロントエンドの共通基盤の配信はされていますが、これまで優先度が低かったこともあり、改善の余地はまだまだあります。実際、異なるプロダクトで同じものを作ってしまうシーンもあります。また、コンポーネントを維持・運用するための仕組みは、まだ十分に整備されていないですね。

Kio：未公表を含めると既に10個以上のプロダクトがありますし、これから共通基盤の重要性が増しそうですね。estieならではの課題として、プロダクトの展開方法に起因する共通化の難しさがあると思います。「業務」領域だけでなく、「物件タイプ（オフィス、物流施設、ホテルなど）」や「エリア（日本、その他のアジア圏など）」といった異なる軸でのプロダクト展開も進めています。そのため、単なるプロダクト間の共通化だけでなく、業務ごと・物件タイプごと・エリアごとに共通化すべき部分と、そうでない部分を整理する必要があります。

Omote：そうですね。また、すべてのユーザーの要望を満たすことは難しいため、どこまでを汎用的な機能としてプロダクトに組み込むかを見極めることも重要な課題です。これはフロントエンド開発やデザインの領域を超えたテーマですが、estieのデザインエンジニアには、こうした課題にも主体的に取り組むことを期待しています。

入社された方に、どのような機会を提供できるとお考えですか？

Omote：estieでは、0→1のプロダクト開発を経験する機会が豊富にあります。そこからプロダクトをグロースさせる過程では、事業的にも技術的にも多くの課題と向き合う必要がありますが、それが面白いですね。スタートアップにおいては、プロダクトマーケットフィット（PMF）と真摯に向き合い、顧客と伴走しながら成長させることが求められます。そうした取り組みに最前線で関われるのは、大きなやりがいですね。 estieのデザインエンジニアの業務は、ソフトウェアエンジニアやプロダクトマネージャーの役割と重なる部分もあります。フロントエンドだけでなく、プロダクト全体を俯瞰しながら進められる環境があるのも大きな魅力だと感じています。

Kio：estieのように複数のプロダクトが相互に作用し合う環境では、開発の複雑性も高く、高度な設計力も求められるので、こうした課題に取り組むこと自体もチャレンジの機会になりそうですよね。

Omote：さらに、estieほどデータ基盤が揃っている会社は珍しいと思います。Snowflakeをはじめとした分析基盤が整っているので、ログを活用して定量的に事業を分析しながら開発を進めることができます。みんなある程度SQLを書けるのも特徴的ですよね。

Kio：確かに、estieはデータを持っていることもユニークですよね。データがあることで、ユーザーの入力負担を減らせたり、AIを活用した機能を提供できたりと、選択肢の幅が広がります。データを活用してプロダクトを考えられることも、estieが提供できる機会だと思います。

Araken：estieではフロントエンド開発を極めたい人も、プロダクトデザインやマネジメントの方向に進みたい人も、それぞれに幅広い機会を提供できると思います。複数のプロダクトを並行して開発しているので、新しい技術やスキルに挑戦できる環境が常にあります。さまざまな選択肢を試しながら自分に合ったキャリアを模索できる環境であるため、「どのように自分がバリューを発揮するか」を考えられる人にとっては、非常に面白いと思います。

estieのデザインエンジニアとして働く魅力や面白さについて教えてください

Omote：estieの面白さの1つは、現実世界のデータ、特に不動産データを扱うことにあります。入社して驚いたのは、日本の土地と建物の関係が1:1ではなく、N:Nの関係になっていることです。例えば、1つの土地に複数の建物があったり、1つの建物が複数の土地にまたがっていたりするケースも珍しくありません。相続や歴史的な背景による分割・統合の影響で、こうした複雑な構造が生まれています。このデータを正しく整理し、価値に繋げていくことは、もはや「面白い」を通り越して使命だと感じています。そして、これはestieだからこそ解決できる領域だと考えています。

Kio：確かに、日本の土地制度を前提にプロダクトを作るのは難しさがありますよね。海外の事例が参考になりにくいですし、国内でも類似プロダクトが少ないですよね。

Omote：そうなんです。しかも、東京の不動産市場規模は世界1位。やりがいがあります。不動産という実態のあるものにも関わらず、理解を深めていくと「シンプルに見えて実は極めて難しい問題」が散らばっています。数学でいうとフェルマーの最終定理のような、一見単純な数式に思えるけれど、解き明かすのが非常に困難な問題です。だからこそ解決したいですし、同じ志を持った仲間を募集しています。

Araken：はるか昔からこの地にある「不動産」は、その長い歴史ゆえに積み重ねられた業務やデータが大量にあるのが特徴的ですよね。あと、estieに入ってから知ることが多くて面白いです。例えば建物の「所在地」1つとっても、「住居表示」と「地番」がそれぞれ定められていることとか。日々目にしていたのは訪問・配達などに便利なように定められた「住居表示」で、実は「地番」という別の概念もあったことを初めて知りました。このようなドメインの事情を理解し、整理しながら開発を進める点はestieのデザインエンジニアに求められる重要な役割と言えると思います。

Kio：そうですね。理想のシステムを思い描くことはできても、それを現実に適用するには、長年積み重ねられた仕組みとのギャップを埋める必要があります。そのプロセス自体も、estieで働く面白さの1つなのかもしれませんね。