Figmaで画面を仕上げてクライアントに渡すと、次に届くのは「ここはどう動きますか」という質問です。デザインの意図は伝えたつもりでも、実装側が知りたいのは画面の見た目だけではありません。デジタル・ガバメント推進標準ガイドラインは、要件として書く対象に画面の遷移や入出力の考え方、帳票、利用者の特性までを並べています¹。画面の外側まで添えて渡せるかどうかで、装飾の担当として扱われるか、設計の担当として扱われるかが分かれます。

1. 画面だけ渡すと、見た目の担当に見える

Figmaのファイルを共有した直後に返ってくる反応が「きれいですね」で終わると、次の工程で自分の役割が縮んでいきます。見た目の完成度が高いほど、逆に「あとは実装するだけ」という空気が生まれやすくなります。渡したものが画面の静止画に近いほど、判断の理由は渡した側の頭の中に残ったままになります。実装側が知りたいのは色や配置だけでなく、その画面がどんな処理の入口になっているかという部分です。

この差は経験の長さでは埋まりません。画面数を重ねてきた実績よりも、画面の外側まで言葉にして渡してきた実績のほうが、次の打診につながりやすくなります。渡す枚数ではなく、渡す情報の厚みが問われています。

実装側から見えている景色

実装を担当する立場から見ると、画面は完成品ではなく手がかりです。ボタンを押した後にどんな処理が動き、どんな条件で表示が変わるのかが分からないまま着手すると、後から仕様を聞き直す工程が増えます。質問が多い相手として扱われるか、判断材料を先に揃えてくれる相手として扱われるかは、渡す資料の中身で決まります。

往復が増えるほど、実装側は次の確認を先に済ませてから手を動かす方針に切り替えます。結果として着手が遅れ、公開までの時間が延びていきます。画面の枚数を増やすより、1枚の画面に添える情報を厚くするほうが、実装側の手が止まる回数を減らせます。

要件として書く対象は画面より広い

デジタル・ガバメント推進標準ガイドラインは、機能に関する事項として、処理内容や入出力情報・方法、入力と出力の関係等まで記載すると定めています¹。画面はこの機能を人の目に見える形にしたものにすぎず、要件として書く対象はその裏側の処理まで含まれています。

画面のデザインを担当する立場であっても、この裏側の処理を意識して渡す資料を組み立てると、実装側が確認する順番が変わります。入力された値がどこに渡り、どんな条件で出力が変わるのかという整理は、画面のデザインと同じ工程で扱ってよい範囲です。

見た目の担当という扱いから抜け出す一歩は、機能の追加ではなく、渡す情報の範囲を広げることです。画面の外側にある処理や入出力の関係まで言葉にして添えると、渡した資料そのものが要件の一部として読まれるようになります。

図の作成：Remogu編集部。要件として書く対象の広がりを整理したもので、統計データではありません

2. 画面の成果物は「遷移」と「入出力の考え方」まで

画面ひとつを渡すとき、実装側が本当に欲しいのは静止した見た目ではなく、次にどう動くかという情報です。ボタンを押した後にどの画面へ進むのか、入力した値がどう扱われるのかが分かれば、実装側は先の工程を自分で組み立てられます。

遷移図を添えるという発想

デジタル・ガバメント推進標準ガイドラインは、画面に関する事項について、画面の概要や表示イメージに加えて、画面の遷移や入出力の基本的考え方まで記載すると定めています²。画面の枚数がそのまま成果物の数になるわけではなく、画面と画面のつながりまで書いて初めて、要件としての形になります。

遷移図は複雑な図表である必要はありません。どの画面からどの画面へ進めるのか、進めない条件は何かを矢印で示すだけで、実装側が確認したい順番がはっきりします。1枚の遷移図が、口頭でのやり取り数回分の役割を引き受けてくれます。

画面の枚数を積み上げるより、画面同士のつながりを1枚にまとめるほうが、渡した資料の価値は高まります。手数を増やす方向ではなく、手数を減らす方向に力を使う発想です。

入出力の考え方を一言添える

