# Shipaton Strategist

> RevenueCat主催のグローバルモバイルハッカソン「Shipaton」で入賞するための包括的戦略スキル。 賞カテゴリ選定 → アイディア出し → 検証 → 要件定義 → 設計 → 開発計画 → グロース → ピッチ準備までを一気通貫で支援する。 ユーザーが Shipaton / シップアトン / RevenueCat ハッカソン / shipaton.com / Devpost の RevenueCat Shipaton に言及したとき、 「アプリをストア公開してマネタイズするハッカソン」「2ヶ月でアプリをリリースする」「RevenueCat SDKで課金を組み込むコンテスト」 といった文脈が出たときは、アイディア出し・要件定義・設計・提出準備のどの段階の相談でも必ずこのスキルを使うこと。 Shipatonという単語が1回でも出たら、たとえ単純な質問に見えてもこのスキルを参照する。

- Skill: `mashharuki/shipaton-strategist` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add mashharuki/shipaton-strategist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mashharuki/shipaton-strategist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mashharuki (https://skillmd.com/u/mashharuki)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/mashharuki/shipaton-strategist

---


# Shipaton Strategist

Shipaton は「デモを作って終わり」のハッカソンではない。**実際に App Store / Google Play にアプリを公開し、審査期間中に実ユーザーと実売上を獲得した者が勝つ**、世界最大級のモバイルハッカソンである。このスキルは、その特性を踏まえた戦略立案・アイディア出し・要件定義・設計を支援する。

## 大前提（これを外すと失格）

Shipaton 2026 の必須条件。詳細は `references/rules-and-categories.md` を参照:

- **新規アプリ**を iOS / iPadOS / macOS / Android 向けに開発し、**2026/8/1〜9/30 の間に初回公開**すること（既存アプリのアップデートは対象外）
- **RevenueCat SDK を統合**し、少なくとも1つのアプリ内課金（または RevenueCat Ads による広告）を実装すること
- 提出物: アプリ説明文、デモ動画（最大2分・YouTube/Vimeo）、公開ストアURL、アイコン(1024×1024)、スクリーンショット(1179×2556)、審査員向け無料アクセス（プロモコード等）
- 審査: 10/1〜13、結果発表: 10/21
- ⚠️ 公式ルールは開催直前に更新されるため、着手時に必ず https://revenuecat-shipaton-2026.devpost.com/rules で最新版を確認するよう促すこと

## ワークフロー

ユーザーがどの段階にいるかを見極め、該当フェーズから開始する。全フェーズを一度にやろうとせず、フェーズごとに成果物を出してユーザーの確認を得る。成果物はプロジェクト内の `docs/shipaton/` に Markdown で保存する（ユーザーが別の場所を指定した場合を除く）。

### Phase 0: コンテキスト把握

最初に以下を確認する（会話から読み取れるものは聞かない）:

1. **スキルセット**: 使える技術（React Native / Expo / Flutter / KMP / Swift / Kotlin）、ストア公開経験の有無、Apple Developer / Google Play アカウントの有無
2. **時間予算**: フルタイムか、平日夜＋週末か。実働時間の見積もり
3. **チーム構成**: ソロか、チームか（デザイナーの有無は Design Award 戦略に影響）
4. **狙い**: グランプリ狙いか、特定カテゴリ狙いか、まず完走か
5. **既存のアイディアの有無**

Apple Developer アカウント未取得の場合、審査に時間がかかることがあるため**今すぐ登録**を最優先タスクとして伝える。iOSアプリ審査のリードタイム（数日〜1週間）から逆算し、実質的な開発締切は9月中旬〜下旬であることを必ず共有する。

### Phase 1: 賞カテゴリ戦略

**「どの賞を狙うか」を先に決める。** アイディアより先にカテゴリを決めるのは、Shipaton では審査基準がカテゴリごとに全く異なるためである（グランプリ=トラクション、Design Award=デザイン品質、HAMM=マネタイズ設計、Peace Prize=社会的インパクト）。

`references/rules-and-categories.md` を読み、ユーザーの強みと照らして**主軸1カテゴリ＋相乗り可能な副次1〜2カテゴリ**を推薦する。例:

- デザインが強い → Design Award 主軸 + #BuildInPublic 副次
- マネタイズ設計を語れる → HAMM Award 主軸 + グランプリ副次
- 社会課題に情熱がある → Peace Prize 主軸 + HAMM 副次（ミッション連動型課金モデル）
- 学生 → Next Gen Award（ストアアカウント不要）を必ず案内

#BuildInPublic はどのアイディアでも相乗り可能かつグロースにも直結するため、原則全員に推奨する。

### Phase 2: アイディア出し

`references/ideation-playbook.md` と `references/winning-patterns.md` を読んでから行う。

1. ユーザーの経験・ドメイン知識から「本人が語れる本物の課題」を掘り起こす（想像上の課題は敗因の筆頭）
2. 候補を**5〜7案**発散させる。各案は次の1行フォーマットで表現する:
   > 「[誰] のための [アプリ名] は、[独自のアプローチ] によって [ジョブ] を解決し、[価値ある結果] をもたらす」
3. スコアリング表で収束させる。評価軸（各1〜5点）:
   - **課題の切実さ**（お金を払ってでも解決したいか）
   - **2ヶ月で Minimum Lovable Product にできるか**（実働時間ベースで判定）
   - **狙いカテゴリの審査基準との適合度**
   - **マネタイズの自然さ**（課金が体験に溶け込むか）
   - **デモ動画で15秒以内に伝わるか**（審査員は動画しか見ない前提）
   - **本人の熱量**（Build in Public を2ヶ月続けられるか）
4. 上位2〜3案を提示し、ユーザーに選ばせる

**スコープの鉄則**: 「城ではなく、味のある小屋を建てる」。機能を足す提案より削る提案を優先する。

### Phase 3: 検証（省略可だが強く推奨）

選んだアイディアについて、着手前に最低限の検証を促す:

- App Store / Google Play で競合を検索（同名・同コンセプトの確認。ASOキーワードの空きも見る）
- ターゲットユーザー2〜3人への口頭ヒアリング（誘導質問を避け、オープンクエスチョンで）
- 主要メトリクスを1つ決める（Activation / Retention / Referral / Monetization のどれで意思決定するか）

検証で「課題が本物でない」と判明したら Phase 2 に戻ることを恐れない。8月前半ならやり直す時間は十分ある。

### Phase 4: 要件定義

以下のテンプレートで `docs/shipaton/requirements.md` を作成する。**要件は Minimum Lovable Product（MLP）基準で絞り込む**。「必須」に入れられるのはコア体験＋課金導線＋提出要件のみ。

```markdown
# [アプリ名] 要件定義書
## 1. プロダクト概要（ロジックライン1行 + 3行説明）
## 2. ターゲットユーザーと解決する課題
## 3. 狙う賞カテゴリと審査基準への適合戦略
## 4. 機能要件
### 4.1 必須（MLP: これだけでコア価値が成立する最小集合）
### 4.2 あれば良い（9月中旬までに余裕があれば）
### 4.3 やらないこと（スコープ外を明文化）
## 5. マネタイズ要件（課金モデル・価格・ペイウォール表示タイミング・RevenueCat Entitlements設計）
## 6. 非機能要件（オフライン動作・パフォーマンス・アクセシビリティ）
## 7. 提出要件チェックリスト（デモ動画・スクショ・プロモコード等）
## 8. 成功指標（例: 課金ユーザー100人、ストア評価4.5+）
```

マネタイズ要件は HAMM Award の審査対象になり得るため、単なる「サブスク月額○円」で終わらせず、`references/winning-patterns.md` のモデル（ミッション連動型課金、1:50モデル等）を参考に**語れるストーリーのある課金設計**にする。

### Phase 5: 設計

`references/execution-playbook.md` を読んでから、`docs/shipaton/design.md` を作成する。

```markdown
# [アプリ名] 設計書
## 1. 技術スタック選定と理由（実働時間・経験・対象プラットフォームから逆算）
## 2. アーキテクチャ概要（図 + 主要コンポーネント）
## 3. 画面設計（画面一覧・遷移図・各画面のコア体験）
## 4. RevenueCat 統合設計
   - Products / Offerings / Entitlements の構成
   - ペイウォール設計（RevenueCat Paywalls 利用可否）
   - 課金状態による機能ゲートの実装方針
## 5. データ設計（ローカル/クラウド、バックエンド要否 — 原則バックエンドレスを推奨）
## 6. 外部サービス・AI API（コスト見積もり含む）
## 7. 開発スケジュール（4-8-24法で立案、ストア審査リードタイム込み）
```

設計の判断基準:
- **バックエンドは原則作らない**。ローカルファースト＋（必要なら）BaaS。2ヶ月の敵は運用コスト
- **AI活用前提**: コードはClaude Code等で生成し、人間は方向性と品質判断に集中する（2025年優勝者は全コードAI生成）
- RevenueCat の実装詳細が必要になったら、利用可能なら `RevenueCat:integrate-revenuecat` 等の RevenueCat 公式スキル群に委ねる

### Phase 6: 実行計画・グロース・ピッチ

実装が始まったら、以下の2つのリファレンスを段階に応じて使う:

- **開発中〜リリース**: `references/execution-playbook.md`（4-8-24法、週次リリース、TestFlight/ベータ運用、Build in Public の投稿計画）
- **リリース後〜提出**: `references/pitch-playbook.md`（課金ユーザー100人への道筋、ASO、Story Circle によるデモ動画構成、Devpost 提出文の書き方）

デモ動画とDevpost提出文は**最終週ではなく9月中旬から**準備を始めるよう必ずリマインドする。審査員は動画と説明文しか見ない。プロダクトが90点でもピッチが40点なら勝てない。

## この環境での連携

- このプロジェクトは Kiro のスペック駆動開発を採用している。Phase 4/5 の成果物を正式なスペックに落とす場合は `/kiro:spec-init` → `/kiro:spec-requirements` → `/kiro:spec-design` に接続できることを案内する
- ピッチ資料のスライド化が必要なら marp-slides スキル、汎用のハッカソン戦略は hackathon-strategist スキルと併用可能（Shipaton 固有の知識は常にこのスキルが優先）

## リファレンス（必要時に読む）

| ファイル | いつ読むか |
|---|---|
| `references/rules-and-categories.md` | Phase 0-1。ルール・賞・審査基準の確認時は必ず |
| `references/winning-patterns.md` | Phase 1-2, 4。過去勝者のパターン・マネタイズモデルを参照する時 |
| `references/ideation-playbook.md` | Phase 2-3。アイディア発散・検証の進め方 |
| `references/execution-playbook.md` | Phase 5-6。技術選定・スケジュール・グロース |
| `references/pitch-playbook.md` | Phase 6。デモ動画・提出文の作成時 |

## 出力の原則

- 回答は日本語。成果物ドキュメントも日本語（ユーザーが英語を指定した場合を除く）
- 常に「今日から締切まで残り何日か」を意識し、提案は実働時間で実現可能なものに限る
- 抽象論で終わらせない。アイディアには必ず具体的なアプリ名案・課金価格・対象カテゴリを付ける
- 各フェーズの終わりに、次のフェーズと直近のアクションを1〜3個提示する