企画書と同時に提出する画面遷移図は，Webの骨格だ。この図一つで，制作・開発効率や工期が決まるといっても過言ではない。今回と次回で，画面遷移図作成の基本と実践について見ていこう。
開発の効率化と長期運用のために
画面遷移図の果たす役割は大きい。顧客に完成予想図をイメージしてもらい，受注を獲得するための一助になる。概算見積書を作成するための資料にもなる。そして，実装機能やデータベース設計を固めるためのタタキ台にもなる。企画書と共に提出すれば終わりというわけではなく，モックアップやプロトタイプ開発にも利用できる。顧客との間で意識や記憶にズレが生じた場合の確認資料としても重宝する。
受注が確定的になると，顧客の要求を入れながら，何度も修正を重ねていく。画面遷移図の段階で調整に時間をかけて完全な合意を得ておけば，開発はスムーズに進む。段取り八分が何より肝心だ。データベース設計のような根幹の部分に変更が生じたときは，1から仕切り直して新たに作成することもある。顧客にもプランナー側にも「迷い」があるなら，お互いに過去に使った時間にこだわらないほうが良い結果が出る。
企画段階でじっくりと練られたWebサイトは，クレームの出ることも，リデザイン要求の相次ぐこともなく，長年重宝されるものになる，というのが筆者の実感だ。
画面遷移図の作成ツールと管理方法
画面遷移図の作成ツールはいろいろあるが，筆者が実際に見たものは―――せいぜい企画相談に乗った際の10数人の描いたものだが―――プランナーが自身が使い慣れているツールで作成したものばかりだった。小規模事業者の場合，案件の規模が大きくはないからかもしれない。また，描き方に標準化されたルールは見当たらなかった。それぞれの顧客層もあり，アピールしやすい方法を採用しているようだ。
(1) 作成ツール
筆者の見たものでは，Webデザイナー出身のプランナーが作成したものは主にIllustrator形式で，各コーナーあるいはページ間のリンク関係のみを示したシンプルなものばかりだった。Web関係者なら誰しも一度は目にしたことがあるはずの，箱（四角形）を並べて線で結んだ「リンク関係図」だ。この図のことを「画面遷移図」と呼ぶWebデザイナーは多いようだ（サイトマップやサイト・ストラクチャーと呼ぶケースもある）。静的なサイトの構成の刷り合わせには有効だが，Webアプリケーションの場合は，実開発にあたって別途新たに基本設計書を作成する必要がある。
一方，システム・エンジニア出身者が作成したものはExcelブック形式で，画面遷移図というよりは仕様書のようなものだった。筆者が見たものは，決まりきったようにフォント・サイズが小さく，枠線を消しておらず，色も黒1色のものばかり。顧客側の担当者がイントラネット管理者などの技術者なら，打ち合わせはスムーズに進むだろうが，技術に疎いタイプの社長自らが窓口を務めるケースでは，抵抗感を示されるかもしれない。
筆者の遷移図は，両者の中間だ。Excelを使って描いている。オートシェイプの「基本図形」「ブロック矢印」「フローチャート」を使えば，ほぼこと足りる。顧客や協業するエンジニアたちが日常業務で使い慣れているソフトのほうが，修正や希望を書き込んでもらいやすく，やりとりも意思疎通も容易だと思う。
使用ツールにせよ構成・描き方にせよ，これが唯一の正解というものはない。ビジュアル重視，処理重視，折衷案，どれも一長一短がある。顧客の業種や，遷移図に託す役割によって選ぶのがベターだろう。
(2) ファイル名
遷移図のファイルは，顧客やプロジェクトのメンバーとプランナーの間で，何度も行き来する。そこで，ファイル名は，案件名と作成（修正）年月日と連番をアンダースコアでつないだものにするなど，一目でわかるようにしておかなければならない。納品後には，画面を表した図の部分を，納品物の画面キャプチャで差替えておくと，後日機能追加等の相談を受けた際に，構成や処理を思い出しやすい。
(3) 保存期間
画面遷移図ファイルの保存期間は，運用期間に準じる。運用期間が長引けば，機能追加の要求が出てくるので，過去の遷移図を利用して検討することになる。OSが進化して作業用マシンを乗り変えた場合でも，いつでもすぐに確認できるように管理しておこう。筆者の場合，最長，4台のマシンを経て使い続けている遷移図がある。
画面遷移図に盛り込む内容
画面遷移図に盛り込む内容は，表1の通りだ。
 |
