要求仕様書の書き方

「仕様書の書き方」の一連のページをまとめて電子書籍化しました。
iBookstore で発売中です。 2015.05.11

この文章や、文章中で定義する用語は、株式会社ランバーミルの開発業務の中で蓄積されたノウハウを基にしています。業界一般や書籍等で定義されているものとは、必ずしもニュアンスが一致していない点に注意して下さい（業務の参考にはなるかもしれませんが、試験対策には使えません）。

要求仕様書とは

クライアントがディベロッパに対して開発を依頼する（予定の）システム要件を文章化したものです。要件定義、業務委託仕様、RFPなどとも呼ばれます。基本仕様書と、似ていますが、まだ「こんなことがしたい」という要求だけで具体的な実現方法については規定されていない点が異なります。とはいえ、ある程度の知識がないと、どんなことが可能か、という判断は難しいため、クライアント側に専門知識を持った担当者が居ない場合など、ディベロッパ側がある程度関与する必要もあるようです。要求仕様書が必要になるのは、発注元の規則で相見積や入札が必要な場合です。

各項目の記載指針

目的(WHY)

何のために必要なシステムなのか、このシステムで何を達成するつもりなのかを出来る限り具体的にします。中長期に渡る開発の場合、双方気付かないうちに徐々に手段が目的化し、当初の目標を見失いがちになることが往々にしてあります（最近良くすり替わりそうになるのが「クラウドを導入する」、とか）。そのような時に、進路を修正するために明文化された目的が必要です。勿論、日々刻々と変わるビジネス上の事情に応じて、この目的も変化することはあり得ます。そのような変化がいつどうして起こったかを記録するためにも重要となります。

予算(HOW)

言わずもがな、幾らまでなら出せるか、という数値です。この辺りは色々と大人の事情が介入しそうですが、コンピュータの世界では、ある機能を実現しようと思った時に、無料（オープンソース）でやるのか、10万（パッケージソフト）でやるのか、1億（大手企業と協力）でやるのか、という極端な選択肢が出てくることもそう珍しくありません。また、オープンソースを選択する場合でも、既存の機能だけを使って数日で仕上げるのか、じっくりカスタマイズするのか、で必要な人件費には大きな開きがでます。せめて、予算のオーダー（桁数）くらいは明確に決めておかないと、この要求を受けたディベロッパ側で適切な提案が難しくなります。

納期(WHEN)

システムがいつまでに必要なのかを決定します。また、システムを分割できるなら、それぞれのモジュール単位の完成日や受け入れテストの日程や不良が見つかった場合の担保期間についても、可能なだけ指定しておいた方がよいでしょう（ディベロッパとの折衝になるでしょうけれど）。この納期と上述の予算との２つが開発の規模を決定する大きなファクタになります。

運用(WHERE,WHAT,WHO)

完成したシステムを、どこで、誰が、どんな風に使うのかを想定して明記します。ここが明確でないと、最終的な結合テストがどうしても疎かになり、運用開始後のトラブルの元となります。また、運用開始後に不具合が見つかった場合のエスカレーション手順（ディベロッパ側にどのように伝えるのか）や、改修が必要になった場合の追加依頼の方法についても規定します。

運用でもう一つ大事なのは、既存システムやハードウェアとの兼ね合いです。例えば、既にハードウェア設備が揃っていて、そこに追加インストールするような形なのか、社外にインフラ（例えば専用サーバやVPS）を用意する必要があるのか、では開発時の制約が大きく異なってきます。また、既存のシステムとのデータ受け渡しが発生する場合には、そのプロトコル（簡単なものではファイルのフォーマット）なども規定しておく必要があります。

その他

完成後のシステムや開発中にディベロッパ側に渡すリソースの著作権や機密保持の方法ついても規定します。