画面設計書の作成とQA

先の企画プロセスで要件とサービスポリシーを整理し、IAとメニュー構造、ユーザーフローまである程度整理した後は、これらの内容を実際の画面単位に落とし込む画面設計書の作成を進めました。

最初は、画面にどのような機能が必要なのか、どのようなデータを表示するのかだけを整理すれば、画面設計書として十分だと考えていました。しかし、実際のプロジェクトで複数の画面を作成する中で、画面設計書と併せて考慮すべき内容は、想像以上に多いことに気づきました。

その後、開発段階に入ってからは、作成した画面設計書を基準に、機能が実装されているかを自分でテストしました。この過程で、企画段階で見落としていた例外的な状況や、開発中に発生したエラーを確認できました。また、企画で画面を設計し、開発した後、実際のテストまで行って初めて、一つの機能が正しく完成するのだということを経験しました。テスト中に見つかったエラーを再度確認して修正しながら、サービスのエラー率を下げることにも意識を向けるようになりました。

このようなプロセスを経る中で、画面設計とQAそれぞれの段階において、私が重要だと考える基準が生まれました。今回の記事では、実際のプロジェクトで画面設計書を作成し、QAを進める中で経験した試行錯誤と、その過程で整理した基準について紹介します。

1. 詳細画面の企画 – 画面設計書の作成で生じた試行錯誤と改善プロセス

私が実際に使用していた画面設計書の基本構成は、次のとおりでした。

[表紙] → [目次] → [改訂履歴] → [メニュー構造] → [画面一覧（IA）] → [権限マトリクス] → [フローチャート] → [共通ポリシー] → [詳細設計]

特に以下の内容は重要だと考え、画面設計書を管理するようにしていました。

1) 改訂履歴

プロジェクトを進める中で、意外にも多く気を配るようになったのが、文書のバージョン管理でした。

画面の企画は、一度作成したら終わりという作業ではありませんでした。

開発者と画面を確認しながら修正事項が発生することもあれば、ポリシーの変更に伴って既存の画面を再度修正することもありました。

問題は、文書が何度も修正され始めると、「今見ている文書は最新バージョンなのか？」

「この画面は、いつ、何が変わったのか？」を確認する必要が生じたことです。

そこで、プロジェクトを進めながら、ファイル名とバージョンを一定のルールで管理し始めました。

例えば、次のようにファイル名を統一しました。

프로젝트명_화면 설계서_v1.2_20260613.pdf

大きなポリシー変更や画面構造が大幅に変わる場合は先頭のバージョンを上げ、

文言の修正や一部コンポーネントの変更など、小さな修正の場合は末尾のバージョンを上げるという形で区別しました。

このようにバージョンを区別しておくと、以前の文書と現在の文書を比較したり、特定時点の画面を確認したりする際に、はるかに便利でした。

• バージョンのスケールルール：

-リリースおよび初回クライアント／チーム承認版：v1.0

-UIレイアウトの全面改訂、コアビジネスポリシーの変更など、大規模なアーキテクチャ変更：先頭のカウントアップ（例：v1.0 ➔ v2.0）

-マイナーなサブ機能の追加、アラート文言の変更、一部コンポーネントの改善：末尾のカウントアップ（例：v1.0 ➔ v1.1）

バージョン管理では、もう一つ試行錯誤したことがありました。

最初は、画面の小さな修正事項まで、すべて履歴シートに記録していました。

例えば、ボタン名を一つ変更したり、Descriptionの文言を修正したりすることまで、すべて履歴に追加していました。

最初は、変更事項を漏れなく残すのがよいと考えていました。

しかし、修正が積み重なるにつれて、履歴シートが非常に複雑になりました。

肝心の重要なポリシー変更の内容を確認しようとしても、細かな修正事項が一緒に混在しているため、必要な内容を見つけるのにかえって時間がかかりました。

そこで、それ以降は変更事項を二つに分けて管理しました。

大きな変更事項は文書の冒頭にある全体履歴に記録し、単純な文言の修正やコンポーネントの位置変更など、小さな変更事項は該当画面のDescriptionの横に修正表示を残しました。

例えば、該当画面にv1.2への修正、修正日、変更内容を表示しました。

このように変更したところ、文書全体の主要な変更履歴と、個別画面の詳細な変更事項を分けて確認できるようになりました。

特に、特定の画面を担当する開発者が、その画面の変更事項だけをすばやく確認するうえでも便利でした。

2) Description

詳細画面を設計する際は、画面の左側にWireframeを描き、右側にDescriptionを記載する方式で進めました。

Wireframeには、Input Box、Select Box、Radio Button、Checkbox、Data Gridなど、実際の画面に配置するコンポーネントを配置し、説明が必要な箇所には番号を付けました。

最初はWireframeの作成に集中していましたが、画面の企画を進めるほど、Descriptionの領域が何よりも重要であることに気づきました。

最初に画面を企画したときは、画面に必要な機能と基本的な動作を中心に記載しました。しかし、複数の画面を企画する中で、例外が発生した際にどのようなアラートを表示するのか、画面に初めて入ったときやデータがないときにどのような状態で表示するのかなど、正常な状況以外のケースまであらかじめ定義する必要があると感じました。

