2022年の初めのことでした。私たちが運営している PlanGo というビジネス（訳注: オランダの自動車教習所向けのソフトウェア）の年間経常収益を集計してみたところ、共同創業者と私は信じがたい瞬間を共にしました。同社の年間経常収益が100万ユーロ（訳注: 約1億6300万円）という重要なマイルストーンをついに突破していたのです。たった1つのRailsコードベースとたった1人の開発者（=私）で構成されている企業がこのような瞬間を迎えるときが来るとは、にわかには信じられないことでした。

ここで明確にしておきたいのですが、ビジネスを立ち上げたのは私一人の力ではありません。PlanGoの共同創業者は、同社のビジョンを形成し、潜在顧客との面会を重ね、成長を実現するうえで極めて重要な役割を果たした人物です。ただし、技術面を担当したのは私1人です。私はRails開発者として、「アーキテクト」「デザイナー」「フルスタックエンジニア」「データベース管理者」「DevOpsエンジニア」の役割を一手に担いました。

Railsの作者であるDHHは、Railsを「個人開発フレームワーク（One Person Framework）」と形容しています。Railsというフレームワークが完全なアプリケーションを1人の開発者だけで構築・メンテナンス可能にしていることが、この言葉に表れています。

そう、Railsは、データベース設計からビジネスロジック、フロントエンドUIにいたるまで、あらゆることを1人でもこなせるように設計されていたのです。これは単なる仮説ではありません。私はまさしく、Railsが本物の個人開発フレームワークであることを実際に体験したのです。

本記事は、以下の読者層に向けて書かれています。

• 専門家のチームなしでも果たして大規模なサービスを構築できるのかという疑問を抱いているRails開発者

• 多くの業務を抱えて多大なプレッシャーにさらされている技術系のビジネス創業者

• 職人技を信頼し、適切なツールやフレームワークを使っているすべての人

ここでは、私たちのビジネスの成長を実現したのはどのような技術上の決定事項だったか、アプリケーションのビジネスの両面をスケールさせるうえでどのような困難があったか、そしてその過程で得たさまざまな教訓についてお話ししたいと思います。

Railsは「Hello World から IPO (上場) まで」の道のりを約束してくれますが、私は、成功そのものよりも、そこに至るまでの道のりの方が魅力的に思えてきました。

最初の立ち上げ

2011年の私は、Web開発を一通りわかったつもりになっていた21歳の開発者でした。既にCodeIgniterでいくつかのPHPアプリケーションを構築していた当時の私にとって、Railsへの乗り換えは魅力的な選択に思えました。何か大きな戦略を構想していたとかではなく、当時話題になっていたものを試してみるのが楽しかったというだけの話でした。

PlanGoというビジネスを立ち上げるにあたり、共同創業者はマーケティングについて「立ち上げ期間中にサインアップしてくれたすべてのユーザーに、私たちのソフトウェアを最初の1年間は完全に無料で提供する」という素晴らしいアイデアを思いついてくれました。この時点では、関心を持つユーザーはおそらく数十人程度だろうと予想していました。

最初の1週間でサインアップ500件獲得

しかし、いざ始まってみると、私たちの電話は鳴りっぱなしでした。受信トレイにも、「このソフトウェアのことを詳しく知りたい」「こんな機能が欲しい」「サポート求む」といった問い合わせメールが殺到しました。

当時の問題は、アプリケーションがまともに動かなかったとかではなく、最初に私が構築したアプリケーションが最小限の機能しか備えていない、いわゆるMVP（Minimum Viable Product）に毛が生えた程度のものに過ぎなかったことです。そこに、完全な製品と適切なサポートを期待する500人ものユーザーが押し寄せてきたのでした。

これほどの人数のユーザーに対応する準備ができていなかったため、私たちは完全に手が回らなくなってしまい、そのせいで初期ユーザーの多くを失望させてしまいました。共同創業者も私も、それぞれ別の仕事を抱えていて、しかも当時の私はユーザーからリクエストされていた機能を構築しようとしていたため、片手間の対応ではユーザーからの要望を到底さばききれませんでした。

「ソフトウェアを開発すること」と「ソフトウェアビジネスをまともに運営すること」はまったく別の話であるという苦い教訓を、骨身に沁みて学びました。

厳しい教訓

正直に申し上げます。あの頃の私は、自分がやっていることを何ひとつわかっていませんでした。RailsのさまざまなチュートリアルやStack Overflowの回答と首っ引きで作業するぐらいは何とかできたものの、ユーザーのビジネスをまともに動かせるレベルのアプリケーションをproduction環境で構築する作業は、まったくの別次元でした。

