define-product

製品を定義する

ユーザーが思い描く製品の意味を引き出し、それを、このアプリが何であり、なぜ重要なのかについてリポジトリ内で現在唯一の説明として保ちます。 大まかな方向性は会話のきっかけにはなりますが、欠けている製品の意味を補うものではありません。

方向性の種を必須とする

既存の製品定義、または少なくとも、ユーザーが追求したいと考えている大まかな対象ユーザー、状況、問題、意図する変化、あるいは解決策の方向性から始めます。 何もない場合は、欠けている情報を示してそこで止めます。個人の痕跡を探ったり、機会を捏造したり、PRODUCT.md を作成したりしてはいけません。

「Web ページを Markdown に変換する」のような大まかな解決策は、インタビューを始めるには十分ですが、明示されていないユーザー、問題、ワークフロー、成功の尺度を示す根拠にはならないものとして扱います。

現在のコンテキストを読む

ルートに PRODUCT.md がある場合は読みます。また、GLOSSARY.md と、存在する場合は docs/decisions/README.md の関連項目も読みます。

これらの情報源は区別して扱います。

• ユーザーの明示的な発言は、意図する製品の意味を示します。
• 現在の PRODUCT.md は、ユーザーが変更を確認するまで、既存の意図する意味を示します。
• コードは現在の動作を示す証拠であり、意図する意味の証明ではありません。
• リポジトリ内の情報や信頼できる外部情報源は事実を示すものであり、製品に関する選択を示すものではありません。

次の質問や最終的な定義を変えうる事実だけを確認します。 既存の意味、新しい依頼、現在の動作が一致しない場合は、その違いを明確に示し、どの意味を優先すべきかを尋ねます。 選択が明確になるまでは、現在のファイルを維持します。

製品の意味を引き出す

次の項目は最終定義を確認するために使い、ユーザーがすべて埋めなければならない質問票としては扱いません。

• アプリを一文で定義する；
• 主なユーザーと、そのユーザーがアプリを使う状況；
• 問題と、現在代わりに行っていること；
• アプリがユーザーにもたらすと約束する変化；
• 繰り返し行われる中核的な流れ；
• アプリ全体にわたる機能と、製品としての境界；
• 体験の原則；
• 観測可能な成功の兆候；
• 重要な前提と不明点。

ユーザー、状況、問題、または現在の代替手段が不明確な場合は、具体的な使用場面を一つ尋ねるところから始めます。 誰が何をしているのか、何に直面し、現在はどうしているのかを尋ねます。 一度に尋ねる質問は、密接に関連するものを一つから三つまでにします。一つの回答が次の質問を決める場合は、その質問だけをして回答を待ちます。

ユーザーがすでに思い描いている意味を引き出すときは、自由回答形式の質問をします。 その質問で答えを勧めたり、誘導する選択肢を示したりしないでください。 回答が大まかなままなら、「誰もが」「簡単」「速い」といった言葉を確定した製品の意味に読み替えず、具体的な状況や観測可能な変化を尋ねます。

現在の問題と、約束する変化は分けて扱います。 今日の問題の反対をユーザーが確認済みの目標とみなすのではなく、何が変わるべきかを尋ねます。

各回答の後は、新たに明らかになったことだけを振り返り、次の重要な不明点に進みます。 最終草案ができるまでは、不足している項目の一覧を内部にとどめ、ユーザーがすでに示した意味を再び尋ねないでください。

ユーザーがまだ決めていない選択肢に対応する

ユーザーが製品の選択がまだ済んでいないと伝えた場合は、ひとまず未確定のままにするか、一緒に決めるかを尋ねます。選択肢や推奨案を提示するのは、ユーザーがその選択を手伝ってほしいと頼んだ後に限ります。

具体的な利用シーンがあれば未決定の選択肢を明確にできる場合は、まずそのシーンについて尋ねます。製品が実際にどのように使われるのかを理解する前に、抽象的な不確かさを選択肢同士の比較に置き換えてはいけません。

