webサイト仕様書の作成方法とは？
こんにちは！
ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤（やなぎさわ）です。
弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。
こちらのジョブウィズでは、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。
さて、システム開発の際、利用者側がなにを開発して欲しいのか明確にしておく必要があります。
漠然とアレが欲しい、と言われても開発側が困ってしまいます。
webサイトについても同様で、こんな機能が欲しい、こういうことができると嬉しいというのをはっきりさせておかなくてはいけません。
今回はそのための資料である仕様書について見ていきたいと思います。
Webサイトにおける仕様書の役割とは？
仕様書、あるいは要求仕様書については、端的に言えば「仕様として実装して欲しい機能を表現したドキュメント」です。
もう少し踏み込んで言えば、現状の問題点を整理すると同時に、漠然としていた理想の姿を具体化し、現実と理想の間にあるギャップを埋めるための手段としてのシステムを定義するドキュメントです。
Webサイトであっても、その他のシステムであっても、仕様書の果たす役割は変わりありません。
仕様書は誰が作る？
仕様書はその性格上、開発規模が小さく要件定義書が仕様書の持っている役割を内包するなどの特別な理由がなければ、通常はユーザー側(システム発注側)が作成します。
開発側は仕様書に携わらないのか？
開発側はITの専門家として、仕様書作成について、
「この問題はこういった機能で解決できます」だとか、「このような機能の追加は難易度が高く、予算が倍に膨らむでしょう」といった風に助言する立場になります。
そして、仕様書が完成し、ユーザー側と開発側が内容に同意した暁には、その仕様書を叩き台にして実際にWebサイトを作るためのステップへと進んでいきます。
このように非常に大切な仕様書ですが、作成上の注意点を三つお伝えします。
仕様書作成の際の注意点
①表現に曖昧さを残さない
まず1つ目は、合意された仕様書はWebサイト開発の原点として、その後の方針に大きな影響を与えるため、表現に曖昧さを残さないようにしましょう。どんな機能が欲しいのかイマイチ良く分からない仕様書を渡されても開発側が困ってしまいます。万が一、未確定の部分があれば、それはいつ確定されるのか明示しておきましょう。
②誰が見てもわかるようにする
2つ目は、誰が見ても分かるようにすることです。案件開始から関わっているメンバーはもちろん、構築フェイズから参加するプログラマーなど後からWebサイト構築に関わるメンバーも仕様書を読んで同じ理解ができなければ、仕様書として失敗です。
③関係者がいつでもチェックできるような状態にする
そして、いつ誰でも関係者であればアクセスできる状態にしておくことです。
仕様書を確認することでそもそものWebサイト構築の目的を再確認できるわけですが、そもそもの目的が分かっていれば、正しい方向に物事を勧められるわけがありません。
また、Webサイト構築を進めていくなかで判断に困った際、改めてそもそもの目的を確認したくなることもあるでしょう。
ですので、仕様書は隠さずにオープンにしておくべきです。いずれの注意点も関係者内での認識相違を起こさないための工夫です。
関係者間、もっといえばユーザー側と開発側で認識相違が発生してしまうと、「欲しかったものと全然違う」「仕様書に書いてある通りにやったのに文句を言われた」とトラブルになるため絶対に避けたいところです。
さて、次に仕様書に書くべき項目について見ていきます。
仕様書に書くべき項目とは？
では、仕様書の重要性がわかったところで具体的な仕様書の中身を見ていきたいと思います。
仕様書に書くべき項目一覧
①企画概要
まずトップに来るのは「なんのためにどんなWebサイトを作成するのか」をはっきりとさせた「企画概要」です。
ここでまず、どういった層をターゲットにしているのかや、どういった目的を達成したいかなど、ユーザー側としてどんな思いを持ってwebサイト制作を依頼しているのかをはっきりさせます。
企画概要でWebサイトの目的がはっきりしたならば、より具体的にWebサイトの内容を詰めていきます。
②設計図
そのためにあるのが「設計図」です。一般的にWebサイト作成での設計図とは、他のページのリンクを上に置くか、それとも右に置くかなど、画面のレイアウトを明らかにする資料です。
会社や個人によっては「画面構成図」「情報設計図」、「ワイヤー(フレーム)」など呼び方は様々です。
③画面遷移図
もう一つwebサイトの設計図と呼べるのが「画面遷移図」です。
これは、商品のページで「カートの中身を確認」をクリックすれば、「カートの中身」というページに飛び、「カートの中身」というページで「レジに進む」をクリックすれば「お会計」ページへ移動する、といった風なサイト内の各ページの繋がりを明らかにする図です。
画面遷移図例
「カートの中身を確認」→「カートの中身」→「レジに進む」→「お会計」
これらの資料の作成に当たっては、どんなページを作るか明らかにしサイトマップを作成すること、そしてユーザーアビリティの視点に立った画面構成のルールを決めておくことが重要です。
④カタログスペック
Webサイトのカタログスペック的な情報も忘れてはいけません。
サイト名やサイトのドメイン、開発言語、どんな環境上(自社SVなのかクラウドなのか)で動くのか、納品や検品はどうするのかなどの情報は「サイトの仕様」としてまとめておきます。
⑤ロードマップ
そして、そのWebサイト構築が今後、どのようなスケジュール感で進んで欲しいのかを明らかにする「ロードマップ」も重要です。
4月には本稼働させたいので、2月末には納品して欲しいといった要望と、それを達成するための各フェーズの期限感を明らかにするものです。
ロードマップのセオリー通り、ガントチャートで作成するのがベターでしょう。
Web要件定義の進め方
Web要件定義の進め方については、こちらで詳しく説明しておりますので、ぜひご一読ください。
Webサイトの制作工程について
Webサイトの制作工程については以下の記事をご参照ください。
まとめ
繰り返しになりますが、仕様書とはユーザー側が「こんなものを作って欲しい」という思いを明らかにするものです。
仕様書の内容をユーザー側・開発側双方が同意して初めてWebサイト構築が進んでいくわけですが、ここで認識相違が少しでもあると、最終的にユーザー側の思いと異なるWebサイトが納品されてしまうことになりかねません。
仕様書作成者はいかに認識相違を発生させないドキュメントにするのか、しっかり考えて作成しましょう。
