サービスレベル設計として捉える非機能の考え方

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

前回の 非機能はなぜ必要なのか の続編です。前回は社内の非機能要件ガイドラインを読んで感じた違和感をエッセイとして書きましたが、今回はその考え方を、実務で使える形に整理し直したものです。

本記事の位置づけ

本記事は、非機能を「システム開発者の目線」ではなく「事業者（サービス提供者）の目線」で捉え直し、考え方の軸を整理するものです。

• 扱うこと: 非機能とは何か、何のために決めるのか、どの順番で誰が決めるのか、何をもって保証とするのか
• 扱わないこと: 個々の品質特性の設計手法、テスト技法の詳細、フレームワーク（IPA 非機能要求グレード等）の項目解説
• 前提: 提案やグラウンドデザイン（GD）などの上流検討で、大枠のやりたいことが決まっていることを前提とする。整理されていない場合の補い方は「前提条件」の章で述べる

本記事の立場

現状の違和感

非機能は「技術目線の仕様」として扱われることが多いと感じています。性能・可用性・セキュリティといった品質特性の項目を並べ、構築側が水準を埋め、テストで担保する、という形です。この捉え方には次の弱点があります。

• サービスレベルへの意識が薄い。項目を埋めること自体が目的になりやすい
• 非機能が「サービスの水準を決めるもの」だという意識が薄い。結果として、決める主体が構築側に寄る
• 非機能を「機能要件から導出できない暗黙の期待を可視化するもの」と捉えると、構築側が期待を拾い集める受け身の構図になる
• 「保証」の対象がシステム（設計とテスト）に閉じ、提供中のサービスが約束を守っているかが問われない

本記事の立場

非機能とは、利用者に対して「このサービスをどこまで信頼してよいか」を約束する設計です。
したがって、非機能はほぼサービスレベル設計と同じものであり、出発点は技術ではなく業務です。

約束する主体は事業者であり、約束の相手は利用者です。構築側（アーキテクト）は、その約束を数値に翻訳し、守れる仕組みを作り、守れていることを示す役割を担います。

二つの捉え方の比較

非機能とは何か

機能と非機能

• 機能: サービスが何をできるか
• 非機能: そのサービスを、どの水準で提供すると約束するか

約束としての書き方は、利用者が体感できる言葉で、どの場面で、どの程度、守れなかったらどうするかまでを含みます。技術的な目標値は、この約束を守るために後から導出するものです。

「暗黙の期待」ではなく「合意する約束」

「いつでも使えて当然」といった暗黙の期待を引き出すことは大切ですが、それは入力の1つにすぎません。サービスレベルはサービス設計そのものであり、事業者が判断して決め、関係者と合意すべき要件です。

期待を拾うだけでは「期待が出てこなければ要件もない」ことになります。約束として設計するなら、期待が出てこない項目も事業者が判断しなければなりません。

SLI・SLO・SLA

社内向けシステムでも SLO の考え方はそのまま使えます。約束の相手が社内の業務部門になるだけです。

利用者から見たサービスレベルの観点

品質特性の一覧から始めるのではなく、利用者の問いから始め、対応する技術的な観点に落とします。

運用やサポートの水準もサービスレベルの一部です。システムの品質特性だけではサービスレベルは語れません。

前提条件 ― 着手時点で何が整理されているか

サービスレベル設計の精度は、着手時点で業務とサービスがどこまで整理されているかで決まります。最初に入口の状態を確認し、不足しているものを関係者と共有します。

新規構築でも数値は出せます。新規サービスであれば、企画段階で「どれだけの利用者に、どれくらい使ってほしいか」という KPI が定められているはずです。実態がそうなるかは別として、事業目標から逆算した数値は根拠が明確で、むしろ確度の高い前提になります。KPI が定まっていないなら、それ自体が事業上のリスクとして事業者に問い返すべき事項です。

上流の検討がない場合は、要件定義の提案時に仮説を立てて補うことになります。ただし、その時間は取れないことが多いものです。そのため、何が整理されていないかを A（前提の確認）で明示し、不足分を補う作業をあらかじめ計画に組み込んでおきます。

目的 ― 何のためにサービスレベルを設計するか

要求: 何を約束するかを決める

• 利用者に何を、どの水準で約束するかを、業務の根拠とセットで決める
• 約束の水準がコストを決める。可用性や性能の水準は、インフラ構成、冗長化の範囲、運用体制、ひいてはランニングコストを左右する
• ランニングコストまで見積もれなければ、事業者は投資判断（決裁）ができない。サービスレベルが決まらないまま進めることは、予算の根拠がないまま進めることと同じである

