スケールしないことをやれ、そして本当にスケールするな

• Paul Graham の「スケールしないことをやれ」というアイデアから出発し、GPT支援の開発環境によって、今では本当に小規模のままで仕事を完結できるようになった
• これからは小規模または個人向けのシンプルなプロジェクトを作り、それを必ずしも 成長 や ビジネス に発展させる必要はない
• 実例として、Slackコミュニティ、ポストカード送付サービス、決まった時間の通知アプリ などを個人あるいは小さな集団のために作り、満足感と実用性を得ている
• AIツール の発展により、小規模でカスタムなソフトウェア制作はコストと速度の面で非常に容易になり、小規模であること自体がむしろ目的になっている
• スケールへの強迫観念から離れ、小さくて役に立ち、自分にぴったり合う何か を作って、そこで止まる自由を楽しめる

---

背景: 「スケールしないことをやれ」と時代の変化

• 10年余り前、Paul Graham は「Do things that don’t scale」（スケールしないことをやれ）という概念を提唱した
• このアイデアは、初期には手作業中心の小さな実験や個人的なアプローチから始め、徐々に拡張する方法を探せという趣旨だった
• しかし最近では GPTベースのツール によって、「初期作業」だけをやって止めても十分であり、むしろそれが最善ですらある
• プロジェクトを始めるための コストと時間 は大きく下がり、あらゆるアイデアがビジネスへと成長しなければならない必要もなくなった
• 自分自身、あるいは大切な少人数だけのためのサービスでも、十分に目的を持ちうる

大きくしてはいけない Slack

• 筆者は約 100人 のユーザーがいる Slackワークスペース を運営している
  • 実際に週ごとに活発に会話する人は 15〜20人ほど
  • 親密さと私的な雰囲気が保たれ、Twitter などの公共プラットフォームより深いコミュニケーションができる
• もっと大きくすることはできるが、拡大 するとすぐに雰囲気が壊れ、親密さが失われる
  • 1,000人規模にする必要もない
  • 名前を知らない人が増え、誰が聞いているのかわからなくなると会話量も減る
• 小さいからこそ可能なこと がある

PostcardMailer: 小さく、そしてシンプルに

• 数年前、筆者は Instagramに写真を投稿すると母親にポストカードを送ってくれる 小さなサイト（PostcardMailer）を作った
  • 写真と説明を取り込み、郵便 API で母親に発送する
• Instagram API のポリシー変更でその方式が使えなくなり、写真アップロード方式で再実装した
  • 友人と一部の Orange Site（Hacker News）ユーザーが利用した
  • その後、スパム や悪用への懸念からアカウント管理を制限した
  • Heroku のサービス終了によりサイトの維持をやめ、最終的に メールベースのサービス へ移行した
• 今では iPhone から [e-mail] にメールで写真を送ると、母親にポストカードが発送される
  • 非公開で、ログインやパスワードもない
  • 世の中にはポストカードサイトはたくさんあるが、まさに望んだやり方 で動くのはこのサービスだけだ

Landline Pill Reminder: 母親だけのための通知アプリ

• 母親が決まった時間に薬を飲まなければならない状況があった
  • 母親はスマートフォンを持っておらず、たいていは折りたたみ携帯すら電源を切っている生活だった
• 信頼できる連絡手段は郵便か固定電話しかなかった
• そこで Twilio API を使って、1日3回音声通話をかける小さなアプリを作った
  • 「薬を飲む時間です」という録音音声を流す
  • 10分後にもう一度電話して確認を求める
• 制作コストはほとんどかからず、数日で完成した
  • これをスケールさせようとすると、他人へのサポート、責任、法的な不安まで発生するが、母親だけのためのソリューション であることが最も安全で効率的だった

パターン（教訓）

• 自分にとって意味のある ニーズ を見つける
• 最も 小さくシンプルな解決策 を作る
• スケールしたい欲求をできる限り抑える
• 完成したソリューションを 楽しむ
• 以前は拡大が中心だったが、今では 「小ささ」そのものが目的 になりうる
  • AIなどの補助ツール により、個人向けにカスタマイズしたソフトウェア制作のコストと労力が大幅に下がった
  • 1人または少人数のユーザー のためのサービスが最適な選択になりうる

結論: 「小ささ」の価値

• 今日のツールと環境における 本当のぜいたく／恩恵 は、速度やコストやAIではなく、そこで止まってよい自由 にある
• 自分だけの「小さくて役に立ち、ぴったり合うもの」を完成させ、無理な成長を追い求めなくても十分だ
• スケールに執着する時代において、ほどよく満足して立ち止まる 静かな満足感 が新しい価値になっている

[GN⁺]

Hacker Newsの意見

