さらば、全てのプロダクトデザイナー。デザインの判断基準をエンジニアが持つための活動とは？

こんにちは、SmartHRプロダクトデザイングループの@kgsiです。
先日、弊社のVP of Product Designの@oujiがこんな記事を公開していました。

みなさん、これを読んでどう思われましたか？内部からみてもよくわからんのが本音だったりするのですが、何故か魂がザワザワしました。

さて、記事の中で繰り返し述べられている「ヘヴィメタル」と、今回ご紹介する内容がマッチするかはわかりませんが、プロダクトデザイナーが関わっている、プロセス改善活動をご紹介します。

プロダクトデザイナーの責任とは？

VPはヘヴィメタルな記事の中でこう述べています。

SmartHR ではお前がお前の責任（インターフェース品質）を果たすためなら、お前はどんな成果の出し方を選んでもいい。

弊社、特にプロダクトデザイングループにおいては、成果の出し方(＝プロセス)が限定されていません。つまり、プロダクトのインターフェース品質を向上させる、最良のものにするという共通の目的さえ果たすことができるなら、その手段は問わないということです。

職種やポジションなどの枠にとらわれすぎることなく、各々があらゆる手段（ユーザーリサーチ、デザインシステム、アクセシビリティ、プロダクトマネジメント）を通し、最適解を導き出す方法を模索していく...というスタンスですね。

そんなスタンスから生まれた活動が、プロダクトエンジニアに「デザイン」の判断を身につけてもらう活動、通称「エンジニアデザイナー化計画」です。

「エンジニアデザイナー化計画」とは

SmartHRの開発グループは、フィーチャーチーム構想を掲げ、クロスファンクショナル化 （※1）の取り組みを進めています。
顧客の求めるフィーチャーを実現するために、チームにはプロダクトを作るために必要な「機能」が揃っていることが求められましたが、プロダクトデザイングループの規模の都合上、全てのエンジニアチームにデザイナーが常に関われる状態ではありませんでした。
（※1 参考:  https://tech.smarthr.jp/entry/2021/03/29/113327）

そのため、プロダクトデザイナー以外でもプロダクトデザインの意思決定を行える状態をつくり、「デザイナー待ち」のリードタイム（※2）を無くしていこう、というのが「エンジニアデザイナー化計画」のコンセプトです。
（※2 本来は製品の開発から顧客の手元に届くまでの期間を指しますが、この場合はハイファイなモックやデザインの意思決定にかかる期間を指します。）

計画の目標

この取り組みの目的は広義の「デザイナー」になることではなく、プロダクトデザイナー以外がプロダクトデザインの判断基準を持ち、意思決定ができるようになることです。具体的には以下の状態を目指しています。

- プロダクトデザイナー以外がプロダクトデザインの意思決定を行える
- 「デザイナー待ち・デザインモック待ち」のリードタイムがなくなる

活動内容

デザイナーが持っている判断基準をプロダクトエンジニアが持つためには、中長期的なプロダクトデザイナーをはじめとした支援はもちろんですが、自発的な学習と意識変革が必要不可欠です。それを支援する活動はさまざまありますが、代表的な活動を紹介します。

1.モブレビュー会
プロダクトデザイングループでは、各機能のUI設計で悩んでいたり、デザイナーによるレビューを必要としたりしている仕様について、モブレビューを通してレビューしあう会を定期的に実施しています。

この会にエンジニアも参加してもらうことで、デザイナーがどのような思考や判断を持ってプロダクトの画面設計・UI設計をしているかを学んでいます。

なお、この会自体は、PMやUXライターなど、デザインに関心があれば肩書や役職に関わらず、だれでも参加できる会となっています。

2.OOUI輪読会
各開発チームに所属する、デザインに興味があるプロダクトエンジニアが自主的に集まり始められた輪読会です。
もともとは「オブジェクト指向UIデザイン」(UI設計手法のひとつであるオブジェクト指向についての指南書です)って本があるよ、と軽い気持ちで紹介したのが始まりですが、それに関心を持ったエンジニアが集まって輪読するようになったのがはじまりです。

