こんにちは！ SmartHRでバックエンドエンジニアとして働いているkobadaiです。
以前スタンディングデスクを買ってみました - SmartHR Tech Blogを書いたことがあるのですが、この記事を読んだ知人から「本当に仕事してんの…？（´・ω・`）」と疑いの目を掛けられてしまいました。 ですので今回は真面目なテイストで私が取り組んでいるバックエンドエンジニアとデザイナーの兼業について書きたいと思います。 なにとぞ、よろしくお願いいたします。
ことのきっかけ
SmartHRに入社してしばらく経過したころ、ある機能の改修を行った際に今までSmartHRの機能の中では実装されていないUIを考える必要がある開発アイテムに遭遇したことがありました。 当時のチームには専属でデザイナーが所属していたのですが、「デザイン業、なんかおもろそうやな……」とソワソワしているとその方から「おう坊主！そんなところで見てねーで、こっちきて一緒にやるか！！」と声を掛けていただきました。 私はそのデザイナーの方と共同でUIを考えることになりました。
そのUIは「どれかを必ず選択しなければならない」「特定の選択肢を選択した場合は、その詳細を選択する必要がある」というものでした。
ごくごく簡単なものでしたが、選択肢それぞれに対し説明を入れなければ理解が難しかったりします。 デザイナーのメンバーと要件を踏まえたうえでユーザーが必要としているものはなにかということまでを含めた情報設計を一通り行った結果、「デザインの作業」というものの複雑性と面白さを同時に体験できたことがデザイン業に足を踏み入れるきっかけになりました。
また、kabetchさんというエンジニアとデザイナーを兼業している良き手本となる方が社内にいらっしゃることや、自社でSmartHR Design Systemというデザインシステムを持っているということもあり、エンジニアがデザイナーを兼業することへの心理的なハードルの低さもありました。 これらも私の背中を押してくれる要素であったことは間違いありません。
なぜはじめた？
デザイン業を経験して以降、細かいUI改修が発生するとその度にデザイン業に積極的に参加していたのですが、あるタイミングで開発の体制が「1人のデザイナーが常にチームに常駐する体制」から「横断的に複数の開発チームと協業する体制」へ移行し、「必要に応じてデザインの相談相手としてプロダクトデザインチームを活用してください」という方針になりました。
フィーチャーチームからデザイナーが抜けることでそのチームは特定の職能を一時的に失うことになりますが、 ふんわりと軽度のデザイン業を経験していた私は
「これはチャンスでは？」 「エンジニアやりながらデザインもできれば色々お得なのでは？」
と考え、デザイン業も担当していくことにしました。
デザインとエンジニアリングの境界をまたぐ
アプリケーション開発において、デザインとエンジニアリングはそれぞれ重要な役割を担っています。 しかし、この二つの間には時として必ずしもスムーズに噛み合うものでもなく、理想と現実のギャップに打ちのめされることもあります。 エンジニアが直面する「技術的な制約」と、 デザイナーとして追求すべき「理想的なUI」の狭間、 つまり冷静と情熱のあいだで、二人は恋に落ちる理想形を探していくことになります。
冷静と情熱のあいだにある課題
デザイナーが作った「理想的なUI」とエンジニアが認識している「アプリケーション上の技術的な制約」がうまく噛み合わず手戻りが発生することがあります。
工程としてはデザインがエンジニアリングよりも前の段階にあることが多いのですが、上記で生じた課題が後になって顕在化し、再設計や実装のやり直しに時間が取られてしまうこともあります。 これが繰り返されてしまうと、プロジェクトの進行に少なからず影響を与えてしまいます。
どのような存在がいるとよいのか？
では、そのギャップを埋めるにはどうすればよいのでしょうか……。
理想を言えばデザイナーとエンジニア間の情報共有や意思疎通が完璧な状態であることなのですが、人間は不完全な生き物なのでそううまくいかない場合があります。 そこでソリューションのひとつとして挙げられるのが、「技術的な制約を理解したデザイナー」や「デザインの感覚を持つエンジニア」という役割です。 このような人材がいることで、以下のような効果が期待できます。
- 技術的な制約を考慮した現実的なデザイン案の作成
- デザインと実装の間のギャップを最小化し早期段階での課題解決による手戻りの削減
「仕様策定」や「プロトタイプ作成」の段階から関わることで、プロジェクト全体を効率的に進めることができる可能性があるわけです。
ある種の理想のモデルとしてのGoogleの「UXエンジニア」
調べてみると、Googleではこの役割を「UXエンジニア（User Experience Engineer、略してUXE）」と呼称しているそうです。 この役割が、「ほしい存在」の答えの中のひとつなのかも、と私は考えたのでした。
細かいことについては上記のページに載っているのでざっくりとまとめると、 デザイナーなどのエンジニアリング以外の専門的知識を持ち合わせたエンジニアがそれに該当するようです。 エンジニア領域以外の知識をエンジニアとしての業務に取り入れることができ、この兼業はエンジニア観点でのフィードバックを設計プロセスの早い段階で取り入れ、逆にエンジニアにもデザイナー観点からのフィードバックを提供するのに最適な立場でもあります。
私の職務はバックエンドエンジニアですが、 まがいなりにも機能の構成要素を洗い出す→必要に応じてFigma上にデザインファイルを作成する→プロトタイプを構築する→実装するを繰り返した結果、なんとなく結果的にそれっぽいことをやっているんだなあということがわかりました。
私が実際にやっていること（現実的なはなし）
ここからは私が社内で実際にやっているお仕事について書いていきますね。
私はSmartHRでバックエンドエンジニアとして在籍しつつ、社内で野生のプロダクトデザイナー見習いとして働かさせていただいております。
SmartHRにはSmartHR Design Systemというデザインシステムが存在しています。SmartHR内のデザイン業では前提としてこのデザインシステムへの理解が必要となってきますが、これが存在しているおかげで「決め」に迷いが生まれることが少なくなります。 多種多様なプロダクトのUIの根本的な考えが統一されているのも、このデザインシステムがあるおかげとも言えます。 誰が実装しても、ある程度は同じ方向に向かって実装していくことができるのです。 それはデザインのみならずライティングに関しても同じです。
ですが、実際に業務に落とし込もうとすると様々な制約が発生します。
- 連携する別のシステムによる制約
- 工数
- 既存のアプリケーションによる技術的な制約
自分の年金の問題老後への不安- etc...
私は普段からこれらの制約をエンジニアとして理解しつつ、デザイナーとしては可能な限りの「理想」を提案し、エンジニアとして実装して提供することを心がけています。
つくるモノによってはデザイン→UXライティング→コーディング（フロントエンドまで含むこともある）を結果的に一気通貫でやることもあります。 その一種の貫徹力みたいなものが、モチベーションにも繋がってきます。
それぞれの工程で発散と収束を行ったあと、各分野のレイヤーを重ね合わせて「良い落とし所」を見つけることになります。
各工程で行うことは簡単にまとめると以下のような流れになります。
1.仕様検討
担当するフィーチャーがユーザーが感じているどのような課題の解決を目指しているものかをPMと紐解いていき、PRD（製品要求仕様書）に落とし込んでいきます。 ここではエンジニア人格とデザイナー人格の両方をぼんやりと活用し作業します。 この作業はフィーチャーリードのPMで行うことが多いですが、最近はフィーチャーリードを担当していないときもデザインたしなみの民としてこの場に呼ばれることが多くなりました。（嬉しいですね）
2.情報設計
やるべきことの大枠と方向性が提供フェーズごとに決まったら、最初のリリース段階でのデザインを考えていきます。 ここでは主にエンジニアの人格で作業します。
- 操作の対象はなにか？
- アクションはなにが必要か？
- 必要な情報はなにか？
これらを主にエンジニア人格で情報設計のアウトプットの概念に従いMUST、WANT、Nice to haveの三つの分類に分けて順序立てて考えていきます。
3.UIデザイン
ここはデザイナー人格の出番です。 デザインを示すためにSmartHRではFigmaを使用しています。 オブジェクト指向UIデザインをベースとして、ボード上にデザインを思いつく限り列挙していきます。
当然最初から最適解を出すことはできないので、最初の段階では特にアプリケーションの制約は考慮せず案を出していきます。 とにかく発散させます。 ただし、どれもSmartHR Design SystemとUIデザイン使用性チェックリストから逸脱しないことを意識します。
デザインの大枠が出てきたら今度はエンジニア人格を引っ張り出し、アプリケーション上の制約を鑑みて既存のコードの要件に収められるように調整を行います。 デザイナーはユーザーからフィードバックされたユーザー体験を元にベストなものを考えますが、 エンジニアはそれを既存のコード上の制約に収まるように調整する必要があります。
SmartHR本体の機能はだいたいのイメージで話すと、長野県の森の木の本数ほどのコードで成り立っているのですが、私が把握していて自信を持って説明できるのはそのほんの一部ということで、おごらずに自信がない場合は各機能に精通したメンバーにヒアリングを行うこともあります。
4.ライティング
デザイン段階で同時に重要になってくるのがライティングです。 ここではデザイナー人格が6割程度で行動します。残りは画面操作をするユーザー人格と、ほんの少しのUXライター人格で考えていきます。
UIデザインが「見た目」や「操作性」を担当するのに対し、ライティングはそのプロダクトがユーザーに伝えるメッセージを設計します。 画面上の文言はユーザーの意思決定や行動を導く鍵となり得ます。 ライティングしたい内容でデザインが変わり得ますし、ライティング次第でデザインが良くなることもあります。
画面を操作するユーザーは、それぞれ画面操作に対する習熟度が異なります。 なので、可能な限り自らの中に存在する画面操作をする人格の習熟度を落としてみて、それでも理解できるようなものを考えていきます。 ユーザーは基本的に文字を読まないという前提を念頭に可能な限り簡潔な文言を用いることを心がけます。 ときにはUXライターのメンバーにヘルプを要請し一緒に考えてもらうこともあります。
3と4で大切なのは、デザインの根拠をしっかり持つことです。 デザイナーやUXライターはその選択が単なる感覚や個人的な好みではなく、論理的な理由やデータに基づいたものであることを説明できなければいけません。 デザインに根拠があるということは、それがユーザーのニーズや課題を解決するために作られていることを示すからです。
5.デザイナーのレビュー会にもっていく
収束させた案をレビュー会に持ち込み、デザイナーからのフィードバックを得ます。 ここでは説明時はデザイナー人格とエンジニア人格の半々で、レビューを受けるときはデザイナー人格で臨みます。
デザイナーのレビュー会は、いわゆるチャンス★タイムです。 色んな方向から美味しいおにぎりが飛んでくるイメージです。 言葉でのフィードバックだけにとどまらず、時間を決めて全員でモブデザインを行うこともあります。 担当領域が異なるデザイナーが一つのプロダクトのUIを考えると生み出されるものは多種多様で、目からウロコが落ちる思いになります。
レビューが終わったらレビュー内容を精査していきます。 エンジニア人格ではコード上の制約になぞらえ取捨選択を、 操作するユーザー人格では案を前提としたシミュレーションを行い、 デザイナー人格で再度UIデザインに落とし込んでいきます。 Figma上でプロトタイプを作成するのもだいたいこのタイミングです。
6.チーム内で共有を兼ねたモブデザインを行う
レビューが終わったら開発チームに持ち込んでモブデザインを行います。 開発メンバーにデザインをはじめて正式に公開するのもこのタイミングです。 ここはデザイナー人格で臨みます。
デザインの根拠が説明できることでデザインの意図や決定を他職種に正確に伝えることができます。 「なんとなくこのデザインにした」といった曖昧な説明で不信感が生じたり、想定していなかった懸念点などが他のエンジニアのメンバーから出てきたときに代替案を論理的に議論できない、といったことを防ぐことができます。
また、デザインの根拠を示すことで、チーム内でUIデザインに対する見識が高まり、 Plan Cが飛び出るなどの副次的な効果が発生します。 より一層チーム全体のUIデザインに対する視座を高めて議論をすることができるようになります。
7.社内の労務担当者などからフィードバックをもらう
現場（実務を行う人）に近い職務（カスタマーサクセスや社内労務）のメンバーにFigmaのプロトタイプを持ち込んで見てもらいます。 ここではデザイナー人格で臨みます。
ユーザビリティテストの社内版といった雰囲気でざっくばらんに進めていきます。 操作者にはロールとタスクだけ開示し、デザインされた画面の根拠や操作方法等は説明せずに実際に触ってもらいます。
操作感のフィードバックのみならず、前段階で知ることができなかった「実はこういう活用のされかたをしている」といった現場レベルの豆知識を得られることもあり、それらを包括して改善のプロダクトバックログアイテムを作成することもあります。 このタイミングで「UXはUIから生まれる」という実感を持つことができます。
フィードバックいただいた内容はデザイナーのレビュー会のときと同様に精査してUIデザインに取り込んでいきます。
8.デザインのまとめドキュメントを残す
上記3から7の工程を一通り行い、デザインが固まったらデザインの概要をまとめたドキュメントを作成します。 これはデザイナー人格で行います。
Figmaファイルでは目的の部分のデザインがどこにあるのかを探すというコストが発生してしまうのでドキュメント化しておいたほうが一目でわかりやすいという利点があります。 要点は押さえつつも基本的にエンジニアのみならずPMやその他職種のメンバーが見ても理解できるレベルにまで情報を簡素化する必要があり、アウトラインを意識して報告型のドキュメントを完成させます。
完成したら関係者に共有を忘れずに！
9.コーディング
ここではエンジニア人格を主として臨みます。 内容は世のバックエンドエンジニアが行っている作業と変わりないと思いますが、 フロントエンドのコーディングが軽微な場合は積極的にフロントエンドのタスクも担当していきます。
ここで稀に仕様検討時やデザイン段階で拾いきれていなかった問題がでてくることもありますが、 エンジニアとデザイナーの人格をフル回転させてシュッと追加対応を行ったり、解決に時間がかかりそうな問題は別のプロダクトバックログアイテムを切って部分的なデザインの修正を行う判断を下したりします。 ですが兼業によって判断のコストをあまりかけずに対応できることが多く、兼業の恩恵を感じられることが多々あります。
場合によっては実際のユーザーにユーザービリティテストを行っていただきフィードバックを得ることも検討します。 ここではコード的にある程度完成されていて実際に動く画面を触ってもらうことが多いです。
現場の生の声はまさにユーザー体験そのものなので、デザインにおいての「知」となります。
10.レビュー〜テスト
こちらもエンジニア人格で行います。 バックエンドエンジニアですがバックエンドのみならずフロントエンド、特にビュー側のレビューも積極的に行います。
また私が所属しているチームではレビューと同時にデザイン確認というタスクも発生します。 デザイン時点ではUIデザイン使用性チェックリストに準じたデザインを行っていますが、コードに落とし込まれたときにそれが基準に準じているかを確認するために行っているタスクになります。
大事なのはチーム内でデザイン確認が誰でも行うことができるようになること、違和感や可用性を損なっていることに気づくことができるようになることなので、独自に「デザイン確認の手引き」としてドキュメントを展開しています。
コードに落とし込んで成果物ができたときに実際に触ってみると 「キーボード操作でこのボタンが触れない！」 「この文言、重要そうなのにスクリーンリーダーで読み上げてくれない！！」 ということが稀に起こるので、品質の担保という意味で実はこの工程がかなり重要だったりもします。
11.リリース後の観測
あとは満を持してリリースし、実際のユーザーの反応を観測する段階に入ります。 ユーザーの体験はRedashで定量的に観測できるものではありませんが、都度ヒアリングを設けたりお問い合わせをいただくなどのフィードバックを元に改善のタスクを作成してプロダクトをよりよくするためのサイクルを回していきます。
まとめ
難しいけど世界が広がるし、リードタイムは短くなる
UXエンジニアの概念の説明だけ見ると全知全能っぽいですが、 デザイナーとエンジニアで種類の違う考え方を持たなければいけないので、やはり脳のリソースを使います。 右脳と左脳がくっつきそうです。
ですがデザイナーの観点が加わることでエンジニアリングにおいても新しい視点での考え方が生まれることがあります。 つまり、プロダクトに持たせることができる可能性が広がります。
デザイナーとして提供する案とエンジニアとして提供する手段がガッチリ噛み合うまでのリードタイムを短縮できますし、噛み合ったときのスッキリした感覚は何にも代えがたいです。
UXのためのアプローチのひとつとしてUIを考えるのだなと、エンジニアが認識できる
これらの工程を経ることで、どんな状況であってもUIは無視できないことがわかりました。 UXは「作り手が理想とする体験」ではありません。 UXはあくまで「ユーザー自身の体験」を元に生まれるものであり、その入口はUIデザインに在るからです。 なので、我々はUIをデザインしているのですね。 「我々エンジニアでもUIを考えたり、はたまたコード側で解決するといったことができる道もあるよ！」 「そしてそれが実際にユーザーに使われて、ユーザー体験を観測することで次に繋げることができるよ！」というサイクルによって、製品がより良くなっていくということを学びました。
まだまだ未熟なので思考で時間が溶ける
デザイン業に没頭していると自分の中では数分しか時間が経っていない感覚があっても現実では数十分が経過してしまっているということが稀にあります。 Figmaを触っているうちに楽しくなってしまったり、「より良いUIとは……」という禅問答じみた問いかけが無限に発生してしまうことが原因です。 まるでブラックホールに飲み込まれていく感覚です。
ですので、「迷ったら相談する」ことは大事です。 師となるメンバーやアドバイスを貰うことができる環境で始めてみるとより良いと思います。 ひとりよりふたり、ふたりよりさんにん。
デザインとエンジニアリングを丁度良い塩梅で融合させ、プロダクトを良い方向に推進させることができるエンジニアを目指し、今後も精進していきたいです。
We Are Hiring!
SmartHRでは一緒にめっっっちゃいいプロダクトを作っていく方を募集しています！ そして私がそうさせていただいているように、所属する部門以外の職能にチャレンジすることができる文化があります。 「エンジニアだけどデザインもやってみたい！」など少しでも興味があれば、是非カジュアル面談のお申し込みからよろしくお願いします！！
