非機能要件の決め方｜技術責任者のいない会社が、稼働率・性能・復旧の数値を実測と契約で決める手順

非機能要件（稼働率・性能・復旧時間・障害対応）の数字を、技術責任者のいない中小企業はどう決めればよいか。SLAを曖昧にしてトラブルになった失敗、アクセスログでサーバ費用を半分にした実測、バックアップから復旧できなかった障害の経験から、確認する項目と契約への盛り込み方をまとめます。

2026年10月28日

執筆者

運営者・AIエンジニア／ IT歴36年以上

非機能要件の決め方｜技術責任者のいない会社が、稼働率・性能・復旧の数値を実測と契約で決める手順

要約

非機能要件の決定とは、停止を許容する時間、待たせてよい秒数、障害時の復旧方法を数値で定めることです。曖昧なまま契約すると、稼働後に「聞いていた話と違う」というトラブルが発生します。
数値は「不安だから多めに」ではなく、アクセスログ（いつ誰が使用したかの記録）や、復元試験の結果で決めます。
決めた数値は「やらないことリスト」と一緒に、発注側と開発側で先に合意します。見積もりでは、テストと保守の配分を確認します。

システムを発注するとき、画面や機能の話には時間をかけます。しかし、「月に何分まで停止してよいか」「壊れたら何時間で復旧するか」は、決めないまま契約が進みがちです。技術責任者のいない会社では、こうした条件を確認する人が社内にいないからです。

こうした条件を非機能要件と呼びます。この記事では、技術の分からない経営者が非機能要件をどう決め、どう契約に含めるかをまとめます。基準は、私自身の失敗と、実測のデータで決めた経験をもとにしています。

非機能要件とは何か

非機能要件とは、システムの「動き方」を決める条件です。どの程度安定して稼働し、どの程度の速度で動作し、壊れたらどう復旧するかを決めます。これに対して、「何をするか」（会員登録ができる、請求書を発行できる、など）は機能要件と呼びます。

IPA（情報処理推進機構）の「非機能要求グレード2018」は、非機能要件を6つの大項目に分けています。IPA の表現では「非機能要求」です。発注側と開発側の認識の行き違いを防ぐための資料です。このうち、この記事で扱う3つは次のとおりです。

| 大項目 | 経営者向けに言い換えると |

|---|---|

| 可用性 | どの程度安定して稼働するか、停止したらどう復旧するか |

| 性能・拡張性 | どれだけ速く応答するか、人が増えても耐えられるか |

| 運用・保守性 | 日々の監視・バックアップ・障害対応をどう運用するか |

IPA は2012年4月に、発注側29団体と開発側30団体に、非機能要求をどれだけ意識しているかを調べました。点数にすると、全般に開発側のほうが高い結果でした。特に差が大きかったのは、可用性、性能・拡張性、運用・保守性です。つまり、発注側は、停止時の扱い・速度・運用の条件を、開発側ほど検討していないということです。技術責任者のいない会社では、この差が最も大きく表れます。

この記事では、費用とトラブルに直結しやすい3つを中心に扱います。可用性、性能、運用・保守性です。

なぜ曖昧なまま契約するとトラブルになるのか

私自身、起業初期の案件で、想定アクセス数や SLA を曖昧にしたまま契約したことがあります。稼働開始後に、「聞いていた話と違う」と言われるトラブルになりました。SLA とは、サービスの水準と、守れなかったときの扱いを決めた約束のことです。

発注側は「普通に使えるもの」を依頼したつもりで、開発側は「仕様書に書かれたもの」を作ったつもりでした。どちらも嘘はついていません。ただ、「普通」の内容が数値になっていなかったのです。それ以来、性能や障害対応の条件も、必ず数値で文書化しています。要件定義とは、何を作るかを決める工程です。発注側が決めることは、要件定義は発注側の責任｜技術責任者のいない会社が決めること、開発会社と合意することで説明しています。