私が最初の頃に書いていたRailsコードは、やってはいけない書き方のオンパレードでした。

• ファットコントローラ（メソッドのコードが200行超え）

• 無関係な責務を十数個も抱え込んだモデル

• ベテラン開発者が裸足で逃げ出すほどこじらせたSQLクエリ

• テストは1個もなし（ページを手動でリロードすれば済むと思っていた）

• コンフィグの秘密情報をGitにがっつり登録していた

いかにも初心者がやりそうなミスを、本当に片っ端からやらかしてしまっていたのです。アプリケーションは（かろうじて）動いてはいたものの、ガムテープで応急処置して後は祈るしかないようなレベルの、惨憺たるありさまでした。

しかもアプリケーションには、それはそれは大量のgemが使われていました。あきれるほど多くのgemです。

「ユーザー認証? gemでやればいいじゃん」
「ファイルのアップロード機能? gemだよね」
「PDF生成、もちろんgemで」
「管理画面? gemでしょ」
「メール処理?  gemで」

こうしてアプリケーションのGemfileは、ユーザー数の増加を上回る勢いで膨れ上がっていきました。当時はgemを使う方が時間を節約できると考えていたのですが、やがてgemの1つ1つが問題の種になっていったのです。

痛恨の失敗から学んだこともあります。少なくとも通貨を扱う場合、BigDecimalと基本的な算術演算に加えてgemに依存していると、数値に対して .round(2) を呼び出したときに、小数点以下2桁の丸めではなく「銀行丸め（banker's rounding: 偶数への丸め）」になってしまったことがあります。このようなことが起きる可能性があるのです。

2013年までには、さすがにビジネスの回し方については少しずつ理解し始めていたものの、技術的な負債が急速に増大してしまい、新機能の構築もままならない状態でした。

アプリケーションを完全に書き直した

経験豊富な開発者なら誰しも「アプリケーションを完全に書き直すのは愚の骨頂」であることを知っているものです。完全な書き直しは最終兵器のようなもので、危険で時間がかかるうえに、そもそも不要です。

しかし、2014年の私は、あえてその禁を犯しました。Railsの経験を数年積んできた私は、Rails 4のタイミングで一から新たに出直すという苦渋の決断を下したのです。

書き直しは数か月をかけて集中的に取り組みつつ、新しいアプリケーションの構築と並行して既存アプリケーションのメンテナンスも行いました。今回の開発手法は前回よりも賢い方法になったおかげで、アーキテクチャが劇的にシンプルになりました。gemの依存関係は半分以下になり、重要な機能のテストも書くようになりました。

新しく書き直したコードベースはシンプルで、しかも高速でした。そして最も重要なのは、パートタイム開発者1人でも十分メンテナンス可能になったことです。再構築された基盤は、その後のビジネスの成長において極めて重要でした。この基盤が、私1人で開発を手がけているビジネスの成長を10年以上にわたって支えてくれたのです。

Railsの並外れたパワー

PlanGoの開発者は2025年まで私1人だけだったという話を聞くと、多くの人が「まさか！」と驚きます。「どうすればそんなことが可能なんですか？」と聞かれたときの私の答えは「Railsで」の一言です。

私はRailsのおかげで、開発を短期間で効率よく進められました。Railsに備わっている「設定より規約（Convention over Configuration: CoC）」「統合テスト」「Active Record」「Acive Storage」「Active Job」のおかげで、本質的でない技術的決定を下すために悩まずに済み、本当に価値を生み出す作業に集中できました。Turbolinksや後のHotwireが登場したときも、当時の目まぐるしいほどの最新JSフレームワークに煩わされずに最新のUIを構築できました。

私が2011年にPlanGoの開発を始めた頃、モバイルアプリはまだ一般的ではありませんでした。当時のユーザーも、いくつかのレスポンシブ表示を超えるようなモバイル版を欲しがってはいませんでした。しかしそれから数年で状況は劇的に変化し、今ではiOS版とAndroid版のネイティブアプリの方がPlanGoを使うときの主要な方法となっています。

しかし、ここまでの道のりは簡単ではありませんでした。TitaniumやRubyMotionなどのフレームワークを試してみたこともあれば、Objective-Cを学んでネイティブアプリを自作しようとしたこともあります。しかしRails以外のどの方法も、品質と開発速度の間で大きなトレードオフを強いられました。

