はじめに
仕事柄、要件定義書と書かれた資料を拝見することが多い。フォーマットは結構ばらついている。ある要件定義書はパワーポイント(PowerPoint)で書かれていたり、ある要件定義書はエクセル(Excel)で書かれたりしている。ある要件定義書はワード(Word)で書かれていたりする。筆者としては、パワーポイントで書かれていようが、エクセルで書かれていようが、ワードで書かれていようが、正直どちらでも構わないと考えている。
ただ、日ごろ感じていることは、それらの要件定義書なるものに記載されている内容を見ても、どこが要件なのかわからない点だ。
例えば、概要図がパワポに記載されているとする。この概要図は、何を表しているのだろう。要件であろうか？必ず実現しなければならない図なのであろうか？筆者の考えとしては、ノーである。概要図は、あくまでも概要図なのだ。要件定義書に最低限書かれていなければならないのは、「要件」である。要件は１個でもよい。複数でもよい。「これが要件である」ということを、堂々と主張している資料は、立派な要件定義書なのだ。
例えば、テキストファイルで、
要件①：良いシステムをつくること
とだけ書かれていたとする。これは要件定義書であろうか？筆者の考えとしては、イエスである。この要件定義書を受けとり、やりますといったベンダーは、何が何でも要件①を満足しなければならない。ただし、良いシステムとは何なのかについて明確化しないとプロジェクトは炎上必須となるので、QAを通じて内容を詰めていかなければならない。もちろん、顧客が考える良いシステムと、ベンダが考える良いシステムが、お互いの頭の中で完全に一致しているならば、QAは不要である。フォーマットが何であれ、システムに対する要件が命令形で表現されている書類は、要件を定義した書なのだ。
では、世間一般で書くべきとされている、業務フロー（AsIsとToBe）や、ユースケース一覧や、システム構成図は何なのであろうか？筆者の考えとしては、それらは理解補助資料である。「業務フローを実現できるシステムを構築しろ」と書いてあれば、これは要件だ。「業務フローは下記である」と書いてあれば、これは理解補助資料だ。「業務フローはこうだからこうしろ」なんて書いてないから、別に従う必要はない。理解補助資料を要件定義書に必ず書けと書いてあるサイトは多いが、筆者としては、とにかく理解補助資料を必ず書けと言っているように聞こえてしまうので、なんだか納得しづらい思いである(理解補助資料自体は記載して構わないが、「ここが要件だ」と主張が力強くなされているのならば、もちろん異論はない)。「業務要件」なるものもいまいちよくわからない。その業務要件は、誰に対して課された要件なのであろうか？システムであろうか？このあたりについては話が長くなるので、別の機会に譲ることとする。
以下に、要件ではないものの例を示す。
- 概要図
- 業務フロー
- 目標
- 要望
以下に、要件であるものの例を示す。
- 要件（○○しろ、○○するな、という記載）
要求と要件の違い
よく、要求と要件の違いについて説明しているサイトを見かけるが、区別することは意味がないと考えている。Wikipediaでも、区別ができていないからだ。
下記は、wikipediaで記載されている、要求仕様に関する説明だ。
要求仕様（ようきゅうしよう、requirement、requirements specification）とは、工学分野において特定の製品やサービスがどうあるべきかを記述する文書を指す。主にシステム工学とソフトウェア工学で使われる用語である。単に、要件、または英語の requirement からリクワイアメント（リクワイヤメント）ともいう。
一方で、下記は、要件に関する説明だ。
また「要件定義」は（開発依頼のあったソフトウェアやシステムについて）顧客が望んでいる機能や仕様などについて、その概略をまとめた文章・文書を指すこともある[3]。ただしこうしたことをまとめた文書は通常は「要件定義書」と呼ばれる[3]。
もう、どっちでもよいだろう。これらの単語を使い分けるメリットはあまりない。wikipediaでさえ区別に困っているのだから、一般的な開発者に使い分けしろといっても、無理な話で、現場は混乱するだけである。
要求も要件も、システムとして実現しなければならないという点では同じである。
- 要求を伝えられた場合、あなたは、それを実現する必要はあるか？
- 要件を提示されたら、あなたは、それを実現する必要はあるか？
上記の問いに対して、両方ともYesと回答するならば、それらを区別する必要はない。顧客からみれば、どちらも一緒だ。「それは要求ではなくて、要件ですね」なんてベンダから言われたときには、「だから、何？」と顧客は突き返すであろう。その場でそのようなことを言わなかったとしても、会議後に「うざいやつ」認定されること必須だ。
どのような資料が、要件定義書となりうるのか？
最後に、どのような資料が要件定義書となるのかに関してまとめておく。この答えは一つである。要件が列挙されていること、これだけだ。最小限の内容として、要件が列挙されていれば、それはもう要件定義書だ。メールで、「○○すること、○○すること」という内容のメールがきたとする。これも要件定義書だ。どんな体裁であれ、強い命令形で表現された文章は、要件として定義されたものなのだ。要件として提示され、受注側が承諾した瞬間、その要件を実現しなければならない。
要件定義というのは、本来難しいものでもない。なぜならば、要件を列挙するだけでよいのだから。
