新規サービスの開発中に
POが何かを決断するために
必要だったこと
株式会社ヴァル研究所 伊藤英明
DevLOVE関西 ビジネスマンを「めんどくさい」から解放する【RODEM】の開発の現場
2017/7/1

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

自己紹介
• 株式会社ヴァル研究所
Business Development Dept. UXデザイナー
• 自社のメイン商材である の技術を
ベースにした新規事業開発の仕事をしています
• RODEMのPO(プロダクトオーナー)
• 経歴的には、デザイナー(プロダクト、UI) →
ユーザビリティエンジニア → UXデザイナー

自分のスキル構造
プロダクト
デザイナー
ユーザビリティ
エンジニア
UIデザイナー
リサーチャー
エンジニアではない…
UXデザイナー

前置き：RODEMの現在の姿

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

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

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

本登壇の趣旨
• このサービスはなぜこういう形になったのか
• 開発の中でどういう決断ポイントがあったのか
• これがどのように決まっていったのかを振り返り
ながらお話します

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

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

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

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

D.A.Norman(1986)
Three aspects model
ユーザー開発者
このように使う
のがいいに違い
ない！
このように
使うものかな？
製品、システムに対する
イメージのギャップ
開発者とユーザーの間にあるギャップ

ある例

ある例

開発者
開発者とユーザーの間にあるギャップ
・書籍版と比べて
かさばらない！
・常に最新のデータ
を提供！
・超長距離乗り継ぎ
のためのページ
行ったり来たりが
できない
・過去の時刻表との
差分を見る楽しみ
方ができない
ユーザー
コレジャナイ！
こういう仕様が
いいだろう！
製品、システムに対する
イメージのギャップ

開発者
開発者とユーザーの間にあるギャップ
ユーザー
コレジャナイ！
こういう仕様が
いいだろう！
製品、システムに対する
イメージのギャップ
• 時刻表を見ようと思えば乗換案内アプリでも済むこのご時世で、
わざわざ時刻表単体でのアプリを購入するユーザーにとって
求められる価値を提供できていたのか？という疑問
• 新しいソリューションは、従来のものを上回る価値を提供
しなければ市場に受け入れられない

顧客開発モデル
• 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の選択
• 検証を終えて：スマホアプリを公開しない
• リリース直前：コンセプト再定義
• リリース後：機能追加、機能改善

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最初のリリース
※Yahooニュース※Concur社ニュースリリース
• 日本外国特派員協会にて記者会見

最初のリリース
• 数多くのメディアでの反響

B向けサービスなんだから
ユーザー管理機能
くらいあるでしょ？
(※イメージです）

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

リリース後：機能追加、機能改善
• 管理者機能
→エンタープライズ向けサービスとして必要
• ユーザーページデザイン変更
→増えてきた機能を一旦情報整理
• 精算連携API
→連携における拡張性
• 駅、ランドマーク検索
→移動予定にバリエーション

リリース後：機能追加、機能改善
• 管理者機能
→エンタープライズ向けサービスとして必要
【ユーザー管理】
利用メンバーの一覧と、個々の精算に関わるルート選択基準(最安／最早)、定期区間など
の登録状況の表示と編集ができます。
【定期区間の一括登録・編集】
利用メンバーそれぞれの定期区間をCSVで一括登録・編集できます。
【訪問先マスタ（顧客リスト）の一括登録・編集】
企業で管理している訪問先マスタ（顧客リスト）をCSVデータで一括登録できます。
【アクティベーションキー管理】
利用メンバーのアクティベーションキー（ライセンスキー）の利用ユーザー数や有効期限、
そのキーで連携している経費精算システムなどの連携サービスが確認できます。
【経路検索の企業設定】
企業の交通費の支給規定に合わせられるよう、経路検索の設定を変更できます。
※設定項目の例：利用できる交通手段の指定（空路、有料特急など）、移動ルート基準（最安／最早）、
運賃種別（ICカード／現金）、特急利用時の指定席／自由席設定など。

リリース後：機能追加、機能改善
• ユーザーページデザイン変更
→増えてきた機能を一旦情報整理

リリース後：機能追加、機能改善
• 精算連携API
→連携における拡張性

リリース後：機能追加、機能改善
• 駅、ランドマーク検索
→移動予定にバリエーション
[株式会社ヴァル研究所]
→行き先最寄駅の高円寺は自動的に検索
[高円寺駅]
→行き先最寄駅付近で事前に待ち合わせるなど

リリース後：機能追加、機能改善
このポイントでの判断
UXデザイナーとして
ユーザーの利便性を向上させるための機能追加や改善
導入の決定権を持つ人もユーザーの一人として考え、企業に
とっての導入しやすさを考える
POとして
機能追加、改善の優先順位を決める
サービスが「売れる」ために有効な手段を選ぶ

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

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

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

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

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

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

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

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

トライアル申込み受付中です
RODEM 検索