こんにちは。
Ubie株式会社にて、デザイナー / プロダクトオーナーをしている村越（@smurakos）です。

外資系コンサルティングファームでのUXデザイナー・シニアマネジャーを経て、2021年2月にUbieにジョインしました。

この4月からはAI問診ユビーという医療機関向けのプロダクトのプロダクトオーナーをしています。

これまでは、事業会社でUXデザインチーム立ち上げ・UXリサーチのためのフレームワーク整理という「型化」の部分や、数人〜数十人規模での組織の人的マネジメントなどの「管理」の部分などのキャリアをここ数年は積んできました。
でも、実際に自分がプロダクトを成長させる、という部分でのプロダクトオーナーという役割は初めてのチャレンジです。

今回は、そんなプロダクトオーナーへの初めてのチャレンジを通じて、ほぼプロダクト開発をイチから学び直した話について、自分の経験を元に書いてみようと思います。

デザインへの解像度を高めるために、デザイナー以外の役割を取る

「真にデザインの力を証明できるデザイナーってどんな人？」ーこう問うた時の自分の答えの一つが、「デザインに対する思想への解像度だけでなく、ある特定の産業ドメインに対する解像度も高い人」です。

デザインリサーチや、プロトタイピング、ユーザテストなどを通じて日々ユーザに接していればユーザへの解像度や、「使いやすいデザインへの解像度」が高まるか、、、
そのプロダクトが提供される産業構造、商慣習、業務フローまで深く知れば、良い体験が作れるのか、、、

ユーザの心理や産業・ビジネスを「知る」だけではなく、「自分の手で育てた経験」がやはり圧倒的に重要だということをこの数ヶ月で痛感しました。

プロダクト体験的にやった方がいいこと、ビジネス的にやった方がいいことの優先度の狭間で葛藤することでしか、真の成長はない

Ubieのプロダクトオーナーの守備範囲は、向こう半年程度の中期的な事業ストーリーの検討→OKRの立案・リファイン→バックログの優先順位づけ→リリースへ、と一般のPOよりも少し広い守備範囲を持っています。

デザイナーとしては、事業の視点⇄プロダクトの視点をどう切り替えてバランスしていくか、が学びの連続だったので、大きな二つの学びを取り上げてご紹介できればと思います。

- シニアなデザイナーだけど、学びや成果に飢えてる
- クライアントワークを長くやってきて、数値で語れる成果に飢えてる
- マネジメントを長くやってきたけど、プレイヤーとしても成長したい

みたいな方にとって、読んだ後「よっしゃ、やるぞ！」と少しでも思ってもらえると嬉しいです。

学びその１：課題の解像度、優先順位の解像度は上がっているか

Ubieでは、トリプルトラックアジャイルに取り組んでおり、課題の発見・解決策の検討・デリバリーをスクラムチームで取り扱っています。

そこでは、以下のような問いかけがよく行われます。

「顧客の要望、それって一体何が課題なんですか？」

SaaSプロダクトの特性上、顧客から直接届くフィードバックやカスタマーサクセスチームや、マーケットのスケール・セールスを担うUCS（Ubie Customer Science）メンバーを経由して届く声、顧客インタビューを通じて届く声など、非常にたくさんの顧客の声が日々寄せられています。

顧客体験設計を担うデザイナーの視点からすると、「プロダクト体験上の顧客インサイトはこの辺だろうな」とある程度アタリをつけて、改善のためのバックログを積むわけですが、ここで最初の論点があります。

- それは、事業にとって本当に解決する必要がある課題かがわかっているか
- それは、プロダクトの成長にとって何が課題なのかがわかっているか
- それは、顧客にとって何が課題なのかがわかっているか

ポイントは「わかっているか」という部分です。
プロダクトオーナーだけがわかっていてもダメで、これをスクラムメンバーと共有して、全員で解像度が揃っている状態が作れているか。

デザイナーであると、つい「これをこうすれば、こういう体験を改善できそうだ」とあらかじめ頭で形を描いて「わかったつもり」になってしまい、課題の解像度が高まっていないという状況にしばしば陥ることがありました。

