止めるサービス開発、止めないサービス開発

328 Views

December 21, 15

スライド概要

12月21日に開催したイベントでお話した内容です。
https://guildworks.doorkeeper.jp/events/35022

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

止めるサービス開発と 止めないサービス開発 〜 適応型プロダクト開発の実際 〜 ギルドワークス代表 市谷聡啓 Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved.

2.

3 / 17

3.

3 / 17 3 価値探索(仮説検証)の結果、 模擬実験フェーズを突破し、ローンチに至った件数 ※17には現在も継続中を含む

4.

Problem Solution fit 価値探索(仮説検証)で学ぶべきこと ユーザーの課題に、ソリューションが適合するか? (Problem Solution fit)

5.

模擬実験からリアルへそもそも行けない 机上検証・擬似環境検証 事業環境での検証 価値探索 MVP開発 プロダクト (仮説検証) ・検証 を育てる

6.

模擬実験からリアルへそもそも行けない 机上検証・擬似環境検証 事業環境での検証 価値探索 MVP開発 プロダクト (仮説検証) ・検証 を育てる ターゲットユーザーに ターゲットユーザーが PSfitの確度が ニーズがない 使わない 20%を切る事実 80%がPSfitしない Photo credit: Ferran. via Visual Hunt / CC BY-NC-ND Photo credit: Ferran. via Visual Hunt / CC BY-NC-ND

7.

PSfitの目処が立たない ターゲットユーザーが居ない、出会えない ターゲットユーザーに想定課題がない Photo credit: antonychammond via Visual hunt / CC BY-NC-SA 想定課題に価値提案が適しない そもそも検証実験が進まない!

8.

最初の突破のために PSfitを引き寄せるための2つの構え ユーザーの文脈における 極端な制約条件下でも 傾向を捉える 形づくれる適応力 本編事例を通じて、この2つの構えを追います。

9.

オズビジョン様 本編にご登場頂くお客様 ・ポイントコマースサービス「ハピタス」の運営 - 会員数 150万人 - 提携ショップ数 2000社 http://hapitas.jp/ - 年間流通総額 200億円 ・ギルドワークスとしては2014年5月から 現場コーチとしての開発現場支援を始め、 「スマートカート」 「ハピタスSmartPhone向けサイト」を担当 http://sp.hapitas.jp/

10.

止めるサービス開発 Toshihiro Ichitani All Rights Reserved.

11.

SmartCart SmartCart (スマートカート) ・サービスコンセプト 日用品を最もお得に買えるネットショップを Stop Service 提示してくれる →日用品の価格.comのイメージ ・ターゲットユーザー 2015年3月サービス開発停止 乳幼児を抱える専業主婦 ・SmartCartの座組 - 2014年8月よりMVP開発開始、 2015年3月開発停止 - 課題仮説の検証(顧客開発)は、 オズビジョン様にて担当。 - ギルドワークスは、顧客開発と並行して、 MVP開発とその後の検証を担当。

12.

順調なスタートアップ ・インタビュー結果は、まずまず。 - コンセプト動画やイメージ図でのインタビュー ・ランディングページでの登録率、良好。 - サービス提供前にランディングページで事前登録率をみる → 十分な期待が持てる(=開発を加速したい) ・インタビューを継続しながら、MVP開発へ進む(顧客開発と並走) 机上検証・擬似環境検証 事業環境での検証 突破 価値探索 MVP開発 プロダクト (仮説検証) ・検証 を育てる

13.

顧客開発とは? つまり、つくるべき何かが開発しながら積極的に変わる

14.

Moving Target 極端な Moving Target 一般的なソフトウェア開発 1年、3ヶ月、1ヶ月… 顧客開発に寄り添うソフトウェア開発 もはや時間単位ではない いつ変わるか分からない 1週間かもしれない、明日かもしれない かつ当然、期間制約も予算制約も厳しい

15.

顧客開発に適応する開発 Photo credit: visualpun.ch via VisualHunt.com / CC BY-SA 変化に適応的になる = 変更可能だから適応できる

16.

適応型プロダクト開発の9つの方針 第一に、関係者の目線を揃える ① 指針 (なぜ、何を検証すべきか?) の共有 ② 状況 (いつどうやって検証するのか?) の共有 ③ 期待 (次のサイクルの開発に何を求めるか) の可視化 ④ 着地点を常に追う (このまま継続するといつどうなるのか?) 第二に、開発を適応的にする ⑤ 程よい先読み力を備える (指針/状況/期待から次の想定を読む) ⑥ 1週間単位のイテレーション開発 ⑦ 書き換え可能な”地図”の用意 (迷子にならないためにA4一枚の線表) ⑧ バッファを持つ (適応への根本的な可能性を高める) 第三に、方式・設計を丁寧にやる ⑨ 高凝集、疎結合 (そして、石橋は早めに早めに叩く)

17.

….PSfitしない!! 全く期待を感じさせないCVR.. Photo credit: Vincent̲AF via VisualHunt.com / CC BY-SA MVPが使われない = ニーズが無いのか?

18.

その意見は自分事か、他人事か インタビュー結果では、 あれば使うだろうという意見 実際には、サイトに訪れても、 カートを使わない(CVしない)

19.

その意見は自分事か、他人事か インタビュー結果では、 あれば使うだろうという意見 実際には、サイトに訪れても、 カートを使わない(CVしない) なぜ?? ユーザーテストを実施して、 ユーザーを目の前にして、 分かったこと

