はじめに
「Claude Codeなどのコーディングエージェントを使う際には、まず要件定義をすることが大事」ということはよく聞きますが、要件定義をちゃんとしたことのなかった私は、実際問題何を決めておく必要があるのかよく把握していませんでした。
そこで、その部分もエージェントにやってもらったらどうなるんだろうと思い、試してみると丁寧なヒアリングをもとに要件定義してくれたのでよかったよ～という備忘録もとい感想文を書きたいと思います。
筆者は新卒2年目でちゃんと要件定義をしてアプリ開発をしたことがありません。そのため、当たり前のことを書いている可能性がありますが、その点ご了承ください。
最初のプロンプト
まず、以下のようなプロンプトを投げました。
Qiita記事の投稿状況を管理するアプリを作りたい。
どんなものにするか、要件定義についてヒアリングしてくれない？
一緒に要件を決めていこう
すると、以下のような質問票を作成し、それに基づいてヒアリングを始めてくれました。
Claude Codeからの最初の質問
まず、以下のようなことを質問されました。
## 基本的な機能について
1. **主な目的は何ですか？**
- 記事の投稿スケジュール管理？
- 投稿済み記事の分析・振り返り？
- 下書きの管理？
- それとも全部？
2. **どんなデータを管理したいですか？**
- 記事のタイトル、投稿日、いいね数、ストック数？
- タグ、カテゴリ？
- 投稿予定日、下書き状態？
3. **アプリの形態はどれがお好みですか？**
- Webアプリ（ブラウザで使用）
- デスクトップアプリ
- CLI（コマンドライン）ツール
ここまでちゃんと整理してくれるとは思わず感動しました。1人で考えていたら「なんとなく管理したい」で終わっていたところを、具体的な観点で整理してくれました。
振り返ると、最初に「ヒアリングしてくれない？」と聞いたのは正解でした。 いきなり「こういうアプリを作って」と指示するのではなく、まず要件を整理してもらうアプローチにしたことで、後の展開が全然違ったと思います。
要件の深堀り
私の答えに応じて、どんどん深堀りしてくれました。
私：「全部やりたいけど、投稿済み記事の分析・振り返りは、qiita-analyzer(Claude Codeに別で作ってもらっている分析ツール)でやっているからいったんいいかな」
Claude Code：「それでは残りの2つが主な目的ですね：記事の投稿スケジュール管理、下書きの管理」
私：「カレンダーボードみたいなもので、投稿状況（予定・進捗など）を管理するイメージかな」
Claude Code：「カレンダーボード形式で視覚的に管理するイメージが浮かびました。整理すると：
- **カレンダーボード** - 投稿予定・進捗を視覚的に管理
- **下書き管理** - 記事の状態管理
- **アイデアメモ** - 思いついたネタを書きなぐる場所」
以上のように、私の曖昧な要望を具体的な機能に落とし込んでくれました。また、既存の運用パターン（毎週月曜投稿）も聞き出して、それに合わせた設計を提案してくれました。さらに、技術選定や開発方針についても、Phase 1（ローカル開発）→ Phase 2（AWS移行）という段階的なアプローチを提案してくれました。
（参考）要件定義書が埋まっていく様子
最終的に作ってくれたドキュメント
対話が進むうちに、AIが自動的に以下のドキュメントを作成してくれました。
1. 要件定義書（requirements.md）
こちらは前述の通り、ヒアリングを進めていくにつれ、どんどん要件が記載されていく様子が見られました。
### 1. 基本的な機能について
**Q: 主な目的は何ですか？**
- [x] 記事の投稿スケジュール管理
- [ ] 投稿済み記事の分析・振り返り（qiita-analyzerで実装済み）
- [x] 下書きの管理
- [x] アイデアメモ機能
**回答:**
カレンダーボード形式で投稿予定と進捗を視覚的に管理。毎週月曜投稿+アルファの運用。
2. データモデル設計（data-model.md）
ArticleStatusについてだけ少し口出ししましたが、ほぼノータッチです。
interface Article {
id: string;
title: string;
scheduledDate: string;
status: ArticleStatus;
type: ArticleType;
tags: string[];
memo: string;
// ...
}
enum ArticleStatus {
IDEA = 'idea', // 💡 アイデア段階
WRITING = 'writing', // ✏️ 執筆中
READY = 'ready', // ✅ 投稿準備完了
PUBLISHED = 'published' // 🚀 投稿済み
}
3. API仕様書（api-specification.md）
RESTful APIの仕様を、Phase 1（ローカル）とPhase 2（AWS）の両方を想定して設計してくれました。
api-specification.md
### GET /api/articles
記事一覧取得
**レスポンス**
```json
{
"articles": [
{
"id": "uuid",
"title": "記事タイトル",
"scheduledDate": "2025-06-23",
"status": "writing",
"type": "regular",
"tags": ["React", "TypeScript"],
"memo": "メモ内容",
"createdAt": "2025-06-20T10:00:00Z",
"updatedAt": "2025-06-20T10:00:00Z",
"qiitaUrl": null,
"qiitaId": null
}
]
}
4. フォルダ構成（folder-structure.md）
React + TypeScript + Viteの標準的な構成に、AWS移行を見越した構造を考えてくれました。
folder-structure.md
## プロジェクト全体構成
qiita-manager/
├── docs/ # 設計ドキュメント
│ ├── requirements.md
│ ├── data-model.md
│ ├── api-specification.md
│ └── folder-structure.md
├── frontend/ # React アプリケーション
│ ├── public/
│ ├── src/
│ ├── package.json
│ ├── vite.config.ts
│ └── tsconfig.json
├── backend/ # Phase 2: AWS Lambda用
│ ├── src/
│ ├── package.json
│ └── tsconfig.json
├── infrastructure/ # Phase 2: AWS CDK/Terraform
│ ├── cdk/ or terraform/
│ └── scripts/
└── README.md
プロジェクト環境の構築まで自動化
私：「ディレクトリは作っちゃいますか githubにリポジトリをプッシュしちゃってもいいかなと思う」
Claude Code：「いいですね！設計も固まったし、GitHubで管理しておくと安心です。」
すると以下を自動でやってくれました。
- プロジェクトディレクトリ構造を作成
- 設計ドキュメントを適切な場所に配置
- README.md、.gitignoreを作成
- Git初期化、初回コミット
- GitHub CLIでリポジトリ作成・プッシュ
使ってみて感じたこと・考えたこと
良かった点
1. 具体的な質問で思考を整理してくれる
- 1人だと「なんとなく」で済ませがちな部分を、具体的な観点で深堀りしてくれた
- 「どんなデータを管理したい？」「アプリ形態は？」など、考えるべき観点を提示
2. 既存の環境・運用を考慮してくれる
- 「qiita-analyzerで分析はやってる」→ 重複を避けた設計
- 「毎週月曜投稿」→ 定期投稿とプラスアルファを区別する設計
3. 段階的なアプローチを提案してくれる
- いきなり本格的なAWS構成ではなく、ローカル→AWSの段階的開発を提案
- 実装の優先順位も整理してくれた
4. ドキュメント化が自動
- 対話の内容を自動的に要件定義書として整理
- 技術仕様まで落とし込んでくれた
AIとの対話で何が変わったのか（思考プロセスの変化）
振り返ってみると、思考プロセス自体が根本的に変わったことに気づきました。
1人で考えるとき
- 「記事管理したいなー」→「とりあえずReactで作るか」→コード書き始める
- 頭の中で堂々巡り、「なんとなく」で妥協
- 本当に必要な機能が見えないまま進む
AIと対話するとき
- 質問されることで「なぜそれが必要なのか」を説明する必要がある
- 説明しようとすると、自分でも気づいていなかった本当のニーズが見えてくる
例えば、「毎週月曜投稿」という運用実態は、最初の段階では伝えていませんでしたが、「これも伝えておかなきゃ」といった感じで、後から伝えておくべきことに気づいて伝えることができるというのは1人ではできなかったと思います。
「壁打ち」の本当の価値（単なる質問応答を超えた部分）
今回の体験で「壁打ち」の価値は、単なる情報のやりとりではないと感じました。
本質的な価値
-
思考の外在化
- 頭の中のモヤモヤを言語化することで、自分でも整理される
- AIに説明する過程で、自分の理解が深まる
-
他者の視点の獲得
- 1人では見えない観点を提示してもらえる
- 「そういう考え方もあるのか」という気づき
-
判断を迫られる効果
- 「どちらがいいですか？」と聞かれることで、曖昧だった優先順位が明確になる
- 選択肢を提示されることで、自分の本当の希望が見える
-
段階的な深掘り
- いきなり完璧な答えを求められるのではなく、対話的に深めていける
- 途中で方向転換してもOKな安心感
最初に「ヒアリングしてくれない？」と聞いたのは我ながらよかったかなと思います。 多くの人は「○○を作って」といきなり実装を求めがちですが、まず要件整理から始めることで、AIの本当の力を引き出せたと感じています。
このような対話的な進め方は、ラバーダック・デバッグの進化系と言えるのかもしれません。
ちょっと気になったこと
体験としてはとても良いと思える部分が大半なのですが、気になる部分もありました。
それは、全く頭を使っている感がなかったことです。
AIが質問してくれ答えるだけで、気づいたらドキュメントができており、GitHubリポジトリまで完成している。「え、これでいいの？」という感じはちょっとありました。
言われるがままとは違うんですが、自分で考え抜いた感覚が薄く感じます。よく言えば「使っている脳が違う」のかもしれません。
- 従来の要件定義：論理的思考、体系的整理、1人で悩み抜く
- AIとの対話：直感的な応答、自然な会話、気づきの積み重ね
これが良いことなのか悪いことなのかは、まだ分からないです。
狙って成功できたわけではない
Claude Codeはまだ使い始めたばかりで、今回は「たまたまうまくいった」感じです。以下のようなことは伸びしろだと思います。
- もっと効率的なプロンプトがあるはず
- 他の便利な機能も知らない
- 設計パターンなども相談できそう
しかし、たまたまでもこのレベルなら十分すごいとも思いました。
まとめ
要件定義を1人でやるのが苦手な人（もしくは経験があまりない人）には、AI壁打ちは試してみる価値があると思います。
Claude Codeを完璧に使いこなせなくても、基本的な対話だけで十分価値がありました。
良かった理由
- 質問によって思考が整理される
- 既存環境を考慮した現実的な提案
- 段階的なアプローチで実現可能性が高い
- ドキュメント化が自動
- 技術選定も一緒に考えてくれる
プロンプトの振り返り
今回うまくいったプロンプトのポイントを振り返ってみました。
1. 対話的なアプローチ
- 「一緒に決めていこう」「ヒアリングしてくれない？」
- → いきなり作って！ではなく、一緒に考える姿勢で進められた
2. 既存の状況を素直に伝える
- 「qiita-analyzerでやってる」「毎週月曜投稿の習慣がある」
- → 現状を踏まえた現実的な提案をもらえた
3. 迷いを正直に表現
- 「〜かな」「〜と思うんだけど」
- → 曖昧な部分を選択肢として整理してもらえた
特に最初に「ヒアリングしてくれない？」と聞いたのが良かったのかもしれません。 いきなり実装を求めるのではなく、要件整理から始めたのが結果的に良かったような気がします。
おわりに
今回は要件定義の経験が少ない状態で、Claude Codeに「ヒアリングしてくれない？」と相談してみたところ、想像以上に丁寧で実用的な対話ができた体験を書かせていただきました。
「要件定義は難しい」「1人では進まない」と感じている方にとって、AIとの対話は一つの有効な選択肢になるのではないでしょうか。完璧に使いこなさなくても、基本的な対話だけで十分価値のある結果が得られることを実感しました。
また、今回の体験を通じて「何を聞けばいいかわからない」状態から「具体的な要件」へ導いてもらえるのは、AI活用の大きなメリットだと感じています。
まだまだClaude Codeの機能を使いこなせていない部分も多いので、今後も色々試してみたいと思います。同じような経験をされた方や、違ったアプローチで活用されている方がいらっしゃいましたら、ぜひコメントで教えてください。
ありがとうございました。
Views: 0
