「優先度が低くてUI改善は後回し」「エンジニアのリソースが足りないから施策が動かせない」
このような声が起こるのは、実はチームで「何をつくるか」の認識が揃っていないことが原因かもしれません。
GA technologiesが運営するAI不動産投資「RENOSY」の社内システム開発チームでは、チームメンバーが課題の認識を揃えるための「課題ドキュメント」「共通認識ワークショップ」という仕組みをつくり、PdM主体なものづくりからチームでのものづくりへとワークフローを更新しました。
私たちが取り組んだ課題や、プロダクトデザイナーが主導した共通認識のつくり方について共有します。
このような仕組みが生まれたのは、RENOSYのAsset Planner（アセットプランナー）（※）が活用する社内システム「物件検索・提案ツール」のUI改善の相談を受けたことがきっかけです。
社内システムということもあり開発優先度は下がりやすく、これまで専属のデザイナーは不在。アセットプランナーから受けた機能要望に対してPdMが都度エンジニアに依頼をして、エンジニアは少ない工数で何とか実装を進める流れになっており、プロダクト全体の体験や細かなユーザビリティは考慮しきれていない状態でした。
ただ、「物件検索・提案ツール」は社内のアセットプランナーが毎日利用するプロダクトです。さらにはアセットプランナー経由でお客さまも目にするものなので、改善が必要であることはみんなが分かっていることでした。
そこで「やはりUIや体験を改善していきたい」というPdMからの相談を受け、プロダクトデザイナーとして白川、渡邊、豊竹の3名がチームに参画することとなります。
私たちへの依頼のタイミングで、すでにPdMがいくつかアイデア出しやアンケート回収を行ってくれていたのですが、そもそも私たちがプロダクトの全体像をキャッチアップできておらず、デザインデータも整備されていなかったので、まず本番環境を見ながら全ての画面を洗い出してFigma化することから始めました。
そこからデザイナー目線でのUI改善案を出してPdMと話してみたのですが、うまくプロジェクト開始に至ることができませんでした。
一度はPdMも良さそうと思ってくれて持ち帰るのですが、その後エンジニアやアセットプランナーと話してくると「やはり開発工数が限られていて品質改善系のプロジェクトにリソースは割きづらい 」「事業課題とのつながりが弱くプロジェクトの合意が取れなかった 」という結論に変わってしまっていました。
「これは、なぜうまく課題が伝わらないのか？を丁寧に深ぼらなければ開発を始めることもできなさそうだ」と思い、そこからはチームの課題を探りにいくためにエンジニアやPdMとの1on1を始めました。
1on1の中でPdMとしては「ビジネス的な要件につながるものでなければ納得してもらいづらい」と思っていることが分かりました。UI改善案とビジネスインパクトのつながりまで示せなければPdMはコミュニケーションしづらいということに気づきます。
またエンジニアとしても「要望に対して都度開発をしてきたので技術負債がある」「本当はボトムアップで提案もしたいけど余白がない」など、技術負債や開発プロセスに問題意識を感じていることが分かりました。
このように課題を整理していくと、チームの課題は「リソースの少なさ」というよりも「コミュニケーション方法」なのではないかと思えてきました。
現在のフローはPdMが各ステークホルダーに対して「これをつくります」と伝えて回るコミュニケーションが中心になっていて、開発チームやアセットプランナーと課題認識がすり合っておらず納得感が生まれていませんでした。
「それは間違いなく課題だ」「解決するとビジネスインパクトも大きい」とみんなが思えれば、リソースが少なかったとしても必ず取り組むことになるはずです。私たちがまずやるべきはUI改善などのソリューションの議論ではなく “課題中心のコミュニケーション” をできるような体制へと変えることだと捉えました。
チーム全体で “課題中心のコミュニケーション” を行うためにも、根拠集めに取り組み始めました。まずは定性的な情報として、使っている人の具体的な行動や課題をさらに理解していくためのインタビューを行います。
社内のアセットプランナーを新卒・中堅・上級者に分け、1人あたり30分から1時間くらいの時間を取ってもらい合計4名にPdMと一緒にインタビューしました。「物件検索・提案ツール」を普段どう使っていて、どこに課題感があるのかを確認し、インタビュー中に画面を触っている様子も観察します。
ヒアリングした情報はペルソナ・課題・ユースケースとして図解しました。元々こういうものはチームでつくっておらず、デザイナーもPdMもエンジニアもそれぞれが別々のユーザーを思い浮かべていたような状況だったので目線を合わせるためにつくりました。
定性だけではなく、定量データも同時並行で取得していきます。定量で悩みの大きさや影響範囲の広さを示せると施策の合意が取りやすくなるはずなので、どちらも重要なデータになります。
システム全体のUI・体験の評価を網羅的に聞くためのアンケートを用意し、PdMにも確認してもらった上でアセットプランナーに回答してもらいました。
またアンケートだけでは定量的な根拠が示しづらそうな部分 (ex. クリック数) なども定量的に示せるようにGoogle Analyticsを導入。知りたい項目をプロダクトデザイナー側ですぐ取得できるようにしました。
具体的には、そもそもGA4やGTMを利用して正しくデータを取る仕組みができていなかったので、正しくデータを取れるような土台作りとして「どこをとるのか」「どんな命名がいいか」「トリガーは何と定義するか」を整理するところから導入・運用まで整備しています。
次に、回収した定量・定性の情報から強い課題を絞り込んでリスト形式でまとめます。
当初提案したUI改善案リストと違うのは、課題だけを並べていることです。チーム全員でものづくりを進めるためにもまずは課題をオープンにして、何に取り組むべきかを全員で話せるようにするべきだと考えていたのでこのようなまとめ方にしています。
さらに、この課題の一つひとつには、定量・定性の根拠をつけた「課題ドキュメント」を紐づけています。スプレッドシートは一覧で優先度を決めやすくするものだとしたら、ドキュメントはその内容や根拠を確認して取り組む課題を意思決定するためのものです。
ドキュメントによって微妙に入れる情報は異なりますが、基本的には「定性的に困りごとが生まれている」「定量的にもニーズが大きい」という流れで誰が見ても納得感が生まれるような構成にしています。
ドキュメントには課題を解決した時の投資対効果・KPIの変化予測などもまとめるようにしました。
最初にデザイナー目線でUI改善案をまとめた時の反省は、ビジネスインパクトが見えづらかったことでした。PdMがビジネス部門の方と施策合意や承認を取りやすくなるように、このドキュメントでは「具体的にこれをやることによってどのくらいコストカットできる」ということまで書くようにしました。
課題ドキュメントの中では、具体的なUIの改善案の話は「あくまでソリューションの可能性としてあり得る」という程度の記述にとどめています。
「ソリューションを具体的にどうするか」という話は全く別の話だと考えていて、まずは「これは定量的にも定性的にも本当に悩みが大きいし、投資対効果もあるから解決すべきだ」とみんなが分かることが大事だと考えて設計しています。
課題リストと課題ドキュメントをまとめた後は、PdMに共有してビジネスインパクトや即効性の観点で優先度が高そうな課題を2つ選んでもらいました。
普段ならここからPdMが施策や要件が決定した状態でエンジニアに対して「これをつくります」と共有することが多かったのですが、チーム全体で課題に納得感を持てるようにしたかったのでさらにプロセスを改善しています。
具体的には、エンジニアも含めた開発チーム全員で課題感をすり合わせる「共通認識ワークショップ」を実施しました。
PdMが「改善したい」と言っている部分に対してエンジニアも同じような思考を辿ってもらい、開発着手する前に「確かにこれは問題だ」と共感するフローを挟むイメージです。
2つの課題に対して、まずはみんなで定量的なデータや定性的なデータを眺めてみつつそれぞれの観点で自由に意見を出してもらいました。
具体的には「システム動作速度が遅い」「検索がしづらい」という課題を設定したのですが、エンジニアも深く課題に共感していき「分かる」「ローディングが毎回起こるの確かにストレスだよね」「こうしたらシステムの処理速度上がるんじゃない？」など自発的に意見を出してくれました。
実は普段からそれぞれが課題を感じていることはあって、このようにチーム全員で課題について話す場を置くとチームの意見を引き出していくことができるのだなと感じました。
結果としてこの課題に対するプロジェクトもそうですし、その後のプロジェクトについても同じように課題を共通認識にするところから始める開発フローがチームに浸透しています。
一つ印象的だったのが、エンジニアの方からある施策の振り返りのタイミングでもらった声です。
施策の振り返りでこんなに温かいコメントをもらうことはあまりないと感じており、エンジニアから見るデザイナーの印象や、開発チーム全体の働きやすさが高まっていることを表しているのではないかと思います。
チームの雰囲気もかなり変わっています。常にスピード感を求められる環境ゆえにこれまでは少なからず疲弊してしまっていたところもあったと思いますが、今では違和感を感じたり相談事項があったりしたらお互いに気軽に聞きにいき、一緒に開発を進めていこうという一体感がより強まったなと感じます。
他にも、この取り組みの後に他のチームからエンジニアがアサインされたのですが、今回まとめた一連のフローをもとに課題に関する共通認識を持ってスムーズに改善に動けていました。プロダクトチームとして再現性を持って迷いなく開発に取り組めるフローが構築できています。
ここれがRENOSYの社内システム開発チームにおける、共通認識をもとにした開発プロセスづくりの流れです。
一般的にも、PdMが一人で施策を意思決定して、後から呼ばれたデザイナーやエンジニアは課題を自分ごとにとらえることなく施策をやって終わりではチーム開発はあまり良い方向にいかないと思います。
今回のようなプロセス改善を進めたことで、プロダクトに関わるすべての人が課題を主体的にとらえられる、 "ワンチームで開発に取り組む文化" が生まれてきました。
あくまでまずは一歩目としての取り組みですが、こうした積み重ねによって良いプロダクトが生まれるはずだと思っています。今後も良いものづくりのためのプロセスをチームに広げ、結果に繋げていきます。