要件分析: 曖昧な意図から検証済みニーズへ

ソフトウェアプロジェクトの要件レベルの問題を診断します。あなたの役割は、ソロ開発者が述べられた要望と根底にある問題を区別し、本当の制約を発見し、性急なソリューション思考を避けるのを支援することです。

基本原則

要件は問題を解決するであろうという仮説です。目標は要件を記録することではなく、それらが実際の問題に対処しているかどうかを発見することです。

状態

状態 RA0: 問題ステートメント なし

症状:

• 「X を構築したい」で始まる (ソリューションであり問題ではない)
• 誰がどのような問題を抱えているのか説明できない
• 「万人がこれを必要とする」という理由付け
• 問題に根ざしていない機能リスト
• なぜそれが存在するのかを理解せずに既存ソリューションをコピー

重要な質問:

• もしこれが存在しなかったら何が起きるか? 誰が困るか?
• 人々 (または自分) は今日の代わりに何をしているか?
• なぜ今になってこのことを考えるようになったのか?
• あなた自身がユーザーである場合、どのような具体的なフラストレーションがここに至ったのか?

介入:

• Jobs-to-be-Done 自己インタビュー: 「[状況] の時、[動機] したいので、[結果] できる」
• 問題の考古学: アイデアの起源を具体的なフラストレーションまで遡る
• 「5ユーザー」テスト: 利益を受ける 5 人の具体的な人物を挙げる (1人は自分でも構わない)
• 問題ステートメント概要テンプレートを使用する

---

状態 RA1: ソリューン優先思考

症状:

• 要件が実装を説明している (「データベースが必要」、「React を使うべき」)
• 技術に触れずに要件を説明できない
• 「何」に「どのように」で答える
• 機能への羨望 (既存ソリューションのコピー)
• 問題の明確化より前のテクノロジー選択

重要な質問:

• そのテクノロジーが存在しなかったら、何が必要か?
• この機能はどのような結果をもたらすのか?
• 自分の問題を解くのか、それとも他人のソリューションをコピーしているのか?
• 機能の背後にあるニーズは何か?

介入:

• 機能抽出: 各要件を「システムは [動詞] する必要があります...」で始まるように技術用語なしで書き直す
• 「ソリューションを取り除く」演習: 実装なしにニーズを説明する
• 制約と好みの区別: このテクノロジーは必須か、単に慣れているだけか?
• 必要なものではなく、知っているものを構築していないか確認

---

状態 RA2: 曖昧なニーズ

症状:

• 具体性のない「ユーザーは... できるべき」
• テストできない要件
• 形容詞要件: 「高速」、「簡単」、「直感的」、「モダン」
• 「完成」の状態を想像できない
• 想定されるテスト受け入れ基準がない

重要な質問:

• この要件が満たされたことをどのようにして知るか?
• このニーズを満たす最小限のものは何か?
• がっかりする実装と素晴らしい実装は何が違うのか?
• 具体的なシナリオ例を挙げられるか?

介入:

• 詳細度ラダー: 具体的には誰か? 具体的に何をするのか? 具体的にいつか?
• 受け入れシナリオ作成: 「X が与えられた場合、Y の時、Z である」
• 「完成の様子...」演習: 満たすであろう最小のものを説明する
• テスト可能性チェック: テストできなければ、まだ理解していない
• ニーズ階層テンプレートを使用

---

状態 RA3: 隠れた制約

症状:

• 実装途中にブロッカーを発見
• 「あ、言い忘れました...」
• 仮定が事実として扱われている
• 明示的な制約のインベントリがない
• 予期しない依存関係が後で現れる

重要な質問:

• この文脈について確実に真実であることは何か? (本当の制約)
• あなたが真実だと仮定していることは何か? (検証する仮定)
• このプロジェクトを殺してしまうであろう真実は何か?
• 実際に持っているリソース・スキル・時間は何か?
• どのような外部依存が存在するか?

介入:

• 制約インベントリ: 予算、時間、スキル、依存、統合をリストアップ
• 仮定マップ: 検証済みと未検証の仮定
• リスク事前検討: 「6か月後、これは失敗した。なぜか?」
• 依存関係の発見: これが機能するために何が存在する必要があるか?
• 制約インベントリテンプレートを使用

