AWS導入の“社内りん議”は通せるか--初心者が絶対に通る道と対応策

AWS初心者が絶対に通る道〜そして伝説へ〜

中山順博氏（以下、中山）：モデレーターを務めさせていただきます、中山と申します。よろしくお願いいたします。本日は、「AWS初心者が絶対に通る道〜そして伝説へ〜」と題しまして、パネルディスカッションをさせていただきます。

まず、このパネルディスカッションの趣旨なんですけれども。ここにお集まりのみなさまは今、AWSの導入を検討されていたり、今まさに導入を進めていらっしゃったり、もしかしたら運用までされている方もいらっしゃるかもしれませんし。

あと、そもそもAWSにするかどうかも含めて、まだ検討中という方もいっらっしゃるかもしれませんけれども。

そういったみなさま方に、私たちの経験をお話しすることで、みなさんの今後の活動に少しでもお役立ちできるんじゃないかなと思いまして、今回こういった講演をさせていただく運びとなりました。最初に、今回の登壇メンバーの組織における役割をお話ししておきたいと思います。

まず、パネラーの山下さんは、いわゆる純粋にユーザー企業としてAWSをお使いいただいています。

アイレットの齊藤さんは、MSP事業ということで、みなさん「cloudpack（クラウドパック）というサービスの名前をご存知の方も多いと思うんですけれども、そちらで情報セキュリティ管理責任者をやっていらっしゃいます。

私は、内田洋行という会社でいわゆるSIerですね。SIをやっている事業部でインフラのエンジニアをさせていただいております。

ぜんぜん役割は全員違うんですけれども。共通点としましては、このあともご紹介するJAWS-UGというコミュニティで活動していたり、当然所属する組織でAWSの利活用を推進しているというメンバーでございます。

JAWS-UGのご紹介なんですけれども。その名のとおり、AWSのユーザーグループでございます。日本全国支部がございまして、東京に関しましては、すごいたくさんの專門支部もございます。明日の19時からイベントもありますので、ご興味のある方はぜひご参加いただければと思います。

では、まずは山下さんのほうから自己紹介をお願いいたします。

AWS導入2社の事業内容

山下光洋氏（以下、山下）：中央電力という会社で情報システム部をやっております、山下と申します。よろしくお願いします。

うちの情シスなんですけど、ほかの2名、もともとシステムなどをやっていない人間と一緒に3人で情シスをやっているというところです。

去年の5月からAWSを使っておりまして、そこで自社サービスやったり、全業務のシステムのAWS移行を来年の2月に一応完了するというところを目標に今進めているという状態でございます。

先ほどご紹介にありましたように、JAWS-UGで少し活動もさせていただいておりますので、よろしくお願いします。

中山：ありがとうございます。では次、齊藤さんお願いいたします。

齊藤愼仁氏（以下、齊藤）：アイレット株式会社、cloudpack事業部の齊藤愼仁と申します。僕は、情報セキュリティ管理責任者として、いろいろセキュリティ周りもやりつつ、ふだんは情シスの役割をやっています。

チームのメンバーは11人いるんですけれども。情シスの担当は開発の2名とその他という感じで5名のスタイルでやっています。

会社自体は、プライバシーマークを筆頭に、いろんなセキュリティの監査要件をクリアしているというかたちですね。

僕の個人ブログで「ロードバランスすだち君」という、非常に最高なブログがありますので、ここをご覧いただくと非常に生々しい話がわりと書いてありますので、これはまあ、後ほどご覧いただければと思います。

中山：ありがとうございます。では、ちょっと私の自己紹介をさせていただきます。今日は基本的にモデレーターとして振る舞わせていただくんですけれども、若干パネラーとして私の経験もお話しさせていただこうかと思っております。

私は今、内田洋行という会社で自社サービスのインフラの運用とか、新しい事業の開発を担当しております。

会社としましては、AWSの利用を一昨年の4月ぐらい、ちょうど2年ぐらい前に使いたいということで提案をして。その半年後ぐらいに、まずは事業部からということで運用を始めたというかたちになっております。