20.

その意見は自分事か、他人事か インタビュー結果では、 あれば使うだろうという意見 実際には、サイトに訪れても、 カートを使わない(CVしない) なぜ?? ユーザーテストを実施して、 ユーザーを目の前にして、 分かったこと 「あれば使う」 「自分も使う」 自分は使わない なぜなら、◯◯(個々人のささやかな理由)だから スイッチングコスト > プロダクトから得られる価値

21.

止めるサービス開発 ユーザーが新たな手段を利用開始するためには、 切り替えするだけの理由がなければならない。 その理由を探るためには、ユーザーのいる世界の状況を、 ユーザーと同じように、見る、聴く、感じる必要がある。

22.

止めるサービス開発 ユーザーが新たな手段を利用開始するためには、 切り替えするだけの理由がなければならない。 その理由を探るためには、ユーザーのいる世界の状況を、 ユーザーと同じように、見る、聴く、感じる必要がある。 机上検証・擬似環境検証 事業環境での検証 突破できず 価値探索 MVP開発 プロダクト (仮説検証) ・検証 を育てる サービス開発を止める

23.

止めないサービス開発 Toshihiro Ichitani All Rights Reserved.

24.

ハピタス ハピタス (スマートフォン向けサイト) ・これまでのサービスコンセプト お買い物をもっとお得に ・これまでのターゲットユーザー ポイント獲得自体を目的とした、 ポイントゲッター ・ハピタスSPサイトリニューアルの座組 - 2015年9月よりリニューアル方向付け開始、 2015年10月-11月デザイン制作+開発、 2015年12月頭 ローンチ - ギルドワークスはプロジェクトマネジメント 及び、UIデザイン制作を担当。 - リニューアル開発は、 http://sp.hapitas.jp/ オズビジョン様内製チームにて担当。

25.

ハピタスの新しい戦略 http://hapitas.jp/mothersupport/ ・新ターゲットユーザー 乳幼児を抱えた専業ママ →ポイントサービスとしてはマジョリティ層にあたる

26.

検証すべき仮説、適応すべき開発 ハピタスSPサイトリニューアルに向けた課題 <検証すべき仮説> ① 新ターゲットユーザーに、 どのようにすれば受け入れられるのか? ② 新ターゲットユーザーに、 どのようにして届けるのか? <適応すべき開発上の制約> ③ ローンチまで実質1ヶ月の超短期開発 …「止めたサービス開発」での学びを活かす

27.

ユーザーの世界へ自分も入る ユーザーが新たな手段を利用開始するためには、 切り替えするだけの理由がなければならない。 その理由を探るためには、ユーザーのいる世界の状況を、 ユーザーと同じように、見る、聴く、感じる必要がある。 ユーザーの要求に ただ応えようするのではなく ユーザーの文脈における 傾向(しようとすること)を捉える では、新ターゲットユーザーの見ている世界とは?

28.

ユーザーが見ている世界、しようとすること どのようにすれば受け入れられるか? → 普段ママが目にしている世界から逸脱しない。 “自分たち(ママ)のモノである” と思える風景をつくる。

29.

ユーザーが見ている世界、しようとすること どのようにすれば受け入れられるか? → ママの「しようとすること」によりそう。 「こちらのやりたいこと」で一方的に圧倒しない。

30.

それにしても開発期間が短い ローンチまで実質1ヶ月の超短期開発 9月 サイトの方向付け 10月 UIデザイン 11月 開発 …リスクが高すぎる 9月 サイトの方向付け 10月 UIデザイン 曳光弾開発 11月 開発

31.

曳光弾開発 曳光弾開発 “開発開始直後の段階からプロジェクトが進みつつ ある方向を確認できるので、目標を絶えず定め直し ながら開発を進めることがやりやすくなります。” http://www.amazon.co.jp/dp/4274066568 最初から全体がどのように連携するかを 念頭におき、本番と同じアーキテクチャで つくり始める。 ・開発チームのリズムをつくる ・「このチーム、このプロジェクト」での課題を早期に 発見できるようにする ・ベロシティの安定化 → 「チームをあっためておく」

32.

止めないサービス開発 どれほど正しいものを見定め、 どれほど正しくつくろうとしても、 プロジェクトチーム全体が それぞれの役割に拘泥することなく 目標に集中して向かわなければ 成果を引き寄せることはできない。 プロジェクトを頓挫させないために “越境”のための”越境”を恐れない。 「プロジェクトふりかえりタイムライン」より

33.

止めないサービス開発 12月7日 ハピタスSPサイトリニューアルローンチ 「プロダクトを育てる」はこれから http://sp.hapitas.jp/

34.

最初の突破のために PSfitを引き寄せるための2つの構え ユーザーの文脈における 極端な制約条件下でも 傾向を捉える 形づくれる適応力 ユーザーの見ている世界、 極端なMoving Targetへの適応 しようとすることを捉え、寄り添う 超短期開発への適応

35.

さいごに PSfitに取り組むために必要な姿勢とは、 「ユーザーのために」だけでは、視点が足りず、 捉えたユーザーの世界の中で 「自分たちが成し遂げたいこと」(意思)を持つ。 「自分たちのために」だけでは、視点が足りず、 ユーザーの世界(文脈)を捉え 「ユーザーがしようとすること」(傾向)に寄り添う。 真摯であればあるほど、目標に向かって 自然と”越境”している。