エンジニアがプロダクトデザインの領域から挑んだ0→1開発

こんにちは！SmartHR プロダクトエンジニアの kabetch です。私はプロダクトエンジニアですが、プロダクトデザインにも興味があって携わるうちに、新規事業の開発を担当することになりました。今回は、その背景から具体的な取り組みまでをお話します。

背景

私はこの会社に入社してからずっと、プロダクトエンジニアとして働いてきました。一方で、プロダクトデザインの領域にも興味を持ち、社内のプロダクトデザイナーと一緒に機能の設計なども行なってきました。

そんな中、とある新しいプロダクトの開発を一から担当する機会に恵まれました。つまり、要件定義から実装まで、事業責任者の「こんなものを作りたい」というイメージを実現させるためのすべてを任されたのです。いわゆるプロダクトデザインの領域から自分がオーナーシップを持って進めていく必要がありました。

プロダクトデザインの経験

具体的にどんな活動をしてきたかをご紹介する前に、プロダクトエンジニアの私がそれまでにプロダクトデザインをどの程度経験してきたのかからお話しします。

冒頭でも触れたように、日々の開発業務を通して興味を持ったプロダクトデザインについて、社内のプロダクトデザイナーに弟子入りし、伴走してもらいながら機能設計を進めてきた経験がありました。概念モデルをまとめたり、UIを設計したり、仕様やUIについてなにかしらの意思決定を主導できるようにはなったと思っています。

見習いプロダクトデザイナーとしての活動は、こちらの記事をご覧ください。

note.com

一方で、これらの経験はすべて既存機能の再設計におけるものだったため、今回のように開発する機能がまだ具体的に定まっていない状態から始めるのは初めてであり、チャレンジングなものでした。

どんなことをした？

そんな自分が新規事業の開発にあたってどんなことをしてきたかをご紹介していきます。主に行なってきたのは、

ヒアリング
仕様やUIの設計
プロダクトデザイナーによるレビュー
詳細設計
実装

と、いざ書き出してみるとなにも特別なことはなく当たり前のことばかりです。しかし、それぞれの過程においてプロダクトを様々な視点で考える必要があり、非常に難しく、学びが多かったです。

ヒアリング

まずは事業責任者とともに、課題が存在すると考えられる領域について、その業務を担当している方々へのヒアリングをとにかく実施しました。多いときは一日に複数件実施することもあり、担当の方との業務の会話が盛り上がって時間が足りず、何度もお邪魔したこともありました。

課題を探るにあたっては、これから扱おうとしている領域が自分にとって初めてだったため、まずはしっかりと業務を理解することから努めていきました。その分野の書籍を読み込むなどもしましたが、やはりヒアリングを通して実務を担当されている方から直接話を聞くことほど業務の解像度が上がることはないと思いました。

このようなヒアリングを通して、やはり当初想定していた課題が多くの企業で存在することがわかってきたので、それをどのように解決していくかを考えていくことにしました。

仕様やUIの設計

ある程度実務や課題が明らかになった時点で、「なにを作るか」を考え始めました。

まずは、実際の業務の中でどの部分にどんな課題が存在しているかを整理し、この課題に対してこんなアプローチをすることで解消されるはずという仮説を立て、必要な機能について考えていきました。

必要な機能が見えてきたら、それを具体的な形にするために、概念モデルを整理しました。例えば従業員、書類、手続きなど、この業務にはどんな概念が登場してそれらがどんな関係性を持っているかを図示しながら整理していきました。

概念モデルが整理されてきたら、どのようなオブジェクトが存在し、そのオブジェクトがどのようなプロパティを保持しており、そのオブジェクトにどんな操作ができるかというように、より具体的なオブジェクトモデリングをしていきました。

この段階になると、具体的なUIの骨格が見えてくるので、デザインシステムを参考にしながら SmartHR UI の Figma ライブラリを用いてモックを作成していきました。モックを作ることで、ヒアリングの際に具体的なソリューションを相手に示すことができ、そこから「これができると嬉しい」「これはそんなに使わないかも」などの議論を引き出すことができ、更にソリューションをブラッシュアップしていくことができました。

なお、ここで行なってきた概念モデルの整理（抽象）からUIの設計（具象）は、このとおりの順序で行なっているわけではありません。様々な工程をひたすら行き来して（抽象と具象をひたすら行き来して）仕様やUIをより明確にしていきました。