実現: 約束を守れる形で作る

• 設計: アーキテクチャはサービスレベルから導出する。たとえば DR 対策の要否と方式は、サービスが止まったときの事業影響と、合意した RTO・RPO で決まる。サービスレベルがない状態では、アーキテクチャは何も決められない
• テスト: 提供を始める前に、約束した水準を満たせることを確認する

保証: 約束が守られていることを示し続ける

非機能テストの合格は「この水準を守れるはずだ」という提供前の確認にすぎません。保証すべき対象はシステムではなくサービスであり、保証はサービスを提供している間ずっと続きます。

保証の仕組み（何を測り、どこに報告し、未達時に誰が何をするか）も、サービスレベルの合意内容に含めます。測り方が決まっていなければ、同じ実績を見ても達成か未達かの判断が食い違います。

SLO を下回らない範囲で許容できる失敗の量（エラーバジェット）を持つと、「新機能のリリースを優先するか、安定化を優先するか」を事業者と構築側が同じ物差しで判断できます。

社内向けシステムでは、業務部門を相手に SLI の計測と定期報告まで行う負荷が大きい場合もあります。その場合は、止まると事業に響く重要な業務から適用し、測る指標を少数に絞って始めます。

継承: 約束と根拠を引き継ぐ

合意したサービスレベルは、業務上の根拠とセットで残します。根拠が残っていれば、事業が変化したときに「約束を変えるべきか」「システムを変えるべきか」を判断できます。根拠のない数値だけが残ると、後任が過剰に、あるいは過小に作り込みかねません。

進め方

原則: 要望を先に数値にする

要望を数値にし、その後で制約に当てはめ、優先順位を決めます。順番を逆にして制約を先に置くと、制約が議論の枠を決めてしまい、本来妥協しなくてよい要望をシステムの都合で諦めることになります。

要望は 2 段階で扱います。満たせなければサービスが成り立たない「絶対に外せない要望」を、まず B で定性的に押さえ、C で業務の数値にします。

ただし、法規制、全社ポリシー、決定済みの技術スタックといった「変えられない制約」は早めに集めておきます。これは要望の検討を止めるためではなく、後の手戻りを防ぐための情報収集です。制約の収集は B・C と並行して進めますが、当てはめるのは要望を数値にした後の E とします。

全体の流れ

各ステップは一方通行ではありません。後段で判明したことを受けて、サービスレベル定義（D）に戻って約束を更新します。

各ステップ

A. 前提の確認

「前提条件」の章のチェックリストで、着手時点で何が整理されているかを確認し、不足しているものとその補い方を関係者と共有します。

B. 業務とサービスの解像度を上げる

主体は業務担当者です。アーキテクトは並走して助言します。定性的でよいので、次を整理します。

• 誰が使うか: 利用者の区分と、区分ごとのおおよその人数
• 何のために使うか: 業務の目的。止まったとき、遅いとき、データを失ったときに業務で何が起きるか
• どの程度使うか: 利用の頻度と時間帯、繁忙期と閑散期、業務イベント（月末締め、決算、キャンペーン、年度切替など）

あわせて、満たせなければサービスが成り立たない「絶対に外せない要望」を定性的に押さえておきます。C で数値にし、E で制約と突き合わせるときの軸になります。

業務イベントは、非機能だけでなく機能や制約にも結び付きます。たとえば締め処理の時間枠は、バッチの処理時間やオンラインを止められるかどうかを決めます。

業務の整理が完成するまで待つ必要はありません。関係者と業務フロー、制約がおおよそ整理できた段階（感覚として 3 割程度）で、「この業務ならこのくらいの利用者になる」「こういうイベントがある」といった話ができる状態になります。そこから並行して次のステップを始めます。

C. 定量化 第1段階: 業務の数値

業務の言葉のまま、数値にします。技術用語（TPS など）はまだ使いません。

業務担当者が数値を出しにくい場合は、アーキテクトが事業計画や現行の実績から仮説を示し、「この想定で実態と合っているか」を確かめます。成果物は、業務と結び付いた基礎数値の一覧です。

D. サービスレベル定義の合意

業務の数値をもとに、利用者向けの約束としてサービスレベルを言葉にし、事業者と合意します。ここで合意するのは利用者向けの約束であり、技術的な目標値（TPS、構成など）ではありません。

合意する内容は、末尾のサービスレベル定義シートを参照してください。最低限、次を含めます。

