| name | product-mind |
| description | 仕様を決める・機能を切る・UX を判断する・優先順位を提案する・仕様の妥当性をレビューするときに必ず使う skill。実装依頼に仕様の曖昧さが含まれるとき、エラー時の振る舞いを決めるとき、フェーズやスコープを切るとき、機能提案を求められたときに使う。仕様が完全に確定していて実装するだけのときは軽く通す。 |
Product Mind
機能を「実装できる形」にするだけでなく「実際の利用者に適切な形」に決めるための skill。
進め方の型
- 仕様が曖昧・大きめの機能は、いきなり実装せず「現状調査 → 方針の提示 → 承認 → 実装」の順で進める。方針提示の段階ではコードを変更しない。
- 選択肢を出すときは、効果 × リスク × 完結度(外部依存なくすぐやれるか)で並べ、推奨を明示する。比較は「できる/できない」の◯×表が読みやすい。
- 大きな改修は、着手前に分割案(feature flag で先行リリースできる単位、段階的に出せる単位)を提示する。全部できてから出す計画は事故のもと。サンクコストで一体リリースに固執しない。
利用者視点の自問
- この画面・機能の実際の利用者は誰か(経営層、管理者、現場、外部ユーザー)。その人の知識・目的で操作して自然か。
- 「その利用者が使うプロダクトとして適切か」を、機能実装のレビューとは別に、プロダクトマネージャーの視点で一度自問する。
- 専門用語・表記・単位は利用者のドメイン慣習(会計、業務など)に合っているか。エンジニア都合の用語を画面に漏らさない。
仕様判断の定石
- 一括処理(インポート等)の一部に問題がある場合、全体をエラーで落とすのではなく、問題行をスキップして警告(何が・なぜ・何件スキップされたか)を提示する形を検討する。ただしドメイン上ありえない値の受け入れとは区別する — 不正値の拒否は quality-mind に従い境界で行う。
- 突合・名寄せの一致基準(完全一致か、全角半角・大文字小文字を同一視するか)は仕様として明示的に決め、実装者判断で曖昧にしない。
- 用語は既存のドメイン用語集・既存画面の語彙に合わせる。同じ概念に新しい言葉を発明しない。指定された用語(「見込」「予想」等)を勝手に言い換えない。
- 互換性・旧仕様の温存は、仕様として明示されたときだけ考慮する。デフォルトは正しい仕様への一本化。
決定の永続化
- 会話・PR で確定した仕様上の決定(「AとBは分ける」「これはフェーズ外」等)は、その場で plan / docs の md に書き残す。口頭のままにすると次のセッションで失われる。
- スコープ外にした要求は「やらない」ではなく「今回のスコープ外(理由・いつ検討するか)」として記録する。
- 仕様書が存在する機能は、実装・レビューの前に必ず仕様書を読む。仕様書と実装が食い違ったら、実装ではなく食い違いを報告して確認する。
完了前
- 実装が仕様の意図(その機能が解決したかった問題)を満たしているかを、チェックリストの充足とは別に一度見直す。
- 仕様の穴(未定義のエッジケース、決めていない文言、権限の未定義)を見つけたら、実装で勝手に埋めずに列挙して確認する。