非機能要件とは｜基幹システムで決める6つの項目と中小企業向けの書き方の例

非機能要件とは、「何ができるか」以外の、止まらなさ・速さ・守り・移しやすさについての取り決めです。中小企業の基幹システムでは、IPAの「非機能要求グレード」が示す6つの項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）を、「何時間止まったら困るか」といった業務の言葉で決めれば足ります。この記事では、6項目の決め方と、そのまま使える記入例を解説します。

非機能要件とは：機能要件との違い

機能要件は「システムで何ができるか」、非機能要件は「その機能を、どんな条件で使い続けられるか」です。受注業務で比べると違いがはっきりします。

• 機能要件の例：受注を登録すると、在庫が引き当てられ、出荷指示が作られる
• 非機能要件の例：平日8時〜20時に使える。受注登録の画面は3秒以内に開く。月末の締め処理は翌朝の始業までに終わる。障害で止まっても、前日の終業時点のデータに戻して1営業日以内に再開できる

非機能要件は業務部門から要望として出てきにくい項目です。現場は「受注が登録できるか」は気にしても、「何時間止まったら困るか」は普段考えていません。その結果、要件定義で決めずに設計へ進み、稼働後に「遅い」「止まった」「データが戻らない」で揉めることになります。

JUASの「企業IT動向調査報告書2026」（東証上場企業などを対象とした調査）では、工程別の内製・外部委託の状況を調べています。「ほぼ内製」と「内製が多い」の合計は、機能要件定義で46.1％だったのに対し、非機能要件定義は37.6％にとどまりました。上流工程の中でも、非機能要件は外部に任せる割合が高めの工程です。発注側が意識して決めないと、ベンダー任せになりがちな項目です。

ただし、非機能要件は費用に直結します。止まってよい時間を「年に数分」とするか「年に数日」とするかで、サーバの冗長化、バックアップの方式、運用体制がまったく変わるからです。技術的な実現方法はベンダーに任せても、業務としてどこまで求めるかは発注者が決める必要があります。要件定義全体の流れは要件定義の進め方で解説しています。

非機能要求グレードの6つの項目

非機能要件を漏れなく決めるための物差しとして、IPA（情報処理推進機構）が公開しているのが「非機能要求グレード」です。最新版は2018年版で、ユーザとベンダーの間で非機能要件の認識がずれることを防ぐために作られました。項目一覧には238のメトリクス（指標）があり、それぞれに0〜5の6段階のレベルが設定されています。IPAでの整備事業は2018年度で終了していますが、資料は現在もIPAのサイトからダウンロードできます。

238項目をすべて決める必要はありません。まずは6つの大項目ごとに、次の問いに答えることから始めます。

IPAの利用ガイドでは、使い方を3段階で示しています。①開発するシステムに近い「モデルシステム」を選ぶ、②重要項目のレベルをグレード表で決める、③残りの項目を項目一覧で決める、という順番です。全項目を一度に確認するのは現実的でないため、影響の大きいものから決めるという考え方です。

中小企業はどのモデルシステムから始めるか

非機能要求グレードには、3つのモデルシステムが用意されています。それぞれの想定と、主な項目の初期値は次のとおりです。

※IPA「非機能要求グレード2018」のモデルシステムシートをもとに、主な項目を抜粋・要約しています。

中小企業の基幹システムは、多くの場合「社会的影響が限定されるシステム」が出発点になります。受注や出荷が止まると、自社だけでなく取引先にも影響が出るからです。

ただし、そのまま採用すると過剰になる項目があります。代表が稼働率です。このモデルの99.99％は、24時間365日動かす前提なら年間の停止が合計約52.6分という水準です。平日の日中しか使わない会社にとっては、そこまでの冗長構成は不要なことが多いでしょう。IPAの項目一覧でも、1日8時間・週5日稼働のシステムなら、年に1時間止まって99.95％、月に1時間なら99.4％になるという換算が示されています。

反対に、上げたほうがよい項目もあります。EDIで取引先から受注データを受けている、物流センターが夜間も出荷している、といった会社では、運用時間や復旧の目標をモデルの初期値より厳しく設定する必要があります。

モデルシステムは「初期値」であり、自社の業務に合わせて上げ下げするものです。次の章から、中小企業で判断が分かれやすい項目の決め方を見ていきます。

