2017年10月6日金曜日

【読んでおきたい】HCI導入を上申する時に書きたい2つのポイント

ガートナー社から発表されたハイプサイクル※にもある通り、

日本でも盛り上がりの様相を見せているWebスケールIT

2017/10/03ガートナー ジャパン株式会社「日本におけるテクノロジのハイプ・サイクル:2017年」https://www.gartner.co.jp/press/html/pr20171003-01.html

その一つの製品形態であるハイパーコンバージド(以下HCI)は、

国内でも少しずつ盛り上がりを見せています。


従来の3Tierと呼ばれるサーバやストレージを調達して構成される

システム構成から脱却して構成を置き換える訳ですが、

そんな時に情報システム部の担当者必ずぶつかるのが、

「どう上申するか?」かと思います。

HCI3Tierシステムを比較し、

当然良いものであることを客観的に示さなければ、

簡単には調達できませんよね。

今回は、HCI3Tier構成を比較しつつ、

HCI導入の上申時に書きたい、

ポイントを2つ紹介していきます。

(クラウドとの比較はボリューム多くなるので別記事で)


特に技術的な観点よりは決裁者(経営者)の視点で

まとめみたつもりです。

完全な網羅性までは追求していませんので、

一つの参考となる考え方としてお読みください。

なお、本分析は一個人の見解ですので、

正確性を保証するものではないことを

予め明記しておきます。


1.社内システムの将来的な拡大への対応

買収・合併、ビジネス拡大に伴う社員の増加など、

ビジネス環境が変化した際に、

社内システムも必ず変化を余儀なくされます。

それは多くのケースで、

必要なリソース量の「増加」を招きます。

本当に増えるかどうかは誰にも予測はできないことですが、

いざ増えた時にどう対応するか、

これは情報システム部門にとって重要な命題です。

従来の3Tier構成においてどうしていたかと言えば、

xx%程度増えるかもしれないので、

バッファを持って導入しよう、

ということが行われるわけです。

至って当たり前のことですが、

これも「これ以上は増えないだろう」という前提を作り、

導入しているので、将来的なリスクを許容して選択しています。

或いは予算的な都合も鑑みて、

ギリギリを攻めて導入し、「増えない前提」という

導入を行うケースもあります。

この結果どうなるかと言えば、

1、2年後、経営側から、新しいシステムを導入してみろ、

利用者を拡大できるようにせよ、

といった指示から前提が崩れます。

結果としてリソース(容量・性能)が不足する為、

新しい基盤をもう1セット導入して運用負荷を倍にするか、

お買い物をし直しさせてくれ、

という稟議を経営者にしにいくわけです。

経営者側も自分が要求している以上NO

言いづらいですが、

なぜ買わなければいけないのかをしっかり説明を要求し、

情報システム担当者は材料集めに苦心するシナリオです。

ここで救世主はHCIです。

HCIWebスケールと言われたりするように、

拡張する前提で作られています。

その為、あとから増やしたいニーズを容易に満たします。

つまり、「足りなければ足せばいい」

「欲しいものを欲しい分だけ」というお買い物の

仕方ができる訳です。

日本企業は欧米に比べると

(個人的印象ですが)

まとめて多くを調達せず、必要な分だけ買って、

やりくりしていくスタイルだと思います。

まさに日本的な調達スタイルに合っているのが、

HCIでの基盤づくりです。

また、情報システム担当者を個人的に救う観点で見ると、

何かしら考慮漏れや手違いがあって不足する事態になったとしても、

足すというアプローチで、

構成の見直しなど大惨事になることも回避できる点も魅力かと思います。


前置きが長くなりましたが、

これをまとめた文案としては

「将来的なビジネス変化やITリソースの需要増に対して、

 社内のITインフラに柔軟性を持たせ、

 経営方針に沿ったIT活用を後押しする為、

 HCIを採用します。」

という様な文言になるのではと思います。

クラウドを取り入れたいけど、

セキュリティ的にNGとなっている会社であれば、

