アイディアを整理します

実現したいアイディアが解決するユーザプロブレム、提供する価値を整理します。
例えば、
　● ユーザプロブレム: お腹いっぱい美味しいものを食べたい！
　● 提供する価値　　: 安くて美味しくて腹持ち良い食べ物屋さん

アイディアの簡単なペルソナを想像します

ペルソナとは提供するサービスの一番の顧客になってくれる人の人物像です。
例えば、

G太、小学1年生男児。体重40kg。
頭はおにぎりのような形をしており、10円ハゲがある。
小学校では少年探偵団を結成しており、食べることが大好き。
他人の家でつまみ食いしたことが功を奏して事件を解決したことがある。

ペルソナの人を探してきて話を聞きます

聞きたいことは、主に以下の4つです。
　● 本当にそのペルソナの人は、想像しているユーザプロブレムを持っているか
　● そのユーザプロブレムを持っている人は、その提供する価値を価値だと考えてくれるか
　● もし、他のサービスでそのプロブレムが解消されている場合は、その競合サービスや満足していないところ
　● 似たペルソナの人にはどこで会うことができるか

この時点でイケてないと言われるサービスは、残念ながらイケてないです。
回答によっては、早期に、初めからやり直す決断をしましょう。

G太 < 昼ごはん食べても2時位にはお腹がすいちゃうんだ…

リーンキャンバスを書きます

【リーンキャンバス テンプレート】とかでググると雛形が出てくるかと思いますので埋めましょう。

ここで初めてソリューションについて深く考えます。
例えば、
　● ユーザプロブレム: お腹いっぱい美味しいものを食べたい！
　● 提供する価値　　: 安くて美味しくて腹持ち良い食べ物屋さん
であった場合、ソリューションはお好み焼き屋さんでも、ハンバーガ屋さんでも、大学の近くによくある600円くらいでお腹いっぱいになる定食屋でもいいわけです。
まず初めの一手としてどの分野でやっていくかを、コストだとか、ユーザの母数だとか、競合についてだとかを考えて、決めていきます。

開発者 ＜ 育ち盛りのG太くんに必要なのは健康的でバランスの良い食事だ！！玄米にして満腹感を持ってもらおう！！

余談ですが、tinycanvasというリーンキャンバスを書くためのwebサービスが神だと思っていたのですが、無くなってしまったので悲しいです。

競合について詳しくなります

どんなサービスでも必ず競合になりうるものがあります。国内外問わず競合を探して詳しくなりましょう。
そして競合のイケてるところと、イケてないところを探して、どういう理由でそうなっているのか観察します。
イケてないところには理由があって、その課題には自分たちも直面することになる可能性が高いです。
また、UI面でもユーザの学習コストがかからないというメリットがあるので、いい意味で、競合の真似をしちゃうのも良いと思います。

プロトタイプを作ります

自分自身がソリューションについて考えるために、そして、人にどんなソリューションであるか伝えやすくするために、プロトタイプを作ります。
この時に作るものは、ペーパープロトタイプでもなんでも構いません。
とにかく手を動かすことで気づきがたくさんあります。

アプリ開発の場合、非エンジニアへのおすすめはProttというアプリで動くプロトタイプが誰でも作れちゃうツールです。prottapp.com
エンジニアなら、実機ビルドが無料でできるようになりましたし、storyboardでポチポチすればいいと思います。
そこまで手をかけなくても、例えば簡単なLPのような印刷物を作ったり、チラシを作ったりしても、人に伝えやすくなります。

ユーザインタビューします

カスタマーセグメントに書いた人を呼んできて、プロトタイプを見せて、ソリューションについてどう思うか話を聞きます。
その他、リーンキャンバスを書いた時に、分からなかったことや、仮説立てたことを質問します。

ユーザインタビューは、やり方からして色々あり、人の話を引き出す方法は奥が深いです。
実りあるインタビューにするためには、専業の方にお任せできるならした方がいいです。

自分自身がインタビューをすることのメリットが
　● 録画や、別室で見るより、些細な表情などの温度感やニュアンスを理解できる
　● 聞きたいことを間違いなく、聞きたい通りに聞ける
であり、デメリットが、
　● 主観が入りすぎてしまう。対象者が意見を言いづらくなってしまう。
　● 会話をつなげることをを頭の片隅で常に考えなければいけないので、集中できない
かと思っています。

G太 < 玄米？そんなのよりポテチ食いてぇ

しょんぼりして、何回か繰り返します

初めのインタビューはだいたいしょんぼりします。
特に専門的な分野だと、一般人ってこういうリテラシーなのか…と思ったり、
自分的には価値をすごく感じることに、価値を全く感じてもらえなかったりします。
しかし、インタビューしていなかったら、たくさんのコストをかけてから、売れない現実を突きつけられるわけです。
先に分かってよかった、と思って、気を取り直してもう一度、リーンキャンバスを書き直しましょう。

そろそろ行けるかなって思います

何度かインタビューを繰り返して、自分の中でも詳細に作りたいもののイメージが出来てきて、
それに対する良いフィードバックをもらえるようになり、何が解決しなければいけない課題なのかも分かるようになります。
そうなったら、満を持して、次に進みましょう。

インセプションデッキを作ります

インセプションデッキとは？この本に詳しく書いてあります。
アジャイルサムライ−達人開発者への道−

【インセプションデッキ ppt】とかでググるとパワポが出てくると思いますので、わいわい埋めましょう。
また、このタイミングでサービス名とロゴも決めると良いと思います。

リリース日と目標を決めます

