要件と仕様の違いとは？目的や使い分ける理由もプログラマーがわかりやすく解説

ライター／woinary

某社で社内向け業務システムの開発、運用を30年近くやっていたシステム屋さん。要件定義や仕様作成の経験も多い。現在はフリーランス。ガジェットやゲーム、ラノベが大好きなおっさんです。

鏡の裏と表？プログラム開発に関係深い要件と仕様の違いとは

image by iStockphoto

ゲームやWebなどのサービスなどのプログラムはどうやって作るのでしょう。もしかして、プログラマがいきなりキーボードを叩いてプログラムを書き出したり、フローチャートといったものを書くと思っていませんか。小さなプログラムではそういうこともあります。しかし、多くの人が使うようなプログラムではまずは設計という作業から。そこに欠かせないのが要件と仕様です。

どちらもそのプログラムがどんなものかを決めるもの。しかし、同じものではありません。ざっくり言うと家の間取り図が要件、実際の設計図面が仕様です。ここではこの違いについて説明していきます。

要件：お客さんの思い浮かべた作りたいもの

要件とは要望や要求と呼ぶこともあります。英語では「Requirement」です。直訳すると必要な条件。つまり、お客さんがこんなプログラムが作りたいという必要な条件を記したものです。

例えば家を建てたり、アパートやマンションを探したりする際に、さまざまな条件がありますよね。どの線の沿線で、駅から歩いて何分、近くにコンビニがある、などなど。こういう必要な条件を書き出していったものが要件です。間取りもその一つですね。どういう部屋があり、どう配置されているのかも重要。間取り図が重要であることは理解できると思います。

仕様：要件に現実を反映した設計図

さて、要件の一つとして間取り図がありますが、これで家を建てることはできません。実際に家を建てるにはもっと壁の厚さや柱の位置を、強度などを基準にきちんと計算して設計図を作りますよね。間取り図を作る時点でもある程度そういうことを考えます。しかし、まずはどんな部屋を用意してどう配置するかが重要になるので、間取り図を先に考えるわけです。

プログラムを作る時も同じ。まずはお客さんがどんなプログラムが欲しいかの条件を書き出したもの＝要件を元に、実際にどういうものを作るかを決めます。これが仕様。家に例えるならば設計図が仕様になります。

何が違う？要件と仕様の目的

image by iStockphoto

要件と仕様はざっくりと言えば間取り図と設計図。でも、なぜ両方必要なのでしょうか。どちらか片方で兼用すればよいのでは。そう考えるかもしれませんね。それではなぜ両方必要なのかを説明していきます。

目指す夢を示すのが要件

最初に簡単に説明した通り、要件というのはどういうプログラムを作りたいのか、をまとめたものです。部屋探しならば駅近やコンビニやスーパーが近くに欲しいなどいろいろありますよね。子育て中ならば近くに学校や公園があった方がよい場合もあれば、仕事をするので周りが静かな方がいいなど。要望も人やその時に重視するもので変わります。

プログラムも同じ。どんなプログラムがよいかを、実際にできるかや予算がどのくらい必要かをまずは抜きにして考えます。それが要件です。夢や目標と言い換えてもよいかもしれませんね。

要件を現実的にどうするかが仕様

大リーグで活躍している大谷選手は「大リーガーになる」という目標の周りにそのためにどうすればよいかを書いたそうです。以降はそのために何をすればよいのかを書き、ということの繰り返し。そうして現在からどうすれば大リーガーになれるかを書き出し、一つずつクリアすることで大リーガーになったわけですね。人生の設計図です。

プログラムを作るのも同じ。要件という最終的な目標に対して、それをどうすれば実現できるか考えます。それが仕様です。ゲームを例にして考えてみます。例えば「直感的な操作ができる」というのが要件です。そのためにどうするかを考え「行きたい方向にスワイプするとその方向にキャラが動く」と決めたとすると、それが仕様。これを要件の数だけ繰り返し、仕様を決めていきます。

