Qiita30万記事を集計した技術書ランキングが、開設3週間で10万円になった話

個人開発の話は、億単位の調達をした起業家か、収益ゼロのまま止まったサイトかの両極に寄りがちである。2018年5月にQiitaへ投稿された「開設後３週間で収益１０万円を得た個人開発サイトでやったことの全部を公開する」は、その中間にある数字を出した記事だ。書き手(@jabba)は自ら「だいたい１ヶ月でiPhoneXが買えるぐらいのサイト規模」と表現している。派手ではないが、手が届く範囲の到達点として輪郭がはっきりしている。

何を作ったのか

対象はtechbookrank.com(テック・ブック・ランク)という技術書ランキングサイトである。QiitaのAPIから技術書に言及している記事を抜き出し、その集計結果で書籍を並べる。「たくさんの技術ブログ記事で紹介されている本ほどいい本」という発想だ。

「いい本」の判定は3条件で、たくさんのQiita記事で紹介されている本、人気のあるQiita記事で紹介されている本、新しい記事で紹介されている本。書き手は「恣意的に特定の本のランクを上げたりは絶対にしていない」と明記している。

面白いのはタグの扱いだ。Qiita記事に付いたタグをそのまま書籍のタグとして継承させている。タグ→記事→書籍という間接的な連結なので、書籍の内容とタグは厳密には一致しない。例として挙げられているのが『人工知能は人間を超えるか』で、この本にはPythonやTensorFlowのタグが付く。本文にそれらの技術への言及はないが、「この本を紹介するエンジニアはだいたいPythonやTensorFlowに関係する記事を書いていますよ」という意味になる。書き手はこのゆるい結びつきを、Amazonの売れ筋順にはない「本との出会い」を生む仕掛けとして意図的に残している。

収益10万円について、記事が書いていないこと

先に断っておくべき点がある。この記事には収益源の内訳が書かれていない。「サイトのマネタイズ」という節はあるが、そこで語られているのは金額を評価基準として重視する理由であり、括弧書きで「ここで言ってるのはあくまで評価基準であって、ウェブサイトの収益モデルが有料課金か無料の広告収益モデルか、とかではない」と、手段の話ではないことがわざわざ明示されている。したがって「3週間で10万円」の獲得手段は本稿でも特定しない。判明しているのは金額と期間だけである。

その代わりに書かれているのは、なぜ収益にこだわるかという理屈のほうだ。「お金の指標がもっとも厳しくそのサイトの良し悪しを測るバロメーターになる」。いいね数では「おーいいモノ作ったねー」で終わってしまうが、「＊円を払ってでも欲しいか」と突きつければ評価は一段厳しくなる、という考え方である。

決定打は、前作で「自分の思い」を出し切ったことだった

軌道が変わった地点ははっきりしている。テック・ブック・ランクの前に作ったサイトは「かなり自分の思いと情熱で突き進んで作ったのだが、結果的にはスベった」。そこで書き手は方針を反転させ、「一旦は自分の思いを置いて、成功事例をトレースすることで企画の立案を学び直す」ことにした。本人が「この方針がとても良かったと思っている」と書く、その一点が前作と本作を分けている。

新しい企画の手順は3行で示されている。対象ユーザーを特定する。そのユーザーが欲しいモノ、気に入っている他製品をとことん調査してコピーする。最後の最後に少しだけ自分の味付けを加える。ターゲットは絞るほどよく、「理系の人向け」より「ITエンジニア向け」、さらに「ITエンジニアでかつ技術書が好きな人向け」ならもっといい、という具合に絞り込まれている。

伸びた理由を分解する

第一に、コンテンツを先に用意したことである。書き手は「ユーザー様はシステムになんか興味はない」「サイトにアクセスした際に目の前にあるのはコンテンツだけ」と書く。投稿型サービスが失敗する典型は、優れたシステムを作って投稿を待ち、身内の書き込みだけで終わる形だ。テック・ブック・ランクはQiitaの約30万記事をAPIで取り込むことで、開設初日から4,000冊分の書籍と投稿数が「実際には無くても、既にそこにあるかのように」並んでいる状態を作った。初訪問者が空のサービスを見ることがない。

第二に、読者が既にいる場所で告知したことである。流入の起点はサイトそのものではなく、先に公開した紹介記事「技術書ランキングをQiita記事の集計から作ったら、約4000冊の技術本がいい感じに並んだ」だった。集計元とプロモーション先が同じQiitaなので、記事を読む層とランキングの利用者層が完全に重なる。書き手も「この記事にそれなりに反響があって、そこからサイトにアクセスが流れて」と書いている。データの供給源と集客チャネルを一致させた設計が効いている。

第三に、無料インフラでコストをゼロに寄せたことである。理由が「サービスをできるだけ長く存続させてチャンスを増やすため」という点に注意したい。月数千円でも数ヶ月続けば撤退の口実になる、という運営心理を先回りしている。構成はRails・GraphQL・React+Redux・MongoDB・GCP・Netlify・Heroku・CloudFlareで、Herokuは無料Dyno、Add-onも無料枠、GCPは永年無料枠、MongoDBは500MBまで無料、Redisは25MB。その25MBのRedisに可能な限りデータを置き、全レスポンスをキャッシュから返してHerokuログ上5ms以内を保つ。DBが更新されたときだけRedisへ書き戻す方式で、通常時はデータベースをほぼ動かさない。初回表示に必要な情報はNetlifyに静的に置き、以降はGraphQLで非同期に取得してReduxに載せておく。無料枠の制約を、設計で速度に変換している。

書き手自身が挙げる失敗要因

記事には「個人開発で３大やってはいけないこと」が並ぶ。「マネタイズは後で考える」と言ってとりあえず作る。「コンテンツ(ユーザー投稿数確保)は後で考える」と言ってとりあえず作る。「ウケるかどうか出してみないと分からない」と言ってとりあえず作る。いずれも推奨する人がいることを認めたうえで、「少なくとも私にとってはこの３つが最大の失敗要因だった」と書いている。前作がスベった理由の自己診断とみてよい。

限界も明示的である。書き手は技術力と企画力に相関はないと述べ、自分の技術力を「頭で考えた企画をどのぐらいの割合でコード書いて実装できるか」で9割超と自己評価しつつ、それが良い企画に直結しないと切り分けている。到達点についても「たったの１０万円」と表現し、次は100倍を目指すと書いている。

再現できる部分と、できない部分

方法論は今も使える。ターゲットを一段深く絞る、先行事例を分解して模倣する、公開初日にコンテンツが埋まっている状態を作る、集客チャネルとデータの供給源を重ねる。ここに追加の資本はいらない。

再現しにくいのは条件のほうだ。まず、無料で使える約30万件の記事という在庫が外部に存在したこと。オープンなAPIを持ち、かつ利用者が濃く集まっているプラットフォームは多くない。次に、そのプラットフォーム上で紹介記事が反響を得られたこと。書き手はQiitaに継続的に投稿しており、収益記事自体も6,000を超えるいいねを集めている。無名のアカウントが同じ導線を引けるとは限らない。そしてインフラ環境そのものが変わっている。当時前提だったHerokuの無料Dynoは2022年に廃止されており、同じ構成をそのまま組むことはできない。

最後に、これは2018年の記録である。書き手はその後、個人サブスクメディアを分析するニュースレターを自作プラットフォームで週1配信するなど活動を移している。数字は当時のスナップショットとして読むのが妥当だろう。

あわせて読みたい

• ヒトデ氏 — 検索とコンテンツで積み上げた個人メディアの収益推移
• Carrd — 運営コストを極限まで削ったソロ運営プロダクト