RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック

f:id:west-c:20200910001913j:plain

こんにちは、west-cです。

業務にて要件定義を行う機会があり、その成果物である要求仕様書の書き方を学ぶために『【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術』という書籍を読みました。今回はその内容をご紹介します。

おすすめの読者層

  • 要求仕様書の目的・ゴールが曖昧な方
  • 自身が作成した仕様書において、仕様漏れや仕様の衝突が後工程で発生したことがある or 発生しないか不安を抱えている方
  • 依頼者から要求を引き出す方法の糸口を掴みたい方

要求仕様書とは

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

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

要求仕様にまつわる問題

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

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

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

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

仕様化のテクニック

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

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

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

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

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

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

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

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

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

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

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

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

実践してみた

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

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

作成した要求仕様書

f:id:west-c:20200908192441p:plain

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

実践した感想

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

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

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

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

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

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

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

おわりに

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

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

*1:この記事では割愛していますが、書籍内には依頼者から要求をヒアリングする方法も紹介されています。

Copyright © RAKUS Co., Ltd. All rights reserved.