システム開発の非機能要件、性能の決め方と発注手順

非機能要件とは？ 何から決めればよいか

非機能要件とは、機能そのものではなく、速さや止まりにくさといった品質の水準を定めた要件です。まずIPA（独立行政法人 情報処理推進機構）の非機能要求グレードの6大項目に沿って、決める対象を洗い出すところから始めます。

非機能要求グレードは、非機能要求を定量的な水準で表現するための指標体系です。発注者と受注者の間で認識の食い違いを防ぐことを目的に公開されています（出典: IPA「非機能要求グレード」）。

非機能要件の6大項目

6大項目は次のとおりです（出典: IPA「システム構築の上流工程強化（非機能要求グレード）」紹介ページ）。

大項目	何を決めるか
可用性	運用時間、目標復旧時間、稼働率
性能・拡張性	応答速度、処理件数、将来の増加余地
運用・保守性	監視、バックアップ、保守の体制
移行性	既存データの移行方法と期間
セキュリティ	アクセス制御、ログ、脆弱性対応
システム環境・エコロジー	設置環境、電力、規格への適合

なお、非機能要求グレードは2018年版が公開されており、IPAは2019年3月に利用ガイド（活用編）と経営層向け読本の改訂を公表しています（出典: IPA「非機能要求グレード2018 利用ガイド[活用編]と経営層向け読本を改訂」）。

性能だけを決めても足りない理由

発注時に相談されるのは、ほとんどが性能の話です。しかし6大項目のうち性能・拡張性は1つに過ぎません。

たとえば可用性を決めずに進めると、障害時に何時間で復旧するのかが誰も答えられない状態で運用が始まります。可用性の項目には、運用時間、目標復旧時間、稼働率といった指標が含まれ、表現の例としては24時間無停止の運用時間、2時間以内の目標復旧時間、99.99%の稼働率といった水準が挙げられます（出典: Qbook「非機能要求グレードとは？6つのカテゴリと使い方・活用ポイント」）。これらは表現の例であり、自社に必要な水準は別に決める必要があります。

最初にやることは次の3つです。

1. 6大項目を紙に書き出し、自社にとって重要な順に並べる（所要時間の目安: 1時間）。
2. 各項目について、決めるのが自社か受注側かを振り分ける（つまずきやすい点: 全部を受注側に任せてしまうこと。水準の判断は業務を知る発注側にしかできません）。
3. 重要度の高い項目から、具体的な数値を入れる作業に移る。

水準の決め方は次のセクションで扱います。ここでは、性能の秒数だけを議論の対象にしないことを押さえてください。

自社の水準はどう決める？ 社会的影響度から逆算する

自社のシステムがどのモデルシステムに当たるかを決め、そこから水準を選びます。中小企業の社内システムに、社会基盤システム並みの水準は要りません。

非機能要求グレードのグレード表は、システムの社会的影響度に応じた3つのモデルシステムに対応しています（出典: IPA「システム構築の上流工程強化（非機能要求グレード）」紹介ページ）。まず自社がどれに当たるかを決めれば、水準の議論は一気に具体的になります。

3つのモデルシステムと自社の当てはめ

3つのモデルは次のとおりです。

モデル	例	想定される当てはめ
社会的影響がほとんど無い	小規模なWebシステム	社内の申請フォーム、予約受付
社会的影響が限定される	企業の基幹システム	販売管理、在庫管理、生産管理
社会的影響が極めて大きい	不特定多数が利用する社会基盤システム	中小企業の社内システムでは通常あてはまりません

中小企業の社内システムは、前の2つに当たることが多くなります。つまり、最上位の水準をそのまま求める必要はないという判断の根拠が、公式資料の側にあるということです。

判断が分かれるのは、社外の取引先が使うシステムです。止まったときに取引先の業務が止まるなら、社内だけで完結するシステムより一段上の水準で考えてください。

レベル0から5の考え方

各指標はレベル0からレベル5までの6段階で評価し、数字が大きいほど実現の難易度が高くなります（出典: 同紹介ページ）。難易度が上がるほど、費用と期間も増えます。

この段階表があると、発注側の伝え方が変わります。「速くしてほしい」ではなく、「この項目はレベル3で」と言えるようになるためです。

