近年ますます世に浸透しつつある「AWS（Amazon Web Services）」ですが、便利なサービスが次々とリリースされる一方で、その変化の速さに企業が追い付ききれないという一面もあるようです。それは「機能」のみならず「組織」という点でも。

　AWSの導入は従来と異なり、事業部門（非IT部門）主導で始まるケースが多く、セキュリティ管理部門やIT部門との連携など、社内の調整に皆さん試行錯誤されています。

　そこで今回はクラウドを試したい事業部門の担当者向けにAWS導入をスムーズに進める勘所をご紹介してみたいと思います！

▼ ハイライト
1. まずは「独立したシステム」としてスタートする
2. 全社公認化に向けガイドラインを整備する
3. AWSのスピード感を活かした体制を検討する
4. 部門ごとのサービス使用量を把握する（課金管理）

1. まずは「独立したシステム」としてスタートする

　クラウドのメリットといえば、必要なとき必要なだけコンピューター資源を利用できること。「新しい企画を思いついたら即トライ！」と言いたいところですが、かくいうクラウドの理想にはまだまだ道のりが長い、というのが実情のようです。

第一関門は「社内規定」

　組織を運営してくうえで欠かすことのできないルールですが、中でも業務データの取り扱いやシステムの品質を定める基準がオンプレミス（情報システムを企業自身が管理する設備内に導入、設置する運用形態）を前提に作成されており、クラウドでは条件を満たせず二の足を踏んでいる、というお話をよく伺います。

　一方で新しい利用形態を全社公認とするのも一筋縄ではいかないもの。クラウド利用に抵触する規定には何があるのか、ステークホルダーとなる部門はどこなのか、そもそも「何で一部門のウチが、全社ガイドラインを策定しているの！？」。ゴールに至るには多大な時間を要し、出来上がった頃には既に気にかけていた市場は消え失せているやもしれません。

　そうしたお客様の多くがたどり着くのは次のような選択です。

• AWSを会社のシステムとは独立したかたちで構築する
• 一般公開可能な情報のみを取り扱う（機密情報は扱わない）

　実際の適用例としては「Webシステム」が多いかもしれません。コーポレートサイトやキャンペーンサイトなど。特に後者は小規模なサイトのオープン/クローズが繰り返され、負荷変動への柔軟な対応が要求されることから、AWSがはまりやすいといえます。

　ともすれば、場当たり的な回避策のように聞こえるかもしれません。しかしこれが突破口となり、その後全社にクラウド導入が広がっていく例を筆者はたくさん見てきました。まずはあたりさわりのないところから手をつける。企業におけるクラウド活用の第一歩は、柔軟な立ち居振る舞いから始まるように思います。

2. 全社公認化に向けガイドラインを整備する

　「まずはクラウドの試験導入を果たし、気づけば同システムも成長してきた。しかもAWSを使った新しいアイデアも浮かんできている。例えば、既存顧客データを活用した販促企画、商品マスタと連携したECサイト・・・」

　クラウドシステムの運営が順調に進んだ場合、いつか必ず会社のルールと折り合いをつける日が来ます。きっかけは企業によって様々ですが、筆者が担当したケースでは「システム規模」や「社内業務データとの連携」を皮切りに、全社公認化へ着手するお客様がいらっしゃいました。

　ある程度の規模に至ったシステムを一事業部門が運営し続けるのは組織構造として無理がありますし、社内システムとのデータ連携にはIT部門との調整が必須です。社内の関連部門（情報システム部やCSR、法務部など・・）に声掛けするならまさにこのタイミングでしょう。

　とはいえ何から手を付ければよいかと、迷われるお客様も決して少なくありません。

　そこでAWSの場合、まずは以下『エンタープライズ AWS 導入ガイド』のドキュメントに目を通されてみてはいかがでしょうか。

　これは企業がAWSを利用する上での勘所を記したガイドブックです。AWSパートナーである国内SIerの共著によって制作されています。

　つまり企業の情報システム導入で発生する課題をあらかじめ踏まえた内容となっているところがポイント。AWSが国内に普及するに至った背景はもちろん、企業がクラウド導入を検討する際によくあたる争点や、オンプレミスと組み合わせてAWSを利用する場合の構成例について触れており、AWS公認化に向けた必要最低限の取り組み事項をおさえるのに便利です。

　その他、各官公庁や公益法人が発行しているガイドも参考になります。

