requirements-scoping

要件のスコープ設定

曖昧なプロンプト（「ニュースフィードを設計する」）を、3つのリストにまとめます。システムが行うこと（機能要件）、システムを形作る数値と品質（非機能制約）、そして意図的に対象外とすること（スコープ外）です。このステップを省くと、設計を誤ることが最もよくあります。目の前の問題とは別の問題を解決することになり、その後の判断がすべて、検証されていない前提に依存してしまいます。このプロセスは、時間をかけることが目的ではありません。設計上の選択を評価できる程度まで、問題を具体化することが目的です。これがなければ、すべてのコンポーネントが推測になり、最初の厳しい質問で全体像が崩れてしまいます。

これを使うタイミング

どのような設計でも、最初のステップで使います。図を1つ描く前、ツールを1つ名付ける前です。依頼が広範な場合（「YouTubeを設計する」）、曖昧な場合（「リアルタイムシステム」）、あるいは規模、整合性、対象ユーザーについて触れていない場合は、いつでも使います。以前の前提を覆す可能性のある制約が新たに現れたときも、設計の途中で使い直します。再スコープは、作り直しよりコストが低くて済みます。最もわかりやすい兆候は、ここで解決する問題を一文で説明できる前に、慣れ親しんだアーキテクチャに飛びつこうとすることです。その反射こそが落とし穴です。誰も実際には読んでいないプロンプトに、覚えている解決策を当てはめてしまうのです。

使わないタイミング

いつまでも質問し続けてはいけません。目的は、最初の仮説を選べるだけの十分な明確さを得ることであり、完全な仕様を作ることではありません。通常は、鋭い質問を3〜5個用意し、残りは前提として書き留めれば十分です。スコープを過剰に膨らませてもいけません。採用した機能はすべて設計して説明する必要があるため、あれば便利な機能はスコープ外に移します（YAGNI）。また、指摘を受けるたびに再スコープしてはいけません。本当に制約が変わったのか、単なる確認や補足なのかを見極めます。

まず明確にすること

設計を大きく左右する質問を、おおよその優先順位順に示します。

• 誰が、どのように使いますか？ 対象ユーザー（一般消費者／社内／B2B）、クライアント（モバイル、ウェブ、または両方）、そして中核となるユーザージャーニーを1〜2つ確認します。これが他のすべての範囲を定めます。
• 必須機能は何ですか？ 優先順位を付けた候補リストを作ってもらいます。中核機能が動くまでは、優先度の低い機能はスコープ外です。
• 規模はどの程度ですか？ DAU／MAU、成長の見通し（3／6／12か月）、読み込みと書き込みの比率、オブジェクトのサイズです。これらを入力として、back-of-the-envelopeでQPSとストレージを見積もります。ここでは値を記録し、見積もりはそちらで行います。
• レイテンシと可用性の目標は何ですか？ p99の数値とナインの目標を、ユーザージャーニーに関連付けます（フィードの読み込みと決済では条件が異なります）。
• データはどれだけ新鮮である必要がありますか？損失はどの程度まで許容できますか？ 強整合性と結果整合性のどちらを選ぶか、耐久性に何を期待するかが、後で最も難しいトレードオフを左右します。ここでは要件（読み取り結果が古くてもよいか、直近の書き込みが失われてもよいか）を記録し、整合性モデルの理論はconsistency-coordinationに任せます。

ユーザーが答えられない場合は、前提を明示して先に進みます（「DAU 1,000万で読み込み中心、結果整合性で問題ないと仮定します」）。明文化された前提は見直せますが、明示されない前提は後で思わぬ問題になります。回答は、使われた実際の言葉で記録します（「友達は最大5,000人」「リージョンの喪失に耐える必要がある」）。何気ない詳細が、後になって構造上の選択を迫る制約だとわかることはよくあります。

手順（レシピ）

プロンプトから範囲を定めた問題へと進める、繰り返し実行できる一連の手順です。

1. プロンプトを1文で言い換えます。「ユーザーが短いメッセージを投稿し、フォローしている人の投稿を時系列の逆順で表示するサービスです。」こうすることで、隠れた前提がすぐに明らかになり、早い段階で合意を得られます。
2. 機能要件をユーザーから見える機能として、動詞を先頭にして列挙します。メッセージを投稿する、ユーザーをフォローする、フィードを表示する、検索する。 これらは「システムは何をするのか」に答えるもので、それぞれアクターが実行できるアクションです。テスト可能な内容にし、実装の話は含めないでください（「DB に保存する」は要件ではありませんが、「フィードを表示する」は要件です）。
3. **優先順位をつけ、核心に絞ります。**プロダクトを定義する2つか3つの要件を選びます。それ以外は明示的に後回しにしてください。後回しにすることも決断であり、単なる見落としではありません。核心の要件によって設計の成否が決まります。それ以外はすべて、後から対応できます。
4. **明確化の回答から非機能制約を導きます。**機能要件がシステムの動作を定めるのに対し、非機能要件はシステムがどれだけ適切に動作すべきかを定めます。規模（DAU、QPS の入力値）、レイテンシ（p99）、可用性（ナイン）、一貫性、耐久性、コストやコンプライアンス上の制限などです。これらは設計を評価するための数値であり、機能が登場するずっと前に、シャーディング、キャッシュ、キューといった構造上の選択を迫るものです。
5. **対象外の項目を明示的に書きます。**設計の焦点を保ち、境界を偶然ではなく明確なものにするため、構築しないもの（分析、広告、モデレーション、マルチリージョンなど）を挙げます。
6. **設計に入る前に、3つのリストを言い直して確認します。**これが以降の作業を評価する基準となる契約です。固定された仕様ではなく、制約が変わった場合に見直す仮説として扱ってください。

