ソフトウェア開発における要件定義では「要件定義ではHowじゃなくWhatを語れ」とか「UIの議論の前にシナリオ／ユースケースを整理しろ」という話を最近何度かすることがあった。この考え方は過去のいろいろな学習経験とプロジェクト経験から来ているのだけれども、そういえばちゃんとまとめたことがなかったと思い、まとめてみることにしたという記事。
要件定義ではHowじゃなくWhatを語れ
どういう意味かというと、具体的にはこんなことを言いたいのだ。
- いきなり要件定義段階で、構築予定ソフトウェアの画面など機能の話をするな
- ユースケースもしくはそれに類する形で要求を整理しろ
- ユーザーの要求を動詞で整理しろ
なお現代的にはユースケースより、ユーザーストーリーといった形で整理するのが良いかもしれない（これは読者の属するドメインによる）。
なぜHowを語るべきではないのか
要件定義でHow、すなわちソフトウェアの画面や機能を書いてしまうことの弊害はいくつかある。いちばんの問題は「それが要求ではない」という点である。またHow（機能）だけが一人歩きして、それを誰がなんのために利用するのかといった情報が失われてしまうという問題があると思っている。
名著「ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)」（残念ながら絶版である）では以下のような説明がある。
要求文書の中にインターフェイスを操作するユーザーの動きを記述すると、3つの問題点が出てきます。
- 文章が不必要に長くなる。
- 要求が不安定になる。つまり、ユーザーインターフェイス設計に対するわずかな変更でも、「要求」自体を変更しなければならなくなる（これはそもそも要求ではない）。
- UI設計者の仕事を奪うことになる。UI設計者に仕事をまかすべきである。
「ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)」、第20章 個別のユースケースについてのメモ メモ7：GUIを排除する、より
ソフトウェア要求に関する歴史的な経緯
そもそも論で太古のソフトウェア要求は機能を中心に語られていたという。その後、ビジネスアナリストが「シナリオベース」の要件分析を始め、それが現代のユースケースやユーザーストーリーベースの要件定義に変化してきたと言われている。歴史を逆行すべきではないだろう。
アナリストは、ユーザー要求の引き出しに、長いこと、使用シナリオを使ってきた。この使用状況中心の観点をまとめたのが、要求モデリングへのユースケースアプローチである。さらに最近、アジャイル開発の支持者が「ユーザーストーリー」のコンセプトを導入した。ユーザーストーリーは、簡潔な記述でユーザーニーズを伝え、詳細を具体化するための話し合いの出発点となるものである。
ユースケースとユーザーストーリーはともに、要求引き出しのプロダクト中心の観点を切り替えて、ユーザーが何を成し遂げる必要があるかという話し合いに移すものである。ユーザーに、システムに何をしてほしいかと聞くものではない。このアプローチは、システムを使用してユーザーが実行するタスク、あるいはステークホルダーに貴重な成果をもたらすユーザーとシステムの相互作用を記述することを意図している。ビジネスアナリストがこれを理解すると、使用シナリオを実行できるようにするために、システムに実装しなければならない機能を導き出すことができる。また、その機能が正しく実装されたかどうか検証するためのテストにも役立つ。使用状況中心の引き出し戦略をとれば、他のどんな技法を使用するよりも、プロジェクトの多くのクラスのユーザー要求を深く理解することができる。
「ソフトウェア要求 第3版」第8章 ユーザー要求の理解、より
例外もある
なお、この原則には当然のことながら例外もある。「ソフトウェア要求 第3版」にも書かれているが、構築するソフトウェアのタイプによっては必ずしも該当しない。バッチシステムや計算集中型のシステム、データウェアハウスなどのアプリケーションや、組込システムやリアルタイムシステムである。これらのシステムはユーザとシステムの相互作用が要求の焦点ではないからである。
