非機能要件について学んだ一ヶ月

はじめに

私はもともとフロントエンドエンジニアで、TypeScript や CSS を書いてきた人間です。要件定義書をちゃんと書いた経験はなく、インフラも「これから」という状態でした。

そんな私が、この1ヶ月(2026/6~)、あるプロジェクトの要件定義、その中の「非機能要件」を担当することになりました。
アサインされた最初、頭の中は「……非機能要件って、何？」でした。「機能じゃない要件」って、じゃあ何を指すんだろう、とイメージがまったく湧きませんでした。

結論、この1ヶ月で認識は大きく変わりました。
非機能要件は 「良いシステムとは何かを、作る前に言葉にしておく作業」 でした。
この記事は、何も知らなかった私が、実際に手を動かして何を学べたのかの備忘録となっています！

非機能要件とは

まず、1ヶ月前の自分に説明するつもりで、非機能要件が何なのかを書きます。

1. 「何ができるか」ではなく「どれだけちゃんと動くか」

システムへの要求は、ざっくり2つに分けられます。「ログインボタン」を例にすると一発でわかりました。

	機能要件	非機能要件（NFR）
問い	何ができる？	どれくらいちゃんと？
ログインボタン例	クリックすると認証してダッシュボードに遷移する	2秒以内に表示 / 同時1万人でも落ちない / パスワードは暗号化 / スマホでも崩れない
一言で	動くか・動かないか	速いか・安全か・落ちないか・使いやすいか

つまり、フロント時代に「当たり前の品質配慮」としてやっていたことを、作る前に目標値として宣言しておく——それが非機能要件でした。名前を知らなかっただけで、感覚としては触っていたようです。

2. なぜ「"非"機能」と呼ぶのか

調べてみると答えはシンプルで、システムへの要求を「機能（Function）」と「それ以外」で二分したものでした。速さ・安全・止まらなさ・運用しやすさをまとめて "Non-Functional（非機能）" と呼んでいるわけです。

大事だったのは、これは重要度ではなく分類名だということです。
最近は「品質要件（Quality Requirements）」と呼ぶ現場も多いそうで、"非" の字に惑わされていました😭

3. 漠然と「品質」では書けないので「カテゴリ」に分ける

「品質を決めろ」と言われても漠然としすぎています。
そこで役に立つのが、非機能要件を体系的に分類したフレームワークです。
有名どころだと、IPA（情報処理推進機構）の「非機能要求グレード」や、国際規格 ISO/IEC 25010 の品質モデルがあり、性能・可用性・セキュリティ・運用性…といった観点であらかじめ項目が整理されています。

非機能の観点	画面づくりでいうと	フロント用語でいうと	ざっくり
性能	表示の速さ・待たされなさ	Core Web Vitals	速いか
セキュリティ・安全性	ログイン制御・入力/出力のチェック	認可・出力サニタイズ	守れているか
可用性	「◯％は動いてます」という稼働の約束	SLA/SLO	落ちないか
使用性	使い勝手・誰でも使えるか	UX/a11y	使いやすいか
運用	ログ・監視（異常に気づく仕組み）	logging/monitoring	気づけるか

実際に学んだこと

教科書的な定義は上記通りですが、ここからは実際に手を動かして初めて腑に落ちたことを書きます。

1. NFR = 決まった問いに答えるもの

各カテゴリには「答えるべき問い」が1つ決まっているだけ、というのが最大の気づきでした。

性能 = どれくらい速い？同時に何件さばく？
効率性 = コストは？ 1社あたり月いくら？
セキュリティ = 誰がアクセスできる？分離は？
完全性 = 二重実行しても壊れない？
可用性 = どれだけ止まらない？落ちたら？
安全性 = AIの出力に機密が漏れない？

カテゴリ名を暗記する必要はなく、この問いに答えられればそのカテゴリは書けたも同然でした。これに気づいてから、一気に手が動くようになりました。
「難しそう」の正体は、たいてい「型を知らない」だけでした。(カンニングバリバリOK 👀)

2. 数字は「規模から逆算」して、根拠付きで置く

一番の学びはここかなと思っています！
「同時実行30」のような数字を、最初は「そんなの分かるわけない、TBD（未定）でいいのでは」と思っていました。

これは違いました。非機能要件は「目標を定める」文書なので、TBDだらけでは文書として成り立ちません。実測値が手元になくても、こう組み立てます。

算出モデルで置く：応答時間なら「入力処理 + 出力トークン数 ÷ 生成速度 + ツール実行時間」のように分解して見積もる
見積もりには必ず根拠を1文添える：10〜15秒（見積: LLM 1回呼び出し + 検索1往復） のように

本当に分からないところだけ「要確認」として残しました。
ここで教わったのは、「分からない」と「まだ確定していない」は違うということでした。
目標値はいったん根拠を持って置いて、後の結合試験で検証するという、この感覚はフロント時代にはあまり無かったものでした。

3. 版が違えば前提も変わる

私が担当したシステムには、先行してつくる簡易版と、あとから仕上げる本格版がありました。
簡易版は自前のデータで完結し、本格版は外部システムと実接続するものでした。
前提が違えば、可用性も、他システムとの接続性も、移行の要否も変わります。だから1つの項目でも「簡易版=… / 本格版=…」と両方書く。「どの版の話をしているか」を常に意識する必要がありました。

4. 結局NFRは「自分が後で建てる土台の仕様書」だった

そして最後に腑に落ちたのがこれです。
この後、私は設計から入り、それをもとにインフラをterraformで構築する側に回ります。

今書いている非機能要件は、数ヶ月後の自分が読む「土台」そのものでした。
「これは何なのか？」と思っていたものが、実は未来の自分への申し送りでした！
ここに気づいてから、1文字1文字の解像度が変わりました。

終わりに

フロントエンド時代に感覚的にやっていた品質配慮（Core Web Vitals、a11y、負荷、セキュリティ）が、「作る前に・根拠付きで・目標値として宣言する」という形で言語化された1ヶ月でした。

この後は、設計に入っていき、インフラ構築フェーズに入ります。
自分で書いたNFRが、自分の仕様書になる。そのとき「あの1ヶ月、ちゃんと考えて書いておいてよかった」と思えるようにというのが、今の正直な気持ちです。
インフラ以前に要件定義や設計など未知の領域に足を踏み入れたので、絶対にものにするぞ！
の勢いでやっていきたいと思います💪
がんばるぞーーーーー！！！！