何をつくったのか

本日、このコラムサイト自体を30分で構築し、本番公開した。

  • コンテンツマーケティング用のコラムサイト
  • LP（24h-sprint.com）と世界観を統一したデザイン
  • 記事3本を含む状態で column.24h-sprint.com に公開
  • LPとの双方向導線も設置済み

これは「事業起動スプリント」が提唱する一気通貫の高速開発を、私たち自身が実践した記録だ。

タイムライン

経過時間工程内容
0:00技術選定3つの選択肢（Astro+microCMS / Notion+Next.js / Astro+Markdown）を比較。最短のCを選択
0:03プロジェクト初期化Astroプロジェクト作成、package.json、tsconfig、content.config.ts
0:05デザイン設計LP のCSS変数・フォント・カラーをそのまま流用。Base.astro に全スタイル集約
0:10ページ実装トップページ（記事一覧）、記事詳細ページ（動的ルーティング）
0:15コンテンツ作成サンプル記事3本をMarkdownで執筆
0:18ビルド確認4ページ生成、ビルド時間797ms
0:20GitHub + Vercelリポジトリ作成、Push、本番デプロイ
0:25カスタムドメインcolumn.24h-sprint.com を設定、SSL自動発行
0:28LP連携LPにヘッダーナビ + コラムプレビューセクション追加、再デプロイ
0:30完了全ページ公開、双方向導線設置済み

なぜ30分で終わるのか

「速くつくった」のではない。遅くなる要因を最初から排除したのだ。

1. 意思決定を最初に終わらせる

3つの技術選択肢を並べ、「最短」という明確な基準で即決した。

多くのプロジェクトが遅延する最大の原因は、開発の遅さではなく意思決定の遅さだ。「もう少し調べてから」「他にも選択肢があるかも」——この逡巡が、数時間、数日を奪う。

完璧な選択より、明確な基準による即断のほうが価値がある。

今回の基準は「最短で本番公開できること」の1点。microCMSは将来的に優れているが、外部サービス登録が必要。Notionは便利だが、API設定に時間がかかる。Markdownは今すぐ書ける。判断に30秒もかからなかった。

2. 既存資産を最大限に流用する

ゼロからデザインしていない。LPの CSS変数、フォント設定、カラースキーム、アニメーションをそのままコピーした。

--black: #0a0a0a
--accent: #c8a96e
--white: #f8f5f0
font-family: 'Noto Serif JP', 'Noto Sans JP'

この6行が、デザインの一貫性とスピードの両方を担保している。新しいデザインを考える時間はゼロ。ブランドの統一感は100%。

3. スコープを絞り切る

初回リリースに含めたのは以下だけだ。

  • トップページ（記事一覧）
  • 記事詳細ページ
  • LP導線（CTA）
  • サンプル記事3本

含めなかったもの：

  • カテゴリーページ
  • 検索機能
  • ページネーション
  • OGP画像自動生成
  • SNSシェアボタン
  • コメント機能

これらは将来必要になるかもしれないが、今日必要ではない。今日必要なのは「コラムサイトが存在し、記事が読め、LPへ導線があること」だけだ。

4. 工程を分断しない

通常のプロジェクトでは、こうなる。

  1. 企画会議で方針決定（1日）
  2. デザイナーがワイヤーフレーム作成（2日）
  3. エンジニアが実装（3日）
  4. テスト・修正（1日）
  5. インフラチームがデプロイ設定（1日）

合計8日。5人が関わり、4回の引き継ぎが発生する。

今回は1人が、設計→デザイン→実装→デプロイを一気通貫で実行した。引き継ぎゼロ。会議ゼロ。待ち時間ゼロ。

これが「一気通貫」の威力だ。

技術選定の考え方

なぜ Astro か

Astro は「コンテンツサイトに最適化された」フレームワークだ。

  • ゼロJavaScript: デフォルトでクライアントにJSを送らない。表示が爆速
  • Markdownネイティブ: Content Collections APIで型安全にMarkdownを扱える
  • 静的生成: ビルド時にHTMLを生成。サーバー不要、CDNから配信
  • Vercel統合: git push → 自動ビルド → 自動デプロイ

React（Next.js）を選ばなかった理由は単純で、コラムサイトにインタラクティブなUIは不要だからだ。必要ないものを入れない。それがスピードの源泉になる。

なぜ Markdown か

CMS（microCMS等）を使わなかった理由は3つ。

  1. 外部依存ゼロ: サービス登録、API設定、Webhook設定が不要
  2. Git管理: 記事もコードも同じリポジトリで管理。バージョン管理が自然にできる
  3. 移行容易性: 将来CMSに移行する場合も、MarkdownファイルはそのままImport可能

「非エンジニアが記事を書けない」という欠点はあるが、それは運用が軌道に乗ってから解決すればいい。

アップグレードパス

この構成の最大の利点は、段階的にスケールできることだ。

Phase 1（今）: Astro + Markdown
  → 記事はGit管理、技術者が更新

Phase 2（記事が増えたら）: Astro + microCMS
  → Markdownをmicroに移行、ブラウザから記事編集可能に
  → Astroのページ・デザインはそのまま流用

Phase 3（トラフィックが増えたら）: Astro + microCMS + ISR
  → Vercelの ISR で差分ビルド、大量記事でもビルド時間を抑制

フレームワーク（Astro）を変えずにバックエンドだけ差し替えられる。最初からこのアップグレードパスを想定して設計している。

この開発から学べること

速さは「能力」ではなく「構造」

30分で完成したのは、タイピングが速いからではない。

  • 判断基準が明確だった
  • 既存資産を流用した
  • スコープを絞り切った
  • 工程を分断しなかった

この4つの構造が、速さを生んだ。逆に言えば、この構造がなければ、同じ成果物に1週間かかっても不思議ではない。

「あとで」は永遠に来ない

「コラムサイトをいつかつくろう」と思っていたら、永遠にできない。今日、不完全でも公開する。記事は3本でいい。デザインは完璧でなくていい。

大事なのは存在することだ。存在しないものは改善できない。存在するものは、いつでも改善できる。

事業起動スプリントが提供する価値

私たちがクライアントに提供しているのは、まさにこの体験だ。

曖昧なアイデアを、翌日に市場に出す。完璧を待たない。まず出す。そこからデータで判断する。

このコラムサイト自体が、そのアプローチの生きた証明になっている。