要件定義と設計で作る7つの図｜画面遷移図・ER図とデザイナーの担当範囲

要件定義と設計の工程では、業務フロー図から画面遷移図、ER図、システム構成図まで、性格の違う図が並行して増えていきます。困るのは書き方そのものより、どの図をどの工程で確定させ、誰が原案を持つのかがプロジェクトごとに揺れることです。IPA「共通フレーム2013 第3部」は、画面の原案を利用部門が作ることを望ましいとする一方で、業務フロー図やER図の様式には踏み込んでいません。この線引きを知らないまま進めると、デザイナーとエンジニアの間に決めきれない領域が残ります。7つの図それぞれについて、確定させる範囲と担当者、そして規格が規定していない部分を整理します。

まとめ

要件定義から設計で作る図は、業務フロー図・画面遷移図・ワイヤーフレーム・デザインカンプ・プロトタイプ・ER図・システム構成図の7つに整理できます。担当の分かれ目は、IPA「共通フレーム2013 第3部」2.2.3.1のガイダンス項番3にある「画面の原案を利用部門が作成して、それを開発者が実装可能なレベルに変換することが望ましい」という記述です（以下、同文書からの引用は句読点のみ読みやすさのために改めています）。画面まわりの図は、デザイナーが白紙から作るものではなく、利用部門の原案を受け取って実装可能な粒度へ翻訳する成果物にあたります。

もうひとつ押さえるべきは、規格が規定していない範囲です。共通フレーム2013 第3部を全文検索すると、「業務フロー」「ER図」「エンティティ」「データモデル」「画面遷移図」「ワイヤーフレーム」はいずれも0件でした。ソフトウェア方式設計の解説（2.4.3.1.1）も「特定の手法に依存した定義を行っていない」と明言しています。少なくとも第3部を見るかぎり図の様式に規格上の正解はなく、探しても答えは出てきません。決めるのは社内標準か開発計画です。各図で何を確定させるかを先に合意するほうが早く、以下の章はその判断基準を図ごとに示します。

要件定義と設計で作る7つの図と担当工程

7つの図は、業務の姿を描くもの、画面を描くもの、内部構造を描くものの3系統に分かれます。系統が違えば原案を持つ人も、確定させるタイミングも変わります。まず全体像を1枚で押さえてください。

工程別に見た7つの図と機能一覧の担当者・確定範囲

表には機能一覧も入れてあります。これは図ではなく表形式の成果物ですが、業務フロー図と同じ工程で確定し、画面数やER図のエンティティ数の見積もり根拠になるため、図と一緒に管理したほうが漏れません。なお表中の「基本設計」は実務で広く使われる呼称で、共通フレーム2013 第3部の用語ではありません（後述のFAQで扱います）。

作る順序は表の上から下でおおむね固定です。業務フロー図と機能一覧で対象業務と機能範囲を確定させ、そこから画面遷移図で画面のつながりを決め、個々の画面をワイヤーフレームとデザインカンプで詰めます。ER図とシステム構成図は画面と並行して進められますが、機能一覧が固まる前に着手すると作り直しになります。

業務フロー図と機能一覧の中身は業務要件そのものなので、記載項目の粒度は業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説で扱っています。本記事は図の側に絞ります。

共通フレーム2013が図の様式を規定していない範囲

「要件定義の正式な成果物一覧」を探して規格にたどり着く人は多いのですが、共通フレーム2013 第3部（全42ページ）を全文検索した結果は次のとおりでした。「業務フロー」0件、「フロー図」0件、「ER図」0件、「エンティティ」0件、「データモデル」0件、「画面遷移図」0件、「ワイヤーフレーム」0件、「デザインカンプ」0件、「モックアップ」0件。実務で当然のように作られている図が、第3部には成果物として1つも名指しされていません。

代わりに書かれているのは、確定させるべき内容のほうです。2.2.3.1の項番1(3)「機能要件の定義」は、要件定義者の作業を「業務を構成する機能間の情報（データ）の流れを明確にし、対象となる人の作業及びシステム機能の実現範囲を定義する」と定めています。情報の流れを明確にせよとは書いてありますが、それを業務フロー図で描くのかDFDで描くのかBPMNで描くのかは指定していません。

方式設計側はさらに明示的です。2.4.3.1.1の解説は「『最上位レベルの構造を表現する方式で』とあるように、ここでは特定の手法に依存した定義を行っていない」と述べ、続けて「適用に際しては、開発計画に記述された標準、手法、ツールに従って具体化し、定義する」としています。ただしこの注記はソフトウェア方式設計についてのもので、図の様式全般に同じ扱いが明記されているわけではありません。とはいえ第3部が他の図の様式も規定していない以上、実務上はどの図も開発計画で決めることになります。