1. モデルシステムを1つ選び、社内で合意する（所要時間の目安: 半日）。
2. 重要な項目から順に、目安のレベルを仮置きする（つまずきやすい点: 全項目を高いレベルに置くこと。費用が跳ね上がります）。
3. 仮置きしたレベルを受注側に示し、費用と期間への影響を確認する。
4. 影響の大きい項目だけ、レベルを上げ下げして調整する。

このやり取りを見積もり前に済ませておくと、提案の比較もしやすくなります。実際の数値の書き方は次のセクションで扱います。

性能要件は何を数字で書く？ 応答速度と同時利用者数

性能要件は、どの操作が、どの条件で、何秒以内に終わるかという3点セットで書きます。条件を書かない秒数は、検収で必ず揉めます。

「画面表示は3秒以内」とだけ書かれた要件は、実務では機能しません。どの画面か、何件のデータが入った状態か、同時に何人が使っているときかで、結果がまったく変わるためです。

書き方の型と記入例

型は「対象の操作」「前提条件」「目標値」の3列で持つと、そのまま検収の確認表に使えます。

対象の操作	前提条件	目標値
受注一覧の表示	登録件数10万件、同時利用20人	3秒以内
受注データの検索	同上、検索条件3項目	5秒以内
月次集計の実行	1か月分、約3万件	10分以内
帳票のPDF出力	50ページ	30秒以内

目標値を決めるときは、現行の運用でどれくらい待っているかを起点にします。今より遅くならないことが最低線で、そこからどこを改善したいかを選ぶ順番です。

すべての操作に目標値を付ける必要はありません。1日に何十回も使う操作と、月に1回の処理では重みが違います。

ピーク時の同時利用者数の見積もり方

同時利用者数は、全社員数ではなく、同じ時間帯に実際に操作する人数で考えます。ここを大きく見積もると、必要のないサーバ構成に費用を払うことになります。

1. 対象業務の担当者数を数える（所要時間の目安: 30分）。
2. 1日のうち操作が集中する時間帯を特定する（つまずきやすい点: 月末や締め日など、月に数回だけ跳ね上がる山を見落とすこと）。
3. その時間帯に同時に画面を開いている人数を見積もる。
4. 将来の増加分を見込み、何年後にどれくらいまで伸びるかを添える。

将来の増加分は、性能・拡張性の項目で扱う話です。今の人数だけで決めると、増員のたびに作り直しになります。何人までなら構成を変えずに耐えられるか、という形で受注側に確認してください。

なお、ここで決めた数値は測定条件とセットで初めて意味を持ちます。測り方の揃え方は次のセクションで扱います。

測り方をどう揃える？ 条件を統一しないと比較できない

性能値は測定条件で簡単に変わるため、要件と同時に測定条件を決めます。当社の実測調査でも、条件を揃えずに比べると、差が機材の違いで説明できてしまいました。

当社がFeliCaの検出時間をOSバージョン別に調べたとき、いちばん危なかったのは「端末が違うだけではないか」と言われて結論が崩れることでした。同じ問題は、システムの性能検収でも起きます。

揃えるべき測定条件

当社の調査で実際に取った手当ては、次のとおりです。これは発注時の測定条件の決め方にそのまま応用できます。

揃えた条件	当社の調査での具体	発注時に置き換えるなら
計測区間	セッション開始からカード検出まで	操作の開始から画面表示完了まで
測定対象	全計測で同一のカード1枚	同一のデータ件数と同一の検索条件
最悪ケース	目的のコードを常にリスト末尾に固定	件数が最も多い取引先や期間で測る
試行回数	各条件10回から20回	各操作を複数回、時間帯を変えて測る
集計方法	平均ではなく中央値	中央値と最遅値の両方を見る
環境差の排除	同一端末のOSアップデートで比較	同一サーバ構成、同一ネットワークで比較

集計に中央値を使ったのは、タイムアウトが混じる条件では平均が外れ値に引きずられるためです。検収の場でも、たまたま1回速かった結果を根拠にされると、実運用と合わない判定になります。

制約事項を先に明示する

測っていない範囲を、測ったように扱わないことが重要です。当社の調査では、端末を分けざるをえなかった条件について、1コードあたりの速度が一致していることを根拠に、観測された差が機材差では説明できないことを示しました。

