「画面定義書って何を書けばいいの？」「画面定義書の作成で気をつけることは？」など、このような疑問をお持ちの方もいらっしゃるのではないでしょうか？
この記事では、画面定義書に含まれる内容や2つの作成パターン、作成時の5つのポイントについて解説しています。
また、画面定義書を作成する上での課題や、その課題を解決するためのサービスについても紹介しています。ぜひ、最後までご一読ください。
画面定義書とは？
画面定義書とは、システムで表示される画面のレイアウトを定義している成果物のことです。そのため「画面レイアウト」や「画面イメージ」とも呼ばれます。画面定義書は要件定義で決まった必要な機能を画面に起こしていきます。具体的には、システム画面に配置する部品や、その部品がどのような動きをするのかなどを画面定義書で決めます。画面定義書の作成は、クライアントと開発者の認識の齟齬を減らすという目的があり、非常に重要な成果物の一つです。また開発者がどのような画面を作成すれば良いかを理解しやすくする役割もあります。
アジャイルでは画面定義書は不要？
画面定義の手順はおおまかには、エンジニアが画面レイアウトを作成し、クライアントにレビューしてもらい、必要に応じて修正し、内容を承認してもらうという流れです。ウォーターフォール型の開発では、その後、基本設計を元に詳細設計を行い、コーディングをするという手順で開発が進んでいきます。ウォーターフォール型の開発では、水が上から下に流れるように上流工程で決めた内容に基づいて、下流工程が動くので内容を定めたドキュメントを作成が必須になります。要件定義で決めた内容を元に基本設計を行い、基本設計で決めた内容を元に詳細設計を行い、詳細設計の内容を元に、製造・開発を行うという流れになるからです。
一方、アジャイル開発ではドキュメント作成よりも実際に動くものを作るコーディングの方が重視されるので、中には画面定義書は不要、と考える方もいます。素早く実際に動くものを作るのであれば、いちいち画面設計などせずにいきなり作ってしまった方が確かに早く、柔軟に変更に対応することができます。しかしアジャイル開発は決してドキュメントが不要な開発手法ではありません。画面設計などの基本設計があるのとないのでは、その後の開発工程の生産性が大きく変わってきます。もちろん作るものの規模が小さい場合であれば、本当に不要というケースもあるでしょうが、アジャイルだから作らない、となると結局必要な機能を確認するという手前のフェーズを飛ばしてしまうということになり、誤ったものを開発してしまうリスクとなります。アジャイルであっても、納品物としてきれいな画面定義書を作らないまでも、最低限認識合わせが行えるレベルでは画面定義書を作るべきでしょう。
画面定義書に含まれる内容は？
次に画面定義書に含まれる内容について、見ていきましょう。ここでは、4つの項目別に説明していきます。
書誌情報
「書誌情報」とは、プロジェクトの名前や画面の概要、画面名を記載します。
画面名については、論理名と物理名が決まっていれば、両方記載しておきましょう。
レイアウト図
「レイアウト図」は、その名の通り画面上にどのような情報、どのような部品を配置するかを示すものです。作成方法によって、CADツールなどで作成する場合もあれば、手書きで作成したレイアウトの画面キャプションを貼り付ける場合があります。
画面に配置する部品には、ブログの場合だとヘッダー画像や広告枠、カテゴリーメニュー、SNSリンクボタン、管理人情報などが挙げられます。
画面部品について
システムで用いる部品を、いくつかのパターンに定義します。部品の種類には次のようなものが使われます。
- テキストボックス
- リストボックス
- チェックボックス
- ラジオボタン
- ボタン
- 罫線
- 表
- 図
また、上で挙げたような部品の説明も記載していきます。部品の説明は画面ごと全てに記載せず、共通の情報としてまとめて記載しておくといいでしょう。
部品ごとの識別IDや、表、図の表示範囲についても記載しておいてください。
操作手順
「操作手順」では、画面レイアウトの操作手順について記載します。
画面定義書の作成におけるポイント
画面定義書の作成では、クライアントが画面の構成や機能について満足してもらえるように作成する必要があります。それと同時に、開発するシステムによっては、大量の画面レイアウトを確認する必要が出てくるため、効率よく確認するために必要な情報を漏れなく確認できるような画面定義書が求められます。
また、画面の構成やデザインに意識が集中しすぎて、機能や操作手順、事前に決定した制約事項の確認がおろそかにならないように注意する必要もあります。これらの項目の確認漏れが起きてしまうと、せっかく下流工程のコーディングに進んでも修正の必要が生じて、作業に大きな悪影響を及ぼしかねません。
ここでは、レビューの効率化と確認漏れを防ぐためのポイントを5つほど紹介していきます。
できるだけ共通化できるルールを設ける
画面定義書に出てくる部品は、なるべく共通化しておきましょう。部品やエリアの分割方法、配色、文字フォント、画面遷移のパターン、エラーの表示方法などにまつわる共通のルールを詳細に決めておくことで、レビューの効率が上がります。
表の表示方法の補足
表はデータベースの検索結果を表すときによく用いられますが、検索結果に応じた表の動きまで記載されているでしょうか。
例えば、検索結果を表示する表の場合、表の行数よりも検索結果が多くなった場合、どのように表示するのかなどです。検索結果に応じた表の表示方法のルールの補足資料を用意しておくことでレビューの効率化が図れます。
入力項目の補足
画面にはユーザーが入力する情報と、システムから出力されてくる出力情報があります。
これらの情報はユーザーの操作性、利便性に大きく関わるものです。画面レイアウトだけでは、どれが入力情報でそれが出力情報かがすぐにわかるようになっていないとレビューの効率化を妨げてしまいます。
補足資料を用いて、部品ごとにどれが入力情報でどれが出力情報なのかを記載しておきましょう。また、入力時に注意や補足が必要箇所についても、補足を入れておくといいでしょう。
区別しづらい部品の区別
これは部品の定義や画面によりますが、同じ矩形の部品であっても分類を分けている場合、区別ができるように補足をしておく必要があります。
クライアントのとの認識に齟齬（そご）が生まれてしまう原因にもなりかねるので、ひと目で区別ができるようにしておきましょう。
文字列のタイプの明記
文字列に関しても、あらかじめ固定されている文字列なのかや、出力される文字列、リンクが設定された文字列など、しっかりと明記しておかなければ、画面レイアウトでは確認できない可能性があります。
文字列のタイプについてもある程度ルール化できるのであれば、事前に決めておくといいでしょう。
画面定義書の作成における課題
ここまでで、画面定義書の作成パターンや内容、作成時のポイントについて紹介してきましたが、画面定義書の作成における課題とはどんなものなのでしょうか？画面定義書の作成時の課題について解説していきます。
画面定義書の作成の課題として大きいのが「考慮漏れ・定義漏れ」と「属人化」です。「考慮漏れ・定義漏れ」に関しては先ほど述べたように共通ルールの設置と補足説明の追加で解決できるため、ここでは「属人化」について説明していきます。
属人化とは、設計方法や内容が設計した本人以外ではわからなくなってしまい、他の開発者では開発を継続できなかったり、開発を再開するのに時間を要してしまうなどの状態を指します。一般的には従業員が突発的に仕事を休んだ場合や、退職したときなどに、他の作業者へ引き継ぎ作業が行われていないときなどに顕在化してきます。
システムの開発においては、ひとりで開発に当たることはなく、複数人の開発者でチームを組んで進めていきますが、携わる人数が多くなればなるほど属人化の影響を受けやすい環境と言えます。設計過程だけでなくプログラムのコーディングの場面でも起こりうる問題のため、属人化が起きないように、定義書の作成作業を標準化することが重要です。
まとめ
画面定義書の内容や作成パターン、作成におけるポイントなどについて説明してきました。画面定義書にはレイアウト図などがありますが、その後のシステムテストなどで非常に役立ちます。
また、開発者視点でも、コーディング時にシステムのイメージがしやすいなどの利点もあり、画面定義書は設計の中で重要な役割を担います。
しかし、部品の定義などの共通ルールの設定や、補足情報の追加をしないと、考慮漏れや定義漏れといった問題が発生する可能性もあるでしょう。。
クライアントとの認識の齟齬（そご）を減らし、開発の後半で修正が入らないような画面定義書の作成を行ってください。
