挫折しない個人開発の３ステップ
最近、エンジニアの間で個人でプロダクトを立ち上げる人が増えています。
いや、近年「ノーコード」や「ローコード」といったバズワードが流行っていることから察するに、エンジニア以外でも、自分のプロダクトを持ちたいと考えている方が増えているのではないでしょうか？
会社やチームではなく、自分一人の力でプロダクトを開発してリリースすることを『個人開発』といいます。
個人開発は、夢のある創作活動だと思います。
自分の作りたいものを自由に作れるし、最近は個人開発したプロダクトを事業化したり、大手企業に売却するといった景気の良い話も増えました。
現代は開発周りのインフラやAPIといった周辺サービスや教材も充実しているので、ひと昔に比べて格段に個人開発もしやすくなりました。
しかしその一方で、多くの方が個人開発で挫折されているらしいです。
先日、大手メディア様にインタビューを受けたときも、そうした挫折に対するアドバイスをご質問いただきました。
（22/03/28にインタビューされた内容の記事が公開されました！！）
私は「習慣化の技術のすべて」のような記事も書いてるくらいですから、挫折や習慣化に関する知識について、人よりもよく知っているほうだと思います。
個人開発についても長いですし、実際に私が開発しているDiQtは、個人開発の初心者が犯しそうなミスは一通り犯してきたので、その経験からも少しはお役に立てることが言えるのではないかと思います。
では、「挫折しない個人開発の方法」として、先に私なりの結論を述べさせていただきます。
『自分が使いたいものを作り、恥ずかしいうちにリリースし、自分で使い続ける』です。
何を作り、どこを目指しているのか？
個人開発は自由です。
そして自由なところこそが、個人開発のいいところだと思います。
毎年開催される「クソアプリアドベントカレンダー」なんて、自由な個人開発だからこそできる最高のイベントだと思っています。
ただ自由だからこそ、「自分が何を作りたくて、それで何を目指しているのか」は自覚できていた方がいいと思います。
個人開発をする人には、さまざまな動機があります。
技術を学ぶために作る人もいるし、
お金を稼ぐ事業として作る人もいるし、
就職のためのポートフォリオとして作る人もいるし、
他人に使ってもらいたくて作る人もいるし、
ただ自分が作りたいから作る人もいる。
たとえば、もしもあなたが「ただ自分が作りたいから作る人」ならば、この記事を読む必要はないかもしれません。
こういうトートロジーの動機はとても強いので、無事リリースできるでしょうし、挫折なんてしないでしょう。
昔私が使っていた美術教本に、今でも忘れられない言葉があります。
「自分のやり方のほうが好きだという内発的な声を無視してはならない。」
散々ノウハウを語った上でこんなことを言うのでびっくりしましたが、それが「アーティスト」というものだと思います。
個人開発は、漫画と同じようなアートの部分もあるので、こういう内発的な感性は大事にしていきたいものです。
また、もしもあなたが「お金を稼ぐ事業として作る人」ならば、今は新しい技術を学ぶ必要すらないかもしれません。
事業によっては、立ち上げるのに重要なのは「お金を払ってもらえる課題の検証」と「資金調達」だったりします。
ノーコードや既存のツールの組み合わせで「実際にお金を払ってもらえるか？」というところを検証できるなら、たとえプログラマーであっても、プログラムを組むよりもまずその検証から始めた方が効率的かもしれません。
そしてプログラムを組む前に、ベンチャー・キャピタルなど投資家に出資をお願いする方が効率的かもしれません。
そういう意味では、「Smart HR」さんのMVPなどはとても参考になると思います。
その前提の上で、その作品を作るために新しい技術を学ぶ必要があるなら、現代はとても恵まれた時代だと思います。
progateやドットインストールやUdemy、QiitaやZennと教材には事欠かないですし、私は独学でスクールに通ったことがないのでわかりませんが、お金があればスクールに通ったっていいわけです。
となると、個人開発の障害となるのはモチベーションぐらいになるので、その点についてお話しさせていただきます。
これは私が実感している１つの例でしかありませんが、個人開発の挫折を防ぎ、モチベーションを保つには、３つのステップがあると思います。
・「他人にウケそうな」サービスではなく、「自分が実際に使いたい」サービスを作る。
・「リリースしたらバズるかも」みたいな淡い期待をせずに、恥ずかしいうちにリリースする。
・リリースしたサービスを自分が使い続ける。
この３つです。
「他人にウケそうな」サービスではなく、「自分が実際に使いたい」サービスを作る。
これは割と重要なことで、そうすべき理由としては、サービスの改善が自分の生活の改善になるからです。
前提として、個人開発をリリースしても、しばらくは自分しかユーザーがいないと考えたほうが気が楽です。
実際ほとんどがその通りなので、「これはウケそうだな」と開発・リリースしたのに、期待を裏切られて無風で悲しくて惨めになってクローズみたいなことはよくある話だと思います。
しかし、「自分が使いたい」サービスだったら、この悲しみの挫折を超えられます。
自分一人しかユーザーがいなくても、自分にとってそのサービスが役立つなら、そのサービスを続ける価値を感じられるからです。
さらにこの場合、たとえあなたの他にユーザーがいなかったとしても、サービス改善のモチベーションにもつながります。
なぜなら、あなたが日々使うサービスならば、サービスの改善それ自体が、あなた自身の生活の改善につながるからです。
やはり人間は、自分自身のために働くとイキイキするものなので、「他人の欲しがりそうなもの」より「自分が使いたいもの」を開発するのは、おすすめのモチベーション戦略です。
さらにいうと、「自分が使いたいもの」を開発することは、サービスの成功確率を上げることにも繋がります。
Y Combinatorのポール・グレアムは、スタートアップが選ぶべき解決課題として、もっとも良いのが「自分の抱えている課題」、次点で「自分の身近な人間が抱えている課題」を挙げています。
他人というのは混沌です。
私は人よりも心理学を学んでいる自信がありますが、それでも他人のことがわからないことばかりです。
そんな他人の課題を理解して解決するというのは、とても大変な作業です。
それに比べれば、自分の課題を理解するのは簡単ですし、解決もしやすいです。
なにせ、ただあなた自身と向き合えばいいだけなのですから。
そして、あなたは決してオンリーワンではないので、あなたと同じ課題を抱えている人は世の中に大勢います。
そのため、あなた自身の課題を解決することは、他の人の課題を解決することに繋がり、結果としてユーザーの獲得と定着につながるのです。
あなたが「こういうサービスがあったら使いたい」と強く思うとき、その背後には必ず「そのサービスによって解決したいあなた自身の課題」があります。
その課題を明確にし、その課題を解決するサービスを開発するのは、サービスの成功確率を上げるだけでなく、サービス改善のモチベーションを保つ上でも、とてもお勧めできる個人開発です。
「リリースしたらバズるかも」みたいな淡い期待をせずに、恥ずかしいうちにリリースする。
個人開発の挫折を防ぎ、成功確率を上げたいならば、さっさとリリースするのは得策です。
LinkedInの創業者リード・ホフマンは、「リリースが恥ずかしくないなら、そのリリースは遅すぎる」という言葉を残しました。
これはスタートアップ業界ではよく知られた名言ですが、個人開発においてもある程度正しい言葉だと思います。
個人開発であっても、最低限作れた時点で、さっさとリリースすべきです。
デザインがダメとか、機能が足りないとか、自動化できてないとか、スケールできないとか、リリースするのが恥ずかしい理由はたくさんあるでしょう。
しかし、その恥ずかしさを無視してリリースし、ユーザーの反応からいち早く学んだ方がたいていは良い結果になります。
たとえ「誰一人使い続けてもらえなかった」としても、「今のままだと使い続けてもらえない」ことをいち早く学べることが、今後開発を続ける上で大きな財産になります。
個人開発でありがちなのは、開発期間が長すぎることで、リリースに対する期待が高まりすぎて、リリース後のユーザーの反応が怖くなり、その恐怖から逃れるためにさらに開発期間を延長し・・・というのを繰り返して最終的にサービスそのものがリリースされずにお蔵入りすること。
あるいは、自分の中の期待が高まりすぎたことで、リリースした後の反響のなさに心が折れて、人知れずクローズすることです。
この現象には、「巨大バッチ死のスパイラル（large-batch death spiral）」という名前が付いています。
「バッチ」というのは、「リリースするまでの開発期間」と考えてもらって構いません。
この概念は、「リーンスタートアップ」という有名な書籍で紹介されているものなのですが、とても感銘を受ける文章なので原文を引用します。
製造工程と違って製品開発はバッチサイズに物理的な上限がなく、どこまでも大きくできるため、これは巨大バッチ死のスパイラル（large-batch death spiral）と呼ばれる。
最終的にはあるバッチがすべてに優先するプロジェクトとなる。
前回リリースのあとに使った時間があまりに長くて、新バージョンの製品が「会社を賭ける」タイプになってしまうのだ。
このときマネージャーは、製品の出荷よりバッチサイズの拡大に走りがちだ。
開発期間の長さを思えば、バグをもうひとつ直したり機能をもうひとつ追加したりしたくなる。
致命的な欠陥になるかもしれない点を見過ごしてこの一大リリースの成功を危険にさらしたくないと思うのがマネージャーという人種なのだ。
（中略）
しかし、仕事をすればするほど、新バージョンを見た顧客がどういう反応をするのか怖くなる。
計画が意欲的になるほど、対処しなければならないバグや矛盾、問題が増えていく。
すぐに、出荷などできない状態に我々は陥った。
製品発表の予定はどこか遠くに行ってしまう。
仕事をすればするほど、やらなければならないことが増える。
出荷不能に陥った我々は危機的状況となり、経営陣は交代となった。
これがバッチサイズ巨大化の罠である。
ここで語られている「致命的な欠陥になるかもしれない点」とは、「そもそも解決課題は存在しているのか？」「課題の解決の方向性はあっているのか？」、もっと端的にいうと「そもそもユーザーに使ってもらえるのか？」という点です。
恥ずかしいうちにリリースすることの利点は、この「致命的な欠陥」をいち早く見つけ出せる点にあります。
私たち人間は、簡単に自分の思い込みを真実にします。
たとえばプロダクトの作り込むうちに、ある機能を「自動化」したいと考えたとしましょう。
そう考えるときのあなたは、その機能が「ユーザーに使われまくること」を暗黙の前提にしています。
しかし、その前提は本当に正しいのでしょうか？
私の経験上、「これはイケる！」と思った機能でも、予想通りには使われないことがほとんどです。
そうなると、「自動化」やそれに伴う「バグの解決」などに使った時間と労力は無駄になります。
それだけならまだ良いですが、その追加機能に投じた労力が多すぎて「サンクコスト効果」からその機能を削除できないなどの状況に陥れば、世の中に蔓延る「無駄な機能で複雑になったプロダクト」にすらなってしまいます。
これはユーザーにとっての不便を生むだけでなく、開発者にとっても不便になります。
機能が多くなればなるほど、プロダクトが複雑になればなるほど、開発者のメンテナンスは大変になるのですから。
こうした悲劇を防ぎ、「そもそも使われるのか」という前提を先に検証するためにも、恥ずかしいうちにリリースすることが重要なのです。
もちろん、恥ずかしいうちにリリースすることにもデメリットはあります。実際私も、その拙さによってTwitterでユーザーからご批判をいただいたことはありますし、AppStoreやPlayStoreで「機能が少なすぎる」と低評価をいただいたこともあります。
それでも、そうしたユーザーの反応自体が、「実際に使ってもらえた点」や「どの機能が足りないか」を明らかにしてくれるために有益なのです。
反応があること自体、何かしら「ユーザーの感情が動いた証拠」でもあります。
心の底からどうでもいいものに、人は意見をしません。
リリースすることによって、わざわざお問合せから「こういう機能が欲しい」と要望をくださるユーザーが現れることさえあります。
リリース時、批判を受けるよりもはるかによく起こりうる結果は、誰も使ってくれないがために、批判も受けず、低評価どころか評価自体されないことです。
というより、そうなることがほとんどなのです。
その場合には、あなたが暗黙に前提と考えていた大元の仮説「こういう課題が存在している」「この課題はこの方法で解決できる」が間違っている可能性があります。
そしてそれを早い段階で学べることは、あなたが本来であれば投じていたであろう時間と労力を大幅に省くことができたという点で、大きな収穫なのです。
また「使ってもらえない」という辛い経験は、そこで諦めさえしなければ、「深いユーザー理解」につながり、改善や次のサービス開発につながります。
これに関しては、「本の問題集投稿サービス」と「問題集投稿サービス」で過疎と無反応を経験した後、やっと「英単語学習サービス」でユーザーを獲得した私の経験からも自信を持って断言できます。
「恥ずかしいうちにリリースする」は、「言うは易し、行うは難し」の典型です。
とくに技術者にとっては、一番超えるのが難しい壁かもしれません。
技術者は、その職業的特性上、「完璧主義」に囚われやすい傾向があるからです。
かくいう私もいつも、抵抗感を感じながら、リリースしています。
それでも私がリリースできているのは、過去のある手痛い失敗を思い出すからです。
私は作家志望時代、ある作品のリリースに「7年」をかけて、失敗しました。
7年はとんでもない期間です。
なぜここまでリリースするのに時間がかかったかといえば、まさに先ほど引用した「巨大バッチ死のスパイラル」のためでした。
まさに引用文の中にあるようなことが、そのまま私に降りかかったのです。
この経験は私の中にトラウマの如く刻み込まれているので、それ以降、私は「恥ずかしいうちにリリースする」ように心がけています。
今振り返ると、DiQtの最初のバージョンはまったく拙く、ひどいものでした。
しかし、それは正しい選択だったのです。
なぜなら、私は作家にはなれませんでしたが、今はこうして個人開発者として生活できているのですから。
私が作家になれなかったのは「恥ずかしいうちにリリース」できなかったからで、私が個人開発者になれたのは「恥ずかしいうちにリリース」できたからなのです。
「創作活動」に携わる以上、「一発でホームランを狙う」なんて甘い考えは捨てましょう。
「努力はギャンブル」という記事にも書きましたが、モーツァルトとベートベンでさえ、他の音楽家に比べるとヒット率は低いのです。
彼らは多作であることによって、つまり『試行回数』の多さによって、大成功を収めたのです。
これはピカソも葛飾北斎も一緒です。
イチローでさえ、「3割打者」なのです。
Appleの創業者スティーブ・ジョブスは、Macのリリースが遅れたとき、「偉大な芸術家は出荷する」と説いて開発チームを鼓舞しました。
出荷しましょう。今すぐに。
私の青春7年の犠牲を、どうか無駄にしないでください。
リリースしたサービスを自分で使い続ける。
モチベーションを保つ上で、「自分が使いたいもの」を作ることを勧めましたが、リリースした後は、実際にそのプロダクトを「自分で使い続ける」ことが重要です。
もし「自分が使いたいもの」を作ったはずなのに、「開発者の自分さえ使わない」のであれば、確実に何かが間違っています。
使い勝手が悪いのかも知れませんし、課題の解決方法が間違っているのかも知れません。
そうした「なんとなく使えない」「何か不便を感じる」「コレジャナイ感」という自分の肌感覚と向き合って改善を続けることは、モチベーションを保つうえでも、成功確率を上げるうえでも重要です。
まず、「混沌とした赤の他人の不便」を解決するより、「自分の不便」を解決するほうがモチベーションを保ちやすいです。
「不便の解決」が、「自分の生活の向上」につながるからです。
そしてあなたが肌で感じる不便は、文字通り、あなたが一番理解できるので、他人の不便よりもずっと解決がしやすいです。
さらに、あなたは世界で唯一無二の存在というわけでもないので、あなたと同じ不便を抱えている人は、必ず地球上に存在します。
もしその不便をきちんと解決することができれば、彼ら彼女らが、あなたのサービスの次のユーザーになってくれるのです。
プロダクトを開発者自身が使いまくって検証することを、業界用語で「ドッグフーディング」と呼びます。
この「ドッグフーディング」の重要性を、私は手痛い失敗から学びました。
かつてDiQtがBooQsという名前で「本の問題集投稿サービス」だったり「問題集投稿サービス」だったりした頃、ほとんどユーザーからアクセスがありませんでした。
そのときもユーザーを集めるために色々と試行錯誤はしたのですが、あるとき、私はあることに気づきました。
私が「使いたい」から開発したプロダクトだったはずなのに、開発者である私自身すら使わなくなっていたのです。
「問題を作成するのが、想像していたよりもずっと大変で面倒」というのが、その理由でした。
プロダクトのすべての機能を熟知していて、かつ、いつでも改善できる立場の開発者が使わないのならば、赤の他人が使ってくれるはずがありません。
私は、一旦すべてを忘れて、「自分が毎日使える状態」を最優先目標にプロダクトを改善することにしました。
そして、毎日使い続けたのです。
その結果、こちらの記事にも書いたように、問題投稿機能を含む多くの機能が削除され、ジャンルも英語のみに狭まりました。
しかし、目標である「自分が毎日使える状態」に達した頃には、自然とユーザーも増え、定着し始めていたのです。
開発者のあなたが毎日使い続けられるクオリティならば、他の人も使い続けてくれるのです。
「ドッグフーディング」の重要性について考えるとき、私がいつも思い出すのが、任天堂の「スーパーマリオブラザーズ」とその開発者である「宮本茂」です。
スーパーマリオは、ゲームデザインのプロから史上最高のゲームに選ばれることも多く、そして実際に、マリオは史上第2位の売り上げを誇るゲームなのです。
では宮本茂は、そんなマリオをどうやって開発したのでしょうか？
彼の開発哲学に迫ってみましょう。
だが、宮本茂がスーパーマリオブラザーズをデザインしたときの第一の目的は、自分自身が楽しんで遊べるゲームにすることだった。
彼はフォーカスグループ調査をするかわりに、任天堂が最初のバージョンを発売した1983年の時点で自分で何時間もぶっとおしでプレイして、バグの発見や解消に努めた。
1990年代と2000年代前半には、大ヒットゲーム「ポケモン」シリーズのデザインに携わったが、このときもゲームとしての完成度を最優先にした。
「それが大事なんです」と宮本は語っている。
「売れるもの、人気になるものを作ろうとするのではなく、好きになるために作るんです。クリエイターである我々自身が愛せるものを作るんです。それがゲーム作りの根幹であるべきだと思っています。」
史上最も売られたゲームの一つが、「売ろうと思って作られたのではない」というのは、なかなか皮肉な話です。
しかし、結局のところ、これが本質なのではないでしょうか？
誰かにプロダクトを愛して欲しかったら、まずは開発者自身が、ユーザーの一人としてそのプロダクトを愛するべきなのです。
まだ愛せないのであれば、愛せるようになるまで、使い続け、改善し続けるべきなのです。
そうすれば、いつかユーザーは集まってくるものですし、モチベーションだって保てるものだと思います。
プライドを捨てて、リリースしよう。
『自分が使いたいものを、恥ずかしいうちにリリースして、自分で使い続ける』。
この指針が、私の独自例だと思われないように、私よりもはるかに成功した個人開発者の友人をご紹介しましょう。
彼が今は有名なあるプロダクトの最初のリリースを行なったとき、私はそれを使う機会があったのですが、正直言って、洗練されたサービスとは言えませんでした。
デザインも洗練されておらず、機能も少なく、さらにそのプロダクトの中でもっとも重要であろう機能を、ユーザーが契約したあとに彼が『手動』で行っていたのです。
しかし、結果は雄弁です。
その後も彼自身がそのサービスを日々使い込みながら改善を続けた結果、次第に多くのユーザーを惹きつけ始め、売り上げもどんどん増えていきました。
そして1年後、そのプロダクトを有名企業に売却しました。
彼とは、ペライチ社にWraptasを売却したnabettuさんです。
nabettuさんは（少なくとも私よりははるかに）優れたエンジニアであり、やろうと思えばリリース前に「自動化」もできましたし、実際にしばらく経ったら自動化していました。
私が驚いたのは、そんな有能なエンジニアが、プライドを捨てて「恥ずかしいうちにリリース」できたところです。
そして、ほとんどユーザーがいない時から、自分一人でも使い込み改善を続けてきたことです。
こうした成功例は、きっと多くの個人開発者に勇気とモチベーションを与えてくれるでしょう。
たいてい挫折してしまうケースというのは、周りの目が怖くなってリリースできなくなってしまうか、リリースできても自分で使い続けられないことがほとんどなのですから。
「自分が使いたいものを、恥ずかしいうちにリリースして、自分で使い続ける」。
この指針に従って、そして諦めなければ、いつかその個人開発は報われるものだと思います。
良い個人開発は、開発者の生活を改善する
私が開発している辞書＆単語帳アプリ「DiQt」は、BooQsという名前だった頃から「本の問題集サービス」や「問題集投稿サービス」とさまざまな変化を経ていますが、DiQtが今の姿になったのは、「自分が毎日使うプロダクト」を目指したことがきっかけでした。
「自分が毎日使うプロダクト」を目指す何よりの利点は、プロダクトの改善が、自分の日々の生活の質の向上につながることです。
「毎日使うプロダクト」にすると決意し、私がDiQtを使って解決を目指したのは、「英語が読めない」という自分の課題でした。
エンジニアは、英語を読む機会がとくに多い職業ですが、当時の私は英語がほとんど読めず、英語の記事を読むときはいつもGoogle翻訳を使っていたのです。
しかし、DiQtの開発を続け、そして使い続けるうちに、あるときGoogle翻訳を使わなくなった自分に気づきました。
いつの間にか、英語が読めるようになっていたのです。
私はDiQt以外には語学系アプリを使っていなかったので、これはDiQtのおかげです。
「自分が使いたいものを作る」個人開発は、開発者自身が「使い続ける」ことによって、開発者自身の課題を解決し、開発者自身の生活の質を上げてくれるのです。
さらに、この課題の解決は、開発者の生活を助けるだけにとどまりません。
開発者と似た人々の生活も助けるのです。
このことを実感したのは、DiQtのGoogle Chrome拡張機能をリリースしたときでした。
リリース翌日に、クラスメソッド社のエンジニアさんにこんな素敵な紹介記事を書いていただいたのです。
英語で書かれたドキュメント、GitHub や Stack Overflow 内でのやりとり、海外の方のツイートなど日常生活には英語に接する機会がたくさんありますよね。
ただ情報を入手するだけならサクッと機械翻訳をかましてしまえばいいのですが、英語学習のためと思って英語で読むこともあるでしょう。そのような時に意味が分からない英単語に出会い、意味を調べても翌日には忘れてるといったことありませんか？ 私はあります。
そのような方におすすめしたいのが Chrome 拡張機能の「BooQs Dictionary」です。
これはまさに、私が日々でDiQtを使う状況であり、そして私がDiQtを使って解決したい自分の課題の説明そのものでした！！
私以外にも、英語が読めないけれど、読めるようになりたいエンジニアはいたのです！
私は自分の課題を解決していたつもりでしたが、同時に、他の人の課題も解決していたのです。
私と似た人々の生活も助けていたのです。
私は、これこそ個人開発の醍醐味ではないかと思います。
個人開発は自由です。
会社みたいに市場規模だとか採算性だとか小難しいことを考えずに、あなたの個人的な課題を解決するために作ってもいいのです。
そうすれば、あなただけでなく、あなたに似た人たちも大勢助けられるのです。
個人開発で、世の中がもっと良くなり、便利になるのです。
こんなに素晴らしいことがあるでしょうか？
現代は個人開発者にとっては素晴らしい時代です。
技術もある、インフラもある、APIもある、連携サービスもある、教材もある、必要ならばコミュニティだってあります（私もnabettuさんもこの「運営社ギルド」に所属しています）。
あとはあなたの「やる気」だけです。
やりましょう！！
そして私と同じような「英語が読めるようになりたい！」と思っている英語学習者はぜひDiQtを使いましょう！！（宣伝）
Web版：
iOS版：
Android版：
Google Chrome拡張版：
あなたの貴重なお時間をいただき、ありがとうございました！