なんでもかんでもクラウドにあげるのか？
某エントリーの話で、「なんでもかんでもクラウド化なのか？」というお話もご意見も多数頂戴いたしまして。一応念押しですが、そういうつもりはまったくないですよ。以下、個人的な補足メモです。会社の意見ではありません。一応、会社の公式声明は「できるものは、とっとクラウド化したほうがいいですよ。」です。
クラウド化の是非については、いろいろあるでしょう。ユーザーの所属する産業毎にシステムのあり方・考え方は違うでしょうし、当然クラウド化すべきだという意見や、いやそもそも無理があるという意見もあると思います。ただ、今までのように先例がないから無理、という理屈は通用しなくなっているのが現状でしょう。その意味では無茶な理屈ではなく、普通に選択肢としてクラウド化が候補になっている、と思います。その上で、クラウド化しない、するという議論が普通にできる状態になりつつあると思います。
そんな中でいろいろ思うところをちょっと補足しておきます。なんかいろいろと変なところのボタンを押した感もあるので。割とざっくばらんに書きます。以下、なんだかクラウド＝AWSみたいな論調になってしまっていますが、業務系システムのクラウド化という意味ではAWSが議論の代表格になってしまっているのが現状なので、ご容赦ください。
・クラウド（特にAWS）はエンド・ユーザーが「安易に直接」使うものではない。前提として、ミッション・クリティカルな業務システムのクラウド化の話です。なんか適当なWebサーバーをレンタル・サーバーにようにホイホイ立てるって場合は、別に直接使っていいと思います。
その上で、ですが・・・
まず、まじめにクラウドの代表格であるAWSはそれほど簡単ではありません。たしかにAWSは社名に「サービス」と入っていますが、日本の商慣行では「プロダクト」に近いと思います。これはサポートの内容に顕著です。AWSのサポートは、サービス・サポートとして見ると失格ですね。受け答えについては「サービス」とはいえないところが散見されます。ただし、プロダクトと見るとまぁそれなりにはわかります。サービスであれば、一種の接客やより細かい受け答えがサポートする側に必要です。すなわち、問い合わせをするユーザーも「動かないのですが、よくわかりません。これどうなっているのですか？」ということを「サービス」サポートであれば尋ねる事も可能ですし、サービサーもある程度踏み込んで答える必要があります。しかし、プロダクトではそうはいきません。原則として切り分けはこちらでやる必要があります。しかもある程度AWSの内部情報なしで行う必要があります。AWSのサポートは、この意味でサービス・サポートというよりもプロダクト・サポートに近いです。
ユーザーさんもクラウドベンダーやマスコミの口車に乗って直接使ってみようとするところも多いですが、現実はなかなか厳しいと思います。実際に、某所でも「EMR上でいろいろ動かしたいのだけど、どうやったらいい？」とか、「とりあえず、やってみたけど動かない。どーすればいいの？」という質問もよく見ますが、端から見ていて、そーゆー質問をしている段階でAWSの自社運用は論外だと思います。自分でログを見て、当たりどころ見つけて、ある程度切り分けを自分でするということが出来ていないといけません。
ただ、これは製品サポートを使う場合には良くある話です。例えばDBをプロダクトベンダーから購入したとします。「なんか動かねーけど？」っていう質問をベンダーサポートに問い合わせをしても普通に「頭大丈夫ですか？（とは言いませんが、似たような）」回答が来るのが普通です。これと似たような感じです。
AWSはプロダクトであって、サービスではないです。高速で走る車は提供されますが、ドライバーは提供されません。自分で運転することが前提です。つまり、運転免許ぐらいとっておきなさいよ、ということです。んで、大抵のエンドユーザーさんは免許とか取っていません、というか、育ててないので運転手が居ません。なので、使えません。ユーザーが直接AWSを使うにはそれなりのインフラの使い手がいることが前提です。（AWS以外の和製クラウドはちゃんとサービスになっているんじゃないのか？という議論もあるにはあるんですが、そもそもそれはクラウドか？という議論があるので、とりあえずおいておきます。というか、AWSよりももっと酷いサービス水準とか普通にありますね。）
・んじゃSI屋さんに頼みますか？ 人材を抱えていないエンド・ユーザーさんから見ると、んじゃーSI屋に頼みますか、ということになるのですが、特にメーカー系SI屋さんにお願いする場合は当然、無理が発生します。箱を売っていたり、自社のDCを持っているSI屋さんに取っては、これは一種の利益相反になってしまいますね。特に、リスクヘッジ目的でSI屋を使っているユーザーさんは、リスクヘッジの代償としてシステムのガバナンスをSI屋に渡しているので、それを人質に取られて、あっさり断られます。曰く「何があっても保証しませんよ」ここで試合終了が普通です。勿論例外はありますが、それはあくまで例外でしょう。
DCをもっているSI屋さんは、そこで働く人材の食い扶持を稼ぐ必要があります。自社外のクラウド利用はビジネス上、かなり辛い。（SI屋さんも立つ瀬がないので、自社DCに適当な仮想化ミドルいれて、クラウドですぜと言い訳に奔走してますが、いろいろと残念な結果になってしまっています。）
んじゃー、E/Uはどうしたら業務用システムにクラウドを使えるのか？ということですが、以下、「超個人的」な試案です。（個人的な話であって、会社の意思とは全然別です。）
・まずガバナンスをとるべき
自社のITガバナンスがない段階で、クラウドだとかオンプレだとかの決定権は本質的にはユーザーさんにはありません。従ってまず、ガバナンスをちゃんと握ることが必要です。当たり前のことだと思います。システムの構築を外にまる投げしている段階で、ベンダーにクラウド使えって怒鳴ったところで、前に物事が進むわけがありません。（率直に申し上げますが、システムの構築を外注SIに任せてリスクヘッジができるとか、そういう時代ではありません。敢えて言いますが未だに「時代錯誤的」な丸投げSIとか本当にいい加減にした方がいいです。）
その上で、ですが・・・
・結局インフラは、自社でもつのか？クラウドにするのか？
選択の余地を得た段階で考えるべきところが、ここからです。要するに、問題は基盤インフラどうするか？です。以下はインフラの話です。アプリとかは別です。
以下、SI屋さんの偉い人には、キツいこと書いてますので、できれば読まない方がいいですね、というか、読まないでください。何度もいいますが、これは自分の個人のメモで、会社とは関係ないです。はっきり言っておきます。
1.社会インフラを支えているという意識のある（またはそういう意識を持つべき）企業
・自社のインフラチームをちゃんとつくる
極論言うとゼネコン型のSI屋さんは全滅していると思ってください。勿論中堅で頑張っている別格のところもありますが、総じて現時点の日本の大手SI屋さんで、インフラ技術力でグローバルなクラウドベンダーに勝てるSI屋はゼロです。よって、そこに頼るのではなく、自分の力でITインフラをどう作るのかちゃんとプランを立てて戦略を持つべきです。直接、製品パーツ供給ベンダーと話をつけるぐらいのことはやらないと無理です。
もう既にそういう動きをしているユーザーさんもいらっしゃるのは割と有名で、気づいている人も多いと思いますが、まだまだ少数です。自社のインフラをメーカー系SI屋に任せている段階で、自社のインフラ力のキャップがSI屋にかかってしまっていることを自覚すべきです。
本来の技術力やR＆Dではなく、人月商売の一山いくらの土建屋SIをSI屋の人材育成の軸にしてしまった責任の一端がユーザーサイドにあるのは、残念ながら現実です。パートナーのSI屋に「お前らなんでそんなに一方的にAWSとかにやられるわけ？」とか言ってみたところで、無駄です。こうなってしまったものを不可逆にすることは非常に困難です。土建屋SIは、ある程度ベース・マーケットができてしまっていますからね。
まずもって、ちゃんとしたインフラチームをつくるべきです。経験的には、それなりの社会インフラ系の企業には、ちゃんとしたインフラチームがあることが多いのですが、ここをより強化すべきでしょう。上のAWSのサポートの例でいうと、「ちゃんとした運転手」を育てるべきということにつきます。ただしこれは人件費コストや採用・評価の筋道や、社内のキャリアパスの設定や企業文化との相性の問題もあり、簡単ではありません。とはいえ、自ら社会基盤の供給者と任じるのであれば、このような組織体制はつくれなければいけないでしょう。真面目にプロのインフラ専門家のチームを社内で育て強化しないと、SI屋さんに任せていたら、いつの間にか、社内のIT基盤の時代遅れ感がひどく、気づいたらAWSの軍門に下ってました、ということになりかねません。
次に「言いたいことはわかるが、SI屋が対抗できないところにE/Uが対抗できるか？」という話に、ま、当然そうなるわけですが、一応やり方はあります。まぁ、個人的意見ですが・・・
・自社インフラの最適化の方向がクラウドとは異なることを利用する
自社でインフラを保持する最大の利点は、業務に応じた最適化がハードウェアレベルで可能になる、ということです。この点ではいくらクラウドベンダーが技術的に優れていても最適化の方向が汎用性に収斂する以上、業務系に最適化した基盤に勝てる見込みは低いです。とくにハードのパーツ・構成・N/W・ミドルまである程度の業務利用の制約をつけたインフラをそれなりの規模で保持できれば、それなりに対抗できます。ITは「いろいろと捨てる」ことがパフォーマンスを出す秘訣であることは論を待たないでしょう。（逆に、現時点最強のクラウドベンダーのAWSの最大の弱点はサービスを増やしすぎるところです。いろいろやり過ぎると、過ぎたるは猶及ばざるが如しになりますね。）
これは実はSI屋には無理で、SI屋の性格上、ある程度キャッチオールな仕組みで勝負する必要があり、この途端にクラウドベンダーと同じ土俵に乗らざるを得ません。ユーザーさんのコンペの比較表が機能一律のマルバツ採点表であることが多い以上これは仕方がないでしょう。しかし、これではグローバルなクラウドベンダーにはなかなか勝てません。
一方、ユーザーさんは同じ土俵に乗る必要はありません。業務系の基盤とクラウド基盤は最適化の方向性が違います。一定の業務向けに最適化されたIT基盤は、ユーザーの業務にとっては最適なパフォーマンスを提供します。これはクラウドでは実現できません。ただし、この基盤を構築・維持・メンテするには、ある程度の人材やリソースを社内にきっちり保持するということが前提になります。つまり高コストになります。ある程度コストを払って、業務に対して高い付加価値をとるという戦術になります。（逆に言うと、このレベルまでの最適化のアレンジメントができて初めて、社会基盤系企業はITのガバナンスを取っているといえると思います。）
たとえば、自分の専門でいうと、業務バッチ処理をHadoopで処理する場合、業務バッチにある程度用途制限した形でハードウェアの構成を最適化することができることがわかっています。これによりたとえばオンプレミスで、クラウドを完全にアウトパフォームする基盤プラットフォームを保持することができます。ただし、これはあくまで自力である程度構成を作れるユーザーの力がなせる特権です。なお、汎用性を求めてつくったHadoopクラスターではこうはなりません。そのような場合は、メンテとか考えれば圧倒的にクラウドの方が有利です。（Hadoopでなくとも、ある特殊な構成のクラスターで特定業務に特化した基盤でパフォーマンスを出しているというのは、最近はよく聞きます。）
もっとも、この方向は一歩間違うと「自社ガラパゴス基盤」をつくることになってしまいます。周りの技術的動向を見ながら、行き過ぎないレベルでの自社基盤の最適化が必要になると思います。違う方に進むと、組み込み・プロプラな世界になってしますので、これはイカンです。・・最終的にはバランス感覚の問題になりますが、そのための内製化基盤ではあるので、ちゃんとできているのであれば、まぁ大丈夫ではないかと思いますが。
（とはいえ、自分の専門の流通ITはわかんないですけど・・何しろAWSの業務の本質は小売流通なんで、よく見るとそれに最適化した基盤が出ているわけです。業務屋視点でみると、あーそう使うの？みたいなものはいくらでもあります。たとえばEMRは、あれはビッグデータの分析基盤じゃないですね。高度な分析的な使い方の方がむしろ例外でしょう。業務屋視点で見れば、小売の大規模マスターの更新バッチ基盤ですよ。どこも苦労している例のアレですわ。AWSはルーツはたぶん社内用のインフラで便利な基盤を、ある程度汎用化して外にだしているだけだと思います・・・）
という風に、自社基盤のあり方を組織を上げてとことん追求すべきです。そこまでチーム力を上げていれば、必要なときに必要に応じて主体的にクラウドを利用することができます。見ていると、チームビルディングが出来ていないのに、なんやらクラウド・ファーストとか言って、ただの「人件費とITのコスト圧縮のためだけ」でクラウド化を進めているところも散見しますが、本末転倒もいいところです。クラウドは道具です。使う人間次第と自覚すべきです。
2.ともかく生き残ることが優先という企業
とはいえ大抵の企業はこちらです。こういうユーザーさんは、少数精鋭でいいので、自分の会社のIT基盤を守れるチームビルドをやってください。んで、そのチームがクラウド使うか、SI屋のDCを使うか判断を任せるべきです。社会インフラ系のユーザーほど、自社に資源を無制限に投入できるわけではないので、IT基盤は、極論すると使えるものはなんでも使い倒すぐらいでいかないと先行き厳しいです。
そのためにチームビルディングがどうしても必要です。少数精鋭でいいと思います。その他大勢は居ても意味がないですね。これは力のある中堅をがっちり育てるしかないです。最初からそのつもりで人は採用してください。ITは腰掛けでできる（というか、他の全部署も本来そうですが）部門ではないです。ただし、勉強しないヤツはとっととパージしてください。この世界は暇さえあれば先を追いかける人間だけが精鋭になれます。昔は、トップエンジニアだった人が、勉強を止めた途端にどんどん退化して何もできなくなったという事例は、自分はそれこそ山のように見ています。IT屋ですらそうです。情報の遠いユーザーサイドでは、なおさらです。自己研鑽できない人間はIT部門にいるべきではないです。（というか、他の全部署も本来そうですが）
チームも集めようにも、そんな人材がいないという話もありますが・・各SI屋さんのインフラのプロの守護神を引き抜けばいいでしょう。どのDCやSI屋にも本当のインフラの守護神は居ます。ただし、どうにも使えない人たちのお守りや、食い扶持を稼ぐための仕事で自家中毒状態です。彼らはインフラのプロなのでクラウドにはそれなりに興味津々です。「給料上乗せ＋好き勝手やってみろ＋勉強をしている限りは職務は保証してやる」のオファーで普通にぐらぐらっと来ます。（それだけ今のSI屋の状況は悪いです。給料は上がるどころか、リストラ減棒->円安で物価上昇->消費税の増税の追い打ちです。それでもインフラ専門の評価が高ければいいですが、普通に低いです。・・・まぁ、なんというか、クラウド時代になるとインフラのプロのマーケットバリューは跳ね上がるのですが、自覚のないSI屋さんとか多いですからね。）
という感じで、インフラのプロは、プロとして調達して、チームビルドした上で、アプリサイドは、自社で企画・設計の人員を中から優秀な人材をハイヤリングすべきです。実装系は、小回りの効く業務系のSIパートナーか、仕組みや何やらを上手く使ってまわせればいいかと思います。企業のビジネスサイズによりますが、「ちゃんとした」4-5名のコアチームと周りをサポートする業務系パートナーが入れば大抵の業務は効率よく回ります。あとは後見人のできるITに理解のある役員がいると望ましいですね。
その上で、手段としてクラウドを選択する、ということが多分正しいと思いますよ。ま、あんまりクラウドの話じゃないんですが、そもそも論ができてなくてクラウドもへったくりも無いでしょう。
3.要するに
社内でちゃんとチームビルドすることが優先でしょうということです。SI屋さんの転落とクラウドの伸張を見れば、ユーザーサイドにボールが投げられているのは自明の理です。クラウドとかオンプレとか議論する前提は、使い手の能力がちゃんとある、ということです。当たり前だと思います。まぁそんな感じです。
・・もう一度、念のためにですが、これは会社の公式見解ではないですよ。公式見解は「クラウドファースト」ですよ・・・とほほ