だから、社内標準を持たない組織が「正しい書き方」を外部に探しに行くのは順序が逆です。先に決めるべきは、どの図で何を確定させ、誰の承認をもって完了とするかです。様式はその後で、使うツールの都合に合わせて選べば足ります。

デザイナーが要件定義で担う成果物と関与しない領域

「デザイナーは要件定義に参加すべきか」という問いは、参加の有無ではなく担当範囲の問題です。共通フレーム2013には、この分担を直接示した一文があります。

画面の原案は利用部門、実装可能な形への変換が開発側

共通フレーム2013 第3部 2.2.3.1のガイダンス項番3に、次の記述があります。「画面の設計では、画面の原案を利用部門が作成して、それを開発者が実装可能なレベルに変換することが望ましい。また、画面の遷移についても利用部門が確認するとよい。」

この一文は2つのことを決めています。第一に、画面の原案を持つのは利用部門です。デザイナーが要件定義の場で白紙から画面を起こすのは、規格が望ましいとする形ではありません。第二に、画面遷移は利用部門の確認事項です。遷移の抜けはデザインの巧拙ではなく業務手順の抜けなので、業務を知る側が見ないと発見できません。

したがってデザイナーの成果物は、利用部門の原案を実装可能な粒度へ翻訳したワイヤーフレーム、配色や装飾を確定させるデザインカンプ、操作感を確認するプロトタイプの3つに絞られます。デザイン要件定義書という文書を別立てで作る場合も、中身は「利用部門の原案から何を確定させたか」の記録であって、要求そのものを新規に作る文書ではありません。発注者側から見た作業範囲の切り分けはWeb制作の要件定義とは？決める項目・進め方と発注者の作業範囲を解説にまとめています。

規格側には、画面の位置づけについてもう一つ手がかりがあります。ソフトウェア要件定義プロセスのガイダンス2.4.2.1.1は、外部インタフェースの例として「ユーザインタフェースとなる画面、帳票、ファイル」を挙げています。画面はソフトウェア品目の外部インタフェースとして扱われるということです。画面設計は見た目づくりではなく、インタフェース定義の一部だという整理になります。

デザイナーを要件定義に呼んでも効果が薄い場面

デザイナーの早期参加は無条件に有効ではありません。次の条件が揃っているときは、要件定義の段階で呼んでも手戻りが増えます。

• 利用部門が現行業務の手順を文書化できておらず、As-Isの業務フロー図がまだない
• 共通フレーム2013 第3部 2.2.3.1が業務要件の記述項目として挙げる「業務内容（手順、入出力情報、組織、責任、権限など）」が埋まっていない
• 対象が基幹システムの内部処理中心で、画面が既存の入力フォームの置き換えにとどまる
• 機能要件の範囲が未確定で、対象画面の数が見積もれていない

この4条件のうち上の2つが特に重いです。原案を出すべき利用部門が業務を言語化できていない状態でデザイナーを入れると、デザイナーが業務ヒアリングの代行者になり、規格が想定する分担が崩れます。この場合は業務フロー図の確定を先に済ませ、デザイナーの参加は画面一覧が固まってからにしてください。逆に、対象が新規の顧客向けサービスで画面が価値の中心にあるなら、要件定義の初期から入れる判断は正しいです。

画面遷移図で確定させる粒度と抜けの見つけ方

画面遷移図は、画面と画面のつながりを線で結んだ図です。作図自体は難しくありませんが、粒度を誤ると、レビューしても抜けが見つからない図になります。

1画面1ノードで書かない判断基準

画面遷移図でノードを画面単位に固定すると、同じ画面が状態によって別の遷移をする場合に線が集中し、条件が読めなくなります。分けるかどうかは、遷移先が変わるかで判断してください。ログイン前後で表示項目だけが変わるならノードは1つ、遷移先の画面が変わるならノードを分けます。

もう一点、正常系だけの図はレビューに耐えません。入力エラーで戻る先、タイムアウト時の遷移先、権限不足のときの表示は、業務手順の分岐そのものです。共通フレーム2013が「画面の遷移についても利用部門が確認するとよい」としているのは、この分岐が業務知識なしには埋まらないからです。レビューは開発チーム内で完結させず、利用部門に遷移先を1本ずつ確認してもらう形にしてください。

作図ツールの選び分け

画面遷移図のツールは、図を誰が更新し続けるかで決まります。デザイナーが更新するなら、デザインツール上で画面と一緒に管理したほうが同期の手間は小さくて済みます。エンジニアが仕様書と一緒に更新するなら、テキストで書ける記法のほうが差分レビューに乗せられます。Mermaidのようにテキストから図を生成する方式は後者に向いており、エディタでの表示手順や表示されないときの対処はVSCodeでシーケンス図・フローチャート自動生成｜Mermaidが表示されない対処で解説しています。

