- Mac向けWeb動画ダウンローダー Downie やメディアフォーマット変換ツール Permute など、さまざまなアプリを作った個人開発者 Carlie Monroe による助言
すべてが即座に成功するわけではない
- 一夜にして成功した事例は多いが、これはごく例外的なケースであり、ほとんどのビジネスには時間が必要
- 限られた予算では、数週間や数か月でヒット作を作るのは現実的に難しい
- 初期資本なしで会社を始めた者として、現実的な助言をしたい
- 小さな失敗に備えること
- 最初に公開したアプリは、ダウンロード数がほとんどなく、ユーザーもおらず、収益もなかった
- こうした失敗を予想し、落胆しないことが重要
- 最初から完璧な製品を作ろうとして1年を費やすのではなく、核となるアイデアを素早く開発し、フィードバックを受けて改善していく方が効果的
- アプリの完成度を保つこと
- アプリの核となるアイデアを開発し、フィードバックとロードマップに基づいて発展させるべき
- 開発を単純化しすぎず、少なくとも安定して動作しなければならない
- アプリがクラッシュしたり、バグが多かったり、未完成に見えたりすると、ユーザーの信頼を得るのは難しい
- 一部の機能が不足していることはあり得るが、継続的なアップデートで改善していくことが重要
- 着実な改善が行われれば、ユーザーはそれを前向きに評価し、アプリを勧めるようになる
- 改善を続けつつ、やめ時を知ることも重要
- アプリを公開し、何度かアップデートし、広告や宣伝も試したのにダウンロード数が200人程度なら、アイデアを見直す必要があるかもしれない
- ユーザーがそのアプリを有用だと感じていないなら、新しいアイデアを検討した方がよい場合もある
- 落胆せず、より良いアイデアで再挑戦する準備をしておくこと
就職しないこと
- 会社勤めをしながらインディー開発を並行するのは非常に難しい
- 私の場合、ケンブリッジ大学で夏の間インターンとして働いていたが、1日8時間働いた後、寮に戻って自分のアプリ作業をさらに3〜4時間していた
- 夏の終わりごろには、ストレスを抱え、体重も増え、コンピューターの前で働くこと以外に何もする時間がなかった
- このペースを長く維持することはできない
- 数か月なら試せるかもしれないが、それだけではアプリを開発し、ユーザーベースを確保するには不十分
- 結局のところ、就職するとビジネスの道がそこで終わる可能性が高い
- ただし、フリーランスの仕事やソフトウェア受託を引き受けるのは構わない
- 1日中アプリ開発だけをするのは、むしろ非効率なこともあり、別のプロジェクトで気分転換するのが役立つこともある
- ただし、外部プロジェクトが本業にならないよう注意し、1日4時間程度に抑えて自分のプロジェクトに集中する時間を確保することが重要
- 序盤は資金が不足することもあるため、フリーランスの仕事で最低限の生活費を確保する必要がある
- ただし、会社勤めをするのではなく、自分のプロジェクトを中心に据えて働けるようバランスを取ることが重要
一人でも、誰かとでもやらないこと
- これは本当に難しい決断
- 私は一人で会社を運営してきた
- 一人で会社を運営すれば、あらゆる決定を自分で下せるし、コードスタイル、機能、UI などをめぐる意見の衝突もない
- しかし、成功は数週間や数か月の話ではなく、他の人が同じような犠牲を払えるかはわからない
- 数か月後に共同創業者が辞めて就職するかもしれず、それぞれの生活状況が異なる以上、方向性が変わる可能性もある
- しかし、完全に一人でやるのも避けるべき
- すべてを一人で処理しなければならないため、年中無休で働くことになる
- 休日や休暇中でもサポートメールを確認し、返信しなければならない
- 1日に平均100件ほどのユーザー問い合わせがあり、その多くは技術的な内容を含むため、単純に他人へ委任しにくい
- 長期休暇を取ると、復帰後にさばききれないほど仕事がたまり、ユーザーは数時間以内の返信を望む
- カスタマーサポート業務は1日2〜3時間ほどかかり、専任スタッフを置くには少なすぎるが、一人で担うには負担が大きい
- もし共同創業者がいれば、内部構造をよく理解しているため、代わりに対応できる可能性が高い
- 誰かと一緒に始めれば、その人が自分の代わりに業務を処理できるため、すべてを一人で抱え込まずに済む
- 矛盾した助言だが、現実的な検討が必要
- 一人なら自由だが負担が大きく、一緒なら責任を分担できるがリスクもある
- 長期的な視点で、自分に合った方向を慎重に決めることが重要
ユーザーフィードバックを大切にすること
- ユーザーが簡単に連絡できるようにするべき
- エラーダイアログ、メイン画面など、アプリ内の複数箇所にサポートボタンを配置するとよい
- メールクライアントを開く方式はユーザー体験を妨げることがある
- 代わりに、アプリ内でサポートフォームを提供すれば、アップデート確認、バージョン情報の付加、追加の詳細情報の依頼などが可能になる
- 継続的に問い合わせや報告が届くことはあるが、それはユーザーがアプリに関心を持っているという前向きなサインでもある
- ユーザーの声に耳を傾けること
- 初期はユーザーが少ないため、できるだけ満足度を高めることが重要。満足したユーザーはアプリを勧めてくれる
- 迅速な返答、要望された機能の実装などを通じて、ユーザーとの信頼を築ける
- ユーザーのフィードバックを反映していくうちに、想定と違う方向へアプリが発展することもあるが、ユーザーベースが大きくなった後で再調整する機会はある
- 要望は選別して取り入れること
- ユーザーの要望がアプリ全体の方向性と合っているかを判断する必要がある
- 単なる問題解決ではなく、長期的に有用な機能かどうかを考えるべき
- 要望の理由と、それがユーザーのワークフローでどう機能するのかを把握した上で、より良いアプローチがあるなら説明することが重要
- 機能不足で1人のユーザーを失うことより、複雑になりすぎて何百人ものユーザーを失う方が大きな問題
突然の終了に備えること
- どんなビジネスもいつかは終わる。大企業でない限り、引退したり、これ以上運営できなくなったりすれば、事業は消えるほかない
- これは自然なことなので、いつか会社を閉じることになるかもしれない点を念頭に置くことが重要
- 技術業界は変化が速く、今人気のアプリも、時間がたてば役に立たなくなることがある
- 2000年代初頭にインターネットバブルが崩壊した際、多くの事業が急激に縮小した例がある
- 事例 1: CandyBar
- 15〜20年前、システムアイコンや Dock をカスタマイズできる人気アプリだった
- しかし macOS が Dock のレンダリング方式を変更し、システム保護機能（SIP）が追加されたことで、もはや使えなくなった
- 事例 2: Skype
- 15年前には不可欠なコミュニケーションツールだったが、今では iMessage、FaceTime、WhatsApp、Zoom、Google Meet などに置き換えられている
- 市場の変化によって、徐々にユーザーの記憶から薄れていった
- 事例 3: Twitterrific & Apollo
- Twitter（X）と Reddit が API ポリシーを突然変更したことで、既存のサードパーティ製アプリは動作できなくなった
- 開発者たちは何の準備もないままアプリを終了せざるを得ず、ユーザーがそれを開発者の責任だと誤解することもあった
- 対応戦略
- 1つのアプリだけに依存せず、2〜4本の安定したアプリを運営するのが望ましい
- 主力アプリのほかにも、予備の収益源となるアプリを確保して不測の事態に備えること
- 完全な出口戦略を立てるのも一案。たとえば、新しい分野へ転換する計画を前もって立てておくことが重要
まとめ
- 上の内容を絶対的な法則だと思わないこと
- これは20年以上の経験から出たものだが、あらゆる経験は主観的なもの
- 時代は変わり、個人の状況も異なるため、同じやり方が常に通用するわけではない
- それでも、このすべてに価値はあるのかと問われれば？
- 個人的には価値があった
- 困難な時期を経て事業を成長させ、それによって生計を立てられるようになった
- ただし、すべての人に向いた道ではない
- 自分でモチベーションを保てなければ簡単に諦めてしまうし、上司のいない環境で自律的に働くことが重要
- 現実を考慮すること
- これはインディー開発を始めようとする人を怖がらせるための話ではない
- むしろ、あまりに早く諦めてしまうことこそ最大のリスクだと何度も述べてきた
- ビジネスを始め、アプリを作ることは素晴らしい挑戦だが、現実的な期待を持つことが重要
- 数か月で終わる話ではなく、数年、あるいは数十年にわたって続く可能性のあるプロセスだ
まだコメントはありません。