Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

要件を捨てて検証に出よう。賃貸情報サイト"カリル"での 仮説検証型システム開発 | Livesense Inc.

17,658 views

Published on

2ヶ月で不動産賃貸情報サイトを少人数で開発して、と言われたらどうしますか。
「決まりきっていない要件」、「決まっている締切」、「限られたスタッフ」。炎上しそうな匂い。要求を「捨てて」開発し、ユーザーの声・マーケットの反応を見ながら仮説検証を行って、プロダクトを育てている事例紹介です。

Published in: Technology

要件を捨てて検証に出よう。賃貸情報サイト"カリル"での 仮説検証型システム開発 | Livesense Inc.

  1. 1. 要件を捨てて検証に出よう 仮説検証型システム開発 賃貸情報サイト カリル を例に 。 株式会社リブセンス/河原塚 有希彦 How LivesensE Works #2
  2. 2. 2ヶ月で 不動産賃貸情報サイトを 少人数で開発して、 と言われたらどうしますか
  3. 3. 炎上しそうな匂い 決まりきっていない要件 ☓ 決まっている締切 ☓ 限られたスタッフ http://commons.wikimedia.org/wiki/File:Deerfire.jpg
  4. 4. https://cariru.net/ 今日は 賃貸情報サイト の話です 「カリル」は (株)ハイタイムとの共同運営
  5. 5. 2014年 年末
  6. 6. 事業リーダー氏 「いよいよ前から考えていた 賃貸仲介業に乗り出そう! まずは繁忙期に ベータテストしたいので 3月にはリリースしたい」 © Kevin Dooley/Business.
  7. 7. 2010年から運営している「door賃貸」 とは異なる業態
  8. 8. 期間は実質2ヶ月
  9. 9. 普通にやると炎上する 1.決まりきっていない要件 ☓ 2.決まっている締切 ☓ 3.限られたスタッフ http://commons.wikimedia.org/wiki/File:Deerfire.jpg
  10. 10. 1.決まりきっていない要件 そもそも 新しいサービスをつくろうとしているので 決まるはずがない。 普通に開発を進めると、 開発中に仕様がコロコロ変わる匂い。
  11. 11. 2.決まっている締切 3月は引っ越しシーズン。 様々なニーズを持つお客さんに触れ、 ビジネスとして行けるか判断したい。
  12. 12. 3.限られたスタッフ 従来からのdoor賃貸を 運営するスタッフ内での新企画。 door賃貸を運営しながらの開発になる。
  13. 13. Quality Cost Delivery QCDの観点から考えると
  14. 14. QualityCost Delivery Quality(品質)を下げる? 実際にお客様に使ってもらい 金銭授受も発生するので 下げるといっても下げられらない
  15. 15. Quality Cost Delivery Cost(人件費)を増やす? 後述するように事業に対する 理解・経験は大事なので、 短期的に増減させにくい
  16. 16. Quality Cost Delivery じゃあ1人1人の稼働時間を伸ばす? 年末は紅白見るし
 お正月はお 蘇飲んでるし
  17. 17. Quality Cost Delivery Delivery(締切)を伸ばす? ※経験上、 締切を伸ばしてもなぜかデスマになる。 繁忙期があるので 伸ばししたくない
  18. 18. Quality Cost Delivery ぜんぶ大事
  19. 19. 画像:pixabay (geralt)
  20. 20. 変えられるのは 「やること・やらないこと」の調整
  21. 21. 立ち上げ時にすべての機能は必要か
  22. 22. スタートアップは誰も欲しがらない ものを作ってしまうことが多い。 (中略) 目標は、できるかぎり早く、 作るべきモノを突き止めることだ。 エリック・リース 「リーン・スタートアップ」
  23. 23. プロダクトのフィーチャの64%は、 めったに、 あるいはまったく利用されない マイク・コーン 「アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法 」
  24. 24. 「捨てる」同意を関係者と取る
  25. 25. 要件のうち、MUSTな項目と WANTな項目を分けるのが重要
  26. 26. でも結局全部やれ、ってなる? (あるある)
  27. 27. ではどうやって「捨てる」か?
  28. 28. 「捨てる」 ¦¦ 怠惰?
  29. 29. 「捨てる」 ¦¦ 怠惰?
  30. 30. 「捨てる」 ¦¦ 機能不足のシステム ¦¦ 悪いこと?
  31. 31. 「捨てる」 ¦¦ 機能不足のシステム ¦¦ 悪いこと?
  32. 32. 「捨てる」 ¦¦ コンセプトを明確にして、 やるべきことを先鋭化させること
  33. 33. 「捨てる」 ¦¦ コンセプトを明確にして、 やるべきことを先鋭化させること
  34. 34. やることを先鋭化し、 リリースサイクルを 短くすることで、 仮説検証サイクルを 高速で回す 出典:エリック・リース「リーン・スタートアップ」 アイ デア 開発 プロ ダクト 計測 データ 学習
  35. 35. 要求は不明瞭でよいが コンセプトは明確にする •仲介事業に乗り出すのは何故か •なぜβなのか •βで知りたいことは何か •なぜ繁忙期なのか •知りたい数値は何か •知りたい肌感は何か
  36. 36. 事業リーダーと何度も話した。 (時間もかけた)
  37. 37. 明確にしたコンセプトは共有する
  38. 38. 質問に答え、 疑問を解消し共有する
  39. 39. 「ミニマムっぽい機能だけの 賃貸不動産サイトでいいっぽい」 目的を何度も聞き、 コンセプトを明確化した結果 「 サイトの性能によるビジネスの可能性より も仲介ビジネスそのものの性能を測りたい」 事業リーダー氏 開発リーダー氏
  40. 40. 序盤にコンセプトを固められ、 なにをやるべきかを先鋭化でき、 「捨てる」判断を行いやすくなった
  41. 41. コンセプトが統合されたシステムは、 より速く作り上げられるし、 より速くテストできる。 フレデリック・P・ブルックス Jr 「人月の神話」
  42. 42. 固まったコンセプトをベースに、 キックオフミーティングで共有
  43. 43. 内容は「インセプションデッキ」から抜粋 我々はなぜこ こにいるのか エレベーター ピッチ パッケージ デザイン やらないこと リスト 「ご近所さん」 を探せ 解決案を描く 夜も眠れない 問題 期間を 見極める 何を 諦めるのか 何がどれだけ 必要か
  44. 44. プロジェクトを核心まで煮詰めて抽出 した共通理解を、開発チームだけじゃ なく、より広範囲なプロジェクト関係 者全員へ手軽に伝えるためのツール インセプションデッキとは Jonathan Rasmusson 「アジャイルサムライ」
  45. 45. (キックオフ資料より「夜も眠れない問題」一部抜粋) 手厳しい質問と回答を 最初に共有することで、 「捨てる」判断がつきやすくなる
  46. 46. キックオフ後、いざ「捨てる」となると 迷い。戸惑い。諦め。 俺のアイディアを...。 これを切ってもいいのだろうか...。 あった方が良いに決まってる... 画像:pixabay.com(nemo)
  47. 47. 「捨てる」ために必要なこと: 不動産ビジネスの理解 ビジネスを理解したうえで、 今回のコンセプトに則しているかを判断
  48. 48. 大きなところでは こだわり条件を捨てた 画像:door賃貸のこだわり条件
  49. 49. こだわり条件を「捨てた」ことで、 技術的負債を膨らませずに、 開発工数を大きく抑えられた(後述)
  50. 50. 「捨てる」効果: 開発がしやすくなるだけではなく、 事業リーダーの判断の助けにも ベータ版リリース振り返り資料より
  51. 51. 事業リーダーが助かった点は、、 ・「どうせ捨てられる」から、  遠慮せずに要求の提案ができる。 ・「捨てる」前提なので、  企画・調査も軽量化される。
  52. 52. うまくいくようにするためには,出資 者と利害関係者のすべてが,どの要求 項目が「やらねばならぬ」区分に入り (中略)どの要求が「やれればやる」区 分に入るかについて同意しなければな らない. エドワード・ヨードン「デスマーチ」
  53. 53. とはいえ「捨てる」のは難しい door賃貸を長く続けてる人が多かったの で、迷いを取り払えた。 (デスマになってから開発メンバーを集めてきても こうした効果は期待できない)
  54. 54. 入社から日が浅い人は ちょっと振り回されてしまった :( ベータ版リリース振り返り資料より
  55. 55. 開発面では、 *aaSを活用して「作らない」
  56. 56. 技術的負債とのつきあい方(1):コード面 「そもそも負債を産まない努力を」 将来行ったほうがいいものは先送りし、 ひどいコードで中途半端に作りこまない。
  57. 57. 技術的負債とのつきあい方(2):コード面 「返済を考えて負債を作る」 スピード重視でもテストは書く
  58. 58. (前述のとおり)開発スタッフの 急な異動・増減おこなわない方針 ¦¦ (他の人ではなく) 負債を作った本人が返済できる 技術的負債とのつきあい方(3):環境面
  59. 59. モデリングはビジネスの分析が必要 で、かつ時間がかかる。 ビジネスとして行けるか不透明な現 段階では、モデリングしないことと した(先送り=負債とした)。 今回のPOINT: データモデリングをしない
  60. 60. これが 「こだわり条件」 検索できない理由。 物件情報を モデリングせずに そのまま全文検索
  61. 61. そして 2015年 3/10 という名で リリース
  62. 62. zeroという名は 「仲介手数料ゼロ」 に由来
  63. 63. アイディアが 形になった瞬間。 アイ デア 開発 プロ ダクト 計測 データ 学習
  64. 64. できたプロダクトで 仮説の検証を行える ように。 アイ デア 開発 プロ ダクト 計測 データ 学習
  65. 65. 検証1. 指標(率)の測定
 検証2. ユーザーテストの実施 定量的にも定性的にも 検証
  66. 66. 指標測定は 物件契約者が出だしたあたりで 実施
  67. 67. 数字面とユーザーの声を合わせて検証 数字は率(CVRなど)で測定し、 量は追わない(必要以上に広告・PRしない) ビジネス振り返り資料より
  68. 68. 2.ユーザーテストの実施
  69. 69. ユーザーテストの 実施にはコツがある
  70. 70. ユーザーテストの一番のコツ: 「まずやってみる」 ユーザテスト振り返り資料より
  71. 71. もうひとつのコツは、 事前準備をしっかりと
  72. 72. あらかじめ全て書き出しておく
  73. 73. 最初にトークスクリプトを作っておくと、 現場であわてずにすむ。
  74. 74. 文言はかなり流用できるので、 次回以降、楽に実施できる
  75. 75. 質問するときはオープン・クエスチョン 誘導せずに、行動の理由を引き出す
  76. 76. ちょっとしたコツ1 わずか5人を呼んで調査すればよい http://u-site.jp/alertbox/20000319
  77. 77. 今回は、社内の他事業部の アルバイトさんに依頼
  78. 78. ちょっとしたコツ リラックスさせるアナウンスとお菓子 「テストではなく、 サイトを使ってみて頂いて正直な感想が 聞きたいだけです。 心の声を聞かせてください」 © Fabien G./Tea-time
  79. 79. ちょっとしたコツ 事前事後の録音も © Joe Valtierra Follow/ Flip a tape 雑談モードの瞬間に 本音が出ることも多い
  80. 80. そして実施
  81. 81. 1. 機能を「捨てた」システムで ユーザーテストをして、 意味があるのか? 2. 「機能不足」の苦情が出るだけ ではないか? ユーザーテストに対する よくある疑問
  82. 82. 実際、厳しい意見が多いが、、 ユーザテスト振り返り資料より
  83. 83. 1. 機能不足の苦情は、 正しい道を進んでいる証拠。 2. 逆にロードマップ上にあるのに
 苦情がこなかった機能は、 考えていたほど重要ではない。 エリック・リース 「リーン・スタートアップ」
  84. 84. 心が折れるフィードバック
  85. 85. 厳しい意見が多く出るが、 そこから何を学べるか
  86. 86. 学びにつながるコメントも
  87. 87. ユーザーテストと 指標の計測結果を 組み合わせて、 商品を再検討 アイ デア 開発 プロ ダクト 計測 データ 学習
  88. 88. 「無料でもどうせ 何か取られるんでしょ?」 という声から、 「理由がある安さ」 を訴える商品設計に変更
  89. 89. meta情報では 「無料のあやしさ」をなくし ユーザーが不動産屋さんに感じていた メリットを盛り込む
  90. 90. 【カリル】なら仲介手数料は最大5万円!割引メニューでさらに 安く、ご希望のお部屋を探せます。一般公開の物件に加え、未 公開物件300万件からご提案。Skype(TM)中継でお部屋見学 もできます。 meta情報
  91. 91. 「何がゼロ円かわからない」 というコメントを元にドメイン・ロゴ変更 https://door-zero.com/ https://cariru.net/
  92. 92. 顧客に対する価値仮説を 「無料」から「ネット完結」 に変更
  93. 93. 学びをもとに、方向転換(ピボット) アイ デア 開発 プロ ダクト 計測 データ 学習
  94. 94. そこまでに費やしたお金と時間、 エネルギーが少なければピボットしやすい。  ­「捨てる」開発  ­ door zero での広告投下・PRは最小限 当初のアイデアからは変わったが
  95. 95. まとめ
  96. 96. 仮説検証サイクルが一回転することで、 仮説と現実の離れ具合を知ることができ、 仮説の精度が上がり事業成長に近づく。 アイ デア 開発 プロ ダクト 計測 データ 学習
  97. 97. このサイクルをたくさんまわすためには、 「捨てる」ことをおそれず小さく開発し アイ デア 開発 プロ ダクト 計測 データ 学習
  98. 98. アイ デア 開発 プロ ダクト 計測 データ 学習 小人数のユーザーテストと 率測定から学びを得て
  99. 99. アイ デア 開発 プロ ダクト 計測 データ 学習 よりユーザーに価値を提供するために 大きな方向転換(ピボット)をいとわず 開発を進めることが大事
  100. 100. もっと詳しく知りたい方は、 Wantedlyの【話を聞きに行きたい】から アイ デア 開発 プロ ダクト 計測 データ 学習 https://www.wantedly.com/projects/15535
  101. 101. Mark Cook(Kodak) 成功とは(単に)機能を提供することではありません。 成功とは、顧客の問題をどうしたら解決できるのか 学ぶことです。 エリック・リース 「リーン・スタートアップ」より抜粋

×