選定でよくある失敗は、作図の書き味だけで決めてしまうことです。要件定義の図は一度描いて終わりではなく、仕様変更のたびに更新されます。更新担当者が普段開かないツールを選ぶと、3か月後には図と実装がずれます。

ワイヤーフレーム・デザインカンプ・プロトタイプの作り分け

この3つは制作の順序として説明されることが多いのですが、順番で覚えると「どこまで作れば合意なのか」が曖昧になります。確定させる対象で区別してください。

3つを分ける基準となる確定対象

この分け方に沿うと、レビューの依頼先が自動的に決まります。ワイヤーフレームに配色を入れてしまうと、レビューが「この青は薄い」という装飾の議論に流れ、配置の合意が取れないまま先へ進みます。色を入れないのは手抜きではなく、議論の対象を配置に固定するための制約です。

プロトタイプは動きを確認する成果物なので、見た目の完成度を上げる必要はありません。逆に、画面が静止したまま「プロトタイプ」と呼ぶのは名前だけで、遷移や入力の検証にはなりません。動かないものを作るくらいなら、画面遷移図とワイヤーフレームで止めて工数を設計に回すべきです。

提案段階でプロトタイプを出すときの権利関係

受注前の提案でプロトタイプを提示する場面には、共通フレーム2013の供給プロセス側に注意書きがあります。1.2.2.3の解説は「提案で、プロトタイプ、体験版ソフトウェアの提供及び、デモンストレーションの実施時は、事前にこれらの権利関係を明確にする」と定めています。

提案時のプロトタイプは、受注できなかった場合に成果物の扱いが宙に浮きます。作成物の著作権が誰に帰属するのか、提示した画面設計を発注者が他社の開発に流用してよいのかを、提案書の段階で書面にしておいてください。デザインを含む提案は流用されやすく、口頭合意では守れません。

ER図とテーブル定義で決める範囲

ER図はデータの単位と関連を表す図です。要件定義でどこまで描き、設計でどこから引き継ぐかの線引きが、後工程の手戻りを左右します。

概念・論理・物理の3層と要件定義で止める線

ER図は3つの層で扱われます。概念レベルは業務に登場する主要な実体と関連だけを示すもの、論理レベルは属性とキーを含めて正規化したもの、物理レベルはデータ型やインデックスまで含めたテーブル定義です。要件定義で描くのは概念レベルまでで十分です。

理由は、共通フレーム2013の2.2.3.1が要件定義者に求めているのが「情報管理の観点、管理の単位、形式などを理解し分析する」ことであって、キーやデータ型の確定までは求めていないからです。同項は続けて「必要に応じて、システム要件定義（2.3.2）、システム方式設計（2.3.3）、ソフトウェア要件定義（2.4.2）、ソフトウェア方式設計（2.4.3）を使用してもよい」としており、必要なら設計プロセスを併用することも認めています。管理の単位とは、顧客を法人単位で管理するのか事業所単位で管理するのかといった判断で、これは業務側でしか決められません。データ型、主キーと外部キー、インデックス、NOT NULLや一意制約は、この判断が固まってから設計工程で詰めます。要件定義の場でカラム名を議論し始めたら、話が層をまたいでいるサインです。

エンティティ抽出でつまずく典型

エンティティとは、業務で管理の対象になる実体のことです。抽出でつまずくのは、業務上の帳票をそのままエンティティにしてしまうケースです。注文書という帳票には、顧客・商品・注文という3つの実体が同居しています。帳票単位でテーブルを作ると、同じ顧客情報が複数の帳票テーブルに重複します。

見分け方は単純で、「その情報は単独で管理されるか」を問うことです。顧客は注文がなくても存在するので独立したエンティティ、注文明細は注文なしには存在しないので注文に従属します。これは正規化でいえば、繰り返し項目を切り出す第1正規形と、主キーの一部にしか依存しない項目を別表へ移す第2正規形で機械的に整理される部分です。この判定を要件定義の段階で利用部門と合わせておくと、設計工程でのテーブル再編がほぼなくなります。

システム構成図とJIS X 0127の図記号

システム構成図は、サーバーやネットワーク機器の配置と接続を表す図です。作図の自由度が高いぶん、プロジェクト間で記法が揃わない図でもあります。

契約要件としての図記号指定

共通フレーム2013 第3部の1.1.1.2は、システム要件に含むことが望ましい「適合する規格」の説明で、要件の記述例を2つ挙げています。「設計表記法は、JIS X 0125決定表に従うこと」と、「機器構成図は、JIS X 0127 計算機システム構成の図記号と用法に従うこと」です。図記号の準拠先を、契約時のシステム要件として書けるという例示です。

