先日、知人に「仕様書ってどうやって書けばいいの？」と聞かれたので、私がサラリーマン時代に書いていた仕様書関連資料についての書き方をシェアします。
組織や人によって仕様書の書き方は千差万別なので、参考程度に読んで頂けると嬉しいです。
最初に私の作っていた書類の名称と役割を簡単に説明しておきます。
（プロジェクトによって作らなかったり内容が変わったりする資料もあります）
【要求仕様書】
クライアントへヒアリングを行い、最初に作成する資料です。
「そもそもどんな話だったんだっけ？」というような時に見直す資料となります。
【要件定義書】
要求仕様書の内容を基に、必要な機能を洗い出し、納期や費用や納品方法等の細かい内容を記述した資料です。
この後の資料作成のベースとなる資料で、ここがあいまいだと高確率で炎上します。
【 客先稟議用資料 】
クライアント側での稟議を通すために、極力シンプルに情報を絞った資料です。
慣れないうちはつい情報量が多くなってしまい、私は何度も作り直させられた資料です。
【 システム仕様書 】
一般的に「仕様書」と呼ばれる資料です。
各モジュールのインターフェース、画面推移、データベース構造、ネットワーク図、必要なサーバのスペック等、あらゆる情報が記載されます。
実装フェーズに入ってからも頻繁に更新され、バージョン番号が際限なく増えていく資料です。
【 社内調整用資料 】
調整先のキーマンの情報や、細かいスケジュール、課題管理表などが含まれます。
私の場合は主に外注先の担当者とのやり取りで活用していました。
【 外注仕様書 】
外注先へ発注するための仕様書となります。
本来なら契約前に私の方で書かなければならない資料ですが、実際には外注先の担当者と共同で作りました。
ってか、外注先の技術とか把握できてないのに、私だけで書けるわけないじゃないか！
【 詳細設計書 】
外注先の技術者さんが実際にシステムを構築するために使う資料です。
各担当者が別々に作り、後でまとめて納品してもらいます。
システムの改修やメンテナンス時に重宝する資料なので、必ず納品してもらいましょう。
では、それぞれの資料の作り方を見ていきましょう。
※私は常駐SEだったので、システム屋視点で書いていきます。
みんなで作ろう要求仕様書の作り方
ある意味、一番楽しくて、一番厄介な、要求仕様書の書き方です。
クライアントの話を聞きながら大いに夢を膨らませましょう
理想的なサービスを思い描き、内心で（そんなもん実装できるわけないじゃないか）と冷や汗を流しましょう。
ここでのポイントは、クライアントのアイディアを否定しない事です。
技術的に無理な部分は「無理です」という必要がありますが、費用や期間の問題や、外注すれば可能性がある内容の場合は、ひとまず要望という形で受け取ります。
ここで小さくまとまってしまうと、後々「やっぱりこれ入れてほしい」といった事になり炎上します。
営業さんと一緒に行こう
可能であれば、ヒアリングには営業さんと２人で臨むのが理想的です。
営業さんには常にクライアント側の立場に立ってもらい、実装が難しい機能については「技術担当は難しいと言っていますが、一旦持ち帰って検討させます」と言ってもらいましょう。
クライアントの発想を妨げずに、後で断りやすくなります。
また、クライアント側の出席者は、現場が分かりつつ、ある程度権限のある方に入ってもらいましょう。
プロジェクトの責任者や、役職的に現場責任者となる課長クラス？の人に入ってもらいましょう。
担当者だけにヒアリングして、いちいち「上司に確認します」なんて言われていてはヒアリングが進みません。
「何のために作るのか？」が一番重要
上の資料の説明のところでも書きましたが、要求仕様書は後で「そもそもどんな話だったんだっけ？」というような時に見直す資料となります。
そこで重要になるのは、「何のために作るのか」という所です。
目的のはっきりしていないシステムは、実装が進むにしたがって余計な機能が増えていき、最終的には火を噴きます。
火の用心には、元を断つのが肝心です。
要求仕様書の項目例
大規模システム案件から離れて久しいので色々抜けもあるかもしれませんが、
一番重要な項目は「システムの目的」です。
- システムの目的（一番重要！）
- システム概要（夢を語ってもらおう）
- 要求機能一覧（とりあえず持ち帰る）
- ローンチの時期
- 想定予算
- 調整が必要な関連部署等
システム屋の腕の見せ所だよ、要件定義書の作り方
個人的には一番重要な資料だと思っているのが「要件定義書」です。
システム仕様書などは、後からいくらでも書き換えられる（というか書き換える）資料ですが、要件定義書が曖昧だと後から高確率で炎上します。
しかし、見積もりの元となる要件定義書は契約の前後で作られることが多く、営業側から「早く出してくれ」とせっつかれます。
また、だいたいの技術者は新しい技術を使いたがるので、システムチームから工数の見えない最新技術の提案がどんどん飛んできます。
個人的に技術屋はマゾだと思います。
後から炎上することが分かっていて、なぜ自分から窮地に陥るような提案をするのでしょうか？
要件定義書は納期や費用別に、3種類ぐらい作っておくとその後の調整が楽になります。
（一度全部入りを作って、現実的なレベルに削っていくと作りやすいです。）
見積もりの元となる情報も含まれるので、短い時間で正確に作成する必要があります。
スケジュールのマージンや、社内リソースの把握、全体工数の見積もりなど、システム屋の経験と勘が試される場面です。
営業さんと連携し、クライアントが求めている部分まで削らないように気を付けながら、なるべく楽に作れるシステム構成に落とし込んでいきましょう。
要件定義書の項目例
一番重要なのは要求仕様と同じくシステムの目的とシステム概要、それに加え実装機能の一覧と作業工数です。
- システムの目的（要求仕様からコピー）
- システム概要（要求仕様からコピー）
- 実装機能一覧（費用別に3種類ぐらい用意する）
- 作業スケジュール（安全マージンを考えて）
- 作業工数（費用見積もりのベースとなります）
- 納品内容（納品物、納品場所等）
- その他調整内容（クライアント側にお願いしたい作業等）
客先稟議用資料
クライアントが社内稟議を通す際に添付する資料です。
もちろん要件定義書は添付すると思いますが、要件定義書だけでは十中八九、稟議を通りません。
お偉いさんは細かい資料なんぞ読まんのです。
説明資料は3ページ以下、1ページの情報は3つまで
稟議用の頭紙を除いて、資料は3ページ以内にまとめましょう。
内容的には、
- システムの目的・概要（なるべく簡潔に）
- スケジュール（むっちゃ簡潔に）
- 概算費用（抜けが無いように気を付けて）
辺りがカバーされていればいいと思います。
詳細は要件定義書見てもらえば分かるし・・・
客先稟議用資料作成のポイントは
「お偉いさんの知りたい情報だけを簡潔かつ分かりやすく書く」
です。
スケジュール資料のサンプル
まず私が書いた「簡潔なスケジュール」です。（ボツを食らいました）
何が悪かったのでしょうか？
最終的に出したスケジュールがこちらです。
お偉いさんが必要とする情報は、
・いつから使えるようになるのか？
・自分は何をすればいいのか？
だけです。
社内調整は事前に上から話を通してもらう必要があるので重要な情報です。
実装やテストのタイミングなぞ、下々の者が把握していれば良いのです。
注意： お偉いさんによっては詳細な情報を希望する人もいます。
クライアント側の担当者さんと話し合いながら最適な資料を作りましょう。
さて、「俺流、仕様書の書き方（要求仕様～客先稟議用資料）」はいかがだったでしょうか？
組織によって資料の書き方は変わってくると思いますが、少しでも参考になったら嬉しいです。
コメント