Webサイトを構築する場合,通常は「設計書」を作成します。サイト全体の設計書であったり,ページ単体の設計書であったりするわけですが,今回は後者である「画面設計書」について考えてみましょう。

画面設計書を読むのは誰か

 Webサイトの構築では,対象ユーザーをできる限り具体的に決めてから開発を進めていきます。同様に,画面設計書にも「対象読者」を見定める必要があります。結論から言えば,かなり属性の異なる二種類の読者が存在します。

 まず,発注者である「クライアント」です。クライアントは,技術的な難易度ではなく,自分たちのビジネス要件を満たすものが作られるかどうかを確認するために画面設計書を読みます。開発(プロジェクト)のゴールや,プロジェクトのメリット/デメリット,リリース後の顧客満足の予想などを,その設計書から読み取ろうとします。したがって,できる限り具体的なイメージが伝わるものが要求されます。

 他方は,「開発チームのメンバー」です。彼らは技術的な実装に関心があり,それが実現可能なのか,実装可能ならば設計図としての役割を画面設計書に期待しています。さらに開発末期にはそのまま「テスト仕様書(何をどうテストして,何が正解なのかを明記してある書類)」となってくれることも期待しています。絵柄などの具体性にはあまり意味はなく,どちらかというと概念的な記述が好まれると思います。

画面設計書の二種類の読者

 こうした全く属性の異なる二種類の読者に対して,完全な満足を与える「画面設計書」を一度に作成することは,かなり難しいことです。それは,方向性を決めるという概要的なシーン(多くは,どの様なユーザー・インタフェース[UI]部品が必要かを考える場面)と,より詳細な実装のためのシーン(デザインの「テイスト:好みや方向性」までの指定がなされる場面)の二つは段階的に発生するもので,いわば画面設計書は開発の進ちょくとともに成長していくものだからです。

画面設計書のプロセス

 では,画面設計書はどのように「成長」していくのでしょうか。画面設計書は,「配布・修正・管理」という三つのプロセスを何度も繰り返していきます。つまり,この三つに効率よく対応できる「形式」が求められます。

画面設計書の想定すべきプロセス

配布
 画面設計書の読者は,クライアントと開発チームなので,通常は物理的に離れた場所に存在します。したがって,配布しやすい形にしておくことは必須条件です。大規模なサイトになればなるほど設計書の分量は多くなるので,その点も考慮しておく必要があります。
 クライアントには「紙」で配布することが多いでしょう。ただし,カラー印刷でないと伝わらないような記述を行うと,後でいろいろと問題が出てくる可能性があります。あまりにページ数が多いとデータ・サイズに関係してくるので,分割などの配慮も必要です。
修正
 Webサイト構築は,様々な形で開発中もユーザビリティ・テストが行われます。実際に使いやすいかどうかは,開発者が実装しながら自問自答しながら進んでいくからです。それはクライアント側でも同じですが,担当者によっては毎回言うことが異なったりすることもあります。そのような担当者側の「ブレ」は,適切な答えを導き出す情報が毎回増減するため生じてしまうと考えられます。
 そのため,クライアント側からも開発チーム側からも,仕様変更の依頼や指示が出てくる可能性は常にあります。そもそもWebサイト構築は,「ウォータフォール型の設計図通りに開発を進めていけばよい」という開発スタイルではないので,設計書そのものにも,修正に耐えられる「形」と「体制」が要求されます。
管理
 誰にどの時点の設計書を渡したのか,チェックを受けたのか。そうした情報をきちんと管理する,あるいは管理できるように準備をしておくことが必要です。簡単なことで言えば,「版番号(ドキュメント用のバージョン番号)」を付けて,どういった議論がなされたのかを整理できるようにしておきます。

画面設計書の検証

 では,画面設計書には,どういったことが記述されるべきでしょうか。Webサイトの性格によって扱う情報は異なりますが,少なくとも三つの視点が挙げられます。ページ単体として見る視点,サイト全体の一部として検証する視点,そして実装する立場から見た技術的な視点,の三つです。

画面設計書の想定すべき検証視点

単体ページとしてのデザイン
 画面を単体で捉えて,本当に使いやすいか,機能は十分か,テイスト(見た目)は対象ユーザーと合っているか,などを吟味したうえで書かれている必要性があります。
サイト全体の一部としてのデザイン
 単体ページだけではなく,その前後の画面から飛んできたときにも,違和感がないか,きちんと統一性はあるか,CSSなどのリソースを共有できるようなデザインになっているか,メンテナンス性はどうか,などが吟味されるべきポイントです。
技術的実装としてのデザイン
 画像処理的な技術,JavaScriptやAjax的な部分での技術検証,データベース設計に必要な情報(データの方や文字長)などの吟味が緻密になされているほど,後々の実装が楽になります。
 例えば,データベースをかなり活用するようなWebサイトの場合,下記のような項目があらかじめ吟味されていると,後の開発が非常に楽になります。
  1. データベースから読み込む文字長(十分なレイアウトが取られているか)
  2. 規定の文字長を超えてしまったらどうするか:文末を「…」で処理するなど
  3. どのテーブルから情報を読み込むのか
  4. 共通部品はどれか,共通CSS定義はどこに記述されるか
  5. 表示する情報を,画面や対象ユーザーや時間などによって,加工(修正)する必要はあるか
  6. サンプル画面は実データに基づいて作られているか
  7. 多数の商品などを列挙する際のソート順(第1~3…ソートキー)
  8. データのメンテナンス(情報入力・修正・削除)などは考慮されているか
  9. 例えば開発者がプロジェクトから3カ月間離れても,復帰しやすい資料が作られているか(誰かの頭の中だけに情報が詰まっていないか,属人性が強すぎないか)
  10. 文字コード(UTF-8,シフトJIS…),対象ブラウザ,非対象ブラウザへの対処方法,などは決まっているか
  11. ファイル名やタイトルなどの命名規則
  12. アクセシビリティ対応
 こうした項目は,確定しないまでも,初期のころから下記項目が議論されていると,エンジニアとデザイナーの交流がスムーズになりやすいように思います。開発するWebサイトの分野に傾向があれば,チェックリスト化して,プロジェクトが完了するごとにそれを更新して育てていくようにすれば,その後の品質向上にもつながります。

画面設計書こそチームの財産になる

 個人的には,画面設計書こそが,プロジェクトを重ねながら一番ノウハウが蓄積する部分なのだと思っています。その他の部分(例えばデータベース設計など)は,従来のソフトウエア・エンジニアリングの世界で十分に吟味されていて,それなりの勉強方法まで確立していると思えるからです。

 作ろうとしている画面を,適切にクライアントに説明できて,開発チームにも誤解なく支持できる「設計書」,それが「画面設計書」です。おそらく,それがどんな開発チームにも適応できるような「理想形」は存在しないのかもしれません。しかし,チーム・メンバーや業界を絞っていけば,その取っ掛かりは見つけられると思います。それが,そのチームの「資産・財産」となっていくのでしょう。

 次回は,こうした画面設計書を書くツールや一般的手法を紹介する予定です。


三井 英樹(みつい ひでき)
1963年大阪生まれ。日本DEC,日本総合研究所,野村総合研究所,などを経て,現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と,エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や,RIAコンソーシアム日刊デジタルクリエイターズ等で活動中。Webサイトとして,深く大きくかかわったのは,Visaモール(Phase1)とJAL(Flash版:簡単窓口モード/クイックモード)など。