爆速で仮説検証のループを回すために試したこと

f:id:numanuma08:20200719074937j:plain
夏だ・・・

こんにちは、id:numanuma08です。最近コベリンではアウトプットを対外的にアピールしていく方針を打ち出したので、積極的にブログを書いていきます。よろしくお願いします。今回のお題ですが、私が社内で新規サービス開発を行うための仮説・実験・検証のループを短い期間で何度も行うために実施したことをまとめます。

仮説・実験・検証ループとは

コベリンでは以前より自社サービスとしてfeatherやfacilioを提供しています。

covelline.com

https://facilio.team/facilio.team

これらに加えて更に新規事業をやろうと、模索を続けています。その一環で私が新しいアイデアを思いついたためそのアイデアが価値あるものなのか調査する必要があります。具体的には「人々は家にある品物の在庫を把握しておらず、買い忘れや重複買いをして困っている」というアイデアです。このアイデアを検証するため、次の観点で仮説を検証することとしました。

  1. この世の中にはアイデアに挙げた課題を抱いている人がいる
  2. 課題を抱いている人はXXXという手段を用いて課題の解決を試みている
  3. 課題を抱いている人にYYYというソリューションを提供できれば、課題を解決できる

課題を抱いている人がこの世に存在しているのか発見した後、その人が今どうしているのかを知りそしてその人に適切なソリューションを提供する流れとなります。このようにリストで表現すると1つの手順を順番に行うように見えますが、実際には次の図のように1つの仮説を検証するための実験と検証をループさせる構造となっています。

f:id:numanuma08:20200722144057p:plain
仮説を検証する手順

ここからは各仮説を検証するめに行った実験を紹介します。

課題を持っている人をみつけるためにやったこと

実はコベリンでは以前からGoogleフォームのアンケートを利用していました。アンケートの結果をもとに顧客見込みとなる人にインタビューを行い、課題を持った人がいることを検証を試みていました。今回私は次の理由からこの方法を選びませんでした。

  • アンケートやインタビューでは個人の行動への結びつきが弱いように感じていた
  • アンケート、インタビュー結果の分析が苦手

「個人の行動への結びつきが弱いと感じていた」点は聞き方(クローズド・クエスチョンをしないなど)の工夫はしていますが、本当にその人が課題を持っているのか観察できません。課題を持っている顧客候補を見つける意味でアンケートやインタビューは有用そうだけれど、それ以上の価値は無さそうだと思いました。次に「分析が苦手」については言葉通りの意味で、今まで何度か行ったアンケートやインタビューから大事な情報を取りこぼしていたり大事なことを聞き出せていないように感じていました。そこで今回新たに私が行った方法は「めちゃくちゃ低コストにソリューションを作って運用してしまう」でした。Line businessアカウントを作成してツールを公開、バックエンドにスプレッドシートを使うことでシステム構成自体は半日程度で完成しました。システム構成を図にすると次のようになります。

f:id:numanuma08:20200722144813p:plain
最初のMVPシステム構成図

あとはShutterstockでそれっぽい画像のダウンロード、Lookaを使ってロゴの生成、Wixでティザーサイトの実装をしてTwitterやFacebookで告知しました。

shutterstock.com

looka.com

ja.wix.com

実際に課題を解決するためのソリューションを爆速で提供し、課題を抱えている人を発見しコンタクトできる状況としました。ソリューションを継続的に利用している人は顧客である可能性があると言うことです。

課題解決の方法を知るためにやったこと

課題を抱えている人を見つけた後にようやくインタビューします。実際に提供しているソリューションを使ってどうだったのか、使う前はどうだったか、今後どうなると良いのかを訪ねます。もともとインタビューの結果を分析して活かすことが苦手だったのですが、今回から新たにGoogle Jamboardを利用してインタビュー結果を眺めてみました。実際のJamboardの図が次のものです。

f:id:numanuma08:20200722145001p:plain
jamboardでインタビュー結果をまとめた

Jamboardに得られた回答を付箋形式で並べると、同じ意見を集めたりカテゴリー化ができました。複数の人からあげられた同じ意見は重要度が高いものとしてマークし、さらに実際の行動や困りに結びついているものほど重要であるとしました。この結果をもとに提供中のLineを利用したサービスはマッチしないらしいこと、もっと別のソリューションが求められていると分かりました。

ソリューションを提供するためにやっていること

これは現在進行系です。課題は実際にあって課題を持っている人がいるらしいこと、課題を解決するソリューションが求められているらしいことが分かりました。次は適切なソリューションの開発です。アプリエンジニアである私としてはスマホ向けアプリを作ってリリースしたいところですが、スピード感を考えるとそれは最適ではありません。今回はglideというno codeアプリケーション開発ツールを利用しました。

www.glideapps.com

glideはGoogleスプレッドシートをバックエンドとしてアプリの開発をコーディングをすることなく行うツールです。データの表示・編集・削除・追加はもちろんアカウント管理機能も提供しています。在庫管理アプリや買い物リストアプリであれば全くコードを書くことなく実現できます。その一方ですこし複雑な動作を実現するには何らかの方法で手を加える必要があります。例えば少し複雑なUIの提供。これについては諦めてglideで実現できるUIのアプリケーションを実装しました。スプレッドシートの変更をトリガーに処理をする場合もコーディングが必要です。今回は1つのスプレッドシート中の2つのシートのデータを連携したかったので、Google Apps Scriptを使いました。glide上からスプレッドシートのデータを変更するとスプレッドシート変更イベントが発生します。Google Apps Scriptのトリガーでスプレッドシート変更イベントをフックして複数のシート上のデータを連携させました。この際、安全にGoogle Apps Scriptのコードを書くためにGoogleが提供するclaspを使ってTypeScriptでコードを書いています。

github.com

glideとGoogle Apps Scriptを使ってアプリケーションを実装するためにかかった時間は1日未満でした。

ちなみに、glideでスプレッドシートを変更した場合に発行されるイベントは「変更」です。「編集」イベントもApps Scriptに定義されていますが、こちらは発行されないので注意が必要です。

community.glideapps.com

今後について

サービスとしてリリースできる状況になっていませんが、現在このような活動で新規サービスの開発を進めています。アプリケーションの開発コストが低いことで仮説の検証のための実験が簡単にできます。ユーザーとのコミュニケーションを通してよりよい仮説の考案と検証のための実験を継続する予定です。

まとめ

私が社内で新規サービス開発を行うための仮説・実験・検証のループを短い期間で何度も行うために実施したことをまとめました。短い期間で何度も検証をするため、それぞれのタスクにかかるコストを可能な限り落としています。この方法がベストであるとは思いませんが、今後新規サービス開発のための活動の中でこの方法を発展させていく予定です。