• どこまで大きくなれるのか気になる気持ちはあるけれど、ある時点――たぶん1,000人より前くらい――で空気が壊れる感じがする。親密さが失われ、名前にも見覚えがなくなり、誰が投稿を見ているのか分かりにくくなるので会話も減る。成長そのものがむしろ悪影響を与えるわけで、小規模だからうまく機能しているように思う。これは Facebook のようなソーシャルネットワークでも同じだと思う。2005〜2010年ごろの Facebook は、主に大学や高校や会社の友人たちが集まって自由に考えを共有し、面白いリンクを回していた時期だった。ところが知り合いがどんどん増え、親しくない人まで友達リストに加わるにつれて、雰囲気はまったく変わってしまった。ある瞬間から、そこまで親しいわけでもない人が自分の投稿を不快に思ったり意見衝突が起きたりすると、だんだん共有しなくなるという経験を誰もがしている

  • Facebook で大して過激でもない内容なのに悪態を1つ書いたら、祖母からメッセージで消してくれと言われたのを覚えている。代わりに祖母をブロックした。祝日にだけ会うくらいのほうがむしろ良かった。祖母はこのことに気づきもしなかったようだ
  • この現象には実際に「Context Collapse」という言葉がある。ソーシャルメディアが、職場・学校・家族などあらゆる社会的状況ごとに異なる自分を見せるのではなく、単一のオンライン人格を強いることを説明する言葉だ。関連リンク
  • 友人たちの中で自分がいちばん最後に Facebook に登録したのを覚えている。IRC で育ったオールドスクールなインターネットユーザーとしては、実名と写真を、いかにも頼りない PHP サイト（しかもハーバード出身の誰かが作ったもの）に入力するなんて、ひどく奇妙に感じられた。でも女の子たちがみんな使っていたので、結局みんなそちらへ流れていった。あれが歴史になる瞬間だった
  • ある時点から Facebook がもはや何かを共有する場所ではなく、競争の場なのだと皆が一斉に気づいたような瞬間があった。そのとき皆は共有をやめ、代わりに「キュレーション」を始めた
  • 2008年ごろの Facebook は本当に良かった。現実の友人たちと一緒にいる感じだった。でも家族が加わると、親戚一同との食事会のような空気に変わってしまった

• 自分のために何かを作る過程は楽しい。自分もそうしている。ただ、元の文章は創業者――つまり会社を作る人――に向けた文章だという点は指摘しておきたい

  • これは特定のタイプの会社、とくに tech startup の話だ。スタートアップのように成長だけに執着して赤字を許容するのではなく、できるだけ早く利益を出す「会社」を作るという視点がもっと必要だと言いたい。必ずしも成長しなくても利益を出せる会社を作るべきだと思う
  • そう、元記事の助言そのものが創業者中心だったのは認める。自分もこの素敵なフレーズを少しひねってみたかった。使い勝手がいいので
  • 自分の問題を解決しようとして何かを作り、それが他の人たちも抱えていて、しかも彼らが解決しようとして失敗してきた問題なら、需要が生まれる可能性がある。十分に不便な問題なら、お金を払う価値もあると思う。実際、こういう問題は B2C より B2B で見つかることが多い。個人的な問題が B2B に広がることはよくある
  • 「Startup」という言葉は、しばしば「急成長するよう設計された小規模な会社」と定義される

• Robin Sloan が数年前に似たテーマで書いた文章がある。プログラミング言語や知識がなくても、誰でもちょっとしたものを作って楽しめるようになったことは、ここ最近で最も前向きな変化の一つだと思う。別に大げさなイノベーションである必要はない。関連文

• Claude Code を使って、ロールプレイングゲーム用のヘックスマップを作る小さな Web アプリを作った。似たようなサイトはたくさんあり、その多くは無料だ。しかも自分のアプリにない機能を持っているものも多い。でも自分のアプリは、自分が望むやり方で動く。川や森をタイル地形の上に重ねるような編集、さまざまな集落アイコン、丘や山のより多くのバリエーションなど、自分が欲しかった要素が反映されている。欲しい機能が出てきたら、そのまま追加すればいい。他人のアプリを見て「仕方ない」と思う必要はない。個人用途なので、スケーラビリティやセキュリティ、収益化などを気にする必要もない。実際の開発には1〜2時間ほどしか使っておらず、それすら2日に分けて AI に書かせた

• 「Do things that don’t scale」というスタートアップの格言がある。Airbnb や Y Combinator の初期から使われていた気がする。数日前にも HN にまた上がっていた。関連記事

  • 面白いタイミングだ。先週末にこの記事を書いたのに、今週は HN をほとんど見ていなかった
  • Google 検索で最初に出てくる記事なので、元記事の信頼性には少し傷がつく気がする

• 何もかも大きくなる必要はない、という考えには同意する。でも ChatGPT と今回のテーマの間に、そこまで接点があるとは感じない

  • 以前は射出成形しかできなかったのが、今は 3D プリンターがある、というようなたとえだ
  • 実際、記事に出てくる例ですら LLM（大規模言語モデル）以前の話だ
  • たぶん ChatGPT でコーディングしたことがないのだと思う

• Robin Sloan の「アプリも家庭料理のように作れる」という文章を勧めたい。関連リンク

• この記事には本当に共感する。こういう理由でソフトウェアコンサルティングの仕事をやめた。これからは LLM に必要なものをすべて書いてくれと頼めばよく、技術スタック、ホスティング、統合まで勝手に面倒を見てくれる。「Discord の代替を探す」が「自分と友達のための Discord クローンを作って」に変わる世界だ。コード品質は重要ではなくなる。どうせ何百万人ものユーザーが使うわけではないのだから

  • これには同意しない。こうしたことは LLM 以前にも可能だった。ほとんどの製品にはすでにオープンソースの代替があり、インストールやデプロイも LLM を使うより簡単なことが多かった。しかもアップデートなども受けられる。ただ、人々はインストールやデプロイやセキュリティ維持の責任を負いたくないので、そうしたサービスに少額を払うほうがずっと良いと感じているだけだ。問題はコードを書くことではなかった

• Maciej Ceglowski の名作「Barely Succeed: It’s Easier」を思い出す。関連YouTubeリンク

• 本質的に、「スケール」がそこまで重要な目標だったのか疑問だ