僕は、新しいアプリを作る時は、一番リスクの高い部分をまず考えるようにしてます。
これは、一番不確実な部分をまず確かめるという意味です。
でも、一番リスクの高い部分を確認するための方法は、一番簡単に、速くわかる方法を探すようにしている。
アプリやサービスのアイデアでも、プログラミングでも、全部そういうふうに考えるようにしている。
やる気なくすリスク
例えば、アプリのアイデアを考える時に、一番リスクの高い事は、「自分が途中でやる気なくして飽きてしまう事」だったりする。
どうせ作るなら、素晴らしいものを作りたいし、素晴らしいものを作るには継続することが重要なので、自分の情熱が続く、飽きないものを選ぶようにしている。
このリスクの具体的な対応策としては、新しいアイデアを思いついた時は興奮して、うおおおってなるけど、しばらく寝かせて、それでもまだ情熱が冷めてなかったら採用とか。
世の中には不便な事がたくさんあって、いろんなニーズが溢れているけど、儲かりそうだけで始めて、自分が共感できないものを始めたら続かないと思うんですよ。
ちなみに、もちろん儲からないとサービスが持続せず続かないので、やる気と儲かりそう、この二つのバランスがとても重要だと思っていて、単純じゃないからいつも悩む。
技術的なリスク
次に、重要なのは、そのアイデアが技術的に可能かどうかってとこになる。
いくら自分が欲しいもの、作りたいものがあっても、自分の技術とその時のエコシステム、既存の技術が追いついてないと実現できない。
だから、プログラミングする時も、まずは一番重要な部分で、なおかつ実現できるかどうか不確かな部分、そこからやり始める。
すでに経験してたり、自分の頭の中で、こうしたら出来るだろうと当たりがついている部分は後回し。
ちなみに、技術的に難しい事に挑戦するという意味ではないんですよ。重要な要素で、技術的に難しい部分を一番最初にやる。
同時に、可能な限り簡単に素早く実現できる技術を選ぶようにしてる。
（設計は始めが肝心だし、リファクタリングはこまめにしないと負債が倍になるからバランス重要だけど。)
製品を欲しがる人を確認するのが最優先なので、リッチな機能や、初心者にも優しいUX、カッコいいデザインは後回し。
欲しがる人がいるかのリスク
技術的に可能だとわかったとして、他人がそれを欲しいと思うかどうかを確かめたいけど、ここが一番難しい。
人によっては、ここが最も重要だから、最初に確認するべきという意見もあると思う。
ただ、僕はいまのところ、まずは自分が本当に欲しいもの、自分だったらお金払ってもよいと思うものを作るようにしているので、最初の一人はすでに確定している。だから、この順番でいいのだ。
それに、実物ができて、実際に使ってもらったり、お金をもらう前の段階で他人に聞いてもたいした事はわからないし、分っているぐらいニーズがあるなら、それこそ気にしなくてもいい。
周りの人も納得するぐらいニーズがある分野なら、競合もいっぱいいるし、出てくるだろうから、競合に勝てるかどうかのリスクが高い。
つまり、他の製品より、自分が作ったものをユーザが選んでくれるかどうか、これを確かめないといけない。
となると、結局、出来るだけ速くリリースして確かめるしかない。
速くリリースしようと思うと、ターゲットは絞る事になって、ニッチな部分から始める事になるので、スケール感もないし、他人に話す時もセクシーじゃなくなるけど、別にそれでいいと思う。
自分の環境リスク、APIやエコシステムが変わるリスク、アップストアでのリジェクトリスク、なにより、誰も欲しがらないものを作るリスク、想像もしてなかったなんらかのリスク、いろんな不確実な事がある。
なので、細かい部分は後回しで、重要な部分から素早く、手っ取り早く確認していったほうがいいと思うんですよ。
*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。