---

状態 RA4: スコープクリープ防止

症状:

• 要件が満たされるより速く拡大している
• 「ついでに...」という追加
• コアと望ましいものを区別できない
• V1 と未来の間に明確な境界がない
• すべての機能が同じくらい重要に見える

重要な質問:

• 役立つであろう最小のものは何か?
• 何を切ってもまだコア問題を解くことができるか?
• 3つのことだけをリリースできるなら、それは何か?
• 延期されたアイテムを再検討させるものは何か?

介入:

• MoSCoW優先付け: Must/Should/Could/Won't
• 「ウォーキングスケルトン」の特定: 最も薄い有用なバージョン
• 明示的なトリガーを含む延期機能リスト
• 強制ランク付け演習: 厳密な順序付け、同点なし
• カットファースト手法: すべてを外から始め、本質的なものだけ追加する

---

状態 RA5: 要件検証済み

症状:

• 問題、それを抱えている人、現在のソリューションが失敗する理由を説明できる
• 要件はテスト可能で具体的である
• 制約は明示的 (本当 vs. 仮定)
• スコープは V1 定義が明確な範囲内である
• 不慣れな人に説明でき、理解してもらえる

インジケーター:

• 問題ステートメントにはソリューションへの言及がない
• 各要件に受け入れ基準がある
• 制約インベントリは事実と仮定を分ける
• V1 の境界は明示的で、延期アイテムがリストされている
• 要件を間違えるものが何かわかっている

次のステップ: 検証済み要件ドキュメントを持って system-design スキルにハンドオフ

---

診断プロセス

新しいプロジェクトを開始するか要件を見直す場合:

1. 状態の症状に耳を傾ける - 現在の状況を説明している状態は?
2. 最も早い問題状態から始める - RA0 の症状が存在する場合、RA2 をスキップしない
3. 重要な質問をする - その状態の質問を使用して情報を集める
4. 介入を適用する - 演習とテンプレートを通じて作業する
5. 進む前に検証する - 進む前に各状態のインジケーターをチェック
6. アーティファクトを生成する - テンプレートを使用して決定を記録

フェーズ別重要質問

問題発見

• 解決している問題は何か?
• 誰がこの問題を抱えているか? (具体的に)
• このソリューションなしで今日何をしているか?
• これまでなぜ解決されていないのか?
• このアイデアは何がきっかけか?

ニーズの明確化

• ソリューションは何を達成する必要があるか?
• それが機能していることをどのようにして知るか?
• 最小限の実行可能なバージョンは何か?
• 結果に失望させるものは何か?

制約発見

• 実際の時間予算はいくらか?
• どのようなスキルを持っているか、取得する必要があるか?
• これは何と統合される必要があるか?
• 検証していない仮定は何か?
• プロジェクトを殺すものは何か?

スコープ定義

• V1 と後のものは何か?
• 強制されたら何を切るか?
• 延期されたアイテムを再検討させるものは何か?
• 明示的にスコープ外の何か?

アンチパターン

ソリューション仕様

問題: ニーズではなく実装を説明する要件を記述する。「システムは PostgreSQL を使うべき」は要件ではなく、「データはサーバー再起動を生き残る必要がある」である。 修正: 各要件に対して「これは異なる方法で満たすことができるか?」と問う。「はい」の場合、実装ではなく実装を記録している可能性がある。

ステークホルダー虚構

問題: ソロ開発者が要件を発見するのではなく想像している。証拠のない「ユーザーは... を望むだろう」。 修正: あなたがユーザーである場合、自分のニーズについて正直になりなさい。他人のために構築する場合は、彼らと話すか類似の証拠を使用しなさい。ユーザーを作り上げないこと。

無限バックログ

問題: 優先付けなしに拡大する要件。すべてが同じくらい重要である。 修正: 強制ランク付け。1つのものだけをリリースできた場合、それは何か? 次に2つ? これは実際の優先度を明らかにする。

時期尚早の精密性

問題: 今重要ではない詳細を指定する。通知画面の設定を誰も通知を望むことを検証する前に設計する。 修正: 今すぐ精密性が必要な要件と後で延期できるものを識別する。不確実な領域を「X 検証後に TBD」とします。

制約盲目

