「システム開発地図」で画面はどう設計する？ 第5回：もう迷わないシステム開発（2/3 ページ）

[今田忠博, 近藤正裕，ITmedia]

画面一覧を作成する

　ユースケース記述のアクターとシステムのやりとりの記述を基に、画面候補を抽出します。画面が抽出される典型的な記述例は以下のようなものです。

• 「アクターは、〜〜を入力する」
• 「アクターは、〜〜を指示する」
• 「システムは、アクターに〜〜」
• 「システムは、〜〜画面を表示する」

　画面候補は、ロバストネス図のバウンダリーに対応するため、適宜整合性を取るようにロバストネス図も見直します。画面候補が出たら画面一覧に追記していきます。

画面イメージを作成する

　入力項目、表示項目、ボタンなどを要素とする画面イメージを作成します。項目一覧などの補助資料を作成してもよいでしょう。

　ユーザーインタフェース標準があれば、既存の画面モックツールやキュメントのテンプレートが利用できるでしょう。ない場合は、必要最小限の簡素な表現に留めましょう。

　このフェーズでユーザーと合意すべきことは、「業務に必要な情報が足りているか」「どの項目が必須であるか」「どのような形式で表示・入力するのか」というところです^（注4）。UI部品のスタイルなどに目が行ってしまって、議論が発散してしまい、要件定義が進まないとなると本末転倒です。スタイルも適用されていないモックで実施したいところです。

　ここで表示したい項目がドメインモデルやエンティティモデルに現れているのか、確認が必要です。もしなければフィードバックします。

画面遷移モデルを作る

　次に画面遷移モデルを作成します。画面イメージの遷移図として表現しても、UMLステートマシン図などで表現してもよいでしょう。

画面遷移図

ステートマシン図による画面遷移モデル

　画面遷移なのか、ポップアップなのかで、業務効率が変わってきます。ポップアップなどはさまざまな画面から呼び出されるので、ステートマシン図では画面遷移と区別してノートなどで記すとすっきりします。

ユーザーインタフェース標準

　ユーザーインタフェース標準は、設計者に対する指針となるとともに、アプリケーション開発者が使用する画面フレームワークの仕様の一部になります^（注5）。特に大きいプロジェクトでは、画面設計の標準化とともに進め、設計者向けにガイドを提供するのが理想的です。

---

注4：　桁数やフォーマットなどは設計フェーズで「画面項目定義書」などの設計書で詳細化することが多いため、要件定義フェーズでは業務上のデータフローに注目して進めるとよいでしょう。

注5：　画面フレームワークの仕様としては、他に、画面遷移方式、画面間で保持すべき情報やその生存期間などがあります。