可用性の決め方：「何時間止まったら困るか」から逆算する

可用性は、非機能要件の中で最も費用に効く項目です。IPAの項目一覧では、主な指標のレベルが次のように定義されています。

※選択肢はIPA「非機能要求グレード2018 項目一覧」より。右欄は説明用の例です。

決め方のコツは、システムの数字から入らず、業務の影響から入ることです。部門長に次の3つを聞くと、レベルが自然に決まります。

1. 止まったときの代わりのやり方はあるか
   手書きの伝票やExcelで半日しのげるなら、RTOは1営業日以内で足りることがあります。代わりがなければ短くする必要があります。
2. どの時点まで戻れば再入力できるか
   1日分の受注を伝票から入れ直せるなら、前日時点への復旧（日次バックアップ）で十分です。EDIで大量に受けている場合は、受信データを取り直せるかも確認します。
3. 止まってよい日・時間帯はいつか
   月末の締め日や大型連休前の出荷ピークは止められません。この時期は保守作業を入れないといった運用ルールで対応します。

性能・拡張性、運用・保守性の決め方

性能・拡張性：ピークの日を基準にする

性能は平均ではなく、一番混む日で決めます。基幹システムなら、月末の締め日、請求書の一括発行日、棚卸日がピークになりがちです。

• 同時に使う人数：ピーク時に何人がログインし、そのうち何人が入力するか
• 画面の応答時間：受注登録・在庫照会など、よく使う画面で何秒以内に応答するか
• 締め処理の時間：月次の請求締めや原価計算が、何時から何時までに終わればよいか
• データの増え方：取引先・品目・伝票の件数が、5年後にどのくらいになるか
• データの保管期間：何年分を画面ですぐ見られるようにし、何年分を保管だけにするか

非機能要求グレードの項目一覧にも、業務量の増大率（1倍、1.2倍など）や、ピーク時のレスポンスの順守率といった指標が用意されています。数字を決めるときは、現行システムの伝票件数を月別に出してもらうのが近道です。

運用・保守性：「誰が見るか」まで決める

中小企業で抜けやすいのが運用の担い手です。バックアップを取る仕組みは入れても、成功したかを誰も確認していない、という状態はよく起こります。

• バックアップの取得と、取得結果の確認を誰がいつ行うか
• 障害の検知（監視）をベンダーが行うのか、自社で行うのか
• 保守のためにシステムを止めてよい時間帯（例：毎月第3土曜の夜）
• 操作の問い合わせ窓口と、受付時間
• パッケージやクラウドのバージョンアップを、いつ・誰が確認して適用するか

クラウドのサービスを使う場合は、可用性やバックアップの多くを事業者のサービス仕様が決めます。自社で決めた非機能要件と、サービスの公表仕様を照らし合わせる作業が必要です。考え方は基幹システムのクラウド化でも解説しています。

移行性、セキュリティ、システム環境の決め方

移行性：止められる日数から決める

移行性では、旧システムから新システムへの切替のやり方を決めます。モデルシステム「社会的影響が限定されるシステム」では、システムの切替は一斉に行う想定です。中小企業でも一斉切替が多い一方で、決めておくべきことは少なくありません。

• 切替のために業務を止められる日数：連休を使うのか、週末2日で切り替えるのか
• 移すデータの範囲：マスタは全件、取引データは直近何年分か、未完了の受注や発注残をどう扱うか
• リハーサルの回数：本番前に何回、移行の手順を通しで試すか
• 切り戻しの条件：何が起きたら旧システムに戻すか

データ移行の計画と照合の方法は基幹システムのデータ移行で、切替の判定基準は稼働判定と本番切替で詳しく解説しています。

セキュリティ：ランサムウェアを前提に考える

警察庁の「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（2026年3月）によると、2025年のランサムウェアの被害報告件数は226件で、被害企業の約6割を中小企業が占めました。被害組織へのアンケートでは、復旧に総額1,000万円以上かかった組織が5割を超え、1か月未満で復旧できた組織は5割強にとどまっています。サイバー攻撃を想定した業務継続計画（BCP）を策定済みの組織は約18％でした。

基幹システムが暗号化されると、受注も出荷も請求も止まります。非機能要件では、次の点を具体的に決めます。

