ファインディのプロダクトデザインチームでは、立ち上げの段階からデザインから事業貢献をするために「デザインの生産性」を高める仕組みづくりに注力しています。

今回は、その中の一つである「予実の管理」についてまとめてみます。

ファインディのプロダクトデザインチームが取り組む「予実の管理」

不確実性が高く、成果に繋がったかどうかを測定しづらいプロダクトデザインの体制づくりにおいて、一つの参考になれば嬉しいです。

ファインディのデザイン組織には、プロダクトデザインチームがあり、3名のプロダクトデザイナーが所属しています。

ファインディのプロダクトデザインチームの体制

私(片寄)は2024年1月に入社後、今の予実管理の体制に至るまで、様々なアクションを通しプロダクトデザイナーとしてどう事業貢献できるかを考えてきました。

プロダクトデザインにおける予実の管理とは

  • デザインが携わった施策の及ぼす効果を事前にきちんと想定(予算、予測)し

  • リリース後に結果(実績)を回収し

  • 投資対効果はどうだったのか、正しくデザイナーの時間(リソース)が使われているかを振り返り次に活かす仕組み

のことです。以下のように、デザインをつくるだけでなくその前後の「予想する効果」「実際の結果」を明確にしていくような活動をしています。

ファインディで行う予実管理

つまり、プロダクトデザインの結果として、どれだけ事業KPIが向上したのか?を追いかけるということでもあります。

例えば「プロフィールページのUIを修正する」など一つ一つのプロジェクト単位で、「その改善がどのKPIに寄与するか」「本当に数値が向上したのか」をプロダクトデザイナーもきちんと数字を追っていきます。

さらに、そのために、施策ごとの目標設定や、要件定義、効果測定のしくみ化まで一緒に行う場合もあります。

プロダクト開発組織の体制によっては「つくった機能が、どれだけ事業数値を伸ばしたのか?」という数値目標はPdMが背負っている場合が多いと思います。

ファインディでも同様に、事業KPIの目標はPdMが持っています。

そういった背景もあり以前は「何をつくるのか、どういう要件にするか」をPdMが考え、プロダクトデザイナーは「言われた要件をUIとして具体化する」という役割に閉じていた時期がありました。

当時のプロダクトデザイナーの役割

もちろん責任範囲を明確にして運用する事は大事だという大前提はあるものの、本来「誰の、なんの課題を、どう解決するか」ということを誰がやるべきかについては、内部事情であり、実際に利用するユーザーには関係がないことでもあります。(つまり、誰がやってもよい)さらに、このような体制のためPdMに負荷が大きくかかる、いわゆる「PdM忙しすぎ問題」が起こってしまっていました。

私が入社した2024年1月は、スクラム開発が新しくスタートしたタイミングということもあって「PdM忙しすぎ問題」にさらに拍車がかかっていました。

そこで、毎週行っているスクラム開発mtgの振り返りの場で「デザイナーとしてもっとPdMの業務を手伝ってみてもいいですか?」という提案をさせていただき、「要件整理からPdMとプロダクトデザイナーで一緒に進めていこう」と決めました。

PdMの業務負担を下げていくために、プロダクトデザイナーから要件整理に入れるように

そこから、少しずつプロダクトデザイナーとして担う範囲を広げていきました。

ここからは実際に行ってきた施策をいくつかまとめてみます。

まずは、つくったものをどのような目的でつくるのか、「想定する効果」をキャッチアップし、具体化していくことに取り組んでいきました。

もともと、ファインディのプロダクトデザイナーは、言われた要件を丁寧にUIに落とし込むことが仕事の中心となっていました。そこから前述したような背景で「予実の管理」までを追いかけ始めます。

予実の管理を行うためには、依頼を受けるときに施策がどのような効果を想定しているのかを正しく可視化しておくことが必要です。

そこで、「何をどのようにつくるのか」という要件の整理にも関わるようにしていきました。

具体的には、PdMからデザイン依頼をもらった後、GitHubに概要が書かれたissueがあるので確認します。その後、プロダクトデザイナー側で用意している要件定義フォーマットを使って、ヒアリングしながら要件を一緒に詰めていきます。

PRDをもとに、要件具体化のためのヒアリングシートを活用して一緒に要件を具体化していく

プロダクトデザイナーとして要件を共に考えるようになって分かったことですが、ファインディもtoCプロダクトでよくある「ターゲットが幅広くなりがち」「KPIの複雑化」という状況に向き合っており、PdMも「この施策がどのKPIを高めるか」「なぜこの体験が必要か」を言語化しきれていないことがありました。

そのため、プロダクトデザイナーからも必要な観点を問いかけ、必要な情報が詰まっていなければ仮説を提示するようにしたことで、つくる前から「これを出すべき」だとPdMと共に確信を持ってプロダクト開発を進めることができるようになりました。

また、体験を言葉だけで具体化するのは限界があります。私自身、2024年1月時点では入社したてだったので、正確につくりたい体験をイメージできているか不安もありました。

そこで、要件のヒアリングのあとに、施策にまつわる体験の全体像を図解するようにしてみました。

体験の全体像をプロダクトデザイナーが整理する

