非機能要件とは?機能要件との違いとIPAの6分類、発注者が数値で決める6項目の決め方【2026年版】

「機能の一覧は書けたが、非機能要件をまとめてくださいと言われて手が止まった」——要件定義を進めている発注側のご担当者から、こうした相談をよく受けます。速いこと、止まらないこと、安全なこと。どれも当たり前に必要なのに、いざ文書に書こうとすると、何を、どの単位で、どこまで決めればよいのかが分からない。社内にインフラの専任がいなければ、なおさらです。

非機能要件とは、システムが「どのくらいの水準で動くか」を決める要件です。機能要件が「何ができるか」を決めるのに対して、非機能要件は速さ、止まらなさ、守り方、移し方、運び方を決めます。IPA(独立行政法人情報処理推進機構)の「非機能要求グレード2018」は、これを可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つに分類しています。

大事なのは、この6分類の名前を覚えることではありません。分類のうち重要な項目を、判定できる数値にして開発会社に渡すことです。「速いこと」は要件になりませんが、「同時100人が利用している状態で、検索結果の一覧が3秒以内に表示される」は要件になります。前者は見積もれず、検収でも判定できません。後者は見積もれて、受入テストで測れます。

本記事では、非機能要件の定義と機能要件との違い、IPAの6大分類で発注者が決めること、数値で書かないと意味がない6項目(同時利用者数・応答時間・稼働率・バックアップと復旧目標・ログ保存期間・対応ブラウザ)の決め方、決めないまま進めるとどこで揉めるか、後から変えると高くつく項目、そしてオフショアや外部委託で特に落ちやすい項目の順に解説します。6分類の出典はIPAの公開資料を直接確認し、版と確認日を明記しました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。非機能要件でこじれた案件に共通するのは、たった一点です。要件定義書に「速いこと」「落ちないこと」としか書かれていなかった。この記事を読み終えるころには、自社の案件でどの項目を、何を根拠に、どんな文章で決めればよいかが判断できるはずです。

非機能要件とは——機能要件との違いは「何ができるか」と「どのくらいで動くか」

非機能要件とは、システムが「どのくらいの水準で動くか」を決める要件です。機能要件が「システムで何ができるか」を決めるのに対し、非機能要件は速さ、止まらなさ、守り方、移し方、運び方といった品質と制約を決めます。まずは定義と、機能要件との線引きを押さえてください。ここが曖昧なままだと、この先のどの分類も決められません。

非機能要件の定義——同じ機能でも、水準が違えば別のシステムになる

非機能要件は、機能以外のすべての要求をまとめた言葉です。IPAが公開している「非機能要求グレード」の資料では、情報システムに対する要求を機能要求と非機能要求に分け、非機能要求のうちシステム基盤に関わるものを対象範囲としています(出典: IPA「『非機能要求グレード』実践セミナー」資料、非機能要求グレード2018の公開に合わせて修正された版。2026年9月16日確認)。

同じ機能でも、水準が違えば中身はまったく別のシステムになります。たとえば「商品を検索できる」という機能を考えてみます。社内の担当者3人が1日数回使うだけなら、1台のサーバーで十分です。同じ機能を、全国の店舗2,000人が朝一斉に使い、1秒でも遅いと接客が止まるという条件で作るなら、負荷分散、キャッシュ、冗長化、監視が必要になり、開発費も運用費も桁が変わります。機能一覧だけを渡して見積もりを取ると、この差が反映されません。

IPAの資料では、非機能要求について「ステークホルダ間の認識の行き違いに気づかないまま開発が進んでしまうことがある」と、その問題点が端的に書かれています(出典: IPA「非機能要求グレード2018 改訂情報 ~初版との差異~」2018年4月25日)。認識の行き違いは、悪意でも手抜きでもなく、書かれていないから起きます。

機能要件と非機能要件の対比表——同じ画面を2つの言葉で書き分ける

