2-1ストレージ
年が明けて最初の土曜日、予約システムの箱の前面で、小さなランプが一つだけ赤く光っていました。業者に電話すると、中に4台入っている保存用のディスクのうち1台が壊れている、という答えです。ミナトは青くなって予約の画面を開きましたが、画面はいつもどおり動いていて、きのうまでの予約も1件も欠けていません。ほっとしたのもつかの間、夕方になると別の困りごとが顔を出します。お客さんの予約が重なる17時前後になると、画面の表示が目に見えて遅くなるのです。数日後、業者から見積もりが2通届きました。「速いディスクを足す案」と「サーバを1台増やす案」です。店長は2枚の紙を並べて言いました。「どっちが速くて、どっちが止まりにくくて、5年でいくらかかるのか。それが分からないと選べないよ」
ミナトが最初に相棒に聞いたのは、見積もりのことではありませんでした。「ディスクが壊れたのに、どうしてデータが消えなかったの」。相棒の答えは短いものです。「4台のディスクを、1台の大きな装置に見せかけて使っているからだよ」
複数のディスクを組み合わせて一つの記憶装置として扱い、故障してもデータを守れるようにしたり、読み書きを速くしたりする技術をRAIDといいます。Redundant Arrays of Inexpensive Disks の頭文字で、安いディスクを冗長に（余分を持たせて）並べる、という意味です。後に Inexpensive を Independent と読み替えることも増えました。どう並べるかによって、速さを優先するか、故障への強さを優先するかが変わります。
こむぎ堂の箱で起きたことを説明できるのは、そのうちの「同じデータを2台に書いておく」並べ方です。同じ内容を2台以上のディスクに同時に書き込むことをミラーリングといいます。鏡に映したように同じものが2つあるので、片方が故障しても、もう片方から読めます。そのかわり、2台使っても、保存できる量は1台分です。
ここから基本情報！RAIDの種類
RAIDには、並べ方ごとに番号の付いた方式（RAIDレベル）があります。違いを理解するには、二つの仕組みを先に知っておくと分かりやすくなります。
一つめは、データを細かく区切って複数のディスクに順に振り分けて書くストライピングです。予約データを1件ずつ交互に4台へ書けば、4台が同時に読み書きでき、1台のときより速くなります。ストライピングだけでは余分を持たないので、故障への備えにはなりません。
二つめは、元のデータから計算して付け足しておくパリティです。RAIDでは、各ディスクのビットの排他的論理和（XOR：同じなら0、違えば1）をパリティにします。小さな例で確かめてみましょう。ディスクAに1011、ディスクBに0110が書かれているとき、パリティは1011 XOR 0110 = 1101 です。ここでBが故障しても、残ったAとパリティから 1011 XOR 1101 = 0110 と計算でき、Bの中身がそのまま戻ります。パリティ1台分で、どれか1台が消えた分を復元できる、というわけです。
この二つの組み合わせ方で、RAIDレベルが分かれます。
| 方式 | データの置き方 | 何台の故障まで耐えるか | 2TBのディスク4台で使える量 |
|---|---|---|---|
| RAID0 | ストライピングだけ。余分を持たない | 0台（1台の故障で全部を失う） | 8TB |
| RAID1 | ミラーリング。2台に同じものを書く | 組の片方 | 4TB（2台ずつの組を2つ） |
| RAID10（RAID1+0） | ミラーリングした組を、さらにストライピングする | 各組の片方ずつ | 4TB |
| RAID2 | ビット単位で分散し、ハミング符号で誤りを訂正する。訂正用のディスクを複数台使う | 1台 | （実用ではほとんど使われない） |
| RAID3 | バイト単位でストライピングし、パリティを専用の1台に書く | 1台 | 6TB |
| RAID4 | ブロック単位でストライピングし、パリティを専用の1台に書く | 1台 | 6TB |
| RAID5 | ブロック単位でストライピングし、パリティも全ディスクに分散して書く | 1台 | 6TB |
| RAID6 | RAID5に、計算方法の違う2つめのパリティを加えて分散する | 2台 | 4TB |
RAID3とRAID4は、パリティを1台にまとめているので、データをどこに書き込んでも、そのたびにパリティ用の1台にも書き込みが起きます。書き込みがその1台に集中して、待ちができやすくなります。RAID5は、パリティをディスクごとに順番に置き場所を変えて分散させることで、この集中を避けています。こむぎ堂の箱がこれでした。4台のうち1台が故障しても、残る3台のデータとパリティから、なくなった分を計算できたのです。
基本情報の範囲ここまで
RAIDは、サーバの箱の中でディスクを束ねる技術です。これとは別に、記憶装置をネットワークにつなぎ、何台ものパソコンから共有して使う形もあります。LANに直接つなぐ、ファイルの共有に特化した記憶装置をNAS（Network Attached Storage）といいます。こむぎ堂なら、店のパソコンと厨房のタブレットの両方から、商品の写真やレシピのファイルを開けるようになります。NASの中身も、RAIDで組んでおくことがよくあります。
ここから基本情報！ブロック単位で使うストレージ
NASは「ファイル」の単位で貸し借りをします。これに対し、サーバと記憶装置を、ふだんのLANとは別の専用のネットワークでつなぎ、サーバから見て自分のディスクのように「ブロック」の単位で読み書きさせる構成をSAN（Storage Area Network）といいます。データベースのように細かい読み書きが大量に起きるサーバで使われます。
基本情報の範囲ここまで
2-2信頼性設計
赤いランプの話を聞いた店長は、感心するより先に首をかしげました。「壊れないディスクを買えば、そもそも困らなかったんじゃないの」。ミナトは答えに詰まり、相棒に打ち込みます。「壊れない部品って、買えるのかな」
相棒の返事は「壊れにくい部品は買える。でも、壊れない部品は買えない」でした。システムの正常な動作を妨げる原因となる、装置の故障やプログラムの誤りをフォールトといいます。フォールトを完全になくすことはできません。そこで信頼性の設計では、「フォールトをどう減らすか」と「フォールトが起きたときにどうふるまうか」の二つを考えます。
ここから基本情報！故障を防ぐ・隠す
店長の言う「壊れないディスクを買う」は、一つめの考え方にあたります。品質の高い部品を選び、十分に試験をして、故障そのものが起きないようにする考え方をフォールトアボイダンス（故障の回避）といいます。ただ、どれだけ部品を選んでも、故障の確率は0になりません。
故障が起きたあとの考え方の一つが、故障の影響を外に出さずに隠してしまうフォールトマスキングです。同じ計算を3台でさせて、1台だけ答えが違えば多数決で残りの2台の答えを採る、といった仕組みがこれにあたります。利用者は、1台が間違えたことに気づきません。
基本情報の範囲ここまで
こむぎ堂のディスクで起きたのは、「壊れても止まらない」ほうでした。構成要素の一部が故障しても、システム全体としては機能を止めずに動き続けられる性質をフォールトトレラント（耐障害性）といい、この性質を持つように設計したシステムをフォールトトレラントシステムといいます。RAIDで組んだディスクや、第1章で見た2台の装置を並べる構成は、その代表的な作り方です。
ただ、止まらずに動き続けることが、いつも正しいとは限りません。故障したときに、被害が広がらない安全な側へシステムを倒す考え方をフェールセーフといいます。信号機が故障したら全部の方向を赤にする、オーブンの温度センサが故障したらヒータを切る、というのがその例です。動き続けることより、安全に止まることを選んでいます。
ここから基本情報！機能を落として動き続ける
フェールセーフと対にして覚える考え方が、故障した部分を切り離し、機能や性能を落としてでもシステム全体の運転を続けるフェールソフトです。そうして機能を落としたまま動かしている状態を縮退運転といいます。こむぎ堂の予約システムで画像を置くサーバが止まったら、商品の写真を出さずに文字だけで予約を受け付け続ける、といった運転です。
基本情報の範囲ここまで
装置の故障とは別に、人の操作の誤りに備える考え方もあります。利用者が誤った操作をしても、危険なことや誤った動作が起きないように作っておくことをフールプルーフといいます。予約の画面で、過去の日付や定休日を選べないようにしておく、受け取り時刻に「25時」と入力できないようにしておく、というのがその例です。電子レンジが扉を閉めないと動かないのも、同じ考え方です。
ここから基本情報！人の誤り
不注意や思い違い、うっかりの押し間違いなど、人によって引き起こされる誤りをヒューマンエラー（人的ミス）といいます。注意を呼びかけるだけでは、ヒューマンエラーはなくなりません。フールプルーフのように、間違えられない仕組み、間違えても困らない仕組みを作っておくことで、影響を抑えます。
基本情報の範囲ここまで
2台の装置を用意して故障しても止まらないようにする場合、予備の側をどれだけ準備しておくかにも段階があります。予備機の電源を入れ、同じソフトウェアを動かして、いつでも切り替えられるように待たせておくのがホットスタンバイです。予備機は用意しておくものの電源は入れておかず、故障してから起動して切り替えるのがコールドスタンバイです。ホットスタンバイのほうが切り替えは速く、そのぶん電気代などの費用がかかります。
ここから基本情報！2台の役割分担
2台をどう働かせるかで、冗長構成はさらに二つに分かれます。ふだんは片方の系だけが処理をし、もう片方は待機しておいて、故障したら処理を引き継ぐ構成をアクティブ-スタンバイ構成といいます。待機している系は、ふだんは仕事をしていません。
これに対し、両方の系をどちらも現役として同時に動かし、処理を分け合う構成をアクティブ-アクティブ構成といいます。ふだんから2台で負荷を分けられるので、速さの面でも得をします。そのかわり、片方が止まると残りの1台に処理が全部かかるので、1台でもさばけるだけの余裕を持たせておく必要があり、データのそろえ方も複雑になります。
基本情報の範囲ここまで
2-3性能指標
平日の17時、ミナトはスマートフォンで予約の画面を開き、ストップウォッチを押しました。「受け取り日を選ぶ」をタップしてから、カレンダーが出るまで4.2秒。昼の2時に同じことをしたときは0.6秒でした。「遅い」と言うだけでは、業者に伝わりません。
ミナトが測ったのは、利用者が操作をしてから、システムから最初の反応が返ってくるまでの時間です。これをレスポンスタイム（応答時間）といいます。予約の画面のように人が画面の前で待つシステムでは、利用者がいちばん直接に感じる速さです。17時のレスポンスタイムは、昼の7倍になっていたことになります。
ここから基本情報！時間と量の物差し
速さの物差しは一つではありません。こむぎ堂では、閉店後に1日の売上を集計する処理を毎晩動かしています。このように、処理を依頼してから、結果がすべて出そろうまでの時間をターンアラウンドタイムといいます。売上の集計を22時に始めて、22時12分に集計表ができあがったなら、ターンアラウンドタイムは12分です。レスポンスタイムが「最初の反応まで」なのに対し、ターンアラウンドタイムは「最後の結果まで」を測ります。
もう一つ、時間ではなく量で測る物差しがあります。単位時間あたりに処理できる仕事の量をスループットといいます。予約システムが1分あたり何件の注文を受け付けられるか、がこむぎ堂のスループットです。1件ごとのレスポンスタイムが短くても、同時に何件もさばけなければ、スループットは小さいままです。
基本情報の範囲ここまで
では、17時に遅くなったのはどこのせいなのでしょうか。業者が調べると、予約システムの中で順番に仕事をする3つの部分の処理能力は、画面を返す部分が1分に300件、予約の中身を確かめる部分が200件、ディスクに書き込む部分が80件でした。注文は3つを順に通るので、全体では1分に80件までしか進みません。前の二つがどれだけ速くても、いちばん遅いところで待ちができるからです。このように、システムの中で最も処理能力が低く、全体の速さを決めてしまっている部分をボトルネックといいます。瓶の首（ボトルネック）が細ければ、瓶をいくら大きくしても注ぐ速さは変わりません。こむぎ堂のボトルネックはディスクでした。
見積もりの2つの案が本当に速くなるのかを比べるには、同じ条件で測る必要があります。共通の基準となるプログラムやデータを使ってコンピュータやシステムの性能を測り、比べることをベンチマークといい、そのための試験をベンチマークテストといいます。2つの案それぞれで、同じ100件の予約を流し込み、何秒で終わるかを測れば、比べる材料になります。
ここから基本情報！業界で共通のベンチマーク
メーカーの違うコンピュータを比べるために、業界団体が決めた共通のベンチマークがあります。TPCは、トランザクション処理の性能を測るベンチマークを定めている団体（Transaction Processing Performance Council）と、そのベンチマークのことです。注文の受付や在庫の更新のような、データベースへの小さな処理を大量にこなす速さを測ります。
CPUの演算性能を測るものには、SPEC（Standard Performance Evaluation Corporation）という団体のベンチマークがあります。そのうち整数の演算の速さを測るのがSPECint、浮動小数点数の演算の速さを測るのがSPECfpです。int は integer（整数）、fp は floating point（浮動小数点）の略です。
基本情報の範囲ここまで
一度測って終わりにしないことも大切です。システムが動いているあいだ、レスポンスタイムやCPU・ディスクの使われ具合を継続して測り、記録して、異常や性能の低下に早く気づけるようにすることをモニタリングといいます。ミナトが17時にストップウォッチで測ったのは、手作業のモニタリングだったともいえます。仕組みとして毎日記録していれば、遅くなり始めた時期にもっと早く気づけたはずです。
2-4キャパシティプランニング
業者への返事を書く前に、店長がもう一つ心配を口にしました。「去年のクリスマスの予約は800件だった。今年は通販も始めたから、1,200件くらいになるかもしれない。今のうちに足りるようにしておかないと、また同じことになるよね」
店長の心配は、「いま足りるか」ではなく「1年後に足りるか」でした。システムに必要な処理能力は、利用する人や処理の量が増えれば増えていきます。だから、あらかじめ将来の量を見込んで、それに見合う機器を用意しておく必要があります。
ここから基本情報！将来の量を見積もる
将来の業務量や利用の状況を予測し、それをさばくのに必要な処理能力や資源を計画することをキャパシティプランニングといいます。出発点は、システムにかかっている負荷、つまり処理や通信のために実際にかかっている仕事の量を知ることです。負荷は、CPU使用率、1分あたりの注文の件数、ネットワークを流れるデータの量などで表します。負荷が処理能力に近づくほど、待ちが増えてレスポンスタイムが長くなります。
負荷の見込みが立ったら、それに見合う機器の規模や構成（CPUの速さ、メモリやディスクの量、台数）を見積もります。この作業をサイジングといいます。こむぎ堂の数字で考えてみましょう。去年の12月23日の17時台、いちばん混んだ1分には40件の注文が来ていました。予約の総数が800件から1,200件へ1.5倍になるなら、いちばん混む1分も40件×1.5＝60件と見込めます。いまのディスクは1分に80件まで書き込めるので計算の上では足りますが、余裕は4分の1（20件）ほどしかありません。そこで、最も混む時間でも処理能力の半分ほどで済むように、1分に120件を書き込める構成を目標にする、と決められます。
基本情報の範囲ここまで
見積もりの2つの案は、どちらも処理能力を増やす案でした。ただ、増やし方が違います。速いディスクを足す案は、いまの1台のサーバを強くする増やし方です。サーバを増やす案は、同じようなサーバを並べて仕事を分け合う増やし方です。利用者や処理の量が増えたときに、こうして性能や規模を広げていける度合いをスケーラビリティ（拡張性）といいます。スケーラビリティが高いシステムは、店が大きくなっても、作り直さずに能力を足していけます。
ここから基本情報！広げ方と準備
能力の広げ方には名前があります。サーバの台数は変えず、CPUやメモリ、ディスクを強いものにして1台の性能を上げるのがスケールアップです。サーバの台数を増やして、全体の処理能力を上げるのがスケールアウトです。速いディスクを足す案はスケールアップ、サーバを増やす案はスケールアウトにあたります。スケールアップは仕組みを変えずに済む反面、1台で載せられる部品には上限があり、その1台が止まれば全部が止まります。スケールアウトは台数を足し続けられ、1台が止まっても残りが動けますが、仕事を振り分ける仕組みが要ります。
見込んだ量に合わせて、サーバやディスク、ネットワークなどの資源を前もって用意し、使える状態に割り当てておくことをプロビジョニングといいます。クラウドでは、負荷が増えたら自動でサーバを足し、減ったら外す、という形のプロビジョニングもできます。
そして、計画を立てて用意したら終わり、ではありません。サービスを運用するあいだ、資源の使われ具合を見守り、将来の需要を予測して、容量や処理能力が足りなくならないよう（また余りすぎないよう）調整し続ける活動を容量・能力管理といいます。ITサービスマネジメントの活動の一つで、ITILではキャパシティ管理と呼ばれます。
基本情報の範囲ここまで
2-5稼働率
2通の見積もりをよく読むと、どちらにも小さな字で数字が書いてありました。速いディスクを足す案には「稼働率 約97％」、サーバを増やす案には「稼働率 約99％」。店長は「2％しか違わないなら、安いほうでいいんじゃない」と言います。ミナトは、その2％が何時間にあたるのかを相棒と計算してみることにしました。
システムのよしあしは、速さだけでは決まりません。システムを評価する項目として、Reliability（信頼性：故障せずに動き続けること）、Availability（可用性：使いたいときに使えること）、Serviceability（保守性：故障しても早く直せること）、Integrity（完全性：データが壊れたり食い違ったりしないこと）、Security（安全性：不正に使われないこと）の五つがよく使われます。頭文字をとってRASISと呼びます。
この中で、見積もりの数字が表していたのは二つめです。システムが必要なときに正しく使える状態にある度合いをアベイラビリティ（可用性）といい、それを数字にしたのが稼働率です。稼働率は、全体の時間のうち、システムが正常に動いていた時間の割合です。
稼働率は、二つの平均から計算できます。故障して直ってから、次に故障するまでの、正常に動いていた時間の平均をMTBF（Mean Time Between Failures：平均故障間動作時間）といいます。故障してから直るまでにかかった時間の平均をMTTR（Mean Time To Repair：平均修復時間）といいます。システムは「動く（MTBF）→止まって直す（MTTR）→動く」をくり返すので、稼働率は次の式で求められます。
稼働率 ＝ MTBF ÷（MTBF ＋ MTTR）
たとえば、予約システムが平均990時間動くごとに1回故障し、直すのに平均10時間かかるなら、稼働率は 990 ÷（990＋10）＝ 0.99、つまり99％です。稼働率を上げるには、MTBFを長くする（故障しにくくする）か、MTTRを短くする（早く直せるようにする）かのどちらかです。予備のディスクを店に置いておけば、取り寄せを待たずに交換でき、MTTRが縮みます。
見積もりの2％の差を、時間に直してみましょう。予約システムを使う時間が1年に3,000時間だとすると、稼働率97％の案では3％の約90時間、99％の案では1％の約30時間、止まっている計算になります。1年に60時間の差です。クリスマス前の夕方にその一部が重なれば、店長の言う「2％しか」では済みません。
もう一つ、どれくらいの頻度で故障するかを表すのが故障率です。決まった時間のあいだに故障が起きる割合で、故障が一定の割合で起きるとみなせる場合には、1 ÷ MTBF で求めます。MTBFが990時間なら、故障率は1時間あたり約0.001回、1,000時間に1回ほどです。
ここから基本情報！組み合わせたときの稼働率
システムは、いくつもの装置をつないでできています。つなぎ方によって、全体の稼働率の計算が変わります。
どれか1つでも故障すると全体が止まるつなぎ方を直列（直列システム）といいます。全部が動いているときだけ全体が動くので、全体の稼働率は各装置の稼働率の積です。稼働率0.9の装置を2つ直列につなぐと、0.9 × 0.9 ＝ 0.81 で、1つのときより下がります。
すべてが故障しない限り全体が動き続けるつなぎ方を並列（並列システム）といいます。全体が止まるのは2つとも止まったときだけなので、「両方が止まっている確率」を1から引きます。稼働率0.9の装置を2つ並列にすると、1 −（1 − 0.9）×（1 − 0.9）＝ 1 − 0.01 ＝ 0.99 で、1つのときより上がります。
見積もりの数字も、この計算から出ていました。予約システムは、画面を返すサーバ（稼働率0.98）と、データを保存するサーバ（稼働率0.99）の直列です。速いディスクを足す案は、この形のままなので、0.98 × 0.99 ＝ 0.9702、約97％です。サーバを増やす案は、画面を返すサーバを2台の並列にします。その部分が 1 −（1 − 0.98）×（1 − 0.98）＝ 0.9996 になり、全体は 0.9996 × 0.99 ≒ 0.9896、約99％です。保存するサーバは1台のままなので、ここが次に稼働率を上げるときの候補になります。
基本情報の範囲ここまで
2-6故障と保全
交換に来た業者が、外したディスクのラベルを見せてくれました。製造は5年前。予約システムを作ったときに入れた4台は、同じ日に同じ箱から出したものだそうです。「残りの3台も、同じだけ使い込んでいますからね」。業者の一言に、ミナトは嫌な予感がしました。
機械の故障の起こりやすさは、使い始めてからの時間で変わります。使い始めてすぐは、作ったときの不良が表に出て壊れやすく、しばらくすると落ち着き、何年も使ううちに部品がすり減って、また壊れやすくなります。こむぎ堂のディスクは、ちょうど最後の時期に入りかけていたのかもしれません。
ここから基本情報！故障率の変わり方
横軸に使用した時間、縦軸に故障率をとってグラフにすると、両端が高く真ん中が低い、浴槽のような形になります。これをバスタブ曲線といいます。曲線は3つの期間に分かれます。
- 使い始めの、製造時の欠陥などで故障率が高く、時間とともに下がっていく初期故障期間
- 故障率が低くほぼ一定で、故障が偶然に起きる偶発故障期間
- 部品の劣化や摩耗で、故障率がふたたび上がっていく摩耗故障期間
初期故障期間の故障は、出荷前に動かして試すことで減らせます。偶発故障期間は、故障率が一定とみなせる期間なので、前の節の故障率の計算（1 ÷ MTBF）が当てはまるのはこの期間です。摩耗故障期間に入った装置は、故障する前に取り替えるのが基本になります。同じ時期に入れた同じ型のディスクが続けて故障しやすいのは、そろって摩耗故障期間に入るからです。
基本情報の範囲ここまで
故障してから直すやり方のほかに、故障する前に点検や交換をして故障を防ぐやり方があります。後者を予防保全と呼びます。予防保全をいつ行うかを決める基準には、いくつかの考え方があります。
ここから基本情報！予防保全の時期の決め方
あらかじめ決めた時間の計画に従って、装置の状態にかかわらず点検や部品の交換を行うのが時間計画保全です。時間計画保全は、基準にする時間で二つに分かれます。「ディスクは4年ごとに全部取り替える」のように、決めた時間の間隔で行うのが定期保全です。これに対し、暦の上の日付ではなく、装置が実際に動いた累積の時間が決めた値に達したときに行うものを経時保全といいます。「動いた時間の合計が3万時間に達したら取り替える」という決め方です。
これに対し、温度や振動、読み書きのエラーの回数などを継続して測り、劣化の兆しが見えた時点で保全を行うのが状態監視保全です。多くのディスクは、自分の読み書きの不調を記録する機能を持っています。その記録を定期的に確かめて、エラーが増え始めたディスクから取り替えれば、まだ使えるものを捨てずに済みます。
基本情報の範囲ここまで
2-7経済性
最後に残ったのは、お金の話でした。店長は見積もりの「導入費用」の欄だけを指でなぞって、「ディスクを足す案は30万円、サーバを増やす案は50万円。20万円も違うね」と言います。ミナトは見積もりの2枚目をめくりました。そこには、毎年かかる費用が別に書いてありました。
システムにかかる費用は、払う時期で二つに分けられます。機器の購入や組み立ての作業など、システムを導入するときに一度だけかかる費用を初期コスト（イニシャルコスト）といいます。これに対し、導入したあと、システムを動かし続けるために毎年かかり続ける費用を運用コスト（ランニングコスト）といいます。保守の契約料、電気代、クラウドの利用料、トラブルに対応する人の手間などが運用コストに入ります。
店長が見ていたのは、初期コストだけでした。導入から運用・保守、使い終わって処分するまでにかかる費用をすべて足したものをTCO（Total Cost of Ownership：総所有費用）といいます。初期コストが安くても、運用コストが高ければ、長く使ううちに逆転することがあります。2つの案を、5年間のTCOで並べると次のようになります。
| 費用 | 速いディスクを足す案 | サーバを増やす案 |
|---|---|---|
| 初期コスト | 30万円 | 50万円 |
| 運用コスト（1年あたり） | 8万円 | 10万円 |
| 運用コスト（5年分） | 40万円 | 50万円 |
| 5年間のTCO | 70万円 | 100万円 |
| 稼働率（1年に止まる時間） | 約97％（約90時間） | 約99％（約30時間） |
TCOで見ても、サーバを増やす案のほうが30万円高くなります。その30万円で、1年に約60時間、5年で約300時間ぶん止まりにくくなる、というのがこの比較の読み方です。どちらを選ぶかは数字だけでは決まりませんが、何と何を引き換えにするのかは、これではっきりしました。
ここから基本情報！見積もりに載らない費用
費用は、どこに結び付けられるかでも分けられます。特定のシステムや製品のためにかかったと、はっきり分けて計算できる費用を直接コストといいます。機器の代金、ソフトウェアの使用料、保守の契約料のように、請求書に載る費用です。見積もりの表に並んでいたのは、すべて直接コストでした。
これに対し、ほかのものと共通にかかっていたり、目に見えにくかったりして、そのシステムに直接は結び付けにくい費用を間接コストといいます。ITの費用でいえば、使う人が操作を覚えるのにかける時間、トラブルのたびに店の仕事が止まる時間、システムが止まっているあいだの売り逃しなどです。
こむぎ堂の売り逃しを、1時間止まるごとに2,000円と見積もってみます。1年に止まる時間は約90時間と約30時間なので、売り逃しは1年に約18万円と約6万円、5年では約90万円と約30万円です。これを直接コストのTCOに足すと、ディスクを足す案は約160万円、サーバを増やす案は約130万円になり、順番が入れ替わります。
基本情報の範囲ここまで
次の日の朝、店長は2枚の見積もりの横に、ミナトが作った表を置きました。しばらく眺めたあと、サーバを増やす案に丸を付けます。「30万円で、クリスマス前の夕方に止まる心配を買うと思えば安いよ」。それから手帳を開いて、2月の定休日に「残りのディスク3台を交換」と書き込みました。
赤いランプが一つ点いた土曜日から、ミナトが確かめた物差しは三つでした。RAIDがディスク1台の故障を隠していたこと。夕方の遅さは、ディスクという一か所のボトルネックから来ていたこと。そして、2通の見積もりの違いは、速さよりも、1年に何時間止まるかと、5年でいくら払うかにあったこと。店長が丸を付けたのは、その三つを同じ表に並べたあとでした。
ただ、表には書けなかったことが一つ残っています。サーバを2台にすれば、画面を返す部分は止まりにくくなります。でも、予約のデータそのものは、まだ店の奥の1つの箱の中にしかありません。その箱ごと水をかぶったら、どうなるのでしょうか。