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

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

画面構成の標準化

　ユーザーインタフェース標準は、個別の画面仕様の検討に先立って、ユーザーと典型的な画面のデザインについて協議し、決めていきます。Webアプリの場合、まず画面のレイアウトを中心に決め、配色・フォント、アイコンなどをデザイナーに発注し、最終的な見直しをかけるという手続きで進めます。

　ユーザーインタフェース標準には、ボタンの種類、入力部品の個別仕様などが記載されます。エラーメッセージやインフォメーションメッセージの表示位置や、照会系画面／更新系画面、単票画面／一覧画面など、処理内容・表示形式による標準も決めておく必要があります。

画面遷移の標準化

　画面遷移は幾つかのパターンに分類できます。業務に特化したものもありますが、一般的には次のようなものを挙げることができます。

画面遷移パターンの例

パターンの例	説明
トランザクション	情報入力→確認→処理結果表示
取り消し時の遷移パターン	ホームに戻る、直前の一覧画面に戻るなど
ドリルダウン	一覧表示→詳細表示
ウィザード	段階的に入力を促し最終的に複雑な情報を入力させる
長い処理のキャンセル	進捗バー表示とキャンセルボタン処理
エラー表示	エラー一覧画面表示 → 入力画面項目のハイライトなど
ポップアップ	メインの画面はそのままに、補足情報を別ウィンドウなどで表示する

　画面遷移についても標準化することで、以下のようなメリットが得られます。

• 設計者が迷わない（試行錯誤の時間が減る）
• システムの振る舞いが予測しやすくする（奇抜なものが作られにくくなる）
• 要件定義を円滑に進められる（共通認識の上に立てる）
• 業務への導入時のマニュアル作成や研修にも役立つ
• 共通の部品として提供できるようになり、実装コストが削減できる

画面イメージと遷移モデルへのユーザーインタフェース標準の適用

　画面イメージと画面遷移モデルに対して、ユーザーインタフェース標準を適用し、画面遷移モデルを正規化・マージ、画面要素の配置を最適化します。

ユーザーインタフェース標準へのあてはめ

ユーザーインタフェース標準適用後の画面例

　ユーザーインタフェース標準の適用は、画面仕様定義の後続作業となります。システム要件定義フェーズで行うか、概要設計で行うかは、プロジェクトによって異なります。

　全ての画面にユーザーインタフェース標準を適用した状態でユーザーと要件を合意したい場合もあるでしょう。このような場合、標準の策定と開発フェーズで必要になる画面フレームワークの方式設計などを十分時間をかけて検討しておく必要があります。アジャイル開発では、画面アーキテクチャを先行して検討しておかないと、イテレーションプランニングがうまく進まないというリスクがあります。

　要件定義では、主要な画面についてのみ適用を実施し、設計以降で個別の画面について行うという手段もあります。

まとめ

　今回は画面仕様について、システム開発地図の成果物と作成手順を説明してきました。

　プロジェクトごとに方針も違えば、顧客の思いれも大きいところで調整に難航することが多い部分です。下手をすると、リリース直前まで仕様変更対応が続くような状況に陥りがちです。

　そのため、漠然と進めるのではなく、要件定義フェーズ、設計フェーズの作業を明確にし、後工程の手戻りを極力少なくすることを目指しましょう。

　システム開発地図を使って成果物間の整合性を取りながら進めることで、精度の高い要件定義が可能になり、設計以降のフェーズの見積もしやすくなります。

　5回にわたって、システム開発地図を頼りに成果物を作成していく流れ、ポイントを解説してきました。

　システム開発に携わる人間の多くが、プログラマーや設計者という役割からスタートするのではないでしょうか。プロジェクト参加時点では、なぜかは分からないけどさまざまなことが決められているように見えて、実はさまざまなことが合意されて進められているわけではないという状況がよくあります。決まっているように見えることの決定理由や経緯は分からないことが多いため、それを変更する必要がある場合に判断する手段もなく、そのまま開発を進めるはめになります。

　結果、あまり役に立たない・誰も喜ばない効率の悪いシステムが出来上がります。

　全ての業務システムは、業務の一部として機能すべきです。業務において必要でなければ作っても意味がありません。間違って分析された仕様に基づいて正しく作っても意味がありません。そのため、業務の分析から、設計・実装までの追跡が必要となるのです。システム開発に携わる人間は、分析から開発まで全体のつながりを知った上で、自分の責任範囲で何が必要か・何を求められていて何を行うべきかを知り、納得して作業するべきではないでしょうか。少なくとも私はそうしたいと思っています。

　システム開発地図やその考え方が、皆さんの携わるシステム開発の道しるべとしてお役に立てば幸いです。

著者プロフィル：今田忠博

SIの現場でSE、PMなどを経験。SI現場で悲惨な体験をし、開発現場を効率的にしたいと2004年に豆蔵に移籍。アーキテクトやフレームワークの設計・実装、PM支援、要件定義コンサルタントなどの業務を経験。そもそも要求が間違っていると、そのあといくらがんばっても幸せになれないと理解する。現在は保守の効率化のため、自動打鍵テストの省力化に取組中。

著者プロフィル：近藤正裕

豆蔵 技術コンサルティング事業部に所属するITアーキテクト。ユーザー系企業でシステム開発、研究開発を担当し、2003年から現職。Java/.NET によるエンタープライズシステム開発を多数手掛ける。アーキテクチャ構築、フレームワーク開発、開発者向けガイド作成、各種自動化を実施してプロジェクトを推進するとともに、アプリケーション品質・開発効率の向上を目指す。