POがUXデザインをする上で
何を指標にしてきたか
株式会社ヴァル研究所 伊藤英明
シン・UX 2017 ～プロダクトマネージャー・プロダクトオーナーにとってのUXのイマとミライ～
2017/1/21

アジェンダ
• 自己紹介
• PO、UXデザイナーとして関わったサービス
「RODEM」について
• プロジェクト内での役割と責任範囲
• HCDプロセスと顧客開発モデル
• いくつかの判断ポイントと判断指標
• まとめ

自己紹介
• 株式会社ヴァル研究所
Business Development Dept. UXデザイナー
• 自社のメイン商材である の技術を
ベースにした新規事業開発の仕事をしています
※その為、若干スタートアップ寄りの話になります
• 経歴的には、デザイナー → ユーザビリティエン
ジニア → UXデザイナー

前置き：RODEMの現在の姿

前置き：RODEMの現在の姿
• ユーザーはカレンダーに予定を入れるだけ
普段と同じように打合せの予定を
カレンダーに登録

前置き：RODEMの現在の姿
普段と同じように打合せの予定を
カレンダーに登録
目的地までの経路や出発時刻を計算
移動予定をスケジュールに追加登録する
• システムが移動予定が算出して登録

前置き：RODEMの現在の姿
• 算出されたデータを使って交通費精算ができる

本登壇の趣旨
• このサービスはなぜこういう形になったのか
• 開発の中でどういう判断ポイントがあったのか
• これがどのように決まっていったのかを振り返り
ながら話します
• 様々な場面で「判断すること」を求められるPOの
助けになる知見を持って帰っていただきたい

プロジェクト内での自分の役割
• UXデザイナーとして
ユーザー目線に立った機能、仕様等の検討
ユーザーへの価値提供に責任を持つ
• POとして
サービス開発の舵取り
チームへの説明責任
サービスのスケールに責任を持つ

HCDプロセス
• システムを使いやすくするためにユーザの立場や
視点に立って設計を行うためのプロセス

HCDプロセス
• システムを使いやすくするためにユーザの立場や
視点に立って設計を行うためのプロセス
使われる
現場を確認
お試し案
を作る
何が必要か
考える
使えるかを
チェック

HCDプロセス
• 仮説構築と仮説検証を繰り返すプロセスでもある

顧客開発モデル
• 4つのステップで顧客不在リスクの低減を図る
経営プロセス
「顧客発見」
ニーズの発見
「顧客実証」
有償販売と
拡張性の確認
探索フェーズ 実行フェーズ
「顧客開拓」
市場参入
需要開拓
「組織構築」
本格販売
ピボット(軌道修正)

顧客開発モデル
• ビジネスモデル仮説を立てる
• Problem/Solution Fitの検証
• Product/Market Fitを実証

判断の指標としてのP/Sfit、P/Mfit
• Problem/Solution Fit
存在する課題と、適切なソリューションが一致して
いる状態
→課題解決方法が合っているか？
→その機能はユーザーにとって必要なものか？
• Product/Market Fit
良い市場を狙っていて、その市場を満足させること
ができる製品を持っている状態
→その製品は需要のある売れる製品か？

ビジネスモデル仮説を立てる
• 各種キャンバスを用いる

Problem/Solution Fitの検証
• ターゲットとするユーザの課題に関する仮説と、
その課題を解決するソリューションの仮説を検証
• その製品、サービスは「誰のどのような問題を
どのように解決するのか？」を明らかに
• これが”MVPの要件定義”となる

MVPとは
Build-Measure-Learnのフィードバックループ１周を回せる
『必要最低限の労力』＋『最低限の実装時間』バージョンの
製品」

Product/Market Fitを実証
• MVPを開発してアーリーアダプター顧客に実際に
販売
• 実際にMVPをもってSIer、販売代理店、エンド
ユーザーへ販売を持ちかける
• 新規顧客の獲得と既存顧客の維持ができるか
(ビジネスモデルとして成立するか)を確認

両プロセスモデルのハイブリッド

幾つかの判断ポイント
• 開発初期のピボット
• MVPによる検証時：入力UIの選択
• 検証を終えて：スマホアプリを公開しない
• リリース直前：コンセプト再定義

開発初期のピボット
• 当初は「交通費精算作業の効率化」を目的にした
ソリューションの開発を目指していた
• 想定課題は「精算時の面倒事」であった
• ビジネスマンの実態を知るためにインタビューを
実施

開発初期のピボット
• 当初、想定していた精算時の課題は感じられてい
るものの、すでに仕方のないこととして受け入れ
られている面
• 外出に関わる活動の中で、何度も経路を検索して
いるという実態が明らかになった
計画時：移動の予定、所要時間を確認するために検索
当日 ：具体的な出発時間を決めるために検索
移動時：乗る電車を確認するために検索
精算時：使った経路にかかった運賃を調べるために検索

開発初期のピボット
• 精算時の面倒事を解消するには計画時の課題まで
遡り解消する必要があることがわかった
• ビジネスマンの外出に関わる「計画時」「移動
時」「精算時」の課題を解決するソリューション
を提供することに決定

