「実現したいこと」と、そのために手にする「手段」の整合を取らねば、まず期待するような成果は現れない。

　プロダクト作りにあたってもこのことを念頭に置く必要がある。テニスの試合に臨むにあたって、野球バットを手にしていくようなことが無いように。手にする手段が違っていては、話にならない。たとえ、これまでどんなにバットを振っていて、スイングには自信があったとしてもだ。

　プロダクトチームでありながら、「要件」「仕様」という言葉を耳にすることが多い場合、「手持ちの武器による誤謬」に陥っている可能性が高い。

　プロダクト作りにおける「要件」とは何か？　いつ、だれが、それを決めるのか。まさか、プロダクトオーナー？
　「何をつくるべきか？」この問いにプロダクトオーナーも、開発者も、デザイナーも、プロダクトチームのメンバーは全員向き合わなければならない。そこに「要件」という言葉をあてはめているようだと、作ろうとしているのは「プロダクト」ではなく「ソフトウェア」になっているかもしれない。

　要件は何か、そのための仕様は何か。もちろん、何周か回ってこうした言葉をあえて使っている場合もある。要求と、要件と、仕様という言葉を使い分ける人は、エピックも、フィーチャーも、ストーリーも使い分けた上で、プロダクトバックログという言葉との共存も器用にこなせるかもしれない。

　言葉は、それを用いる人のこれまでの経験の影響を受ける。「何かよくわからないもの（プロダクトとして作るべきもの）」を捉える言葉として、「要件」をあてる人、「ストーリー」をあてる人、あるいは「仮説」をあてる人。そこでどういう言葉を使うかで、どんな歩みが色濃かったのか想像することもできる。

　当てはめる言葉は、単なる記号として役割を越えて、チームの行為を方向づけるところがある。「要件」を決めるのに必要なのは「要件定義」。「仮説」を判断するのに必要なのは「仮説検証」。まだ、プロダクトとして何を作るべきか分かっていない段階で、チームが要件定義を始め出したらどうしようか。

　テニスの試合に臨むにあたって、野球バットを手にしていくようなことが無いように。手にする手段が違っていては、話にならない。たとえ、これまでどんなにバットを振っていて、スイングには自信があったとしてもだ。