JIS X 0127-1988「計算機システム構成の図記号と用法」は、適用範囲を「この規格は、情報処理システムなど、計算機システムの構成図に用いる図記号とその用法を定める」と定めています。発注者側が複数ベンダーの構成図を並べて比較する必要があるなら、図記号の準拠先を要件として書く手は有効です。ただしJIS X 0127は1988年制定と古く、今回は日本産業標準調査会のデータベースにアクセスできず現行性を確認できませんでした。実際に契約へ書く前に、規格が有効か改正されていないかを同データベースで確認してください。

一方で、社内システム1件の開発に規格準拠を要求するのは過剰です。ベンダーが1社で、図を読む相手が固定されているなら、社内標準の記法で揃えるほうが速く、レビューも通ります。準拠指定が効くのは、読み手が組織をまたぐ場合に限られます。

アーキテクチャ図との使い分け

アーキテクチャとは、システムを構成する要素と、その要素どうしの関係や設計の指針をまとめた構造のことです。システム構成図とアーキテクチャ図は、しばしば同じ意味で使われますが、答える問いが違います。システム構成図が答えるのは「どの機器がどこに置かれ、何とつながるか」で、調達と運用のための図です。アーキテクチャ図が答えるのは「機能をどの単位に分割し、どう依存させるか」で、実装方針のための図です。

共通フレーム2013では後者にあたるソフトウェア方式設計について、2.4.3.1.1が「特定の手法に依存した定義を行っていない」としています。レイヤー図で描いてもコンポーネント図で描いても規格上の適否はなく、開発計画で決めた標準に従えばよいという扱いです。両方を1枚に詰め込むと、運用担当者には冗長で開発者には粗い図になります。読み手ごとに分けてください。工程全体での成果物の位置づけは基本設計とは？システム開発での位置づけと成果物、要件定義・詳細設計との違いで整理しています。

よくある質問

画面遷移とは何ですか？

画面遷移とは、利用者の操作に応じて表示される画面が別の画面へ切り替わることです。ログイン画面で認証に成功するとメニュー画面へ移る、といった動きが該当します。これを図にしたものが画面遷移図で、画面をノード、操作や条件を矢印で表します。共通フレーム2013 第3部の2.2.3.1は「画面の遷移についても利用部門が確認するとよい」としており、遷移の妥当性は開発側だけで判断せず業務側の確認を経ることが望ましいとされています。

エンティティとは何ですか？

エンティティとは、業務で管理の対象となる実体のことで、ER図では四角形で表されます。顧客、商品、注文などが典型です。判定の基準は、その情報が単独で管理されるかどうかです。顧客は注文がなくても存在するので独立したエンティティになりますが、注文明細は注文なしには存在しないため注文に従属します。帳票をそのままエンティティにすると情報が重複するので、帳票に含まれる実体を分けてから整理してください。

デザイン要件定義書には何を書きますか？

デザイン要件定義書は、画面まわりで確定させた事項を記録する文書です。対象画面の一覧、画面ごとに表示する情報項目、遷移の条件、配色や書体などブランド上の制約、対応するデバイスと画面幅が中心になります。注意したいのは、この文書が要求を新しく作る場ではないことです。共通フレーム2013 第3部の2.2.3.1は画面の原案を利用部門が作成することを望ましいとしており、デザイン側の文書はその原案を実装可能な粒度へ変換した結果を残すものと位置づけられます。

外部仕様書と基本設計書は同じものですか？

実務では同義に扱われることが多い呼び方ですが、いずれも公的な規格用語ではありません。共通フレーム2013 第3部に登場する工程名は、システム要件定義、システム方式設計、ソフトウェア要件定義、ソフトウェア方式設計、ソフトウェア詳細設計、ソフトウェア構築などで、外部仕様書も基本設計書も名指しされていません（「外部仕様書」「基本設計」はいずれも第3部に0件）。したがって指す範囲は組織ごとの社内標準で決まります。他社と用語をやり取りするときは、名称ではなく「どの図と表を含むか」で確認してください。

要件定義の図はどのツールで作りますか？

ツールは図の種類ではなく更新担当者で選ぶのが実務的です。デザイナーが継続更新する画面まわりの図はデザインツール上で画面と同居させ、エンジニアが仕様書と一緒に更新する図はテキストで記述できる記法にすると差分レビューに乗せられます。共通フレーム2013の2.4.3.1.1は、ソフトウェア方式設計について「開発計画に記述された標準、手法、ツールに従って具体化し、定義する」としています。図の作成ツール全般を対象にした記述ではありませんが、拠り所を開発計画に置くという考え方は他の図にも当てはまります。着手前に開発計画へ明記してください。

関連記事

• 基本設計とは？システム開発での位置づけと成果物、要件定義・詳細設計との違い
• 要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説
• 機能要件とは？非機能要件・業務要件との違いと定義する5つの事項
• 業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説
• Web制作の要件定義とは？決める項目・進め方と発注者の作業範囲を解説