1.ポイントは「わからない」ということがわかっているか
例えば、直近で取り組んだ話題として、「患者さんが問診を通じて、自身の症状を伝えられているか、それが医師に正しく伝わっているか」という論点を取り扱いました。

一見、これは課題として機能しているように見えますが、こう問うてみるといかがでしょうか。

- 患者さんが問診で自分の症状を伝えられていないってどういうとき？
- それはどのくらいの割合で発生するの？
- それには、診療科や特定の症状などの傾向・特徴はあるの？
- 患者さんが問診で自分の症状を伝えられないことが医師にとってどのくらい大きなペインになるの？

これだけあげただけでも、「わからない」ことばかりであることがわかります。

しかし、この状態では何を改善したらいいかもまだわからない状態です。
解決策を検討するにはもう１段深く潜る必要があります。

2.抽象的なわからないを具体的なわからないへ変換するためのユーザストーリーマッピング
何がわからないか、を具体的に理解するために実施したのが以下のスクリーンショットのようなマッピングです。

- 問診のフロー＋アルゴリズムをブレイクダウン、セクションごとに分割
- 内部的に動いているデータの流れを可視化
- 患者→医師への情報の流れを可視化

全体の流れを細かく可視化してみると、例えば、以下のことが見えてきます。

- 患者さんは、自身の症状をタブレット問診でどのように入力しているか
- 患者さんは、自分が一番辛い症状の優先度をどのように判断するのか
- 患者さんが問診で入力するキーワードは診療科によって差があるのか
- 選んだ症状に対する問診内容（フロー）に問題があるところはあるか
- 問診が完了してから、医師側への情報伝達に問題があるのか

だいぶ、わからないことが具体的になってきたと思います。

これらを解決するための解決策を立てて、その検証・評価計画を立てることでようやくバックログとして見積もれる状態になります。

「何が理解できないのか」をきちんと理解する、何が理解できないのか、を構造的に整理する、「課題」にも解像度があって、課題の解像度が高まっているかどうかもまた、プロダクトの成長には大切な要素であることを身をもって学んだ事例です。

学びその２：顧客を広い視野で捉えて、深く理解し、それをスクラムチームと共有する

もう一つ、この数ヶ月で徹底的にトライしているのが、「データによって、顧客を俯瞰で捉える」ことに意識することです。

今までは、インタビューや観察といったリサーチによって、特定のセグメントの顧客の行動や思考に対して寄り添い、共感をすることで深い顧客理解を得ることを中心としてきました。

前のセクションでも書いたように、プロダクトの成長観点を考えると顧客というもの自体にも解像度が存在していることがわかり、同時にわからないことがたくさんあることがわかってきます。

- 顧客のセグメントの切り方にはどのようなパターンがあるのか
- パターンごとの傾向の違いがあるのか
- そこでは何が課題なのか
- それを誰が解決できるのか

プロダクトの利用傾向、顧客にインタビューを通じて深くよりそうだけでなく、マクロな傾向を俯瞰して捉えることで長期的、構造的な課題を明らかにする。

そのために、意識的に定量データに向き合う取り組みを行なってきました。

また、そのことをスクラムのメンバーにも思考のプロセスを含めて詳細に共有するという試みを行ってきました。

1：インプット＿定量データをもとに、真因を探究する
「データには示唆が浮き上がってくる視点が必要」ー これも、自分で深くデータを見てみて、改めて気づいた視点です。

- 全ての顧客の導入N週目以降の利用状況を可視化する
- 導入からの時間経過で利用状況におけるパターンでセグメント化する

というのを今回はトライしてみました。

細かく蓋を開けてみると、導入いただいている顧客の中でも「アップトレンド」「アクティブ」「ダウントレンド」「非アクティブ」、という大きなグループが見えてきました。

また、それぞれのグループについての動向を観察すると、稼働開始からN週、などある程度一定期間経過後に上記の４グループのトレンドのどれかに入っていくことがわかります。

各グループ、特にダウントレンドなど、ネガティブになっているグループを特定したら、

