仕様書の書き方と役立つ手法

目的

仕様書の書き方、必要な前提スキル、役立つ手法を理解する

仕様書はどんな書き方でも自由、だから難しい

仕様書とは「何をするか」を記述した文書です。

「設計書」との違いがわかりにくいですが、
・目的が違う
設計書は内部向け資料（そのため専門用語が多い）
⇔仕様書は外部向け資料（わかりやすい記述が必要）
・書く内容が違う
設計書は詳細（手順レベルまで落とし込むこともある）
⇔仕様書は概要・アウトライン
という違いがあります。

業界を問わず、様々な場面で使用されるのですが、どうやって書けばいいかについては、なかなかまとまった教育がありません。

会社によってはほとんどフォーマットが決まっており、穴埋めのように書き込んでいけばできあがるところもあります。

一方で業務請負やシステム開発、受注生産など、何をやるかが毎回異なる会社では決まったフォーマットがないところが多いのではないでしょうか。

そのため、はじめて作成を任された人は別案件のものを参考にしたり、先輩に教わりながら作成することになりますが、

・自信をもって上司に見せたら「全然ダメ」と言われる

という悲しい経験をしがちではないでしょうか。

小学生の自由作文と違ってお客さんにみせるものですし、いい加減なことは書けません。

なにがポイントで、なにを書けばいいのかがわからず、なんとなく作って、数をこなせば自然と身につくことがあるかもしれないし、ずっとうまく作成できないということもある、ではまずいでしょう。

仕様書は「何をすればお客さんが満足するか」が書ければOK、ただし前提スキルがあってこそ

結論を言うと仕様書は「お客さんが求めること（合格基準）」が書けていればほぼ完成です。

加えて、明快に(誰が読んでもわかるように)書いていることも必要です。

そのため、仕様書の「表面的な書き方」だけをマスターするのでは意味がありません。
以下の必要なスキルが合わさってはじめて作成できます。

・お客さんが求めていることを理解する能力
・お客さんが求めていることに対して自社が提供できること、それによって解決できること（自社サービスの理解が前提）を整理する能力
・これらを適切に文章・図表で表現する能力

これらは優れた営業担当、プロジェクトマネージャー、管理職に求められるスキルであり、身に着けると非常に武器になります。

単に「仕様書がうまく書ける」という評価だけでなく、
「お客さんの信頼を得る能力に優れている」
「社内のリソースをうまく活用する能力に優れている」
「説明能力に優れている」
という評価が得られます。

仕様書をうまく書けるとはこれらのスキルの証明書になりうるのです。

システム開発における仕様書の作り方を例に

では仕様書を作成する際のポイントと、役立つ手法について説明します。

ポイント
①目的を明確にする
　ゴールのイメージがずれないように明確にします。
②５W1H＋doを押さえる
　ゴールからプロセスを逆算します。
　　When：いつ（スケジュール・納期）
　　Where：どこで（自社or客先）
　　Who：だれが（自社・お客さん・委託先・担当者）
　　What：なにを（目的物）
　　Why：なぜ（品質レベルに関わります）
　　How：どのようにして・いくらで（手法やツールの制約、採算）
　　do：どうする

ポイントを整理したうえで、なにをどのように書くべきかを検討しましょう。

たとえばシステム開発ではお客さんは「こういうシステム・機能が欲しい」というオーダーが満たされるかが重要であって、受注側がどのような開発をするかは重要になりません。

したがって一般的に仕様書に記載すべきは、How以外の①②のすべてになるはずです。

文章の書き方は「わかりやすい文章〜1文レベル編〜」を参考にしてください。もちろん図表を使ってもOKです！

続いてこれらを整理するのに役立つ手法です。

私がおすすめするのは関係図、ガントチャートです。またツールではないですがMECE（ミーシー／ミッシー）という思考フレームワークも役に立ちます。

関係図は関係者が多い場合に役立ちます。
メリット：当事者の役割や関係性を整理できます。
デメリット：時系列や詳細な工程が書けません。

ガントチャートは工程を整理するもので、以下のようなものです。私はよくフローチャートや役割分担表を兼ねて使います。
メリット：時系列や詳細な工程が整理できます。
デメリット：各工程が密接に関連しあう場合、その関係性を示すことが難しいです。
※以下の図ではモジュール②からモジュール③に赤い矢印を引くことで、モジュール②が完成してモジュール③に着手できることを示しています。この程度ならばよいのですが、複雑になるとこういったことができません。

MECEは「もれなく・ダブりなく物事を整理する考え方」です。

例えば上記のガントチャートを作る際に、「設計」の段階が漏れているとすると、時系列に沿ってやることを想像していくと、「開発するのに設計書がないとできなくないか？」と漏れに気づくことができます。

また開発物を分解していくと、機能が３つあって、３つのモジュール（部品）に分解できるから分担の境目を決める、と漏れだけでなくダブりも気づくことができます。

これらの手法を使うと、自分の頭の整理にもなりますし、他人に説明するのにも役立ち、誤解や手戻りを少なくできますので、ぜひ活用してみてください。