「技術的な専門用語が多くて、ベンダーへの伝え方や製品選定の判断基準がよくわからない…」
ITシステム開発やDXプロジェクトにおいて、業務部門が主体となって業務要件を定義した後に待ち構えているのが「システム要件定義」のステップです。画面の項目や入力の流れといった業務機能だけでなく、システムの稼働時間、応答速度、セキュリティ、障害時の復旧体制、採用するクラウドやデータベースの選定など、検討すべき論点は多岐にわたります。
特に非エンジニアのDX担当者や業務部門のリーダーにとって、システム要件定義は「技術用語が多くて敷居が高い」「ベンダーや社内の情報システム部門にすべて任せてしまいたい」と感じられがちな工程です。しかし、この非機能要件やシステム基盤の前提を曖昧にしたまま開発を進めてしまうと、本番リリース後に「アクセスが集中すると画面が固まる」「夜間メンテナンスで使いたい時間に使えない」「問い合わせ窓口が決まっておらず現場が大混乱に陥る」といった深刻なトラブルを引き起こすリスクが高まります。
本記事では、システム要件定義の全体像と本質を整理した上で、機能要件と非機能要件の決定的な違い、IPA（独立行政法人情報処理推進機構）が策定した「非機能要求グレード」を活用した要件の可視化と合意形成の手法、失敗しない採用製品の選定基準、そしてリリース後の安定稼働を支える運用ルールの早期設計ポイントまで、分かりやすく解説します。
- システム要件定義の位置づけ：事業要件・業務要件からシステム要件へつなぐ役割と3つの構成要素
- 機能要件と非機能要件の違い：「やりたいこと」と「動くための前提」を整理し、手戻りを防ぐ視点
- IPA「非機能要求グレード」の活用法：6つの重要カテゴリと、コストバランスを考慮した合意形成のポイント
- 採用製品選定の3つのポイント：非機能適合・社内既存資産の活用・ランニングコスト（TCO）の評価軸
- 運用ルールの早期設計：3層の運用体制（ヘルプデスク・情シス・保守SE）とエスカレーションフローの整理
システム要件定義の位置づけと全体像
システム要件定義は、要件定義プロセス全体の締めくくりとなる極めて重要なフェーズです。ここではまず、要件定義全体におけるシステム要件定義の位置づけと、具体的にどのような要素を決定するのか、その全体像を確認していきましょう。
業務要件をITシステムへ落とし込む架け橋
上記の図「要件定義編の進め方」に示されている通り、ITシステムの要件定義は大きく3つのステップで段階的に進められます。
- 事業要件定義：なぜシステムを導入するのか（Why）、ビジネス上の目的・ゴールや投資対効果（ROI）を明確化する工程
- 業務要件定義：誰がどのような手順で業務を行うのか（Who/How）、業務フローや要求一覧、業務機能一覧を整理する工程
- システム要件定義（赤枠部分）：業務要件で導き出された機能を、どのようなITインフラ・基盤・製品・運用体制で実現するのか（With What/IT）を具体化する工程
業務要件定義では、利用部門（エンドユーザー）と対話しながら「営業活動の進捗をリアルタイムに把握したい」「見積書作成の承認フローを自動化したい」といった業務課題の解決策を言語化しました。しかし、それらの機能が「どのクラウド基盤上で稼働するのか」「何秒で応答すべきか」「万一の障害時に何時間で復旧すべきか」「稼働後の問い合わせに誰が対応するのか」といった前提条件が決まっていなければ、開発ベンダー（SIer）は正確な基本設計やインフラ構成の構築を進めることができません。
システム要件定義は、業務部門が描いた「やりたいこと（業務要件）」を、現実のITシステムとして安定稼働させるための「実現基盤の仕様と運用ルール」へ翻訳する、最後の架け橋となる工程なのです。
要件定義全体の進め方や、前工程である「事業要件定義」「業務要件定義」については、以下の個別ガイドで詳しく解説しています。合わせてご参照ください。
システム要件定義を構成する3つの柱
上記の図「システム要件定義の全体像」が示すように、システム要件定義は前工程のアウトプットである「提案依頼書（RFP）」「業務一覧」「要求一覧」「機能一覧」を入力情報として受け取ります。その上で、以下の3つの主要な検討要素（柱）を順次整理し、具体的な成果物として定義していきます。
- 非機能要件定義：IPAが公開している「非機能要求グレード」などを活用し、可用性、性能、セキュリティ、運用性などの基盤的品質要件を整理し、「非機能要求一覧」を作成する。
- 採用製品定義：非機能要件や予算、社内の既存システム環境を総合的に評価し、利用するデータベース、ミドルウェア、SaaS、パッケージなどを選定して「採用製品一覧」を作成する。
- 運用ルール検討：システム稼働後の問い合わせ対応や障害検知、保守対応の手順と体制を整理し、「運用フロー」や「運用体制図」の草案を策定する。
システム要件定義の最大の特徴は、「業務要件（機能）以外のすべての要件を決める工程」であるという点です。単にソフトウェアをプログラミングするための仕様を決めるだけでなく、稼働後のインフラ環境や日常の運用オペレーションまで見据えて合意形成を行うことが、プロジェクトを成功に導く土台となります。
機能要件と非機能要件の違いと重要性
システム要件定義を正しく理解し、ベンダーや社内エンジニアと円滑に対話するためには、「機能要件（Functional Requirements）」と「非機能要件（Non-Functional Requirements）」の違いを明確に把握しておく必要があります。
機能要件は「やりたいこと」、非機能要件は「動くための前提」
上記の図「非機能要件とは何か？（機能/非機能要求の相違点）」で整理されているように、両者の本質的な違いは「業務機能そのものか」それとも「システムを動かす基盤的品質か」という点にあります。
| 区分 | 機能要件（機能要求） | 非機能要件（非機能要求） |
|---|---|---|
| 定義 | 業務を遂行するためにシステムが備えるべき具体的な機能（やりたいこと） | システムが安定して稼働・利用されるための基盤的品質や制約（当然の前提） |
| 具体例 |
・顧客情報の登録・編集画面 ・受発注データに基づく在庫引き当て計算 ・月次売上レポートのPDF出力 |
・画面の検索応答速度は3秒以内 ・稼働率は99.9%以上（平日9:00〜21:00） ・システムダウン時は3時間以内に復旧 ・個人情報データの暗号化保存 |
| 主たる対話相手 | ユーザー部門・業務担当者・営業部門 | 情報システム部門・インフラエンジニア・セキュリティ責任者 |
| 顕在化のしやすさ | 業務イメージが湧きやすく、要望が出やすい | 「動いて当たり前」と思われ、見落とされやすい |
機能要件は「どんな画面があり、ボタンを押すとどう動くか」という目に見える振る舞いであるため、発注側（業務部門）からも活発に意見が出ます。一方で、非機能要件は「データベースのバックアップ頻度」や「通信の暗号化方式」といった技術的要素が多くを占めるため、業務部門からするとイメージが湧きにくく、検討が後回しにされがちです。
非機能要件が抜け落ちたシステムが直面するリスク
しかし、非機能要件が曖昧なまま構築されたシステムは、たとえ機能要件を100%満たしていたとしても、現場で使い物にならない「致命的な失敗作」となってしまいます。実務で頻発する典型的なアンチパターンには、次のようなものがあります。
- 月末処理時の画面フリーズ（性能・拡張性の欠如）：通常時は快適に動くものの、月末の締め日に全社員が一斉アクセスした途端にサーバーが高負荷で応答しなくなり、業務が停止する。
- 夜間バッチの突き抜け（スケジュール定義の不足）：日次売上データの集計バッチが想定より長時間かかり、翌朝の始業時間になっても前日のデータが反映されず営業活動に支障が出る。
- データ喪失と復旧不能（運用保守性・バックアップの不備）：クラウド障害やオペレーションミスでデータが破損した際、日次バックアップが世代管理されておらず、数日前の状態に戻すことすらできない。
- サイバー攻撃による情報漏洩（セキュリティの軽視）：外部からの不正アクセスやSQLインジェクション攻撃への対策（WAF導入や暗号化）が施されておらず、顧客情報が流出して社会的信用を失墜する。
このように、非機能要件はシステムの「命綱」です。「技術的なことは開発ベンダーに任せておけば大丈夫だろう」と丸投げするのではなく、発注側自身が「自社の業務において何が許容できて、何が許容できないのか」を主体的に判断し、ベンダーと共通認識を持つことが不可欠です。
IPA「非機能要求グレード」を活用した要件の可視化と合意形成
非機能要件の重要性は理解できても、実際に検討を始めると「どこから手を付ければいいのかわからない」「専門的すぎて発注側と開発側で会話が噛み合わない」という壁にぶつかります。そこで有効なのが、IPA（独立行政法人情報処理推進機構）が策定した「非機能要求グレード」です。
※参考：IPA「非機能要求グレード」公式ページ（情報処理推進機構）
非機能要求を整理する6つの重要カテゴリ
上記の図「非機能要求グレード 6つのカテゴリ」に示されているように、IPAの非機能要求グレードでは、システムに求められる非機能要件を以下の6つの大分類カテゴリ（全238項目）に体系化しています。
- 可用性：システムを継続して利用可能とするための要求。稼働率（例：99.9%）、運用スケジュール（夜間停止の有無）、耐障害性、災害対策（DR）など。
- 性能・拡張性：システムの処理能力と将来の拡張に関する要求。オンラインレスポンス速度、ピーク時の同時アクセス数、データ増加に伴うリソース拡張性など。
- 運用・保守性：システムの運用管理と保守サービスに関する要求。バックアップ頻度・保存期間、リソース監視間隔、計画停止の許容範囲、保守サポート体制など。
- 移行性：現行システムから新システムへの切り替えに関する要求。データ移行の対象範囲・方式、システム切り替え時期、並行稼働期間の有無など。
- セキュリティ：情報資産の機密性・完全性を守るための要求。データの暗号化、アクセス権限管理、不正監視、脆弱性診断、Webアプリケーションファイアウォール（WAF）導入など。
- システム環境・エコロジー：システムの設置環境や環境負荷に関する要求。データセンターの立地、消費電力・CO2排出量基準、社内IT環境ポリシーへの適合など。
ここで極めて重要な視点が、図の下部に描かれている「要求グレードと費用のバランス」です。例えば、稼働率を「99.9%（年間停止時間約8.7時間）」から「99.99%（年間停止時間約52分）」や「99.999%（数分以内）」へ引き上げようとすると、サーバーやネットワークの完全二重化、マルチリージョン構成、24時間365日の有人監視が必要となり、初期構築費だけでなく毎月のクラウド利用料や運用費が跳ね上がります。
「すべて最高レベル」を求めるのではなく、自社の業務影響度に見合った適切な水準を見極めることが、非機能要件定義における最大の肝となります。
失敗しない採用製品（パッケージ・SaaS・DB等）の選定基準
非機能要件の方向性が定まったら、次に行うのが「採用製品（ハードウェア、OS、データベース、ミドルウェア、SaaS、パッケージソフトウェアなど）の選定」です。自社開発（スクラッチ開発）する部分と、外部製品を組み合わせる部分を切り分け、どの製品を採用するかを合意形成していきます。
上記の図「製品選定時のポイント」に示されているように、製品選定においては以下の3つの評価軸をバランスよく評価することが不可欠です。
非機能要件を満たしているかの適合性確認
大前提となるのが、先ほど定義した非機能要件（稼働率、性能目標、セキュリティ基準、サポート体制など）をその製品が確実に満たせるかという点です。
例えば、どんなに機能が魅力的で操作性が優れたSaaSであっても、「自社のセキュリティポリシーで求められるIPアドレス制限やSSO（シングルサインオン）に対応していない」「APIの呼び出し制限（レートリミット）が厳しく、既存基幹システムとの大量データ連携に耐えられない」といった場合、採用することはできません。カタログスペックの機能一覧だけで判断せず、非機能要件との適合性を厳しく検証する必要があります。
社内既存製品の再利用による管理コストの抑制
2つ目のポイントは、「すでに企業内で使用実績のある製品やプラットフォームを集約して活用できるか」という視点です。
目新しさや特定の機能だけを理由に新しいデータベースや開発フレームワーク、クラウドサービスを次々と導入してしまうと、社内には以下のような「隠れた管理コスト」が重くのしかかります。
- 運用担当者・情シス部門の再教育コスト：新しい製品ごとに操作方法や監視手順をゼロから覚える必要がある。
- 二重の監視・パッチ適用負担：セキュリティ脆弱性情報の収集やバージョンアップ作業が製品ごとに個別発生し、運用が煩雑化する。
- トラブルシューティングの属人化：社内にノウハウがないため、障害発生時に原因究明や復旧が遅れやすくなる。
すでに社内で標準的に使われているデータベース（例：PostgreSQL、Oracle、SQL Server等）や共通クラウド基盤（AWS、Azure等）が存在する場合は、可能な限りそれらへ集約・再利用する方が、全社的なIT運用コストを大幅に抑制できます。
開発費だけでなく運用保守を含めた総コスト（TCO）評価
3つ目のポイントは、初期構築費用（イニシャルコスト）だけでなく、稼働後の運用保守費やライセンス費用を含めた総所有コスト（TCO：Total Cost of Ownership）が予算内に収まるかという点です。
ITシステムは導入して終わりではなく、稼働している限り「月額サーバー費用」「ユーザー数に応じたSaaSライセンス費」「ベンダーへの保守契約料」「定期的なOS・ミドルウェアのバージョンアップ費用」といったランニングコストが継続的に発生します。ランニングコストが高すぎると、企業の利益を恒常的に圧迫し、将来の新たなIT投資やDX推進の予算を奪ってしまうことになりかねません。
開発ベンダー（SIer）から提案を受ける際も、「初期見積もりの安さ」だけで飛びつくのではなく、5年間のトータルコストを試算した上で選定することが重要です。発注側と開発側がWin-Winの長期的なパートナーシップを築く上でも、持続可能なコスト構造の合意が欠かせません。
リリース後の混乱を防ぐ運用ルールの早期検討
システム要件定義の最後の重要タスクが、「運用ルール（運用体制・フロー・工数）の検討」です。「運用のことはリリース直前のテスト段階で考えればいい」と後回しにされがちですが、要件定義の段階で運用ルールを検討しておくことには大きなメリットがあります。
「どんな体制で問い合わせを受けるか」「どうやって障害を検知するか」を事前に考えておくことで、画面に必要なエラーログ出力機能や管理者向け通知機能など、見落としていた業務要件・機能要件に早期に気づくことができるからです。
運用ルールの策定では、以下の2つのポイントを押さえます。
役割に応じた3層の運用体制
運用と一言で言っても、対応すべき内容は「パスワードを忘れた」「データの修正方法を教えてほしい」という日常的な問い合わせから、「夜間バッチが異常終了した」という緊急障害まで多岐にわたります。これらを混乱なくさばくため、以下の3層の役割分担を明確にしておくことが推奨されます。
- ヘルプデスク（1次窓口）：エンドユーザーからの問い合わせを最初に受け付け、パスワード初期化やマニュアルに記載された操作案内、利用権限の付与など定型的な業務を迅速に処理する。
- 情報システム部門（判断・タスク管理）：ヘルプデスクで解決できない問い合わせの一次切り分けや、開発ベンダーへの作業依頼、改修要否の意思決定、タスクの進捗管理を行う。
- 保守担当SE / 開発ベンダー（2次・専門対応）：システムのプログラムエラー調査、データベースの直接修正、夜間バッチの復旧対応など、専門的な技術作業を実施する。
「誰が」「どこまでの権限を持ち」「どんな作業を行うのか」を組織間で合意しておくことで、リリース後の責任のなすり合いや現場のたらい回しを防ぐことができます。
問い合わせと障害対応のエスカレーションフロー
体制を定義したら、主要な業務イベント（問い合わせ対応、障害対応など）ごとに、図「運用フロー」のような具体的なエスカレーションの流れを整理します。
- 問い合わせ対応フロー：利用者がヘルプデスクに連絡 ➔ ヘルプデスクで解決できない場合は情シス社員へエスカレーション ➔ 情シスが判断して保守SEへ調査依頼 ➔ 解決策を利用者へ回答
- 障害対応フロー：監視ツールがシステムエラーを自動検知 ➔ 保守SEが一次原因を特定して暫定対応（サーバー再起動等）を実施 ➔ 情シスへ状況報告・影響範囲共有 ➔ 根本的な恒久対応（プログラム修正等）を計画・実施
要件定義の時点では、完成度40%〜60%のラフなフロー図や箇条書きのルールメモであっても十分な効果があります。後続の基本設計やテスト工程に進むにつれて詳細化していけばよいため、まずは関係者間で「全体の流れの合意」を取っておくことが大切です。
まとめと実践へのステップ
システム要件定義は、業務要件定義で定めた「やりたいこと」を、現実のITシステムとして安全・確実・持続可能に稼働させるための極めて重要な工程です。
- 3つの構成要素：非機能要件定義、採用製品定義、運用ルール検討を一体として進める。
- 機能と非機能の峻別：非機能要件は「動いて当たり前の前提」であり、ここが疎かになるとシステム全体が破綻する。
- IPA非機能要求グレードの活用：6カテゴリ（可用性、性能、運用、移行、セキュリティ、環境）の中から重要項目を抽出し、コストバランスを意識して合意する。
- 製品選定の3原則：非機能適合・社内既存資産の活用・総所有コスト（TCO）の観点で評価する。
- 運用の早期設計：3層の体制定義とエスカレーションフローの整理でリリース後の混乱を防ぐ。
技術的な専門用語が並ぶシステム要件定義ですが、本質は「ビジネスとITの健全な合意形成」にあります。業務部門、情報システム部門、開発ベンダーがお互いの強みを持ち寄り、対等なパートナーとして対話を重ねることで、真に現場に定着し成果を生み出すITシステムを築き上げていきましょう。
要件定義の全体像や、失敗を防ぐ思考法、前工程（事業要件定義・業務要件定義）については以下の記事で詳しく解説しています。
【DX人材育成・学習ロードマップ】
全社的な教育設計やご自身の学習計画の参考として、本サイトでは3つの役割に応じた学習ロードマップを公開しています。
経営層・管理職向け
DXの定義や必要性、組織変革を支えるスポンサーシップを最短で学びます。
一般社員向け（DXリテラシー標準 DSS-L準拠）
DXリテラシー標準(DSS-L)に準拠し、デジタル技術の基礎知識や変革マインドを身につけ、身近な業務改善や自社課題の発見へ主体的に関わる土台を作ります。
ビジネスアーキテクト・推進リーダー向け
既存事業の効率化から新規事業の開拓までをリードするため、プロジェクト推進法やチェンジマネジメント手法などを体得します。
コメント