デザインとエンジニアリングの両軸からプロダクト開発を支える、Design Engineerたちのスタンスと仕事
プレイドには、デザインとエンジニアリングの双方を横断しながら業務を遂行する役割「Design Engineer」として働くメンバーがいます。Design Engineerは、プロダクトの体験価値向上のための設計やその実装などを担います。
プロダクト開発組織で活躍するDesign Engineerの中から、「KARTE Craft」の開発に携わる石本 光司と、社内の開発体験の向上に取り組む「Developer Experience Team」に所属する安田 祐平の2名に、Design Engineerの業務範囲や社内外に向けてつくる価値、自身のキャリアなどについて話を聞きました。
デザイナーやフロントエンドエンジニアを経験し、プレイドへ
――プレイドに入社されるまでのキャリアと、プレイド入社のきっかけを教えてください。
石本：僕は大学でデザインを専攻していて、Webデザイナーとしてキャリアをスタートしました。当時、簡単なHTMLとCSSが書けたので、自分でUIカンプを作成し、そこからコーディング実装もできるデザイナーとして業務にあたっていました。そうするうちに、徐々にデザインからUI実装のほうへ関心が向くようになり、フロントエンドエンジニアとして、いくつかの会社でキャリアを重ねてきました。
ただフロントエンドエンジニア専業になっても、またデザインとエンジニアリングの職域を行き来している自分に気づいたんです。ユーザーのためにわかりやすいUIを提供したい、でもそのためにはサイトやアプリケーションの動きだけでなく、デザインも重視しなければならない。さらにフロントエンドエンジニアとしてフォローすべき範囲が広がっているようにも感じていて、自分が突き詰めたいUIに集中できない環境になりつつあって。
そんなときに、プレイドのDesign Engineer求人を見つけて「これは、自分がやりたかったところとマッチするのでは」と感じ、2021年に入社しました。ちなみに、Design Engineerに感じた可能性やこれまでの経歴、当時感じていたことをまとめた記事を書いたりもしているので、ぜひ読んでいただけると嬉しいです。
安田：僕は2023年にプレイドに入社しました。ここに来るまでにはフロントエンドエンジニアとして2社を経験していて、いずれもクライアントワークを中心にWebサイトの制作を請け負う会社でした。プレイドへの転職のきっかけは、当時プレイドが取り組んでいたデザインシステムの開発を担ってほしいと声をかけてもらったことです。
元々はデザイナーになりたいなと思っていたのですが、フロントエンドエンジニアとして就職したこともあって前職まではなかなか方向性を変えられずにいたんです。そうした中でもデザイナーと議論したり、自分なりにデザイン目線の提案をしたりもしていて。プレイドからはそれを評価してもらえたのかなと思っています。
今はデザインシステムの開発業務のリードを担いつつ、Developer Experience Teamという主に社内の開発環境の改善や、効率的な開発のための仕組み作りといった活動をする組織にも所属しています。石本さんのように特定のプロダクトにコミットするのとは異なったスタイルで仕事をしています。
デザイナーのイメージを正確にUI実装する
――プレイドにおける、Design Engineerという職種について教えてください。
石本：採用情報に記載した内容からお伝えすると、プロダクトの体験価値向上、そのための体験設計やインタラクションデザインやフロントエンド実装を担います。プロダクトにおける理想像を考え、デザインを通じてプロダクトの利用体験を豊かにすることが役割です。業務例としては、プロダクトのUI実装、Single Page Applicationの設計と実装、デザインシステムの開発、フロントエンド開発環境の構築と改善などが挙げられます。
僕の解釈としては、デザイナー寄りのフロントエンドエンジニア、といったイメージでとらえています。一口にフロントエンドエンジニアといっても、簡単なSQLを扱ったり、バックエンド領域への理解も求められたり、安田さんのように開発環境を整備したり……と、業務範囲がとても広いんです。その全てにおいて高いスキルを発揮できる人って、やっぱりほとんどいないんですよね。そこで、UI開発にフォーカスしたスキルや志向性を高く持つのがDesign Engineerだと考えています。
「デザイナー」と「エンジニア」をまたぐような形で存在していて、例えばUIカンプの作成は本来デザイナーの役割ですが、ちょっとしたものなら自分たちでデザインも実装もできます。
安田：フロントエンドエンジニアの職域が広すぎる、というのは以前から言われていたことでもあると思います。そこから徐々に、HTMLやCSSのようなデザイン的な領域と、JavaScriptを扱ったりアプリケーションの裏側をつくる領域に二分されていった印象があります。プレイドでは前者をDesign Engineerとしてとらえていて、デザイン寄りのフロントエンド技術や専門性を備えた人材、という意味合いが強いと思います。
プレイドは、プロダクトを開発するソフトウェアエンジニアもスキルや扱う技術を幅広く持ち、守備範囲も広く活動するメンバーが多いです。ただ、どうしても業務の幅が広く、各領域へのウエイト配分が難しいんです。その中で、「KARTE」のプロダクトとして優れたUIを担保するためにも、フロントエンド、特にデザインに近い部分を細かくフォローする人＝Design Engineerが必要とされています。
石本：そうですね。安田さんが開発している「Sour」と呼ばれる社内のデザインシステムを使うと、どんなエンジニアでもある程度の実装はできますが、やはり限界があって。ちょっとしたコンポーネント同士のアライメントが不ぞろいだとか、デザイナーの作ったカンプとの差異を埋められる人がいると違うんですよね。
KARTEは、多様な目的や課題に対応する強く幅広い機能や活用法があり、さらに日々新しい機能開発や改善を続けているBtoBプロダクトです。ユーザーとなるクライアントの担当者には、我々が提供する機能を広く深く使い込んでいただくことで、その先にいるたくさんのエンドユーザーの顧客体験をさらに向上させることができます。そのためにも「使いやすさ」はとても重要な要素で、UIが果たすべき役割はとても大きいと考えています。
――Design Engineerは、社内の組織図のなかではどのようなところに位置しているのでしょうか。所属している人はどのようなキャリアの方がいますか。
石本：Design Engineerとしては2024年11月現在、プロダクト領域のDesign Engineerが5名と、コミュニケーション領域のDesign Engineerが1名と育休を取得中のメンバーも1名います。プロダクト領域はKARTEなどのプロダクトにまつわる開発に携わっていて、コミュニケーション領域は主にマーケティングや各プロダクトのWebサイト制作も含めたユーザーコミュニケーションのための開発に携わっています。
また、グループ企業のCODATUMとRightTouchにもそれぞれ1名ずつ在籍しています。グループ全体で計9名が在籍しており、日常的に交流や情報交換の機会を持ちながら活動しています。
デザイン組織の中にDesign Engineerだけの部署は存在せず、それぞれが所属する組織の中で求められている役割や課題に向き合い、バリューを発揮しています。これは担当するプロダクトの状態にもよりますが、複数のプロダクトを兼務している人もいます。
安田：実際に開発を進めていくときの動き方は、他のメンバーのスキルに応じて柔軟に変化することが多いですね。プロダクトの状況や特性、取り組むべきタスクの量・質などもさまざまですし、人によって得意な領域や関心のある領域は異なります。フロントエンドに強い人が多ければUIに集中したり、バックエンドに強い人が集まっているならフロントエンド全般をフォローする。誰がどの活動を担うかバランスや重要度などを加味して、動き方やカバー範囲を考えていくことが多いです。
プレイドのDesign Engineerには、事業会社だけでなくデザイン系の制作会社出身の人も多いですね。これは制作会社のエンジニアとスキルの範囲が近しく、状況に合わせて役割を変えながら活動していくというスタイルの合致もあって、親和性があるのかもしれません。
プロダクト開発やデザインシステム開発・メンテナンスに従事
――日々の業務について教えてください。
石本：僕が携わっているKARTE Craftというプロダクトは、KARTEの機能を拡張したり、独自のカスタマードリブンなアプリケーションを開発できるPaaSです。外部の技術やシステムとの連携が重要なプロダクトであるため、一定のエンジニアリングの知識が不可欠です。一方で、KARTEユーザーの多くは非エンジニアの方々であるため、そうした方々でも簡単にシステムを構築できる仕組みを提供することを目指しています。
具体的には、ChatGPTのようなアシスタントAIや画像生成AIをアプリケーションに組み込むことで、コーディングを補助したり写真素材を用意する手間を省いたりと、簡単にアプリケーションを構築できるようサポートしています。エンジニアたちが、こうしたAIツールやライブラリをKARTE Craftに迅速に取り入れてくれるので、私はそういった複数のツールをKARTE CraftのUIとして整えていくことが多いです。データ処理やバックエンドへのつなぎ込みは既にできているので、僕はUIを考慮して説明文を追加したり、アクセシビリティを考慮したコーディングにしたり、といった調整をかけていっています。
デザインの視点でいうと、Empty Stateやエラーがある際の表示方法を考えることも多いです。エンジニア視点ではどうしても正常な状態の表示や、情報が正しく伝わるための表示を意識しますが、イレギュラーがあった場合の表示画面にもしっかりと配慮したくて、情報だけでなくイラストを付加するなどといった検討をしていきます。
KARTE Craftの開発メンバーはエンジニア4名と僕、11月から加わってくれたデザイナー1名の6名体制です。バックエンドが得意なエンジニアが多いので、フロントエンドを中心に担いつつ、デザイナーが参画する前はデザイン全般をフォローしていました。
安田：先ほども少し話しましたが、僕はデザインシステムのSourの開発と、Developer Experience Teamでの活動をしています。まずはSour開発について紹介します。
僕がプレイドに声をかけてもらったのは、このSourをより良く開発・運用していくためというのがきっかけです。僕の入社時点でSourはある程度形になっていて、コンポーネントやそのガイドラインはかなりできていました。なので今取り組んでいるのは、それらをさらに安定させたり、品質を向上させる仕事です。
例えば、既存のコンポーネントのバグを直したり、ドキュメントがわかりやすくなるように書き直したり、開発者が使いやすくなるようにインターフェースを見直したり、という感じです。
注意が必要なのは、そうした変更に伴うインパクトを適切に管理することです。Sourはすでに多くのプロダクトのさまざまな画面で使われているので、後から実装を変更すると意図しない問題が発生することがあります。そのため、変更内容はリリースノートに記録したり、セマンティックバージョニングを採用することで破壊的変更を明示したり、そもそも不用意な変更を発生させないためのリリース計画を立てたりしています。
Developer Experience Teamの活動としては、社内のライブラリのメンテナンスや、機能開発を終えて保守フェーズに入ったプロダクトの管理やバージョンアップも行います。Node.jsも扱いながら、CI/CDの作り込みなどバックエンド領域にも関わっています。
例えば、社内で複数のプロダクトで横断的に使われているライブラリが使いにくいという課題があり、その改善にも取り組みました。まずライブラリの利便性を高めるために、改めてその仕組みを設計し直したのですが、大変だったのは、それに伴ってライブラリのユーザー側のソースコードをアップデートすることでした。KARTEはそれなりに歴史の長いシステムになりつつあり、共通資産のボリュームはさることながら、それを利用するソースコードの分量も相応なものになっています。それらを一度に書き換えるのは危険なので、段階的に検証と移行を進められる方法を考えて実施したり、一つひとつ手作業で書き換えるのは手間が掛かるうえミスも増えるので、コードのパターンを分析して書き換えのためのスクリプトを作成するなど、効率的かつ正確に刷新できる方法を考えていきました。
このように各プロダクトのチームが手を回せないところをフォローしながら、プロダクトの開発者がやるべき業務に集中できる環境づくりに取り組んでいます。
――Design Engineerだからこそ、プレイドだからこそ得られるやりがいや楽しさはどんなところにありますか。
石本：僕はもともとWebデザイナー出身で、一度フロントエンドエンジニアにジョブチェンジしたという経歴を持っています。過去の話ですが、フロントエンドエンジニアでありながらデザインにも意見をすることで、難色を示されたこともありました。自分のやりたいことやできることと、業務としての立ち位置や役割の境界線に悩ましく思っていたところに、プレイドでこのポジションと出会えたことは、よかったなと素直に感じています。
僕自身は、フロントエンドエンジニアとしてのスキルは決して卓越したものではないと思います。でも自分にとってHTMLやCSSでUIを作ることはそれほど大変なことではなく、プレイドには反対に「CSSは苦手」という人もいて、「じゃあ僕がやりますよ」とお互いに得意なところで補い合える関係がある。自分の能力をしっかりと発揮できているのはこの役割の魅力だし、やりがいも感じています。
担当しているKARTE Craftの機能の中にはAIチャットによるサポート機能「Craft Copilot」などもあります。AIサポートは今のところ、テキストベースのコミュニケーションが主流ですが、これが他のインターフェースにできたら、音声入力でもできたらと想像するのも楽しいですね。
安田：先にお話ししたとおり僕はもともとデザイナー志望だったので、エンジニアとして業務にあたるなかでもデザインを通して自分を磨いてくることができていました。そういう姿勢や経験が今の仕事につながったのかなと思っています。
Design Engineerは、デザイナーでもありエンジニアでもある。どちらにも柔軟かつ能動的に関わることができることが面白いところです。このままDesign Engineerとして働くことはもちろん、本人の意向次第で好きな方向へ進むこともできると思います。キャリアの重ね方を考えたときにも、どちらにでもウエイトを置くことができるのは、性格的にも合っているような気がしています。
今携わっているデザインシステムについては、KARTEを中心としたマルチプロダクトのためのものというのが面白い部分だと思います。特性が異なるさまざまなプロダクトで機能させられるように、個々のプロダクトの事情だけではなくて、一歩引いて俯瞰した見方でデザインに取り組んでいます。
例えば、あるプロダクトで特殊なUIコンポーネントが実装されているとき、それを安易にデザインシステムに取り込まずに、もっと一般的なUIコンポーネントの組み合わせで表現できないかというような提案をしています。そうしたことが回り回って、デザイン全体として見たときのユーザビリティやアクセシビリティを向上させる結果に繋がるからです。
プレイドの“デザイン”の品質向上に貢献できる人を求めたい
――Design Engineerとしてのご自身の成長において、これからさらに強化したい点はありますか。
石本：Design EngineerはUIに集中できる環境にありますが、エンジニアが用意してくれたAPIを使う際、「もう少しデータが欲しい」と感じることもあります。例えば、リストUIに作成日を表示している場合、更新日でソートしたいとニーズがあっても、APIが更新日のデータを返していないことがあります。こういった場合に「このデータも追加してください」とエンジニアに依頼するのが気が引けることもあるんですよね。
そこで、全てを自分で対応するのは難しくても、足りない部分をある程度自分で巻き取れるようになりたいなと思っています。幅を出しすぎるとフロントエンドエンジニアの職域に近づいてしまう感覚もあるので、デザインやUIには軸足を置いておくということは、個人的に意識をしておきたいですね。
安田：僕は最近Developer Experience Teamの業務にウエイトを割きがちで、デザインシステムでの活動ができていないのが気になっているので、今一度注力していきたいなと思っています。デザインシステムには、ゼロベースでプロダクトをつくり上げていくのとはまた違った独特の難しさがあって、KARTEのいろいろなプロダクトに適用される「デザインのモデル」のようなものを考える仕事なので、さっきお話したような古いシステムへの適用や、複数のプロダクトへの影響も考慮する必要があり、課題が多いんです。
少し前のデザインシステムが今も適用されている部分があっても、それを使い慣れているユーザーもいるので、新しくしようと見た目をガラリを変えるとかえって戸惑わせたり、使いにくいと感じさせてしまうこともあります。手がつけにくい課題でもありますが、だからこそしっかりと検討し、解決していきたいなと思っています。石本さんと比べると、僕の考えや立ち位置はエンジニア寄りなのかもしれません。
石本：デザイン寄り、エンジニア寄りのどちらでもOKで、ある程度自由にスタンスを決めつつ行き来できるのがDesign Engineerのいいところですよね。同じ人でもプロダクトのフェーズやメンバー構成、タイミングによって変化することもあります。もちろん組織やプロダクトに求められた役割は果たしますが、自分のスキルの強みやスタンスは混ぜ込んで意思決定や活動ができていると思います。
――Design Engineerとしてジョインしてくれる人に求めたいスキルは何ですか。
安田：プレイドのプロダクト組織では、職種ごとのスキル・モチベーションマトリクスというスキル定義をしていて、プロジェクトのアサインや業務の分担、採用活動などの参考にしています。デザインエンジニアのスキル定義は次の通りです。
UIの実装
ビジネスロジックの実装
HTML
CSS
JavaScript/TypeScript
UIライブラリの構築
アクセシビリティの継続的改善と維持
DevOps
専門的コミュニケーション
情報収集と積極的学習
これらの項目ごとに、より具体的な詳細や目的、想定されるアウトプットなども併せて定義しています。
この定義に書かれているものがスキル要件に近いと思うのですが、この中で欠かせない要素だと、やっぱりUI実装やHTMLやCSSあたりの根幹的なスキルや経験は重視しています。あと、個人的にはアクセシビリティを大事にできるエンジニアは今後重視されるのではと思っているんです。アクセシビリティについては、近寄り難い専門スキルとして一線を引いている人が多いと思いますが、デザインするうえで欠かせない技能なので、今後啓発活動なども進めていきたいですね。
石本：スキル的な部分は最低限必要だと思いますが、デザインへの興味や関心があるということを第一に考えたいですし、面接でもそこはしっかりと見るようにしています。やはり「デザイン」を冠した職種なので、デザイナーの作ったものをしっかりと実装するためにエンジニア目線を活かして力を出せる人と仕事をしたいと思っています。とても感覚的な話ですが、個人的にはデザインとエンジニアリングが7 : 3くらいでデザイン寄りくらいの感覚で働いている感じもあります。
安田：僕は逆に3 : 7で、エンジニア的な役割や業務が多い気がしますね。自分の場合は、デザインを大規模に適用するみたいなことを考えることが増えて、エンジニア側の感覚にならないと進められないからというのもあって、今はちょっとそっちに寄ってます。
――最後に、プレイドのDesign Engineerとして働く価値を改めて教えてください。
石本：入社時に期待していたことから変わらず、突き詰めたいプロダクトのUI開発に集中できる、そこの価値に向き合えることが一番大きいですね。自分の志向にも合ってるし、強みが発揮できている手応えもあります。何を大切にすべきか、何をどう実現すべきかを自分たちで考えながらプロダクトや日々の業務に向き合えているので、本質的な仕事ができているように思います。
安田：何より仕事で取り組んでいることに面白さや価値を感じています。複数のプロダクト、しかもフェーズや体制などさまざまな要素が異なるプロダクトたちに展開される共通部分を担うデザインシステムづくりはやっぱり難しくて、面白いです。
あとは、繰り返しになりますが幅ですね。僕と石本さんの二人を切り取っても、業務や役割やスタンスにも違いがありますし、固定化されている部分が少ない。自身や周囲の活動を通じて、デザイン・エンジニアリングを軸に多様な刺激と成長を得られ続ける環境だと思います。こういった環境を楽しめる方、より一層面白い刺激を持ち込んでくれる方が、ますます増えると嬉しいですね。
■ プロダクトエリアの採用情報