さらに、外挿した推定値には実測値と区別できる印を付け、未実測であることを明記しています。対象外にしたOSバージョンや、単一のシステムコードのカードしか試していない点も、制約として書きました。

発注側がやることは次のとおりです。

1. 測定条件を要件書に併記する（つまずきやすい点: 条件を口頭で合意して書き残さないこと）。
2. 本番相当のデータ件数を用意する時期を決める（所要時間の目安: データ準備に数日かかることがあります）。
3. 測定に使う環境を1つに固定し、途中で変えない。
4. 測れなかった条件を、検収報告に制約として書いてもらう。

測っていないことを測ったように書かない。この1点が、性能レポートの信頼性を最後に決めます。検収での確認手順は次のセクションで扱います。

検収でどう確認する？ 契約書への落とし込み

決めた水準は、検収条件として契約書に書いておきます。口頭の合意だけでは、性能が出なかったときの取り扱いが決まりません。

検収とは、発注者がベンダから受け取った成果物が仕様どおりかを確認し、合否を判定する工程です。検収が完了すると発注者の支払義務が確定し、その時点が契約不適合責任の期間の起算点になります。

検収条件の書き方

IPA（独立行政法人 情報処理推進機構）は2020年12月22日に「情報システム・モデル取引・契約書（第二版）」を公開しています。ユーザ企業とベンダのどちらにも偏らない中立的なモデル契約書で、システム仕様、プロジェクト管理方法、検収方法について双方の対話を深めることを目的としたものです（出典: IPA「情報システム・モデル取引・契約書（第二版）」2020年12月22日公開）。

性能要件を検収条件に落とすときは、前のセクションで決めた3点セットと測定条件を、そのまま合否の判定表にします。

検収条件に書く項目	内容
判定対象	対象の操作と前提条件
合格基準	目標値と、どの集計値で判定するか
測定環境	使用する環境、データ件数、実施時期
不合格時の扱い	再測定の回数と、改修の範囲

実務解説では、発注側が確認すべき契約書のチェックポイントとして、検収基準、知的財産権の帰属、契約不適合責任の3点がよく挙げられます。検収条件を具体的に書かないまま契約すると、合否判定や不適合発覚時の対応で認識が食い違い、トラブルになりやすくなります。

契約不適合責任の通知期限を確認する

2020年4月施行の改正民法では、成果物に不適合があった場合の通知期限について、従来の引渡しから1年という規定に代えて、契約不適合を知った時から1年以内に通知することが原則となりました。ベンダに故意または重過失があった場合には、この期間制限は適用されません。

ここでいう通知とは、単に不満を伝えることではありません。不適合の種類と範囲を、相手が具体的に把握できる程度に伝えることを指します。

一方でIPAのモデル契約書は、知った時からという主観的な起算点をそのまま踏襲せず、検収完了後〇か月または〇年以内に通知するという客観的な起算点を契約書上の規定として維持する方式を採っています。発注者にとっては、検収完了日という明確な日付を基準にできる点で実務上わかりやすい方式です。

1. 契約書に検収の合格基準と測定環境を明記する（つまずきやすい点: 仕様書に書いたから十分だと考えること。合否の根拠になるのは契約書の定めです）。
2. 契約不適合責任の通知期限が、どちらの起算点で書かれているかを確認する（所要時間の目安: 30分）。
3. 不合格時の再測定と改修の範囲を、あらかじめ決めておく。

性能が出なかったときに何が起きるかを、契約前に決めておく。これだけで、稼働直前の揉めごとの多くは避けられます。

非機能要件の言語化は、業務を知る発注側にしかできない部分が残ります。社内に判断できる人がいない場合は、要件の整理から一緒に進める形もあります。進め方に迷う場合はお問い合わせからご相談ください。

つまずきやすい点は？ 発注側が陥りやすい3つの失敗

水準を高く設定しすぎる、測定条件を書かない、可用性を決めないまま運用に入るという3点が、費用と手戻りに直結します。いずれも要件を固める前に防げます。

測定条件については前のセクションで扱いました。ここでは、水準の設定と、後から変えにくい項目の扱いを整理します。

過剰な水準は費用に跳ね返る