私も先ほど申し上げましたJAWS-UGというユーザーグループで活動しておりまして。「初心者支部」というところですとか。あとは「CLI專門支部」というちょっと変わった支部があるんですけれども、そちらで活動したりしております。

AWS導入検討の経緯と課題

では、さっそく本題に移りたいと思います。今日のお題として5つほど用意をさせていただきました。

まず1つ目に、AWSの採用の検討のフェーズ。2つ目に稟議の通し方、予算の申請。3つ目に料金について。4つ目がパートナーの利用とありますが、これは自力で運用するのか、それともプロに任せるのかといった話です。5つ目、使ってみて実際にどうだったかというところを考えております。

まず1つ目のお題、AWSの採用の検討というところなんですけれども。当然検討するにあたっていろんなことを考えるかと思います。

最初に、そもそもAWSを検討した背景・目的ですとか、あとはほかのサービス。IaaSといますか、こういったインフラよりのサービスに限らず、SaaSなども比較したのかとか、オンプレと比較したのかとか、あとは実際になにを移行したのか。

また、検討したけど、ちょっと難しいと思ったものはなかったのかとか。あとはアプリケーションベンダーさんのパッケージのサポート周りのことですとか。いろいろあろうかと思いますので、このへんお話をしていこうかと思っています。

最初に、全員役割が違うということを申し上げたんですが、基本的には山下さんのご経験をベースにしてお話をさせていただいてディスカッションをしていくという流れにさせていただこうと思っております。

じゃあまず山下さんに、そもそもなぜクラウドサービスを導入しよう、検討しようとされたのかというのをご説明いただいてよろしいでしょうか。

山下：スライドに書いてあるんですけれども、技術者にとっていい仕事ができるんじゃないかと。そこの説明もしないといけないんですけど、今日いらっしゃる方で情シスの方は何人ぐらいいらっしゃいますか？

（会場挙手）

ありがとうございます。わりといらっしゃる。情シスさんとかでやられてるとよくわかるかなと思うんですけど。自分の職場で同じ仲間からの要望を受けて、なにかしらのシステムをやっていかないといけないと。

そういうときに、やはり事業を進めていくなかで、「これを絶対しないといけない」「これはしたい」というところをすぐ構築することができるというのは、たぶんクラウドしかないと思うんですね。

それがあってのクラウド採用というか、選択したというところですね。やはりオンプレの場合、いろんなハードルが多く高いというところがあるので、そこで選んだというところがあります。

中山：ありがとうございます。ちなみにお聞きしたいんですけれども、こういった検討を始める時点では、山下さんのところのITインフラというのはどういったかたちで運用されていたんでしょうか？

山下：すべてデータセンターにあるような状態、運用管理もデータセンターの方と、外部業者の方がすべてやっているという状態です。

中山：なるほど。ありがとうございます。そのなかで、なにか課題みたいなものはありましたか？

山下：とくにないですね。それをそのまま続けていくうえではなくて、例えば、もうすでに動いているシステムのなかで、「ここをこう変えたい」「新しい仕事でこういうことがやりたい」というときに、そのシステムを変える、もしくはサーバーを増やすというところにすべて稟議が必要になってくる。

そこのハードルが高くて、「効果が出るかどうかわからないところの投資はできません」となって諦める。これの繰り返しですよね。それが一番大きな課題だったと思います。

中山：できるだけ新しいチャレンジをしやすい環境が必要だったという感じでしょうか？

山下：そうですね。

AWSの導入を決める際の指標

中山：ありがとうございます。では次に、実際に山下さんがそういった複数のクラウドサービスを検討するにあたって、どんな指標で検討されたのかというところをご説明いただいてもよろしいでしょうか。

山下：1位がシェアです。その下が、「運用、価格、学習コスト」と書いてるんですけど。ご説明したいのは1位のシェアの部分ですね。

IBMさん、Googleさんとか、いろいろあるんですけれども。要は一番使ってる人が多くて、かつパートナーさんも多いと。

万が一、自分が急にいなくなったときに事業が止まる可能性があるのかというところで、自分の代わりがいくらでもいるようなところで、AWSを採用しています。

