superpowers を試してみた（設計編）

まさおさんのSuperPowers解説記事を読み、これは面白そうだと思って味見してみました。
という記事

インストール手順

claudecode内で

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

やってみた：Claude Codeでコミュニティ活動募集プラットフォームを設計した記録

Claude Code（Claude Opus 4.6）のブレインストーミングスキルを使い、社内向けコミュニティ活動募集Webサイトの設計から実装計画の策定までを1セッションで行った記録です。

やりたかったこと

• 部活動の活動募集のWebサイトを作りたい
• 野球部のみと限定せず、色々なコミュニティの募集掲示板としたい
• ユーザは複数の部活動・コミュニティに参加できる
• 参加している回数や種類に応じてユーザにバッジが付与される（積極的で賞、カテゴリマスターみたいな）

ブレインストーミングの流れ

/superpowers:brainstorming スキルを起動すると、Claudeが1つずつ質問を投げて要件を固めていきます。
３つくらい選択肢を用意してくれて、それに対して回答をしていく形式です。

Q1: 対象ユーザーは？

A) 特定の学校・大学の生徒向け
B) 特定の企業・組織内の社員向け ← 選択
C) 地域のコミュニティ向け
D) オープンな一般向けプラットフォーム

→ B（社内向け） を選択。ただし、いいサービスであれば外部公開も視野に入れたい。

Q2: 活動募集のイメージは？

A) イベント型（単発イベントの募集）
B) メンバー募集型（コミュニティへの加入募集）
C) 両方 ← 選択

→ C（両方） を選択。さらに「イベントに参加する＝メンバーになる（今後の募集に対して通知が飛ぶ）」という仕様を追加。

Q3: 認証方法は？

→ メール＋パスワード。将来的な外部公開に備える。

Q4: 通知手段は？

→ まだ決めない。社内にはSlack、メール、Teamsがある。

Q5: バッジ管理は？

→ 自動付与のみ。「どんなバッジがあるか皆知らない方が楽しい」ので隠し要素に。

Q6: 技術スタック

→ お任せ。ただしPythonが多少読めるのでバックエンドはPython希望。

Q7: コミュニティ作成の権限

→ 誰でも作成申請でき、管理者が承認する。

3つのアプローチ提案

Claudeから3つの技術アプローチが提示されました。

アプローチ	構成	特徴
A	FastAPI + React SPA	フロント・バック完全分離
B	FastAPI + Next.js	SSRでSEO対応
C（推奨・採用）	Django + htmx + Tailwind CSS	1プロジェクトで完結、Python only

Django + htmxを選んだ理由

1. Pythonが読めるのでコードを理解しやすい
2. Django Adminがコミュニティ承認にそのまま使える
3. 1プロジェクトで完結するためシンプルに運用できる
4. htmxで十分にインタラクティブなUIが実現可能
5. 将来のAPI化もDjango REST Framework追加で容易

設計のディスカッション

アプローチ決定後、設計をセクションごとに詰めていきました。Claudeが提案 → 自分がフィードバック → 修正、というサイクルです。

画面構成の提案

→ OK

カテゴリ → ハッシュタグに変更

当初はカテゴリ（スポーツ、音楽、技術...）で分類する設計でしたが、「カテゴリでの検索は考えておらず、自由にハッシュタグを使用して設定・検索できるようにしたい」とフィードバック。#初心者歓迎 のようなタグシステムに変更。

イベント管理者の定義

「イベントの管理者はどう定義されるか」と質問したところ、created_by（作成者）をそのまま管理者とする案が提示されました。

→ さらに「コミュニティを作成したものが退社・脱退した場合は？」と深掘りしたところ、Membershipに role（member / admin） を導入する設計に改善。

イベント承認は不要

「イベント作成時はコミュニティ管理者の承認が必要か」という問いに対して、Claudeは「不要」を推奨。

• コミュニティ作成 → 管理者承認が必要（荒れ防止）
• イベント作成 → メンバーなら自由に作成（活性化のため）

この非対称な設計は納得感がありました。

DBはMySQL

PostgreSQLが提案されましたが、MySQLに変更。Django ORMなのでDB設定変更のみで対応可能。

バッジに絵文字を使用

バッジのアイコンに絵文字を採用。🔰（はじめの一歩）、🏅（常連さん）、🔥（超アクティブ）など。

スペックレビュー

設計書を書いた後、Claudeの内部レビュー（spec-document-reviewer）が自動で走りました。
勝手に自分でレビューするのが良きです。
cc-sddだと人間がレビューするので、結局資料を読むのが大変

1回目のレビュー：Critical 4件 + Important 6件

指摘された主な問題：

• イベント定員超過時の動作が未定義 → 「定員に達しました」と表示し参加ボタン無効化
• イベント参加キャンセルフローが未定義 → 開催前ならキャンセル可能、バッジは再判定で取り消し
• Membership脱退フローが未定義 → マイページから脱退可能、最後のadminは脱退不可
• バッジ名「カテゴリマスター」が設計方針と矛盾 → 「コミュニティコレクター」に変更
• 過去イベントの扱いが未定義 → デフォルトは今後開催予定のみ表示、トグルで切替

2回目のレビュー：残り2件

• バッジ再判定のシグナルに post_delete が必要
• コミュニティ脱退時の community_count バッジの扱い

いずれも修正して最終的にレビュー通過。

実装計画

全14タスクの実装計画を策定。各タスクはTDD（テスト駆動開発）で、「テスト記述 → 失敗確認 → 実装 → テスト通過 → コミット」のサイクル。