• バックアップを、ネットワークから切り離した場所（オフライン）にも保管するか
• バックアップから実際に戻せるかを、年に何回試すか
• 利用者のIDとパスワードの管理、退職・異動時の権限の削除を誰が行うか
• 操作ログ・アクセスログを何年分保存するか
• 社外から接続する場合の方式（VPNや多要素認証など）

IPAは2026年3月に「中小企業の情報セキュリティ対策ガイドライン」第4.0版を公開し、基本の対策である「情報セキュリティ5か条」に「バックアップを取ろう！」を加えて6か条にしました。基幹システムの非機能要件を決める際の土台として使えます。

システム環境・エコロジー：取引先と法令の条件を拾う

この項目では、システムの外から課される条件を拾います。取引先から求められているセキュリティの基準、業界のガイドライン、サーバを置く場所（社内かデータセンターかクラウドか）、使う端末の条件などです。大手の取引先と電子的に取引している会社では、相手の基準が後から変わることもあるため、営業や購買の担当者にも確認します。

非機能要件を決める手順と、確認のチェックリスト

中小企業で非機能要件を決めるときは、次の5つの手順で進めると、2〜3回の検討会で一通りまとまります。

1. モデルシステムを選ぶ
   IPAのモデルシステムシートを見ながら、「社会的影響が限定されるシステム」を出発点にするかを決めます。社内だけで完結する小さなシステムなら「殆ど無いシステム」側から始めます。
2. 現行の実績を集める
   月別の伝票件数、締め日のログイン人数、過去1〜2年の障害と停止時間、バックアップの取り方を現行のベンダーや情シス担当から集めます。
3. 部門長に業務の影響を聞く
   「何時間止まったら困るか」「どの時点まで戻れば再入力できるか」「止めてよい日はいつか」を、販売・製造・経理の各部門長に聞きます。
4. レベルを仮置きし、費用への影響を確認する
   仮のレベルをベンダーに示し、レベルを1段上げ下げしたときに構成と費用がどう変わるかを聞きます。費用に見合わない項目は下げます。
5. 理由と前提を書いて確定する
   記入例のように、要件ごとに決めた理由と、利用部門が担う運用（再入力、バックアップの確認など）を書いて確定します。

確定前に、次の10項目を確認します。

• 運用時間（曜日・時間帯）が決まっている
• 障害時に戻す時点（RPO）と、再開までの時間（RTO）が決まっている
• システムで戻せない分を、誰がどう補うか（再入力など）が決まっている
• 大規模災害時の再開目標が、工場や倉庫の復旧計画と矛盾していない
• ピークの日の同時利用者数と、主な画面の応答時間が決まっている
• 締め処理など、時間の決まった処理の完了時刻が決まっている
• 5年程度先のデータ量の見込みと、保管期間が決まっている
• バックアップの確認担当と、復元テストの頻度が決まっている
• 移行するデータの範囲と、切替のために止められる日数が決まっている
• 権限の付与・削除の手順と、操作ログの保存期間が決まっている

記入例：非機能要件一覧（従業員100名の製造業）

ここまでの内容を、要件定義書に載せる形にまとめた例です。従業員100名、1工場・1営業所の金属加工業が、販売・生産・在庫・購買を刷新する想定です。平日8時〜20時に使い、土曜は一部の部署のみ稼働します。

※説明用の例です。数値は業務条件によって変わります。

この一覧のポイントは、「決めた理由・前提」の列です。理由が書いてあれば、ベンダーから「この水準だと費用がこれだけ上がる」と言われたときに、業務条件に戻って見直せます。理由のない数字は、交渉の場で根拠を失います。

よくある質問

まとめ

非機能要件とは、機能以外の止まらなさ・速さ・守り・移しやすさについての取り決めです。中小企業の基幹システムでは、IPAの非機能要求グレードの6項目に沿って、「社会的影響が限定されるシステム」を出発点に、自社の業務条件に合わせて上げ下げするのが現実的な決め方です。

決めるときは、システムの数字ではなく「何時間止まったら困るか」「どの時点まで戻れば再入力できるか」「一番混む日に何人が使うか」という業務の問いから入ります。理由と前提を書き添えておけば、費用との調整もしやすくなります。

要件定義書の他の章も含めた全体像は要件定義書の書き方で確認できます。自社の場合にどの水準が妥当か判断がつかないときは、無料診断で現状の課題とあわせて整理できます。