AWSへの社内サーバー移行の事例

サーバーワークスに依頼している業務の概要を教えてください。

今回のAWS移行については、大きくは「方針策定を除く『実作業の部分』は、原則としてサーバーワークスにアウトソースする」という形にしています。依頼している業務の内容は次のとおりです。

【設計】
■ 移行前の全サーバーの状況をアセスメント
■ アセスメント状況を踏まえて、移行後のAWS利用ガイドライン、AWS最適構成を策定
■ 設計内容は「最初に決めて終わり」というのではなく、それ以後の「アデランス側のIT施策の変更・改善」「外部環境の変化」に応じて、協議の上、柔軟に修正

【構築】
■ 既存サーバー基盤のAWS移行作業
■ アプリケーションベンダー、既存SI会社とも必要に応じて連携

【運用】
■ 死活監視
■ リソース活用の最適化
■ （※【最適化コンセプト】は次のとおり）：
-「必要なサーバー資源を、必要なときに、必要なだけ確保」
-「無駄をつくらない。足りなくなることもない。常にちょうどよく」
-「新しいことがやりたいときに、すぐに簡単にできる」

【その他】
AWS利用料金の支払い代行
（AWSはサーバーワークスを代理店として購入するという形態）

アデランスが、サーバー基盤をクラウド化することに決めた経緯を教えてください。

（廣瀬氏）：私がアデランスに入社したのは6年前、2010年ですが、そのとき社内システムは、おおむね「1物理サーバー1システム」の形で、データセンターで運用されていました。

それらサーバーの運用管理は大手SI企業に委託していました。しかし、わずかな変更をするだけでも、大がかりな契約書や見積書が必要になり、また都度都度 「ここまではやりますが、そこから先はやりません」という形の業務定義も発生しました。変更作業はわずかでも、そこに至るまでの手続きは膨大でした。

この問題を解決するべく、2012年に社内サーバーのほぼ全てを仮想化しました。基盤を仮想化すれば、サーバーの新設、変更、削除がスピーディーになりま す。これにより、従来あった課題、つまり「万事につけ作業が重い、遅い、小回りが効かない、時間と費用が膨大にかかる」という状況を解決できると期待したのです。

しかし、残念ながらそうはなりませんでした。

なぜ問題が解決しなかったのでしょうか。

もちろんサーバーを仮想化すれば、諸々のことは、ある程度スピーディーになります。

しかし、いくら仮想化したといっても、結局はその背後に物理サーバーがあります。つまり仮想サーバーの新設や変更も、その物理環境のリソース制限からは逃 れられません。新しいシステムを導入しようとしても、結局は資源不足の問題が出てくるわけで、決して自由にはなれません。

また仮想化したとしても、ハードウエア、ソフトウエアが弊社が所有する「資産」であることに変わりはありません。所有しているということは、それを維持・管理する業務が発生する。具体的には、SI企業からは「ハードディスクが壊れました。どうしましょう」「メモリが足りなくなりました。どうしましょう」と具申が来るわけです。

結局、その問題を解決するべくSI企業にサーバー新設、ディスク交換、メモリ増設を依頼すれば、結局、以前と同じような「作業の重さ、遅さ、高さ」の問題が出てきます。

サーバーを仮想化したことで問題は「ある程度は」解決しました。しかし、それは「ある程度」に過ぎず、私の考える「サーバー基盤の理想型」とはほど遠いものでした。

「サーバー基盤の理想型」とは具体的には。

以下、「あくまで『理想型』であり、今でも実現できているわけではない」ということを前提にお話しします。

私はサーバー基盤に限らず、すべてのITインフラは、電気、ガス、水道など一般インフラと同じく、『外部に完全にアウトソース』できるのがいちばん良いと考えています。

私たちは「事業会社のIT部門」なので、「事業を発展させるようなIT施策を企画・立案・実行すること」が本業です。サーバー基盤などインフラ構築・運用は「重要ではあるが副次的な作業」となります。

これは工場など製造部門の本業が「事業を発展させるべく、良い製品を作ること」であり、「電気、ガス、水道などは、外部のインフラ企業から購入している（アウトソースしている）」というのと同じ構造の話です（※）。

ITインフラは電気やガスに比べて歴史が浅いので、「社内で抱え込む部分」と「アウトソースする部分」の境界があいまいです。しかしそれがインフラである以上、やはり外部にアウトソースするのが本来的な姿だと思います。