言葉の定義より、実際の書き分けを見るほうが早いはずです。同じ機能について、機能要件と非機能要件をどう書き分けるかを並べました。

左の列だけが要件定義書に並んでいる状態が、非機能要件が抜けている状態です。左の列は開発会社が読んで作るものを決められますが、どのくらいの規模で、どのくらいの速さで、どこまで守って作るかは決められません。結果として、開発会社は自社の標準的な水準を当てはめて見積もります。その水準が発注側の期待と一致していれば問題は起きませんが、一致しているかどうかは、誰も確認していないことになります。

要件定義のどこで決めるのか——工程の全体像は別記事に譲る

非機能要件を決めるのは、要件定義の工程です。機能要件の整理と並行して進め、基本設計に入る前に水準を確定させるのが基本の流れになります。要件定義という工程そのものの位置づけや、誰が関わって何が成果物として残るのかは「要件定義とは」の記事で扱っています。要求と要件の関係(現場の希望をどう判定できる言葉に変換するか)は「要求定義と要件定義の違い」の記事、要件定義書の章立てと文書としての書き方は「要件定義書の書き方」の記事、要件で決めた水準を画面や帳票の形に落とす工程は「基本設計とは」の記事をご覧ください。本記事は、そのなかで「非機能」という一枚だけを深く扱います。

分類の物差しは2つ——IPA「非機能要求グレード2018」とISO/IEC 25010:2023

非機能要件を漏れなく洗い出すための物差しは、実務では主に2つ使われています。

1つはIPAの「非機能要求グレード」です。初版が2010年4月に公開され、新たなセキュリティ脅威の台頭とシステム基盤技術の進展を受けて、2018年4月25日に「非機能要求グレード2018」として改訂されました(出典: IPA「非機能要求グレード2018 改訂情報 ~初版との差異~」2018年4月25日)。国内の発注実務ではこちらが事実上の共通言語になっており、本記事も6分類はこの資料に沿って説明します。なお同事業は終了しており、IPAでは問い合わせを受け付けていません。

もう1つはISO/IEC 25010です。ソフトウェア製品の品質モデルを定めた国際規格で、第2版が2023年11月に発行され、ISO/IEC 25010:2011を置き換えました。第2版では安全性(safety)が品質特性として追加され、usability と portability がそれぞれ interaction capability と flexibility に置き換わっています(出典: ISO/IEC 25010:2023, Second edition 2023-11, Foreword。2026年9月16日確認)。製品としての品質を評価したい場面ではこちらが向きますが、システム基盤の発注要件を決める場面では、要求レベルの例示まで用意されているIPAの資料のほうが実用的です。

では、その6分類で発注者は具体的に何を決めればよいのか。次章で分類ごとに整理します。

非機能要件の6大分類——IPA非機能要求グレード2018で、分類ごとに発注者が決めること

IPA「非機能要求グレード2018」は、システム基盤に関する非機能要求を6つの大項目に分類しています。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つです(出典: IPA「システム構築の上流工程強化(非機能要求グレード)紹介ページ」および「『非機能要求グレード』実践セミナー」資料。2026年9月16日確認)。この章では、分類ごとに発注者が決めることと、開発会社に任せてよいことを分けて整理します。

6大項目・35中項目・118小項目・238メトリクスという構造

非機能要求グレードは、6つの大項目の下に中項目、小項目、メトリクス(指標)がぶら下がる4階層になっています。2018年版では6大項目、35中項目、118小項目、238メトリクスに体系化されています。改訂前の236メトリクスに対し、新規追加が2メトリクス、既存項目に修正を施したものが20メトリクスでした(出典: IPA「非機能要求グレード2018 改訂情報 ~初版との差異~」2018年4月25日)。

メトリクスごとに要求レベルが0から5の6段階で設定されており、レベル値が大きいほど実現難易度が高くなり、一般に開発コストは増加します。レベルで示す値はユーザーと開発ベンダーの間で合意形成を図る出発点であり、最終的には具体的な数値として合意することが想定されています(出典: 同上・実践セミナー資料)。ここは大事な前提です。グレード表のレベルを選んだだけでは要件になりません。レベルは議論の入口で、着地点は数値です。

