はじめに
ヴァル研究所さんのRODEM 開発の裏話的な勉強会に参加させていただきました。技術的な話はあまりありませんでしたがサービスを成長させていくための考え方や苦労話などが聞けて面白かったです。半年かけてiOSアプリを開発したけどリリース直前に開発をやめた話はなかなか衝撃的ですが、判断に至る背景と理由を聞くと納得ができます。とはいえ難しい決断でなかなかできないことだと思いました。
概要
ビジネスマンを「めんどくさい」から解放する【RODEM】の開発の現場
日時：2017-07-01（土）13:30 - 17:00
場所：株式会社ロックオン 大阪本社
イントロダクション：RODEMの紹介
伊藤 英明（ヴァル研究所）さん
予定を登録するだけで経費精算までの業務を簡単にする
開発の背景
働き方改革が注目される動向の中で課題も多い
ルールだけ作ってもまくいかない
例）サイボウズのkintoneのキャッチコピー
ヴァル研究所ができることは何か？
駅すぱあとを使うお客さんの課題
1.アポイントのとき
・何度も経路検索している
2.アポイントメント当日（移動前）
・何時の電車？
・どこで乗る
3.アポイントメント当日（移動中）
・何時に着く？
4.交通費精算時
・月1回の精算
めんどくさいの実態調査
何度も経路検索をする
- アポイントメント時60分
- 当日24分
- 精算時60分
⇒毎月144分（生涯で136人日！）
RODEMカレンダー
行き先を入れるだけでその予定と行き先の移動予定を登録する
対応サービス
- Googleカレンダー
- Office365の予定表
最初に予定を入れるだけでいい
後の処理が楽になる
- 経費精算サービスとの連携
- 運賃情報をCSV出力
- 定期区間控除
はじめてサービスデザインを任されたデザイナーがいかにRODEMの開発についていくようになったか
深沢 幸治郎（水交デザインオフィス・JUSO Coworking）
担当したこと
1.モバイルアプリのデサイン
2.ロゴデザイン
3.ピボット語の管理画面のUIデザイン
4.リニューアルのデザイン
変更を前提とした開発でデザイナーが貢献できること
2015年（プロジェクトスタート）
ツール：AdobeのFW,PS
デザインファイルの共有：Basecamp
アプリ制作の要求についていきにくい
- 画像は複数サイズ
- モバイルで見ると思っていたのと違う
- 最新版どれ？
- デザインルールの変更
プロトタイピングに興味
当時はBootstrapなどを用いたインブラウザデザインが主流
- デザイナーには敷居が高い
- アプリの場合HTMLとCSSいらない
- 本番用のCSSと開発用で違う
2016年
グラフィックツールでプロトタイピング
ツール：
Sketch を使い始める
Adobe XD(Experience Design)
- ワイヤーフレーム＋α
- ページ遷移がすぐ試せる
- 共有ボタンでURL発行してすぐ共有
さらに InVision を導入
- プロトタイプ作成ツール
- 1プロジェクトなら無料
- 画像を読ませてページ作成
豊富な画面エフェクト
CRAFT …InVisionのプラグイン
楽になったポイント
- 要求をとにかく早くカタチにできる
- 要望から基本設計をとりあえず形にする（一番たいへん）
- ミーティングの価値が倍増
- 共有が簡単でその場ですぐに反映してみてもらえる − 実装者が比較的安心して着手できる
- 動かせるから粗や矛盾が早くあぶり出せる
2017年
Sketchの新機能
- シンボルのネストとオーバーライド
- ボタンなどを再利用可能なまま文言などだけ変更
- 要素をデザインデータ上で多層に組織 ⇒用意したパーツの組み合わせで新規ページデザインができる
CRAFTのライブラリ
- スタイルガイドページを自動生成
- Sketchデータに含まれる依存コードを自動生成
- インスペクトモード
- コーディングに役立つ情報（paddingなど）
- アセットの書き出し
ポイント
- 実装者への指示が明快になる
- Sketchを持っていない実装者にもデータを診てもらえる
- 共有が簡単
仮説検証の現場でデザイナーができること
デザイナーの仕事は仕上げだけじゃない
- 変更に強い
- 開発のアシスト
新ツールやフローへの理解
チーム全体に理解を得る
ひとりのデザインからみんなのデザインへ
補足
QiitaにSketchの投稿があった。エンジニアにも注目されている様子。
新規サービスの開発中にPOが何かを決断するために必要だったこと
<話し手>伊藤 英明(ヴァル研究所)
資料あり
HCDプロセス
- システムを使いやすくするためにユーザーの立場や視点に立って設計を行うためのプロセス
- 仮説構築と仮説検証を繰り返す
開発者とユーザーのギャップの存在
例）時刻表の電子化
開発者
- 書籍とくらべてかさばらない
- 常に最新のデータ
ユーザー
- 超長距離の乗り継ぎのためページの行ったり来たりができない
- 過去との差分がわからない
顧客開発モデル
4つのステップで顧客不在リスクの軽減を測る経営プロセス
4つのステップ
探索フェーズ
- 顧客発見
- 顧客実証
実行フェーズ
- 顧客開拓
- 組織構築
ポイント
1.ビジネスモデル仮説を立てる
2.Problem/Solution Fit
・課題解決方法が合っているか
・ユーザーにとって必要？
3.Product/Market Fit
・製品は受容がある？売れる？
P/S Fit
- 課題の仮説とソリューションの仮説の検証
- 誰のどのような問題をどのように解決するか？
- MVPの要件定義になる
MVP…必要最低限の労力＋最低限の実装時間での実現
P/M Fit
- アーリーアダプターへの販売
- ビジネスモデルが成立するか確認
幾つか決断のポイント
開発初期のピボット
想定課題：精算時のめんどくささの解消
インタビュー⇒計画時の課題まで遡り解決する必要があった
UXデザイナーとして
インタビューを実施し、MVPの要件定義となる課題解決のソリューションを設定した
MVPによる検証：入力UIの選択
当初の想定
- 予定データになる
- 精算データを作れる
- ユーザーの既存の体験を変えないことを重視
- B向けサービスであることからスイッチングコストへの考慮
⇒ユザーが普段から使っているカレンダーを予定登録時の入力UIとすることに決定
UXデザイナーとして
価値体験のコアを見極めてMVPとして必要な機能を決める
POとして
サービスのスケールを考えた時どういう機能があるべきか決める
検証を終えて：スマホアプリを公開しない
P/S Fitの検証
移動時の課題…再度検索するのが面倒
⇒急な予定変更、迂回経路がある
予定外の行動に弱い
- マップアプリを見たり、駅すぱあとで調べたほうがいい
- 駅すぱあともRODEMの競合であったという事実
- 課題に対してソリューションがFitしていなかった
POとして
リリースしない判断
リリース直前：コンセプト再定義
一定の形態を持たずに変幻自在に姿を変えながらユーザーに寄り添い助ける存在というコンセプトを再定義
POとして
他のサービスと共生関係でビジネスが成立する形の定義
リリース後：機能追加、改善
- 管理者機能
- ユーザー管理機能の追加
- 定期区間の設定
- 精算連携API
- 駅ランドマーク検索
- 最寄り駅で昼食をとってから訪問するなどのケースに対応
POとして
優先順位ぎめ、売れるための有効な手段の選択
まとめ
- 決断することを求められる
- ユーザーとして何がいいのか
- サービスのスケール
- チームはどう動くか
- PS Fit,P/M Fitを指標として決める
- やってみないとわからないことはある
- HCDプロセスと顧客開発モデルの活用
- やってみるのではない、やるのだ
- 仮説が信じられるまでやってみる
仮説検証に追随するソフトウェア開発をするために大切なこと
<話し手>佐々木 将之(ギルドワークス)
@chachaki
資料あり
RODEMの役割
ターミナル駅、線路切り替えのような役割
仮説をもとに作る
- 仮説は1つではない
- 仮説は検証すればするほど変わる
- 仮説検証のサイクルと開発のサイクルがある
- 開発体制…ほとんどリモート（東京、宮城、大阪、愛媛）
デザイン（2015/11~2016/12 iOSアプリ）
- トーン＆マナー策定
- ワイヤーフレーム作成
- デザインカンプ作成
⇒ざっと棄てた
作ったもので検証する
- 課題仮説を整理⇒当日の課題のソリューションはを提供するのは難しい
- アプリを操作するのが面倒
- ⇒アプリで訪問先とか入力しない⇒インビューすると離脱する人が多かった
検証結果を元に作り直す
- 事業・プロダクトの乗り換え
- むきなおり
- ミッション・ビジョンの点検
- 事業ロードマップ
- プロダクトバックログ作成
つくりなおし
- iOSアプロ開発の停止
- Webサイト開発の開始
- 各種サービス連携の開始
- カレンダー連携⇒GoogleだけでなくOffice365を追加
- RODEMのために作られているわけではない
- webhook…カレンダーで変更があった時に通知
- 例）どのイベントの通知なのか教えてくれない
- 思った通りにはならない（何でそんな仕様なの？）
まとめ
仮説検証に追随するソフトウェア開発をするために大切なこと
ターミナル駅、線路切り替えのような役割⇒RODEMの役割と同じ
一通り全部やれること
- 開発リード・マネジメント
- 仮説検証・顧客開発
MVPのあり方
<話し手>篠原 徳隆(ヴァル研究所)
資料あり
- Prodoct Manager
- 事業レイヤーの上のほう
- マーケティング、リサーチ
- Product Owner
- プロダクトに責任をもつ
今日の結論
新規事業の真髄はMVPとMVPのマインド
MVPの在り方
※MVPあるある
MVPって何？どんなものを作る？どんなレベル？
↓
事業仮説を検証するための実用最小限
- 何故作るか
- ストーリーを検証
- 作るべきものの価値を見定める
- どんなものを作る？
- ランディングページ
- 動画 − どんなレベル？
- フェーズによって検証目的が異なる
- MVP ver.1⇒作るべきものを見定める（ニーズ検証）
- MVP ver.2⇒売って価値検証
- 検証ポイント
- 第一印象の検証（アクティベーション）
- 役に立つかの検証（Retention）
- 売れるかどうかの検証
RODEMでの事例
MVPを並行して開発し検証
- アプリ…MVP検証の結果全く使われなかった
- もう1つのMVP…ユーザーは使い慣れたサービス上で解決したいのではないかという仮説を検証
もう1つのMVPを用意した理由
⇒スイッチングコスト
検証結果を踏まえたピボット
- 日光で合宿
- コンセプトの再定義
- サービスとサービスをつなぐサービスのあグリケーション
ふりかえり（次に向けて）
- MVP開発に時間とコストをかけすぎた
- カレンダーに訪問先を登録するだけでよかったかも
- 結果的に他の課題への対応が遅れる
今やるなら実装2週間で体験サイトを用意した。これで十分だった。
MVPの留意点
- 適切なユーザーターゲットで検証を行う
- 適切に選んだつもりでも見せてみないとわからない
- 反応を見定める
- 検証スピード
- フィードバックからすぐに軌道修正できる
- 時間は様々なものに影響する
- アウトプットすることで良くも悪くもまわる
- MVPは外部の人によって磨かれる
- 最初は社内など身近な人で検証するのが吉
- ただし真の検証は外部から始まる
- 自分達が気づかないことも多々ある
- MVPのスコープ
- 小さく作るのは機能を減らすのではなく検証するストーリーを厳選する
- 尖る要素を用意
- 独自の価値提案の検証こそがMVPの重要な目的
- 狩野モデル で言うところの魅力品質を検証する
- それ以外の要素を作り込みすぎない
- 尖る要素が見つかったら最優先で徹底的に磨く
- 短所を補うのではなく長所を伸ばす
- MVPは棄てるもの／壊すものであることを忘れない
- MVPに固執しない
- PM／POはしっかり判断
- 体験できるもので検証
- 人は目で見えて動く・体験すると反応も関心の度合いも違う
- 計測環境は最初から用意する
- 特許に気をつける
- 初期段階から十分気をつける
- 忘れた頃に突然やってくる
応用事例
応用事例①：トライアルの申し込み件数を伸ばしたい
カスタマージャーニーマップを作成
⇒申込みに課題があることが見えた
⇒即日トライアル環境を発行する機能検討
やったこと
- 短期で実現する方法検討
- Googleスプレッドシート
わかったこと
- 1週間で実装完了
- 前月比10倍の申し込み
次にやること
- 機能として実装（バックログに追加）
応用例②：Salesforce連携
- Salesforceの取引先情報を利用すれば手間が減る
- 利用料等のコストが高額
やったこと
- 営業にヒアリング⇒カスタマージャーニーマップ作成
- SalesforceにアドオンしたMVP作成
わかったこと
- 取引先の課題は名寄せ
- 全ての企業が網羅されるわけではない⇒効果的ではない
- 会社や人によって入力方法が様々
次やること
- 今は対応しない
- 他の価値を検証
まとめ
- 最も早く効果的に検証できるMVPを考える
- 魅せる部分を検証
- 世に出して磨く
所感
デザイナ、開発、PO、PMというそれぞれの立場からのプロダクトアウトで製品を作り上げる苦労や工夫の話が聞けたのが良かった。その中でもアプリを棄てるという重大な判断に対しての認識が全員一致しているのはMVPのあり方がチームに浸透しているからだと思います。製品開発のエンジニア視点で考えると、複数拠点のリモート開発でこのような認識を合わせてMVPを実践するのは非常に大変だろうと想像しましたが、開発メンバーも含めて全員になるべく共有して浸透させているようでした。エンジニアもこのようなプロセスに適応していくスキルを磨く必要性を改めて感じました。