「自社の社内システムにクラウドのような拡張性を導入できます」

と言ってみるのはいかがでしょうか。

ここまででおなか一杯感はありますが、

次にいきます。

2.5年毎のリプレースプロジェクトからの解放

一般的にハードウェアの保守は5年までと設定されていることが多いです。

(例外として7など調整するケースはあります)

その為、5年毎に機器交換の1大プロジェクトが発生します。

RFIを出して、RFPを出して、

ベンダーの比較検討、経営会議での承認、

専任担当をつけて何か月もかけての更改プロジェクト遂行、

リスクをはらんだシステムの切替日、

そしてトラブルによる切り戻し・・・

考えただけでも胃の痛くなる大仕事です。

従来の3Tier構成では、

必ずこの大仕事が待っていました。

システムが仮想化したことで、

幾分この作業は和らいだ点がありますが、

異なるアーキテクチャ上に移すリスクは必ず残ります。

HCIに切り替えることで、

この考え方から脱却する手段があります。

必要な分だけ足せるメリットを生かし、

基盤の「新陳代謝」を行う方法です。

考え方としては、

従来の基盤に新しいハードウェアを足し、

仮想マシンをライブマイグレーションします。

古い機械の上から仮想マシンをすべて移動させた上で、

リソースから古い機械を外す。

まさに「新陳代謝」です。

このやり方では、同じアーキテクチャを元にして、

ライブマイグレーションだけを行うという

非常に簡単なお引越しで基盤更改ができるメリットがあります。

これを上手く活用することで、

切替の大規模プロジェクトをしなくとも、

普段のリソース拡張と同じ調達のレベルで、

機器更改が完了してしまいます。

これを経営者目線で見ると、

「5年毎の機器更改における人件費の大幅圧縮と

 機器切替における業務停止リスクを最小化する為に、

 HCIでの基盤導入を行います」

ということになるでしょうか。

この「お祭り」を避ける人件費どのくらい圧縮できるか?

という話で言えば、

1日当たりの情報システム担当者の人件費を

仮に6万円と設定すると例えばこんなイメージです。

(割と控えめな現実的な試算をしたつもりです)

RFP作成:6万円×(作成10日+レビュー2日+修正8日)=120万円

ベンダー選定:6万円×(説明2日+QA3日+プレゼン対応2日

           +比較表作成5日+稟議資料作成8日

           +社内説明4日+指摘修正8日

           +事務手続き2日)=204万円

PJ管理:6万円×(定例会0.25日×4回×4か月+レビュー10回×0.25

          +社内での進捗報告&資料作成0.5日×4回×4か月

          +事務手続き1日×4か月+課題管理と回答1日×4回×4か月

          +リリースの社内判定3日)=321万円

このくらいの大ごとをしています。

HCI化すると、今後リソース拡張等の入れ替えだけなので、

PJ管理程度で、計算を割愛しますが、

1か月程度のPJで済むので、費用も4分の1くらいと

見てもよいでしょう。

またこれだけの人件費をかける一方で、

人的リソースがこの「価値を生まない」PJ

確保されてしまうリスクもあります。

本来経営者としては、情報システム部門に

経営を引っ張ていくようなIT活用を検討することを

期待していると思います。

人手不足が深刻化する中で、

その人的リソースを有効活用し、

情報システム部門の役割をより経営に貢献する

変化を促す為にも、

この取り組みは重要です、

と上申してもいいかもしれませんね。



少々長くなってしまったので、

2つだけにしました。

他にもHCI化することで、

3Tierで複数メーカーの機器を使っていた所から、

1社にサポートを集約できること、

採用する会社によっては、

サポート品質を向上させられること、

フラッシュも活用されることで、

インフラの性能向上=システムの性能向上、

運用の簡素化による運用体制の見直し、

技術者育成の簡素化、

などなどメリットはいっぱいです。

折角なので、社内インフラを更改する時は、

HCIを検討してみてください。


今回は以上です。