昨年、CeFILとitSMF Japanが合併して、CeFIL内に「SMIC」（Service Management Innovation Center）を立ち上げた。私はその共同代表を務めている。
私は長年、情報システムの現場に身を置いてきた。その中で強く感じてきたのは、「サービスの継続性」がいまだに精神論に依存しているという現実だ。障害が起きれば「気を引き締めよ」「再発防止を徹底せよ」と語られる。しかし、それが経営としてどの水準のリスクを引き受け、どの価値を優先すると決めた結果なのかは、必ずしも明示されない。
サービスは、努力や気合で守るものではない。本来は、優先順位と投資配分を伴うマネジメントの問題である。どこまでの停止を許容するのか。防御と復旧のどちらに重心を置くのか。顧客価値を基準に、何を守ると決めるのか。これらは精神論ではなく、経営判断として言語化されるべき問いだ。
SMICを立ち上げた背景には、この問題意識がある。サービスの継続性を、現場の努力目標から経営の意思決定へと引き上げたい。その想いの一端として、本コラムを書いた。

１．ゼロトラブルは本当に顧客のためか

15年位前、私は米国のSaaS企業を訪問した。今でも鮮明に記憶している。
「委託するサービスは、トラブルなく運用していただけますか」と私は尋ねた。返ってきた答えは明快だった。
「標準の稼働率は99.5％です。それ以上をご希望なら、追加料金をいただきます。いかがなさいますか。」その瞬間、私は突きつけられた。

可用性は理念ではなく、コストとのトレードオフだという事実を。日本では「止めるな」が絶対命題として語られがちである。しかし彼らは違った。何％を守るのかは選択であり、その選択には価格がつく。顧客は自らの事業特性とコストを見比べて決める。そこには感情論も精神論もない。あるのは経営判断だけだ。
ゼロトラブル主義は、一見顧客第一に見える。しかし本当に顧客のためになっているのか。顧客が求めているのは「理念としてのゼロ」ではない。自分にとって重要な価値が守られることだ。この違いを曖昧にしたまま「止めるな」を絶対化すると、経営は重要な判断から目を背けることになる。

２．ゼロを前提にすると、優先順位が消える

すべてを止めない、すべてを最高水準で守る。この発想は一見強い。しかし資源は有限である。人材も予算も時間も限られている。にもかかわらず「全部を守れ」と言えば、優先順位の議論は消える。
基幹システムと周辺機能は同じなのか。新規サービスと既存基盤は同じ水準で守るのか。スピードと安定性のどちらを優先するのか。
本来、これらは経営が明示すべき問いである。しかしゼロトラブルを絶対化すると、選択の議論は精神論に置き換わる。「注意を徹底せよ」「ダブルチェックを増やせ」という指示が積み重なり、判断は言語化されないまま残る。

３．顧客価値から考える

私が所属した会社では、システム障害を「お客様迷惑度指数」という数値で評価する取り組みを行った。停止時間だけではない。影響顧客数、業務停止の深刻度、代替手段の有無などを加味し、顧客影響を定量化した。
その結果、経営会議での議論は大きく変わった。
「ゼロにしろ」という抽象論ではなく、「どの迷惑度を許容するのか」「どの領域は絶対に高指数を出してはならないのか」という具体的な対話が始まったのである。
障害はゼロにはできない。だが影響範囲は最小化できる。
この現実を経営と共有したことが、精神論からの脱却の第一歩だった。
顧客が本当に守ってほしいのは、「停止ゼロ」そのものではなく、「自分にとって重要な体験が損なわれないこと」だ。この視点に立てば、すべてを同じ強度で守ることが最適解でない場合もある。むしろ重要度に応じて守り方を変えるほうが合理的である。

４．可用性には二つの設計思想がある

サービスの安定性は、大きく二つの軸で成り立つ。
一つは、障害を起こさないように徹底的に防御すること。
もう一つは、障害が起きても迅速に復旧させること。
前者だけを追求すれば、変更は慎重になり、スピードは落ち、コストは膨らむ。後者を強化すれば、一定の発生は許容しながらも、顧客影響を抑えることができる。
99.5％で十分な領域もあれば、99.99％を求めるべき領域もある。その差を決めるのは現場ではない。事業特性と顧客価値を踏まえた経営判断である。

５．復旧速度を上げるという経営判断

「止まらないようにしろ」という命令は抽象的である。しかし「復旧時間を何分以内にする」という目標は具体的だ。
復旧速度を上げるには、監視の高度化、自動化、権限委譲、意思決定の迅速化、情報公開の透明性が必要になる。単なる気合では実現しない。組織設計そのものに踏み込む投資が求められる。
これは水準を下げる選択ではない。顧客価値を守るための、もう一つの高度な戦略である。

６．ITILが示すのは手順ではなく判断である

ITサービスマネジメントの代表的枠組みである ITIL は、単なる運用手順集ではないはずだ。インシデント管理、問題管理、変更管理といったプラクティスは、「何をどの水準で守るのか」という前提があって初めて機能する。
目標復旧時間やサービスレベルを定めることは、まさに経営が優先順位を明示する行為である。
しかし、日本企業では、ITILが手順レベルで使われている。ユーザーが優先順位を決めないし、運用側は経営に対して優先順位の問いを発することができない。私自身の反省でもある。コストとのトレードオフや深夜対応の常態化について、もっと経営に迫るべきだった。

７．ゼロトラブルを超えて

ITILが本来示しているのは、運用の厳格さではなく、経営の判断を可視化する枠組みである。問うべきは「止めるな」ではない。「何を守り、どう守るのか」である。
米国SaaS企業の99.5％という数字も、「お客様迷惑度指数」という試みも、いずれも同じことを示している。サービスの水準は、理念ではなく選択であるという事実だ。
この問いを、ユーザーや経営層に向けて発していく力を運用チームは持つべきである。それこそが、真のパートナーとしての役割だ。
「ITILはじめの一歩」（最上千佳子著）の「おわりに」に、次の言葉がある。
「サービスマネジメントとは、働いている人たちを幸せにすること。」
ゼロを掲げて疲弊させるのか。
選択を言語化し、納得の上で守るのか。
その違いは、経営の優先順位にある。