非機能はなぜ必要なのか

秋のブログ週間2026 の4本目です。

はじめに

ここ数年、システムや非機能要件について深く考えることから遠ざかっていました。先日、社内の有志がまとめて公開した非機能要件のガイドラインを読んだところ、唐突にパッションを感じたので改めてブログしてまとめます。

なお当社の非機能要件ガイドラインの内容が間違っていたわけではありません。むしろ丁寧で、実務の知恵がたくさん詰まっていました。それでも、読み進めるほど小さな違和感が積み重なっていったのです。

本件に関しては、社内の有識者とも勢いにも任せてチャットで議論してみました。この記事は、そのとき勢いに任せて書いた内容を、少し落ち着いてから書き直したものです。

非機能は、技術の話だと思われていることが多い

技術者、アプリケーション設計者と会話するとき、非機能要件はどこか「技術目線の仕様」として扱われがちだと感じています。性能、可用性、セキュリティ、運用保守性。品質特性の一覧表があって、構築側がそれぞれの水準を埋めていき、最後にテストで確かめる。

もちろん、それも非機能の大事な一面です。でも、それだけだとしたら、非機能は誰のためにあるのでしょうか。

私は、非機能要件はほとんど「サービスレベル設計」と同じものだと考えています。利用者に対して「このサービスをどこまで信頼してよいか」を約束する設計です。約束するのは事業者で、約束の相手は利用者です。そう考えると、出発点は技術ではなく業務になります。性能や可用性の話をする前に、「誰が、何のために、どの程度使うのか」という問いが先に来るはずです。

「止まらないでほしい」は、まだ要件ではない

非機能要件は「機能要件からは導き出せない、暗黙の期待を可視化するもの」と説明されることがあります。たしかに、「（たとえば）いつでも使えて当然」という期待は、画面や機能を洗い出しているだけでは出てきません。それを引き出すのは大切な仕事です。

ただ、期待を引き出すことと、約束を決めることは違います。

「24 時間止まらないでほしい」は期待です。一方、「平日 8 時から 20 時の受付時間は、ほぼ止めずに提供します。夜間はメンテナンスのために止めることがあります」は約束です。後者には、夜間に使う人がどれくらいいるのか、止めないためにいくらかかるのか、という事業の判断が入っています。

期待を拾い集めるだけでは、期待が出てこなかった項目には要件がないことになってしまいます。サービスレベルは、事業者が判断して決め、関係者と合意するサービス設計そのものだと思うのです。

順番の話

ガイドラインを読んでいて、もう1つ気になったのが順番でした。進め方のステップでは、制約の洗い出しや優先度付けが先にあり、要求を数値にするステップはその後に置かれていました。

私は、要望を正しく数値にするのが先だと考えています。要望があり、それを制約に当てはめ、そのうえで優先順位を考える。制約を先に置くと、制約が議論の枠を決めてしまいます。システムの都合が先に立って、本来は妥協しなくてよかった要望まで諦めてしまうかもしれません。

さらに言えば、数値にする作業には2つの段階があると思っています。

1つ目は、業務の数値です。業務の関係者や業務フローを整理し、関係者の間で合意していくと、新しいサービスがどれくらいの人に向けて展開されるのか、繁忙期と閑散期がいつなのか、月末の締めや決算のような業務イベントで何が起きるのかが見えてきます。これを業務の言葉のまま書き出します。

2つ目が、システムの目標値です。業務の数値をもとに、性能の諸元や、止まったときに何時間で戻すか（RTO）、どの時点のデータまで取り戻すか（RPO）を決めていきます。

1つ目を飛ばして2つ目に行くと、数値の根拠が業務とつながらなくなります。

社内の議論

チャットのスレッドでは、いくつも大切な指摘をもらいました。

ある同僚は、「要件定義の段階で大事なのは上限値で、閑散期や業務イベントごとの細かい量は、機能要件が具体化した後のテスト計画で決めることではないか」と言いました。もっともです。私も、性能テストのシナリオを要件定義で決めきるべきだとは思っていません。それでも、業務イベントが機能や制約に結びつくことはよくありますし、要件定義の時点である程度の精度で数値を出せなければ、コストを見積もれず、その後の予算に響きます。どこまでを要件定義で扱うか、その境界はまだ言葉にしきれていません。

別の同僚は、「業務やアプリの側に立つと、技術的に何が可能かわからないのに仕様を決められない、という声もある」と言いました。これも本当にそのとおりです。構築側は「何を実現したいかわからないと決められない」と言い、業務側は「何ができるかわからないと決められない」と言う。鶏と卵です。

結局、三人とも同じところに着地しました。どちらかの完成を待つのではなく、お互いに仮説を置いて、往復しながら確度を上げていくしかない。業務の整理が 3 割ほど進んだあたりで、「この業務ならこのくらいの人が使うよね」「こういうイベントもあるよね」と話せる状態になります。そこから並行して走り出せばいいのだと思います。

私自身は、業務を担当する人には、まず「できる・できない」を脇に置いて、どんなサービスにしたいのかを考えてほしいと思っています。その横で、技術に詳しい人が助言する。そのうえで、できる・できないを一緒に議論する。それが理想の形だと考えています。

「保証」するのはサービスである

最後に、いちばん言いたかったことを書きます。

ガイドラインには、非機能要件を定義する目的として「実現（正しく作り、保証する）」という章がありました。そこで語られていたのは、設計とテストでした。

でも、保証すべき対象はシステムではなく、サービスのはずです。非機能テストに合格したことは、「この水準を守れるはずだ」という提供前の確認にすぎません。利用者にとって大事なのは、今日、このサービスが約束どおりに動いているかどうかです。

約束が守られているかを測る。定期的に事業者や利用者に報告する。守れなかったときには原因を調べ、手を打ち、説明する。事業が変わったら、約束そのものを見直す。そこまで含めて、はじめて「保証している」と言えるのではないでしょうか。保証はリリースの日に終わるものではなく、サービスを提供している限り続きます。

おわりに

非機能要件の話をすると、どうしても技術の言葉が先に出てきます。TPS、稼働率、冗長化、DR。どれも大事な言葉です。でも、それらはすべて「利用者に何を約束するか」を守るための手段です。

諸元がない中では、アーキテクチャは何も決められません。DR 対策ひとつとっても、サービスレベルによって答えが変わります。だからこそ、非機能を考えるときは、システムの前にサービスを、技術の前に業務を見たいと思っています。

数年ぶりに勢いで書きました。誤った解釈もあるかもしれません。ご意見をいただけたら嬉しいです。