非機能要件が後回しで地獄を見る──性能・可用性・運用を最初に置く設計の型

リリース直前、画面もAPIも一通り動いている。
なのに、現場だけが妙に落ち着かない。

負荷テストの結果が怖い。監視が決まっていない。障害時の手順が曖昧。
とても香ばしい香りがするプロジェクト。

何より、誰も「落ちたときにどう戻すか」を言語化していない。

すでに煙の臭いが漂っている。

この状態、プロジェクト経験が増えるほど見覚えがあるはずです。
そしてだいたい、同じ言葉で炎上が始まります。

• 想定より遅いですね（性能）

• 落ちたらどう復旧します？（運用）

• その停止、許容されます？（可用性）

ここで慌てて非機能要件を詰めようとしても、間に合いません。
なぜなら、非機能は仕様の「付け足し」ではなく、設計の「土台」だからです。

非機能が後回しになるのは、努力不足ではなく構造

非機能要件が後回しになる現場には、だいたい次の3つが揃っています。

1) 目に見える成果物が優先される

画面、機能、API、業務フロー。
成果物が可視化されやすいものほど「進捗」として扱われ、非機能は見えにくいぶん後回しになります。

2) 決める責任が宙に浮く

性能目標、SLA、RTO/RPO、監視、アラート閾値、運用体制。
これらは「誰が決めるか」が曖昧になりやすい。結果、決まらないまま実装が進みます。

3) 非機能がトレードオフの塊だと忘れられる

性能を上げればコストが増える。
可用性を上げれば設計と運用が重くなる。
運用を簡単にすれば自動化や仕組みが必要になる。

つまり非機能は、意思決定そのものです。
意思決定を避けると、最後に「まとめて支払う」ことになります。

非機能の正体は、3つの問いに集約できる

僕が現場でまず置くのは、性能・可用性・運用をそれぞれ「問い」に落とすことです。

• 性能：いつ、何が、どれくらい速くあるべきか

• 可用性：何分（何秒）止まってよいのか、止まったら何を守るのか

• 運用：誰が、何を見て、どう判断し、どう戻すのか

この3つの問いが先に固定されると、設計と実装の迷いが減ります。
逆に、ここが曖昧なままだと、どれだけ実装しても不安が消えません。

型：非機能を最初に置く 3点セット

ここからが実務の型です。
非機能は全部を網羅しようとすると重くなるので、最初は3点セットだけ置きます。

① 目標値を1行にする（性能・可用性の最低ライン）

例）

• 平常時：主要APIは p95 500ms 以内

• ピーク時：同時○○ユーザーで p95 800ms 以内

• 可用性：月間停止許容 30分（計画停止含む／含まないを明記）

ポイントは「測れる言葉」にすること。
速い、落ちない、安定、では議論が終わりません。

② 失敗時の優先順位を決める（守る順番）

例）

• 最優先：データ整合性（壊さない）

• 次点：ユーザー影響の局所化（全停止より機能縮退）

• その次：復旧時間（RTO）

• 最後：コスト

非機能の地獄は、失敗時に「何を守るか」が決まっていないときに起きます。
優先順位が決まっていれば、障害対応の判断が速くなります。

③ 運用の入口と出口を決める（監視→判断→復旧）

ここは難しく見えますが、最初は型で十分です。

• 監視：何を見て異常とするか（メトリクスと閾値）

• 判断：誰が、どの時間帯に、何分以内に判断するか

• 復旧：切り戻し手順／縮退手順／連絡順を1枚にする

運用が「気合い」になる現場ほど、復旧が属人化し、夜間対応が固定メンバーに寄ります。
設計の問題が、人の疲労として現れるんです。

具体例：要件定義の場で、こう聞くと一気に進む

非機能を早く置くには、要件定義の場で質問の順番を変えます。
僕は次の順で聞きます。

1. いちばん困る失敗は何ですか（遅い、止まる、壊れる、漏れる）

2. それが起きたとき、何分までなら許容できますか

3. その許容を超えたら、何を優先して守りますか

4. それを守るために、運用で誰が何を見て判断しますか

この順番だと、相手は「技術の話」ではなく「事業の話」として答えられます。
結果、目標値やSLAが置けるようになります。

1週間の最小実装：明日やる1つ、今週やる1つ

明日やる1つ

プロジェクトの資料か議事録に、非機能の3点セット欄を作ってください。
目標値1行／失敗時の優先順位／運用の入口と出口。
空欄でもいいので「ここを決める場所」を先に作る。

今週やる1つ

ステークホルダーを集めて、30分だけ「失敗時の優先順位」を確定してください。
ここが決まるだけで、設計の迷いが減り、後半の議論が速くなります。

よくある失敗：真面目な人ほど逆噴射する

非機能でやりがちな逆噴射は、この3つです。

• 完璧な非機能一覧を作ろうとして、決める前に疲れる

• 負荷試験だけ先にやって、目標値がないので結論が出ない

• 監視ツール導入が目的化して、判断と復旧が置き去りになる

非機能は「全部やる」より「決める順番」が大事です。
小さく置いて、運用しながら育てるのが勝ち筋です。

まとめ：非機能は、最後に足すものではなく最初に置く判断基準

性能・可用性・運用。
これは技術論に見えて、実態は「意思決定の設計」です。

最初に置くべきは、立派な資料ではありません。
目標値1行、失敗時の優先順位、運用の入口と出口。
この3点があるだけで、後半の地獄をかなり減らせます。

最後に問い

あなたの現場で、いま一番宙に浮いているのはどれですか。
性能の目標値、可用性の許容、運用の判断と復旧──まずどれを1行にしますか？

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！

個別に整えたい人へ（キャリア相談）

僕は普段、30代エンジニアのキャリア停滞を抜け出す支援をしています。
現場の詰まりをほどいて、評価・役割・選択肢を整えるために、状況を一緒に棚卸しできます。

▼相談はこちら（ココナラ）：