ユーザーが選択を委ねた場合は、その範囲を明確にします。具体的な選択、重視する基準、制限事項を明示します。そのうえで、選んだ内容と理由を伝えます。「あとは任せる」という広い委任は、無関係な製品の意味づけまで決める権限を与えるものではありません。

ユーザーが範囲を定めずに「あとは任せる」と委ねた場合は、中心となる意味づけのうち、依然としてユーザーの入力が必要な点を伝え、実際の利用シーンから話を続けます。委任する選択肢、その基準、制限事項をユーザーが明示しない限り、後からその意味づけを補うと約束してはいけません。

作業中は、次の状態を区別して扱います。

• ユーザーが直接確認した意味づけ。
• ユーザーの明示的な委任の範囲内で決めた選択。
• ユーザーが前提として受け入れた、裏付けのない見解。
• ユーザーが意図的に未確定のままにすると選んだ重要な点。
• まだ確定していないAIの提案。

沈黙や情報不足によって、製品に関する選択が確定、委任、前提化、または保留されたことにはなりません。ユーザーがその状態のままにすることに同意した後に限り、前提または未確定事項として記録します。

定義が整ったかを判断する

未回答の点によってアプリの定義、ユーザーと利用シーン、繰り返し発生する問題と現在の代替手段、提供すると約束する変化、コアループ、または長期的な境界が大きく変わる可能性がある間は、インタビューを続けます。他の領域について尋ねるのは、その回答によって後続の製品作業が変わる場合に限ります。項目を埋めるだけのために詳細を作り出してはいけません。

中心となるユーザー、状況、問題、現在の代替手段、提供すると約束する変化、またはコアループが推測のまま、あるいは認識されていない抜けとして残っている場合は、PRODUCT.mdを作成してはいけません。何がまだ不足しているかを説明し、インタビューを続けます。中心的ではない抜けを残せるのは、ユーザーが前提として受け入れるか、意図的に未確定のままにすると決めた場合に限ります。

書き始める前に、製品の方向性全体を一度提示します。ユーザーが確認した内容、委任の範囲内で決めた内容、受け入れられた前提または意図的に未確定のままにする内容を明確に分けます。その案を確認するか、修正するようユーザーに尋ねます。

詳細な初回依頼を確認とみなせるのは、ファイルの作成を明示的に求めており、重要な製品に関する記述のすべてを推測なしで書けて、既存の製品の意味づけと矛盾しない場合に限ります。その場合は、質問を繰り返したり、再度承認を求めたりせずに作成します。

現在の製品コンテキストを記述する

ルートのPRODUCT.mdのみを作成または更新し、製品コンテキストの形式に従います。現在の説明はその場で書き換えます。時系列を追記したり、日付入りのバージョンを作成したり、現在の前提の横に古くなった意味づけを残したりしてはいけません。

確定した委任による選択は、それが影響する製品のセクションに記載します。委任された事実とその理由は、書き込み前の案と完了報告で明示します。PRODUCT.mdに別途、由来を説明するセクションを追加してはいけません。

ファイルには製品に関する内容のみを記載します。

• アプリ全体の機能は、機能のバックログではなく、安定した境界として記述します。
• エクスペリエンスの原則は、視覚的なシステムや画面デザインではなく、製品が守るべき特性として記述します。
• 前提を解釈するのに十分な根拠は残しますが、マーケティング目的の説得、会社の背景、購入を促す呼びかけは含めません。
• 技術、アーキテクチャ、データとファイル構造、リポジトリの運用方法、実装計画、個別の画面、詳細な機能要件、作業単位の受け入れ基準は、既存の成果物に残します。

このスキルの一環として、作業単位の仕様を作成したり、設計や実装に着手したりしてはいけません。

完了

ユーザーが製品の方向性全体を確認し、後続のエージェントが推測を意図と取り違えることなく、すばやく理解できる状態になったら完了です。更新した PRODUCT.md、確立または変更された重要な意味、委任のもとで行った選択、受け入れられた前提や意図的に不明のままにした点を報告してください。