"What"と"How"の分離の罠とコラボレーション・スペース

みなさんも今まで、戦略などについてロジカルに考えさせられる研修で「WhatとHowを分けて考えなさい」と言われたり、ビジネスの現場で「うちにはHowを語れるやつは多いけどWhatを語れるやつがいない」とか聞かされたことがあるのではないかと思います。また、Scrumの世界においても、「Whatを決めるのがプロダクトオーナーでHowを決めるのがチームである」というようなことが言われることもあります。 確かに、その考え方も一理あるのですが、現実を見ると、プロダクトオーナーだけでWhatが決められるケース（そんなプロダクトオーナーがいるケース）は少ないのではないでしょうか。また、特に高度なテクノロジー絡む場面においては、実装レベルのHowの知識がないと本当に価値のあるWhatが描けないということも増えてきています。 このあたりをどう考え、どう説明するのかについては、私自身もなかなかきれいに説明できていなかったのですが、Tobias Mayer氏が2011年のLondonでのScrum Gatheringのセッションで使った資料にちょうど良い部分がありましたので紹介しておきます。 資料のPDFは、以下のページで見ることができます。 "Dogma-free Scrum" by Tobias Mayer # 本稿で引用している図表は全て上記のPDFからの抜粋です。 この中で、彼は"Collaboration Space"の重要性を説いています。これは物理的な意味とメンタルな意味の両方を指しています。 まず、Scrumにおけるバックログのモデルとして、彼は以下のような構図を示しています。ここでは、プロダクトオーナーが"Who"と"What"と"Why"を決めてリクエストを行い、それに基づいてチームが"How"を決めてリクエストに応える…という形になっています。ある意味、これはWhatとHowの分離です。 

しかし、これではプロダクトオーナーのリクエストはうまく伝わりません。そこで、彼はRequest/Response Modelで、Why-What-Howの三層構造を提示します。このモデルでは、リクエストする側は"Why"を徹底的にクリアにします。どういう理由で、誰のために、どんな価値が、…といったことをです。そして、それをもとにしてRequesterとResponder/sがコラボレーションスペースで協調的にWhatを導きだすわけです。 

つまり、"What"と"How"で役割を分離するのではなく、分けるとしたら"Why"と"How"です。そして"What"はコラボレーション・スペースで協調的に導きだすというのがここでの考え方です。さらに言えばこれは、Scrumの実践だけでなく、要求開発アライアンスの提唱するOpenthologyにおけるコタツモデルのメタファーにも通じるものであると考えます。