技術責任者のいない会社で、こうした数値を曖昧にすると、どうなるでしょうか。私が何度も見てきたのは、次の流れです。経営者には妥当かどうかの見極めがつかず、外注先の言い値で契約します。あとになって、保守費用が高すぎることや、システムをほかへ移行できないことに気づくのです。非機能要件は、この「言い値」が最も入り込みやすい部分です。

数値は「不安だから多めに」ではなく実測で決める

経営者が非機能要件の数値を決めるとき、最も多い失敗は、「よく分からないから、念のため多めにしておく」という判断です。これは費用に直結します。

あるプロジェクトでは、必要以上に性能の高いサーバの構成を見直しました。サーバとは、システムを稼働させ、データを保存しておくコンピュータのことです。アクセスログ（いつ誰がどのページを閲覧したかの記録）で、実際に必要なサーバの規模を再調査しました。その結果、月額費用をおよそ半分にできました。「不安だから多めに」という感覚を改め、実測の数値で決めたことが、費用を削減する決め手でした。

ここで重要なのは、最初の構成が多めだったことではありません。見直さないまま、毎月支払い続けていたことです。アクセスログは、システムが稼働を開始すれば自動で蓄積されます。ピーク（最も多くの人が同時に使う時間帯）に何人が使用しているかは、感覚ではなく記録で分かるのです。

私は、技術が分からない経営者には、専門用語を避け、「コスト」「リスク」「時間」の3つに言い換えて説明します。クラウド（自社でサーバを持たず、他社のコンピュータを借りて使う形）へ移行する場合なら、「初期費用は下がるが、毎月の費用は上がる。その分、障害への対応は速くなる」と伝えます。非機能要件の数値も、同じ3つの言葉で考えれば判断できます。稼働率（停止せずに稼働する時間の割合）を上げれば、コストは増え、リスクは減ります。復旧を速くすれば、復旧時間は短縮され、コストは増えます。どの水準にするかを、実測の数値を確認しながら決めるのです。

項目ごとに、何を数値化するか

可用性: 稼働率と「停止したらどうなるか」

可用性は、稼働率という数値で表します。稼働率とは、ある期間のうち、システムが使える状態だった時間の割合のことです。

クラウドで運用するのであれば、そのサービス内容を読んでおきます。たとえば Amazon の EC2（サーバを時間貸しするサービス）の SLA を見てみましょう。リージョン（地域の単位）では、月の稼働率99.99%以上を約束しています。インスタンス（サーバ1台）では、99.5%以上です。守られなかったときは、サービスクレジット（補償）が提供されます。リージョンの場合、補償（サービスクレジット）の割合は、次のとおりです。

稼働率が99.99%未満、99.0%以上: 10%
稼働率が99.0%未満、95.0%以上: 30%
稼働率が95.0%未満: 100%

ここから、2つのことが分かります。1つは、同じサービスでも使い方で保証の数値が異なることです。もう1つは、補償を受けても、停止中に失った売上や信用は回復しないことです。自社のシステムが停止したらどのような影響が出るかは、クラウド側には分かりません。経営者が見積もるしかないのです。停止したときの被害と、それを防ぐ費用を、コスト・リスク・時間で比較して、稼働率の目標を決めましょう。

性能: 「速い」を秒数で記載する

「速いサイトにしてほしい」は、要件になりません。何を、どの条件で、何秒以内にするかを、要件定義書に記載しましょう。

Web サイトの速さは、Core Web Vitals（Google が公開する3つの指標）で測れます。何秒以内にするかは、自社で決めます。

| 指標 | 何を測るか | Google が「良好」とする値 |

|---|---|---|

| LCP | ページを開き始めてから、最も大きな画像や文字が表示されるまでの時間 | 2.5秒以内 |

| INP | ボタンを押したりしてから、画面が反応するまでの時間 | 200ミリ秒以下 |

| CLS | 読み込み中に、表示がどの程度ずれるか | 0.1以下 |

