先輩～、全部まるっとクラウド化！じゃ、だめですかね～？
ドーン！と大きいサーバを入れてプライベートクラウドー！とか。あ、いっそパブリッククラウドにボーン！と全データ入れちゃえば、サーバのお守りもしなくて済むし…

アンタ、まさかそれ本気で言ってないでしょうね…？
システムを見直す時、どれだけたくさん検討項目があると思ってるの？

ひぇーーー！こんなに検討項目があるなんて…。。。

でもこのままの状態じゃ困るんです～！
もしまたサーバが増えたりしたらもう管理しきれないですよ～！！

うむ、このままでは彼の工数やらサーバの保守費用やらで、コストもかさむ一方でしてね。本当は災害対策にも手をつけたいんですが、人員的にも費用的にもそれどころじゃない。このような煩雑に使われている"もったいない"状況をなんとかしないと…

もちろん、システムの見直しは必要です。
でも、はじめからクラウドありきではなく、御社の業務にぴったりあったICTインフラを見極めるところからはじめまてみませんか？
言うなれば「ICTインフラの"ちょうどいい"化」を目指しましょう！

なるほど"ちょうどいい"か…。
いい響きじゃないか！

どうやったら"ちょうどいい"ICTインフラを作ることができるんですか？

そうですね…、それではお客様には特別にポイントをお教えしますね！
この『ICTインフラの"ちょうどいい"化』は、2つのステップで行います！

ステップ①ICTインフラをサービスレベルで仕分けする
全ての業務とサーバを洗い出し、洗い出した業務に求められるサービスレベルを決める

ステップ②最適なICTインフラを選定する
物理環境／仮想化によるサーバ集約／クラウド化／サービス利用…などのICTインフラを選定していく

まずは、ステップ①「ICTインフラをサービスレベルで仕分けする」方法をご紹介しますね。
情くん、「サービスレベル」って、具体的にはどんなことだと思う？

うーんと～…、社内システムの運用時間とか、ATMの営業時間とか、ですかね？

あとバックアップのスケジュールなんかも「サービスレベル」ですよね。
毎日とるのか、1週間に1回くらいなのかとか…

そのとおりです！
「サービスレベル」とは、業務要件のうち、ICTシステムに対して求められる内容のことです。

なるほど～。で、この「サービスレベル」をどう使うんですか？

では、サービスレベルの中でも特に重要なもののひとつ、「サービス停止許容時間」と、御社の基幹系システムを例にとって考えてみましょう。

御社の基幹系システムは「①販売管理」、「②会計」、「③人事給与」、「④勤怠管理」の4つの業務システムで構成されています。
お客様、各業務システムの「サービス停止許容時間」はどれくらいでしょうか？「サービス停止許容時間」とは、「トラブル時に業務が停止しても許される時間」を意味します。

そうですね…。
「①販売管理」や「②会計」は、もしストップしたらすぐにお客様とのお取引に支障が出ますから、できる限り早く復旧したいですね。
「③人事給与」や「④勤怠管理」は社内のことですから、最悪1日くらい停止してもなんとかなるんじゃないでしょうか。

ありがとうございます！
さて情くん、この結果から何が分かるかしら？

えーと、『もしサービスが停止したらすぐに復旧しないといけない「①販売管理」「②会計」』と、『1日くらいは大丈夫な「③人事給与」「④勤怠管理」』の2つに分かれたってことですよね…。
前者は高性能＆高可用な環境を整える必要があるけど…。
そっか！業務の性質が異なるから、それに合った性能のサーバを導入すればいいんだ！

なるほど！「基幹系だから」という理由で、ついなんでもかんでも高性能なサーバを導入したりしがちですけど、必ずしもそうではないというわけですね。

現行システムは①～④まで全て同じPCサーバを使用してるんですが、こうやって見ると"もったいない"使い方をしてたということがよく分かりますね。

そうなんです。
今、例にとった「サービス停止許容時間」は、たくさんあるサービスレベルの中の一例です。実際にはその他のサービスレベルによる仕分けも実施し、その結果を複合的にみて最終的に判断します。
このように、サービスレベルを基準にして選んだICTインフラならば…

ちょうどいい！ってことですね～！！！

ちょ、人のキメ台詞とらないでよっ！

先輩、次のステップ②「区分ごとに最適なインフラを選定する」方法も早く教えてくださいよ～！

ここで登場するのがこの秘密兵器、「ICTインフラ選定のためのフロー図」です！
ステップ①で判明した区分ごとにフローを辿るだけで、最適なICTインフラの種類を判別できちゃうんです。

では御社の『もしサービスが停止したらすぐに復旧しないといけない「①販売管理」「②会計」』でフローを辿ってみましょう！

オーケー、レッツスタートォォ！！！
まず1つ目のポイントは…「仮想化に不向きな要因があるか？」ですね！

仮想化に不向きって、具体的にどういうことなんですか？

例えば、特殊なハードウェアや、Faxなどのプロトコルを使っていると、そもそも仮想化できない場合があるんです。そういう要因がある業務グループは従来型の物理環境が最適という結果になります。御社の会計や販売管理システムではいかがですか？

特にそういう要因はないと思いますね。

了解しました。では次の選定基準に進みますね。
2つ目のポイントは「『必要とするICTリソースが一定でない業務』があるか？」です。
例えば、一時的にウェブサイトを立ち上げたり、特定の月だけ、もしくは月末月初など一時的にデータが増える集計をしたりすることはありますか？

多少の変動はありますが、ウチは年間通して需要が一定な商品を多く扱ってますので、データ量が著しく変わるということはあまりないですね。

なるほどなるほど。
情くん！今の結果をフローに書きこんでみて！

ハイ！えーと、はじめはNo、次もNo…
…できました！結果は…クラウドじゃなくて仮想化によるサーバ集約になりましたよ！！

クラウド化までしなくても、サーバ集約だけでじゅうぶんだったのか…！

そういうことです！つまり御社のシステムにはこれが…

"ちょうどいい"ってことですよ～！！

今回はどうもありがとうございました！
見直し後のシステムの調子はいかがですか？

ハイ！
あれから全ての業務システムを"ちょうどいい"化のノウハウで整理してもらって、以前と比べて業務負荷が格段に減りました！

全体のコストが圧縮できたおかげで、ウチの経営サイドがやりたがっていた災害対策の検討をはじめることになったんですよ。

ハイ、大丈夫です。ありがとうございます！

システム担当者も経営サイドも、みーんなが納得するシステムの見直しができたのも、「"ちょうどいい"化」のおかげです！
本当にありがとうございました！