Task	内容
1	プロジェクトセットアップ（Poetry, Django）
2	Tailwind CSS + htmx
3	CustomUserモデル
4	認証画面（ログイン/サインアップ）
5	Tagモデル + オートコンプリート
6	Communityモデル
7	Communityビュー・テンプレート・Admin
8	Eventモデル
9	Eventビュー・テンプレート
10	バッジシステム（モデル・判定エンジン・シグナル）
11	検索機能
12	トップページ
13	マイページ
14	全体テスト・最終確認

実装計画もレビューが2回走り、以下が修正されました：

• community_detail ビューの __import__ ハック → 標準importに修正
• テストのバグ（EventParticipationの直接作成とadd_participantの二重呼び出し）
• Membership作成時のバッジ判定シグナル漏れ
• event_detailビューのcontextにmembership変数が欠落
• admin昇格機能が未実装
• トップページビューがurls.pyに直書き → config/views.pyに分離

EARS形式ユースケースの作成

設計書だけでは「期待する動作が分からない。試験を書くことができない」という問題があったため、EARS（Easy Approach to Requirements Syntax）形式でユースケースを作成してもらいます。

EARSの5パターン：

パターン	構文	テストとの対応
Ubiquitous	システムは [動作] する	常に成り立つテスト
Event-driven	[イベント] のとき、システムは [動作] する	正常系テスト
State-driven	[状態] の間、システムは [動作] する	前提条件付きテスト
Optional	[条件] の場合、システムは [動作] する	条件分岐テスト
Unwanted	もし [望ましくない状況] ならば、システムは [動作] する	異常系テスト

例えば、イベント参加の要件は：

Event-driven: ログイン中のユーザーが募集中かつ開催日時前かつ定員未満のイベントの
「参加する」ボタンを押したとき、システムはEventParticipationを作成する。

Unwanted: もしイベントの定員に達している場合、システムは参加ボタンを無効化し
「定員に達しました」と表示する。参加リクエストが送信されてもEventParticipationは作成しない。

cc-sddだとこの辺は要件と一緒に作成されるけど、superpowersだと作ってくれません。
各ユースケースがテストケースに直結するため、実装時に迷いがなくなります。今後のブレインストーミングでも設計書と合わせてEARSユースケースを必ず作成する運用にしました。
ただ、エンジニアとしては「IF ～ THEN ～」「WHEN ～」の方が読みやすいかもしれません。

画面設計

画面遷移図（Mermaid）

Markdown + Mermaid記法で画面遷移図を作成しました。全体遷移に加えて、認証状態による分岐、イベント参加フロー、コミュニティ作成〜承認フロー、バッジ判定フローを個別に図示しています。

ワイヤーフレーム（ビジュアルコンパニオン）

ブレインストーミングスキルのビジュアルコンパニオン機能を使い、全8画面のHTMLモックアップをブラウザで確認しながら設計しました。

作成した画面：

1. トップページ — 主催イベント（黄色背景）、参加予定、新着イベント、人気コミュニティ
2. 検索 — コミュニティ/イベントタブ切替、タグ検索、ページネーション
3. コミュニティ詳細 — 説明、今後のイベント（max3件+もっと見る）、メンバー一覧（admin昇格ボタン）
4. イベント詳細 — イベント情報、参加者一覧（バッジアイコン+初参加ラベル）
5. マイページ — 通知、バッジ、主催イベント、参加予定、コミュニティ、イベント作成ボタン
6. コミュニティ作成申請 — フォーム（画像の選択/削除UI）
7. イベント作成 — フォーム（コミュニティ紐付き）
8. 認証 — ログイン/サインアップ並列表示

マイページの例：

成果物

1セッションで以下が生成されました：

• 設計書: docs/superpowers/specs/2026-03-19-community-hub-design.md
• EARSユースケース: docs/superpowers/specs/2026-03-19-use-cases-ears.md
• 画面遷移図: docs/superpowers/specs/2026-03-19-screen-flow.md
• 実装計画: docs/superpowers/plans/2026-03-19-community-hub-implementation.md（3400行超）
• ワイヤーフレーム: .superpowers/brainstorm/ に全8画面のHTMLモックアップ
• Gitコミット 多数

所感

• 1問1答のブレインストーミング形式が思考を整理しやすい
• 選択肢を提示してくれるので「何を決めるべきか」が明確になる
• スペックレビューの自動実行で、自分が見落としていたエッジケース（定員超過、最後のadmin脱退、バッジ取り消し）が洗い出された
• 実装計画のコードレビューでバグが事前に発見できた（__import__ ハック、テストの二重呼び出し、シグナル漏れ）
• EARS形式でユースケースを書くと、テストケースが自然に導出される。設計書だけでは曖昧だった期待動作が明文化できた
• ワイヤーフレームを1画面ずつ確認することで、見落としていた導線（マイページからのイベント作成）や表示要素（参加者のバッジ、初参加ラベル）が発見できた
• 「参加者増加の通知が欲しい」のように、画面を見て初めて気づくニーズがある。設計→ワイヤーフレーム→フィードバックのサイクルは重要
• 次のセッションでは実装計画を更新し、subagent-driven-developmentで実装を進める予定

---

新卒向け、転職希望者向けのオンライン座談会を開催しています。
また4月からAI関連の勉強会も開催しております。
ちょっとでも興味を持たれた方はぜひご応募いただけますと幸いです！
https://kusurinomadoguchi.connpass.com