画面の遷移と並んで欠かせないのが、入出力の基本的な考え方です。入力した値がそのまま表示に反映されるのか、条件によって別の処理につながるのか。この一言があるかどうかで、実装側が仮に置く前提の数が変わります。

たとえば入力欄の隣に「必須項目」とだけ書くのではなく、未入力のまま次に進もうとした場合にどう扱うかまで一言添えると、確認のやり取りが1往復減ります。難しい書き方をする必要はなく、画面の意図を短い文章にする作業です。

この積み重ねが、画面の担当から要件の担当へと見え方を変えていきます。渡す資料の分量を増やすことより、渡す資料の中身に判断の理由を残すことのほうが効きます。

画面に添える4つの記述

画面のデザインに添える情報を、実装側が読む順番で整理すると次の4つに絞れます。目的、遷移、入力の扱い、表示条件です。すべてを長文で書く必要はなく、画面ごとに数行ずつ添えるだけで十分です。次の表は、それぞれの記述に何を書けばよいかをまとめたものです。

この4つを画面ごとに書き添えておくと、実装を担当する側は仕様を推測する必要がなくなります。渡す資料の枚数は増えませんが、1枚に載る判断材料は明確に増えます。

記述	書く内容	実装側が助かる理由
目的	この画面が何のためにあるか、一言で示す	仕様に迷ったときに立ち返る基準になる
遷移	次にどの画面へ進めるか、進めない条件は何か	分岐を推測せずに実装できる
入力の扱い	入力した値をどう扱うか、未入力のときはどうするか	仮の前提を置かずに済む
表示条件	どんな条件で表示が切り替わるか	条件分岐の実装漏れを防げる

3. 出力は画面の外にもある

画面を作り込むほど、出力といえば画面の中の表示だと考えがちです。しかし要件として書く対象には、画面の外に出ていく出力である帳票も含まれています。印刷して残す書類や、他部門に渡す一覧も、同じ設計の対象です。

帳票も要件として書く対象

デジタル・ガバメント推進標準ガイドラインは、帳票に関する事項についても、帳票の概要や表示イメージ、帳票の入出力の基本的な考え方等を記載すると定めています³。画面の設計と同じように、帳票にも目的と入出力の考え方を添える対象があるという整理です。

帳票は画面より後回しにされがちですが、実装側にとっては画面と同じ重さを持つ成果物です。どの項目をどの順番で並べるか、どの条件で出力されるかという情報が抜けていると、画面の設計が終わっていても着手できない工程が残ります。

画面のデザインを担当する立場でも、帳票に載る項目の並びや、出す条件までは考えを言葉にしておく余地があります。全部を自分で決め切る必要はなく、判断の材料を渡す役割を担うということです。

減らす提案も設計の仕事

帳票については、業務のデジタル化を前提に最小限にすることが望ましいという考え方も明文で置かれています⁴。紙で残す出力を無条件に増やすのではなく、本当に必要な帳票かどうかを見極める視点も、要件を書く側に求められています。

この視点は紙の出力を否定するものではありません。業務のデジタル化が前提になった結果、残しておきたい帳票と、画面上の表示だけで足りる場面を仕分けるという話です。減らす提案ができると、実装側との打ち合わせで話せる範囲がひとつ広がります。

画面を作る役割の延長線上に、出力全体を見渡して整理する役割があります。装飾を整える力と、出力を仕分ける力は別の筋肉のようでいて、同じ資料の中で発揮できるものです。

図の作成：Remogu編集部。出力の対象を整理したもので、統計データではありません

4. 誰が使うかを、要件として書く

画面の色や配置を決めるとき、判断の理由を聞かれると答えに詰まることがあります。多くの場合、その理由は「誰が使うか」という前提の中にあります。利用者の姿を言葉にしておくと、色や配置の判断に理由が生まれます。

利用者の種類と特性を書き出す

デジタル・ガバメント推進標準ガイドラインは、ユーザビリティ及びアクセシビリティに関する事項として、利用者の種類、特性及び利用において配慮が必要な事項等を記載すると定めています⁵。ここでいう配慮が必要な事項とは、規格の詳しい基準の話ではなく、想定する利用者の姿を言葉にしておくという範囲です。

