当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
インフラの要件定義を任されたものの、『アプリの要件定義とは何が違うの？』『お客さんに何を聞けばいいの？』と手が止まっていませんか。
結論から言うと、インフラエンジニアの要件定義は、システムがどのくらいの品質で動き続けるかという「土台の条件」を、発注側と合意する工程です。
この記事では、IPAの非機能要求グレードの6つの大項目に沿って、インフラで決めることを記入例付きで見ていきます。
インフラの要件定義とは？アプリを支える「土台の条件」を決める工程
インフラの要件定義では、サーバーやネットワーク、データの保管場所など、アプリが動く土台に求める条件を決めます。機能よりも「止まらないか」「速いか」「守れるか」「運用できるか」が中心になります。
インフラとは、システムが動くための土台のことです。サーバー、ネットワーク、データの保管場所、監視やバックアップの仕組みなどがここに入ります。
システム基盤と呼ばれることも多く、システム基盤の要件定義も、インフラの要件定義とほぼ同じ意味で使われます。
アプリの要件定義では、画面や帳票など「システムが何をするか」を決めるのが中心ですよね。
一方でインフラの要件定義は、「そのシステムがどのくらいの品質で動くか」を決める仕事なんです。
要件定義全体の意味から確かめたい方は、要件定義とは？意味をわかりやすく解説もあわせて読んでみてください。
機能要件と非機能要件のどちらを担当する？
要件は、大きく機能要件と非機能要件に分けられます。
| 種類 | 中身 | 主に担当する人 |
|---|---|---|
| 機能要件 | システムが何をするか（画面、帳票、データ、処理、外部連携） | アプリ側のSE |
| 非機能要件 | どのくらいの品質で動くか（性能、可用性、セキュリティ、運用、移行） | インフラエンジニアとアプリ側のSE |
インフラエンジニアが中心に担うのは、非機能要件の多くの部分です。
ただ、非機能要件はアプリの作りとも関わるので、アプリ側と一緒に決めていくのが基本になります。
アプリ側のソフトウェアの要件との分け方は、ソフトウェア要件定義とはで詳しく解説しています。
インフラエンジニアの要件定義では何をする？流れと役割
インフラの要件定義は、業務の話を聞くところから始まります。いきなり機器や構成の話をせず、「どう使われるか」を先に押さえるのがコツです。
インフラエンジニアの要件定義は、おおよそ次の流れで進みます。
- システムの目的と業務の使われ方を聞く
- 利用者の数や場所、使う時間帯を確かめる
- 非機能要件の項目ごとに、求める水準の候補を出す
- 発注側と水準をすり合わせ、費用との釣り合いを見て決める
- 決めた内容を非機能要件一覧にまとめ、承認をもらう
- 決まっていないことを課題一覧に残し、次の設計へ渡す
『構成図を描くのが要件定義だと思っていた…』という方も多いはずです。
実は、サーバーの台数や機器の選定は、要件定義の次の基本設計（方式設計）で決めることが多いです。
要件定義では、その前提になる「どのくらいの品質が要るか」を決めるところまでがひと区切りになります。
要件定義の段階でまとめておくもの
インフラの要件定義が終わる時には、次のようなものがそろっていると、設計の担当者が迷わずに進められます。
- 非機能要件一覧（項目ごとの水準と、その理由）
- 利用者の数や場所、使う時間帯をまとめたメモ
- 他のシステムや外部とのつながりの一覧
- 決まっていないことを書いた課題一覧
- 誰が何に合意したかを残した議事録
特に「その水準にした理由」を残しておくと、後から費用を見直す時の判断材料になります。
誰がどこを担当するのか
インフラの要件定義には、いくつかの立場の人が関わります。
| 立場 | 主な役目 |
|---|---|
| 発注側（業務部門、情報システム部門） | 業務の使われ方を伝え、求める水準と予算を判断する |
| インフラエンジニア | サーバーやデータの保管、監視、バックアップの条件を決める |
| ネットワークエンジニア | 拠点どうしのつなぎ方、通信の速さ、外部との出入り口の条件を決める |
| アプリ側のSE | アプリの作りから必要になる条件を伝え、すり合わせる |
ネットワークエンジニアの要件定義も、インフラの要件定義の一部として一緒に進むことが多いです。
会社や案件の規模によっては、一人のインフラエンジニアがネットワークまで担当することもあります。
非機能要求グレードの6つの大項目で整理する、インフラで決めること
インフラで決めることは、IPAの非機能要求グレードの6つの大項目に当てはめると漏れなく洗い出せます。項目ごとに「何を決めるか」と「聞き方」をセットで持っておくと、ヒアリングがぐっと楽になります。
非機能要求グレードは、非機能要件を発注側と開発側で合意しやすくするためにIPAが用意した道具です。
大項目は6つあり、それぞれのレベルを0〜5の段階で選ぶ方式になっています。
ここでは架空の題材として「全国の営業所の社員が、外出先からも日報を登録する社内システムの基盤を新しく作る場合」で考えてみます。
| 大項目 | インフラで決めること | 記入例（日報システム・例） |
|---|---|---|
| 可用性 | 動かす時間帯、止まった時にどこまで早く戻すか、予備の機器を持つか | 営業日の朝から夜まで使える状態にする。夜間の計画停止は認める |
| 性能・拡張性 | 同時に使う人の数、応答の速さ、データの増え方、将来の拡張 | 夕方に登録が集中しても待たされない。営業所が増えても対応できる |
| 運用・保守性 | 監視の範囲、バックアップの取り方、障害時の連絡の流れ | 毎日バックアップを取り、異常は情報システム部門に知らせる |
| 移行性 | 今のデータを移すか、切替の時期と方法 | 表計算ソフトで管理している過去の日報は移さず、閲覧用に残す |
| セキュリティ | 誰が使えるか、社外からの使い方、記録を残す範囲 | 外出先からは会社が認めた端末だけが使える。操作の記録を残す |
| システム環境・エコロジー | 機器を置く場所や制約、使う機器の条件 | 自社の機器は増やさず、外部の設備を使う前提にする |
『全部の項目を細かく決めないといけないの？』と思う方もいますよね。
ただ、すべてを最高の水準にする必要はありません。業務で本当に困ることを基準に、項目ごとに水準を選ぶのが大事なんです。
レベルを選ぶ時の考え方
非機能要求グレードのレベルは、高いほど品質が上がる一方で、費用も増えやすくなります。
例えば可用性なら、「少しでも止まると業務が止まる」のか、「半日止まっても紙でしのげる」のかで、選ぶレベルが変わります。
業務への影響ごとに、考え方の目安を並べると次のようになります。
| 止まった時の業務への影響（例） | 水準の考え方 |
|---|---|
| 止まるとお客さまへの対応がすぐに止まる | 予備の機器を持ち、早く戻せる水準を検討する |
| 止まると社内の作業が遅れるが、別の手段でしのげる | 計画停止を認め、戻す早さは費用と見比べて決める |
| 止まっても翌日にまとめて作業すれば困らない | 戻す早さより、データを失わないことを優先する |
日報システムの例なら、止まっても翌日にまとめて登録すれば業務は回ります。
そのため、戻す早さより「書いた日報が消えないこと」を優先して、バックアップの条件を手厚くする、という選び方ができます。
非機能要件一覧の記入例
決めた内容は、項目ごとに「要件」「確かめ方」「決めた人」をそろえて一覧にしておくと、後のテストでも使えます。
| 項目 | 要件（日報システム・例） | 確かめ方（例） | 決めた人（例） |
|---|---|---|---|
| 性能 | 夕方の登録が集中する時間帯でも、登録の操作で待たされない | 集中する時間帯を想定した負荷のテストで確かめる | 営業部門と情報システム部門 |
| 運用 | 毎日バックアップを取り、前日の状態まで戻せる | 戻す手順を実際に試して確かめる | 情報システム部門 |
| セキュリティ | 外出先からは会社が認めた端末だけが使える | 認めていない端末で使えないことを確かめる | 情報システム部門 |
非機能要求グレードは、2010年に最初に公開され、その後改訂版（2018年版）が出ています。発注側に説明する時は、表を一緒に見ながら「この項目はどのレベルが合いそうですか」と聞くと話が進みやすくなります。
ヒアリングで聞くこと：業務の言葉からインフラの条件に置き換える
発注側の多くは、インフラの言葉では答えられません。業務の言葉で聞いて、インフラの条件に置き換えるのがインフラエンジニアの腕の見せどころです。
「可用性のレベルはいくつにしますか？」といきなり聞いても、発注側は困ってしまいますよね。
そこで、業務の場面に置き換えて聞いてみるのがおすすめです。
| 業務の言葉で聞く質問（例） | 答えから決まるインフラの条件 |
|---|---|
| このシステムが止まったら、業務はどうなりますか？ | 可用性の水準、予備の機器を持つか |
| 一日のうち、一番使われる時間帯はいつですか？ | 性能の水準、混み合う時の余裕 |
| 社外や自宅から使う人はいますか？ | ネットワークの経路、セキュリティの条件 |
| データを間違えて消した時、いつの時点まで戻せれば困りませんか？ | バックアップの取り方と残す期間 |
| 障害が起きた時、誰に連絡が行けばいいですか？ | 監視の範囲、連絡の流れ |
| 今のデータで、新しいシステムに持っていきたいものはありますか？ | 移行の範囲と切替の方法 |
会話にすると、こんなやり取りになります。
「夕方に日報の登録が集中すると聞きましたが、待たされたらどうなりますか？」とインフラエンジニアが聞きます。
「登録を後回しにして、翌日まとめて書く人が出てしまうと思います」と発注側が答えます。
ここから、「夕方の集中する時間帯でも待たされない性能が要る」という条件が決まるわけです。
ネットワークの要件定義で確かめること
ネットワークエンジニアの要件定義では、拠点やつなぎ先ごとに条件を確かめていきます。
- どの拠点から、どのくらいの人数が使うかを確かめる
- 社外や外出先から使う時の経路と、許可する端末を決める
- 他のシステムや外部のサービスとやり取りがあるかを洗い出す
- 回線が切れた時に、別の経路で使い続ける必要があるかを決める
- 通信の記録をどこまで残すかを決める
『日報くらいなら、ネットワークは今のままで大丈夫では？』と思うかもしれません。
ただ、外出先から使う前提になると、社内だけで使う時とは守り方が大きく変わります。最初のヒアリングで、使う場所は一度確かめておきましょう。
「今と同じくらいで」という答えをそのまま要件にしてしまう。今の水準が分からないまま進むと、後から「前より遅い」「前は止まらなかった」と言われることになります。今の状態がどうなっているかも、数字や記録で確かめておきましょう。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
新規構築とリプレースで、インフラの要件定義はどう変わる？
- 業務の使われ方から水準を組み立てる
- 利用者の数や増え方を見込みで決める
- 移行の要件は少なめで済むことが多い
- 今の水準と不満を洗い出してから決める
- 今の利用状況の記録を根拠にできる
- 移行と切替の要件が大きな比重を占める
インフラの要件定義は、新しく作るのか、今のシステムを入れ替えるのかで力の入れどころが変わります。
新しく作る場合は、実際の利用状況がまだないので、業務の使われ方から見込みを立てるのが中心です。
入れ替えの場合は、今のシステムの記録が手元にあるぶん、根拠を持って水準を決めやすくなります。
その代わり、データの移し方や切替の日の段取りなど、移行の要件を細かく決める必要があります。
新しく作る時は、見込みの根拠を残しておく
新しく作る場合、利用者の数やデータの増え方は見込みで決めるしかありません。
『見込みが外れたら、要件定義の責任になるのでは…』と不安になる方もいるはずです。
だからこそ、「営業所の社員数をもとに見込んだ」のように、見込みの根拠を一覧に書いておきましょう。根拠が残っていれば、使われ方が変わった時にどこを見直せばいいかがすぐに分かります。
入れ替えの時に見落としやすいこと
『今のシステムと同じ構成でいいですよね？』と言われることもありますよね。
ただ、今の構成のままだと、当時は要らなかった条件が抜けていることもあります。
例えば、以前は社内だけで使っていたのに、今は外出先から使いたい人が増えている、という場面です。
入れ替えの時は、今の構成を写すのではなく、今の使われ方に合っているかを一つずつ確かめてみてください。
- 一番混む時間帯の使われ方を、記録から確かめる
- これまでに止まった時の原因と、戻すまでの流れを振り返る
- 利用者から出ている「遅い」「使いにくい」の声を集める
- 今のバックアップから実際に戻せるかを確かめる
- 保守の期限が近い機器や仕組みがないかを洗い出す
システム移行・リプレースの要件定義の進め方はシステム移行・リプレースの要件定義で、業務システムを新しく入れる時の要件定義はシステム導入・構築の要件定義で詳しく扱っています。
よくある相談に答えます
- インフラエンジニアの要件定義では、具体的に何をするのか
- 上流工程の設計構築や要件定義が、どんな仕事なのか分からない
- IPAの資料を読んでいるが、現場でどう使えばいいか分からない
インフラエンジニアの要件定義って、どんなことをやるの？
お客さんから要望を聞くところまではイメージできるけれど、その先が分からない、という相談はよくあります。
結論から言うと、聞いた要望を、非機能要件の項目ごとの水準に置き換えて合意するのが中心の仕事です。
この記事の6つの大項目の表のように、項目ごとに決めることを並べ、発注側と一つずつ水準を決めていきます。
決めた内容は非機能要件一覧にまとめ、次の基本設計で構成や機器を選ぶ時の根拠になります。
上流工程の要件定義と設計構築は、何が違うの？
インフラの上流工程として、要件定義と設計構築がまとめて語られることも多いですよね。
要件定義は「どのくらいの品質が要るか」を決める工程で、設計は「それをどんな構成で実現するか」を決める工程です。
構築は、設計どおりに機器や設定を整える作業になります。要件定義で決めた水準がないと、設計で構成を選ぶ根拠がなくなってしまうんです。
IPAの資料を読んでいるけれど、どう使えばいいか分からない
要件定義を学ぼうとIPAの資料を読み始めたものの、量が多くて使い方が分からない、という声もあります。
まずは非機能要求グレードの6つの大項目を覚えて、担当している案件で項目ごとに「何が決まっていて、何が決まっていないか」を書き出してみるのがおすすめです。
発注側の立場で要件定義を学ぶなら、IPAの「ユーザのための要件定義ガイド 第2版」も役に立ちます。業務部門の担当者向けに、つまずきやすい問題と解決のコツがペアで書かれています。
非機能要求グレード（IPA）の資料は、表を一緒に見ながら発注側と話す時にも使えます！
よくある質問
インフラエンジニアの要件定義では、何を決めますか？
サーバーやネットワーク、データの保管、監視やバックアップなど、システムの土台に求める品質の条件を決めます。非機能要求グレードの6つの大項目に沿って決めると漏れを防げます。
システム基盤の要件定義とインフラの要件定義は違いますか？
ほぼ同じ意味で使われることが多いです。どちらも、アプリが動く土台に求める条件を決める工程を指します。
ネットワークエンジニアは要件定義で何を担当しますか？
拠点どうしのつなぎ方や、社外から使う時の経路、外部との出入り口の守り方などの条件を決めます。インフラの要件定義の一部として、インフラエンジニアと一緒に進めることが多いです。
機器の台数や種類は要件定義で決めますか？
多くの場合、機器の台数や種類は次の基本設計（方式設計）で決めます。要件定義では、その根拠になる性能や可用性などの水準を決めておきます。
発注側がインフラに詳しくない時はどうすればいいですか？
「止まったら業務はどうなりますか」「一番使われる時間帯はいつですか」のように、業務の言葉で聞くのがおすすめです。答えをインフラの条件に置き換えるのは、インフラエンジニアの役目です。
まとめ
- インフラの要件定義は、システムの土台に求める品質の条件を決めて合意する工程
- 非機能要求グレードの6つの大項目に沿うと、決めることを漏れなく洗い出せる
- 発注側には業務の言葉で聞き、インフラの条件に置き換える
- ネットワークの要件は、使う場所とつなぎ先ごとに確かめる
- 入れ替えの時は今の構成を写さず、今の使われ方に合っているかを確かめる
コメント