ビジネスモデル仮説を立てる
• 各種キャンバスを用いる

Problem/Solution Fitの検証
課題 ソリューション
計画時
アポごとに訪問先の所在地、最寄り駅を
調べて経路を検索。移動時間を踏まえた
スジューリングをしなくてはならないの
が面倒
→
スケジュール登録時に移動ルートも
自動で登録。
正確な計画立案をサポート。
移動時
当日の出発時間や乗る電車を決めるため
に再度検索するのが面倒
→
移動中の乗換をリアルタイムアシス
ト。急なアクシデントも迂回経路で
サポート
精算時
精算のために日にちや経路を思い出した
り、改めて検索しなくてはならないのが
面倒
→
交通費精算用の明細リストを自動で
作成することによる面倒な入力作業
からの解放
• 誰のどのような問題をどのように解決するのか？

開発初期のピボット
このポイントでの判断
UXデザイナーとして
ユーザーに対してインタビューを実施、その実態から課題を
明らかにする
MVPの要件定義となる「課題解決のためのソリューション」
を設定する
POとして
MVPの要件定義に沿った開発方針を決める

MVPによる検証時：入力UIの選択
• まず、MVPでは
①：予定を入れる→移動予定が算出される
②：移動予定で精算データになる
という体験価値の再現を目指した

MVPによる検証時：入力UIの選択
• ①について、当初の予定ではアプリからの予定
登録を考えていた
打合せの予定を登録 自宅、会社から目的地までの経路や
出発時刻を計算。移動予定を一覧

MVPによる検証時：入力UIの選択
• ユーザーの「既存の体験」を変えないことを重視
B向けサービスであることから、スイッチングコス
トへの考慮もあった
• ユーザーが普段から使っているカレンダーを予定
登録時の入力UIとすることに決定

MVPによる検証時：入力UIの選択
このポイントでの判断
UXデザイナーとして
ユーザーに提供する体験価値のコアが何であるかを見極め、
MVPとして必要な機能を決める
POとして
サービスのスケールを考えたとき、(ユーザーの価値を損ねる
こと無く)どういう仕様であるべきなのか決める

検証を終えて：スマホアプリを公開しない
• MVPとしてのRODEMは「カレンダー＆リマイン
ダー＆ナビゲーション＆精算システムへのアダプ
ター」だった

検証を終えて：スマホアプリを公開しない
• 主に「ナビゲーション」部分を担うものとして
アプリを作った

Problem/Solution Fitの検証
誰の、どのような問題を、どのように解決するのか？
課題 ソリューション
計画時
アポごとに訪問先の所在地、最寄り駅を
調べて経路を検索。移動時間を踏まえた
スジューリングをしなくてはならないの
が面倒
→
スケジュール登録時に移動ルートも
自動で登録。
正確な計画立案をサポート。
移動時
当日の出発時間や乗る電車を決めるため
に再度検索するのが面倒
→
移動中の乗換をリアルタイムアシス
ト。急なアクシデントも迂回経路で
サポート
精算時
精算のために日にちや経路を思い出した
り、改めて検索しなくてはならないのが
面倒
→
交通費精算用の明細リストを自動で
作成することによる面倒な入力作業
からの解放
検証を終えて：スマホアプリを公開しない

検証を終えて：スマホアプリを公開しない
• 予定通りの行動はサポートできるが予定外の行動
に弱い
• マップアプリを見たり、駅すぱあとで調べたほう
がいいという場面が多い
• ピンポイントには駅すぱあともRODEMの競合で
あったという事実
• 駅すぱあと(その他アプリ)からスマホの画面を
奪えない
• 課題に対してソリューションがFitしていなかった

検証を終えて：スマホアプリを公開しない
このポイントでの判断
UXデザイナーとして
MVPの利用状況を分析し、P/S fitの検証を行う
POとして
現状のソリューションでは移動中の課題解決ができていない
という事実を元に、アプリを公開しないという判断を下す

リリース直前：コンセプト再定義
• スマホアプリを廃止したことで、RODEMという
システムは完全に「サービスの裏方」になった

リリース直前：コンセプト再定義
• 一定の形態を持たずに変幻自在に姿を変えながら
ユーザーに寄り添い助ける存在というコンセプト
を再定義

リリース直前：コンセプト再定義
このポイントでの判断
UXデザイナーとして
システム、サービスがユーザーへの価値提供を行える形を
模索しコンセプトに落とし込む
POとして
他のサービスと戦うこと無く、共生関係においてビジネスが
成立する形を定義する

まとめ
• POは様々な場面で「判断すること」を求められる
• ユーザーにとって何がいいのか
• サービスのスケールにとって何がいいのか
• そのためにチームはどう動くべきなのか
• その都度「P/Sfit」「P/Mfit」を指標をすることで
必要な判断ができた

まとめ
• 私が繰り返しのプロセスに拘る理由

やってみなきゃわからんこともある
t. Do or do not. There is no try.」 (やってみるのではない

仮説が信じられるものになるまで繰り返す
ルーク「I don't believe it.」(信じられません)
ヨーダ「That is why you fail.」(だから失敗したのじゃ)

ご静聴ありがとうございました。