- プロダクトで届けきれていない価値があり、それはどんなものか
- それは、プロダクトだけでは解決しきれない（例えば、プロダクトとカスタマーサクセスの連携）ものなのか
- 長期的に、どのグループにどういう施策を行なって、どういう状態に持っていくか

など、プロダクト観点、サクセス観点、マーケット拡大の観点での解像度も高めることができました。

データを個別顧客、プロダクトの観点だけでなく、全体・時系列・時間経過、という視点からも立体的にみることで、構造的な課題についても解像度を高めることができた事例です。

全体を立体的に眺めていくことで、目先でおこっている現象だけでなく、もう少し真因的な構造として起こっている課題が見えてきた点で、データをみる・データを探索することに執着することの重要さを改めて実体験として学ぶことができました。

2：アウトプット＿思考のプロセスを極力詳細に
ユビーのスクラムチームにおけるプロダクトオーナーの役割は、事業ストーリー、全社のOKRなどにも及ぶため、守備範囲が広くなりがちです。
スクラム外のチームとのやり取りも多く発生するため、プロダクトオーナーの思考の中で優先度が常に変化したり、意思決定の軸も変化したり、ということが起きがちです。

今回、スクラムチームでトライしたのは、社内のドキュメント共有ツール（社内ではDocBaseというツールを使って文書共有を行なっています）を用いて、毎週金曜日に、以下のことを文書として残し、その中で自分がどういう思考を行なっているかというメトリクスと思考のプロセスをアウトプットする、という取り組みを行なっています。

- その週のキーメトリクスの動き
- リファインメントなどのスクラムセレモニーで議論された内容の補足
- 外部チームとのやりとりで共有すべきこと。優先度に影響しそうなこと

全体での認識共有や議論はやはりSlackやミーティングの場でリアルに行うことに越したことはないですが、透明性を保つという意味では自分の思考プロセスを意識的に開示するというのは、自分の思考を整理するという意味でも、それをログとして残すという意味でも良かったかな、と思っています。

まとめ

いかがでしたか？
自分がジョインした時は、プロダクトオーナーとしてプロダクト成長の責任を預かるということはあまり想像していませんでした。

でも、経験してみると今まで自分がデザイナーとして学び、知識として得ていたことを実践知として血肉化することができました。
また、デザインに対する見方もさらに広げることができました。
それはある種、プロダクト開発をイチから学び直したのに近いほど濃い学びを得ました。

「観見ニ眼」という宮本武蔵の言葉が好きなのですが、今回改めて「視界と視野を広く持ちながら、視点を深く」「足元ではなく、物事の真因を見つめること」の重要さに気づき、改めてその言葉の持つ意味を深く理解することができました。

観見二眼
目の付け方は、大きく広く付ける目である。
「観・見」二つの目があり、「観の目」を強く、「見の目」を弱く、遠い所を近いように見、近い所を遠いように見ることが兵法では必要不可欠である。（宮本武蔵「五輪の書 水の巻」）

Ubieはホラクラシーによる自律的な組織運営を行なっており、意思によって役割が決まってくる環境でもあります。
その環境・カルチャーがあるおかげで、個々人が新しい役割をどんどんとっていって、短期間で濃い学びを得て、成長に繋げることができる、というのも組織として非常にユニークな点だと感じています。

知識でわかっていても、知ることとできることの間には埋め難い圧倒的な断絶があり、「できる」ようになるのはとにかく実践、失敗、葛藤、そこからの学びに尽きる、というアンラーニングのお話でした。

We are hiring!

最後に。
Ubieでは、今後の事業成長を見据えてまだまだ一緒に戦ってくれる仲間を募集しています。
「デザインに関わっているけど、本当の意味でプロダクトを成長させたことがない、その経験に飢えている」「成果を出すことに飢えている」「学びを得ることに飢えている」、そういう方がいたらぜひ一度、メンバーに会いにきていただけたらと思います。

Ubie Discovery 採用サイト

Ubie Discovery の最新情報がほしい方

不定期(月に1〜2回程度の目安)でご案内をお届けします。
直近でのご転職を検討されていない方も、登録と同時に選考への応募とみなすものではないので、気軽にご登録ください。