Google はこの指標を、スマートフォンとパソコンに分けて測ります。確認するのは75パーセンタイル（表示4回のうち3回が満たす速さ）です。平均ではなく「大半の人がこの速さ以内か」で確認します。

自社のシステムでは、「ピークに同時に何人が使い、主な画面が何秒以内に表示されるか」という形式で、要件定義書に記載します。同時に使う人数は、前の章で書いたとおり、アクセスログを見れば分かります。開発側には、その人数で負荷試験を実施してもらい、結果を数値で受け取りましょう。負荷試験とは、想定した人数が同時に使う状態を機械で作り、速度を検証する試験です。

運用・保守性: バックアップは費用対効果で決める

バックアップ（データの控え）で決めるのは、取得するかどうかではなく、どこまで復元できるようにするかです。数値化するのは、次の2つです。

RTO（目標復旧時間）: 停止してから復旧するまでに、許容できる最大の時間
RPO（目標復旧時点）: 壊れたとき、直前の何分間のデータを失っても許容できるか

どこまで復元できるようにするかは、費用と損失を比較して決めます。たとえば Supabase を見てみましょう。Supabase は、アプリのデータベース（顧客や取引の記録を蓄積する仕組み）を提供するサービスです。2026年10月時点で、Pro プラン以上は毎日自動でバックアップを取ります。何もしなければ、失うデータは最長で1日分です。PITR（指定した時点に復元できる仕組み）を追加すると、消失するのは障害直前の最大2分間に入力されたデータだけです。PITR の費用は、過去7日分まで復元できる設定で、月額およそ100ドルです。

比較するのは、1日分のデータが消失したときの損失と、毎月およそ100ドルの費用です。注文や入金の記録のように、消失すると回復できないデータなら、支払う価値があります。元の資料から作り直せる社内の集計表なら、毎日のバックアップで十分です。

復元できるかを検証する手間も、費用に含めておきましょう。私が経験した最も大きな障害は、ディスクの故障でした。復元できるかを確認していなかったため、復旧に丸1日以上かかりました。それからは、「バックアップを取得したか」ではなく「実際に復元できるか」を定期的に検証しています。この復元のことをリストアと呼びます。このときの経緯は、バックアップは「取れているか」ではなく「戻せるか」で説明しています。

リストアの試験を、いつ、誰が行うかも、保守の契約書に記述しておきます。障害時の対応も同じです。「誰が、何時間以内に回答し、何時間以内に修正するか」が契約書に記載されているかどうかが重要です。

セキュリティ: 安さの裏に欠陥がないか

20年ほど前、知人の起業家が、ビジネスマッチングサイトを安く作れたと喜んでいました。サイトを確認すると、セキュリティ上の欠陥が複数見つかりました。結局は修正に費用がかかり、最初から適切に作るほうが費用を抑えられたのです。安い見積もりで非機能要件が記載されていないときは、この例を思い出してください。

契約と見積もりにどう反映するか

数値を決めたら、文書化して、発注側と開発側で合意します。私が実施して有効だったのは、「やらないことリスト」を、発注側と開発側で先に合意したことです。要件定義書とは別に作ります。あとから要望が増えて、範囲が拡大するのを防げました。非機能要件でも同じです。「稼働率の保証をしない」「負荷試験は何人分まで」と決めたことも、この「やらないことリスト」に記述しておきます。

見積もりでは、合計額ではなく配分を確認します。設計・実装・テスト・保守に、工数がどう配分されているかを必ず確認しましょう。見積もりが極端に安いときは、テストや保守の工数が含まれていないことがよくあります。高すぎるときは、要件が決まっていない分を「念のため」で上乗せしていることが多いのです。非機能要件を数値で提示すれば、「念のため」を上乗せする理由はなくなります。高い部分を説明できるかどうかで、見積もりの良し悪しが分かれます。工数の内訳の見方は、システム開発の見積もりは妥当か、工数の内訳から確認する方法で説明しています。

