requirements-analysis

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

ソフトウェアプロジェクトにおける要件レベルの問題を診断します。個人開発者が、表明された要望とその根底にある問題を区別し、実際の制約を見つけ、時期尚早に解決策を考えることを避けられるよう支援します。

中核となる原則

要件とは、問題を解決する方法についての仮説です。目標は要件を文書化することではなく、それらが実際の問題に対処しているかどうかを見極めることです。

状態

状態 RA0：問題の記述がない

兆候：

• 「Xを作りたい」というところから始める（問題ではなく、解決策）
• 誰がどのような問題を抱えているのか説明できない
• 「誰もがこれを必要としている」という考え方
• 問題との結びつきがない機能リスト
• 既存の解決策が存在する理由を理解せずに模倣する

主な質問：

• これが存在しなかったら、何が起きますか？誰が困りますか？
• 人々（またはあなた自身）は、今どのように対処していますか？
• 今このことを考え始めたきっかけは何ですか？
• あなた自身がユーザーなら、どのような具体的な不満がきっかけでしたか？

介入策：

• Jobs-to-be-Doneの自己インタビュー：「[状況]のとき、[動機]したい。それによって[成果]を得られるから」
• 問題の掘り起こし：具体的な不満にたどり着くまで、アイデアの起源をさかのぼる
• 「5人のユーザー」テスト：恩恵を受ける具体的な人を5人挙げる（自分自身を含めてもかまいません）
• Problem Statement Briefテンプレートを使用する

---

状態 RA1：解決策を先に考える

兆候：

• 実装方法を要件として記述する（「データベースが必要」「Reactを使うべき」）
• 技術に触れずに要件を説明できない
• 「何を」に対して「どのように」で答える
• 他の製品への機能羨望（既存の解決策を模倣する）
• 問題が明確になる前に技術を選ぶ

主な質問：

• その技術が存在しなかったら、何が必要ですか？
• この機能はどのような成果を生み出しますか？
• 自分の問題を解決していますか、それとも他人の解決策を模倣していますか？
• その機能の背後にあるニーズは何ですか？

介入策：

• 機能の抽出：技術用語を使わずに、各要件を「システムは[動詞]しなければならない」で書き直す
• 「解決策を取り除く」演習：実装方法を一切使わずにニーズを説明する
• 制約と好みを区別する：この技術は必須ですか、それとも単に使い慣れているだけですか？
• 必要なものではなく、知っているものを作ろうとしていないか確認する

---

状態 RA2：曖昧なニーズ

兆候：

• 「ユーザーが……できるべき」といった具体性のない記述
• テストできない要件
• 「速い」「簡単」「直感的」「モダン」といった形容詞だけの要件
• 受け入れ基準を想定できない
• 「完了」がどのような状態か説明できない

主な質問：

• この要件が満たされたことを、どうすれば確認できますか？
• このニーズを満たすための最低限は何ですか？
• 期待外れの実装と優れた実装は、それぞれどのようなものですか？
• 具体的なシナリオを挙げられますか？

介入策：

• 具体性を高める質問：具体的には誰が？具体的に何をする？具体的にはいつ？
• 受け入れシナリオを作成する：「Xという前提で、Yのとき、Zとなる」
• 「完了とは……」の演習：ニーズを満たす最小のものを説明する
• テスト可能性を確認する：テストできないなら、まだ十分に理解できていません
• Need Hierarchyテンプレートを使用する

---

状態 RA3：隠れた制約

兆候：

• 実装の途中で障害に気づく
• 「あっ、言い忘れていました……」
• 仮定を事実として扱う
• 制約の一覧が明示されていない
• 予期しない依存関係が後から見つかる

主な質問：

• この状況について、確実にわかっていることは何ですか？（実際の制約）
• 何が真実だと仮定していますか？（検証すべき仮定）
• もし真実だと判明したら、このプロジェクトが頓挫する要因は何ですか？
• 実際にどのようなリソース、スキル、時間がありますか？
• 外部依存関係には何がありますか？

介入策：

• 制約の一覧作成：予算、時間、スキル、依存関係、連携を列挙する
• 仮定のマッピング：検証済みの仮定と未検証の仮定を区別する
• リスクのプレモーテム：「6か月後、このプロジェクトは失敗しました。なぜでしょうか？」
• 依存関係の洗い出し：これが機能するには、事前に何が必要ですか？
• Constraint Inventoryテンプレートを使用する

---

状態 RA4：スコープクリープの防止

症状：

• 要件の拡大が、要件を満たすスピードを上回っている
• 「ついでに……」という追加がある
• 中核となる機能と、あれば望ましい機能を区別できない
• V1 と将来の境界が明確でない
• すべての機能が同じくらい重要に感じられる

主な質問：

• 役に立つ最小限のものは何ですか？
• 中核の問題を解決したまま、何を削れますか？
• 3 つしかリリースできないとしたら、何を選びますか？
• 先送りした項目を見直すきっかけは何ですか？

介入策：

• MoSCoW による優先順位付け：Must／Should／Could／Won't
• 「ウォーキングスケルトン」の特定：役に立つ最小限のバージョン
• 見直しの明確なきっかけを設定した、先送り機能のリスト
• 強制順位付けの演習：同順位を認めず、厳密に順序を付ける
• まず削るアプローチ：すべてを対象外として始め、不可欠なものだけを戻す

---

状態 RA5：要件の検証完了

症状：

