画面案だけで発注できる？操作・表示・エラーを要件にする方法

画面要件は、配置と動きの両方を説明する

画面案は、欄やボタンなどがどこにあるかを話し合うための見取り図です。単純な紙の図でも、項目のまとまりや不足する案内を見つける助けになります。画面要件は、それに加えて、誰がどの条件で何を操作でき、何が見え、次にどう進める必要があるかを説明します。

たとえば「確認へ進む」というボタン名が描かれていても、何を確認するのか、選択が不足したらどう返すのか、押した時点で保存や送信をするのかは、名前だけでは決まりません。図と文章を使い、見た目の合意と動きの合意を分けて確認します。

発注担当がすべての細部を先に決める必要はありません。業務上どんな結果が必要かを整理し、具体的な実現方法や制約を開発担当と相談します。未確認の保存時点や権限を、図に描いたから決定済みと扱わないことが大切です。

英国政府のサービス設計ガイドは、作る前に試作で案を共有し、確かめる考え方を説明しています。また、試作用のコードをそのまま本番へ移さないよう区別しています。本稿では図案を検討材料にする参考として使います。英国の行政サービスの説明を、日本の民間企業に必須の方式や契約条件として扱うものではありません。GOV.UK：試作の目的と本番との違い。

背景の公開相談では、文字中心で要求を管理していた本人が、画面を文章だけで説明する難しさと、一枚の画像へ複数の要求が混ざる悩みを述べています。本稿の印刷会社と画面案は編集上の架空例であり、本人がこの方法を実施して成功したという話ではありません。本人の画面要件に関する質問と追加返信。

誰が何を終えたい画面かを先に決める

最初に、画面を使う一場面を選びます。この例で扱う仕事は、営業が校正確認を制作担当へ依頼する入力画面の要件を、図案と文章で照合することです。印刷会社のすべての受注・制作・請求を、一枚の画面案で決めようとはしません。

画面を使う立場

営業担当

依頼を受ける立場

制作担当

発注側で整理する立場

IT発注担当

営業担当には、依頼する際に何を選び、どんな内容を見直したいかを聞きます。制作担当には、その依頼を受けて何を確認する必要があるかを聞きます。IT発注担当は、両者の説明を画面案の該当箇所と結び、発注先へ確かめることを整理します。ここで示す役割名だけで、実際の権限や決定者まで確定するわけではありません。

GOV.UKの利用者理解の資料も、特定の解決策より、利用者が達成したい仕事と困りごとの背景を理解することを説明しています。本稿では、画面の配置を選ぶ前に、営業と制作の仕事を聞く観点へ応用しています。GOV.UK：利用者と、その人の必要を理解する。

一件の仕事全体で、誰とシステムがどんなやり取りをするかを整理したい場合は、通常と例外を一つの仕事で伝える方法が前段になります。ここでは、その仕事の一部を表す画面案と、操作への返答を詳しく対応させます。

項目名と番号を、操作・表示へ結び付ける

図の番号は、同じ場所を指して話し合うために使います。実際の項目名を隠す符号にせず、「案件番号の欄」「校正版の欄」「確認へ進む」の名前を主に使います。この記事では説明のため、それぞれを図の1・2・3として対応させます。これはシステム内の画面IDやメニュー名ではありません。

案件番号の欄（図の1）

何の案件について依頼するかを選ぶ箇所です。選択済みの画面案では、案件番号と校正版の両方を選んだ条件を置きます。ただし、実際の案件番号、その元データ、選べる範囲は未確認です。図の空いた欄へ実在の番号を作って入れません。

校正版の欄（図の2）

この依頼で確認したい版を選ぶ箇所です。ここでいう校正版は、校正確認の対象として選ぶ版を指します。どの版を選んでよいか、版をどう確定するかは別に確認します。「選択済み」と書いた案だけで、正しい版の選択や制作側の承認を証明しません。

「確認へ進む」の操作（図の3）

営業がこの操作を選んだ後、選んだ案件番号と校正版を見直せる確認画面を、要件の候補にします。この操作を保存や送信と同じ意味に置き換えないでください。いつ保存・送信するかは、現在の例では未確認です。

