はじめに
2ヶ月、エンジニア2人（ジュニア寄り）という条件で、あるプロジェクトのPoCをスタートしました。
機能数こそ絞られていましたが、そのまま走り出すと以下のような実装以外のオーバーヘッドで時間を溶かしてしまう懸念がありました。
- 設計の迷走：「これ、どう実装するのが正解ですかね？」という迷い
- ツール選定の沼：技術選定に時間をかけすぎてプロトタイプができない
- AIとの協働ルールの欠如：AIエージェントへの指示が属人化し、コード品質がバラバラになる
そこで、プロジェクトの最初の2日間を「迷うポイントを物理的に潰す基盤づくり」に捧げました。
方針：「GitHubとJiraを見れば、すべてが揃っている」
目指したのは、開発者が「次に何をすればいいか」を1秒も迷わない状態です。
- 設計・意思決定：すべてGitHubリポジトリ（ADR）に集約
- タスク・進捗：Jiraに詳細なチケットとして展開
- AIルール：CLAUDE.md でAIエージェントの挙動を縛る
Jiraを選択したのは、Claude CodeからAtlassian MCP経由でチケット操作が可能になり、ブラウザを開かずにタスクの更新・確認ができる環境を構築するためです。
最初の2日でやったこと
1日目：プロジェクトの基盤を作る
- ブランチ戦略：GitHub Flowの明文化
- PRルール：AI（CodeRabbit）＋人間によるレビューの必須化
- AIへの指示（CLAUDE.md）：プロジェクト固有の命名規則やディレクトリ構成を記録
- 技術選定（ADR）：「なぜそれを選び、何を見送ったか」の記録
2日目：設計を構築する
- 設計ドキュメント作成：状態遷移図やER図を docs/ 配下に配置
- Jira連携：Claude Codeから直接叩けるようタスクを細分化
- MTGの仕組み化：質問リストと議事録をリポジトリで管理
- AI作業フローの標準化（Superpowers）
Superpowersとは？
AIエージェントに「思考(brainstorming) → 計画(plan) → 実行(execute) → 検証(verify)」という開発規律を強制するフレームワーク。バイブコーディングで起きがちな「思いつき実装」問題を解消します。
ADR（Architecture Decision Record）
ADRでは結論だけでなく、以下の2点を重視しました。
- なぜそれを選んだか
- 何を選ばなかったか（比較対象）
開発中、ジュニアメンバーから「なぜDynamoDBなんですか？ RDBの方が楽では？」という疑問が出た時も、コミュニケーションコストを最小限に抑えられたと感じています。
ツールスタック
| ツール | 用途 | 補足 |
|---|---|---|
| Claude Code | AIコーディング | Proプランを使用 |
| Superpowers | 開発フロー標準化 | Claude Codeのスキルとして導入 |
| Jira (Atlassian MCP) | タスク管理 | Claudeから直接チケット操作 |
| CodeRabbit | AIレビュー | .coderabbit.yaml でルール管理 |
| v0 | UIプロトタイプ | 捨てコード前提で高速にイメージ合意 |
| Chrome DevTools MCP | ブラウザ操作 | E2Eテストや動作確認をAIが代行 |
実際に直面した「想定外」の課題
1. Claude Code（Pro）の利用量上限
Superpowersでのステップを丁寧に踏ませた結果、トークン消費が激しく、想定より早く上限に達しました。
利用量上限を事前に深く調査して、Maxプランにしても良かったかもしれません。
2. IAM権限のボトルネック
AWS CDKでの開発中、IAM権限不足でデプロイが止まる場面がありました。都度リクエストと付与待ちの時間は大きなロスでした。
あらかじめ作業範囲を予測し、開発者用パワーユーザー権限を事前に合意して付与しておくべきだったのが反省点です。
投資した「2日間」の結果
実装フェーズに入ってからのスピードは早かったと思います。
- 1日目：フロントエンド構築（Next.js / Tailwind）
- 2日目：バックエンド構築（Lambda + API Gateway）
- 3日目：インフラ（CDK）＋ CI/CD構築
迷う時間が削ぎ落とされているため、メンバーは実装だけに集中できました。
まとめ
短期間・少人数のプロジェクトほど、決めるべきことを後回しにすると、コミュニケーションコストで破綻します。
設計そのものよりも、迷いを少なくするための仕組みに最初の2日を投資したことで、ジュニア中心のチームでも最短距離でPoCを形にできました。