大項目の下の中項目は、たとえば可用性なら継続性、耐障害性、災害対策、回復性の4つ。性能・拡張性なら業務処理量、性能目標値、リソース拡張性、性能品質保証の4つ。移行性なら移行時期、移行方式、移行対象(機器)、移行対象(データ)、移行計画の5つです(出典: 同上)。この粒度で並べられると、自社の案件で何が抜けているかが見えてきます。

6分類ごとに「発注者が決めること/開発会社が決めること」の一覧表

実務で迷うのは、どこまでが発注者の仕事かという線引きです。原則は単純で、業務が止まって困るのは発注者なので、水準は発注者が決めます。その水準をどう実現するか(冗長化の方式、キャッシュの置き方、監視ツールの選定)は開発会社が決めます。

左から3列目が、発注者が要件定義で言語化する範囲です。右の列は、開発会社の提案を受けてレビューする範囲であり、発注者が方式まで指定する必要はありません。むしろ方式を先に指定してしまうと、より安く同じ水準を満たせる選択肢を潰すことがあります。

セキュリティの対策そのものを設計・運用でどう組むかは「オフショア開発のセキュリティ対策」の記事、障害が実際に起きたあとの一次対応と告知の出し方は「サーバー障害の原因と対応」の記事で詳しく扱っています。本記事では、あくまで要件段階で決める水準に絞ります。

全部を決めようとしない——重要項目92項目から、モデルシステムを選んで決める

238のメトリクスを全部埋めようとすると、要件定義が終わりません。非機能要求グレードは、この問題に2つの仕掛けで答えています。

1つは重要項目です。開発コストや品質に与える影響が大きいメトリクスを重要項目と位置づけ、グレード表の対象にしています。実践セミナー資料では、コストや品質に影響が大きい重要項目として92項目があらかじめ要求レベルの値を例示されており、早期に判断できるとされています(出典: IPA「『非機能要求グレード』実践セミナー」資料)。238を眺めるのではなく、92から入る。これだけで作業量が大きく変わります。

もう1つはモデルシステムです。非機能要求グレードは、信頼性の観点から情報システムを3つのモデルに分けています。社会的影響がほとんど無いシステム、社会的影響が限定されるシステム、社会的影響が極めて大きいシステムの3つです。それぞれ、企業の特定部門が比較的限られた範囲で利用しているシステム、企業活動の基盤となり取引先や顧客等の外部利用者にも影響が及ぶシステム、国民生活・社会経済活動の基盤となるシステム、と定義されています(出典: 同上)。

やり方はこうです。自社のシステムがどのモデルに近いかを1つ選び、そのモデルのベース値を出発点として、重要項目のレベルを調整する。そのうえで残りの項目を詰める。IPAの利用手順も、モデルシステムの選定、重要項目のレベル決定、その他のレベル決定という3段階になっています(出典: IPA「システム構築の上流工程強化(非機能要求グレード)紹介ページ」)。

社内システムなら1つ目、取引先が使うシステムなら2つ目、と当たりをつけるだけでも、議論の出発点が揃います。「うちは止まっても困らない部門システムだから、可用性はベース値でよい。ただし個人情報を持つのでセキュリティは1段上げる」という会話ができれば、要件定義の非機能パートは半分終わったようなものです。

ここまでが分類の話です。次は、6分類のうち特に「数値にしないと意味がない」項目に絞って、決め方の手順を見ていきます。

数値で書かないと意味がない6項目——同時利用者数、応答時間、稼働率、バックアップと復旧目標、ログ保存期間、対応ブラウザ

