頑張って運用しない。個人開発で『運用しない設計』を作る
はじめに
「個人開発でつらいのは、実装より運用かもしれない」── そう思ったことはないでしょうか。
アプリを作ること自体は楽しいし、機能開発も進められる。
でも、リリースしたあとに待っているのは意外と地味な運用です。
- サービスが落ちていないか気にする
- 問い合わせフォームがちゃんと動くか確認する
- エラー通知を見る
- スパムを防ぐ
- インフラや認証の面倒を見る
1人でプロダクトを育てるとき、この「運用コスト」は無視できません。
しかも厄介なのは、運用が重くなるほど新しい開発の時間が減ることです。
だから個人開発では、運用を頑張る より先に、そもそも運用しない設計に寄せる 方が大事だと思っています。
本記事では、個人開発で僕が意識している「運用しない設計」の考え方を整理します。
運用しない設計とは何か
最初に誤解がないように書くと、「運用しない設計」は 何も見なくていい設計 ではありません。
そうではなく、
- 人手が必要な箇所を減らす
- 自分で面倒を見る範囲を狭くする
- 事故ったときの復旧コストを小さくする
- 日常的な確認作業を減らす
という設計です。
企業の SRE なら、運用を仕組み化してチームで回すことができます。
でも個人開発では、そもそもそのチームがいません。
なので「運用力を高める」より、運用対象そのものを減らす 方が効きます。
なぜ個人開発で重要なのか
個人開発では、運用コストはそのまま自分の時間コストになります。
たとえば、次のようなことは全部「小さな運用」です。
- サーバーを立てる
- 認証を持つ
- メール送信基盤を維持する
- エラー通知を見て一次対応する
- 問い合わせフォームの abuse を防ぐ
- 定期的に死活確認する
1つ1つは小さく見えても、積み上がるとかなり効いてきます。
そして厄介なのは、こういう運用タスクは価値の源泉ではないのに時間を食うことです。
だから、個人開発ではまずこう考えた方がいいと思っています。
これは本当に自分で持つ必要があるか？
何を managed service に逃がすか
僕は、価値の源泉ではない部分はできるだけ managed service に寄せます。
たとえば、こんな分担です。
| 領域 | 役割 | どこに逃がすか |
|---|---|---|
| フロント配信 | デプロイ、CDN、プレビュー | Vercel |
| DB / Auth | データ保存、認証、RLS | Supabase |
| メール送信 | 問い合わせ送信、通知メール | Resend |
| 障害検知 | 例外収集、通知、原因調査 | Sentry |
ここで大事なのは、便利だから使う ではなく、自分が運用したくない責務を外に出す という考え方です。
Vercel
フロントの配信・デプロイまわりを自前で持たないだけで、かなり楽になります。
たとえば Focusnest のような小さなプロダクトでも、デプロイのたびにサーバー設定や TLS を気にしたくありません。
Vercel に寄せると、その手の“配信インフラの面倒”をかなり減らせます。
- デプロイ基盤を自分で維持しない
- CDN や HTTPS を自分で面倒見ない
- プレビュー環境を自前で作らない
これだけで「インフラを触る時間」がかなり減ります。
Supabase
個人開発で Auth や DB を自前で持つのは、思った以上に重いです。
たとえば kaizen-lab のように、ユーザーごとのデータや認可があるプロダクトでは、認証・セッション・RLS を全部自作するのはかなり重いです。
Supabase を使うと、その重さをかなり外に出せます。
- 認証
- セッション管理
- データベース
- アクセス制御
このへんを全部自前でやると、すぐに本筋から逸れます。
Supabase はこのあたりをかなりまとめて肩代わりしてくれます。
Resend
問い合わせフォームや通知メールのためだけに、メール送信基盤を重く持ちたくないときにちょうどいいです。
実際、Focusnest のサポートページでは Resend を使っています。
問い合わせメールを確実に送りたい一方で、SMTP や本格的なメール基盤の運用までは持ちたくなかったので、かなり相性が良かったです。
「メールをちゃんと送る」という運用ポイントを、自分で抱え込まなくて済むのが大きい。
Sentry
障害検知も、自前でログをかき集めて眺めるより、最初から Sentry に寄せた方が圧倒的に早いです。
kaizen-lab でも、まずは「エラーが起きたことをちゃんと知れる状態」を作る方を優先しました。
いきなり完璧な運用を目指すより、検知の基盤を外に出す方が 1 人開発では圧倒的に効きます。
- エラーが起きたら通知される
- スタックトレースが残る
- 再現条件の把握がしやすい
少なくとも「何が起きたか分からない」状態を減らせます。
自前で持つべきものは何か
とはいえ、全部を external service に逃がせばいいわけではありません。
自前で持つべきものもあります。
僕が自前で持つべきだと思うのは、次のようなものです。
1. コアの業務ロジック
プロダクトの価値そのものです。
- どういう体験を作るか
- どんなワークフローで価値を出すか
- どこで差別化するか
ここは当然、自分で持つべきです。
2. 最低限の abuse 対策
managed service を使っても、入口の防御は自分で考える必要があります。
たとえば問い合わせフォームでも、最低限これくらいは要ります。
- バリデーション
- rate limit
- honeypot
- 不正入力の抑制
「外部サービス使ってるから安全」ではなく、入口設計は自分の責任 です。
3. 監視すべき重要導線の定義
Sentry があるから安心、ではありません。
本当に大事なのは、どこが壊れると困るのかを自分で決めていること です。
たとえば個人開発なら、まず見るべきなのはこういうところです。
- ログインできるか
- 課金できるか
- 問い合わせが送れるか
- コア機能が使えるか
全部を細かく見るのではなく、重要導線だけは落とさない 方が大事です。
ハマりポイント
1. managed service を使っても運用ゼロにはならない
ここは大事です。
Vercel も Supabase も Sentry も Resend も、使えば終わりではありません。
- env はちゃんと管理する必要がある
- 課金境界は把握しておく必要がある
- 失敗時の挙動は自分で決める必要がある
「運用しない設計」は、運用がゼロになる魔法ではなく、自分で持つべき運用を減らす設計 です。
2. 小さい機能でも運用対象になる
たとえば問い合わせフォームは小さい機能に見えます。
でも実際には、
- スパムが来る
- 送信失敗が起きる
- abuse される
- 通知先が壊れる
など、普通に運用対象です。
実際、Focusnest の問い合わせフォームでも、メール送信だけでなく rate limit や honeypot を入れています。
「小さい機能だから雑でいい」とすると、あとでじわじわ返ってきます。
3. 監視対象を増やしすぎると自分が死ぬ
個人開発では、全部を監視しようとすると逆に続きません。
だからこそ、
- 何を見ないか
- どこは気にしないか
- どこだけは絶対に見るか
を先に決める必要があります。
これは SRE 的にいうと可観測性の話ですが、個人開発ではもっと直接的に、自分の集中力を守るための設計 でもあります。
実際の考え方
ここまでの話を雑にまとめると、僕の中では次のような分担になっています。
- 価値の源泉 は自分で持つ
- 壊れると面倒だが差別化にならないもの は外に逃がす
- 入口の防御 と 重要導線の定義 は自分で持つ
この線引きがあるだけで、運用の重さはかなり変わります。
僕は個人開発で、こういう順番で考えることが多いです。
- この機能は本当に必要か
- 自分で持たなくていい責務は何か
- 事故ったときに誰が面倒を見るのか
- 毎日/毎週確認が必要になるものは何か
- それを減らす方法はないか
この順番で見ていくと、「実装できるか」だけでは見えなかった負債が見えてきます。
まとめ
個人開発では、頑張って運用する設計は長続きしません。
新しい機能を作る時間を守るためにも、最初から
- 自分で持たなくていいものは持たない
- managed service に逃がせるものは逃がす
- 重要導線だけを明確に見る
- 日々の確認作業を減らす
という設計に寄せる方がいいと思っています。
可用性を上げることも大事ですが、個人開発ではそれと同じくらい、自分の時間を守ること が大事です。
その意味で、個人開発における SRE っぽさは、「すべてを完璧に運用すること」ではなく、運用しないように設計すること にあるのかもしれません。
Discussion