- 1人で Railsでサービス全体を開発・保守 しながら、年 100万ユーロのARR（年間経常収益） を達成した個人開発者の実践記
- 当初は 基本的なMVP だけで始めたが、フルリライトと構造改善 を経て、保守可能な構成へと成長させた
- 核心は Railsの一貫した哲学、構成要素、そしてTurbo Nativeによるモバイル対応力 にある
- 全トラフィックと利用量をさばきながらも、月1,500ユーロ以下のサーバー費用で運用 できた効率的な構成
- 最終的には 長期志向の投資家に一部持分を売却 し、14年ぶりに2人目の開発者を採用 して新たな局面を迎えた
The One-Person Framework の実践適用記
Railsひとつで100万ユーロARRを達成
- 2022年初頭、PlanGoは 年間経常収益（ARR）100万ユーロ を突破し、これは 単一のRailsコードベースと1人の開発者 によるサービスとしては夢のような達成だった
- 技術以外のすべての領域――ビジョン策定、顧客獲得、成長戦略――は 共同創業者とカスタマーサポートチーム が担っていたが、アーキテクチャ設計からデプロイ、運用、フロントエンド/バックエンド実装までをすべて1人で担当 した
- DHHが唱えた「One Person Framework」、つまり1人の開発者がアプリケーション全体を管理できる構造が、理論ではなく現実として証明された
- Railsの構造的な哲学――データベース設計、ビジネスロジック、フロントエンドUIまでを一貫したツール群の中で扱えること――は、少人数または1人の創業者にとって特に有利 だった
- この記事は次のような人に向けて書かれている:
- Rails開発者: 今でも1人で大きなプロダクトを作れるのか悩んでいる人
- 技術系創業者: 複数の役割を抱え込み、負荷の大きさを感じている人
- 職人気質や技術選定を重視する人
始めた当時の状況
- 筆者は2011年、21歳の開発者として既存の PHP(CodeIgniter) プロジェクトに取り組む中で、Railsに入門した
- 大きな戦略があったわけではなく、トレンドに乗ってRailsを使ってみたいという単純な動機 から始まった
- 共同創業者のマーケティング案により、ローンチ週の登録者には1年間無料提供 というオファー戦略を実行
- 数十人程度を想定していたが、実際には 初週で500人以上が登録 した
- MVPレベルのプロダクトだったため、すぐに 数百件の機能要望、質問、サポート依頼 が殺到した
- サーバーは問題なく動いていたが、プロダクトが完成していない段階で顧客要求が爆発的に増加 した
- 共同創業者2人とも 本業を持っていたためフルタイムでの対応は不可能 だった
- その結果、多くの初期ユーザーを失望させざるを得ない状況が生まれた
- この経験を通じて、「ソフトウェア開発」と「ソフトウェアビジネスの運営」はまったく別の問題だと痛感した
- 機能実装だけでは不十分で、持続可能な顧客対応、期待値管理、サービス運営体制 が必要だという教訓を得た
作りながら学ぶ
- RailsチュートリアルやStack Overflowを参考に開発を始めたが、本番環境で実際の顧客ビジネスを支えるアプリケーション構築はまったく別次元の仕事 だった
- 初期のRailsコードには、次のような 典型的な初心者のミス が含まれていた:
- 200行を超えるコントローラーメソッド
- 役割が混在した巨大なモデル
- 非効率なSQLクエリ
- テストコードなし
- Gitにコミットされた設定値やシークレットキー
- 機能実装自体は可能だったが、アプリケーション全体は 場当たり的なコードと不安定な構造に依存 していた
- ユーザー認証、ファイルアップロード、PDF生成、管理UI、メール処理など多様な機能は Gemに依存して素早く実装 したが、時間がたつにつれて 各Gemが新たな複雑性と問題を生み出した
.round(2) を使った際、期待とは異なる "banker's rounding" が適用され、金額計算の誤り が発生
- 単純な計算まで外部Gemに任せた結果、数値処理の本質的な理解不足が問題を招いた
- 2013年ごろには、プロダクト運営の経験が蓄積する一方で 技術的負債が急速に増加 し、新機能開発がますます難しくなっていった
全面リライト
- フルリライトは 一般に危険で非効率な選択と見なされがち だが、2014年に Rails 4ベースで完全にゼロから再構築 することを決断
- 既存アプリケーションを維持しながら、同時に新しいコードベースを開発する 集中的な作業を数か月並行 した
- アーキテクチャを単純化し、Gem依存を半分以下に減らし、主要機能にテストを導入 した
- 新しい構造は以前より 簡潔で高速 になり、とりわけ パートタイムの1人開発者でも保守可能な水準 に設計された
- このリライトはその後 10年以上にわたり単独開発者が運用できる技術基盤 となった
Railsは超能力
- PlanGoは2025年までたった1人の開発者によって運営されており、その実現を可能にした最大の理由は Rails だった
- Convention over Configuration、統合テスト、ActiveRecord、ActiveStorage、ActiveJobといったRailsの構造的特徴のおかげで、本質でない意思決定を最小化し、コアバリューの創出に集中 できた
- TurbolinksやHotwireの導入以降は、複雑なJSフレームワークなしでもモダンなUIを実装可能 だった
- 2011年の開発初期にはモバイルアプリ需要はほとんどなかったが、その後は iOS/AndroidアプリがPlanGoの主要インターフェース となった
- Titanium、RubyMotion、Objective-Cなど複数のフレームワークを試しながら、品質と速度のバランスの問題 に直面した
- Turbo Native 導入後は生産性が急激に向上し、基本的なネイティブ開発の知識だけでもRailsコードベースを活用した高品質なアプリ実装が可能 になった
- この方法は特に B2BやSaaSアプリで理想的なアプローチ であり、ネイティブの性能と体験を小規模な開発コストで実現 できる
- その結果、年間 10万回以上のアプリダウンロード、一時的にはオランダのApp StoreでDuolingoを上回る順位 も達成した
- すべてのアプリは 1人のRails開発者によって開発・保守 されている
- 主な指標:
- Rubyコード: 36,170行
- JavaScriptコード: 13,495行
- テストカバレッジ: 40%
- 日次アクティブユーザー: 6,332人
- ピーク時の毎分リクエスト数: 7,000件
- 月間サーバー運用費: €1,500未満
- 構造化されたモノリシックアーキテクチャ を維持したことは最良の選択の1つであり、マイクロサービスの複雑さなしにCapistranoで簡単にデプロイでき、デバッグもしやすかった
- 技術系創業者にとってRailsは単なるフレームワークではなく、1人でチーム全体の仕事をこなせるようにしてくれるスーパーパワー だった
100万ユーロのその先へ
- 2022年末、予想外の転機が訪れる。海外の投資家がPlanGoに関心を示し、買収提案 を持ちかけてきた
- 当時のPlanGoは ブートストラップで€1M ARRを超えた状態 で、外部資金なしでも 持続可能な収益構造と効率的な運営 を維持していた
- この提案はチーム内に "私たちはこれから何を望むのか?" という問いを投げかけるきっかけになった
- 従来どおり維持するのか、外部資金でスケールアップするのか、完全に売却するのかなど、さまざまな可能性を検討した
- 事業への愛着は依然として深かった が、より多くのリソースと専門性を確保できれば、チャンスをより容易に実行へ移せる という認識が生まれた
- 利益確定の観点でも、10年以上かけて積み上げた価値の一部を回収しつつ事業を成長させ続ける選択肢 は合理的だった
- 最終的に選んだのは、価値観と長期的な方向性がよく合うオランダのエバーグリーンファンドとのパートナーシップ締結だった
- 一部持分を売却しつつ、経営権と過半の持分は維持
- 追加リソースを確保しながらも、既存の構造や文化を損なわない形
- この決定は短期的なイグジットや攻撃的拡大ではなく、持続可能で顧客中心のビジネスを基盤とした安定成長戦略 の一環である
- その後も Railsベースのアプローチは維持 しつつ、これまで挑戦しにくかった機会をより積極的に追求する新たな局面に入った
学んだこと
- PlanGoを14年間、1人の技術系創業者として運営して得た教訓は次のとおり
- Embrace Rails conventions
- Railsの哲学や規約に逆らおうとしないことが重要
- 「Rails Way」は すでに実証された問題解決法 であり、それに従うほど プロダクト固有の価値に集中できる
- Less is more
- GemやJSライブラリは 機能を素早く実装できる一方で、複雑性や故障リスクも高める
- 新しい依存関係を追加する前には、必ず "これは本当に必要か?" と自問すべき
- Find a community
- ソロ開発者にとって、他のRails開発者とのつながりは非常に重要
- たとえばSpina CMSを作る中で得たコミュニティは、同僚ではなくても知識共有やフィードバックのための貴重な接点 となった
- Technical debt isn't always bad
- 素早く市場に出るための実用的な選択 が、技術的な完璧さより優れることもある
- 技術的負債は、意識して受け入れる時期と返済する時期を見極めることが肝心
- You can go far alone
- Railsを活用すれば、1人の開発者でもチーム規模のプロダクトを設計し、拡張し、デプロイできる
- 「チームは必須だ」という一般的な通念に縛られる必要はない
これから
- 新たな投資パートナーはPlanGoのスリムな運営方式に同意しつつ、ただ1つの条件を提示した: Rails開発者をもう1人追加すること
- 問題は1人開発へのこだわりではなく、14年にわたって発展してきたコードベースに新しい開発者をオンボーディングすること自体の難しさ にあった
- そのコードベースはPlanGoの進化であるだけでなく、初心者から熟練者へ成長してきた個人の開発ヒストリーがそのまま刻まれた構造 であり、
異なる時期の自分自身が下したさまざまな判断やコードスタイル が混在していた
- Rails World（カナダ）で出会った2人目のRails開発者を採用したことで、構造的な変化と前向きな影響 が生まれた
- 単一障害点だった技術リスクの解消
- 新しい視点とアイデアの流入
- ペアプログラミングによるコード品質の向上
- 同じ言語を共有する開発者仲間との協業がもたらす知的刺激
- 今後も 大規模な開発チームを作る予定はない
- これまでに証明されてきたように、Railsベースのアプローチだけでも小さく強いチームが意味のあるソフトウェアを作れる
- ただし、どれほど効率的な1人開発者であっても、良いチームメイトによってさらに成長できる ことを実感した
- PlanGoの歩みは RailsのOne-Person Frameworkが実際に機能することを示す事例 であり、
適切なツールを持つ小さなチームが、自分たちなりの基準で本格的なビジネスを築ける証拠 でもある
- 初めてのプロダクトを作る1人開発者であれ、技術スタックを検討している少人数チームであれ、この話が Railsを最大限に活用したときに開ける可能性 を示すものになればと思う
4件のコメント
この内容をNotebookLMのオーディオ概要でポッドキャストにしてみました。
https://notebooklm.google.com/notebook/…
このくらいなら素晴らしいですね。もう少し磨いてみようと思います。
わあ……すごいですね……本当に。こんなに自然だなんて
そして、情報がすっと頭に入ってきますね……
Hacker Newsの意見
Djangoに近い経験を持つユーザーが、自分のアプリを運用している
フレームワークより人のほうが重要だと主張するユーザーがいる
RailsとPhoenixを使った経験を共有するユーザーがいる
Rails 7+がソロ開発者でも野心的なアプリを構築する助けになると発表したユーザーがいる
新しいパートナーがRails開発者を追加したがっていた経験を共有するユーザーがいる
AdonisJSを使ってアプリを構築中のユーザーがいる
RailsにはDjangoより優れている点が多いと考えるユーザーがいる
Railsを使ってアプリを構築しているソロ開発者がいる
全面的な書き直しは避けるべきだと主張するユーザーがいる
フレームワークはそれほど重要ではないと考えるユーザーがいる