よくある罠: 問題ではなく解決策を仕様化してしまう

ひとつの失敗パターンは、単独で取り上げる価値があります。あまりにもはまりやすいからです。仕様を書こうと腰を据えると、すでに頭に描いた解決策を書きたくなります。「タブ付きのサイドバー」「ポップアップするモーダル」「Postgresのテーブル」。しかし解決策で埋め尽くされた仕様は、まだ得てもいない決定をこっそり固定してしまいます。

この2行を比べてみてください。

Bad:  Add a left sidebar with collapsible sections for each book status.
Good: Let me see my books grouped by status without losing the full list.

最初の文は、それが正しい判断だと誰も確認しないうちから、サイドバー、折りたたみ可能なセクション、そしてレイアウトをすでに選んでしまっています。二つ目の文は*なすべき仕事(job to be done)*を述べ、AI(とあなた)が、それを満たす最もシンプルなものを自由に見つけられるようにしています。それは、3つのフィルターボタンだけかもしれません。欲しい結果を述べましょう。実装は、できるだけ長く交渉の余地があるままにしておきましょう。解決策は、仕様の中なら安く変えられ、コードの中では高くつきます。