学習コストというところなんですけれども。やはり勉強会という意味では、JAWS-UGがすごく活発でして。私も行き出して1年ぐらいなんですけれども。

そこでもいろいろなことを教えてもらえる、自分も学習していけるというところがあってAWSを採用したということですね。

中山：ありがとうございます。また1個質問なんですけれども。この学習コストのところで、コミュニティは基本的に業務時間外、夕方や土日祝日に勉強会をやることが多いんです。

私なんかは好きで行ってるからいいんですけれども。同じ情シスの方にはこういったAWSの勉強や学習をどのように勧めてやってらっしゃいますでしょうか？

こういったコミュニティに業務として出ろというのはちょっと言い難いところがあるんじゃないかと思うんですけれども。そのへんの実体を教えていただければと思います。

山下：基本的に誘うようなことはしてなくて。「行ってくるよ」と。それで「行ってきたよ」「こういうことがあったよ」「楽しかったよ」と。そういうことをずっと発信し続ける。

とにかくこういうところに出てくる人というのは、自分で選んで来ないと意味があまりないのかなと思っています。なので、そこはなにもしていないという状態ですね。

中山：ありがとうございます。もう1つお聞きしたいんですが、この「従量課金であること」というところなんですけれども。ここは逆に懸念されることがわりと多いような要素だと思うんですけれども。

ここがあえて評価ポイントというのは、先ほどおっしゃっていたように、新しいチャレンジをするというところではむしろこっちのほうがやりやすいと。そういった考えでここは評価されてたということでしょうか？

山下：そうですね。

中山：なるほど。ありがとうございます。

開発環境の移行にあたる苦労

次にいきたいと思います。こういったかたちで検討されて、AWSを導入されたわけなんですけれども。実際に、現時点で移行について悩んでるシステムですとか、そういったところを山下さんからおうかがいしてよろしいでしょうか。

山下：物理のネットワークのところとかはどうしても難しいところがあって、解決策はあると思うんですけれども。そこはなかなか手が出せないと。

まあパッケージソフトですね。メーカーさんが嫌だって保証してくれないというところがあって、悩んでいるという部分はあります。

中山：ありがとうございます。じゃあ、齊藤さんにおうかがいしたんですけれども。齊藤さんのほうは、すべてAWSに移行済みということなんですけれども。実際、移行にあたって苦労された点ですとか、なにかありましたでしょうか？

齊藤：そうですね……実際に苦労した点は一切ないですね（笑）。

中山：なるほど。

齊藤：もともとオンプレの資産がそんなにないので。たぶん億単位とか何千万円単位でオンプレ資産を持ってて、償却しないといけないとかだったらしんどいんでしょうけど。うちの場合はほとんどそういったことがないので。

オンプレが一切なかったわけではないんですけど、それを持っていくといううえでは、そんなに苦労はしなかったですね。

あとはさっき学習コストの話がありましたけど、cloudpackって事業自体がAWSのプロフェッショナル集団なので、AWSのことに関して基本的になんでもできるんですよね。

AWS Direct Connectをひくという話になってもわりとサクッとひけるようになってますし、そういった意味では非常に楽させてもらいましたね。

中山：ありがとうございます。ついでに私の経験もお話しさせていただきますと、私の場合、クライアントを含む開発環境の移行というところでちょっと悩みがありまして。ソフトウェアのライセンスのところで、もっていけないことはないんですけれども。

具体的に言いますと、Microsoftのビジュアルスタジオですとか、ライセンス的に難しいところ。もってはいけるんですけれども、面倒なところがありますので、今ここを少し悩んでいるというところです。

Amazon WorkSpacesにアプリケーション、Amazon WorkSpaces Application Managerというのがあるんですが。まだ東京に来てないので、これが来たら移したいなと思ってるものがあります。

クラウド導入への社内の懸念・反対意見に対する回答例

最初の検討の経緯は以上といたしまして、次に予算の申請、稟議の通し方。実際に組織のなかでAWSを使いたいと提案したとします。そういったときに、やっぱりいろんな方を説得したり、周りを巻き込んでいかないといけないわけです。

