動画と記事で学ぶ / 設計・構築
ネットワーク要件定義を未経験者向けに説明。利用者への聞き方、速さ・停止条件の具体化、要件一覧の記入、未決事項、設計への引き継ぎを例で追います。
ここからは、記事でゆっくり確かめましょう。図や操作の例を見ながら、気になるところから読み進めてください。
「速くしたい」「止まらないようにしたい」。利用者の希望は、最初から設計できる数字で届くとは限りません。何の操作で困り、どんな状態なら業務を続けられるかを聞いて具体化します。
要件定義は、その条件を関係者と合意する工程です。営業PCから社内アプリを使う例で、聞き取りから一覧、未決事項、次の設計担当への引き継ぎまで見ていきます。
要件は条件、基本設計は方式、詳細設計は値
要件定義で決めるのは、満たしたい条件です。基本設計はその条件を満たす構成や方式、詳細設計は実装する具体値へ進みます。「アプリを使える」から「FWで制御する」、そしてIPやルールへつながります。
要件には自由に変えられない制約も関わります。既存回線を使う、予算の上限がある、停止できる時間が限られる、といった条件で選べる構成は変わります。
用語の補足：要件と制約は、何が違う？
要件は満たしたい条件、制約は自由に変えられない条件です。既存回線を使う、停止できる時間が決まっている、予算に上限がある、などは構成を選ぶときの制約になります。
| 工程 | 主な問い | 成果物の例 |
|---|---|---|
| 要件定義 | 業務で何を実現し、どの条件を満たすか | 要件一覧、通信要件、制約、合意事項、未決事項 |
| 基本設計 | その条件を、どの構成と方式で満たすか | 構成図、ネットワーク分割、冗長化、制御・運用方式 |
| 詳細設計 | その方式を、どの値で実装するか | IP表、接続表、機器パラメータ、ルール、試験への対応 |
成果物は、次の担当へ渡す資料です。要件一覧、通信一覧、制約、合意した内容、未決事項を残すと、設計者が前提を読めます。口頭で共有したつもりの情報を、読める形へまとめる仕事でもあります。
既存の機種やIPが制約なら、この工程でも技術情報を調べます。ただし「機器を2台買う」と台数を決めただけでは、業務上どんな条件を満たしたいかは分かりません。目的と確認方法から具体化します。
利用者の困りごとと、今の構成を一緒に聞く
利用者には、困る操作や業務への影響を聞きます。情報システム部門には現行構成と運用、セキュリティ担当には許可や記録の条件を聞きます。一人の回答だけでは、必要な前提がそろわないことがあります。
誰が、どこから、何のアプリを、どの時間帯に使うかを押さえ、既存の図、設定、測定値と照合します。表は質問の抜けを防ぐための材料で、すべてを同じ相手へ読み上げる台本ではありません。
| 確認する領域 | 質問の例 | 集める根拠 |
|---|---|---|
| 利用者・拠点 | 誰が、どこから、何人で使いますか | 利用者一覧、拠点一覧、稼働時間 |
| 通信・アプリ | どの端末から、どのサービスを使いますか | 接続先、認証方式、通信要件 |
| 性能・容量 | 遅くなる操作と時間帯はいつですか | 測定値、同時利用、増加見込み |
| 可用性 | どの障害で、どの業務を何分止められますか | 業務影響、停止許容、復旧手順 |
| セキュリティ | 許可する利用者と通信、管理権限は何ですか | 社内方針、権限一覧、ログ要件 |
| 運用・保守 | 誰が監視・変更・復旧を行いますか | 運用体制、連絡先、作業可能時間 |
| 移行 | 切替時間と、戻す判断はどうしますか | 現行設定、移行対象、停止合意 |
| 制約・予算 | 回線、設置場所、調達、予算の制約はありますか | 契約、電源・ラック、納期、予算枠 |
利用者は夜間も使いたくても、保守担当には停止時間が必要かもしれません。答えが違ったら、どちらかを設計者が推測で採用せず、業務への影響と制約を並べ、判断する人を決めます。
移行は新しい環境への切替、切り戻しはうまくいかなかった場合に元へ戻す対応です。作業できる時間に、戻す時間まで含められるかを聞くと、後の移行計画へつなげられます。
「速い」「止まらない」を、測れる言葉にする
「速い」なら、対象操作、現状の所要時間、利用人数や時間帯、目指す結果を聞きます。操作も測定条件も違う数字では、変更前後を比べられません。評価方法まで一緒に決めます。
「止まらない」なら、回線断、機器故障、保守停止のどれを想定するかを分けます。何の業務をどの程度止められるかによって、必要な対策と試験が変わります。
用語の補足：非機能要求って何？
何の機能を提供するかに加え、性能・可用性・運用などに求める条件です。「アプリを使える」だけでなく、どんな負荷・故障・保守の場面でも、どの程度使えればよいかを整理します。
| 曖昧な希望 | 聞き直す内容 | 合意する項目 |
|---|---|---|
| 速くしてほしい | どの操作が、いつ、何秒かかっていますか | 対象操作、測定条件、目標、評価方法 |
| 止めたくない | 回線断・機器故障・保守停止のどれですか | 対象障害、影響範囲、許容停止、復旧方法 |
| 安全にしたい | 何を誰から守り、誰に利用を許可しますか | 許可範囲、認証、ログ、例外 |
| 運用しやすく | 誰が、どの時間帯に対応しますか | 監視・通知・変更・復旧の分担 |
可用性は必要なときに使える性質です。機器や回線を複数用意する冗長化でも、切替後に何秒で使えるか、既存の接続が続くかは別の確認です。台数だけで業務への影響を言い切れません。
性能、可用性、運用などは非機能要求として整理します。IPAの非機能要求グレードは確認漏れを防ぐ参考になります。全部を最高にするより、業務への影響と費用・制約から必要な条件を合意します。
参考：IPA：要件定義・非機能要求に関する資料（2026年10月確認）
要件一覧には、確認方法も書く
要件一覧には、希望する条件と、満たしたかを確認する方法を書きます。NW-APP-01のようなIDを付けると、設計と試験でも同じ条件を参照できます。
「営業端末からアプリへ通信可能」だけより、代表端末で対象画面を使えること、対象外のポートは拒否されることなど、実施する操作と判定を示します。依頼した側も、この方法で結果を確認できます。
| 項目 | 説明用の記載例 |
|---|---|
| 要件ID | NW-APP-01 |
| 業務目的・対象 | 営業端末から指定の社内アプリを利用する |
| 条件 | 営業端末網から、アプリのHTTPS接続を許可する |
| 対象外・依存 | 管理・DNS・認証等の通信は別要件で確認する |
| 確認方法 | 代表端末でアプリ操作成功。対象外ポート拒否も確認 |
| 根拠・合意者 | 利用部門の確認結果と、業務・ネットワーク責任者の合意記録 |
| 状態 | 合意済み／確認待ちを区別し、確認待ちには担当と期限 |
下の例では、管理、DNS、認証の通信を別要件として扱います。一つのHTTPS条件に、まだ聞いていない必要通信を含めたつもりにならないためです。依存する条件も追える形に残します。
性能の数値には、単位、対象範囲、測定条件、判断者を付けます。未確定なら仮と書き、確定済みと区別します。数字が表に入っただけで正式な合意になるわけではありません。
決まっていない条件は、担当と期限を付ける
「利用人数は確認中」で止めると、誰が答えるかも、設計をいつ進められるかも分かりません。担当、期限、決まらない場合の影響を付けます。未決事項は、回答を得るための作業として管理します。
同時利用数は回線や機器の容量、停止可能時間は移行と切り戻し、通知の受け手は監視の設計に関わります。何が決まらないと何を決められないかを、表のように対応させます。
| 未決事項の例 | 必要な対応 | 影響 |
|---|---|---|
| ピーク時の同時利用数 | 利用部門が実績と増加見込みを回答 | 回線・装置の容量検討 |
| 保守で停止できる時間 | 業務責任者が作業枠と停止を合意 | 移行計画と切り戻し時間 |
| 障害通知の受け手 | 運用責任者が時間帯別の担当を決定 | 監視・通知・保守の設計 |
先に進めるため仮値を使う場合も、その根拠と見直す時期を残します。仮値を確定値に見せると、後の担当がそのまま調達や構築へ進む可能性があります。
合意後の変更には、理由と費用、期限、設計、試験への影響を調べます。会議で話して終えるより、合意した版を更新して関係者へ渡すことで、次に使う条件をそろえられます。
次の設計担当へ、何を渡せば進められる？
次の担当が設計を始めるには、合意した要件だけでなく、制約と未決事項も必要です。現行の構成、通信、変更履歴と合わせ、どの版を誰が確認したかまで渡します。
下の一覧は、資料があるかだけでなく、その資料で次の判断ができるかを見るために使います。要件IDを設計と試験へ対応させる方法も決めておくと、実装後に条件を追えます。
- 要件ごとに対象・条件・優先度・受入方法が分かる。
- 現行構成、通信一覧、制約、変更履歴がそろっている。
- 未決事項に担当者と期限、設計への影響が付いている。
- 業務・運用・セキュリティの関係者が合意した版を特定できる。
- 要件IDを設計・試験へ引き継ぐ方法が決まっている。
個人検証でも、最初に「PCから社内アプリを使う」「この操作ができれば成功」と書いてから図と設定を作れます。Pingが通っただけより、何の条件を確かめたかを説明しやすくなります。
仕事の経験を伝える際も、会議に出たことに加え、自分が何を聞き、どの条件を整理し、誰と合意して、どの資料へ残したかを示します。要件定義の仕事を、具体的な担当として伝える材料になります。
