こんにちは。キャディでプロダクトマネージャー（以下PdM）をしている北林です。
昨年の6月にキャディに入社し、現在はリリース前の新機能のPdMをしています。
今日はこの新機能のDiscovery*1での、デザイナーやエンジニアとのコラボレーション事例について共有しようと思います。
こんな方に向けて書いています
- DiscoveryでのPdM、デザイナー、エンジニアのコラボレーション事例を知りたい方
- グローバルなチームでのコラボレーション事例を知りたい方
チーム紹介
まずは私たちのチームを紹介します。
まだ正式リリース前の機能ということもあり、PdM、デザイナー、エンジニアがそれぞれ1名のスモールなチームです。私は日本生まれ日本育ち、ワンさんは台湾出身、Matthiはドイツ出身と、グローバルなチームでもあり、普段のミーティングは日本語と英語のMixで進むことが多いです。
今回のDiscoveryの進め方
これまでDiscoveryはPdMが中心になって進めることが多かったのですが、今回はPdM・デザイナー・エンジニアの3人でコラボレーションして進めました。
デザインシンキングのフレームにそって今回の進め方を整理
| デザインシンキングのステップ | 今回のDiscoveryの進め方 |
|---|---|
| 共感（Empathize） ユーザーの立場に立って、感情・行動・ニーズを深く理解する | チーム全員でインタビューに参加 |
| 問題定義（Define） 集めた情報をもとに、本質的な課題を明確にする | チーム全員でMiroボードでユーザーの業務フローや課題を整理しディスカッション |
| アイデア発想（Ideate） 課題に対する解決策をたくさん出す | 課題に対しチーム全員でIdeation sessionを開催して解決策を検討 |
| プロトタイプ（Prototype） アイデアを簡単な形にしてみる | エンジニアがHi-fi（高忠実度）プロトタイプ*2を作成 |
| テスト（Test） ユーザーに試してもらい、フィードバックを得る | Hi-fiプロトタイプをユーザーに実際の業務を想定したシナリオで使ってもらい、観察する |
このような進め方をとった背景には、以下のような理由があります。
- プロダクトがまだ立ち上げ段階にあった→ 仕様や実装方針が固まりきっておらず、チームで仮説を立てながら柔軟に方向性を探るアプローチが有効だった。
- PdM・デザイナー・エンジニアがそれぞれ1名ずつという非常にスモールなチーム構成だった→ 意思決定のスピードを保ちながら、密なコラボレーションがしやすい状況だった。
- デザイナー・エンジニアが今回の機能領域の開発経験があった→ 私が1人で考えるより、Discoveryから3人で議論を重ねることで、よりよい意思決定につながると考えた。
なお、こういったコラボレーション型のDiscoveryはすべてのケースに適しているわけではなく、例えば以下のような状況ではPdMが単独で進める、もしくはDiscovery自体を軽量化する方が適している場合もあると思います。
- リードタイムが極端に短い場合→ スピードを優先した判断と意思決定が求められるため、意思決定プロセスをよりシンプルにする必要がある。
- 大規模なプロダクトやチームの場合→ 関係者が多すぎると合意形成に時間がかかり、コラボレーションの効果が薄れてしまう。
- 探索の余地が少ないリニューアル・改善案件の場合→ 既知の課題に対する明確な解決策があるケースは、時間をかけたDiscoveryは不要なこともある。
- 要件が外部により規定される場合（法令対応など）→探索よりも正確な実装や影響範囲の把握が重要となる。
チームで具体的に取り組んだこと
全員でユーザーインタビューに参加
お客様を訪問し、実際の業務を想定したシナリオに沿ってHi-fiプロトタイプを使っていただき、その様子を観察しました。
現地にて実際に動くプロトタイプを使っていただくことで、ユーザビリティ上の課題が発見できたり、検討できていなかったサービス外でのタッチポイントでの課題を発見することができました。
また、お客様から「これなら〇〇の業務にも使えそう」とコメントをいただくなど、想定していなかったユースケースに気づくことができました。
インタビュー結果を視覚化
Miro上に業務フローを書き出し、どこで顧客の課題が発生しているかをマッピングしました。
製造業の業務フローは非常に複雑ですが、ダイアグラムにまとめることで、キャッチアップがしやすく、またチーム内での認識を揃えることができました。
（また、グローバルチームで全員母国語が異なるため、できるだけ文章ではなくダイアグラムに整理するようにしていました）
チームでのIdeation Workshop
課題を洗い出した後は、チームで重要課題を決め、その課題について解決策のアイデアをたくさん出すというIdeation workshopを行いました。
Ideationは発散のフェーズであるため、「否定しない」「質より量」「自由奔放」「人のアイデアに便乗する」という雰囲気作りも重要です。
Ideationには色々な方を巻き込むのが望ましいので、CPOの白井と、PdMの庭瀬も巻き込みました。色々な視点からたくさんの新しいアイデアが出て、その中から実際にロードマップに追加されるものもうまれました。
PRD*3もチームで共創
PRDは私はこれまで1人で書くことが多かったのですが、今回はチームで共同で書きました。
具体的には、ユーザーペインはPdM、ユーザーストーリーはデザイナー、機能要求はIdeationの結果をふまえてPdMがまとめ、技術のリスク点などはエンジニアが書く・・というようなかたちです。
PRDをチームで書いているので、レビューの時間が短縮できるという副次的な効果もありました。
チームでDiscoveryを進めてみて、正直どうだった？
今回チームでDiscoveryを進めてみて、正直どうだったかを3人でディスカッションしてみました。
得られたこと
- 全員でアイデアを出すことでソリューションの選択肢が広がり、より良い判断ができた
- デザイナー・エンジニアも顧客理解が進み、ユーザー視点での設計・実装が可能になった
- Hi-fiプロトタイプでの検証などPdMだけではできないアプローチが実現した
- 技術的観点での実装時のリスクや落とし穴を早期に認識できた。（今までは、PRDを読んだ段階で ”おっと！これは難しいぞ” となることもあったので）
- 「なぜこの機能を作るのか？」という共通認識がチームに生まれた
難しかったこと・乗り越え方
- PdMが単独で進めるより時間はかかる。顧客インタビューの日は移動も含めると丸一日デザインや開発が進まない。→ 全員がすべてのインタビューに参加するのではなく、検証したいことや実際に自分の目で確認して欲しい顧客属性など、対象のインタビューを選ぶ。
- Hi-fiプロトタイプを作る工数が大きい → Hi-fiプロトタイプでしか検証できないことにフォーカスし、不要な部分は作らない。それでもやっぱり時間はかかったので、工数の見積もりはシビアにおこなう。
- グローバルチームならではの言語の壁 →できるだけテキストではなく、Diagramや実際のプロトタイプで説明することを心がける。
- 職種の役割に囚われない...といっても役割分担が難しい →お互いのcanやwillの相互理解が重要。チームビルディングが大切。
- （これは私が勝手に思っていたことですが）「PdMが全部考えないといけない」という固定観念があった →PdMの仕事は結果を出すことであるため、チームに自分よりもっと得意な人がいたら余計なプライドは捨てて任せるべきだし、良いアイデアはチームで出せば良い
最後に：まずは小さく試してみよう
前述の通り、Discoveryをチームでおこなうのは一定の時間もかかりますし、エンジニアやデザイナーの時間の使い方も変わるため、組織的な調整も必要です。
いきなりフルで巻き込むのではなく、
- ユーザーインタビューに1件だけ参加してみる
- 1時間だけIdeation sessionを開いてみる
など、小さなことから始めてみるのはいかがでしょうか。