そんななかで、懸念ですとか反対意見をいろいろ言われるかと思います。あとは今までのやり方と比べて、「本当にどっちがいいんだ？」みたいなことを考えないといけないと思うんですけれども。

そんななかで、これまでどういった対応をしていきたか、というところをお話しさせていただきたいと思います。

こちらも山下さんが実際に問われた内容を踏まえて、具体的に聞かれたことを1つずつあげていきまして、いろいろディスカッションしていきたいと思います。

まず1つ目、これは山下さんが聞かれたことなんですけれども、実際どういうことだったか教えていただいてよろしいでしょうか。

山下：書いてあるとおりですね。要は、クラウドにいったらこうなるんじゃないかというところで、「自分でCPUを選んだりメモリを選んだりできないんでしょ？」ということを言われました。

ただ、それが本当のシステムによってやらなきゃいけないことをできるかどうかの壁には、今の時点ではなりえないなという判断をしてます。

中山：なるほど。ありがとうございます。

齊藤さんにもおうかがいしたいんですけれども。実際問題、「クラウドでは難しくて、オンプレじゃないと難しいよね」みたいな用途はあまり思いつかないなと思うんですけれども。実際にまだクラウドって難しいんじゃないかみたいなことは、なにかあったりするんでしょうか？

齊藤：難しいというよりかわかりやすいという意味で、「日本国外にデータ絶対に持ち出したくないんだけど」というシチュエーションがあったときに、目に見える場所にものがあるみたいな安心感というので、「ちょっとクラウドはな……」って煙たがられることはありますよね。

もはやAWSは東京リージョンがあるので、それがどうしたって話なんですけど。目に見えないものを伝える難しさはありますね。

中山：機能ですとか性能面で難しいことがあったりというのはないものなんでしょうか？

齊藤：昔はAWSのメモリも16ギガまでしかなかったりという時代もありましたけど。もはやX1のインスタンスなんてメモリが2テラとかいってますからね。

もう好きにやりたい放題じゃないですか。オンメモリDBとかできちゃうわけですよ。SAP HANAとかね。もう好き放題できちゃうので、そのへんの障壁はもうだいぶなくなりましたね。

中山：なるほど。ありがとうございます。では、次です。こちらも山下さんからお願いできますでしょうか。

山下：これも同じように聞かれたんですけど。そういった多様なIPとかインスタンスが必要なときに、リソース不足に陥るんじゃないかと。これは「緩和申請で事前に申請しておけば大丈夫ですよ」と回答してます。

中山：ありがとうございます。齊藤さんにおうかがいしたんですが、cloudpackさんではけっこう大規模な事例もホームページに載ってたりすると思うですけれども。申請した量があまりにも多くて断られたなんていうことは実際になかったんでしょうか？

齊藤：ないですし、基本的にユーザーさんから「これだけ申請しておいてね」って言われた数字よりちょい増しで申請してますので。一応マージン取ってね（笑）。

中山：なるほど。

齊藤：あとは予想して、「これだったらたぶんSESもあるな」というので追加で申請したりするこも多々ありますね。怒られることはないですね。

中山：ありがとうございます。では、次。こちらも山下さんに質問の経緯をお願いできますでしょうか。

山下：クラウドというと「セキュリティ大丈夫ですか？」と言われることがあると思うんですね。ただ、「それよりもオンプレで自分たちが管理してるほうがリスクあるんじゃないか」と回答してます。

その根拠としては、これだけの第3者認証を取得しているという事実がありますので、それをそのまま回答しているということですね。

中山：ありがとうございます。ちょっとお聞きしたいんですけれども。実際にここにいろんな種類の第3者認証が記載されているんですけれども。

そもそもこれ一つひとつがどんなものかですとか、これがどれほどのものなのかみたいなことは逆に聞き返されたりということはなかったんでしょうか？

山下：それはなかったですね。

中山：齊藤さんの会社では、そういったいろんな認証を取られていると思うんですけれども。これらの認証が実際どれほどのものなのかというのを、解説をお願いできればと思ってます。

齊藤：これ全部解説したら、たぶん3時間ぐらいかかると思うんですけど（笑）。例えば、PCI DSSの話をしちゃいますけど。PCI DSSを知らないって人はいらっしゃいます？