インセプションデッキとリーンキャンバスができていれば自ずと決まってくるかと思いますが、リリース日の目安と、目標を決めます。
目標は、リリース後1ヶ月で1万ダウンロード、5週目アクティブ率50%、みたいなものです。
目標は1つじゃなくてもいいですが、1回目のリリースはざっくりでいいと思います。
これを達成できなければどうするのかだとか、何を持ってサービス継続不可と判断するかも考えておくとシャキっとします。

ユーザーストーリーマッピングをします

インタビュー用のプロトタイプのことは忘れて、イチからユーザーストーリーマッピングをしましょう。

リーンキャンバスとかインセプションデッキは何度も書き直すんですが、ユーザーストーリーマッピングって私はほんとに最初の最初しかしないので、いつも忘れて、いつもこのブログさんを読み直してやってます。
ユーザーストーリーマッピングで地図を書き、ソフトウェア開発の旅に出よう！ | 世界はどこまでもシンプルである

バックログを作ります

バックログ、見積もり、優先度付当たりは、先述のアジャイルサムライが勉強になります。
アジャイルサムライ−達人開発者への道−

バックログ(≒ ストーリーのリスト)を作ります。色々ツールが有りますが、私はまだ良いものに出会えておらず、GoogleSpreadSheet派です。
何がいいかと言いますと、一意の順位付けができて、並び替えが用意で、修正がチーム全体にすぐ反映されることと、
いろんな目線で見たいときに列の非表示機能やフィルターが便利です。

見積もります

各ストーリーがどれくらいの難易度でできるかを見積もります。
プランニングポーカー、なんてものもありますが、私はSML方式くらいのざっくり三段階が好きです。SMLで始めたつもりが、だいたい終わる頃にはLLとかが出てきてますが。
大まかな設計は、インセプションデッキで終わらせておくと話がスムーズです。
本当は難易度見積りに言語などは関係ないと思うのですが、難易度見積もりに慣れてない人はある程度具体的に想像できる環境にしてあげないと、見積もるのが難しいようなので、言語やAWS使うのかとかもインセプションデッキで話しておくと、良いかと思います。
この時、開発環境の構築などはじめに必要なものはできている前提で見積もります。

見積もれたらリリース日から逆算して、どれくらいのペースでタスクをこなしていかなければいけないのかを知りましょう。

優先度付をします

開発のしやすさや、ユーザからの意見を早く聞きたいもの、最悪なくても必要な機能などを考えて、開発する順番を付けます。
下の方まできちんと順番を付ける必要はありません。上からこなしていって、近くなったら考えましょう。

準備期間を経て、上から開発します

開発をはじめます！見積もりの時に計算したペースより、おそらくはるかに遅いペースでの開発となると思います。
しかし、1週目は遅いものです。あまりあせらずに、みんなで効率よい仕事の仕方を模索していきましょう。

必要なら開発開始までに準備するための時間を作って、micro serviceにするのかとか、ドキュメント何で書くかとか、ライブラリとかフレームワークを相談するなどしても良いと思います。スクラムでいうスプリント0です。

適宜インタビューをします

見れるものができたらインタビューをします。実際に触ってもらってどう感じるのかを聞きましょう。
開発が始まってからのインタビューでは、主にソリューションからアウトプットが大きくズレていないかや、本当にユーザにとって使いやすいのがそのUXなのかを聞きます。
この時期のインタビューで、提供しようとしている価値からして全く刺さらないユーザさんが出てくると、不安になってしまいますが、あまり気にしてはいけません。
逆に、この時期に不安にならないくらいには、開発前に調査をして、提供しようとしている価値には確信を持っておく派です。
もし、開発前は刺さったのに、この時期に刺さらないのであれば、
過去のインタビューで話したソリューションと実際に出来ていているアウトプットに差異があることを疑いましょう。

ただ、全く刺さらない人がある程度いるようなら、市場が変化した可能性もあるため、一度開発を止めて練り直すのも必要かもしれません。

スコープ？リリース日を守る？と、迷いながらリリースします

インセプションデッキのトレードオフスライダーで、順番は決めているかと思いますが、再確認します。
この時期になると企画はあれもこれも入れたい気持ちになり、開発はリリース日を考えて動いているのでスコープの追加には不安になりがちです。
正しい判断をして、リリースを迎えて、チームで銅鑼を鳴らすなり、くす球を割るなり、お寿司をたべるなどしてお祝いしましょう٩(๑❛ᴗ❛๑)۶

数字を検証します

まずは、立てた目標を検証します。
そして、コホートとかファンネルとかを見て改善点を思いつきます。GoogleAnalytics超便利。
また、このままユーザ数が増えて問題ないか、コスト上の課題などを計算します。

実際に使ってくれた人からインタビューします

自然流入して使ってくれた人の話が聞ければ、話を聞きまくります。
たとえ、離脱して使わなくなったとしても、どういう期待を持ってサービスを使い始め、どういう理由で使わなくなったのか根堀り葉堀り聞きます。
プロダクトを我が子のように感じてしまい、一喜一憂します。

聞いては作り、聞いては作り、を繰り返します

ユーザの欲しいものを作るという意味ではなく、作りたいものが伝わっているか、進んでいる方向性があっているか、実現したいものの一番使いやすいUXはどれかを聞きます。
定性調査だけではなく、定量調査や、ログを仕込んでユーザの動きを追うなども大変ためになります。
あとは繰り返しです。きっと本当はもっとお金の話とか、政治の話が絡んでくると思いますが、ユーザーのことを一番に考えます。

プロモーションします

カスタマーセグメントや、ユーザインタビューを通して知った流入経路から、最適だと思う方法でプロモーションします。
どんどんユーザが増えて、新しいサービスが成功しますように。