PR

 前回は画面遷移図の作成方法やと構成といった基本について説明した。今回は,実際に画面遷移図を作成するうえでのポイントと注意点を解説する。

ハイレベル・サイトマップとフローチャートをミックスする

 今回説明する画面遷移図とは,リンク関係図のことではない。Excelを使って,1機能を1ワークシートに描く,リンク関係と画面設計とデータベース設計が混然一体となった図のことだ。Webデザイナー出身のプランナーには,ハイレベル・サイトマップ(双方向の詳細なリンク関係図)とフローチャートのごった煮のように見えるかもしれない。

 前回述べたように,リンク関係図では「1個の箱」問題が生じる。さらに詳しいハイレベル・サイトマップでも,イベントと処理の関係を示すことは難しい。一方,フローチャートでは画面レイアウトを表現できない。また,技術者の間でのみ通用する表現手法では,顧客側との意思疎通をはかるには不都合だ。顧客とプロジェクト・チームの全員で共有して理解できる方法が必要というわけで,筆者の場合,画面遷移図という言葉自体が一般的ではなかったころから試行錯誤してきたこの方法に,現時点では落ち着いている。

 まず,Excelのワークシートのタイトルとして,開発する機能名(プロジェクト名)を書く。それから,次の三つを忘れないように盛り込もう。

(1)各ファイルなどの関係
 1機能が,複数のプログラム・ファイルからなることは多い。クラス化した処理を共用したり,設定ファイルを利用することもある。データベースを使ったデータの読み書きや,もちろん単純なリンク関係もある。遷移図では,フォルダ構成と,プログラム・ファイル+クラス+設定ファイル+データベース間の関係を示さなければならない。

 フォルダ名,プロジェクト名,データベース名を記入する場合は,頭の中で名称を読みながら必ず3回チェックしよう。レガシー・データが正確であれば,画面遷移図内の名前をコピー&ぺーストして,フォルダや新規プロジェクトを作成することができ,プログラマやHTMLオペレータの入力ミスが発生しない。SSLの適用範囲,ロボット避けの範囲も必要であれば記載する。

(2)各ページの表示イメージ
 Excel上で図形描画機能を使って作図したシンプルなものでもよいし,イメージ・プランの検討が同時進行しているなら,画像処理ソフトで作りこんだ背景やイメージ画像を貼り込んで図を描き加えてもよい。シンプルな機能説明に終始するか,ビジュアル・イメージを押し出すかは,開発目的とプレゼンテーション方法によってケースバイケースだ。

 1プログラム・ファイルが,イベントの発生前と発生後の画面というように,複数のページから成るように見える場合は,複数の画面イメージを描いたほうがわかりやすい。使用するコントロールやプロパティ,各ページのタイトルやh1要素にあたる見出しの文言等もできるだけ記入しておこう。

(3)バックエンドの処理
 サンプル・アプリケーションやプロトタイプ開発を担当するプログラマに必要な情報を盛り込んでおこう。データの入力,編集,削除,保存,読み込み,表示,検索・抽出,生成などの処理を図式化し,文字コード,検証方法,条件分岐,フォーム間で渡す値,各機能間の連携方法を書き込む。ファイル名の命名規則,リスト表示する選択項目の最大文字長も明記する。

 また,生成するデータの形式や構造,一時的にメモリーに展開するデータの構造,バックグラウンドで行うデータ互換や変換処理,エラー・メッセージの文言,メールの自動送信を伴う場合は,メール・サーバーの設定やサブジェクトと本文とシグネチャの文言も忘れてはならない。検索処理については選択ボックスと入力ボックスの使い分けと条件指定方法も記入しておく。データベースからの読み込み/書き込みの詳細,既存サイトや顧客社内システムとの連携方法も必要であれば書く。

(4)データベース設計
 データベースを使う場合,データ構造,項目名,データ型,必須項目,文字長,主キー等を指定しておく。XMLの場合,文字コードと名前空間,整形式XML/検証済みXMLのどちらにするかを決定し,整形式の場合はひな型のXMLツリーと構造の説明を,検証済みとする場合はスキーマ定義を書いておく。

 顧客側更新の場合,Webフォームの入力画面の見本も付けておこう。データベースの運用・更新作業の手順,更新頻度とデータの整合性の説明については,ワープロで作成して,別添資料としてもよい。

プロトタイプにつながる画面遷移図の描き方

 Webアプリケーションでは,画面遷移図と基本設計は切っても切れない関係にある。そのため,条件分岐,表示,データベース(「磁気ディスク」で代用),単一ファイル(「書類」で代用),複数ファイル(「複数書類」で代用)等の記号を使い分けて,フローチャートのように描く方法は有効だと思う(図1)。ただし,内部処理だけでなくWebブラウザへの出力結果も重要なので,「表示」ならば,表示の記号のみで済ませるのではなく,表示内容を明記したり,画面イメージを描く必要がある。

 もっとも,明記しなくても顧客にもプログラマにもわかる部分(Webサイトであれば常識とされる処理)は端折っても差し支えない。例えば,新規ウィンドウで開いた画面に[このウィンドウを閉じる]ボタンを付ける場合,その処理は「閉じる」以外にはないからだ。