（会場挙手）

けっこういるんですね。もうちょっと、頑張れって言わざるをえないですね（笑）。

PCI DSSは日本ではだいぶ知名度が上がってきたんですけど。2020年に、オリンピックがくるじゃないですか。あの間に国もPCI DSSをしっかりやれよというふうに、今、国としてわりと動きが活発になってきている第3者認証なんですね。

国際規格で、「Payment Card Industry Data Security Standard」の略なんですけど。国際ペイメントブランド5社が共同で策定した、クレジット業界における国際的なセキュリティ基準というものになっています。

クレジットカードのようなセンシティブなデータを扱うときに、こういうセキュリティって絶対実装的に需要だよねとか、脆弱性試験これだけ必要だよねとか、負荷試験これだけやってるという、ファシリティの話も含めて、きちんとできてますかということを監査するんですね。

クレジットカードの情報をできるだけ極小化しなさい、扱う場所を小さくしなさいという考えがPCI DSSの非常に基本的な考え方です。

そういったものを取り扱わないお客さんだとしても、PCI DSSを持っていることで、そういったセンシティブなデータも扱えるんだよということを証明できるわけですね。なので、非常に今需要が高まっている監査になってますね。

AWSのセキュリティの信頼性

中山：ありがとうございます。齊藤さんのところでもう1つ、こちらのSOC2というのを取られてたと思うんですけれども。こちらについてもよろしければ、よろしいでしょうか。

齊藤：AWSもSOC2を積極的にやってるんですけれども。SOC2というのは、日本ではほとんど知られていなくて。国内の業者でも本当に大手さんが数社取られているだけのわりとマイナーな認証なんですけれども。

AICPAというアメリカの公認会計士協会が定めるセキュリティの要件なんですね。セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシー、この5項目のうち2項目以上をやりなさいと言っているのがSOC2ですね。

日本だと上場企業さんがJSOXなんかやると思うんですけれども。あれのもっとセキュリティに特化してかなりうるさくしたバージョンがSOC2ですね。

ありのままの内部統制の情報は、この会社さんはこういうことをやっていて、セキュリティはこういう体制でやってますということを全部レポートに書いて公開するんですね。

普通ISMSとかプライバシーマークとかやられてる方はわかると思うんですけれども。監査の内容を第3者に公開するということはないと思うんですよ。

ところがSOC2は全部公開されるので、もうありのままが見たい放題になるというような、非常に厳しい監査なので、知るところでは史上最強の監査だと思っています。

中山：ありがとうございます。この2つを齊藤さんのところのアイレットさんが取得されてると思うんですけど。雑な質問で恐縮なんですが、これを取得するのはどれぐらい大変でしたか？

齊藤：例えばプライバシーマークって日本では有名ですけど、あれは国内基準なので、国際的には通用しないんですよね。あれは総務系がちょっと大変かなというぐらいで。

次にISMSというのがあるんですね。「ISO27001：2014」ですけど、これが、会社規模にもよるんですけど、まあ1週間ぐらいで監査は終わるかなというぐらいのものですね。

PCI DSSになると、極小化すればいいだけの話ですので、全社でやるとなるとけっこう大変なんですけど、これもだいたい1週間ぐらいの監査で終わりますね。金額的にはISMSの2倍ぐらいの価格レンジで取れるのがPCI DSS。

SOC2はしんどくて。うちが一番初めにやったときは、監査に1年半かかったんですよ。そんなにかかっちゃダメなんですよね。けっこう怒られたんですよ。

次、今年もまたやるんですけど。SOC2、1年更新でやるんですけど、もうPCI DSSの3000倍ぐらい大変なんですよ。かかる金額もたぶん3000倍ぐらいなんじゃないかってぐらい大変ですね（笑）。

なにがすごいって、AWSのレポートは半年に1回監査してるので、そのスピードではできないんですけど、まあうちは1年に1回やろうということでやってますね。

中山：ありがとうございます。今のお話ですごいAWSさんがどれだけセキュリティに力を入れてるかというのは納得いただけるんじゃないかなと思います。