| 表1●画面遷移図に盛り込む内容（早期段階の提出用） [画像のクリックで拡大表示] |
管理情報は，基本の企画書に重複する部分もあるが，記載しておいたほうがわかりやすい。忘れてはならないのが変更履歴だ。顧客との間で調整が重なって3校以上になりそうな場合は，誰が，いつ，どの部分を，何の理由で，いかに変更したか，という5W1Hの記録を必ず残しておこう。開発現場では仕様変更記録は必須である。
次に，Webサイト全体の，おおまかな構成を示す資料が必要だ。一般的に「リンク関係図」と呼ばれるものにあたるが，それ単独で作成せず，画面設計書に含めて描いてもよいと思う。
画面設計書は，Webサイトを構成する各ページ内の，ユーザー・インタフェース・デザインや処理を図や表で表したものだ。Excelで作成する場合，1枚のワークシートにサイト全体の処理を描くことはできないので，複数のワークシートに分けることになる。案件の内容や規模によってシートの枚数が増えすぎたら，Webサイトのコーナー単位で複数のブックに分けるとよいだろう。
もし，データベース処理を含むWebアプリケーションであれば，企画段階から，データベース設計書を作成しておきたい。データベース定義の詳細も，できるだけ書いておこう。また，XML形式等の設定ファイル等を使うようであれば，それも書いておくとよい。
リンク関係図の「1個の箱」問題
リンク関係図は，静的なサイトの構造表現には適しているが，処理を伴うWebアプリケーションの構成を表現するには不都合がある。なにしろ，箱の数と1個の箱を実装するための工期が必ずしも一致しないうえに，何を「1個の箱」で表すのかが明確ではない。1個の箱が，1機能・1ページ・1プログラムファイル・1枚の画面イメージのどれにあたるのか―――が，あいまいだ。
例えば，「商品情報の登録」という1機能を，商品情報の入力と追加，編集，削除という三つのプログラム・ファイルに分けて実装すると仮定すれば，1機能3フォーム（ページ）3プログラム・ファイルとなる。ところが，図のみで操作がイメージできるように作図するには，入力・追加・編集・削除といった四つの画面イメージが必要となる。
あくまで1個の機能ではあるが，概算見積には3個のプログラムの予算が計上されており，見た目は4画面である。これを1個，3個，4個のうち，何個の箱で表現すれば伝わりやすいかは，顧客側の技術に対する理解度によって異なる。つまり顧客ごとに1個の箱の持つ意味が異なることになる。これでは，納品後，追加機能などが生じた折に，顧客側担当者が異動などによって技術理解度の異なる人に変わっていたら，説明がしづらくなってしまう。
さらに，シンプルなリンク関係図ありきで打ち合わせが進み，とんとん拍子で受注が確定した場合，実開発に着手した後で，リンク関係図通りの実装は困難という事態が生じるかもしれない。エンジニア出身のプランナーが，コードまで深く考えつつ破綻の恐れのないリンク関係図を作成するか，あるいは顧客側が細かい注文をつけない，一式お任せタイプであれば問題は生じないだろうが，そのようなケースばかりではないだろう。
筆者は，慎重かつ確実に顧客との合意を得たいので，リンク関係図のみを単独で作成したことはない。企画案提出段階から，プロトタイプ開発の打ち合わせに使うことができるような，制作・開発用の内部資料を作成する。そして，その中から，顧客への説明を必要とする部分だけを抜き出して，提出資料を作成する（この方法のメリットについては，本連載第13回を参照）。顧客側から質問が飛び出したり、バックグラウンドの処理を知らせる必要性が生じたときは，プリントした内部資料を打ち合わせに持参しておき（渡すのではなく）その場で見せて説明すればよい。
例えば図1は，Webアプリケーションのプレゼンテーション用サンプル・プログラム開発のための資料として作成したものの一部だ（実際は3ブック1文書から成る。内容も，本記事用に簡略化している）。まず，1機能1シートとして処理の流れを描く（上図）。これは開発打ち合わせに使う。そして，バックグラウンドの処理部分を除いた，対顧客説明に必要な最低限の部分（青地の部分）のみ別ファイルとして作成し（下図），提出用資料に代えている。
 |
| 図1●開発用資料を，顧客提出用資料に転用する方法（処理はダミー） [画像のクリックで拡大表示] |
もちろん，図1のような資料だけでは，顧客に完成予想図も画面デザインもイメージしてもらうことはできない。そのため，企画案提出時には，HTMLで仮組みしたモックアップやサンプル・プログラムを，テスト用サーバーに仮アップしたり，顧客のマシンに配置するなどして，表示イメージを確認したり処理を体験してもらうよう工夫している。
次回は，実際に画面遷移図を描く上での注意点について，見ていこう。