そうこうするうちにTurbo Nativeが登場しました。これによって生産性が爆上がりし、「アプリの構成方法」「認証処理」「ネイティブアプリのような画面遷移」など、ネイティブらしいアプリの開発スキルが飛躍的に向上しました。残りの部分はTurboが補ってくれるので、私は既存のRailsコードベースやスキルをこれまで通り活かせるようになったのです。

この手法は、多くのビジネス用アプリ（特にB2BアプリやSaaSアプリ）にとって、まさしく長年探し求めてきた聖杯です。開発でひと手間加えるだけで、ネイティブアプリ並のパフォーマンスと操作性を得られるのですから。
その実力は数字が証明しています。私たちのPlanGoアプリは年間10万ダウンロードを超えています（オランダでは、あの有名なDuolingoアプリを一時的に上回ったこともあります！）が、それらすべてを構築・メンテナンスしているのは、たった1人のRails開発者なのです。

私たちのPlanGoについて、より詳しくわかる数字を以下に示します。

• Rubyコード: 36,170行

• JavaScriptコード: 13,495行

• テストカバレッジ: 40%

• 1日あたりのアクティブユーザー数: 6,332人

• ピーク時のリクエスト数: 7,000件

• 月額サーバーコスト: 1,500ユーロ未満

他のフレームワークに目移りせずに「十分構造化されたモノリス」にこだわったことは、私が下したさまざまな技術的決定の中でも特に重要な決断でした。マイクロサービスで頭痛の種を抱えることもなく、デプロイはCapistranoで極めてシンプルに行え、デバッグも簡単です。どれも、私1人で開発するうえで重要な要素です。

技術系の創業者にとって、Railsは単なるフレームワークではありません。1人でチーム全体の仕事をこなすための手段であり、まさにスーパーパワーです。

年間経常収益100万ユーロを達成

2022年末頃、思いもよらぬ出来事が起こりました。PlanGoに興味を持つ海外投資家が私たちに買収の話を持ちかけてきたのです。

その頃のPlanGoは、年間経常収益が100万ユーロを超え、自己資金と事業収益だけで十分ビジネスを回せるほどに黒字化していました。Railsを基盤とするスリムなオペレーションで成り立っていた私たちにとって、外部資金援助も大規模なチームも不要でした。

しかし買収の可能性が持ち上がったことで、私たちはいったん立ち止まって振り返ることを余儀なくされました。「自分たちが本当にやりたいことは何なのか？」「自分たちの力だけで成功させたこの事業を本当に手放していいのか？」「積極的に事業を拡大するか？それとも現状維持か？」

私たちの今後について、これまでと異なる視点で考えるときが来たのです。
多くの選択肢を検討し、多くの投資家と話し合いを重ね、じっくりと自分の気持を分析しました。そして明らかになった結論はこうです。

「私たちが今のビジネスを愛していることは間違いない」
「しかしこの機会を活用すれば、リソースと専門家をさらに投入するのが容易になるだろう」

率直に申し上げれば、価値あるものを作り上げる作業を長年続けてきた私たちにとって、この投資を検討することは、自社株を現金化できるという意味では悪い話ではありません。私たちは10年以上もPlanGoに心血を注ぎ込んできたのですから、そうして育て上げた価値の一部を形にすると同時に、今後も自分たちの手でビジネスを成長させるという方針は筋が通っています。

最終的に、私たちは完璧な落とし所を見出しました。オランダのあるエバーグリーン・ファンド（=明確な終了日がなく、利益を再投資しながら継続的に運用する無期限ファンド）と、私たちの価値観や長期的な見通しについて意気投合できたのです。こうしてPlanGoの一部を売却し、重要な所有権と経営権は手元に残しつつ、次のレベルに到達するためのパートナーを獲得できました。

私たちは、事業から急いで撤退したのでもなければ、あらゆる犠牲を払って事業を強引に拡大しようとしたのでもありません。私たちは、自分たちが培ってきた価値観を理解してくれるパートナーに出会えたのです。すなわち「持続可能なビジネスであること」「顧客を幸せにすることと利益を両立させること」という価値観です。私たちは、この価値観という基盤を捨て去るのではなく、さらに発展させたいと考えました。

そして私たちは、今もパートナーと一緒に旅を続けています。ビジネスをここまで発展させてくれたRailsのパワーを今後も引き続き活用しつつ、さらに従来はできなかった新しい機会を追求するための追加リソースを手に入れたのです。

このビジネスで得た教訓

私が技術系の個人開発創業者としてPlanGoの開発に14年携わることで得た教訓を、私と同じような道を歩む他のRails開発者たちにとって役に立てるために、ここでいくつか紹介しておきます。