「事業会社のIT部門はITインフラを構築・維持することを仕事と思ってはならない、それ以外で勝負しなければならない」ということです。

この「情報インフラのアウトソース」は、「インフラのTCOをゼロ化する」と言い換えることも可能です。

「インフラのTCOのゼロ化」とは具体的には。

TCOとはTotal Cost of Ownershipの略で、直訳すると「何かを所有すること(ownership)により生じる全コスト」のことです。これを減らすべく「TCO削減」の 掛け声のもとに、様々な施策や取り組みがなされています。

ところで電気やガスや水道では、利用者はそのためのインフラを一切所有していません（※）。所有していないのでTCOは発生しない。つまりゼロです。同様 に情報インフラも、それを所有することをやめてTCOをゼロにするのが良いと考えるわけです。

では現状ある手段の中で、この理想型に最も近いものは何か、それはやはりAWSのような「サーバーのクラウド化」となります。

この考えに至った2014年から、「社内サーバーすべてのクラウド化」について、本格的な検討を開始しました。

まず最初に「どのクラウドサービスが良いか」を見定めたいと考え、AWSをはじめとする各種の「サーバー基盤クラウドサービス」を比較検討しました。
※ 「工場の自家発電」などはここでは考えないことにします。

検討の結果、AWSを選んだ理由を教えてください。

検討を開始する前から「サーバー基盤クラウドの中ではAWSが知名度もシェアもNo.1らしい」とは聞いていました。しかし先入観を持つのは良くないと考え、まずは各サービスを冷静に比較検討しました。
といいながらも割合に早い段階で「AWSが良い」という結論に至ってしまいました。実績、機能、将来性を考えると「やっぱりAWS」だなと。
もちろんAWS以外にも良いクラウドはあります。しかし、それらはどれも「大手IT企業が運営するクラウド」というのが難点でした。

今回のサーバー基盤クラウド化には、そもそも「特定企業へのベンダーロックインを解消したい（身軽になりたい）」という意図がありました。それを考える と、アマゾンという「本業がITではない会社」が提供するAWSが、もっとも「ベンダーロックインが避けられそう」に思われました。

次に「AWS構築をどのクラウドパートナー企業に依頼するか」の検討を開始しました。

クラウドパートナーはどのように選定したのでしょうか。

クラウドパートナーの選定は、「リストアップ」、「RFPによる一次選定」、「最終選定」の三段階で行いました。
今回の「会社全体のサーバー基盤の移行」は、「重要かつ、後戻りが難しい」という性質のプロジェクトだったので、どの選定段階でも「先入観を持たない」「安易に決めない」という姿勢で真剣に比較検討しました。

第一段階「リストアップ」

第一段階、「リストアップ」はどう行ったのでしょうか。

まずアマゾンに連絡して「良いクラウドパートナー企業を教えてほしい」と質問しました。その他、ITコンサルティング会社に費用を払って業界状況の調査、候補企業のリストアップを依頼しました。
まず30社が列挙されてきました。その候補に対し、「既存取引先は残す」「AWSが推奨してくる企業は残す」「有名なところ、おおむね評判が良いところは残す」という方針で30社を8社に絞り込みました。

第二段階「RFP」

第二段階「RFPによる一次選定」はどのように？

まずは候補企業にRFPを出して提案を求めました。RFPの骨子は二つあって、一つは「3年計画で全社のサーバー基盤を移行したい」ということ、もう一つ は「新CRMシステムを3カ月後（2015年9月）にAWSで稼働させたい」ということでした。
RFPを出したのが2015年5月末、回答期限は6月10日、そして新CRMの稼働開始が9月ですから、これはクラウド企業にとっては「タイトなスケジュールの要請」だったといえます。
このRFPに対しては、「実質上、断ってきた会社」、つまり「ウチはその仕事はできません（やりたくありません）」という趣旨の回答をしてきた企業が多くありました。
これはある意味、思惑通りの展開でした。

「RFP回答を断ってきた企業が多かったことが思惑どおり」とは具体的には。

今回、サーバー基盤をクラウド化するのは、従来あった「少し変更するだけでも、作業が重く、遅く、そして費用は高い」という問題を解決するためでした。
これを裏返していえば、新たに起用するクラウドパートナーには「軽やかな対応、迅速な作業、合理的な費用」という三要素を求めることになります。
クラウド企業の選定を始めた頃、ちょうど目の前に「9月稼働開始が現場から要望されているCRMシステム」というタイトな納期の案件がありました。なら ば、これをRFPに盛り込んで、それに対する反応を見れば、良いクラウド企業を見つけるためのリトマス試験紙になる、そう考えたわけです。
一次コンペを終えて、サーバーワークスを含む数社が最終候補に残りました。

