Show HN で reach するための準備リスト: 兼業エンジニアの投下手順
Show HN を兼業 micro SaaS のローンチで効かせるための前日・当日の準備リスト。タイトル設計・初動コメント・関連コミュニティへの渡し方を、gpdf の Show HN 投稿準備で手元に組んでいるリストから書き出す。
兼業の Show HN は前日までの素材作りで結果の 7 割が決まる
Show HN を「投稿ボタンを押す瞬間の意思決定」と捉えると、兼業エンジニアにとっては最悪のチャネルになる。投稿後の数時間で何を返せるかでフロントページに残るかが決まり、その数時間に本業のミーティングが入っていれば終わる。だから兼業前提では、Show HN の準備は「投稿ボタンの前」に 9 割を寄せる以外にない。
私は受託テックリードを本業にしながら、業務外で gpdf / gsql を MIT で公開している (運営構造の詳細は nadai ecosystem の記事 を参照)。本稿は、gpdf を Show HN に投げるために手元で組んでいるリストを、後続 (gpdf-api 公開・gsql の広報) でも再利用できる形に書き出したものだ。投稿自体はまだ実行していないので、「やったら必ず reach する手順」ではなく「外す確率を下げるためにフロントロードする項目」だと読んでほしい。
前日までに確定させる 5 つの素材
兼業の最大の制約は、当日のリアルタイム可処分時間がほぼゼロという点だ。だから前日までに書き込み済みの素材を 5 つ準備する。当日に書き起こすのではなく、当日はコピペで動ける状態にしておく。
- タイトル:
Show HN: <product> – <one concrete benefit>の形に収める。70 字以内、機能でなく benefit を入れる。Show HN: gpdf – Pure Go zero-dependency PDF generator with CJK supportのように、「何ができるか」と「何が違うか」が同じ行で読み取れること - 最初の 30 秒で見える画面: README の冒頭か LP のファーストビュー。1 個の動く GIF / コードスニペット / スクリーンショット のいずれかで「これは動く」を即座に証明する。文章で説明し始めた時点で reach は半減する
- 比較表: 既存ツールとの差分を 1 個のテーブルにまとめる。私の場合は gofpdf / go-pdf/fpdf / UniPDF / gopdf / Maroto との比較で、軸は「Pure Go / CGO 不使用 / アクティブメンテ / ライセンス / CJK フォント対応」だった。比較表は技術系コミュニティで最も短時間で読まれる構造で、HN のコメントでも引用されやすい
- コメント返信用 FAQ: 過去の Show HN を 10 件ほど読むと、上位コメントの種類はほぼ 5-6 パターンに収束している。「ライセンスは?」「<競合> との違いは?」「ベンチマークは?」「商用利用は OK か?」「なぜ既存の X を fork しなかったのか?」 — これらの返答を 3-4 行で書き溜めておき、当日はコピペで貼れる状態にしておく
- 作者の第 1 コメント原稿: 投稿者本人による最初のコメントは reach に効く。「なぜ作ったか / 既存ツールでは何が足りなかったか / 何が未対応か」を 5-7 行で正直に書く。とくに「未対応」を明示すると初動の信頼が上がると感じている
5 つのうち、私が gpdf 公開準備で過小評価していたのは比較表だった。最初は README の文中に競合への言及を埋めていたが、表に切り出した瞬間に明らかに読みやすくなった。文章で書く判断と、表で書く判断は別物だと、その時に学んだ。
当日: 投稿時刻と最初の 90 分
投稿時刻は 米東海岸の平日 8:00-10:00 (JST 21:00-23:00) が一般的に厚いとされている。私もこの帯を狙う予定だ。HN のフロントページ滞留時間がこの時間帯に始まるトラフィックで大きく決まるためだ。
ただし時刻は決定的ではない。同じ時刻でも、その日の他の投稿の競合次第で初動はぶれる。私の感触だと「時刻 1 割、タイトル 3 割、最初の 30 秒で見える素材 3 割、初動コメント 3 割」という割合だと思っている。時刻にこだわるより、上の 5 素材を厚くする方が期待値は高い。
最初の 90 分の動作はこう決めている。
- 投稿直後 (0-5 分): 自分の第 1 コメントを投稿。1 番手にしておくと、その後のコメント階層の起点になる
- 5-30 分: 上位コメントが付き始める。FAQ から該当パターンをコピペで返信。新しい質問パターンが出てきたら手書きで返す
- 30-90 分: フロントページに乗るかが見える時間帯。乗っていれば issue / discussions 経由の問い合わせも入り始めるので、GitHub の通知窓口を 1 個に絞って置いておく
この 90 分を本業のミーティングと被せるとほぼ詰む。私は投稿日を「夜会議のない曜日」に固定する予定だ。本業のスケジュールを動かす方が、Show HN 当日にコメント遅延するより損が小さいと判断している。
関連コミュニティへの渡し方
Show HN だけで完結させない。HN に乗らなかったときの保険として、関連コミュニティへの渡し方も前日までに用意する。私の場合の選択肢はこうだ。
| コミュニティ | 投稿形式 | 渡すタイミング |
|---|---|---|
| Hacker News (Show HN) | 本命のリンク投稿 | 平日朝の米東海岸帯 |
| Lobsters | リンク投稿 | HN と同日、2-3 時間後 |
| reddit r/golang | self-post で背景説明 | HN と別日 (reddit は週末が厚い) |
| Go Weekly / Awesome Go | PR / 投稿フォーム | リリース週中 |
| Twitter/X | 個人アカウントから紹介 | 投稿直後 |
同日に全部に流すと「マーケティング感」が強く出てネガティブに見られる場合がある。HN を本命にして、Lobsters を当日別タイミング、reddit は別日、というのが私の運用だ。
ここで 1 つ重要なのは「Show HN で外したから他に流す」のではなく、最初から Show HN は数あるチャネルの 1 つに過ぎない と捉えることだ。HN フロントページに残らなくても、Lobsters と r/golang で個別に 50 stars 集まるなら、結果としてはほぼ同じだ。チャネルをポートフォリオで持つ方が、兼業の精神衛生にも良いと感じている。
質問への応答
「Show HN で 100 stars 取った後の話は?」
本稿では扱わない。「投稿前の準備」に絞っている。投稿後の継続運用と実数の話は、4 ヶ月経過後に別記事で出す予定だ。
「タイトルに価格や割引を入れていいか?」
Show HN のガイドラインで価格訴求が明示的に禁止されているわけではないが、コミュニティの嗅覚として強く嫌われる。私は機能 benefit のみに留めている。商用化の文脈は LP 側に逃がす。
「コメントで自社プロダクト名を連投していいか?」
これも嫌われる。FAQ 返信で自分のプロダクト名を出すのは自然だが、別の人の質問に「ぜひ
「Show HN は古いのでは?」
代替の登場 (Product Hunt や独自 Discord) はあるが、技術プロダクトの一次評価コミュニティとしての HN の位置はまだ動いていないと感じている。少なくとも Go の OSS / 開発者ツール領域では、HN フロントページに乗ることの価値は他チャネルでは置き換えにくい。
次のステップ
ここまでが 2026 年 5 月時点で組んでいる Show HN 準備リストだ。gpdf 本体・gpdf-api・gsql の広報で実際に使い、外した項目があれば追記する。
- 検証段階の話: リリース前のバリデーション戦略
- 並走の運営構造: nadai ecosystem: 複数 micro SaaS を一人で運営する戦略
- 時間設計: 受託テックリード兼 OSS 開発者の時間設計