1. Railsの規約は守ること

フレームワークに逆らうと、無用な摩擦が生まれます。「Rails way」が存在するのには理由があります。Rails wayは、とっくに解決済みの問題を踏むことなく、独自の製品開発に専念できるようにするためにあります。

2. 少ないほど良い

gemであろうとJavaScriptライブラリであろうと、増やせば増やすほど複雑になり、壊れる可能性も高くなります。私は、Gemfileに何かを追加する前には「これは本当に、本当に必要なのか？」と必ず自分に問いかける習慣を身につけました。

3. コミュニティとつながること

個人開発者として、他のRails開発者たちとつながりを密にしておくことはとても重要です。私がSpina CMSを構築したことでつながったコミュニティは、アイデアを共有したり学び合ったりできる同僚の存在に次ぐ、貴重な第2の情報交換の場となりました。

4. 技術的負債は必ずしも悪ではない

自分の書いたコードが少々雑であったとしても、その分リリースを早められるなら容認されることもあります。技術的負債は、借り入れが発生したときに「これは負債なんだ」と自覚することと、返済計画を慎重に考えておくことが肝心です。

5. 「1人でもここまでやれるんだ」と気づくこと

通常ならチームによる作業を必要とする構築、スケーリング、デプロイなども、Railsを使えば開発者1人で実現できます。「まずはチームを揃えないと」といった常識に囚われて立ち上げをためらわないようにしましょう。

後日談

新しいパートナーは、私たちの個人開発方式については気に入ってくれましたが、その代わりに「これだけは必ずやって欲しい」という条件を提示してきました。すなわち、Rails開発者をもう1人チームに加えるという条件です。
私にとって難題だったのは、「1人で開発している方がいい」という気持ちを克服することではなく、私がプログラマーとしてたった1人で14年かけて進化させてきた膨大なコードベースに、いかにして新しい開発者にスムーズに参画してもらうかということでした。

このコードには、PlanGoの進化の軌跡だけではなく、私自身が初心者から経験豊富な開発者へと成長してきた過程も刻み込まれています。その中には、初心者のときに下した技術的決定もあれば、経験を積んでから下した技術的決定もあり、経験や理解のレベルは実にさまざまです。そうした14年間にもわたる私の思考の紆余曲折を他所から来た開発者に任せるのは、大変な作業になることが見込まれました。そうした困難にもかかわらず、2人目のRails開発者（カナダのRails Worldで出会いました！）を迎え入れたことで、私たちに大きな変革をもたらしてくれました。

おかげで、これまで私につきまとっていた「私が死んだらおしまい」という単一障害点のプレッシャーが解消されたのみならず、自分には思いもよらなかった新鮮な視点やアイデアが吹き込まれたのです。ペアプログラミングのセッションを重ねることでコードの品質も向上し、同じRails言語を話せる者がいることで、知的にも大きな実りを得られるようになりました。

なお、今後大規模なエンジニアリングチームを編成する予定はありません。Railsのパワーを活用する私たちのアプローチによって、大勢の開発者をかき集めなくても、スケーラブルで価値のあるソフトウェアは開発できることはもう証明されています。

しかしこの度の変化によって、既に最大効率を達成している単独の開発者であっても、適切なチームメイトがいることにはメリットがあると改めて学びました。

PlanGoのサクセスストーリーは、Railsの「個人開発フレームワーク」としての実力を証明する良い例です。適切なツールを選んでおけば、小規模なチームでも本格的なビジネスを自分たちのペースで構築できることを示してくれました。

私がPlanGoでたどった道すじが、初めて製品を開発する個人開発者たちにとっても、技術スタックを検討している小規模チームにとっても、Railsの真価を引き出すことで実現できる可能性について何がしかのヒントになれば幸いです。

Railsアプリを1人で開発している方がいらっしゃったら、ぜひ私にもお知らせください。どんなものを構築しているのかお聞かせください。

偶然にも、本記事と同じ2025年4月に、シリコンバレーで有名な Y Combinator の公式 YouTube チャンネル『Startup School』から Ruby on Rails について言及された動画が公開されました。

当該動画によると、20年以上に渡って生き続けた「設定より規約」のコードが、 AI のパフォーマンスをより際立たせている、とのことです (意訳)。

本記事のストーリーにあるように、既にたった１人の開発者でも大きな成果が出せる Ruby on Rails ではありますが、AI 技術の発達により、個人の力を今後さらに際立たせていけるかもしれないですね!  💎✨

ココまでお読みいただき、ありがとうございました…!!! 🙇💖