システム開発（サービス運営）におけるサービスレベルについて

Apexに関するつぶやきを見ていると、バグが多すぎる！すぐ直せよ！っみたいなコメントをよく見ます。こんなのウチの会社だったらアリエナイ！みたいな大人のコメントも見られるので、システム開発（サービス運営）におけるサービスレベルとリソース配分について、過去の経験から整理したいと思います。

私のシステム開発に携わった経験

２種類の異なるシステム開発の現場に携わっていました。
１つは①金融系の発注関連のシステム、もう１つは②予約や購買を行ういわゆるWebサービスです。
規模感としてはどちらも1日で億円単位以上の取引が行われるほどの大きさで、どちらも一般カスタマー向けに提供していましたが、障害やバグへの対応などのサービスレベルは全く別物でした。
残念ながらゲームの開発・運営に携わったことはないのですが、その頃の経験を交えてシステム開発及びサービス運営のサービスレベルについて考えてみます。

求められるサービスレベルの違い

システムはそれぞれ求められるサービスレベルが異なります。それは利用者からの要求レベルをもとに、企業側で提供する条件を定めることになります。
①金融系の発注関連のシステムだと「発注可能な時間帯に発注できない」「間違った値段で取引してしまった」「残高が間違っている」となると重大障害です。金融業界は安定したシステム稼働が求められ、監督省庁の金融庁から厳しくチェックされています。上記のような重大障害を頻繁に起こすと、業務改善命令や業務停止命令が下されることになります（昨今のみずほ銀行の事例を見ると金融庁との関係性が分かると思います）。
必然的にシステム開発も障害が起きないようにテスト項目が積み重なり、障害のたびに再発防止策を検討してチェックリストが分厚く・・・というスピード感よりも安全を取るようになります。新しくリリースする際も、障害が起きたら元の状態に戻す準備をして臨む、というのが当たり前でした。
②いわゆる一般カスタマー向けのWebサービスだと比較的緩いと思います。サービスが提供できない状態は重大障害だと思いますが、顧客が他のサービスを利用するようになるだけで、それによって何か処分が下されることは少ないと思います。私が携わっていたサービスも何か障害起きたらすぐ直せばいいじゃん、という軽いノリでリリースが行われ、安全よりもスピード感を重視していました。
あまりに障害が多くて社内で問題になって総点検をやることもありましたが、内部の自浄作用による改善がメインで外部からの圧力や顧客からのクレームをもとに動いている訳ではなかったです。

そのシステム（サービス）に適したサービスレベルを求めよう

そのサービスを利用できないような障害が起きた！となると機会損失が発生するので企業側としても早い対応を行います。しかし、ちょっとしたバグ程度だと、それが売上にどれだけ影響するのか、それによって顧客はどのくらい離れるのか、を考えてサービスレベルを定めるものです。サービスレベルを上げれば上げるほど、維持するための体制が増え、コストがかかるため、ちょうどいいバランスのサービスレベルを定めます。
高すぎるサービスレベルを求めて、結果的にコストが嵩む、というのはよくある話です。本当にそのサービスレベルの高さ必要なの？という点は日本のシステム開発では見直した方がいいところなのかなと思います。
我々利用者としてもバグだ！すぐ直せ！(怒)とプンスカするのではなく、このバグによる影響はどのくらいだろうか？と考えると、すぐに対応されるのか、放置されるのか、の感覚が分かってきます。

システム開発にバグは付き物です。バグが発生しないシステムなんてものは存在しなく、いかに重大障害を発生させないか、発生した時にいかに影響を極小化するか、という考え方のもと、リソースを配分しています。
バグが発生してもその影響度と緊急性をチェックして、いつ対応するかの優先順位づけをしています。些細なバグを直したら売上が上がるのか？というと、そうではないものがほとんどだと思います。それよりは売上に直結する開発を優先し、何かのついでにバグを直す、と考えるのがリソースの最適化としては正しいと考えます。
ゲームの開発現場はリソースが逼迫している、というのが定説と聞いたことがあります。好きなゲームにバグが多いとイライラするかもしれませんが、些細なバグは見過ごして楽しむ方がお得だと思います！だってその程度のサービスレベルで提供するのがリソースの最適化として正しいのですから。