目次
個人開発を始めた頃の私は、技術選定が好きでした。
好きというより、こだわりすぎていたと言った方が正しいかもしれません。
サービスのアイデアを思いついても、まず比較表を作る。新しいフレームワークが出たら調べる。SNSで話題になっている技術を見ると「こっちの方が正解なんじゃないか」と気になる。
気づけばコードを書く時間より、技術選定について考える時間の方が長くなっていました。
今振り返ると、あれは「失敗したくない」という気持ちの裏返しだった気がします。
でも実際にいくつかのサービスをリリースして運用してみると、当時気にしていたことの多くはそれほど重要ではありませんでした。
この記事では、個人開発を続ける中で捨てた5つのこだわりについて書きます。
新しい技術を見ると触りたくなります。
特に個人開発だと誰に許可を取る必要もないので、「せっかくだから使ってみよう」となりがちです。
私も何度もやりました。
サービスを作るつもりだったのに、途中から技術検証が目的になっていたこともあります。
もちろん新しい技術を学ぶこと自体は悪くありません。
ただ、学習と開発を同時にやると予想以上に進みません。
ドキュメントを読む。
サンプルコードを探す。
エラーの原因を調べる。
こうした時間が積み重なると、思った以上にリリースが遠のきます。
個人開発で一番もったいないのは、作り切れないことです。
どれだけモダンな技術を使っていても、公開されなければ何も分かりません。
ユーザーが使うかどうか。
課金してくれるかどうか。
そもそも需要があるのか。
こういうことはリリースしない限り確認できません。
最近は「一番良い技術」より「一番早く作れる技術」を選ぶことが増えました。
以前の私は、まだユーザーがいない段階からスケールを心配していました。
APIを分離した方がいい。
認証サービスは独立させるべき。
将来の負荷を考えるとDBも分けたい。
そんなことを考えていました。
今思うと、かなり気が早かったです。
実際に困るのはアクセス集中ではありません。
アクセスが来ないことです。
個人開発で最初にぶつかる壁は、ほぼ確実にそちらです。
それなのに複雑な構成にすると、開発速度だけが落ちます。
モノリスは地味ですが強いです。
設定が少ない。
デプロイが楽。
障害調査も簡単。
夜中にサービスが落ちたとき、確認する場所が1つで済むのはかなりありがたいです。
スケールの心配は、実際にスケールしてから考えれば十分だと思うようになりました。
昔は設計図を作り込むのが好きでした。
将来追加するかもしれない機能まで考えてテーブル設計を作る。
拡張性を考えて抽象化する。
でも、その未来はだいたい来ません。
実際にユーザーが使い始めると、想定と違う使われ方をされます。
追加されると思っていた機能は不要だったり、逆に全く考えていなかった機能が求められたりします。
つまり最初から正解を当てるのは無理です。
最近は設計を軽視しているわけではありません。
ただ、未来のための設計より、今必要な設計を優先しています。
コードが汚くなったら直せばいい。
ユーザーが増えてから考えればいい。
そう割り切ると、かなり開発しやすくなりました。
以前は無料で運用することに妙な達成感がありました。
無料枠を組み合わせて何とか動かす。
でも実際は、そのために何時間も使っていました。
月500円や1,000円払うだけで解決することは意外と多いです。
データベース管理。
ログ収集。
監視。
こういう部分をサービスに任せるだけでかなり楽になります。
個人開発を続けていると、お金より時間の方が不足します。
平日の夜や休日しか開発できない人も多いはずです。
だから今は「時間を節約できるなら払う」という判断をするようになりました。
無料にこだわることは減りました。
エンジニアは綺麗なコードが好きです。
私も好きです。
リファクタリングしてコードがすっきりすると気分が良い。
ただ、それだけでユーザーが増えることはありません。
ユーザーは内部実装を見ません。
見ているのは、
問題が解決できるか
動作が安定しているか
使いやすいか
そのくらいです。
バックエンドが何で動いているかを気にする人はほとんどいません。
個人開発をしていて感じるのは、80点のサービスを公開する方が、100点を目指して止まるより価値があるということです。
公開して初めて学べることがあります。
机の上では分からないことばかりです。
今は技術選定で迷ったら、次の5つを見ています。
使い慣れた技術は想像以上に強いです。
開発速度だけでなく、問題解決の速度も違います。
開発だけではなく、保守や障害対応まで含めて考えます。
未来の自分もチームメンバーです。
しかも結構厳しい。
情報が少ない技術は、ハマったときが大変です。
検索して答えが見つかるかどうかはかなり重要です。
正解を当てることより、外したときに修正しやすいことを重視しています。
最終的にはこれです。
その技術選定によってリリースが1か月遅れるなら、本当に必要なのかを考えます。
技術選定について考えるのは楽しいです。
新しい技術を調べるのも好きです。
ただ、個人開発を続けて感じるのは、技術選定そのものが成果ではないということです。
ユーザーは「どの技術を選んだか」ではなく、「そのサービスが役に立つか」を見ています。
だから今は、完璧な技術スタックを探すより先に作り始めるようにしています。
振り返ると、失敗した技術選定は何度もありました。でも、それで致命傷になったことはほとんどありません。
一方で、考えすぎて作らなかったアイデアはたくさんあります。
個人開発では、そちらの方がずっと大きな損失でした。
コメントはまだありません