画面を作成する際は、初期状態、データの表示方式、ユーザーインタラクション、バリデーションと例外的な状況を確認するようにしました。

① 初期状態とデータの表示

まず、ユーザーが画面に初めて入ったとき、どのような状態になるのかを記載しました。

例えば、単に「テーブルを表示」と記載するのではなく、「テーブルはステータスの優先順位『Failed > Warning > Canceled > Running > Passed』の順に並べ、1つのテーブルに最大20件を表示する」のように、実装に必要な基準まで記載しました。

② ユーザーインタラクションおよび画面遷移ポリシー

ボタンやコンポーネントをクリックしたときに何が起こるのかも、具体的に記載しました。

例えば、「[修正]ボタンをクリックすると、画面遷移なしでMB_01_P01レイヤーポップアップを中央に表示する」、「コンボボックスの選択値を変更するたびに、下部のグリッドデータを更新する」

のように、画面遷移の有無やポップアップの形式まで併せて記載しました。

③有効性の検証と例外状況

正常な場合に画面がどのように動作するかは簡単に想像できますが、

• 入力値が誤っている場合

• 検索結果がない場合

• すでに処理されたデータを再度編集しようとする場合

• 権限のないユーザーがアクセスする場合

のように、正常な流れから外れる状況は見落としやすいものでした。

そこで、画面を作成した後には、「この機能が正常に動作しない状況では、どうすればよいのだろう？」ともう一度考える習慣を身につけました。

この過程を経て、画面設計書は単に画面を説明する文書ではなく、開発過程で発生し得る解釈の違いをあらかじめ減らすための文書なのだと分かりました。

2. QAテストケースを自分で作成して分かったこと

開発がある程度完了した後、私が作成した画面設計書どおりにサービスが実装されているかを確認するため、テストシナリオを作成しました。

初めてQAを行ったときは、単に機能が正常に動作するかどうかだけを確認すればよいと思っていました。

しかし、実際にテストシナリオを作成してみると、「何をテストするのか」をあらかじめ定義すること自体が重要なのだと分かりました。

そこで、テストケースには次のような内容を整理しました。

• テストID

• 機能およびモジュール

• 画面ID

• テストアカウントおよびデータ

• テスト前提条件

• テスト手順

• 期待結果

• 実際の結果

• テストステータス

• 不具合対応内容

テスト手順と期待結果は、できるだけ具体的に分けて作成しました。

実際にテストを行う人が、そのまま手順に従って実施できるレベルで作成しました。

このように作成したことで、テストを進める際に項目を漏らすことも減り、開発者に不具合を伝えるときも、どのような状況で問題が発生したのかを説明しやすくなりました。

テスト結果は、PASS、FAIL、BLOCK、TO DOにステータスを分けました。

正常に動作すればPASSとして処理し、期待結果と異なる動作をした場合はFAILとして記録しました。

FAILが発生した場合は、単に「できない」と記載するのではなく、実際にどのような動作が発生したのかを記録しました。

例えば、期待結果が「承認完了したデータには編集ボタンが表示されない。」だったにもかかわらず、実際の画面で編集ボタンが表示される場合は、「承認完了状態のデータを検索すると［編集］ボタンが表示される」

のように実際の結果を記載しました。

このように記録しておけば、開発者もどの条件で問題が発生したのかをすぐに確認できました。

また、ログインエラーのように、前提となる機能に問題があり次のテストを進められない場合は、BLOCKとして処理しました。

この過程を繰り返す中で、QAは単に機能を押してみる作業ではなく、企画段階で定義した要件と実際の実装結果を比較するプロセスなのだと実感しました。

3. まとめ

プロジェクトを初めて始めたときは、画面設計書を画面の見た目と機能を説明する文書だと考えていました。しかし、実際に複数の画面を作成し、開発者の方々と協業する中で、その考えは大きく変わりました。

画面を1つ企画するときも、「画面には何が表示されるのか？」で終わるのではなく、「最初にアクセスしたときはどのような状態なのか？」「データがなければどうなるのか？」「権限が異なると何が変わるのか？」「誤った入力があった場合はどうなるのか？」まで考えるようになりました。

また、画面設計が終わったからといって、1つの機能が完成するわけではないことも経験しました。開発後には、作成した設計書を基準に実際の実装結果を確認し、テスト過程で見つかったエラーや漏れを再度確認して修正するプロセスが必要でした。企画段階で定義した内容と実際の実装結果を比較しながらQAまで進めて初めて、1つの機能が完成するのだと考えるようになりました。

特に、最初からすべての状況を完璧に定義しようとするのではなく、開発者から質問を受け、QAで漏れていた部分を発見し、文書管理で不便を感じながら、少しずつ基準を作っていきました。

結果として、私が考える良い画面設計書とは、プロジェクトに参加する人々が同じ画面と同じ動作をイメージできるように基準を合わせる文書であり、QAとは、その基準どおりに実際のサービスが実装されているかを確認するプロセスだと思います。

ryu