• クラウドサービス利用のための情報セキュリティマネジメントガイドライン(経産省)
• データセンターの安全・信頼性に係る情報開示指針　第2版(総務省）
• IaaS・PaaSの安全・信頼性に係る情報開示指針(総務省）
• 非機能要求グレード(独立行政方針　情報処理推進機構）
• クラウド情報セキュリティ管理基準(特定非営利活動方針日本セキュリティ監査協会)

3. AWSのスピード感を活かした体制を検討する

　特にAWSを社内システムと連携する場合「IT部門」との体制づくりが重要になってきますが、ここの設計でひとつ重要なポイントがあります。

「AWSのスピード感を活かした体制」を検討する!!

　ひとつの例として、筆者がとある企業の宣伝部のAWS導入を支援したケース（仮にA社とします）をご紹介したいと思います。

　A社では、自社プロダクトの販売促進やプロモーションサイトの運営を同社の宣伝部が広告代理店と共同で行っており、AWSシステムのオペレーションは代理店のパートナーであるWeb制作会社が一手に請け負っていました。そして、AWS公認化（社内システムとの連携）前後で次のように体制が変化しました。

図 2. AWS公認化前後における体制の変化

　さて、ここで重要になってくるのが「宣伝部（代理店、Web制作会社を含む）」と「情報システム部」の役割分担です。

　もしAWSの利用にあたり、宣伝部から情報システム部への申請フローを厳格に管理し過ぎれば、「まずはトライ！」というクラウドの恩恵を受けられなくなってしまいますし、また宣伝部の権限を過剰に制限してしまった場合にも（例えば、サーバーの再起動のために申請が必要になる等）申請作業が煩雑化し、やはりAWSの持ち味を活かし切れないという結果に至ります。

　スピードとセキュリティはトレードオフの関係にあり、つまりは落としどころを見極めるかたちになりますが、ここをうまくやりくりしないと、結果アンダーグラウンドなAWSが残存し、標準化が頓挫する事態になりかねません。

　ここはお互いの業務特性を理解し合い（宣伝部：スピード／情報システム部：サービスの安定提供・セキュリティ確保）＆粘り強く調整いただく他無いのですが、様々なAWS導入を経験してきた筆者としては、例えば以下のような役割分担をお勧めできればと考えています。

　ユーザーやアクセス権といったセキュリティ関連機能の管理、および物理ネットワークトポロジやIPアドレスなどのネットワーク構成管理は、社内システムとの連携の兼ね合いもあるためIT部門に担当いただくのがベストです。一方サーバーの電源ON/OFFやウェブ/アプリケーションサーバーの再起動といった細かな操作は、事業部門および外部パートナーで完結してしまうのが、サービスをスマートに運営する上でのコツといって良いでしょう。

　すべてが理想どおりに進むほどサービス運営は簡単ではありませんが、まずは上記を念頭に検討されてみてはいかがでしょうか！

4. 部門ごとのサービス使用量を把握する（課金管理）

　さて、当水準までAWSを社内に浸透させるだけでも相当タフな作業ですが、この先起こる出来事についても触れておきたいと思います。ここからは事業部門の担当者様というより、全社標準インフラ運営を担当することになったIT部門管理者様向けのトピックです。

　これまで一部門の利用に止まっていたAWSですが、今後は全社からの申請に応じてサーバー資源を割り当ててゆきます。こうした場合に課題となってくるのが費用負担配分の算出方法です。各部署がいつ・どれだけのコンピューターリソースを消費したのか、全社標準インフラを公正に運営していくにはこの根拠を必ず把握しておかなければなりません。

図 3. 部署ごとのAWSの費用配分は、何を根拠に決定すれば良いのか？

　その際まず思いつくのは「アマゾン社からの請求書ベースで処理する」ではないでしょうか？しかし、AWSの請求明細は「インスタンス使用料」や「データ転送料」「データベース利用料」など機能カットでの総額となっており、当然のことながらユーザー企業の内部事情を考慮したつくりにはなっていません。従って部署それぞれの利用料を把握するにはもう一歩工夫が必要になります。

　そこでシステム運用に慣れた管理者ならば当然に思い浮かべるカード「ログを基にサーバーの利用時間から課金する」、これならどうでしょうか？確かにアマゾン社は詳細なシステム稼働ログを提供しており、日々ブラッシュアップを続ける姿勢も感じ取れるものの、ただ、まだ実運用に乗せるには時期尚早か・・というのが筆者の正直な感覚なのです！

　そこで、ご提案したい費用配分方法はふたつ。

1. 部署ごとにユーザーアカウントを分けて管理する。
2. 社内向けのプライスリストを制作する。

4-1. 部署ごとにユーザーアカウントを分けて管理する。

　これはAWSを利用するユーザーアカウントを部署単位で分け、ひいては請求書を分けてしまうというもの。AWSの請求書がユーザーと紐づくことを利用したもので、現状最もシンプルで確実な費用配分手段といって良いでしょう。ただし、デメリットもあります。「ユーザーが分かれる＝ネットワーク（Amazon VPC）も分かれる」ため、IPアドレスやサブネット、ゲートウェイといったネットワーク構成管理の負担増には目をつぶる必要があります。また従量課金（利用量に応じて金額が変動する）というAWSのサービス特性上、事前の予算化が難しく、ともすれば日本企業に馴染みにくい部分があるかもしれません。

4-2. 社内向けのプライスリストを制作する。

　こちらは、あらかじめ社内提供用のオリジナル価格表をIT部門で定義してしまいます。前述の1にある課題をクリアできるため、ある種理想的な課金の仕組みではあるのですが、いかんせん難易度が高い。システム提供時の平均的なリソース利用量を予測して価格を設定する必要があり、初めてAWSを運用する担当者にとっては雲をつかむような話でしょう。その上見積もりを誤った際にはIT部門が費用を被らなければならない側面も。あと、為替の変動リスクも見逃せません（AWSの請求は「＄（米ドル）」です）。

　従って落としどころとしては「まずは部署ごとのユーザーアカウント分割。追ってプライスリスト検討」というのが現実路線となり、実際多くのお客様がそうした選択をされています。もちろんAWS運用に慣れたSIerへの相談も併せてご検討くだいませ！

最後に

　本記事では事業部門が主導するAWS導入の勘所をご紹介させていただきました。「1. 独立したシステムとしての導入」「2. ガイドラインの整備」「3. 体制づくり」「4. 課金管理」と決して平たんな道のりではありませんが、ひとつひとつこなしていけばAWSをいつでも必要なだけ利用できる真の意味でのクラウドサービスとして活用できるでしょう。微力ではありますが、当記事が皆様の日々の業務のお役にたてれば幸いです。

　AWS移行について、さらに踏み込んだ移行のポイントや事例等の関連記事は、下記よりご覧いただけます。