月商40万円のサービスのコードを3万行から1.5万行に削った。4年目の作り直しが変えたもの

個人開発の記録は「作った」か「伸びた」で終わることが多い。この事例は、4年運営したあとに作り直した話である。しかも増やしたのではなく、コードを半分に削っている。

サービスの規模

月間30万PVで月商40万円。1PVあたりおよそ1.3円が回収できている計算になる。個人開発のWebサービスとしては高い水準である。

派生しているOSSライブラリ「pdfme」も、3,000スターとweekly downloads 100,000+という規模に育っている。本体の収益とは別に、技術資産としての面積が広がっている。

削った量

4年ぶんの機能追加で3万行に達していたものを、3ヶ月かけて1.5万行にした。機能を削るのではなく、同じことをより少ないコードでやる形に組み替えている。

移行の進め方も具体的だ。一斉切り替えではなく、無料ユーザーを30〜50%ずつ段階的に新版へ流し、約2週間かけて完了させている。収益の柱である既存ユーザーを一度に危険に晒さない。

なぜ削る判断ができたのか

ここが、この事例の読みどころである。月商40万円が立っているサービスのコードを半分にする作業は、それ自体は1円も新しい売上を生まない。本人も「1円も利益を産まない作業」と表現している。

にもかかわらず着手できた理由は、規模と体制の組み合わせにある。月商40万円は、1人が生活を賄うには十分だが、人を雇うには足りない。つまり、この先ずっと1人で保守し続けることが確定している。

その前提に立つと、3万行を抱えたまま5年目・6年目に進むほうが高くつく。依存パッケージが増えるほど更新作業は増え、1人しかいない開発者の時間を毎年削っていく。3ヶ月の作り直しは、その将来コストを先払いする判断だった。

同じ「1人で長く持つ」構造でも、68本のアプリを10年抱えた個人開発者は本数を増やす方向に、こちらは1本を軽くする方向に進んでいる。どちらも保守負荷の話であり、解き方が逆になっている。

「作り直し」が失敗にならなかった条件

個人開発で作り直しは危険な手である。技術スタックを変え、機能の方向も変えた結果、次のバージョンまでに19ヶ月かかって終わったSEOツールのように、作り直しがそのまま停止につながる例は多い。

この事例が3ヶ月で終えられた違いは、はっきりしている。

ユーザーがいた。月間10万アクティブユーザーが使い続けている。止められない以上、期限が自動的に発生する。

収益があった。月40万円が入り続けているので、3ヶ月手を止めても生活が崩れない。

やることが決まっていた。新機能を考える工程がない。同じ挙動を、より少ないコードで再現するだけである。作り直しの範囲が「実装」に限定されていて、「何を作るか」には及んでいない。

失敗する作り直しは、たいていこの3つ目が守られていない。反応がないから何を作るべきか分からず、その状態で土台に手を入れる。

掲載事例と並べる

月40万円はその4分の1あたりに位置する。

ただしPV単価で見ると評価が変わる。月30万PVで月40万円は1PVあたり約1.3円。月間350万PVで月20〜30万円だったブログメディアの1PVあたり0.5〜0.7円と比べると、PVは10分の1以下なのに単価は2倍以上である。読み物より、目的を持って使われる道具のほうが1アクセスの価値が高い。

OSSが別の資産になっている

見落とせないのが、このサービスから派生したOSSライブラリ「pdfme」の存在である。3,000スター、weekly downloads 100,000+。

本体の月商40万円とは別に、この面積が積み上がっている。OSS自体は直接の売上を生まないが、技術的な信用と、同じ課題を持つ開発者への露出を作る。帳票生成という用事を検索した人が、サービス側とライブラリ側の両方から入ってくる導線になる。

コードを半分に削る作業と、ライブラリを切り出す作業は、実務としては地続きである。汎用的な部分をライブラリへ追い出せば、本体は薄くなる。削減の一部は、外へ出したことによる結果とも読める。1人運営で保守量を減らしながら、外向きの資産を増やす形になっている。

再現の条件と限界

この判断から外へ持ち出せる見方は、1人で運営する前提が確定しているなら、コード量そのものが将来のコストになるというものだ。人を増やせない事業では、保守できる量の上限が事業の上限になる。

一方で、この判断が可能だったのは収益が先にあったからである。売上ゼロの段階でコードを半分にしても、増えるのは満足感だけになる。順序としては、まず数字を立て、その数字を長く保つために削る、という流れになっている。

付け加えると、4年目という時期も判断に効いている。1年目や2年目なら、まだ機能を足して伸ばす余地を探すほうが合理的だ。4年運営して規模が安定し、今後の伸びしろより保守の負担のほうが大きいと見えた段階で、削る判断が正当化される。作り直しの是非は、コードの状態だけでなく事業の年齢で決まる。

限界も書いておく。この記録にはリニューアル後の収益がどうなったかが出ていない。月40万円が維持されたのか、増えたのか、一時的に落ちたのかは分からない。削減できた保守工数も「1円も利益を産まない作業」という表現にとどまり、時間の数字はない。投資額(3ヶ月)は分かるが、回収額が分からない記録である。