要求仕様の本当の意味を探れ

顧客やエンドユーザーは、自分たちが思っている解決案を要件として主張することがあります。F-16 Falconの設計責任者だったハリー・ヒレーカーの経験が良い例です。彼のチームは、なんとマッハ2から2.5のスピードを出せる戦闘機を作ってくれと言われたのです。当時はもちろん、おそらく今でも、これは容易なことではありません。しかも、目標は「安くて」軽い戦闘機を作ることだったのです。スピードが倍になると、耐えなければならない力は4倍になるのに、どうすればそんなことが可能になるでしょうか。

そこで、設計チームがマッハ2から2.5というスピードが必要なのはなぜかと空軍に聞いたところ、答えは「戦闘から回避できるようにするため」でした。なんだ、そうだったのか。本当のニーズが明らかになったので、設計チームはその問題に取り組んで、技術的に実現可能な解決策を生み出すことができました。速さではなく、加速と機動性を重視した推力重量比の高い戦闘機です。

この教訓は、ソフトウェア開発にも生かせますユーザーが必要だという機能や特徴に、実は何を求めているのかをたずねれば、アーキテクトは本当の問題を考えることができますし、おそらくクライアントがいう解決策よりも安くてより良い方法を考え出せるでしょう。本当に大切なものに力点を置けば、優先順位もシンプルになります。もっとも大切な要件とは、他のすべての要件のもととなっている要件です。

では、それはどうすれば見つかるのでしょうか。「契約交渉よりも共同作業」というアジャイルの精神に従えば、アプローチは見つかります。具体的には、顧客のニーズを聞くことを目的とするワークショップやミーティングを聞くのです。そこでは「なぜ」という問いに答えやすくなるよう、顧客を誘導しましょう。私達は暗黙の前提に基づいて話をしがちなので、「なぜ」に対する答えを見つけるのが難しい場合があります。また、どのようにして解決策を実現するかという技術的専門的な議論になると、顧客の問題から離れてソフトウェア開発の問題ばかりに重点を置くことになってしまいます。それは避けた方がいいでしょう。