私は、保守費が高いかどうかは、相場の目安ではなく内容で判断しています。その保守費に、監視・バックアップ・リストアの試験・障害時の対応が含まれているか、それぞれ何時間分かを確認します。

進め方も決めておきましょう。成功した案件では、週に一度、進捗の共有と「動作するものを提示してもらう」確認を続けました。認識のずれを早期に修正するのに効果的です。仕様書だけ渡して一任した案件は、失敗しました。納品の直前になって、想定とはまったく異なるものが提出されたのです。非機能要件も、文書を渡して終わりにしません。負荷試験やリストアの試験の結果を、途中で実際に提示してもらいましょう。

経営者が確認すること

経営者は、技術の内容を読む必要はありません。次の4つを、開発側に確認し、回答を文書に残してください。

| 確認すること | コスト・リスク・時間のどれか |

|---|---|

| 停止したら、誰に、どのような被害が、どの程度生じるか。それは月に何分までなら許容できるか | リスク |

| 壊れたとき、何時間で、何分前のデータに復元できるか。復元できることを、いつ誰が検証するか | 時間 |

| ピークの時間帯に何人が同時に使い、主な画面が何秒以内に表示されるか。その人数はどの記録から算出したか | 時間・コスト |

| 障害時に、誰が何時間以内に回答し、何時間以内に修正するか。それは保守費のどこに含まれているか | コスト |

いずれか1つでも「お任せください」「一般的には問題ありません」という回答しか得られないなら、その項目はまだ決まっていません。注意が必要です。

よくある質問

Q: 新しいシステムで、まだアクセスログがありません。数値はどう決めればよいですか。

最初から過大に見積もらないことです。私がサーバ費用を半分にできたのは、稼働開始後にアクセスログで見直したからでした。最初の数値は仮でかまいません。その代わり、稼働後にアクセスログを確認して見直す時期を、先に決めておきましょう。見直しのない「念のため」が、最も高額になります。

Q: クラウドの SLA が 99.99% なら、自社のシステムも 99.99% 稼働すると考えてよいですか。

いいえ、そうとは限りません。クラウドの SLA は、基盤部分についての保証です。その上で稼働する自社のシステムは、開発会社の設計や運用が原因でも停止します。自社のシステムの稼働率と、停止したときに誰がどう対応するかは、別に決めて文書化しましょう。

Q: バックアップは毎日取っていると言われました。それで十分ですか。

「取得できているか」と「復元できるか」は別です。私は、復元できるかを検証していなかったために、復旧に丸1日以上かかりました。毎日バックアップを取得しているなら、失うデータが最長1日分でも許容できるかを確認しましょう。それでも足りなければ PITR のような仕組みの費用と比べます。そのうえで、「バックアップから実際に復元する試験を、いつ、誰が実施するか」を保守の契約に含めてください。

まとめ

非機能要件の決定とは、停止を許容する時間・待たせてよい秒数・障害時の復旧方法を、数値で定めることです。曖昧なまま契約すると、稼働後に「聞いていた話と違う」というトラブルが発生します。
数値は「不安だから多めに」ではなく、アクセスログやリストアの試験といった実測のデータで決め、稼働後に見直します。
バックアップは、どこまで復元できるかを費用対効果で決め、復元の試験を保守の契約に含めます。
決めた数値と「やらないことリスト」を発注側と開発側で先に合意し、見積もりは設計・実装・テスト・保守の配分で確認します。
経営者は、コスト・リスク・時間の3つで確認し、「お任せください」で終わる項目を残さないようにします。

無料相談のご案内

PH Tech AI は、社内に技術責任者がいない会社の、技術の判断と開発体制づくりを支援しています。発注するシステムの非機能要件をどう記載するか、現在の保守契約に数値が含まれているかを、一緒に整理します。見積もりの配分が妥当かも確認します。無料でご相談いただけます。まずはお気軽にお問い合わせください。