プロダクトデザイナーによるレビュー

このプロジェクトにおいてオーナーシップを持っているのは私ですが、もちろんすべてを自分一人で行なわなければならないわけではありません。社内には頼れるプロダクトデザイナーがいます。ここまでやってきたことのレビューも何度もしてもらいました。

このあたりから、プロダクトデザイナーが参加している定例会やレビュー会にも頻繁に顔を出すようにし、今やろうとしていることを共有しました。

「オブジェクトの切り分け方は本当にそれで正しそう？」「選定したコンポーネントは利用目的からするとあまり適切ではないかも」といったようなフィードバックをもらって検討し直したり、「こういうことがしたいんだけどどう表現すればいい？」という相談に対してたくさんのアドバイスをもらったりしながら、仕様やUIの品質を磨いていきました。

レビューにおけるコミュニケーションの中では、自分たちがなぜその方針を選んだのかを説明することが求められる場合がありますが、なかなかはっきりと答えるのは難しいものです。作ろうとしているものに対して明確な「なぜ作るか」を持って設計していくことが大事だと痛感しました。

詳細設計

おおよその仕様が決まってきたら、実装のための設計を進めていきました。この時点ではまだ細かい部分のUIが確定していなかったりしますが、多少のUIの変更などは後から調整できるという考えのもと、「この機能ではなにができるか」が決まった段階で内部的な設計に取り掛かり始めました。

機能を使うにあたっての様々なユースケースを洗い出し、ユースケースごとに、登場人物、登場オブジェクト、シナリオ、操作によってどのような処理が走るか（このオブジェクトが作成される、このオブジェクトのこのプロパティが変更される）などを明確にしていきました。

ここではあまり細かな部分にまで時間をかけず、だいたいどんな感じの実装になりそうか、どんな開発タスクが必要になりそうか、などがわかる粒度で設計を進めていきました。

なるべく設計の途中の状態でも内容をオープンにすることを心がけ、他のプロダクトエンジニアからもフィードバックをもらいながら、小さく素早く価値を届けられるようにするためにブラッシュアップしていきました。

「どうやって作るか」を考えるにあたり、「そもそもなにを作らないか」を考えることは非常に重要です。特に、今回のように新規事業として自分たちの考えるソリューションが課題を解決するかという仮説検証を素早く回すためには、必要な機能に絞って小さく作っていく必要があります。しかし、実際にやってみると、

「ここまでリッチでなくてもこの機能でやりたいことは実現できるよね」
「この機能追加は今必要？」
「こういう設計になっていればこの部分は作らなくて済みそうだね」

といったフィードバックをもらうことがあり、まだまだ「なにを作らないか」の視点が足りていないことを思い知らされました。

実装

ある程度設計が進んだら、必要そうな開発タスクを洗い出し、それらを順番に並べたりブロッキングなどの依存関係を明らかにしたりして、開発のクリティカルパスを可視化していきました。

この時点である程度のリリース予測が立ってくるので、あとはリリースに向けてひたすら実装を進めていきます。この段階でもまだUIの確定していない箇所などはありますが、UIの細かな修正や更新は後々必ずあるものとして、まずは内部的なところから実装を進めていきました。

このようにして、なるべく小さく、なるべく素早く、でもなるべく手戻りのないように開発を進めています。

もちろんこれで終わりではなく、今後も様々な機能を開発する予定なので、このような動きを継続していくことになります。

ここまでの動きを通して学んだこと

前提として、デザインとエンジニアリングは不可分だと思っています。ここまでがデザイナーの仕事、ここからはエンジニアの仕事、というものはなく、すべての人が開発者としてプロダクト開発の様々な工程にコミットすべきです。この考えは弊社でも浸透しています。便宜上、私もここでは「エンジニアだけどプロダクトデザインの領域からやっていった」のように表現していますが、今回やってきたことは決してデザイナーだけの領域というわけではないと思っています。

とはいえ、このように”プロダクトデザインの領域”からエンジニアの自分がオーナーシップを持って、一気通貫でプロダクト開発をする経験は貴重であり、多くのことを得られたと思っています。

特に、以下のように様々な視点でプロダクトのことを考え、どのように実現するかを考え続ける経験は、開発者としての視座を高め、視野を広めるきっかけになったと思います。