6分類のなかでも、数値にしないと要件として機能しない項目があります。同時利用者数、応答時間、稼働率、バックアップ世代と復旧目標、ログ保存期間、対応ブラウザの6つです。この章では、それぞれを何を根拠に決めるか、根拠が出せないときにどう書くかを、実務の手順として整理します。

なぜ「速いこと」「止まらないこと」は要件にならないのか

理由は2つあります。見積もれないことと、判定できないことです。

見積もれない、というのは開発会社側の事情です。「速いこと」という一文からは、必要なサーバー台数もキャッシュの設計も決まりません。決まらないまま見積もりを出す場合、開発会社は自社の標準的な水準を仮置きします。その仮置きが発注側の期待より低ければ稼働後に苦情が出ますし、高ければ不要に高い見積もりになります。どちらに転んでも損です。

判定できない、というのは発注者側の問題です。検収の場面で「速くない」と主張しても、契約書にも要件定義書にも基準が書かれていなければ、開発会社は「要件どおりに作りました」と答えるほかありません。私が見てきた非機能のトラブルは、ほぼすべてこの形をしています。要件定義書に「速いこと」「落ちないこと」としか書かれていなかった、という一点です。

IPAの資料も、レベルで示す値をユーザーとベンダーの合意形成の出発点と位置づけ、最終的に具体的な数値として合意することを想定していると明記しています(出典: IPA「『非機能要求グレード』実践セミナー」資料)。数値にするのは相手を縛るためではなく、両者が同じものを見るためです。

6項目の決め方——何を根拠に引くか、出せないときの代替、要件文の例

数値は勘で決めるものではありません。ほとんどの場合、すでに社内にある実績値から引いてこられます。

可用性のレベル感をつかむ目安として、IPAのグレード表では、社会的影響がほとんど無いシステムで稼働率99%、限定されるシステムで99.99%、極めて大きいシステムで99.999%という例示が置かれています(出典: IPA「『非機能要求グレード』実践セミナー」資料のモデルシステムシート)。99%は年間に換算すると約88時間、99.99%なら約53分の停止に相当します(年間8,760時間で計算)。この差を実現するための構成と費用の差が、そのまま見積もりの差になります。

大規模災害時の目標復旧水準についても、IPAは3日以内に再開、一週間以内に再開、数ヶ月以内に再開といったレベル値を例示し、そのレベルを選ぶ条件まで併記しています(出典: 同上)。自社でゼロから考えるより、例示から1つ選んで調整するほうが速く、社内の合意も取りやすいはずです。

数値は「誰が・いつ・どうやって測るか」までセットで書く

数値を決めただけでは、まだ半分です。検収で揉めるのは、数値ではなく測り方が決まっていないときです。

「検索が3秒以内」と書いたとして、誰の端末で、どの回線で、何件のデータが入っている状態で、何人が同時に使っている状態で測るのか。これが決まっていないと、開発会社は開発環境のきれいなデータで測り、発注者は本番の混み合った時間に体感で判断します。両者の数字が合わないのは当然です。

要件文には、最低限この4点を添えてください。

1. 測定条件——データ件数、同時接続数、回線、端末。「本番相当のデータ量(受注100万件)で」と書く
2. 測定方法——性能測定ツールか、ストップウォッチか。何回測って平均を取るか
3. 判定者と時期——受入テストで発注者が実施するのか、開発会社が測定結果を提出するのか
4. 未達のときの扱い——チューニングで対応するのか、構成変更は追加費用になるのか

この4点を書くだけで、受入テストの計画がそのまま書けます。受入テスト(UAT)を誰がどう進めるかは「UATとは」の記事で扱っていますので、あわせてご覧ください。

正直に言うと、ここまで書ける発注者は多くありません。ただ、全項目でやる必要はないのです。稼働率と応答時間の2つだけでも測り方を書いておけば、検収でこじれる確率は大きく下がります。

数値を決めた場合の話をしてきました。次は、決めなかった場合に何が起きるかを見ます。

非機能要件を決めないまま進めるとどこで揉めるか——後から変えると高くつく項目

