第2回：知っていてこそのガイドライン (2/3)

どのように「ビュー」を見える化するのか

UIの部分は、その名の通り「ユーザインタフェース」なので、成果物自体は最終的に必ず見える化できる。だからこそ「作る前に見える化する」ことについては、これまであまり重要視されていなかったのではないだろうか。

弊誌のアンケートでも、開発ドキュメントの作成に関してWordやExcelを使っているユーザがほとんどだという結果がでている。その次にくるのがPowerPointである。これらのツールでは簡単な図版の作成は可能だが、詳細なUIを表記するためには別のグラフィックツールなどを使う必要がある。

その1つの解決策が、Microsoftの「VISIO」だ。ビジネスドキュメントに必要な図の作成はもちろん、あらかじめさまざまなUIのパーツが登録されており、組み合わせるだけでUIを詳細にビジュアル化することができる。

またVISIOはUMLやフローチャート図の作成にも対応しているなど、開発ドキュメントを作成する上で非常に便利なツールであるといえるだろう。しかし、弊誌のアンケートをみる限り、その普及率はかなり低いものだと考えられる。

つまり現状では、ドキュメント作成の段階からデザインを担当できる人物をアサインし、作成に参加してもらわない限り、どうしてもドキュメントに掲載されるものは「簡単な図」にとどまってしまう。

「従来どおりだから」「図を作ることに労力をかけたくない」といった理由から、これまでのやり方を踏襲しているだけでは、「伝わらないドキュメント」を作り続けることになってしまうのだ。

序

第1部　表現

• はじめに
• 第1章　画面一覧
• 第2章　画面遷移
• 第3章　画面レイアウト
• 第4章　画面遷移・レイアウト共通ルール表現
• 第5章　入出力項目
• 第6章　アクション明細
• 第7章　工程成果物間の関連

第2部　記述確認

• はじめに
• 第1章　網羅性のチェックリスト
• 第2章　コツのチェックリスト

第3部　レビュー

• はじめに
• 第1章　レビューの進め方
• 第2章　設計書レビューの進め方のポイント
• 第3章　工程成果物に着目したレビューのポイント

あとがき

用語集

なぜ発注者「ビュー」ガイドラインなのか

ここで改めて発注者ビューガイドラインの「画面編」の内容をみていこう。この画面編については発注者ビュー検討会のダウンロードページより、利用規約に同意することでダウンロードできるので、ぜひ入手して目を通していただきたい。

目次をみてもわかるように、このガイドラインは開発ドキュメントの「内容の作成」よりも、開発ドキュメントの「内容を決定する際のポイント」そして「依頼者と開発者間でレビューを行う際のポイント」について記述されている。よって「どんなツールを使うか」の部分については、各人が検討していく必要がある。

中でも、ワンランク上の開発ドキュメントを作成したいという方なら、第1部の35ページからはじまる「画面遷移」に関する項目だろう。単に図を貼り付けていくだけのものではなく、構成要素の解説からはじまり、さまざまな画面遷移の表記例などが含まれたドキュメント作成のコツが詰まっている。

重要な点として第1部の48ページにある「確認のコツ」があげられる。これは個々の画面遷移に対して、必要な画面定義が設計されているかを「図を描くことによって確認する」という手法だ。

これまで画面遷移の問題から手戻りが発生したプロジェクトについて、この発注者ビューガイドラインに沿って記述しなおしてみることで、何が手戻りの原因であったかを理解できるはずだ。 次のページ