基本仕様書の書き方

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

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

基本仕様書とは

クライアントからの（システムに対する）要求がほぼ出揃ったと判断できるタイミングで作成する仕様書です。クライアントの要求（要件定義書）を、ディベロッパからの視点で再定義すると共に、大まかなスケジュールや構成等を決定します。さらに、予定する方法でシステムを実現した際に発現が想定される問題点、制限事項等も、現段階で可能な限り明らかにします。

各項目の記載指針

以下では、基本仕様書に含まれる各項目の記載方法を説明しています。基本仕様書テンプレートも参考にして下さい。

開発の目的(WHY)

システムを開発する目的を記載します。導入による費用対効果などを可能な限り数値ベースで明確にしましょう（下記例参照）。開発が進みシステムが具体化してくると、（ほぼ間違いなく）要件やスケジュールの変更を余儀なくされる場面に出会います。この時、ここに記載した内容が重要な羅針盤となるでしょう。

×悪い例,集計作業を簡素化する
○良い例,現在2時間を要する集計作業の工数を30分以内に改善する

基本方針(HOW)

開発の基本方針を記載します。この項は、一度まとめてしまえば大部分を複数の案件で使いまわすことができます。よって、以下では説明は省略し、”JavaによるGUIアプリケーション”の場合を想定した例を記載しています。

設計方針 -アプリケーション起動時にメイン画面となるフレームを開き、各機能はその内部フレームとして実現する。

リソース管理方針 -メッセージは全て日本語、敬語に統一する。 -処理の中断を行う要素（ボタン等）のラベルは「キャンセル」に統一し、複数の選択肢がある場合は、右端に配置する。

実装方針 -静的関数をまとめたクラスには、「..Logic」または「..Utilities」という名前を付ける。 -システム全体で共有するリソースを管理するクラスには、「..Context」という名前を付ける。

テスト方針 -JUnitによるテストケースを可能な限り追加する。 -ユーザの操作に関わるテストケースは「テスト仕様書」にまとめ、各リリースや、大きな修正の直後に、全件実施する。 -各リリース後には、ユーザによる仕様整合性のチェックと承認を実施する。

リリース後更新の方針 -アプリケーションはJavaWebStart技術を用いたオンライン起動によって起動される。リリース後にシステムの修正が発生した場合、サーバに登録された実行ファイルを書き換えることによって、全てのクライアントに更新を配布可能である。

機能一覧(WHAT)

この項には”何を作るのか”を記載します。詳細は「詳細見積書」や「外部設計書」にも記載されるため、記述はアウトラインのみに留めます。

システムの用途 システムが利用されるシーンを想定し、記載します。

対象となるユーザ システムを利用するユーザとその（代表的な）利用環境を想定し、記載します。

ハードウェア構成 システムを構成するハード（サーバ、ネットワーク、その他周辺機器）を記載します。

記載例： Host: xxx xxx Router: yyy yyy

ソフトウェア構成 システムの運用に必要なソフトウェア（OSを含みます）を記載します。

記載例： OS: Fedora 8(linux) Java: j2sdk1.6.0以上 Database: h2database 1.0.64

目標性能 達成すべき性能を列挙します。

制限事項 システムの利用にあたっての制限事項を列挙します。（当たり前ですが）出来ない事を全て書くという事は不可能ですが、想定される利用シーンの中で、対応が難しくなってくると考えられるものをなるべく多く見つけ出しておくことは肝要です（例えば、Windows98では起動できません、等）。

他のシステムとの関連（競合力） システムが既存の別のシステムをリプレース（或いはカバー）するものであれば、そのシステムに対する優位性や関連性を記載します。類似のパッケージ化されたシステムが存在する場合は、それらを使用せず新規に開発が必要となった経緯や理由も記載するとよいでしょう。

開発体制(WHO)

開発の規模に応じてプロジェクトマネージャ、プログラマ、デザイナ等の役割やコンポーネント（部品）毎の担当者等を記載します。一部にしか関わらないメンバに関しては、参加の時期も明確にしましょう。ディベロッパだけでなく、開発途上からシステムのテストに参加して貰うユーザも必ず定義します。クライアントには設計段階から仕様のチェックを依頼しますが、それだけで100%確認を行うことは不可能です。最終段階での大きな手戻りを防ぐために、要所要所で実際のシステムに触ってもらうことは非常に重要です。

例：
○○ - プロジェクトマネージャ
△△ - プログラマ（コンポーネントA,B担当）
×× - プログラマ（コンポーネントB担当 yyyy年xx月以降参加）
□□ - 仕様適合検査責任者

開発スケジュール(WHEN)

着手時期、リリース時期、運用開始時期を定義します。リリース時期は規模に応じて「フェーズ1」「フェーズ2」のように区切ります。新規性の高い案件の場合、運用開始時期は”開始目標”のニュアンスを帯びる事になります。また、ここで最も重要なのは「リリース＝完成」ではなく「リリース＝クライアントに実際に試してもらえる状態」だという点です。開発体制の項でも述べたように、設計段階で仕様を100%チェックすることは不可能です。目的と矛盾する仕様そのものの間違いが潜んでいることも多くあります。

開発環境(WHERE)

開発言語 開発に使用する言語、IDEとそれらのバージョンを記載します。

依存関係 依存するライブラリ、フレームワーク及びアプリケーションとそれらのバージョンを記載します。ライブラリについては実装段階で増減する可能性がありますので、大よその目安程度で良いでしょう。依存アプリケーションには、例えばシステムからExcelシートやPDFをエクスポートするような場合に「Microsoft Excel」や「Acrobat Reader」などを列挙します。

他システムとの関連（依存） 以下のいずれかに該当するシステムを全て列挙します。

-データを受け渡しが発生するシステム
-起動・実行等の制御をする（される）システム

※マクロを含むExcelは”関連システム”とみなします。つまり、依存アプリケーションに「Microsoft Excel」を登録するだけでなく、ここにも該当のファイル(.xls)を列挙します。