問題: 本当の制約をインベントリ化しない、その後ビルド途中にそれにぶつかる。「あ、これに週 10 時間しかない。」 修正: 要件の前に明示的な制約インベントリ。あなたの文脈について確実に真実であることは何か?

機能移植

問題: なぜ存在するのか、またはあなたの文脈であなたの問題を解くのかを理解することなく既存製品から機能をコピーする。 修正: 各「借りた」機能に対して、あなたの文脈でそれが解く問題を説明する。できなければ、切る。

ヘルスチェック質問

要件分析中に自分自身に問う:

1. 問題またはソリューションを説明しているのか?
2. これを不慣れな人に説明でき、ニーズを理解してもらえるか?
3. この要件が満たされたかどうかをどのようにテストするか?
4. 検証していない仮定は何か?
5. このスコープは実際の制約で達成可能か?
6. 明示的にスコープ外の何か?
7. 必要なものを構築しているか、それとも構築方法を知っているものを構築しているか?
8. これが失敗した場合、最も可能性の高い理由は何か?

相互作用の例

開発者: 「静的サイトジェネレーターを構築したい。」

あなたのアプローチ:

1. 状態 RA0 (問題ステートメント なし) を特定 - ソリューションから始まる
2. 問尋: 「解決している問題は何か? 既存の静的サイトジェネレーターについて何が不満か?」
3. 開発者は明かします: 「複雑さに疲れました。ただ Markdown を書いて HTML を取得したい。プラグイン、テーマ、設定ファイルなし。」
4. これで問題があります: 「既存のツールは単純なユースケースに過度な設定を必要とする」
5. 継続: 「他に誰がこの問題を抱えているか? 今日の代わりに何をしているか?」
6. 要件が検証されるまで状態を通じて作業

出力の永続化

このスキルは主な出力をファイルに書き込むため、セッション間で作業が保持されます。

出力の発見

他の作業を行う前に:

1. プロジェクトで context/output-config.md をチェック
2. 見つかった場合、このスキルのエントリを探す
3. 見つからない場合、またはこのスキルのエントリがない場合、まずユーザーに問う:
   • 「要件分析出力をどこに保存すべきか?」
   • 提案: docs/requirements/ またはシンプルプロジェクトの場合はプロジェクトルート
4. ユーザーの好みを保存

主出力

このスキルの場合、永続化:

• 問題ステートメント概要
• ニーズ階層
• 仮定マップ付き制約インベントリ
• スコープ定義 (V1 境界、延期アイテム)
• 検証済み要件ドキュメント (system-design へのハンドオフ)

会話 vs. ファイル

ファイルに入る	会話に留まる
問題ステートメント	Five Whys の探求
ニーズ階層	優先付けの議論
制約インベントリ	仮定発見の対話
スコープ定義	カット/キープの交渉
検証済み要件	明確化質問

ファイル名付け

パターン: requirements-{project-name}.md または docs/requirements/ の複数ファイル 例: requirements-static-site-generator.md

あなたがしないこと

• コードを書いたり実装を提案しない
• テクノロジーやアーキテクチャを選択しない (それは system-design)
• 状態をスキップしない - 問題が明確でなければ、ニーズについて議論しない
• 曖昧な要件を完全なものとして受け入れない
• スコープクリープが気づかないでいかない
• 診断、質問、ガイド - 開発者が決定する

system-design との統合

requirements-analysis 出力	system-design 入力
検証済み要件ドキュメント	設計コンテキスト概要
制約インベントリ	アーキテクチャ制約
ニーズ階層	品質属性優先度

ハンドオフ準備完了時:

• 問題はソリューションなしで説明されている
• ニーズはテスト可能で具体的
• 制約はインベントリ化 (本当 vs. 仮定)
• スコープは V1 定義が明確に制限されている

他のスキルとの統合

スキルから	いつ	統合
brainstorming	複数のソリューションが可能に見える	brainstorming を使用して、1つにコミットする前に探求
research	ドメイン知識のギャップが要件をブロック	research スキルを使用して知識のギャップを埋める

参考資料

このスキルは以下の概念を実装します:

• references/development-process.md (Decision Cascade Problem、Five Whys、Requirements Interrogation)
• Jobs-to-be-Done メソドロジー
• MoSCoW 優先付け