各部の説明には、使う人、操作する前の条件、選ぶ内容、操作、表示される返答、次にできることを結びます。「ボタンがある」と「その操作で必要な返答が見える」は別の確認です。配置が合っていても、違う版が表示されたり、不足したまま次へ進む案だったりすれば、動きの説明を確かめ直します。

案件番号の元や校正版の管理方法そのものを決める段階では、データ項目の意味と元情報を分ける方法へつなげます。画面に描かれた欄から、その値の出所や更新担当まで推測しません。

図で、選択済みと未選択の案を読み分ける

解説図を原寸で見る

この図を読んだ後の判断：図の欄や操作を、文章の要件候補と対応させて説明できます。一方、版の確定ルール、保存・送信のタイミング、案内文の承認、権限、実装後の動作は未確認です。営業・制作・発注先など、回答できる担当へ確かめてから、図案と文章を同じ内容へ直します。二つの案を、修正前後の結果や、実際の画面遷移の成功として扱いません。

不足案内は、場所・文・次の行動で説明する

校正版が未選択の別案では、同じ「確認へ進む」を選ぶ場面を想定します。そのとき、校正版の欄の近くに不足を伝える文案を置き、未選択を知って選び直してから進めることを、要件の候補にします。実際のエラー表示が確認できたという意味ではありません。

「エラーを出す」とだけ書くと、利用者が何を直せばよいかを説明できません。校正版が不足したという理由と、選び直す行動がつながるかを読み合わせます。ほかの入力がどう残るか、戻ったときに何を選び直すかも、必要な場合は追加で確認します。未指定の動きを、実装済みの機能として書き足しません。

W3C WAIのフォーム解説は、必要な入力をラベルで明確にし、不足などを利用者に分かる形で知らせることを扱っています。また、画面側だけの検証では安全性を確保できず、サーバー側でも検証が必要だと説明しています。本稿は案内の要件を検討する参考にし、図案だけで本番の安全性や読み上げの結果を認定しません。W3C WAI：入力の検証と案内。

文字の文案、見える位置、どの欄の不足か分かること、選び直す行動を一緒に考えます。実装後は、キーボードでの操作や支援技術への伝わり方も、必要な利用条件で別に確かめます。この記事の静止した図から、その確認を済ませたことにはしません。

二つの画面案と未確認を同じ項目で読む

選択済みの案は「何を確認して進むか」、未選択の別案は「何の不足を伝えて選び直すか」が違います。営業担当が「確認へ進む」を選ぶときの表示と次の行動を、同じ項目で比べます。どちらも画面案の条件であり、実際に保存・送信やエラー表示を確かめた結果ではありません。

次の二つは、この記事の架空の検討条件です。案件番号と校正版を選んだ案と、校正版を未選択にした別案を分けます。図に出す説明と、後で確認する実結果を混ぜないため、現在分かっている範囲をそのまま示します。

選択済みの案には、案件番号と校正版を確認できる表示と、確認画面で見直せるという要件候補があります。確認画面を描いたことだけでは、依頼が制作担当へ届いたとも、選んだ内容が保存されたともいえません。

未選択の別案には、校正版欄の近くの不足案内と、選び直してから進むという要件候補があります。「未確認」は、ゼロ件・不要・失敗・合格と置き換えません。営業が条件を選んだ案と、不足がある案の違いを、実施前後の成果として数えないでください。

未決の回答を受けたら、図と文章をどう直す？

原資料では、次の点が未確認です。確認先は会社の実際の役割と権限に合わせて決めます。営業の希望だけで、データ管理や保存・送信、権限まで一括して決める形にしません。

• 案件番号の元データ
• 版の確定ルール
• 送信/保存のタイミング
• 誤り文の承認
• 権限
• 実装後の動作

案件番号の元が分かったら

何を選べる欄にするか、利用者が案件を見分けるために何を表示するかを検討します。図の案件番号の欄と、その説明文を一緒に直します。元データが不明なままでは、選択候補が用意できることまで確定しません。

版を確定するルールが分かったら

校正版の選び方と確認画面で見直す内容を更新します。ルールに複数の条件があれば、どの条件の画面案かを分けます。「選択済み」と描いた状態から、すべての版が選べると広げません。

保存・送信のタイミングが決まったら