非機能要件を決めないまま進めても、開発は進みます。問題が表に出るのは、たいてい開発が終わったあとです。この章では、揉める場面を時系列で3つに分け、後から変えると高くつく項目と、後から足しても大きな負担にならない項目を分けて示します。決める順番を決めるための材料として使ってください。

揉める場面は3つ——検収、本番稼働直後、運用開始から半年

1つ目は検収です。機能は仕様どおりに動くが、遅い。あるいは、本番のデータ量を入れたら固まる。ここで発注者は「使えない」と言い、開発会社は「要件に性能の記載がありません」と答えます。どちらも嘘をついていないので、話が進みません。落としどころは追加費用によるチューニングか、そのまま受け入れるかの二択になり、双方に不満が残ります。

2つ目は本番稼働直後です。典型は月初や月末の集中でシステムが重くなるケース、そして権限設計の作り直しです。「部長は他部署のデータも見られるようにしてほしい」といった話が稼働後に出てくると、認証認可の設計に手を入れることになります。これは画面の追加より重い作業です。

3つ目は運用開始から半年ほど経った頃です。何かトラブルが起きて「誰がいつ操作したか」を調べようとしたら、ログが3日分しか残っていなかった。あるいは、監査で1年分の操作履歴の提出を求められたが、そもそも取得していなかった。ログは、取っていなかった過去を後から作ることができません。

私が受ける非機能関連の相談は、この3つの時点のどれかで発生しています。共通するのは、要件定義の段階では誰も悪くなかったということです。悪意も手抜きもなく、ただ書かれていなかった。それだけです。

後から変えると高くつく項目と、後から足せる項目

すべての非機能が後戻りに弱いわけではありません。重い項目と軽い項目を分けて、重いものだけ先に決めれば、要件定義の負荷は現実的な範囲に収まります。

表の上半分、特に文字コード、可用性構成、データモデル、認証認可、監査ログ、タイムゾーンの6つは、要件定義の段階で必ず決めてください。下半分は、運用しながら調整できます。

当社が支援した決済アプリの案件では、二要素認証とウォレット機能を最初から要件に入れていました。決済を扱う以上、認証の強度とログの取得は後付けが効かないからです。逆に、監視のアラート条件は稼働後に何度も調整しました。この配分が現実的な進め方だと考えています。

見積もりが安い理由が非機能にあることがある

相見積もりで金額に大きな差が出たとき、単価や工数の差だと思われがちですが、非機能の前提が違うだけということが少なくありません。

A社は冗長構成と監視を含み、B社は単一構成でバックアップのみ。A社は本番相当のデータで性能テストを行い、B社は機能テストのみ。A社は運用マニュアルと引き継ぎを含み、B社は含まない。この3点が違えば、同じ機能一覧でも見積額は倍近く変わります。

安い見積もりが悪いわけではありません。社内の部門システムで、半日止まっても業務が回るなら、単一構成のほうが合理的です。問題は、その違いに気づかないまま金額だけで比べることです。比較するときは、機能一覧を揃えるのと同じように、非機能の前提を揃えてください。少なくとも、可用性の構成、性能テストの有無、運用の引き継ぎ範囲の3点は、見積もり依頼時に条件として明示することをおすすめします。

ここまでは国内の委託でも同じ話です。海外のチームに渡す場合は、条件がもう1つ増えます。

非機能要件をオフショアや外部委託に渡すときに握る項目と、当社の体制

国内の開発会社であれば、書かなくても通る前提があります。日本語が正しく扱えること、日付が日本時間で動くこと、土日祝日が休みであること。海外のチームに渡すと、この「書かなくても通る」が通りません。能力の問題ではなく、前提が共有されていないだけです。ここを要件として明示できるかどうかが、オフショア開発で非機能が落ちるかどうかの分かれ目になります。

国内では暗黙で通る4つが落ちる——文字コード、タイムゾーン、全角半角、祝日カレンダー

