たとえるなら
料理のレシピです。「塩は小さじ1」と決めてあれば、食べた人がしょっぱいと感じても、それはレシピ（仕様）どおりの味です。味を変えたいならレシピ自体を書き換える必要があり、それが「仕様変更」にあたります。
もう少しくわしく
仕様は、システムやソフトが「どう動くべきか」を定めた取り決めのことです。「このボタンを押すと確認画面が出る」「パスワードは8文字以上」といった決めごとの集まりで、それを文書にまとめたものを仕様書と呼びます。開発チームは仕様書を共通の地図にして、同じゴールに向かって作業します。
仕様書に書かれるのは、たとえば「どんな画面があるか」「画面のどこに何を表示するか」「入力欄には何文字まで入れられるか」「入力をまちがえたときにどんなエラーを出すか」「登録した内容をあとから消せるのか」といった細かい決めごとです。人間なら「まあ普通こうだよね」で済ませる部分も、コンピューターは決めていないことを勝手に判断できないため、ひとつずつ言葉にしておく必要があります。
現場の定番フレーズが「それは仕様です」。想定外の動きに見えても、意図してそう作ってある（＝バグではない）という説明です。逆に、仕様で決めたとおりに動かないものがバグと呼ばれます。つまり、ある動きがバグかどうかは、見た目の不自然さではなく「仕様でどう決めたか」で判定されるのです。
よく混同されるのが要件との違いです。要件は「何のために、何ができるようにしたいか」という目的の話で、仕様は「そのために画面や機能をどう動かすか」という手段の話です。「社員が出張費を自分で申請できるようにしたい」が要件、「申請ボタンを押すと上長に承認依頼のメールが飛ぶ」が仕様、というイメージです。要件を先に固め、それを実現する形に落としこんだものが仕様になります。
もうひとつよく聞くのが「仕様変更」です。作っている途中で決めごとを変えることを指し、開発の現場では影響の大きい出来事です。変更の内容によっては、完成していた部分の作り直しやスケジュールの見直しが必要になるため、「仕様変更が入った」という一言で現場の空気が引き締まります。かかる手間が増えれば工数の見積もりもやり直しになり、費用や納期の相談につながることもあります。
仕様があいまいなまま開発が進むと、あとで大きな手戻りが起きます。「当然こうなると思っていた」という発注側と、「そこは決まっていなかったので、こう作った」という開発側の認識がずれ、完成間近になってから作り直しになる——これは実際によくある失敗です。だからこそ、決めごとを文書にして双方で確認しておくことに時間をかけます。
IT業界で働きはじめたばかりの人にとって、仕様は「調べる対象」でもあります。動きがおかしいと感じたときにまずすべきなのは、自分の感覚で判断することではなく、「これは仕様でどう決まっていますか」と確認することです。仕様書を見て決まっていればそのとおりに作り、決まっていなければ「決まっていません」と早めに声を上げる。この習慣がある人は、現場でとても頼りにされます。
現場での使われ方
「これ、バグですか？」「いえ、仕様です」
不具合の報告に対して、意図した動作であると答える定番のやりとりです。ただの言い逃れではなく、仕様書に根拠があるのが本来の形です。
「お客さまから仕様変更の依頼が来ました」
決定済みの内容を変えたいという依頼。作業量やスケジュールへの影響を見積もり直す必要がある、重みのある報告です。
「そこ、仕様が決まってないので確認します」
仕様書に書かれていない部分を見つけたときの報告。勝手に判断して作りこむより、確認して決めてもらうほうが安全です。
「仕様どおりに動いているか、テストで確認しました」
テストは「うまく動くか」ではなく「仕様どおりか」を確かめる作業です。判定の基準は、いつも仕様の側にあります。
よくある質問
仕様とスペックは同じ意味ですか？
語源は同じで、どちらも英語のspecification（スペシフィケーション）から来ています。パソコンの性能を指す「スペック」も、機械の仕様という意味です。IT現場の「仕様」は、性能よりも動きの取り決めを指すことが多いです。
仕様と要件は何が違うのですか？
要件は「何ができるようにしたいか」という目的、仕様は「そのためにどう動かすか」という手段です。「出張費を自分で申請できるようにしたい」が要件、「申請ボタンを押すと上長に承認メールが飛ぶ」が仕様にあたります。ふつうは要件を先に決め、それを実現する形として仕様を決めていきます。
「仕様です」と言われたら、もう直してもらえないのですか？
そんなことはありません。「仕様です」は「今はそう決まっている」という意味であって、「変えられない」という意味ではありません。変えたい場合は仕様変更として相談することになります。ただし決めごとを変える以上、作業量や納期への影響を見積もり直す必要があります。
仕様書は誰が書くのですか？
多くの現場では、お客さまの要望を聞き取る立場のシステムエンジニア（SE）が中心になって書きます。プロジェクトによってはプロダクトマネージャーや、開発するエンジニア自身が書くこともあります。大切なのは誰が書くかよりも、関係者が同じ内容を見て合意していることです。
仕様が決まっていない状態で開発を始めることはできますか？
できますが、リスクは高くなります。ウォーターフォール型の開発では先に仕様をしっかり固めてから作りはじめます。アジャイル型の開発では、大枠だけ決めて動くものを作りながら細かい仕様を決めていきます。どちらの進め方でも、「まだ決まっていない」ことをはっきり共有しておくことが欠かせません。