• 対象のサービスと利用者
• 提供時間帯
• 何を測るか（SLI）と、目標値（SLO）
• 測り方（計算式、計測地点、集計期間）
• 守れなかったときの扱い（報告、改善、利用者への説明）
• その水準にした業務上の根拠

E. 制約への当てはめと優先度付け

合意したサービスレベルを、予算、スケジュール、規程、技術制約、外部依存（外部の認証基盤や連携先の SLA など）に当てはめます。収まらない場合は、要件を Must（満たせなければ事業が成り立たない）、Should（交渉の余地がある）、Want（余裕があれば実現する）に分けて調整します。

妥協するかどうかを決めるのは事業者です。構築側は「水準とコストの組合せ」と「妥協したときに利用者と業務に何が起きるか」を選択肢として示します。妥協した場合は、D に戻ってサービスレベル定義（約束）を更新します。システムの都合で黙って水準を下げてはいけません。

F. 定量化 第2段階: システムの目標値

合意したサービスレベルを、システムの目標値に変換します。性能諸元（TPS、データ量）、稼働率、RTO・RPO、DR 方式、バックアップの頻度と保管期間などです。

変換の計算式は、業務の数値と結び付けて残します。

ピーク時の同時利用者 1,000 人 × 10 秒に 1 回の操作 = 100 TPS
月末締めの日は通常の 3 倍の件数 → 300 TPS を上限として設計する

要件定義の段階で求める精度は、サービスレベルとコストの判断に効く範囲までとします。特に上限値（最大の利用者数、最大の件数）は必ず押さえます。

業務イベントは、構成、コスト、機能、制約のいずれかを変えるものまでを要件定義で扱います。判断に迷ったら「そのイベントを知らないままだと、アーキテクチャかコストが変わるか」を問います。変わるなら要件定義で数値にし、変わらないなら後続に回します。業務イベントごとの細かいボリュームを性能テストのシナリオにまで落とし込むのは、機能要件が具体化した後のテスト計画で行います。

G. アーキテクチャとコストの見積もり

サービスレベルから導出した目標値をもとに、アーキテクチャと、イニシャルコストおよびランニングコストを見積もります。サービスレベルの水準ごとに複数案（例: 高・標準・最低限）を示すと、事業者は水準とコストを比べて判断できます。コストが事業計画に合わなければ、D に戻って約束を見直します。

H. 実現と保証

設計、構築、非機能テストで「約束を守れる」ことを確認し、提供開始後は SLI の計測、定期報告、未達時の対応、見直しで「約束を守っている」ことを示し続けます（「保証」の節を参照）。運用の実績は、次のサービスレベル見直しの根拠になります。

役割分担

業務担当者は、まず「できる・できない」を脇に置き、どんなサービスにしたいかを考えます。アーキテクトはその横で、技術的な実現性とコストを助言します。そのうえで、できる・できないを一緒に議論します。

仮説を置いて往復する

サービスレベル設計には、次の鶏と卵の問題があります。

• 業務側: 技術的に何が可能かわからないと、仕様を決められない
• 構築側: 何を実現したいのかわからないと、アーキテクチャを決められない

どちらかの完成を待っていては進みません。双方が仮説を置き、往復しながら確度を上げていきます。

往復の進め方

• 業務の整理が 3 割程度進んだ時点で、並行してサービスレベルの仮説を置き始める
• 数値には確度を添えて扱う（仮置き、確度中、確定）。仮置きの値は幅を持たせ、確度が上がるにつれて狭める
• 確度の低い値を「確定」として約束しない。後から水準を下げる説明は、上げる説明よりはるかに難しい
• 仮説を覆すときは、事業前提の変化や実績との乖離といった理由を添えて説明する

アーキテクチャの検討が先行する場合

リプレイスやデータ基盤の案件では、基盤の制約が決まらないとアプリの要件が煮詰まらないため、アーキテクチャの検討が業務・アプリの検討より先に始まりやすいです。一方で、業務要件がまったく固まっていない状態では、サービスレベルも固められません。

アーキテクチャの検討が先行する場合も、次を守ります。

• 先行して決めるのは方針レベルにとどめる
• 前提にしたサービスレベルの仮説（業務の数値の仮置き）を明示する
• 業務検討の結果で仮説を検証し直すことを、あらかじめ関係者と合意しておく

さいごに

非機能を技術の仕様としてではなく、利用者への約束として捉え直すと、誰が決めるのか・どの順番で数値にするのか・何をもって保証とするのかが自然に定まります。前回のエッセイで感じた違和感を、実務で使える形に落としたつもりです。足りない点や異論があれば、ぜひ聞かせてください。

用語

サービスレベル定義シート（テンプレート）