年齢層や利用環境、画面に触れる頻度といった特性を書き出しておくと、文字の大きさやボタンの間隔を決めた理由を説明できるようになります。感覚で選んだ配色ではなく、利用者の特性から導いた配色だと言えるようになります。

この作業は画面をデザインした後ではなく、着手する前に済ませておくほうが効きます。想定する利用者を先に言葉にしておけば、途中で配色や文字サイズを変える回数も減っていきます。

ユニバーサルデザインへの配慮

国民向けの情報システムの整備に当たっては、デジタルデバイドが是正されるよう、ユニバーサルデザインの考え方等に配慮するものと定められています⁶。特定の利用者だけを想定した画面ではなく、幅広い利用者が扱える画面という前提が置かれています。

この配慮は難しい技術を足すことではありません。操作の手順を短くする、表示の意味を文字でも伝える、といった小さな工夫の積み重ねです。規格の詳細に踏み込まなくても、利用者の幅を意識した設計は始められます。

利用者の輪郭をどこまで具体的に書けるかが、画面の担当と要件の担当を分ける境目になります。次の見出しでは、その輪郭を書き出すときに押さえておきたい観点を整理します。

利用者の輪郭を書き出す観点

利用者の輪郭は、年齢や職業といった属性だけでは十分に書けません。利用の頻度、利用する場所、画面に触れる時間帯、支援が必要な場面の有無まで含めると、配色や操作の設計に理由が生まれます。次の表は、書き出す際に押さえておきたい観点を整理したものです。

表の項目をすべて埋める必要はありません。想定する案件の性質に応じて、優先度の高い観点から言葉にしていくだけでも、渡す資料の説得力は変わります。

観点	書き出す内容	配色・操作への影響
年齢層	想定する年齢の幅	文字サイズや行間の基準が決まる
利用環境	画面に触れる場所や機器	タップ領域や配置の余白が決まる
利用頻度	日常的に使うか、たまに使うか	操作手順の省略可否が決まる
支援の必要性	支援が必要な場面の有無	表示の伝え方を文字と色の両方にするかが決まる

図の作成：Remogu編集部。利用者の輪郭を書き出す観点を整理したもので、統計データではありません

5. 実現できるかを、先に確かめる

画面を作り込んだ後で「この機能は今の仕組みでは動かせません」と言われると、作り直しの時間がまるごと発生します。実現できるかどうかを先に確かめておくと、この手戻りの多くは避けられます。

既製の機能を使う場合の書き方

クラウドサービス等が提供する機能を利用する場合には、その利用する機能について記載するものと定められています⁷。画面の中にある入力欄や通知の仕組みが、独自に作るものなのか、既製の機能を利用するものなのかを分けて書くという整理です。

この区別を先に書いておくと、実装側は独自開発が必要な範囲だけに力を割けます。逆にこの区別がないまま画面だけを渡すと、実装側はどこまでを作り込む必要があるのか、画面から逆算して推測する作業を背負うことになります。

デザインの段階で既製の機能を前提に置けるかどうかを実装側に確認しておくだけで、後の工程で発生する作り直しの範囲は小さくなります。確認する順番を早めることが、そのまま手戻りを減らす力になります。

非機能要件は先に検証する

非機能要件は技術的に検討を要する事項を多分に含むことから、日本産業規格等のほかRFI等を通じて広く情報を取得し、実現性等の検証を行うものと定められています⁸。表示速度や同時に扱える利用者数といった要件は、画面を描き終えてから確かめるものではなく、先に確かめておく対象です。

デザインを担当する立場から見ると、非機能要件は自分の範囲外に感じられるかもしれません。しかし想定する画面の動きが、実装側にとって実現しやすい範囲なのかを先に尋ねておくだけで、描く画面の前提が変わります。

描いてから尋ねるよりも、先に尋ねてから描くほうが、手戻りの量は小さくなります。実装側に聞いてから描くという順番を意識するだけで、渡す資料の完成度は一段上がります。

経験を4つの層で書き出す