なぜ分ける？要件と仕様が別な理由

要件と仕様がなんとなく違うものというのはわかってきたでしょうか。では、なぜ片方だけではいけないのでしょうか。例えば、最初から仕様を決めれば早いですよね。しかし、そうもいかないのです。

一つに要件と仕様は作る人が違うこともあるということ。そして、要件の段階であまり現実を気にし過ぎてしまうと、本当に欲しいものではなくて簡単にできそうなものになってしまうため。また、間取り図代わりに設計図をみても、素人には分かりづらいですよね。要件の時点であまり現実の細かいことを書くと、かえって分かりづらくなります。そのため、要件と仕様は分けて考えるのです。

実際どうやる？要件と仕様のまとめ方

image by iStockphoto

要件と仕様がなんとなく理解できたところで、実際にどうやるかを説明します。要件や仕様をまとめたものが要件定義書や仕様書という文書です。ここではある会社が発注者となって何かのプログラムをソフトウェア・ベンダーに作成してもらう場合を取り上げます。

誰がやる？要件の取りまとめ

まずは要件です。要件を誰が作るのかは場合によってさまざま。発注者の方でまとめてベンダーに提供することもあります。また、ベンダーの方で発注者に確認しながら作成することも。

どちらにしても、実際にそのプログラムを使う人の今の作業のやり方や関連資料などを調べます。場合によっては実際に作業している人にインタビューすることも。また、どういうところで時間がかかっているといったことや、どうなったら楽になるかを詳細まで聞いていきます。その結果を分析してまとめたものが要件定義書。これを発注者とベンダーで確認するのです。

夢と現実の狭間？仕様への落とし込み

要件が決まった後はベンダーの作業が中心です。できあがった要件定義所を元に、現実にどうやってプログラムを作るかを決めていきます。どんなプログラミング言語を使うのか、どんな部品を使うのかも決めるのです。プログラムの詳細はまだこの先で決めますが、プログラムを作るために必要なものをすべて書き出します。

例えば、どんな画面が必要で、その画面と画面はどうやって移動するのか、入力するデータはどんなもので、その結果何をして、どういう結果を出力するのかも全て決めるのです。それをまとめたものが仕様書。プログラムの設計図になります。この時点では現実にできるものでなければなりません。お客さんの要件としてはこうだけど、現実では難しいということも。要件からなるべく外れないように、現実的になるように決めるのが腕の見せ所です。

それは仕様です？相反する想い

仕様の中でも利用者に直接関係する部分はお客さんに確認してもらいます。仕様作成はベンダーの作業ですが、お客さんの要件から外れていないことを確認してもらうことが大事。これを怠るといざプログラムができた時にお客さんに「思ったものと違う」と言われることも。サンタさんに欲しいプレゼントをリクエストしたのにちょっと違うものが来て「コレジャナイ」と思ったことがありませんか。仕事ではそんなことがあっては困るので、確認するわけです。

お客さんはこうしたい、でもそれはできないことや、予算をオーバーしてしまう。そんな相反する想いをどうにかまとめることでプログラムが完成するのです。

要件と仕様は裏表の関係、両方大切なソフトウェアの設計図

要件と仕様は表と裏みたいなもの。要件はプログラムがどんなことをするもので、どうしたいかという理想を書いたもの。そして、仕様はそれを現実でどう実現するかを書いたもの。プログラムを作るためにはどちらも大切な設計図となります。

実際のプログラム作成の現場でこの2つを混同していることも。しかし、理想と現実はきちんと分けておく必要があります。この要件定義書や仕様書は今プログラムを作るために必要なのはもちろんです。しかし、プログラムが古くなると作り直すことも。その将来のプログラム作成のためにも大事な資料となります。その時、理想と現実が混ざってしまっていると、本当はどうしたかったのかが分からなくなってしまうのです。