（Miro上で複数人で行われているワークの様子）

現在はエンジニア以外も集まって週1回定期で開催されており、座学からワークまで通しで行われています。

3.チーム単位での啓蒙・活動
個々の開発チームで活動の細部が異なりますが、例として自分が所属するチームでの事例を紹介します。

例えば開発工程ではデザイン作業のチケットを作り、ブラックボックス化を防ぎつつ、インターフェースの設計に対して意見がしやすいよう努めてます。また、新たに決まったルールや、レイアウトの良し悪しなどの、リファレンス共有なども定期的に行っています。
更に最近では一歩踏み込んで、計画のコアメンバーとなるエンジニアと一緒にプロダクト全体のインターフェースの状態仕様を一緒に考えて、ルールを起草する...といった試みを始めています。

（チームにおけるプロダクトデザイナーの動きを可視化する試み）

組織全体で見てみると、現在は、デザイナーの数が計画開始当初よりも増えたため、各チームへの啓蒙が広くできるような状態になってきました。
それぞれの開発チーム内でモブデザインや、Figma（デザインツール）の勉強会などが開催されています。

4.設計や意思決定を支えるためのデザインシステムの準備
繰り返しになりますが、この取り組みの目的は「デザイナー」になることではありません。
広義の「デザイン」に関する深い知識は必ずしも必要ありませんが、SmartHRの既存ルールやパターンなど、インターフェース設計のためのナレッジ、ドキュメントは必要です。

SmartHR Design Systemは、だれでも・効率よく・迷わずにSmartHRらしい表現をするためのデザインシステムとして日々更新されています。インターフェースの設計ルールや文言やコンポーネントの使い方などを網羅しているこのドキュメント群は、活動に必要不可欠な存在となっています。

SmartHR Design System

はじめてよかったこと

計画を宣言して始めてから半年経ちますが、観測している限り徐々に好ましい状況が生まれつつあります。
活動前は、インターフェース設計はデザイナーが事前に作業し、開発チームにハイファイなデザインモックを渡す...という、受発注関係で仕事が回っているケースがほとんどでしたが、自分が所属する開発チームでは徐々にその流れに変化がおき、最近ではエンジニアからのインターフェースに対しての意見、提案が増えてきました。

また、学習支援やガイドラインの啓蒙により、開発実装時にデザイナーが想定していなかった状態への表示提案、改善提案の機会が生まれつつあります。

これからの課題

SmartHRの開発組織全体で行われている、クロスファンクショナル化の動きも相まって、チームのマインド変化は、目に見える形で観測できています。ただ、実際にフロー効率が上がってめちゃくちゃプロセスが改善した…と、言い切れるまでには成っていません。

また、この活動の主体は有志のプロダクトエンジニアによって進められているので、個人の活動に寄りがちです。偏りがないようにチームや組織としての目標として、長期目線で実施していく必要がある、と感じています。

最後に

そんなわけで、プロダクトデザイナーとして「責任」を果たすために、デザインの判断基準を持てるエンジニアを増やそうとしているよ！というお話でした。SmartHRの「ヘヴィメタル」を少しでも翻訳したつもりですが、ご理解いただけましたでしょうか？

なお、これらの活動内容も一定ではなく、組織やチームの状況に応じて柔軟にアップデートされ、別の、新たな活動に変化するかもしれません。
プロダクトデザイングループは技能や手法にとらわれず、インターフェース品質への「責任」を果たすための活動を模索してくれる方を募集しています。

また、新たな境地を開き、クロスファンクショナルに活動して事業に貢献したいプロダクトエンジニアも絶賛募集中です。

職域や領域にとらわれない働き方に興味がある、あるいは「ヘヴィメタル」がわからないとお嘆きの方、カジュアル面談でも構いません、一度雑談しましょう。

SmartHR エンジニア採用