要件定義の打ち合わせで、ベンダーから「機能要件と非機能要件を整理してください」と言われ、戸惑った経験はないでしょうか。IT専任の担当者がいない企業では、こうした専門用語に初めて触れることも珍しくありません。「なんとなく意味は分かる気がするけど、自分たちが何を決めればいいのかが分からない」という状態に陥るのは、決して珍しいことではないのです。
機能要件と非機能要件は、システム開発において別々の役割を持っています。この2つの違いを理解しないまま進めると、「動くけれど使えないシステム」ができあがるリスクがあります。性能が遅すぎる、障害が多すぎる、セキュリティが弱い——こうした問題の多くは、非機能要件の見落としから生じます。
難しいのは、非機能要件はベンダーから積極的に提案されないケースがあることです。発注側から要望がなければ、ベンダーは実装しやすい標準的な設計を選びます。その結果、「リリース後に問題が発覚する」という事態が起きやすいのです。
本記事では、機能要件と非機能要件の違いから、なぜ非機能要件が見落とされやすいのか、そして発注者として打ち合わせで確認すべきポイントまでを具体的に解説します。次回のベンダー打ち合わせに向けて、確実に役立てていただける内容です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
機能要件と非機能要件の基本的な違い
機能要件と非機能要件は、システム開発の要件定義で必ず登場する2つの概念です。簡単に言えば、機能要件は「システムが何をするか」、非機能要件は「システムがどれくらいの品質で動くか」を定めるものです。
機能要件とは「システムが何をするか」を決めるもの
機能要件とは、システムが持つべき機能・振る舞いに関する要件です。ユーザーが操作したとき、システムがどう応答するかを定義します。
機能要件の例を挙げると次のようになります。
- 「商品を検索できる」
- 「カートに商品を追加できる」
- 「クレジットカードで決済できる」
- 「注文確認メールを自動送信する」
- 「管理者が在庫数を更新できる」
これらはすべて、システムが「何をするか」という機能の定義です。利用者が画面上で行う操作や、その結果として起きることが機能要件になります。発注側のビジネスパーソンが「こういうことがしたい」と考えていることのほとんどは、機能要件に当たります。
非機能要件とは「どれくらいの品質で動くか」を決めるもの
非機能要件とは、機能の「質」や「制約」に関する要件です。同じ機能でも、品質レベルが異なると、使い物になるかどうかに大きな差が出ます。
非機能要件の例を挙げると次のようになります。
- 「検索結果を2秒以内に表示する（性能）」
- 「年間稼働率99.9%を維持する（可用性）」
- 「個人情報を暗号化して保存する（セキュリティ）」
- 「利用者が1万人に増えても対応できる（拡張性）」
- 「障害発生から4時間以内に復旧する（運用・保守性）」
こうした要件は、ユーザーが直接「操作する」ものではありません。しかし、これらが不十分だと、機能がどれだけ揃っていても「使えないシステム」になります。
具体例で比較する——ショッピングサイトの場合
ショッピングサイトを例に、機能要件と非機能要件を対比してみます。
分類 | 要件の例 | 発注者のイメージ |
|---|---|---|
機能要件 | 商品を検索できる | 「検索機能が欲しい」 |
機能要件 | カートに入れて購入できる | 「購入フローを作りたい」 |
機能要件 | 注文履歴を確認できる | 「マイページが必要」 |
非機能要件 | 検索結果を2秒以内に表示する | ← 発注者から出てきにくい |
非機能要件 | 同時に1,000人がアクセスしても動く | ← 発注者から出てきにくい |
非機能要件 | 決済情報はPCI DSSに準拠して扱う | ← 発注者から出てきにくい |
表を見ると明らかです。機能要件は「やりたいこと」から自然に出てきますが、非機能要件は意識して確認しなければ抜け落ちやすいのです。打ち合わせでの「確認すべきこと」の多くは、この非機能要件に含まれています。
非機能要件の6大カテゴリを押さえる
非機能要件には多くの種類がありますが、IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」では、6つのカテゴリに整理されています。これを知っておくと、「どんな観点で非機能要件を考えるか」の全体像が把握でき、打ち合わせで「他に確認すべきことはないか」を自分でチェックできるようになります。
可用性——サービスを止めないためのルール
可用性とは、システムをどれだけ継続して使えるか（稼働率）に関する要件です。
- 稼働率: 「年間99.9%以上稼働する（ダウンタイムは年間8.7時間以内）」
- 復旧目標: 「障害発生から4時間以内に復旧する（RTO: Recovery Time Objective）」
- 定期メンテナンス: 「月1回、深夜2〜4時に保守作業を行う」
発注者への確認ポイント: 業務が止まったとき、どれくらいの損失が生じますか？それによって「どれくらい止まってよいか（許容停止時間）」が変わります。
性能・拡張性——スピードと成長への対応
性能・拡張性とは、応答速度や同時接続数、将来的なデータ量・利用者数への対応に関する要件です。
- 応答時間: 「通常操作の応答時間は3秒以内」
- 同時接続数: 「最大500人が同時利用できる」
- 拡張性: 「利用者が3倍になってもサーバー増設で対応できる」
発注者への確認ポイント: 今後3年でどれくらいユーザーが増える想定ですか？最初の設計でスケールアップできる余地を作っておくかどうかで、将来のコストが大きく変わります。
運用・保守性——使い続けるためのコスト
運用・保守性とは、システムをリリース後に継続して管理・維持するための要件です。
- バックアップ: 「データを毎日夜間に自動バックアップし、30日間保持する」
- 監視: 「障害発生時にアラートメールを運用担当者に自動送信する」
- ログ管理: 「操作履歴を90日間保存する」
発注者への確認ポイント: リリース後、誰がシステムを運用・管理しますか？社内に専任担当者がいない場合は、ベンダーに運用保守を委託するか、運用負荷が低い設計を最初から求める必要があります。
移行性・セキュリティ・システム環境
残り3つのカテゴリも、発注時に確認が必要な重要項目です。
移行性は、既存システムや旧データから新システムへの乗り換えに関する要件です。「旧システムのデータをどのタイミングで・どの形式で移行するか」「移行期間中は新旧両方のシステムを並行稼働させるか」などを定義します。現行システムがある場合は必ず確認が必要です。
セキュリティは、情報漏洩・不正アクセス・データ改ざんへの対策に関する要件です。「個人情報の暗号化」「二段階認証の導入」「脆弱性診断の実施」などが含まれます。個人情報を扱うシステムでは特に重要度が高まります。
システム環境・エコロジーは、システムを稼働させる環境（クラウドかオンプレミスか）や、消費電力・環境負荷に関する要件です。近年はSDGsの観点からも注目されています。
なぜ非機能要件は見落とされやすいのか
非機能要件が重要だと分かっていても、実際の要件定義では後回しにされがちです。これには構造的な理由があります。
非機能要件が後回しにされる3つの理由
理由1: 目に見えない・業務イメージがわかない
機能要件は「〇〇ができる」という形で業務に直結しているため、発注者がイメージしやすいものです。一方、非機能要件は「稼働率99.9%」「レスポンスタイム2秒以内」のように数値で表現されることが多く、それが業務にどう影響するかをイメージしにくいのが現実です。「とりあえず動けばいい」と考えて後回しになりがちです。
理由2: ベンダーから積極的に提案されないことがある
非機能要件の水準を高くすればするほど、開発コストは上がります。発注者から明示的な要求がなければ、ベンダーは標準的な（コストを抑えた）仕様を採用することがあります。「言われていないから入っていない」という状況が、後にトラブルの原因になります。
理由3: 後から変えると費用がかかる
機能要件の変更は比較的対応しやすいですが、非機能要件（特に可用性・性能・セキュリティ）は、システムの基盤設計に関わるため、リリース後に変更しようとすると大規模な改修が必要になります。最初の要件定義で決めておかないと、後から高いコストを払うことになります。
非機能要件の不備が引き起こす失敗パターン
非機能要件を後回しにした場合、具体的にどのような問題が起きるのか。実際によくあるトラブルのパターンを整理します。
パターン1: 処理が遅すぎて使われなくなる
「検索機能はある」のに、結果が表示されるまで10秒かかる。開発環境では数件のデータで問題なかったが、本番データ（数万件）では極端に遅くなった——というケースです。性能要件を事前に定義していれば、負荷テストで発見・対策できました。
パターン2: 障害で業務が長時間停止する
サーバーが停止したとき、復旧に丸一日かかった。可用性（復旧目標時間）を定義していなかったため、ベンダーも対応手順を準備していなかった——というケースです。稼働率や復旧目標時間（RTO）を最初に合意しておくことで防げます。
パターン3: 情報漏洩でビジネスリスクが生じる
個人情報を扱うシステムで、セキュリティ要件を明確にしないままリリースした結果、不正アクセスや情報漏洩が発生した。契約にセキュリティ要件が記載されていなかったため、責任の所在も曖昧になった——というケースです。
パターン4: ユーザーが増えてシステムがダウンする
当初は100人程度の社内利用を想定していたが、グループ会社へ展開したところ1,000人が使うことになり、サーバーが頻繁にダウンするようになった。拡張性の要件を定義していれば、最初の設計段階で対処できました。
こうしたトラブルに共通するのは、「リリース後に問題が発覚する」という点です。発覚した後の対応は開発段階の何倍ものコストがかかります。
発注側が押さえておくべき要件定義のポイント
「では実際に、打ち合わせで何を確認すればいいか」——ここからは、発注者として具体的に動けるようになるための実践内容です。
機能要件：業務フローから「何をするか」を書き出す
機能要件は、自社の業務フローを整理することから始めるのが最も効率的です。
- 現在、人手でやっている業務をリストアップする
- それをシステムに置き換えたとき、「誰が・何を・どうする」かを書き出す
- 「システムが〇〇できる」という形に言語化する
例えば、「毎月の請求書を手作業でExcelで作っている」という業務があれば、「システムが自動で請求書を生成し、メール送信できる」という機能要件になります。
書き出した機能要件は、ベンダーとの打ち合わせで「これは入りますか？」と一つひとつ確認します。確認なしに「当然入っているだろう」と思い込むのは危険です。
非機能要件：ベンダーに確認すべき5つの質問
非機能要件は、発注者から自然に要望が出てきにくい領域です。以下の5つの質問を打ち合わせで必ず確認することをお勧めします。
質問1: 「稼働率と障害時の復旧目標はどう設定しますか？」 → 「99.9%稼働」「4時間以内に復旧」など、具体的な数値と合意形成が必要です。業務へのインパクトを伝えた上で、ベンダーと調整しましょう。
質問2: 「何人が同時に使う想定で設計しますか？ピーク時は？」 → 同時接続数・ピーク時の想定ユーザー数を伝えます。将来の拡張計画（3年後の想定）も共有できると、スケールアップに対応しやすい設計が選ばれます。
質問3: 「セキュリティ対策は何が含まれていますか？」 → 個人情報・機密データを扱う場合は、暗号化・アクセス制限・脆弱性診断が含まれるかを具体的に確認します。「標準的なセキュリティ対策を実施します」という曖昧な回答は追加確認が必要です。
質問4: 「リリース後の運用・保守はどう対応しますか？」 → バックアップの頻度・障害時の連絡フロー・バージョンアップ対応など、リリース後のサポート体制を確認します。「保守契約」の範囲と費用も明確にしておきましょう。
質問5: 「現行システム・データの移行はどう進めますか？」 → 既存のExcelや旧システムのデータをどのタイミング・どの形式で移行するかを確認します。移行期間中の業務継続方法（新旧並行稼働の有無）も重要なポイントです。
要件定義書でどう記載するか
機能要件・非機能要件は、最終的に「要件定義書」という形で文書化され、ベンダーとの合意の根拠になります。重要なのは**「動くシステムを作る」という目的ではなく、「合意した品質基準を明文化する」ために作成する**という認識を持つことです。
要件定義書に記載された内容が、開発完了後の検収基準になります。非機能要件が曖昧なまま（「速いシステム」「安全なシステム」など）だと、リリース後に問題が起きた際、ベンダーの責任を問いにくくなります。数値で合意できるものは数値で記載することを徹底しましょう。
機能要件・非機能要件の定義を進める手順
実際の要件定義は、どのような順序で進めると良いのでしょうか。
まず機能要件を固める
最初に機能要件をできる限り明確にします。「何をするシステムか」が固まらないと、非機能要件の水準も決められないからです。
- 業務フローを可視化する: 現在の業務フローを図や箇条書きで整理する
- 「やりたいこと」を全部書き出す: 優先順位は後で決める。まず洗い出す
- 優先度をつける: 「必ず必要（Must）」「あれば良い（Want）」「将来的に検討（Future）」に分類する
機能要件のリストができたら、ベンダーと一つひとつ確認し、開発スコープを確定させます。
次に非機能要件を整理する
機能要件が固まったら、6大カテゴリを参照しながら非機能要件を整理します。
すべての項目を詳細に定義する必要はありません。自社のビジネス上のリスクが高い領域（例えば、個人情報を扱うならセキュリティ、ECサイトなら可用性）を優先的に検討しましょう。
IPA の「非機能要求グレード」は一般に公開されており、発注者が非機能要件の候補項目を確認するためのチェックリストとして活用できます。ベンダーに「こちらのグレードを参考に、我々のシステムではどのレベルが妥当ですか？」と確認するのも有効なアプローチです。
ベンダーと合意する
非機能要件は、発注者だけで決めるよりもベンダーに素案を作成してもらい、その内容を発注者が確認・交渉するという進め方が現実的です。
合意のポイントは2つです。
- 数値化できるものは必ず数値化する: 「速い」「安全」といった曖昧な表現を避け、「応答3秒以内」「稼働率99.5%以上」のように具体的な数値で合意する
- 優先順位を明確にする: 予算の制約がある場合、すべての非機能要件を高水準にすることはできません。ビジネス上のリスクが大きい項目を優先して水準を上げ、許容できる項目はコストを抑える、という判断が必要です
「最初から完璧を目指す必要はない」というのも重要なポイントです。要件定義は繰り返し議論して精度を上げるプロセスです。最初の打ち合わせでは「確認すべき観点を理解している」だけでも、ベンダーとの対話の質は大きく変わります。
まとめ
機能要件と非機能要件の違いを改めて整理しておきます。
比較軸 | 機能要件 | 非機能要件 |
|---|---|---|
定義 | システムが「何をするか」 | システムが「どれくらいの品質で動くか」 |
例 | 商品検索、カート、決済 | 稼働率、応答速度、セキュリティ |
発注者から出やすさ | 出やすい（業務イメージと直結） | 出にくい（数値・品質の意識が必要） |
リリース後の変更コスト | 比較的低い | 高い（基盤設計に関わる） |
非機能要件が軽視されがちなのは、発注者の知識不足ではなく、「目に見えにくい」「ベンダーから自動的には出てこない」という構造的な理由があります。だからこそ、発注側が先回りして確認する姿勢が重要です。
次の打ち合わせでは、ぜひ本記事で紹介した「5つの質問」を持参してみてください。ベンダーとの対話の質が変わり、要件定義の精度が高まります。
要件定義書の具体的な書き方や記載項目については、システム開発の要件定義を成功させる完全ガイドも参考にしてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
