開発が成功する仕様書とは？書き方と注意点も徹底解説
Webシステムやアプリの開発の際に必ず必要となる「仕様書」。システム開発がうまく軌道に乗るかはこの仕様書にかかっているといっても過言ではありません。しかし、システム開発に馴染みがなければ、仕様書とは何か、と尋ねられても正しく答えられないという方も多いでしょう。
仕様書には何を書くのか、誰が作成するのか、その目的や役割は…？これらの疑問に答えるべく、今回は仕様書についての基礎知識や開発が成功する仕様書の条件、さらに書き方や注意点まで詳しく解説します。
仕様書について詳しく理解しておくと、これからシステム開発を発注する方はもちろん、受注する側の方も、大変仕事がやりやすくなるに違いありません。ぜひ参考にしてください。
仕様書とは？
まず最初に、仕様書とは何かについて解説しましょう。仕様書には何を書き、誰が何の目的で作成するのか、またその役割についてもお伝えします。
仕様書は何を書くの？
仕様書は、そのシステム開発を、「誰が」「何を」「いつ」「なぜ」行うのか、について明確に文章化したものです。
システム開発には、必ず明確な目的があります。そして、その目的を持つにいたった背景もあるはずです。仕様書には、それら開発の目的やバックグラウンド、納期、さらに予算までを記載します。
仕様書は誰がいつ作成するの
仕様書は、システム開発を発注する側が作成します。開発の第一段階として要件定義がありますが、受注者はこの要件定義で発注者がその開発でいつまでに何を、どれくらいの予算で行いたいかなどを事細かくヒヤリングします。仕様書は、この要件定義の前段階として、発注者側から開発者側へ提出するものです。
仕様書はなぜ必要なの？
いくつもの複雑な工程を経て行われる開発現場では、ただ耳で聞くだけでは誤解や思い込みが生じ、先で言った言わないの水掛け論に発展することがよくあります。そこで、発注者と受注者は、初めの段階で密な話し合いを重ねて要件定義を行うのですが、その土台の役割を果たすのが、仕様書です。
仕様書には、その時点で決まっている開発目的やシステムのイメージ、納期や予算などを数字や機能性、操作性も含めて具体的に記します。その資料があることによって、開発者と発注者は考え方や開発方法のすり合わせができるので、相互の考え違いや開発者の勝手な思い込みをなくす手立てにもなるでしょう。
設計書との違い
システム開発に馴染みのない人たちの間で、仕様書と設計書の違いがどこにあるのかについてよく話題にのぼります。繰り返しますが、発注者が提示した仕様書の情報をもとに、システム開発をどの様に進めるのかについて開発者と発注者間でしっかり話し合いをして要件定義を行います。その後、その開発のためにどの様なものを使ってどんな手順で開発していくのか、そのプロセスを示すのが、設計書です。つまり料理で例えると、設計書はレシピに当たります。
仕様書を作成するのは発注者なので、誰にでもわかるような一般的な表現が多用されますが、設計書はエンジニアやプロジェクトマネージャーが開発作業に使うため、開発者側によって手順や技術的な内容を専門用語を使って一から十まで細かく記されているのが特徴です。
開発が成功する仕様書の条件
続いては、システム開発が成功する仕様書とはいったいどのような共通点があるのか、について具体的に解説していきます。このポイントを押さえるだけで、仕様書の出来に雲泥の差が現れるので、しっかりと覚えておきましょう。
要求事項の漏れがない
仕様書の最大の目的は、システム開発で何をしたいかを開発者に明確に伝えることにあります。つまりシステム開発が成功する仕様書というのは、要件事項に漏れがないことが必須です。
しかし、中には後になって聞いていなかった、知らなかった、というケースもあり、ことによっては納期や予算の変更を迫られることも考えられます。また、そのような齟齬が生じると、開発現場の雰囲気が悪くなり、肝心のシステムそのものの出来にも悪影響を及ぼすかもしれないので注意が必要です。
図を使って説明
システム開発が成功する仕様書には、必ずといって良いほどわかりやすい図が使われているものです。想定するユーザーが、システムのエリアをどんなルートで移動するのか、明確なストーリーが描けるか、矛盾やひっかかりを持たずに済むのか、などもっとも大切なユーザビリティのイメージを共有するには、ワイヤーフレームを画面遷移図とともに示すのも有効です。よって、「こんな感じで」「あんなニュアンスで」という曖昧な表現は排除して、誰もが誤解せずにすむ質の高い図を用意するのが肝要でしょう。
選択肢を用意
システム開発の目的は同じでも、その達成方法は必ずしも一つとは限りません。しかも仕様書を提示するのはまったく開発には手つかずの段階ですから、その時点で方向性や手段を絞り過ぎると、かえって開発の可能性を狭めるリスクがあるでしょう。その意味で、開発がうまく進む仕様書には、選択肢が複数用意されているのも共通項です。
細かな仕様の説明
先ほどシステムのイメージを図で示す重要性について触れました。ただ、単に図だけでなく「ここは特に大切にしたい」というポイントがあれば、少し踏み込んで丁寧に注釈や説明書きを添えるのも、良い仕様書の特徴です。たとえたった一行でも、そこには意外と発注者のこだわりや大切にしたい理念が表れるもので、開発者が開発イメージや要求を明確につかむための一助となることがよくあるのです。
仕様書の書き方と注意点
続いて、実際に仕様書を書く時の具体的な方法や注意点について、さらに解説しましょう。
開発目的
仕様書に必ず必要なのは、システム開発の背景と目的、具体的な機能、納期、そして予算です。例えば、Webサイトである程度閲覧数は増えているのに、コンバージョン率が増えないとか、婚活のマッチングサイトで男性側の登録者が増えないなど、今抱えている問題や背景を明記し、その課題解決のためにどのようなシステムを導入、またはアレンジしたいか、などを仕様書にはっきりと示します。これを納期や予算とともに表すことで、開発者側からするとトータルでどこまで可能か、また修正が必要かなどの具体的な目安や問題点が浮き彫りとなり、両者間で議論を深めるきっかけになります。
依頼方法に注意
仕様書で開発者に依頼する際に、「このWebサイトと同じ様にして欲しい」といった伝え方をするケースが少なくありません。しかし、それだと単なる他社やライバルの模倣となり、オリジナリティに欠け、開発の意義が薄れるリスクがあります。それよりも、あくまでこうしたい、といったテーマや内容を具体的に詳しく記載するようにしましょう。すると、開発者側でこちらが想定する以上の方法を提示してくれるかもしれません。たとえ真似したいシステムがあるにしても、「こんな感じで」と丸投げするのではなく、仕様書には、そのシステムのどの点を取り入れたいのか、明記するようにしましょう。
ワイヤーフレームに画面遷移がある
開発を成功させる仕様書には、わかりやすい図が使われると述べましたが、具体的にはワイヤーフレームが不可欠です。例えばWebサイトの開発なら、トップページのどこに何を配置するのかをワイヤーフレームに落とし込めば、想定しているイメージが一目瞭然です。さらに、そこからどんなページに画面遷移するのかまでを表示してストーリー性を表現するとなお良いでしょう。
この段階ではあくまでイメージのため、あまり詳しい画像までは必要ありません。また、1つのパターンに絞る必要もなく、考えられるパターンを複数示すのも議論がスピーディーに深まるのでおすすめです。
仕様書の書き方：お役立ちツールをご紹介
最後に、実際に仕様書を書く際に役立つおすすめのツールをご紹介しましょう。操作性や見た目の良さなど、いずれも良質な仕様書作成の強い味方となってくれるに違いありません。ある程度慣れも必要ですが、これらのツールを使うことで、より具体的にイメージを表現できるだけでなく、新たな発想が生まれることもあるので、ぜひ参考にしてください。
パワーポイント
マイクロソフト社のパワーポイントは、圧倒的にユーザーが多く、ワイヤーフレーム作成に必要な機能はすべて揃っているので、使い勝手が良いでしょう。オフラインで使えるため、パソコンさえあれば、オフィスだけでなく移動中でも作業可能です。Googleスライドと互換性がある便利さも見過ごせないおすすめポイントです。
cacoo
cacooは、クラウド型の作図ツールです。いつでも、どこでも、誰とでもワンチームでワイヤーフレームの共同作成や編集、コメント入れなどができ、さらにビデオ通話とチェットでリモート会議も可能です。テンプレートも豊富で、PCはもちろん、モバイルアプリにも対応しているので、あらゆるシステム開発に向いています。慣れればわずか数分で誰にでも見映えの美しい作図が可能なので、初心者でもクオリティの高い仕様書作成ができるでしょう。
Moqups
Moqupsは、ブラウザベースで使えるワイヤーフレームに特化した無料ツールです。英語版ですが、直感的に操作できるため、慣れれば問題ありません。さまざまな図形やフォントが揃っていて、ドラッグ＆ドロップで容易にワイヤーフレームが作れるので、初心者におすすめです。無料版は1人しか使えませんが、有料版なら何人でも無制限で使えるうえ、容量や使える機能も増えます。Googleドライブと連携できるので幅広い使い方が可能でしょう。
まとめ
仕様書の意味や役割、また、開発が成功するための書き方などについて詳しくお伝えしました。仕様書は、発注者にとっては大事な意思表示の手段であり、開発そのものをうまく軌道に乗せるために不可欠な存在です。仕様書が、要求事項をとりこぼすことなく、開発者にとってもわかりやすく作成できれば、さらに重要度の高い要件定義がスムーズに進むので、開発のための質の高い青写真が描けるでしょう。
仕様書には、開発者の情熱や本気度が如実に表れます。よって、発注者に提示する前に、社内でしっかりと議論を重ね、ワイヤーフレームなどを使って訴求力の高いレイアウトを心掛けましょう。
開発者との話し合いを重ね、設計、プログラミングと段階が進むにつれ、最初に想定していた開発案と異なるものに行きつくことも多々あります。しかし、すべては最初の仕様書から始まります。まずは、ここに開発への思いと考えを盛り込むことにあらん限りの力を尽くしましょう。
ただし実際のところ、仕様書フェーズで案件の要件をすべて説明しきるのは難しく、途中で仕様書変更が発生することは良くあります。そのため、レリパではお客様にラボ型契約でご注文いただくことが多く、この契約形態なら仕様変更にも柔軟に対応できるので、必ずや最終的に素晴らしいシステムがリリースできるに違いありません。
ラボ型契約について詳しく知りたい方は、以下の記事をご参照ください。
>>> ラボ型開発のメリット？なぜラボ型を選んだほうが良いのか？
「どのオフショア開発会社ごとに条件に合っているか確認するのは大変そうだ……」と思われた方は、ぜひRelipaにご連絡ください。
