フューチャー技術ブログ

非機能テストを記号接地する

テスト連載2026 の3本目です。

1. はじめに

TIG(Technology Innovation Group)の清水です。

あなた今回非機能テストやってみない?と言われた。けどそれってなんだっけ、という人向けの記事です。「非機能テスト」と聞いてなんとなくイメージが浮かぶようになる、が記事の目標です。

2.  そもそも 【非機能】 が分かりにくい

【非機能】という単語がそもそも分かりにくいです。

「キノウではナイもの」。なんだそれは。

絵だとこうです。うーむ分からん。

IMG_0098.png

非機能は【構造】と捉えると分かりやすいです。

機能(サービス)を支える構造、ですね。

絵はこうです。さっきより多少いいでしょうか。

でも具体、のイメージはまだつきにくいです。

IMG_0100.png

3. 門限が決まっている → 性能要件

映画館の【券売機】を例に考えます。

予定時刻で映画が始まってしまう。

開始5分前に50人来て購入・発券するなら、1分あたり10人を捌く必要がある。券売機が2台なら、1台はその半分捌ければ良いです。

業務 門限から考えて、どれくらいのスピードが必要か です。

映画を楽しんでもらう・また来ようと思ってもらう を頂点として、券売機に求められる性能要件は何か、ですね。

IMG_0101.png

本当の映画館では、ポップコーンを買ったりトイレに行ったりの時間もあります。始まるといっても予告編があり、人の流量をどう見立てるかが重要です。家族なら人数分まとめて発券するでしょう。web予約側は20分前締め切り・劇場では開始直前まで、という条件もあります。映画館によっては上映開始後でも購入可能で、考え方の違いが門限に現れています。1人でぽっかり時間空いた・映画見るぞというとき、上映開始後に購入できると確かに嬉しいです。

券売機の要求を処理するシステム側から考えるとき、日本全国で100館・1館に5台券売機があるなら、500台の券売機が同時要求してきます。お客さんから券売機いくらなんでも遅すぎだろと思われると、次は違う映画館に行ってしまうかも知れません。それより前に現場が混乱します。あーまた、とニュースになるでしょう。目も当てられません。ということで機能と非機能を絵にします。

IMG_0102.png

非機能

ここではスピードを取り上げました。性能ですね。

空席確認から発券までに2時間かかったら、お客さんは違う映画館に行ってしまうでしょう。頑張って作った機能が全て台無しです。映画を楽しんでもらう・また来ようと思ってもらうというそもそもの話が、吹き飛んでしまいます。

非機能で転んで全てが台無しになるケースのイメージです。では何秒だったらOKなのか。処理量、同時性、画面フレームワーク特性、ネットワーク構成、排他制御、選択した各処理方式等含めて限界がある中で、経済合理性とバランスが取れ、構築期間を守ることができ、映画を楽しんでもらうを実現できるところが、目的地です。

応答が遅いと怒られる

「門限までに全部処理して!」以外に、画面レスポンスが遅くて怒られる、もあります。空席表示に10秒かかったら、まず「壊れてるな」と連打されます。普段みんなが使っているスマホアプリとの体感勝負になりやすいです。あまりに高性能を求めると、実現可能性に黄色信号が点るのと合わせて、費用にはねてきます。

一度にお客がいっぱいやってくる

人気アイドルグループの最終ツアー、となるとチケットサイトには一度に大勢のファンが押しかけます。想定を超えた要求がやってくると、システムはスローダウンし挙動が不安定になります。このような性質のシステムでは、性能破綻しないように流量制御機構を配備します。流量に合わせてシステムリソースを拡張する方式を採るケースもあります。「あなたは何番目」を見えるようにし、お客さんのイライラを鎮める工夫もするでしょう。あまりに大きな非機能(性能)要件から、新しい機能・アーキテクチャが必要になるケースです。全体が破綻しないように、システム挙動をいかに想定内・テスト範囲内に収めるか、が重要です。

全公演満席になるほどの人気グループであれば、チケットサイトが一時期ダウンしても、割当枚数は復旧後に販売できます。しかしサイト全体が重くなることで、他のコンサートや美術館チケットを買おうとしていたユーザーは競合サイトに流れるでしょう。流量制御機構を配備することで回避できます。

4. テストする

非機能要件定義で「この機能群を、こんなふうに支えてほしい」を確定します。その通りに動くかを、実際にやって証明するのが【非機能テスト】です。
ただ最後の最後にそもそもこれって。。。となると収拾がつかなくなります。このアーキテクチャで非機能要件が達成できるか、はアーキテクチャ決定時に確認する必要があります。これははじめての性能テスト にも記載されています。

サービスに必要な非機能 = 機能を支える構造、は性能だけではありません。
代表的なものを普通のことばで表現するとこうです。

  • どれくらいのスピードを出したいか?
  • どれくらい伸縮させたいか?
  • どれくらいの止まりにくさにしたいか?
  • 5年間サービス維持できそうか?
  • どれくらいの耐攻撃性にしたいか?

テストについて言えることがあります。

  • その条件で 動かしたなら大丈夫」
  • 「動かしていないなら、いざという時に動かなくても不思議はない」

そして非機能で転ぶと「特定機能の停止」にとどまらない全滅がありえます。熟慮し先を見ながら進めたいですね。

5. 終わりに

非機能テストってなんだっけ、という方がなんとなくイメージを持てるように、記事を書きました。なんとなくイメージついたかも。。?という方は是非一歩踏み出してください。

すでに、ガイドライン公開したよ記事 & ガイドライン本体が公開されています!