非機能要件は、上げれば上げるほど費用と期間が増えます。稼働率を1桁上げるだけで、構成そのものが変わることもあります。

高い水準を求めること自体が悪いわけではありません。問題は、業務上の必要が無いのに「念のため」で上げてしまうことです。

よくある設定	見直しの問い
24時間365日の稼働	夜間に使う人はいますか。止められる時間帯はありませんか
全操作を1秒以内	1日に何回使う操作ですか。月1回の処理も同じ水準が要りますか
全データの即時反映	数分後の反映で困る業務はどれですか

判断の順序は、業務が止まって困る度合いから決めることです。困り方が小さい項目の水準を下げれば、その分を本当に必要な項目へ回せます。

後から変えにくい項目を先に決める

実装者の視点で言うと、後から変えるのが特に重いのは、可用性とデータの持ち方に関わる部分です。冗長構成にするかどうか、どこまで履歴を残すかは、土台の設計に影響します。

逆に、画面の応答速度は稼働後にも改善の余地が残ります。索引の追加や処理の見直しで対応できる場合があるためです。

1. 可用性の水準を最初に決める（つまずきやすい点: 稼働後に冗長構成へ変えると、作り直しに近い規模になります）。
2. 履歴やログをどこまで残すかを決める（所要時間の目安: 半日）。
3. 性能の目標値を仮置きし、稼働後に見直す前提で合意しておく。
4. 決めた内容を要件書と契約書の両方に反映する。

非機能要件は、一度決めて終わりではありません。利用者が増えたときに何が先に苦しくなるかを、受注側に聞いておいてください。その答えが具体的に返ってくるかどうかは、発注先を見極める材料にもなります。

自社の業務に必要な水準がどのあたりかを整理したい場合は、無料診断もご利用いただけます。

よくある質問

発注の現場で実際に聞かれることの多い質問をまとめました。数値の目安は業務の内容と規模で変わるため、断定的な基準は示していません。

非機能要件は要件定義のどの段階で決めるものですか？

要件定義の初期、機能の一覧を作るのと並行して着手してください。可用性やデータの持ち方は土台の設計に影響するため、機能がすべて固まってから決めると手戻りになります。まず6大項目を洗い出して重要度を並べ、重要な項目から数値を入れていく順番が現実的です。

応答速度は何秒以内にしておけば無難ですか？

一律の正解はありません。決め方の起点は、現行の運用で実際にどれくらい待っているかです。今より遅くならないことを最低線に置き、1日に何十回も使う操作から目標値を詰めてください。月に1回の処理まで同じ水準にすると、費用だけが増えます。

非機能要件を厳しくすると費用はどれくらい上がりますか？

金額の目安は案件により変動するため、ここでは示しません。ただし構成が変わる水準かどうかで、増え方の性質が変わります。冗長構成や24時間の無停止運用のように土台が変わる要件は、影響が大きくなりやすい項目です。仮置きしたレベルを受注側に示し、費用と期間への影響を出してもらってから調整してください。

稼働率や復旧時間は、社内システムでも決める必要がありますか？

必要です。決めていないと、障害時に何時間で戻るのかを誰も答えられない状態で運用が始まります。社内だけで完結するシステムなら、業務時間内に復旧できれば足りることもあります。取引先の業務が止まるなら、一段上の水準で考えてください。

性能が要件を満たさなかった場合、どう対応してもらえますか？

契約書に定めた内容によります。だからこそ、不合格時の再測定の回数と改修の範囲を、契約前に決めておく必要があります。検収の合格基準と測定環境を契約書に明記しておけば、判定そのものでの食い違いも防げます。

最後に、非機能要件を決める流れをまとめます。

1. 6大項目を洗い出し、自社のモデルシステムを決める（所要時間の目安: 1日）。
2. 重要な項目から水準を仮置きし、費用と期間への影響を確認する（つまずきやすい点: 全項目を高い水準にすること）。
3. 性能要件を対象の操作、前提条件、目標値の3点セットで書く。
4. 測定条件を要件書に併記し、そのまま検収の合格基準にする。

関連リンク

• 自社に必要な非機能要件の水準を無料診断で整理する
• システム発注の進め方をまとめたDXガイドブック
• システム開発の料金の考え方