【翻訳】ソロでのプロダクト開発を成功させるには？（Smashing Magazine, Victor Ayomipo）
ソロ開発の良いところでもあり悪いところでもあるのが、「ソロ」という部分です。一人で仕事をすることには自由があり、その自由は刺激的でもありますが、生産性や進歩の妨げになることもあります。Victor Ayomipoは、ソロ開発をナビゲートし、「正しい」アプリを構築するために必要なことについての個人的な教訓を共有しています。
ソロで何かを作ろうとしたことのある人なら誰もが予想するように、私の目標はアプリを作ることではなく、アプリを作ることでした。ワイヤーフレーム、ToDoリスト、プロジェクト構造など、何でも用意しました。そして作り始めました。製品ではありません。ランディングページを作るところから始めて、4日間もかかってしまいました。アイデア自体はとても良かったので、すぐにマーケティングを始める必要がありました！
色、影、グラデーション、フォントサイズ、余白、パディングなど、細部まで完璧にする必要がありました。ロゴの制作にどれだけ時間がかかったかは言うまでもありません。
ネタバレ： 誰もあなたのロゴなんて気にしていません。
なぜ、あんなに作りたかったコアアプリの一部でもないものに、こんなにこだわってしまったのでしょう？なぜ私は、明らかに前に進む必要があるのに、自分自身に口うるさく言わなかったのでしょうか？
一人での開発の現実は、いつやめるべきかを教えてくれる人がいないことです「⚠️次に進みなさい」。ほとんどのユーザーは、ログインボタンが黄色か緑色かなんて気にしていません。彼らが欲しい（必要としている）のは、クリックしたときに機能し、問題を解決してくれるボタンなのです。
早期かつ頻繁なテスト
不必要な調整、優柔不断なUIの決定、完璧主義は、私が必要以上に物事に時間を費やす理由の核心です。
他のソロ開発者と同じように、私も大規模なチームのような効率でビルドをプッシュすることを望んで始めました。しかし、言うは易く行うは難しです。
ソロでビルドする場合、コーディングを始め、設計上の欠陥に気づき、それを修正することに切り替え、バグが現れ、それを修正しようとし、その日は終わりました。そうしているうちに、「そうだ。今こそ雑に作る時だ」と。それは、プロジェクトやプロダクトマネジメントの善意が窓の外に出てしまうときであり、ストーリーボード、ユーザーペルソナ、基本的な優先順位付けのような、優れたUI/UXの原則に基づいた、定義されたゴールと実行可能なタスクで突き進むのではなく、思いつきで仕事をしている自分に気づくときなのです。
このことを完全に理解するには、経験しなければなりません。私が学んだコツは、人々に見てもらうために何かを世に出すことに集中し、それから実際のフィードバックに取り組むことです。言い換えれば、最初から完璧を求めるよりも、アイデアを世に出し、それを反復することの方が重要だということです。
だってそうでしょう？世界で最も素晴らしいアプリのアイデアがあったとしても、それに対するフィードバックを受け始めるまでは、それを完璧なものにすることはできません。あなたは読心術の達人ではありません-私たちは皆、読心術の達人になりたいと思っていますが-そして、いくつかの洞察（多くの場合、最も適切な洞察）は、実際のユーザーからのフィードバックや分析を通じてのみ得ることができます。確かに、あなたの初期の仮定は正しいかもしれませんが、それを出荷して評価を始めるまでどうやって知ることができますか？
最近、私は他の人に（そして私自身にも）、絶対的なものではなく仮説に基づいて仕事をするように言っています。仮説を立て、それをどのようにテストするつもりかを説明し、そして出荷します。そうすることで、完璧に近づくために使える関連した洞察を集めることができます。
弱点を認識する強さ
現実を見ましょう：自分自身で完全なアプリケーションを構築するのは簡単なことではありません。一人で家を建てようとするようなものです。できそうに見えますが、現実には、それを実現するためには自分の手よりも多くの人の手が必要なのです。しかし、現実には、それを実現するためには、自分の手よりも多くの人の手が必要なのです。
一人でできることは限られており、前もって自分の長所と短所を認めておくことで、一人ですべてできるという罠を避けることができます。
私は以前、プロジェクト管理アプリを一人で作ろうとしたことがあります。難しいかもしれないとは思いましたが、自信がありました。数日のうちに、この 「シンプルな 」プロジェクトは足が伸び、チームコラボレーション、分析、時間追跡、カスタムレポートなどの新機能が追加され、拡張されました。
完全なアプリを作るには多くの時間がかかります。考えてみてください。あなたは、誰の助けも借りずに、たった一人でチームの仕事をしているのです。デザイン資産、コンテンツ、バックエンド開発を提供してくれる人はいません。あなたのアイデアに「すっ飛んできてウンコをする」利害関係者もいません（これはいいことかもしれませんが）。すべての決定、すべてのコード行、すべてのデザイン要素は、100％あなただけのものです。
フル機能のアプリを一人で作ることは技術的には可能ですが、考えてみれば、MVPという概念が存在するのには理由があります。Instagramを例にとると、リールやストーリー、クリエイターのインサイトなどを使ってスタートしたわけではありません。写真の共有というシンプルなものから始まったのです。
私が言いたいのは、小さく始めて、ローンチして、ユーザーに製品の進化を導いてもらうということです。そして、より多くの人の手を借りることができれば、なお良いでしょう。ただ、自分の強みを生かし、他の人の強みに寄りかかって弱みを補強することだけは忘れないでください。
MVPのように考える
最小実行可能製品（MVP）というコンセプトは、私にとって常に魅力的なものでした。最も単純な形では、技術的に機能するあなたのアイデアの基本バージョンを作り、ユーザーの前に出すことを意味します。そう、これはとてもわかりやすく、広く普及しているヒントですが、ソロの開発者にとって、特に私にとっては、いまだに最も難しい原則の1つです。
先ほど、私の「天才的な」アプリのアイデアは足が生えたと書きました。しかもたくさん。どうしたらいいのかわからないほどアイデアがあり、それなりの量のコードも書いていませんでした！確かに、このアプリはフェイスID、ダークモード、高度なセキュリティ、リアルタイムの結果、その他多くの機能をサポートするように拡張することができました。しかし、ユーザーが欲しがっているかどうかもわからないアプリのために、これらすべての開発に何ヶ月もかかるかもしれません。
私は自問自答することを学びました： 「もし簡単に作れたら、このプロジェクトはどうなるだろうか」と。その答えが、ほとんどいつもユーザーが求めているものと一致するのは、とてもシュールなことです。もし、あなたの壮大なアイデアを、1つか2つのことを非常にうまくこなす、欠かすことのできない1つのアイデアに絞り込むことができれば、最終的な結果が、本当のユーザーの問題を解決することにレーザーフォーカスしたものであることがわかると思います。
最もシンプルなバージョンを最初に出荷してください。ダークモードは後回し。必要なのは、明確に定義されたアイデア、検証すべき仮説、そしてその仮説を検証するための機能的なプロトタイプだけです。
不完全さを潔く扱う
あなたは開発に対する 「Ship it Fast 」アプローチについて聞いたことがあるかもしれません。ある意味、「Ship it Fast 」は究極的にはMVPを表現する別の方法です。
開発者として、私たちは自分の仕事の質に深くこだわるので、それは理解できます。しかし、ship-fastの考え方は、品質を無視することではなく、早急に何かを送り出し、実際のユーザー体験から学ぶことです。今すぐ出荷して、後で完成させましょう。
だからこそ、私は他の開発者に、MVPを出荷することが最も安全でプロフェッショナルな開発アプローチ方法だと言いたいのです。気まぐれに屈することなく、スコープとタスクを守ることを強いられます。私は、すべてのプロジェクトの開始時に「集中の誓い」を誓うようにしています。
私Vayoは、このアプリがMVPの栄光を手にするまで、一切の変更、追加、追加機能を行わないことを（この設計図に片手を添えて）ここに厳粛に誓います。私は、際限のない微調整の誘惑や、「あと1つの機能だけ 」という考えを避けることを誓います。
プロトタイプが完成して初めて、新しい機能、拡張、調整を検討します。
署名、Vayo、MVPの番人
覚えておいてほしいのは、自分ひとりで開発するとき、責任を取ってくれる人は誰もいないということです。最初のバージョンは完璧なものではないことを受け入れ、少し立ち止まることで、プロジェクトの初期段階で適切な思考をすることができます。
重要なことに優先順位をつける
どんなものを作っても、必ずバグがあることに気づきました。常にです。もしGoogleがGoogle Notesアプリにまだバグがあるのなら、どんなプロジェクトにもバグはつきものだということを受け入れるのは、一人の開発者としては問題ありません。
欠陥のあるテストを見てください。例えば、あるテストを1,000回以上実行し、すべて緑になったとしても、次の日に同じテストを実行するとエラーが表示されます。それがソフトウェア開発の本質なのです。また、無限に機能を追加していく場合も、終わりがありません。あなたが興奮するような新機能は常にあります。課題は、その熱狂をある程度抑えて、後でそれに取り組む意味があるときまで責任を持って棚上げしておくことです。
私は、バグや機能を「侵入型」と「非侵入型」の2種類に分類することを学びました。侵入型とは、クラッシュや重大なエラーのように、修正されるまでプロジェクトが正常に機能しなくなるものです。非侵入的なものは、静かなものです。もちろん、それらは修正されるべきですが、すぐに対処されなくても製品は問題なく動作しますし、ユーザーが価値を得るのを妨げることもありません。
バグや機能を他の方法で分類したいと思うかもしれません：
- 価値の高いもの、低いもの；
- 高労力、低労力；
- 高コスト、低コスト；
- 必要なもの、あると便利なもの。
開発者やチームがこのような分類を使って、それぞれのカテゴリーを考慮した優先順位の「スコア」を作っているのを見たこともあります。どのようなカテゴリーを使うかよりも、集中力を維持し、タスクを遂行するのに役立つものであれば、それがあなたにとって正しいアプローチになるはずです。
技術スタックとともに生きる
開発サークルの古典的な難問があります：
Reactを使うべきか？それともNextJS？それともVue？もっと最適化されるらしいし。でもちょっと待って、React Reduxはもうダメで、Zustandが新しいホットなツールだって。
そうやって、あなたは丸一日かけて、構築するために使っている技術スタックについてしか考えなくなってしまったのです。
私たちは皆、平均的なユーザーがボンネットの下の技術スタックについてあまり関心がないことを知っています。あなたのお母さんにWhatsAppがどんな技術スタックで作られているか聞いてみてください。ほとんどの場合、技術スタックにこだわるのは私たちだけで、それは通常、ボンネットの下をチェックするように頼まれたときにだけ起こります。
私は、50％のパフォーマンスと10％のコード削減を約束する新しい技術スタックが毎日リリースされることを受け入れるようになりました。その新しいツールはスケーリングが向上するかもしれませんが、私の現在のゼロユーザー数で実際にスケーリングの問題があるのでしょうか？おそらくありません。
私のアドバイス： 自分が一番使いやすいツールを選び、そのツールが自分に不利に働き始めるまで使い続けることです。
すでに知っていて使っているツールで仕事ができるのであれば、早い段階で何かと戦う必要はありません。基本的に、時期尚早に最適化したり、常に最新の光り物を追いかけたりしてはいけません。
最初のコード行の前にデザインを
多くのソロ開発者がデザインを苦手としていることは知っています。私のデザインプロセスは、伝統的にVS Codeを開き、新しいプロジェクトを作成し、思いつくままにアイデアを作り始めるというものでした。デザインアセットもカンプもワイヤーフレームもなく、ただ純粋に、構造化されていない即興で。これは良いアイデアではありませんし、私が積極的に断ち切ろうとしている習慣です。
最近では、コードを書き始める前に、自分が何を作ろうとしているのか、必ず青写真を描くようにしています。それができたら、自分の 「集中の誓い 」を尊重するために、何一つ変えないようにしています。
私は、多くのチームがカンプやワイヤーフレームを 「プロジェクトの成果物 」と呼ぶのが好きです。それらは、何かがどのように見え、どのように機能するかを示す、真実の証拠となるものです。あなたは要件セットで仕事をするタイプかもしれません。しかし、仕事で参照できる何らかのドキュメントを持つことは、長いドライブ旅行でターン・バイ・ターンのナビゲーションを持つようなものです。
もしあなたが私のように、自分が最高のデザイナーだと自負していないとしたら？その場合は、前もって自分の弱点を認め、そのような強みを持つ人の助けを借りることができます。そうすれば、目標を明確にし、自分の得意なことに集中することができます。
期限を決める
個人的には、締め切りがないと先延ばしが止まらなくなります。先延ばしを防ぎ、指定された時間に確実に何かを送り出すことができるので、私はどんなプロジェクトを作るときにも期限を設定するようになりました。説明責任がなければうまくいきませんが、この2つは相性がいいと感じています。
私は2～3週間の期限を決めてプロジェクトを立ち上げます。そして、どんなことがあっても、その期限が過ぎたらすぐに、今の状態の作品をソーシャルに投稿するか、共有しなければなりません。そのため、中途半端なプロジェクトは公開したくないので、自分のコンフォートゾーンにはもういません。自分の脳を騙すことができれば、どれくらいの時間でも行けるというのは面白いですね。
これは極端な制約であり、あなたには通用しないかもしれません。私は自分の境界線を知っておく必要があるタイプです。締め切りを設定し、それを尊重することで、私はより規律正しい開発者になれるのです。それ以上に、時間が決まっていることで考えすぎることがなくなり、より速いビルドにつながるので、効率的に仕事ができるようになりました。
結論
ソロ開発の長所と短所は、「ソロ」という部分です。一人で作業することには多くの自由があり、その自由はインスピレーションを与えてくれます。しかし、その自由さに酔いしれることもあり、放っておくと生産性や進歩の妨げになります。これが、一人での開発が誰にでも適しているわけではない理由です。チーム環境の方が良い反応を示す人もいるでしょう。
しかし、もしあなたがソロ開発者であるなら、私の個人的な経験があなたの役に立つことを願っています。私は「完璧な」アプリを一人で作れるような完璧な開発者ではないことを理解するために、何度も鏡の中の自分を見つめ直さなければなりませんでした。何かを作るには、計画、規律、そして謙虚さが必要です。
アイデアは安くて簡単ですが、自由から一歩踏み出し、完璧さよりも進歩に基づいて独自の制約を加えることが、私たちを動かし続け、本質的なことに時間を費やすための秘密のソースなのです。