第三段階 「最終選定」

最終選定はどのように行ったのでしょうか。

最終選定は、候補数社に来社していただき、それぞれ2時間のプレゼンテーションをしていただきました。
この最終選定を行った際しての、主な比較基準、求めた要件は次のとおりです。

要件1．「機能の充足度、納期」

こちらが求める内容、納期に対し、提案内容が必要十分であるかどうか、フィットしているかどうか、という話です。ただし、この点については候補3社とも 「こういうことはできますか？」というRFPに対し、「できます」と回答した上で最終候補に残っているわけです。 3社ともこの要件は満たしていました。

要件2．「スピード感」

今回のプロジェクトは、「脱・重厚長大」が基本コンセプトなので、提案内容、形式がそれに見合っていることを求めました。つまり、身軽、迅速、柔軟、自由、低価格などのキーワードを予感させて欲しかったわけです。
候補数社の中で、隅々まで緻密に設計したキメ細かいサービスを、従来型の重厚長大な形式で提案してきた企業もありました（その分、価格は非常に高価でし た）。そうした提案が有り難い場合もあるのですが、今回の「サーバー基盤クラウド化プロジェクト」では、 基本方針にそぐわないので、その提案は見送ることになりました。

要件3．「柔軟性」

今回のプロジェクトは「3年計画」なので、途中で「予期せぬ突発事態」「外部環境の変化」による内容変更、方針変更が生じることは十分にありえます。 そんな場合でも、「契約内容ではここまでなので、これ以上は別途見積もりです」と対応するのではなく、合理的な範囲でやりくりして何とかするという「柔軟性」を発揮してくれる企業が望ましいと考えました。
この点については候補数社の中で、「完全パッケージ方式の極めて明瞭なサービス内容と価格体系に基づく提案」をしてきたところがありました。もちろんハッキリ、明朗明確であるのは素晴らしいことです。しかし今回のような長期計画では、若干の「そぐわなさ」を感じました。

要件4．「向き・不向き」

リストアップ段階で、ITコンサル会社から言われたのは、「クラウド企業の場合、大きくは『ゲームに強い会社』と『企業情報システムに強い会社』に分かれます。 両者は社風や仕事の進め方がハッキリ違います」ということでした。今回のプロジェクトでは、やはり後者の「企業情報システムに強い会社」が良いと思われました。
これら4要件を基準に比較検討した結果、サーバーワークスが弊社の求める要件を最もよく満たしていたので、同社を起用することに決定しました。
サーバーワークスは提案内容や組織体制が、重厚長大すぎず、かつパッケージ的になりすぎず、AWS化プロジェクトにふさわしい軽快さと柔軟性を備えており、バランスの良さを感じさせた点が、大きな選定理由となりました。
その後、2015年6月から3年計画の第一フェーズを開始しました。これを無事に終えた2016年4月現在は「第二フェースが進行中」という状況です。
これまでのところサーバーワークスは、弊社が求めたとおりの「軽やかさ、迅速さ、柔軟性」を期待通り発揮してくれています。第二フェーズ、第三フェーズも確実に計画を遂行できると確信しています。

現在、サーバー基盤のAWS化を検討している企業に向けて「先輩ユーザーとしてのアドバイス」などあればお聞かせください。

全社のサーバー基盤をクラウド化するとなると、当然、長丁場の作業になります。その前提でクラウドパートナーを選ぶとなると、機能やサービス内容がRFP にフィットしていることは当然として、それ以外の「熱意、相性、向き不向き」などが重要になると考えます。
それら定性的な要素については、プレゼンの機会などを通じて、会って判定する他はないかもしれません。

サーバーワークスへの今後の期待をお聞かせください。

アデランスの情報システム部門では、今後とも、ユーザー向けシステムの企画・立案・構築設計という「事業会社のIT部門の本来業務」に注力するべく、インフラ部分の構築・運用については、クラウド化、アウトソースを推進していきたいと考えています。
サーバーワークスには、そうした私たちの取り組みを、優れた技術、提案、運用サポートの継続提供を通じて後方支援していただくことを希望します。今後ともよろしくお願いします。