「確認へ進む」の返答と、その後の操作の範囲を見直します。確認画面へ進むだけなのか、その前後でどんな処理が必要なのかを発注先と確かめます。まだ回答がなければ、ボタン名に保存や送信を含むと推定せず保留します。

不足案内の文言が決まったら

未承認の文案を、合意した条件と文へ置き換えます。図の案内箇所と、文章の「どの不足に何を知らせるか」を同じ版で修正します。文だけ直して、古い文を描いた図を残しません。

権限や利用環境が分かったら

営業・制作などの役割ごとに、どの画面や操作を確認するかを分けます。スマホ・PC、キーボードなど必要な条件を確認計画へ反映します。役割名があるだけで、実権限が設定済みとはしません。

回答がまだ得られないなら

未決の理由と、回答できる担当、図や文章のどこに影響するかを残します。その部分を確定した発注条件へ混ぜず、先に検討できる箇所と分けます。依頼者から曖昧な了承があったことを、全条件の承認としてまとめません。

一つの回答が複数の箇所へ影響する場合もあります。たとえば版の選び方が変わるなら、校正版の欄だけでなく、不足案内、確認画面の表示、確認する具体例も見直します。図と文章の対応を保つために、変更した理由も関係者へ伝えます。

同じ版を読み合わせ、実装後の確認を決める

読み合わせでは、配置の好みを聞くだけでなく、営業担当に一つの操作をたどってもらいます。「この欄で何を選び、ここを押すと、何が見える想定ですか」「選んでいないときは、どこを直せばよいと分かりますか」と、図と説明を一緒に読みます。

1. 対象の図と文章をそろえる。どの案のどの版を見ているかを確認します。図だけが新しく、操作の説明が古い状態を避けます。社内の管理方法に合わせて、同じ内容へ戻れる形にします。
2. 営業の操作と、画面の返答を別に読む。項目を選ぶこと、確認へ進むこと、確認画面で内容を見直すことを対応させます。保存や送信の実施とは分けます。
3. 未選択の条件をたどる。どの欄が不足し、どの案内を見て、何を選び直すかを説明してもらいます。図の見た目だけでは分からない挙動を質問にします。
4. 回答と未決を図・文章へ戻す。決まった内容は両方へ反映し、まだ決まらない部分は質問として残します。その後、実装後にどこを誰が確かめるかを発注先と相談します。

実装後の確認では、合意した条件で必要な役割が操作できるか、選んだ内容が期待する場所に表示されるか、不足時に何を直すか分かるか、次の画面へ適切に進めるかなどを照合します。スマホで欄や案内が隠れないか、PCやキーボードでもたどれるかも、必要な対象で確かめます。実装していない図案をクリックしたことだけで、実動作を確認済みにしません。

読み上げやその他の支援技術の確認が必要な場合は、対象となる環境と方法を決めて実施します。静止画の読みやすさ、画面の見た目、実装のアクセシビリティは異なる確認です。この教材では実際の支援技術の結果も未確認です。

画面案だけの依頼を、具体的な説明へ書き直す

この一文では、画面の配置と、営業が終えたい操作、その後に見たい内容がつながりません。校正版が未選択の場合や、保存・送信を行う時点も、図から推測してもらうことになります。

この書き直しは、画面案を確定仕様へ変えるものではありません。何を検討し、何が分かれば条件を決められるかを伝えるための説明です。発注先との合意後も、対象の図と文章、実装後の確認を対応付けます。

まとめ：一つの操作と返答を対応させる

画面案から要件を整理するときは、項目名と図の番号を使い、誰が何を選び、操作後に何を見て、次にどう進むかを説明します。選択済みの案と、未選択などの別条件を分け、保存・送信・実装結果を図から推測しません。

回答を受けたら、図、操作の説明、不足案内、確認する条件を同じ内容へ直します。未決の部分は確認先を付けて残し、試作や図案の読み合わせと、本番で動作を確かめた状態を分けます。

最初の一歩は、営業が一件の校正確認依頼で「確認へ進む」を選ぶ場面を取り上げることです。案件番号と校正版の欄を指し、選ぶ前の条件、操作後に見たい内容、未選択時の案内を、業務担当と発注先へ説明してください。