図1●条件分岐,表示,データベース,単一ファイル,複数ファイルを描き分ける
図1●条件分岐,表示,データベース,単一ファイル,複数ファイルを描き分ける
[画像のクリックで拡大表示]

 顧客またはエンドユーザーの操作,リンク,値の流れ,参照,といった関係は,矢印で表す。その際,操作はブロック矢印,リンク関係は実線,データベースからの読み込み/書き込みや値の引渡し・参照といった関係は破線で表現するなどというように,規則を決めてから描こう。色を作成して使い分け,線はたどりやすいように折れ曲がったり交差させないよう,できるだけ最短距離で引こう。引き慣れたら,画面上に表示されていない部分を頭の隅に置きつつ,左上隅からどんどん作図していけるようになる。

 文字の色も,規則を決めて使い分けるとわかりやすい。例えば説明は「黒」,前回仕様からの変更や追加は「青」,プログラマへの伝達事項はフキダシを使って「赤」で書き込む,といった具合だ。開発には無関係な顧客への説明方法などについては,コメント機能で書き込むのも一手である。プログラマが画面遷移図を使う場合に目障りにならず,営業担当者やプロジェクト・リーダーに情報を伝えられるからだ。

 前回の記事の図1でも,赤文字部分はプログラマへの伝達事項だ(図2)。書き方は,開発プラットフォームによって異なるが,筆者の場合は「ListBoxは使わずDropDownList使用。index=0は[掲載可否を選んでください]」「RangeValidator,データ型はinteger,最大値100」「入力・編集フォーム共通。登録|確認ボタンの表示|非表示の切り替えで対応」等のように書き込んでいる。プランナーが,使用するクラスやメソッド,宣言する変数の型や代入する値をイメージしたうえで作図しておくと,その後の打合せはスムーズに進む。

図2●前回の記事の図1の部分。赤文字はプログラマへの伝達事項になっている
図2●前回の記事の図1の部分。赤文字はプログラマへの伝達事項になっている

 もし,登録フォームや検索フォームを作るなら,データの検証方法も詳しく書いておこう。検証コントロールを使うのであれば,その種類とプロパティなどだ。全角半角,空白の扱い,上限値,下限値,データ型,特定アドレスのメールを受け付けない場合はそのドメイン,XSSへの対策も記載しておけば開発が迅速に進む。

 以上を,1ワークシートが縮小印刷でA1に収まる程度に効率よく作図する。この方法で作図すると,中規模案件で数ブック程度になる。

顧客提出前に,プロトタイプ開発者の確証を得る

 遷移図があらかた描けたら,顧客提出前にプログラマとの打ち合わせの機会を持とう。実装方法を説明して合意を得ておくためだ。特に,メンテナンスの面からクラス化したり,設定ファイルを読み込んで処理したほうがよい場合は,処理の目的を確実に伝えておかなければならない。表面上は同じ動作になるので実装方法までは問われないだろうなどと誤解されると,アプリケーションの更新の都度,プログラムの中に記述された設定値を変更する手間が発生し,初回のプログラミングの手間を上回ることがあるからだ。

 逆に,例えばバックエンドの処理でワンクッション(1プログラム・ファイル)を挟まなければ納期的に厳しいとか,誤操作を防ぐために1個ボタンを追加したほうがよいのではといった意見がプログラマから出たときは,検討したほうがよい。1ページ,1個のボタンが増えるだけでも,処理や画面レイアウトに影響が及ぶ。基本設計はビジュアル・デザインに影響し,逆にユーザー・インタフェースは設計に深くかかわっている。また,サイト全体と各ページの部分は,ニワトリとタマゴのような関係で,相互に影響しあっているからだ。

 デザイナー出身のプランナーが画面遷移図を作成するときは,不明点を残したまま提出しないように注意しよう。必ず自分でサンプル・コードを書いて実装の可否を確認するか,エンジニアに確認しておく必要がある。特に,排他制御については独断で進めてはならない。

「1か,0か」を念頭に置いて,描き忘れを防ぐ

 画面遷移図を初めて描く人が最も注意しなければならないのは,条件分岐で条件外の場合の処理を忘れがちになることだ。最初のうちは,「実行」「取消」のような簡単な分岐で「取消」が終端であったとしても,終端であることを示す記号を書くか,言葉で「閉じて終わる」などと書くクセをつけよう。「1」の場合の処理を書いたら,必ず「0」の場合の処理も書く。このことを念頭に置いて,書き忘れを防ごう。

 Webアプリケーションも,1か0かの処理に還元できる。ハードウエアと基本的な考え方は同じだ。そのようなわけで,最後にハードウエア分野から参入してWebプランナーを目指す人のための,遷移図作成の練習方法を紹介しておこう。前々回に書いたように,画面遷移図は回路図と似ているのでなじみやすいはずだし,情報家電花盛りでハードとソフトの壁を越えるプランナーも増えるだろうからだ。

 例えば,1機能を1基板として描き,1かたまりの処理を1個のICで,クラスはユニットとして表現する。コネクタの接続が,各機能間のリンク関係にあたる。条件分岐処理はセレクト・スイッチで表す。値の参照は,信号の流れを表すように矢印を付けて引き,処理の終わりはグランドで示す。関係が複雑化すれば,同一方向への流れは集束させてたどりやすくする。相互結線図を別途作成してもよい。これは,ハイレベル・サイトマップに該当するので,静的サイトであれば,それだけで十分だろう。

 筆者はハードウエア記述言語については門外漢だが,おそらく現在のハードウエア業界の人なら皆が皆,Webの世界は遅れている,ずいぶん古めかしい図を描く必要があるものだ,という印象を持つのではないだろうか。だがWebは,設計を直接試作品に展開するのではなく,顧客の検討・承認という「人間的なもの」を通さなければならない世界であり,図への理解度も顧客によって異なるので,現場ではやむをえないのである。

 この方法がわかりやすいと思う人は,いくつかテーマを決めて描いてみればよい。描き慣れたら,顧客と開発にかかわるメンバー全員が理解し共有できる方法を検討してみよう。それから実務に移り,実践の中で最良の描き方を模索していけばよいのではないだろうか。