webサイトの基本仕様書。定義しておいた方が良いもの。
webサイトの要件定義って大事ですよね。
何を作るかということを明確化し、後になって齟齬を起こさないようにするためにはとても大事なステップです。
webサイトの制作を、新規クライアントと進める場合、定義すべき、制作スコープ、コンテンツ、機能、連携すべき仕組みなどは要件定義フェーズでまとめておくべきですが、対象ブラウザや印刷対応など、いちいち個別にクライアントから指示されないことも多いです。
それらについてはどうでしょうか。
テスト・検証の段階になってクライアントから
「あれ、私のAndroidで表示が崩れるんですけど。直してください。」
とかってことはありがちです。
で、そのAndroidのOS確認すると相当古いバージョンだったとか・・・・。
そういう、プロジェクトの最初の段階で、指摘されないが、最初に押さえておいた方が良い「汎用的な」要決定事項があります。
今回は、それらについて紹介します。
webサイトの基本仕様書でうっかりを無くす。定義しておいた方が良いもの。
汎用的なものとして、予めて定義しておいたものが良い事項を整理すると、、、
- 後でリスクになりそうなこと
- どのクライアントにも当てはまること
- 現実的に対応できること
です。
具体項目例
上記踏まえ、制作側で「こういう想定ですよ」と、予め定義しておいた方がよいですよ、というものをまとめておきます。
対象OS
Windows、Mac、iOS、AndroidそれぞれでどのバージョンのOSまで対応するか。
対象ブラウザ
定義したOSにおいた、どのブラウザのどのバージョンまで対応するか。
ブラウザのバージョンは細かく上がりまくるので、「その時点の最新」とさせていただくことが多いです。
マルチデバイス対応（レスポンシブ・リキッド）
定義した、OS、ブラウザにおいて、PC、タブレット、スマホそれぞれでどのように対応するか、というところです。基本的には、「レスポンシブデザインによるワンソース管理」といったことになります。
レスポンシブデザインにおいては、可能なら何段階切り替えがあるかを定義する「ブレイクポイント数」は決めておいたほうがよいですね。
大体PC表示とスマホ表示を切り替える1つ、ということが多いです。
また、タブレットはPCサイトを表示させ、タブレットだけの特別対応ということは、あまりやりません。
あと、リキッド対応の有無も定義しておきましょう。
PCのブラウザウィンドウのサイズに応じてコンテンツの表示幅を可変させるかどうかの定義です。
個人的には、リキッド対応をしなくても良いと思うのですが、タブレットなどで表示が見切れてしまうといったことが無いようにする必要はあります。
対象モニタサイズ（幅）
「横幅が1024px以上のモニタサイズを想定」といった書き方をします。
合わせてブラウザのウィンドウサイズに合わせて、webサイトの表示を伸縮させるかどうかも定義しておきます。
リキッド表示対応と言われたりします。
「ウィンドウのサイズに応じて表示を伸縮させる。ただし、最低表示幅は●ピクセル、最大表示幅は●ピクセル。」といった書き方をします。
検証端末
公開前にテストを行うテスト検証端末を定義しておきます。
世の中にある端末をテスト検証端末として揃えることはできません。
通常は、「最新のiPhone、最新のGoogle Pixel、最新のiPad」くらいが現実的なところだと思います。
※高額な検証端末を貸し出すサービスもありますがこれも難しいところですよね。。
印刷対応
印刷時の特別対応の有無です。
基本的には「ブラウザの印刷機能による。印刷用の特別対応はしない。」というところが現実的です。
ただ、地図ページなどは、印刷用のPDFを準備しておくとか、ヘッダー、フッター、サイドナビを非表示にする対応をするということはあります。
アクセシビリティ対応
アクセシビリティについては、
「JIS X 8341-3:2016」として定義されている規格があります。
これは日本工業標準調査会（JISC）が制定した、情報通信における機器、ソフトウェアおよびサービスの情報アクセシビリティを確保・向上するために、企画・開発・設計者および経営者が配慮すべき具体的な要件がまとめられた標準規格です。
そしてそれにはAAとかAとか、対応レベルというものがあります。
これについて、「順守する」という約束まですることは、お勧めしません。
結構細かく完全な保証は難しいケースがありますので、、、。
もちろん対象サイトの性質にもよりますが内容を理解した上で、「目指す」的な言い回しがよいのではと思います。
SEO対応レベル
キーワード分析、それを踏まえたコンテンツコンサルなどを含むかというところです。
「webディレクターがサイト設計をするのに合わせて、キーワードや見出しを提案します。」くらいが現実的なところだと思います。
SNS連携利用有無
「基本的には想定ありません。」で良いと思います。
対象のwebサイトによりますが、BtoBのサイトであれば、あまりSNS活用に期待はできません。
演出・アニメーション対応レベル
これは、一応お断りを入れておいた方が良いです。遅延ロードに合わせて、ふわっと登場アニメーションを入れるくらいが現実的と思います。
コンテンツ作成範囲
webディレクターが編集をすることはあっても、ライターがコンテンツをゼロから書き起こすということは、デフォルトの想定では、考えないことが多いです。
事前の調査・分析範囲
アクセスログ分析でユーザーのニーズ調査をすることはしますが、リアルなユーザー調査や、グループインタビューなどの想定は基本無いと思うので一応お断りを入れておくことが多いです。
テスト検証方法
コンテンツ確認、表示確認、機能動作確認、脆弱性確認といったものがありますが、テスト検証でどこまで対応するか、といったことです。
サンプリングでの確認、網羅的に確認、といった考え方を定義しておきます。
ドキュメント納品物
標準で納品すべきドキュメントは何か定義しておきます。
- サイトマップ
- テスト検証報告書
- サイト基本仕様書
- 機能設計書
- サイト運用マニュアル
あたりがよくあるパターンです。
一回作ってしまえば改変しつつ、使い回しできます。
プロジェクトの最初にこんなにたくさんのことを決められない、という声もあるかもしれません。
ただ、ここで紹介しているものは、基本どの案件でも標準的に使えるものです。
なので、一回作ってしまえば、その後はゼロからつくる必要はありません。
都度改善したり、タイミングに合わせた更新をすれば大丈夫です。
項目は挙げましたので、皆さんに合う形で変更してもらえればです。
まとめ
今回はサイトの基本仕様書に含めるべき項目という視点でお話ししました。
勘違いしていただきたくないのは、これ、クライアントを縛るためではありません。自分を守るためだけのものでもありません。
「認識を合わせるためのもの」です。
認識を合わせておくことで、後で「このときどう？」「これ決めてなくない？」みたいな余計な心配を掛けずに済みます。なので言い回し的に「これは対象外です」「これはやりません」みたいな、言い回しにならないようにするのは結構大事かもです。
クライアント「メリット」を想像しながら定義ができると良いな、って思います。