私が現場で最も多く見てきたのが、次の4つです。いずれも日本語環境と日本の商習慣に由来するもので、海外のチームには「仕様」として伝える必要があります。

これに加えて、氏名や住所の形式(姓と名を分けるか、番地の表記をどうするか)、金額の丸め方(消費税の端数処理)、帳票の用紙サイズ(日本ではA4とB5、海外ではレターサイズが既定になっていることがある)も、確認しておくと事故が減ります。

ベトナムとの開発では、時差が2時間しかないため日中の連絡は重なりますが、ベトナムの法定祝日は2026年で年12日(労働法112条の条文上は11日で、2026年からベトナム文化の日が加わります)で、日本とは日程が違います。2026年のテト(旧正月)は2月14日から22日までです。稼働カレンダーと日本の祝日カレンダーは別物として扱ってください。ベトナム側の休暇日程は「ベトナムの祝日」の記事にまとめています。

委託前に握っておく非機能の合意事項

渡す前に、次の5点を文書で合意しておくと、後戻りが大きく減ります。

1. 文字・日時・カレンダーの前提——上の表の4項目を、要件定義書の付録として1枚にまとめる
2. 性能の測定条件——本番相当のデータ量と同時接続数、測定は誰がどの環境で行うか
3. ログとセキュリティの水準——取得対象、保存期間、開発環境に本番データを持ち込んでよいか
4. レビューの回数と対象——設計レビューを誰がいつ行うか。非機能に関わる設計は必ず日本側でレビューする
5. 受入の基準——未達だった場合にチューニングで対応する範囲と、構成変更が追加費用になる境界

仕様書としての書き方や、海外チームに渡すときの書式の工夫は「オフショア開発の仕様書の書き方」の記事、品質を仕組みで担保する考え方は「オフショア開発の品質」の記事で詳しく扱っています。

当社の場合——日本人PMの設計レビューと、仕組みで守る3点

当社は、パターンA(日本人PM/ブリッジSE+エンジニア)とパターンB(エンジニアのみ)の2つの体制を用意しており、非機能要件が論点になる案件ではパターンAをおすすめしています。上の4項目のような日本側の前提は、日本人PMが要件として文書化したうえでベトナム側に渡す運用にしているためです。

品質は人ではなく仕組みで守ります。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準の工程に入れています。人財は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインしており、協力会社を経由しないため、誰がどの設計をレビューしたかが追えます。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

介護記録SaaS「CareViewer」の案件では、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、文字コードや日付の扱いといった前提を要件として固定したうえで、週次で優先順位を判断しながら開発を続けています。従来の半分以下のコストで継続開発できているのは、前提の握り直しが発生していないからです。

正直に申し上げると、非機能要件が固まっていない段階で「安く早く作ってほしい」という案件は、当社には向きません。水準が決まらないまま作ると、作り直しの費用がコスト削減分を上回るためです。逆に、要件は動くが水準の議論は一緒に進めたい、という案件には向いています。1名から、最短2週間で開始でき、増員は約1週間、縮小と交代は1か月単位で対応できます。

非機能要件に関するよくある質問

非機能要件についていただくことの多い質問を5つ、実務の目線でお答えします。いずれも要件定義を進めている途中で判断が必要になる論点ですので、社内で議論するときのたたき台としてお使いください。

Q1. 非機能要件は誰が決めるのですか?

水準は発注者が決め、実現方式は開発会社が決めます。止まったときに困るのは発注者であり、どのくらい困るかを知っているのも発注者だからです。ただし、数値の根拠となるログの分析や、レベルごとの費用の違いは開発会社のほうが詳しいので、たたき台を出してもらい、発注者が業務の実態に照らして決める進め方が現実的です。決めた結果に責任を持つのは発注者、という線引きだけ動かさないでください。

Q2. 238のメトリクスを全部決める必要がありますか?