• 問題の内容、誰がその問題を抱えているか、現在の解決策がなぜ機能しないかを説明できる
• 要件が検証可能で具体的である
• 制約（実際のものと仮定上のもの）が明示されている
• スコープが明確な V1 の定義とともに限定されている
• 初めて聞く人にも説明すれば理解してもらえる

指標：

• 問題の説明に解決策が含まれていない
• 各要件に受け入れ基準がある
• 制約の一覧で事実と仮定が分けられている
• 先送り項目の一覧とともに V1 の境界が明示されている
• 要件が誤りだと判断できる条件を把握している

次のステップ： 検証済み要件ドキュメントを添えて、システム設計スキルに引き継ぎます

---

診断プロセス

新しいプロジェクトを始めるとき、または要件を見直すとき：

1. 状態の症状に耳を傾ける - 現在の状況を表している状態はどれですか？
2. 最も初期の問題状態から始める - RA0 の症状がある場合は、RA2 に進まずに対処します
3. 主な質問をする - 該当する状態の質問を使って情報を集めます
4. 介入策を適用する - 演習とテンプレートに取り組みます
5. 次に進む前に検証する - 進行前に、各状態の指標を確認します
6. 成果物を作成する - テンプレートを使って決定事項を記録します

フェーズごとの主な質問

問題の発見

• 解決しようとしている問題は何ですか？
• 誰がこの問題を抱えていますか？（具体的に）
• この解決策がない場合、今はどうしていますか？
• なぜこれまで解決されていないのですか？
• このアイデアを思いついたきっかけは何ですか？

ニーズの明確化

• 解決策は何を実現する必要がありますか？
• うまく機能していると、どうすれば分かりますか？
• 実用最小限のバージョンはどのようなものですか？
• 結果にがっかりするとしたら、どのような場合ですか？

制約の発見

• 実際に使える時間はどれくらいですか？
• どのようなスキルがあり、何を身につける必要がありますか？
• 何と連携する必要がありますか？
• まだ検証していない仮定は何ですか？
• プロジェクトを頓挫させる要因は何ですか？

スコープの定義

• V1 に含めるものと、後回しにするものは何ですか？
• 強制された場合、何を削りますか？
• 先送りした項目を見直すきっかけは何ですか？
• 明確にスコープ外とするものは何ですか？

アンチパターン

解決策の仕様化

問題： ニーズではなく、実装を記述した要件を書くことです。「システムは PostgreSQL を使用する」は要件ではありません。「データはサーバーの再起動後も保持されなければならない」が要件です。 対処法： 要件ごとに「別の方法でも満たせるか？」と問いかけます。満たせる場合は、ニーズではなく実装を記述している可能性があります。

ステークホルダーの虚構

問題： 要件を発見するのではなく、1 人で開発する人が要件を想像してしまうことです。根拠もなく「ユーザーは……を求める」と考えます。 対処法： 自分がユーザーなら、自分自身のニーズに正直になりましょう。他の人向けに作るなら、その人たちと話すか、類似事例を根拠にします。ユーザーをでっち上げてはいけません。

無限に増えるバックログ

問題： 優先順位を付けずに要件が増え続け、すべてが同じくらい重要になってしまうことです。 対処法： 強制順位付けを行います。1 つしかリリースできないとしたら何ですか？ では 2 つなら？ こうすることで、実際の優先事項が明らかになります。

早すぎる詳細化

問題： まだ重要でない詳細を指定してしまうことです。誰も通知を望んでいるか検証する前に、通知設定画面を設計してしまいます。 解決策： どの要件を今の時点で詳細にする必要があり、どの要件を後回しにできるかを特定します。不確かな項目には「X の検証後に決定」と仮置きします。

制約の見落とし

問題： 実際の制約を洗い出さずに進め、開発途中で制約に直面してしまうことです。「あ、これに使えるのは週 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 への引き継ぎ）

会話とファイルの使い分け

ファイルに保存	会話に残す
問題の説明	ファイブ・ホワイの掘り下げ
ニーズの階層	優先順位付けの議論
制約一覧	前提の発見に関する対話
スコープの定義	削除・維持の調整
検証済み要件	明確化のための質問

ファイル名

形式：requirements-{project-name}.md または docs/requirements/ 内の複数ファイル
例：requirements-static-site-generator.md

行わないこと

• コードを書いたり、実装を提案したりしません
• 技術やアーキテクチャを選びません（それは system-design の役割です）
• 状態を飛ばしません。問題が明確でなければ、ニーズについて話し合いません
• あいまいな要件を、完成したものとして受け入れません
• スコープの拡大を見過ごしません
• 状況を診断し、問いかけ、導きます。判断するのは開発者です

system-design との統合

requirements-analysis の出力	system-design の入力
検証済み要件ドキュメント	設計コンテキストブリーフ
制約の一覧	アーキテクチャ上の制約
ニーズの階層	品質属性の優先順位

引き継ぎの準備が整う条件：

• 解決策を提示せずに、問題が明確に述べられている
• ニーズが検証可能で具体的である
• 制約が（実際のものか仮定上のものかを含めて）一覧化されている
• 明確な V1 の定義によってスコープが限定されている

他のスキルとの統合

スキル	タイミング	統合方法
brainstorming	複数の解決策が考えられる場合	1つに決める前に、brainstorming を使って検討します
research	ドメイン知識の不足が要件策定の妨げになる場合	research スキルを使って知識の不足を補います

参考資料

このスキルでは、以下の概念を実践します：

• references/development-process.md（Decision Cascade Problem、Five Whys、Requirements Interrogation）
• Jobs-to-be-Done の方法論
• MoSCoW による優先順位付け