図解した体験全体像をもとに検討し、また要件定義に戻り、、と、繰り返しディスカッションして要件を詰めていくようにします。

可視化することによって、PdMの頭の中にあった体験が、チームとしての仮説となります。

「予想する効果」を具体化できるようになったあとは、リリース後の「実際の結果」を追いかけられるようにすることにも取り組みました。

施策によって高めたいKPIや先行指標が決まっても、測定する仕組みがまだ整っていない場合もあります。

そのような時は、プロダクトデザイナーが提案したり、数値測定に関して推進することもありました

数値計測の仕組みがない場合、プロダクトデザイナーが主導してつくる(画像はイメージ)

さらに、プロダクトデザイナーとして、数値を扱えるようになる環境も整えています。

その一つが、ファインディのプロダクトデザインチームで毎日行う朝会です。

デザインチームで毎日行っている全体朝会の後に、プロダクトデザインチームでも朝会を行っています。その際、担当している事業の数値と状況を「毎日」報告し、互いにレビューをし合う文化があります。

毎日デザインチームの朝会で、自分の担当施策や事業の数値を報告

この取り組みを通して日々数値を報告していると、まずはKPIの数値がどれくらいかというのがわかってきます、その後はだんだん傾向が見えてくるようになります。その結果「あれ、この数値なら、この施策のままで良いんだっけ」と疑問が湧いてきます。

このように数値と日々向き合う事で、自分自身、事業数値に無関心な状態ではいられなくなります。

マネージャーの向さんも「なんでこの数値なの?」と背景を聞いてくださるので、どんどん事業のことが自分ごとになり、数値を意識したプロダクトデザインを行えるようにチームが成長していきました。

このように予実を管理できる体制が整ってきた段階で、さらに予実を合わせにいくための活動を追加していきました。

例えば、最近では、仕様段階から「本当にこの体験で事業数値を高められるのか?」という確認をするために、Lo-Fi / Hi-Fiプロトタイプによる検証を取り入れはじめています。

Lo-Fi / Hi-Fiプロトタイプでの検証の流れ

要件ヒアリングを終え、ワイヤーフレーム作成の段階で、Lo-Fiプロトタイプ (最低限体験を確認できるように作成した、たたき台としてのプロトタイプ) を用意します。

その上で、良さそうだとすれば、Hi-Fiプロトタイプ (正式なコンポーネントで、リリース前提で作成した精緻なデザインファイル) を用意します。規模の大きい施策や、ユーザーへの影響が大きい施策については、社内でメンバーに共有してフィードバックをもらい、ブラッシュアップをしていきます。

これで問題なさそうということになれば、実装を開始していくような流れです。

これらをすべての施策で行うのは、まだリソースの観点で難しいのですが、ユーザーにとって変化が大きいものや、新しいものであれば、必ず実装前に予実が合いそうか、体験に違和感などがないかどうかを検証していくようにしています。

四半期で追いかけているKPIに対して、今のタスクで足りているかどうかまで、デザインチーム内で先に議論してくることもあります。

実際、今のままでは足りないと判断したら、事業側と相談して、施策の追加を行うよう促したり、今の施策をストップして別施策に切り替えるような提案を、デザイナーから率先して行っています。

施策の優先度に関するディスカッションの様子

これらの取り組みの結果として、プロダクトデザイナーとして、信頼を得られるようになってきました。

以前は「何をつくりたい」という話が中心でしたが、それ以前の「KPIを高めるためには、どういうことをしたら良いか」という相談からもらえるようになったり。

あとは、オフィスでPdMやエンジニアが、デザイナーの席まで来てくれることも増えています。これも、ファインディのプロダクトデザイナーが、体験全体に責任を持ち、事業目線で動いていることを社内の他職種の方も理解してくれている証拠かなと思います。

結果として、この半年で、プロダクトデザイナーが関わった施策の事業数値も向上しています。PdMやエンジニアから、プロダクトデザイナーに対しての印象の変化について聞いてみたので、こちらに残しておきます。

PdMとエンジニアより、ファインディのプロダクトデザイナーに対する印象の変化

プロダクトデザインの役割は、UIをつくるだけでは貢献度合いが少ないはずです。

言われたものをつくるだけでなく「本当にこれをつくることで事業数値を高められるのか?」まで追いかけてやっとプロダクトデザインの価値が出せるのでは?と考えるようになった今日この頃です。

現在のプロダクトデザインの体制について

ファインディにおいて、ここまで役割を拡大できるようになったのは、デザイン組織としての信頼が積み上がってきていたからです。

また、「結果を出せるデザイン組織である」ということを、プロダクトデザイン・コミュニケーションデザインの双方から社内全体に示していくことが必要です。

ファインディのプロダクトデザイナーの理想は、限りなくPdMに近い役割を持つことです。

あくまで事業数値の最終責任を負っているのはPdMですが、体験の観点から、プロダクトデザイナーとして事業に貢献していくことを追い求めています。

ファインディのプロダクトデザイナーの理想は「限りなくPdMに近い役割を持つこと」

今後もデザインの生産性を高め、事業貢献できる組織づくりに取り組んでいきます。

このデザイン組織をもっと知る

ファインディ