出力するのは説明文ではなく、3つの短いリストです。非機能要件の数値は、次にback-of-the-envelopeへ渡してください。

落とし穴／誤解を招く点

スコープ設定は、誤って行うくらいなら省略したほうがましです。誤った確信を生み出してしまうからです。次の点に注意してください。

• 解決策を前提にした要件。「Kafka／キャッシュ／シャーディングが必要」は、解決策を要件として紛れ込ませたものです。これをニーズ（「書き込みのバーストを吸収する」「読み取りを高速に処理する」）に立ち返らせ、後から設計によって適切なツールを選びましょう。
• 数値化されていない非機能要件。「大規模」「低レイテンシ」「高可用性」では、何も決まりません。数値のない要件は願望にすぎません。選択に影響する前に、back-of-the-envelopeを使って数値化しましょう。
• **徹底性を装ったスコープの肥大化。**すべての機能を受け入れるのは勤勉に見えますが、設計を散漫にし、時間を浪費します。目標を満たす最小限のスコープが最適です。
• **見せかけの対象外項目。**難しい部分を避けるために項目を除外すると（難しいから一貫性を切り捨てるなど）、本当の問題が隠れてしまいます。焦点を定めるために削りましょう。プロンプトが実際に問う難題を避けるためではありません。
• **回答を最終決定として扱うこと。**要件は仮説です。制約が変わったら（「今度は p99 < 50ms」「今度は1つのリージョンを失う」など）、どの前提が無効になるのかを述べ、影響を受ける部分のスコープを見直してください。場当たり的な修正で済ませてはいけません。
• **影響の小さい質問から始めること。**読み取りと書き込みの比率を確認する前に、ボタンの色を聞くようなものです。アーキテクチャを左右する質問から始めましょう。細かな質問にすべて整然と答えても、システムの本質は依然として不明なままです。
• **確認せず、スコープについて一方的に話し続けること。**スコープ設定は対話です。3つのリストと前提を言い直し、修正のためにいったん待ちましょう。確認のための指摘をスコープへの攻撃として受け取ると、設計が誤った問題を擁護することになります。

やるべきこと、やってはいけないこと

• やるべきこと：プロンプトを一文で言い換え、最も重要度の高い質問（対象ユーザー、主要機能、規模、レイテンシ／可用性、鮮度）から始めます。
• やるべきこと：機能要件、非機能要件、対象外の3つのリストを作成し、未回答の質問はそれぞれ明示的かつ後から見直せる前提として扱います。
• やるべきこと：すべての非機能要件を定量化し（「p99 < 200ms」「10M DAU」など）、生の数値を計算のために back-of-the-envelope に渡します。
• やるべきこと：実際の制約が変わったら、どの前提が無効になるかを明示してスコープを見直します。
• やってはいけないこと：解決策を要件として紛れ込ませません（「Kafka が必要です」など）。ニーズを示し、設計によってツールの必要性を判断します。
• やってはいけないこと：すべての機能を受け入れません。優先度の低い機能は対象外に回し、難しい部分を避けるためだけに除外しないでください。
• やってはいけないこと：いつまでも質問し続けたり、スコープについて長々と話したりしません。最初の仮説を立てるのに十分な明確さを得たら、確認して先に進みます。

重要な数値

要件スコープの設定では入力を収集しますが、計算は行いません。生の数値（DAU／MAU、ユーザーあたりの1日のアクション数、読み取り：書き込み比率、オブジェクト／ペイロードのサイズ、保持期間、ピーク係数、p99 レイテンシ目標、可用性のナイン目標）を特定し、レイテンシ／QPS／ストレージの表と換算計算を担当する back-of-the-envelope に渡します。後続の判断の大半を左右するため、次の2つの数値はそのまま記録してください。読み取り：書き込み比率（読み取りが95％のシステムではキャッシュが有効ですが、書き込みが急増するシステムではキューが有効です）と、スケールの期間（1k QPS 向けの設計と1M QPS 向けの設計は別のシステムです）。単位と前提は各数値の横に記載してください。

図

スコープ設定の成果物は図ではなく3つのリストです。編集可能な合意事項として、すべての追跡の起点となるよう、テキストのままにしてください。スコープを定めた要件によって最初の高レベル設計が正当化された段階で、プラグイン内の architecture-diagram スキルを使ってその設計を図示します。要件自体に図は必要ありません。

関連する構成要素

• back-of-the-envelope — 入力として渡す：ここで収集した非機能要件の数値（DAU、比率、SLA）が、QPS、ストレージ、サーバー台数の計算に使われます。次のステップです。
• scaling-evolution — 入力として渡す：ここで定めた成長期間によって、計画すべき次のボトルネックが決まり、設計中にスコープを見直した場合は、新たな制約を渡します。
• api-design と data-storage — 入力として渡す：ここで示した機能要件とアクセスパターンが、具体的な契約とスキーマになります。
• consistency-coordination — 担当する概念はここにある：鮮度と耐久性の要件はここで収集し、一貫性モデルの理論はそちらで扱います。
• system-design — 見積もりと高レベル設計の前、ステップ1でオーケストレーターによって呼び出されます。

参考資料

• references/clarifying-question-catalog.md — カテゴリ別（機能、規模、レイテンシ／可用性、一貫性／耐久性、制約）にまとめられた質問集、曖昧な内容を具体化する例、記入式の要件テンプレートが含まれています。実際のプロンプトのスコープを定めるときや、上記の5つの質問だけでは不十分な不慣れな分野の場合に参照してください。