BtoB新規事業を
舵取りするための
ユーザー調査
株式会社ヴァル研究所 伊藤英明
ユーザーテストLive!『第2回 UT事例発表会』 UX先進企業の担当者が語る「活用事例」第二弾
2017/10/4
アジェンダ
• 自己紹介
• PO、UXデザイナーとして関わったサービス
「RODEM」について
• 仮説構築フェーズでのユーザー調査
• 仮説検証フェーズでのユーザー評価
• まとめ
自己紹介
• 株式会社ヴァル研究所
Business Development Dept. UXデザイナー
• 自社のメイン商材である の技術をベースにし
た新規事業開発の仕事をしています
• RODEMのPO(プロダクトオーナー)
• 経歴的には、デザイナー(プロダクト、UI) →
ユーザビリティエンジニア → UXデザイナー
自己紹介
• マーケティング/商品企画のためのユーザー
インタビューの教科書 共著
担当サービス「RODEM」
アポイントメント時
どのくらい移動時間がかかる
か
知るため、カレンダーに移動
の
予定を入れるために検索
業務で外出するたびに何度も経路検索
を
していませんか?
アポイントメント当日
具体的に何時に出発するかを
決めるために検索
業務で外出するたびに何度も経路検索
を
していませんか?
交通費精算時
いつどこに打合せに行った
か、
どのくらいの運賃がかかっ
た
のか、その日のことを思い
出しながら改めて検索
業務で外出するたびに何度も経路検索
を
していませんか?
あなたの交通費精算は各駅停車では
ありませんか?
• ユーザーはカレンダーに予定を入れるだけ
普段と同じように打合せの予定を
カレンダーに登録
担当サービス「RODEM」
普段と同じように打合せの予定を
カレンダーに登録
目的地までの経路や出発時刻を計算
移動予定をスケジュールに追加登録する
• システムが移動予定が算出して登録
担当サービス「RODEM」
• 算出されたデータを使って交通費精算ができる
担当サービス「RODEM」
あなたの交通費精算を各駅停車から超特急
に!
87%の工数削減!!
本登壇の趣旨
• このサービスはなぜこういう形になったのか
• 開発の中でどんな調査、評価を行い、どんな決断が
あったのか
• サービスデザインで舵取りしていったことを振り返りな
がらお話します
BtoBサービス開発の難しさ
• ユーザーの声は大きく扱われるが、本質的な課題で
はないことも多い
• 導入までのハードルが多い
例)社内での既存システムや風習に合わないところは
個別対応しているケースが多い
HCDプロセス
• システムを使いやすくするためにユーザの立場や視
点に立って設計を行うためのプロセス
HCDプロセス
• システムを使いやすくするためにユーザの立場や視
点に立って設計を行うためのプロセス
使われる
現場を確認
お試し案
を作る
何が必要か
考える
使えるかを
チェック
HCDプロセス
• 仮説構築と仮説検証を繰り返すプロセスでもある
仮説構築フェーズでのユーザー調査
• ユーザーの課題は何か、その課題を解決するのに
適した手段は何か
• BtoBに合わせた調整:課題を聞くのではなく、実態か
ら課題を見つける
開発初期のピボット
• 当初は「交通費精算作業の効率化」を目的にしたソ
リューションの開発を目指していた
• 想定課題は「精算時の面倒事」であった
• ビジネスマンの実態を知るためにインタビューを実施
開発初期のピボット
• 当初、想定していた精算時の課題は感じられているも
のの、すでに仕方のないこととして受け入れられてい
る
• 外出に関わる活動の中で、何度も経路を検索している
という実態が明らかになった
計画時:移動の予定、所要時間を確認するために検索
当日 :具体的な出発時間を決めるために検索
移動時:乗る電車を確認するために検索
精算時:使った経路にかかった運賃を調べるために検索
開発初期のピボット
• 精算時の面倒事を解消するには計画時の課題まで遡
り解消する必要があることがわかった
• ビジネスマンの外出に関わる
「計画時」「移動時」「精算時」
の課題を解決するソリューションを提供することに決
定
ビジネスモデル仮説を立てる
• 各種キャンバスを用いる
Problem/Solution Fitの検証
• ターゲットとするユーザの課題に関する仮説と、
その課題を解決するソリューションの仮説を検証
• その製品、サービスは「誰のどのような問題を
どのように解決するのか?」を明らかに
• これが”MVPの要件定義”となる
Problem/Solution Fitの検証
課題 ソリューション
計画時
アポごとに訪問先の所在地、最寄り駅を調
べて経路を検索。移動時間を踏まえたスケ
ジューリングをしなくてはならないのが面倒
→
スケジュール登録時に移動ルートも自
動で登録。
正確な計画立案をサポート。
移動時
当日の出発時間や乗る電車を決めるため
に再度検索するのが面倒 →
移動中の乗換をリアルタイムアシスト。
急なアクシデントも迂回経路で
サポート
精算時
精算のために日にちや経路を思い出したり、
改めて検索しなくてはならないのが面倒 →
交通費精算用の明細リストを自動で作
成することによる面倒な入力作業からの
解放
• 誰のどのような問題をどのように解決するのか?
MVPとは
Build-Measure-Learnのフィードバックループ1周を回せる『必要最
低限の労力』+『最低限の実装時間』バージョンの製品」
仮説検証フェーズでのユーザー評価
• 課題解決の方法性が合っているのか
• その手段でユーザーの課題は解決するのか
• BtoBに合わせた調整:
課題の解決はもちろんのこと、「ユーザーの普段の行
動」に即する手段を提供する
MVPによる検証時:入力UIの選択
• まず、MVPでは
①:予定を入れる→移動予定が算出される
②:移動予定が精算データになる
という体験価値の提供を目指した
MVPによる検証時:入力UIの選択
• ①について、当初の予定ではアプリからの予定
登録を考えていた
打合せの予定を登録 自宅、会社から目的地までの経路や
出発時刻を計算。移動予定を一覧
MVPによる検証時:入力UIの選択
• ユーザーの「既存の体験」を変えないことを重視
B向けサービスであることから、スイッチングコストへの
考慮もあった
• ユーザーが普段から使っているカレンダーを予定
登録時の入力UIとすることに決定
検証を終えて:スマホアプリを公開しない
• MVPとしてのRODEMは「カレンダー&リマインダー&ナ
ビゲーション&精算システムへのアダプター」だった
検証を終えて:スマホアプリを公開しない
• 主に「ナビゲーション」部分を担うものとして
アプリを作った
Problem/Solution Fitの検証
誰の、どのような問題を、どのように解決するのか?
課題 ソリューション
計画時
アポごとに訪問先の所在地、最寄り駅を調
べて経路を検索。移動時間を踏まえたスケ
ジューリングをしなくてはならないのが面倒
→
スケジュール登録時に移動ルートも自
動で登録。
正確な計画立案をサポート。
移動時
当日の出発時間や乗る電車を決めるため
に再度検索するのが面倒 →
移動中の乗換をリアルタイムアシスト。
急なアクシデントも迂回経路で
サポート
精算時
精算のために日にちや経路を思い出したり、
改めて検索しなくてはならないのが面倒 →
交通費精算用の明細リストを自動で作
成することによる面倒な入力作業からの
解放
検証を終えて:スマホアプリを公開しない
検証を終えて:スマホアプリを公開しない
• 予定通りの行動はサポートできるが予定外の行動に弱
い
• マップアプリを見たり、駅すぱあとで調べたほう
がいいという場面が多い
• ピンポイントには駅すぱあともRODEMの競合であった
という事実
• 駅すぱあと(その他アプリ)からスマホの画面を
奪えない
• 課題に対してソリューションがFitしていなかった
リリース直前:コンセプト再定義
• スマホアプリを廃止したことで、RODEMというシステム
は完全に「サービスの裏方」になった
リリース直前:コンセプト再定義
• 一定の形態を持たずに変幻自在に姿を変えながら
ユーザーに寄り添い助ける存在というコンセプトを再
定義
現在:改善のための開発
• スクラム開発で仮説構築と仮説検証を繰り返していま
す
https://www.slideshare.net/itow_ponde/uxpo-170927-80220011
ご静聴ありがとうございました。

BtoB新規事業を舵取りするためのユーザー調査