ありません。IPAの非機能要求グレードは、コストや品質に影響が大きい重要項目を92項目に絞り、3つのモデルシステムごとに要求レベルのベース値を例示しています。まずモデルシステムを1つ選び、重要項目を調整し、残りは開発会社の提案をレビューする。この3段階が本来の使い方です。小規模なシステムなら、本記事の6項目(同時利用者数・応答時間・稼働率・バックアップと復旧目標・ログ保存期間・対応ブラウザ)だけでも、何も書かないよりはるかに前に進みます。

Q3. 同時利用者数やピーク時の件数が分からない場合はどうすればよいですか?

仮置きして、前提として明記してください。「利用登録者数の3割が同時に使うと仮定する」と書けば、その仮定が間違っていたときに誰の責任で見直すかがはっきりします。数字を空欄にするより、根拠付きの仮定を置くほうがずっと安全です。現行システムがあればアクセスログから、なければレジ台数や受付窓口数といった業務の同時進行数から逆算できます。

Q4. 非機能要件を厳しくすると、見積もりはどのくらい変わりますか?

項目によります。IPAもレベル値が大きいほど実現難易度が高くなり、一般に開発コストは増加すると明記しています。特に効くのは可用性の構成で、単一構成と冗長構成では初期費用も月額の運用費も変わります。当社の公開単価でいえば、実務3年目安のエンジニアが1,500USD(約22.5万円/1USD=150円換算目安)、ブリッジSEが3,000USDで、最小構成の日本人PMフロント+2〜3人月なら月額約80万円からです。水準を1段上げるとどの費用が増えるかは、見積もり時に分けて出してもらってください。

Q5. 非機能要件は契約書に書くのですか、要件定義書に書くのですか?

要件定義書に書き、契約書からその要件定義書を参照する形が一般的です。受入基準として判定に使う数値(応答時間・稼働率・復旧目標)については、測定条件と判定方法まで含めて要件定義書に書き、検収条件として契約書で引用します。契約書本体に数値を直接書き込むと、変更のたびに契約変更が必要になるため、参照方式のほうが実務的な選択。

まとめ: 非機能要件は6分類の重要項目を、業務の実績値から数値にして、測り方まで書く

非機能要件とは、システムが「どのくらいの水準で動くか」を決める要件です。機能要件が「何ができるか」を決めるのに対し、非機能要件は速さ、止まらなさ、守り方、移し方、運び方を決めます。IPA「非機能要求グレード2018」は、これを可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つに分類し、6大項目・35中項目・118小項目・238メトリクスに体系化しています。ただし238すべてを埋める必要はありません。3つのモデルシステムから自社に近いものを選び、重要項目92項目のベース値を調整するところから始めてください。

発注者が必ず数値にすべきなのは、同時利用者数、応答時間、稼働率、バックアップ世代と復旧目標、ログ保存期間、対応ブラウザの6項目です。いずれも勘ではなく、現行システムのログ、対象部門の人数、社内規程、IT資産管理の一覧といった手元の実績値から引いてこられます。そして数値だけでなく、誰が・いつ・どの条件で測るかまで書いてください。検収で揉めるのは数値が低いときではなく、測り方が決まっていないときです。文字コード、可用性の構成、データモデル、認証認可、監査ログ、タイムゾーンの6つは後から変えると作り直しになるため、要件定義の段階で必ず決めておく項目になります。

海外のチームに渡す場合は、国内では書かなくても通る前提——文字コード、タイムゾーン、全角半角、祝日カレンダー——を仕様として明示してください。能力の問題ではなく、前提が共有されていないだけです。当社は日本人PMが日本側の前提を要件として文書化したうえでベトナム側に渡し、設計レビュー、プルリクエストによるコードレビュー、リリース前のダブルチェックの3点を標準の工程に入れています。要件定義の工程全体は要件定義とは、文書としての章立てと書き方は要件定義書の書き方もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、非機能要件の整理をどこまで当社で巻き取れるかの判断と、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。