これまでの経験を「何を作ったか」だけで語ると、装飾の担当という見え方から抜け出せません。着手した画面の数ではなく、実装側とどこまで擦り合わせて渡してきたかを言葉にすると、実績の伝わり方が変わります。次の表は、経験を4つの層に分けて書き出す型です。

4つの層を埋めきれない場合は、埋まっている層だけを先に言葉にしておくとよいでしょう。空欄を無理に埋めるより、実際に担当した範囲を正確に書くほうが、打診を受けた後の話がかみ合います。

層	書き出す内容	伝わること
見た目の設計	配色や配置の判断理由	装飾ではなく設計の判断ができること
遷移・入出力の整理	画面のつながりと入力の扱いを整理した経験	実装側との往復を減らせること
帳票・出力の整理	出力を仕分けた経験	画面の外まで見渡せること
実現性の確認	実装側に先に確認した経験	手戻りを見込んで進められること

図の作成：Remogu編集部。確認の順番による違いを整理したもので、統計データではありません

6. まとめ

画面だけを渡すと見た目の担当に見えてしまうのは、渡す情報が画面の内側で止まっているからです。遷移や入出力の考え方、帳票、利用者の特性、実現性の確認まで言葉にして渡すと、同じ画面が要件の一部として読まれるようになります。

この5つの視点は、どれも大きな作業を新たに増やすものではありません。今まで頭の中で判断していたことを、渡す資料の中に一言ずつ添えるだけで、実装側との往復は目に見えて減っていきます。

こうした渡し方ができる人材が関わる案件は、リモートでも進めやすい領域が広がっています。Remoguが扱う案件の90%以上がフルリモート可能です⁹。まずは自分の経験がどの案件に合うのか、登録して確かめてみるところから始められます。

7. よくある質問

画面の遷移まで書くのは、担当の範囲を超えることになりませんか

画面の遷移や入出力の考え方を書くことは、実装を代わりに行うことではありません。デジタル・ガバメント推進標準ガイドラインが画面に関する事項として遷移や入出力の考え方を挙げているとおり²、これは画面の設計に含まれる範囲です。実装の詳細を決めるのではなく、画面の意図を実装側に伝わる形にする作業です。

遷移図を描く力は、Figmaで画面を組み立てる力の延長線上にあります。新しい技能を覚える必要はなく、すでに頭の中にある画面の順序を、線と矢印で書き出すだけです。

帳票や印刷は自分の担当ではないのでは

帳票についても、概要や表示イメージ、入出力の基本的な考え方を記載する対象として挙げられています³。画面と同じ設計の対象であり、担当の外にあるものではありません。加えて帳票は業務のデジタル化を前提に最小限にすることが望ましいとも整理されているため⁴、どの帳票を残すかを考える視点も歓迎されます。

アクセシビリティはどこまで踏み込めばよいのか

本記事で扱うのは、利用者の種類や特性、配慮が必要な事項を要件として書き出すところまでです⁵。規格の詳しい基準への対応は、別の視点が必要な領域のため、専門に扱う記事に譲ります。まずは想定する利用者の姿を言葉にする段階から始めれば十分です。

政府向けのガイドラインは民間の案件でも参考になるのか

デジタル・ガバメント推進標準ガイドラインは国の情報システムを対象にしたものですが、要件として何を書くかという整理そのものは、民間の案件でも応用できます。画面・帳票・利用者の特性・実現性という4つの視点は、業種を問わず実装側との往復を減らす共通の型になります。

この型を意識して渡す資料を整えておくと、次に受ける打診でも同じ考え方を活かせます。まずは自分の経験に近いリモート案件を見て、条件を確かめてみるとよいでしょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（a 機能に関する事項）（2026年6月12日）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（b 画面に関する事項）（2026年6月12日）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（c 帳票に関する事項）（2026年6月12日）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（c 帳票に関する事項）（2026年6月12日）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（a ユーザビリティ及びアクセシビリティに関する事項）（2026年6月12日）
＊6 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（同）（2026年6月12日）
＊7 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（機能要件の定義）（2026年6月12日）
＊8 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（非機能要件の定義）（2026年6月12日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）