要求仕様書とは

書籍では、要求仕様書を「要求について、関係者がその内容について認識を特定できている文章」と定義しています。

要求（今回の機能で実現したいこと）は曖昧なものを含んでいるため、具体的な振る舞いや制限として仕様化することが要求仕様書の役割となります。

要求仕様にまつわる問題

多くの現場における要求仕様にまつわる問題として以下が挙げられています。

多くの現場では、設計の様子が見えるような具体的なレベルの仕様は、設計工程の中で掘り下げるものと考えられている。

そのような考えで書かれた要求仕様書は設計や実装のイメージにはつながらず、設計工程や実装工程で具体化するなかで仕様の漏れや衝突に気づくことになる。

これは私にとっては耳の痛い話で、はじめて仕様書作成を担当した機能において具体的な仕様に落とし込めていない仕様書を作成し、実装工程になってから実装担当者から質問が頻発する、という苦い経験がありました。要求仕様書というと上流工程に位置することから細かい仕様は後工程で決める印象を持ちがちですが、少なくとも仕様の衝突が発生しない程度には具体化する必要があると改めて感じました。

仕様化のテクニック

要求仕様書では、依頼者から引き出した要求を仕様に落とし込む必要があります*1。

仕様へ落とし込む方法について、書籍では以下に基づいたテクニックが紹介されています。

要求という振る舞いの中に含まれている動き（＝動詞）をすべて表現してしまえば、それぞれの動詞および目的語について必要な仕様をもれなく記述できる。

例えば、以下のような要求があったとします。

印刷途中で、用紙やトナーの不足が分かった時点で担当者にメールで知らせる。

この文章において直接見えている動詞は以下の通りです。

不足が"分かる"
メールで"知らせる"

しかし、この要求に含まれる動詞はこれだけではなく、よく読むと以下の動詞も見えてきます。

用紙やトナーの量を"知る"
メールを"組み立てる"
担当者のメールアドレスを"読み出す"

これらの動詞をもとに仕様化を行う、というのが書籍で紹介されている仕様化のテクニックです。それぞれの動詞に対して仕様化すべき内容としては以下のようなものがあるでしょう。

用紙やトナーの量を知る
- 用紙・トナーの残量をどのように入手するか
不足が分かる
- 用紙・トナーの残量がどれくらいであれば不足と判断するか
メールを組み立てる
- メッセージの構成をどうするか
担当者のメールアドレスを読み出す
- メールアドレスをどこから読み出すか
メールで知らせる
- どのように通知するか
- 再送方法をどうするか

「よく読むと見えてくる動詞」は慣れないと洗い出しが難しそうですが、個人的には、その要求を実現するためのプロセスをイメージすれば、そのプロセス一つひとつが動詞と対応付くのではと感じました。設計や実装のイメージを持ちながら要求仕様書の作成を行う考え方は、ここに直結するのだと思います。

実践してみた

書籍にはこの他にも要求仕様書の作成に関するテクニックが紹介されており、筆者が推奨するフォーマットも提示されています。そこで、過去に自分が要件定義を行った機能について、改めて書籍の手法を用いて仕様化を行ってみました。

ちなみに書籍で紹介されている要求仕様書の作成手法はUSDMという名前が付いているようです。調べると資料も見つかりますので、詳しく知りたい方は書籍と併せてそちらもどうぞ。

作成した要求仕様書

書籍で紹介されているフォーマットに厳密には従っていませんが、一つひとつの要求を仕様にブレークダウンする書き方は踏襲しています。また、要求に複数の動詞が含まれる場合は、要求をもう一段階層化して動詞を分解しています。

実践した感想

（良くも悪くも）考えるスコープを絞り込める

一つの動詞＋目的語に絞り込まれた要求を仕様に落とし込んでいくため、考えるべきスコープを絞って集中的に仕様化できることを実感しました。これまでの私は思いつくままに仕様化していましたが、全体から詳細にブレークダウンしていくことでより網羅的に仕様の洗い出しができている感覚がありました。

一方、考えるスコープが絞られるということはより近視眼的になることでもあります。仕様化を進める中でも、複数の要求にまたがるような仕様が漏れそうという不安がありました。定期的に要求レベルに立ち返って全体を俯瞰するなど、鳥の目・虫の目の視点の切り替えが肝になると感じました。

要求と理由をセットで記述するのは効果あり

書籍では、「なぜこの要求を実現したいのか」という依頼者の思いを明らかにするため、要求は理由とセットで記述するよう紹介されています。

実際に理由を添えて記述することで、「そういえばこの要求はなぜ必要なのだろう？」と初心に立ち返りながら考えることができました。背景や理由を明文化することで、要求を実現するためのよりよい解に至ることもできるのではと思いました。

また、仕様の経緯を辿れるようにする意味でも、背景や理由をドキュメントに残しておく意義はあると思います。

おわりに

試しに実践してみたことで、書籍のテクニックが仕様漏れ防止の一助になると感じました。このフォーマットをいきなり既存の要求仕様書に置き換えるのはハードルが高そうなため、まずは抜け漏れ防止のクロスチェック的な立ち位置で部分的に取り入れたいです。

また当然ではありますが、いくら漏れなく仕様化できたとしても、そもそもの要求の認識が依頼者とズレていたのであれば元も子もありません。今後は要求の引き出し方についても深く学んでいきたいです。

エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。

https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gle
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com