Asakusa on Spark

Asakusa on Spark

AsakusaがSpark上で動くようになりました。
Asakusa on Spark (Developer Preview) — Asakusa Framework Developer Preview 0.2.2 documentation

すでに実際に本番に利用しています。
ノーチラス・テクノロジーズがさくらインターネットにAsakusa Frameworkで開発した大規模データの高速処理基盤を導入し、顧客単位での精度の高い原価計算を実現高速処理基盤はApache Spark™で構築 | NAUTILUS

OSSとしての公開を行いましたので、内容や位置づけをまとめておきます。例によってノーチラスは社内でいろんな意見は当然出ていますが、今回は概ね一致している感じです。

  • パフォーマンス

概ね「業務バッチ処理という観点で見れば、すべからくHadoopMapReduceより、Sparkのほうが高速に処理を終えることができる」というのが結論になっています。ノーチラスの持っているユースケースでは、ほぼすべてのケースでパフォーマンス改善が見られました。おおよそ3倍から5倍の程度の実行時間の短縮が達成されています。これは一度のバッチで処理するデータサイズが、概ね数百GByte以下程度で、かつ、かなりの程度で複雑な処理になっているケースでのパフォーマンスになっています。さすがに非常に単純な処理（例：単純集計一発だけ）で、一度に処理するデータサイズが概ね500Gbyte以上のケースでは、MapReduceに軍配があがると思いますが、そのケースですらSparkもそれなりのパフォーマンスが出しつつあります。

なぜSparkにパフォーマンス優位があるか、というと、これは割と単純にHadoopMapReduceのオーバーヘッドが大きく、これをSparkでは取り除いているということにつきるでしょう。巷では（というかSparkの公式サイトでは）オンメモリー処理によりパフォーマンスが出ているといわれているが多いのですが、実際はそうでもありません。もっともIOコストのかかるノード間のシャッフルデータ転送時のディスク強制書き出しはHadoopMapReduceと同じであり、同じようにコストがかかります。Sparkでいうところの、オンメモリー処理というのは、繰り返し処理のときに明示的にキャッシュが使えるということだと思いますが、現実の処理では同じデータの繰り返し処理が中心でできているバッチがそうそうあるわけではなく、繰り返し処理で明示キャッシュが使えるからといってパフォーマンスが一般に10倍とかになるわけがありません。冷静に考えれば普通におかしいとわかる話なのですが、トレンディーな技術や会社が、VCからお金を集めるときにはよくあるストレッチの話なので、まぁ仕方がない話ですわね。

課題になっていたHadoopMapReduceのオーバーヘッドとは何かというと、自分の見るところでは大きく二つあって、一つはすべての処理を無理矢理Map・Reduceの形にしなければならない、という点です。これはよく言われるところではありますが、HadoopMapReduceではすべての処理をMap・Reduceの形に変形し、かつこの順序で実行する場合はどうしても無駄が発生します。もちろん、これはMap/Reduceの形にすることによって並列分散処理が実行しやすい、というメリットの裏返しですが、いろいろな処理をしていくようになってくると、さすがにデメリットが目立ちます。二つ目はMap・Reduceのタスク処理が実態としてはそれぞれが独立したjvmアプリケーションになっている点です。Map・Reduceのタスクが行われるたびにアプリケーションの起動・終了が行われるわけで、jvmの再利用オプションがあるとはいえ、このオーバーヘッドはかなり大きい。

上記の二点は大規模データに対する単純処理であれば、それほどコストになりませんが、DAGベースで1000ステージを超えるようなケースであれば、下手をすると総コストの5割がこのオーバーヘッドになることがあります。Sparkでは、上記の課題をきれいにとりはらっています。すなわち、処理を無理にMap・Reduceの形での順序実行をしているわけでもなく、またジョブ実行自体を普通に一つのアプリケーションとして管理しています。したがって、単純にHadoopMapReduceからSparkに変更するだけで、オーバーヘッドのコストが削減されることになってしまっています。

  • HadoopMapReduceの終焉

かなりの大規模なデータ処理のセグメントを除いて、現状のSparkはHadoopMapReduceと比較する限りにおいては、ほぼ一方的に優れていると言って良いでしょう。今後はHadoopMapReduceで動いているほぼ大部分の業務系の処理はSparkに（可能であれば）移行すると思います。Hadoopが登場した時分では、大規模データ（特にweblogやlifelog）の一斉集計が主要用途でしたが、現状では、データに対する操作は単純なGroupByではなく、さまざまな操作を要求されつつあります。このような状況で、パフォーマンスで見れば、HadoopMapReduceで動かし続けるデメリットは余りにも大きい。MapReduceに対する改善はすでに小規模なもののみとなっており、Sparkから比べて処理時間が3〜5倍かかることを鑑みても、HadoopMapReduce上でのアプリケーションに継続投資を行うことはあまりにも効率が悪い。もちろん大量データの単純集計であれば、まだまだHadoopMapReduceに分があるので、そのような仕組みはそのまま運用していればよい話で、無理やりSparkに移行する必要もないでしょう。

特に、我々がフォーカスしているような、特に企業の業務系のバッチ処理ではHadoopMapReduceを利用するメリットはほぼゼロです。データサイズや処理の複雑性から見ても、Sparkに軍配があがります。仮に、HadoopMapReduceからSparkに移行できないとすれば、それはあまりに大量の処理を裸のMapReduceで書きすぎたということになるのではないでしょうか？　4年前のAsakusaのリリース当初から、MapReduceを裸で書くことはアセンブラで処理を記述することとそれほど大差はなく、ほどなくメンテできなくなるだろうし、デメリットがどんどん大きくなりますよと、わりと声を大にして言ってきたが、現実となりつつある感もします。HadoopMapReduceは、ほぼいわゆる「レガシー」資産になりつつあります。

  • Sparkは無敵なのか？

ではSparkはそれほど無敵なのか？ということですが、当たり前ですが、無敵ではないです。（むしろHadoopが隙だらけだったという方が正しい）

・設定やチューニングが面倒
現状ではたいていの場合は、パフォーマンスが出ずに玉砕することが多いでしょう。加えて安定して稼動させるには経験が必要です。これはもうHadoopMapReduceのメリット（設定が分散処理基盤のわりには簡単）とデメリット（パフォーマンスの上限が割りと簡単に出てしまう）の交換に見えます。Sparkではパフォーマンスを出すために、アレやコレやパラメータを設定して、パフォーマンスを出すために試行錯誤する必要があります。これをアプリケーションごとに行う必要があります。さらにYarnで実行させるには、Yarnの設定も重要になる、ということで、これは確かに面倒です。広範囲にわたって整合性のとれた設定が必要であり、これはなかなか難易度が高いです。徐々にノウハウが共有化されていますが、できることが増えるということのデメリットはゼロにはならないでしょう。とはいえ、これはまさに時間の問題ですね。

・基本的なアーキテクチャの問題。
これはいろいろ意見がありますね。

ひとつは各処理の論理的な出力ポートがひとつであることです。ほぼ似たようなミドルのTezは複数取れますね。処理をブランチさせるようなフロー制御を行う場合は、基本的に無理が発生します。実際、Asakusaの実行基盤のターゲットとするときも問題になりました。Asakusaではあの手この手で解決しているが、普通に実装するのはかなり無理筋になります。

ふたつめはShuffle時点の強制書き出し。言うまでもなく、これはいちいちコストがかかるので。とはいえ、賛否両論です。特に処理の終盤で、前半戦で利用したデータをもう一度使うような場合があれば、書き出しは有効です。放っておけばそのままメモリーを占有してしまうからね。また、改めて言うまでもないですが、ノード・フェイルにも当然強い。そもそもRDDの発想からすると、書き出しは発想の根本にあるものなので、反対するやつは使うなという話にもなるようです。（んじゃー、サイトに堂々とin memory 処理とか書くんじゃねーよ、とか思いますが・・。実際、早とちりしている人も多数いますし）

とはいえ、どこで何を使うかは処理全体をコンパイルする時点である程度目星はつくので、ちゃんと見渡せる仕組みがあれば、Shuffleをいちいち書き出すのは無駄であることは間違いないでしょう。必要なときだけ書ければ十分だと思います。今後のメモリーの容量は太陽系の大きさ（比喩）まで広がる可能性があるので、plannerが賢くなった、しっかりした分散処理の管理基盤がでてきれば（まだないけど）たぶんSparkはわりとあっさり負けます。・・・当分先だと思いますが、具体的にいうとRack Scale Architectureベースのメニーコア前提の、割とかっちりした処理基盤が出たときには、かなり簡単に水を空けられるよなあ・・・とか思います。もちろん、その場合はHadoopは文字通り象なみのスピードの扱いになるとは思いますが。

さて、今回はAsakusaの開発陣の頑張りもあって、かなり大幅なアーキテクチャの変更が行われています。従前のAsakusaのコンセプトを維持しつつ、コンパイラがほぼ全面的に書きなおしになっています。従来のAsakusaはAsakusaDSLから最適なMapReduceプログラムを生成する仕組みになっていましたが、新しいコンパイラは一旦、DAGの中間構造を生成し、そのDAGの中間データからSparkに最適なバイトコードを生成する仕組みになっています。つまり、今後Spark以外の「より高速なDAGの実行エンジン」が出てきたときには、Sparkのバイトコード生成部分のみを入れ替えるだけで、新たな実行環境に対応することが可能になっています。現状、ノード分散環境化での実行形式の標準がDAGになりつつあるのは、周知の通りであり、DAGの実行エンジンはTezやFlinkを見るまでもなく、今後もいろいろ出てくるだろうとみています。Asakusaはそのエンジンに対応しやすくするために、今回根本のアーキテクチャを再構築しています。

これは、Asakusaの意味合いの変化をもたらすと思っています。ユーザーはAsakusaDSLで処理を記述しておけば、今後、より高速な処理エンジンが開発されてきたとしても、Asakusaが対応しさえすれば、そのメリットを享受できるということになります。特にソースコード・テストデータを「まったく変更することなし」に新たな高速環境に移行できるというメリットは非常に大きい。個人的には、テストデータ・テスト環境をそのまま持ってこれるのは、大きいと思っています。これは業務系アプリケーションの投資可搬性を大幅に向上させることになります。Asakusaにより業務システム投資サイクルと分散環境のライフサイクルのギャップを埋めることが可能になると思っています。

  • 今後

まぁこんな感じです。我々としては、Better HadoopとしてSparkを利用している、というのと、Sparkに対応するのと同時に、その先も見ながらAsakusaのアーキテクチャを予定通りに変えました、というところです。正直ベースで、Spark、かなり速いです。予想よりもいいですね・・・

Sparkをはじめ、今後の分散環境は高速化がますます進むでしょう。いろいろとできることが増えると思います。ベースデータレイヤーとしてのHDFS-APIは鉄板だと思いますので、HDFS互換にデータ溜めておいて、処理基盤だけほいほい取り替えるとパフォーマンスが勝手にあがるという感じになるでしょう。とはいえ、アプリケーションレイヤーから見るとシステム投資のライフサイクルと実行基盤のライフサイクルのギャップが進行しますが、その辺を埋めるのがAsakusaって感じになるといいなぁと思っています。


・・・って気がついたら一年ぐらい放置してたので、ちょっと反省してます。某プロジェクトにどっぷりだったので・・・
今後はできれば2ヶ月に1回ぐらいは更新したいと思います。すみません。

データセンターの原価計算について〜「クラウド」の別側面として

要するにデータセンターの「原価計算」です。いろいろこのあたりに関わっています。複雑な計算ロジックと大量のデータを扱う必要があるので、大規模並列計算の適用が必須になり、結果として当方の出番になった、という状態。尚、実行基盤にHadoop（MapR）を利用しています。（一応予定ではSparkに移行するつもりで、開発も始まっています。）

さて、いろいろやっていて思うところがあるので、現時点での考え方をまとめておきます。機微な部分はNDAになるので書きませんし、以下は自分の「個人的な」意見であり、特定のサービサーの話をしているわけではありません。基本的にInteropで公にしゃべった話のまとめです。

■現状認識
現在、国内DCはほぼ乱立状態に近いと思われます。ここへ来て春先のAWSの値下げのインパクトもありました。今後は、より競争的なマーケットになるでしょう。退場する企業やM&Aも活発化していくでしょう。生き残りをかけて各社は「次の一手」を打っていかないとあっという間に行き詰まるの業界の共通認識のようですね。

次の一手を打つ前に当然考えなければいけないのが、「それで今、いくら儲かっているだっけ？」という判断です。投資が有限である以上、回収して利益を出していかないと企業活動は停止に追い込まれます。勿論、「採算度外視で、まずはシェア優先」という戦略もあるでしょうが、それは前提として「採算の状況が正確にわかっている上での無視」が基本です。"わかった上での無視"と"わからないので無視"では意味が全然違う。

実は日本のDCはほとんどの場合、後者に近いのが現状です。要するに「いくら儲かっているだっけ？」が正確に把握できていない。いや、勿論簡単などんぶり勘定無敵のエクセルワークシートはありますが、それ以上のものはほとんどないでしょう。これは、サービサーの当事者に問題があるだけではなく、背景にある制度会計にも問題があります。この種のCostingを問題にしている人は中には多数いるとは思いますが、まず打つ手がないはずです。

■現状の「ざっくり原価計算」
DCビジネスは投資中心のビジネスです。従って、儲かっている＝投資回収ができている、のスキームです。この回収計算は大抵は以下のロジックで行われます。

初期投資：固定資産＝土地・建屋・電力設備等・空調設備等・NW機器・サーバー・その他のサービス系設備（セキュリティ・事務・防災）・付随する工事
ランニング：電力・空調・トラフィック・人件費

まず、初期投資額を提供可能なラック数または坪数で割り、ラック単価・坪単価を算定します。次にランニングを過去のトレンドから推定して、適当な指標を作り割り当てます。さらに収入サイドとして、ラック建値・坪建値を見積もり、稼働率や実際の見通し・実績を割り当てます。最後にラック（または坪）単位での収入から想定ランニングコストを引き、限界利益を算出して、期間累計でラック・坪単位で回収できていれば黒、ダメなら赤。以上です。

非常にシンプルです。結果として、やるべきことはラックの稼働率・坪効率の向上になります。あとは、できればラック単価・坪単価の値上げのための「付加価値戦略」の追加です。(尚、コストでは勝負にならないので、人手をかけた高サービス、ってな言い方をサービサーが言いますが、これは根本の投資回収ビジネスが変わっていない以上、付け焼き刃の後追い施策でしかないです。Costingを見ればすぐにわかる話です。)

この原価計算の最大の問題点は、「ラックベース・坪単位にユーザーを紐付けることができないクラウド型のサービス」では、ユーザー単位での収益性が文字通り「まったくわからない」ということです。無論、ハウジングなりコロケーションなり、ある程度ユーザーアカウントが特定のサーバ・ラック・敷地に「制限する」ことができているのであれば、この割とざっくりしたコストモデルでも、適用できます。実際、そうしてやってきたの現状でしょう。

ところが状況は変わりつつあります。クラウドベースのサービスは、リソース配分がハードベースからソフトベースに抜本的に変わります。本来であれば、ハードベースのコストモデルは役に立ちません。言われてみれば、当たり前です。しかし、現実にコストモデルを仕組みから変えていくというのはかなり厳しい。

■そもそもリソースコストの配分が変わりつつある。
さらに言うと、発生コストの負担割合が変わりつつあります。Interopでのセッションでも竹中工務店の方が話していましたが、「現状のDCでは初期投資よりも電力コストの割合の方が増えつつあります」。サーバ・ディスクの単価も下がりつつあるのは周知ですし、NW機器についてのコスト低減も時間の問題でしょう。しかしながら電力コスト（＋結果としての空調コスト）や人件費は、上がることはあっても、下がることはないです。というか確実に上がってます。

従って、とりあえず初期コストが回収できて、あとは「ほっておけばなんとかなる」というスタイルはそもそも、かなり微妙になるでしょう。リソースコストの側面から見ても従前のコストモデルは早晩役に立たなくなります。

■現状のDCのコストモデルはそもそも限界
つまり「ざっくりの投資モデル」というコストモデルは通用しない状況になりつつあります。普通に考えても、現実にこれだけ市場が競争的になれば、打つ手としては、より細かいサービスでしのぎ、細かい「利益」を積み上げて行く方法しかないでしょう。要するにロングテール。いまさら感もありますが。

では、それに合わせたコストモデルや原価計算の仕組みに変えればいいんじゃね？という話ですが、それができれば苦労はないわけです。以下のハードルがあります。それも相当高い。

・制度会計
要は特定のユーザーやアカウント単位でのCostingが必要になります。UsageベースやActivityベースの計算ですね。しかも多層的な構造になります。まともな会計プロフェッションならこの話を聞いた段階で「相当な厄ネタ」と判断するはずです。屍累々。

一般的にいって、というか制度会計的に、DCの主要コストの電気・空調を直接費にカウントするのは相当無理があります。普通に間接費なんで恣意的な配賦計算になります。まぁ要するに適当になります。私見ですが、現状の制度会計、特に原価計算は、DCに限らず一般的に、「現在」の日本企業のビジネスモデルにまったく合っていません。半世紀前の「ものづくり」的な発想が中心であれば、通用するのでしょうが、現在はうまくマッチしません。特に間接費的と直接費の間にある微妙なコスト、一般的な販管費よりもアカウントや製品・サービスに直接結びついて、しかし製造の直接費ほどその連関がはっきりしないコスト、は今後の企業活動では非常に重要なファクターです。が、現在のところ今の日本の原価計算の仕組みは、この手のコストファクターの管理にはかなり辛い。

つまり、DCのコストモデルを見直す、と言ったところで現行の会計の仕組みは何もしてくれません。つまり自分で一から考える必要があります。むしろ役に立たない制度会計が強制されている分だけ厄介です。

・ハード環境
ActivityベースやUsageベースの考え方が敬遠されてきた直接の原因は、データ取得の運用の困難さです。継続してコスト・ドライバーの動きが計測できない、またはそのデータの取得にコストがかかり過ぎる。結果、発生コストの配分ができず、勢い適当な基準になってしまいます。この対応策は、ある程度のデータ収集の自動化なのですが、当然ハードコストがかかります。また仕組みを構築する必要があります。

・ソフト環境
仮にこの手のActivityやUsageのデータがとれたとしても、普通に相当のデータ量になります。DCだと要するにトラフィックや電力のトランザクションデータですが、普通に「おい、ちょっと待て。それそんな簡単な話ではない」というのが相場でしょう。

要するに「本当のビックデータ（PCとかUSBメモリーとか俺のスマホに入らない）」になります。この手のデータを業務システムで扱うのは、ある程度の仕組みが必要ですが、そんなものはその辺に転がっているものではありません。マスコミ・コンサル各位のビッグデータ→統計分析→”データサイズは関係ない”という矮小化の結果、今の日本のITでは「普通のビックデータ」を処理する基盤・技術・ノウハウがたまらないという皮相的な状況になってしまっています。要するに環境や運用技術が一般的ではない。

・アプリケーション
そしてこれもないですね。コストモデルの実装がない。簡単に言うと多重的なコストツリー（ってそもそも末端のノードから見て、親が複数ある段階で「ツリー」じゃなくて、もっと複雑な別の何かですね。まぁDAGはDAGなんですが。循環とかないので。）なのですが、現状のRDBMSベースで構築すると、よほどうまく設計して実装しないと、奇妙奇天烈な巨大SQLのカタマリになり、ウンともスンともいいません。普通にSI屋に頼むと目玉飛び出る見積もりに加えて、なんか動くのかそれは？的なものができあがります。

・文化
そして実は一番大きなハードルは、たぶんこれです。「そんな細かい原価計算とかしても、仕方がないじゃん。要は投資が回収できていればいいだろ。それだけの話」という「ざっくり文化」です。これは相当強いと思われます。これによりコストモデルの変更ができない。

そして実は現状の日本のDCビジネスが根本的にクラウドになっていない理由もここにあります。要するにですね。発想が土建屋です。徹頭徹尾。特にマネージメント層に顕著に見えます。個々のお客さんにサービス要素と様々コストスキームの組み合わせを適用して、収益なり利益を稼ぐ、というのはサービス・ビジネスの基本です。「とりあえず投資して、頭数で割ればいい」ってのはですね。サービス・ビジネスではないです。この辺から切り替えていかないと厳しい。逆にここが切り替わるといろいろと打つ手が出てくる。上記の環境や手段の話は、この文化の問題に比べれば、大きな問題ではないですね。

■解決策
以上の解決策は課題が明快な分、実は自明です。簡単に言うとサービスベースに見合う、コストモデルを作って、必要なデータ収集・計算環境をつくって、マネージメントレベルでちゃんと運用しろ、ってことです。それだけの話です。あとは手段の問題でしかないです。

情報収集については、最近はbuilding management systemは相当に優秀ですし、トラフィック・データの収集はそれこそプロレベルの人も多い。分析環境もHadoopならなんやらのおかげで実行可能になっています。あとはコストモデルの設計ですが、これはそのDCビジネスのエース級を当てれば、なんとかなります。（なるはずです。いずれにしろSI屋さんはダメっすね。無理です。）

実際のアーキテクチャとかコストモデルとか、実装とか運用とかいろいろ書けばキリがないのですが、ざっくりの背景や大枠は以上の感じです。（これから先は、各Prjの詳細にどうしても触れざる得ないので割愛）

■本当にDCビジネスはスケールメリットのビジネスなのか？
とまぁ最後に、現在個人的に思うところとして、一般に言われる「DCビジネスはスケールメリットのビジネスである」のテーゼにはちょっと疑義を感じます。確かにこれは真実だと思いますが、それほど自明でしょうか？

これは前提にDCでのスケールメリットが特定の企業に寡占され、しかもそのコストメリットがビジネスに対して支配的であることがあります。私見ですが、それほど市場は単純に見えません。まず、スケールメリットの寡占ですが、この手のIT技術は見ている限り常にビジネス的にはカウンターバランスが働きます。少なくとも「圧倒的」というレンジには届かないと思います。というか、メリットの享受はフォロワーにも必ずあるはずです。

さらに、スケールメリットにより発生するコストメリットが支配的という前提も崩れつつあります。要するに電力・エネルギーのコストの問題。これは規模のメリットはあるにはあるのですが、それほど寡占優位ではないです。

要するにそれほど単純には見えません。にもかかわらず、卑近の例だと、日本でのDCビジネスについては、確かにAWSあたりが圧勝の勢いです。果たしてこれは「DCビジネスはスケールメリットのビジネスである」ということの証左なのでしょうか？

なんとなく感じるのは、・・・日本のDCビジネスを仕切っている「土建屋気質」そのものが問題のように感じます。日本勢は打つべき手が打てていない。その根っこの部分は、文化的なものを感じます。どんなビジネスモデルにもその裏側には、表には出ない、しかしはっきりとしたコストモデルがあります。現状の日本のDCビジネスのコストモデルが、旧態依然とした土建屋的なものであれば、クラウド的なサービスを取り繕ったところで、それは限界があるでしょう。手を打つべきは、仮想化やコンテナといった表面的な技術ではなく、根っこにある「基本的なビジョン」にあるような気がします。

そんな感じ。

エンタープライズという言葉に意味はあるのか？

「エンタープライズ」という言葉

IT業界では、一応、「エンタープライズ」という言い方があります。残念ながら明確な定義がありません。自分は「一般企業の業務系システムのIT」に対応する言い方だと思っています。大抵はこの意味で通じます。が、これでは漠然としすぎていて定義としては役に立ちません。現実の用例としては、対比的に用いられることが多く、ありがちの用法としては、特にWeb系と対比して、よりしっかりやっているとか、より硬派な仕組みを作っているとか、よりまともな産業に属しているとか、そんなニュアンスで使われます。まぁ、特に品質あたりではよく言われる言葉ですね。「それエンタープライズじゃ通用しない。」マスコミや特に雑誌でよく使われる言葉でもあります。明確な定義があることはほぼありません。

さらに、よく聞く言い方で「エンタープライズでも使われてます」という言い方があります。特にWeb系での利用がメインだった製品やサービスが、より「ミッションクリティカル」な仕組みでも使われてます、と強調したいときに使う決まり文句でもあります。大抵の場合は、ある製品やサービスが一般企業の業務系システムの市場に参入するときのセールストークで使われます。まぁ現実には「エンタープライズでも使われてます」という言い方は、「まだエンタープライズでは使われていない」ということと同義であることが多いのですが。

「エンタープライズ」という言葉に良く似た用法で思い出すが、以前某ファイナンス系外資で働いていた時に言われた言葉で「俺はニューヨークから来た」という台詞です。これは面白くて、ニューヨークからニューヨーク外に来た人間が大抵使う台詞のひとつです。もともとニューヨーク出身じゃない人間が、ニューヨークに一回転身して、こちらに戻ってきても、同じ事を言う訳です。「俺はニューヨークから来た。」だからどうした？って感じなんですが、なんやら、ニューヨークから来ただけエライ、ということが言いたいらしい。なにを言ってるんだお前わ、って周りはそう見る訳ですが、本人はとにかく言わないと気がすまない。まぁ、「エンタープライズ」にも残念ながらそのような匂いがするわけです。

ええっとですね。「エンタープライズ」って言い方は、実はITベンダーだけなんですよ。ユーザーでは「自分、エンタープライズなんで」とか絶対言いません（もちろん、例外はいくらでもありますが）。なぜかというとずっとエンタープライズで、これからもエンタープライズだからですね。要するに言う意味がない。口に出すだけの価値がないわけです。ずっとそこにいる人にとっては、その場所を強調することは、普通に違和感があるわけです。ニューヨークでずっと仕事をしている人が、「俺はニューヨークから来た」なんて言わないと同じです。要するによくわからんアイデンティティに使われる言葉に似てます。

さらに、ぶっちゃけて言うと、「エンタープライズ」という言葉は一種のカウンターカルチャーに対する自己防衛的な言葉になっていることも多い。

「エンタープライズ」という言葉の裏側

この「エンタープライズ」という言葉の裏側には、現実には、エンプラ系IT屋とWeb系IT屋の不毛なすれ違いを見てとることができます。

片や「俺たちはいつも技術のトップを行っている。OSS最高。SI屋のような理不尽な組織にへつらうことなく、自由にやっているぜ的な」自画自賛モードがありつつも、品質あたりは適当で「テスト？いやユーザーがやってくれんじゃん。とりあえず公開しちゃえサービス」の現実や、「そもそもそのOSSがまともになっているのは、いろんな“エンプラ企業”が金だしているから(ry」な現実には、あえて目をつぶる傾向があります。んで、最後には、「エンタープライズでも使われてます」とか言う。うむぅう・・・

片や「品質優先、最後は信頼性でしょ。確実に使われるものこそ、真に残るわけです。ITは遊びじゃないすよ」といいつつも、先端的な技術は常にWeb系からおこっているという現実や、個々人の能力でみると、間違いなくWeb系の方が技術力が高いという現実、品質優先といいつつも最後はデスマの力技の押し込みが当たり前という現実には目をつぶっているわけです。そんなにエンプラすげーのか、そんなにエンプラは品質重視なのか、と問われれば、やらないよりはましというのが現実で、本当に品質に相当のコストを最初から振っているプロジェクトの方が圧倒的に少数派というのは、言われなくてもわかっているのが普通です。最後の言い訳では、「少なくとも俺個人は品質を重視してる」というプライドだけです。うむぅう・・・

ま、要するにどっちもどっちなんですが、そーゆー狭間にいる言葉が「エンタープライズ」という「言い方」になっています。一昔前のスーツとギークという手垢にまみれすぎた言葉がありますが、この言葉の現代の亡霊を「エンタープライズ」言葉の響きの中にみてとれます。

似非マーケティングワードとしての「エンタープライズ」

その一方で、現状では「エンタープライズ」という言葉は、IT系のいわゆるバズワードのベースになっています。その意味ではマーケティングの言葉として、中身がスカスカのまま、利用するのは確かに「有り」ではあります。”ビッグデータ”とか”リアルタイム”とか”データ・サイエンテイスト“とかと同列ですね。中身のないキャッチーなゆるふわ言葉ほど使い勝手のよいものはないですからね。もうまったく無意味。

そんなわけで、この「エンタープライズ」って言葉はあんまり意味ないよね〜って平生から思っているわけです。まぁ商売上のセールストークとして、エンタープライズという言い方は自分でもしますが、ぶっちゃけ自分で言っててその都度違和感は感じます。「エンタープライズ。」・・自分、ユーザー身分だったときに、「ITの人」から、「エンタープライズ」なんてはじめて言葉を聞いたときには、一瞬、某米国のSF番組の宇宙戦艦イメージしましたから。おぉシールド張って、フェイザーでも飛ばすんかい。

自己のアイデンティティを示すのに、内輪ネタでかつ、割といい加減な言葉を使いだしたときは、かなり自己崩壊が進んでおるなという感覚はあるわけです。まぁエンタープライズ業界な自分らは、いろいろ自覚した方がいいわね、と思う訳です。

とはいえ

まぁ仮に無理矢理、エンタープライズという言葉に肯定的な意味づけをするのであれば、「ミッション・クリティカル」なシステムにも耐えうる品質という意味でしょう。実際には「エンタープライズな」という形容詞を使ったときに、それほどの品質に足るシステムなりサービスなのか、というとなかなか疑問ではありますが・・なので、恥ずかしくも、自ら「エンタープライズ」と自称するのであれば、それ相応の品質基準で自らを律するぐらいの心構えは欲しいですね。でなければ、「エンタープライズ」は単なる中身のないマーケティングワードか、自分のプライドを飾り立てる虚勢の言葉にしかなりません。この辺は自戒も込めて思います。

以下余談ですが・・
んじゃーエンタープライズってのをまともな英語で言ったらどーなのよ？ってのはあると思いますが、自分がいいなと思った言葉はindustrial-strengthです。日本語にするとまったく通じませんが。こっちの方がニュアンスは伝わります。普通に「industrial」っていう言い方もいいと思います。とはいえ、「俺たち、インダルトリアル」なんて言うと、コナンに出てくるアレっぽい感じで、・・・ま、それはそれで合っているというか、なんというか。・・結局、俺たちエンタープライズ、なんでしょうかね。とほほ〜。

ま、閑話休題。

2014年のSIビジネスとかそのあたり

というわけで2014年に突入ですが・・・

景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。

とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減（または横ばい）というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よくわからないシステム」の赤字案件が急増する感じです。その兆候はいろいろ出始めています。

案件獲得については、いろいろとリスクチェックの仕組みが各SI屋さんには当然あるとは思いますが、金を積まれればやらざるを得ないわけです。やってみたらハマッタなんてのは、よくある話です。景気も良くなれば営業サイドもがんばります。そんな感じで「いろいろと無理があるぞ」プロジェクトが量産されます。というか、されています。その辺に結構転がってるし。いや、まじで。

まぁ人がいないわけです。特にできる人材不足が顕著です。これは一つは、技術的に検討することが増えていることが原因のひとつです。まぁとにかくやらなければいけないことは増加の一方ですからね。もう一つはそもそもの若手不足です。全日本的な人口減のボディーブローが効き始めてます。

本来的に言えば、ユーザーサイドである程度自衛策的に内製化的な動きをやっておくべきでしたが、残念ながら時間切れな感じです。この景気の上方回帰の流れの中で、システム投資はやれるときにやっておけ圧力が強くなりますが、とはいえ人員強化ほどの強烈なトレンドにはなりません。よって、ユーザーサイドではSI屋依存が、残念ながら強化されます。SIサイドも強い引き合いは久しぶりの機会なので、頑張って案件は取りにいくでしょう。表面上の需給バランスの一致はマーケットメイクをより強固にします。そして、この流れは、いろいろな問題を完全に先送りします。

他方、現場を見てみれば、このような状態になってくると、なかなかリスクのある新技術は採用したくないのが人情です。「だって、回らないプロジェクトさらに回らなくしてどーすんのよ」的なPMの愚痴モード全開です。案件の数だけは増えますからね。

腕のあるPMにしてみれば、今時のクラウド技術やら新技術とやら試しておきたいのが本音でしょう。SI屋自身のR&Dはほぼ削減の一直線のなか、エンジニア的には自力救済的に自分の技術力を上げておかないとまずいです。特に、今後の「新技術」はトレンド見る限り、クラウド方面からしか出てきません。ということは、クラウドの主戦場が分散処理に移っている以上、新しい技術トレンドは分散処理がベースになってきます。これをSIで利用する、というのは相当ハードルが高いというか、無理がかなりあります。というか無理ですよ。普通のSIですら回らないのが現状です。

さて、割とデッドロックな感じのSI所属や業務系のエンジニアはどうするのか？というのがたぶん今後の話題になります。というか、既に各所でなっているみたい。見切りをつけて某携帯ゲームさんに鞍替えした方々は、途端に土砂降り状態で手持ちの傘がないという状態のようですし。

んで、どーすんだって話しなんですが・・・まぁ実も蓋もないのですが、見ていて思うのは、結論的には「転職含めて進路をじっくり考える」機会到来かなと思います。お前が言うな、って話はあるんですが、新年なんで書いていいかと。

予想ではありますが、今後5年は国内のエンジニアは転職のチャンスだと思います。おそらくここ20年で一番の機会ではないかと。主として理由は以下です。なお、行く先どこよ、って話ですが、まずは回復基調にあるユーザー企業さんになるでしょう。

1.景気の上向き時は人・もの・金が動くので、転職自体がしやすくなる。これは異論はないと思います。選択肢が単純に増えます。

2.SI限界を目の当たりにしたユーザー企業の自衛策も（それなりに）出てくる。良質SIの減少はまさに、悪貨は良貨を駆逐するがごとく不良案件が増大してきます。自社体制の増強は各ユーザー企業にとっても焦眉の急です。ある程度内製化を考えるところでは人を取り始めるでしょう。（まぁそう簡単にうまく行かないと思いますが・・）

3.ユーザー企業自体の統合が進むので、IT部門の強化や投資需要が増大し、人員許容のキャパが増える。今後の景気回復は、特に労働集約的産業でのM&Aを加速させます。人手が足らないという流れは、間違いなく賃金上昇圧力になり、そのまま人件費の高止まりどころか上昇になります。各企業は、その賃金上昇に見合うだけの労働生産性の向上が必要になりますが、これは当然投資余力があるところに限定されます。要するに、なんとかぎりぎりなところは、「注文はくるが、その量とそのコストでは捌ききれない」という状態になります。結果、業界のトップエンドがどんどん成長するが、二位以下は突き放されるという結果になるでしょう。当然の結果としてM&Aが進みます。これは情報システム部門の統合にそのままつながります。トップエンドでは人員の増強に入るでしょう。（統合された方は必要な人材を残してリストラ対象）

そんなわけで、人は動く時期が来るかなとは思います。では、今後の方向性として、どう考えればよいか？ということですが・・・

■完全安定志向の人
えっとですね。この場合は、移動不可です。SI屋に張りついてどう生き残るか？に徹するべきです。ただし、基本的にじり貧は覚悟すべきです。消費税は上がります。実質可処分所得は減少します。また、管理職以上のポストは老年層の独占になり、結果、出世と給与の上昇はきわめて厳しいです。しかしながら、SI市場はデスマが増加するとはいえ、マーケットとしては強固ですのでそれはそのまま残ります。そのレベルでの生活は保証されるでしょう。土方で頑張る。デスマで生きる。これも人生です。職業に貴賎なし。ローリスク・ローリターン。余計な邪魔はしないでください。これも選択です。

■ある程度リスクは仕方がないという人
ハイリスク・ハイリターンとか、ローリスク・ローリターンだと普通に死ぬので、ミドルリスク・ミドルリターンな人。まぁこんなご時世です。リスクフリーが一番良いけど、そんなこと言っても、ないものねだりですし。
こういう場合は、各マーケットのトップエンドに近いユーザー企業あたりが一番いいと思います。市場は広がってくるかなと思います。ただ、特にユーザー企業に軸足を移す、という人は老婆心ながら以下に留意された方がよいかと。

1.エージェントは使わず、自分でちゃんと探すこと。
エージェントは使っても情報収集程度にする。必ず自分の手で「十分に調べる」ことが重要です。会社の雰囲気。トップや経営陣の資質。情報システム部の評判。時間はかけて構いません。最悪数年は調査にかかる位の気持ちが必要です。焦る必要はないと思います。「従業員をちゃんと採用します。」というところと話を継続的にすべきです。特にユーザー企業に移るのであれば、とにかく調べるというスタンスが大事です。

2.中規模以下の企業に行くときにはそれなりの理由が必要。
上記のように、中途半端な立ち位置の企業は、トップエンドに近い将来吸収されます。転職先がいきなり吸収・合併されて、速攻で追い出されましたでは立つ瀬がまったくありません。今後の5年は今まで以上に凄い勢いで「惰性で生きてきた」企業は姿を消すでしょう。強いアゲインストや、強いフォローの風では企業の経営の巧拙は、顕在化しません。「若干フォロー」という状況は企業のスタンスがまともに差にでます。しかしながら、敢えて自ら中小企業＋業界で随一のものがある、ところは別です。それは別に考えた方がいいですね。こういうところのITはそれはそれで面白いので、選択肢としては考えるべきでしょう。

3.朝ちゃんと起きるということができるようになっておくこと。
これ実はエンジニアにはハードル激高いというのは現実ですが・・まぁユーザー企業で働くには普通にできないといけません。転職時には気力・体力が削られますので、朝早く起きてジョギングでもして、体力をあげておくということもよろしいかと。まぁ、大抵のエンジニアの方はこの辺でアウトですが・・・単純に「郷に入りては郷に従え」ってだけです。

4.当たり前ですが「自分に投資しておくこと」が今まで以上に重要。
当たり前ですが、「自分を売りに出す」ということは「自分の売りものはなにか」ということを明確にすることになります。ユーザー企業に行って自分は何ができるのか？気がついたら、外注管理とパワポ・ワード職人でしたって人はやはり厳しい。とにかく、手を動かすようにしておく。PMになってくるとパワポやワードはうまくなりますが、あっと言う間に手が動かなくなります。コンサル系の仕事は、よほどその業界の事情に詳しくない限り、ユーザー企業に移った段階でSI屋叩きの仕事専従になります。

お勧め案は
・とりあえずクラウドが使えるようになっておく。これは便利。
・簡単な数学ぐらいはマスターしておく。別にデータサイエンティストとかイラン。
・要件をどう切り出すかの手法は自分なりの方法を確立しておく。
・運用でヤバイところはどの辺かアタリがつくぐらいの経験は積んでおく。
・せめてjavaと普通のSQLは使えるようになっていてください。お願いします。

趣味みたいなプログラミング言語とかマスターせんでいいから、上の内容を押さえておけば、来てくれというユーザーはたくさんありますよ。すげー、あります。

■一攫千金の人
ハイリスク・ハイリターンですよ。え、なんでSI屋にいるのかって？それはトレーニングとノウハウの吸収ですよ。捲土重来・虎視眈々、機会を見て旗揚げですよ。という人は、まず上場しそう会社に潜り込んでください。すげー増えてるみたいです。（遠い目
運が良ければストックオプションでウハウハです。また、その他にもいろいろわかると思います。正直、（自分の立場は置いておいて）いきなりの起業はお勧めではないです。先の起業まで考えている人は、まずは転職先で、できれば営業をやってみてください。如何に自分や周りがいままで看板で食えていたかわかります。その上でどうするか考えるべきです。

まぁなんというか、デスマ警報を逃さないようにしつつ、いろいろ調べてみっか、という季節になりそうですね。自分的に他人に転職指導とかしている場合じゃないのですが、某雑誌にお先真っ暗なエッセイとか書いてしまったので、そのフォローでございます。どうぞご自愛ください。

AsakusaはなぜAsakusaというのか

このエントリーは、Asakusaアドベントカレンダーの24日目ですね。
http://www.adventar.org/calendars/200

いろいろ各所で聞かれる内容であるので、一応、非公式記録として残しておきます。諸説あってどれが本当か、もはや今となっては記憶も定かではないわけです。

前提）Asakusa系の名前は、放っておくと勝手に開発者のTwitterのアカウント名がつけられて相当ヤバイことになる。

Asakusaの開発でもっとも工数がかかるのが名前付けであります。（誇張なし。）これは理由は簡単で、命名は大抵は合議制なんですが、あんまり関わりはしないのに「いや、その名前だけは許せん」という発言者が多いということと、実際、かなりイマイチな名前が最初はつけられることが多いためです。結果、工数がかかる。

(ただし、中の人の性格がきわめてひねくれている人が多いので、アレ系の場合は、瞬発で決まりますね。例えば、Monkeyなんとかがいろいろとアレだったので、その代わりに作られたJenkinsでのジョブ管理Plug-inが「Monkins」という名前になったわけですが。体感で5秒ぐらいで決まった気がします。これはひどい。)

まぁ、いずれにしろ、ネーミングはもめるので、時間切れの場合は、その方のTwitterのアカウント名がプロダクト名になることが決まっているわけです。んで、そのままだと某御徒町方面になりそうな感じもあったのですが、いや、それは待て、ということでAsakusaに決まったわけです。（時間切れの例はAshigelコンパイラ）

んで、由来ね。

通説多数説）
1.とりあえず一般（ユーザー部門とか、一部海外とか）受けしそうな名前にしてみた。これは全日本的にですが、なるべく覚えてもらえる名前、というのはいろいろ便利ではあります。「浅草」という地名を知らない日本人は多分いないし、外人でも知っている人は知っていると思われるので、そのあたりを狙ってみた。これは実際にはそこそこに成功しており、海外はともかく、国内では、開発元のノーチラスは知らなくても、Asakusaという名前は（中身はわかんないけど）聞いた事がある、という感じでは人がちょくちょくいたりします。

2.Aで始まる
ABC順・あいうえお順で頭にくるというのは、アピール度合いでは、かなり有効である、というのは昔から聞く話ではあります。ので、「A」または「あ」で始まる名前を命名しました。対抗は実は、Akasakaでして、こちらは前から読んでもAkasaka 後ろから読んでもAkasakaというアピールポイントもあるので、捨てがいたいものがあります。とまれ、「A」または「あ」で始まる名前に一般に目立ちます。

3.そもそも地名は商標上トラブルにならない
地名は商標登録できません。はい。よって、逆手にとってトラブルになりにくいということになります。誰も登録できないので、もめ事になりにくい（例外はなんかあるようですが。ナイヤガラなんとかとか）ので、事前にそのあたりを回避するという作戦をとったりしてます。ただし、これは諸刃の剣で、SEO対策としては最悪に近い。一般にAsakusaはググらビリィティが低いと言われますが、それはそーです。普通にAsakusaでググれば、「浅草」がヒットしますわ。この辺は痛し痒しかと。

4.関連商材が多いので、割とサブプロジェクトの命名が楽
浅草は観光名所ですので周りにいろいろあるわけで、そのあたりがいろいろ関連プロジェクトの命名の、もとネタを考える時に結構楽だということがあります。実際、Asakusaの入出力管理は、浅草への入り口ということで、雷門から取っています。すなわちThunder Gate。んで、雷門の守護神が風神・雷神なので、Thunder Gate/ Wind Gateがサブモジュールとしてあります。あとは、インストーラーとして、Jinrikisha（人力車）がありますね。今後も、人形焼き・花屋敷・スカイツリー・仲見世とかいろいろあるので、それなりに命名を考えるときは便利です。

少数有力説）
1.首謀者が単にその近所に住んでいる
首謀者の某御徒町方面が、上野・浅草・御徒町方面に、かなり長く住んでいるので、そのあたりの愛着もあるということのようですね。この界隈はまぁとにかくいろんなものがあるので・・・フルスタックフレームワークとしても、ちょうどいいかと。業務系ITは、理屈で割り切れるものではなく、それなりに関わった人の匂いがするものです。なので、Asakusaという名前は、その対象から考えてもなかなかマッチしている気がしますね。
どうでもいいですが、浅草は日本で唯一毎日寄席をやっている場所でもあります。落語の噺は、いろいろとアナログ的な利用ができるので、IT屋的にも覚えておくといいです。オブジェクトの等価性と粗忽長屋とか。

2.Hadoop関係の飲み会が浅草近辺で多かった
うむ。これはまぁ仕方がないですね。以前のHadoop大忘年会とやらも浅草「米久」でしたし、中年Hadoop愚連隊（成員は内緒）の地獄の焼き肉大会とかもAsakusaだったりして、気がついたら浅草ビューホテルの地下のバーで、飲み過ぎて終電なくなっちまいました的なアレも多かった感じです。まぁ必然かと。

以上、どうでもよいネタでしたが、Asakusa今後ともよろしくお願いします。

ノーチラス二年目終了して三年目へ

二年経過したので記録として置いておく感じで。

ということで気がついたら設立から二年経過していました。正直、まだ二年しか経過していないのか、という感じがします。この一年は二年分ぐらいの時間感覚でした。まじで時間経過が速すぎて死ぬかと思った。去年の今頃はAsakusaの立ち上げで、特にSI屋向けのサポートに力を入れていた時分で、今と状況がまるで違う状況でした。この一年では大きな試行錯誤を二回ほどやった感じになっていて、現在ではAsakusaの向こう側の違う方向性の模索し始めているところです。

大きな方向性としては、この一年で以下が大きく違ってきていると思います。

1.クラウド・コミットが普通になってきた、とはいえ、一方でまだまだというところも実情。元々クラウド上で構築や作業や環境の獲得は普通にやってきましたが、やはり、春先の西鉄ストアさんの基幹業務系をAWSで動かしたというのは、それなりのインパクトがあったと思います。日本でのファーストケースになった実績という対外的な意味もありますが、社内的には「AWS？いや別に業務系で普通に使えるけど？」という感覚になっています。（社内にいると普通に常識になっているけど、この感じは日本ではまだまだ多分特殊だと思います。）

一方で、日本での業務系のクラウド受容はまだまだ、という感じも受けています。まずは文化的な問題が一番大きいでしょう。「クラウドを使わない」という選択は、本来的にはクラウド固有のメリット・デメリットを把握しつつ、いろいろ試行錯誤した結果としての、積極的な非選択という形が望ましい（おそらく海外ではそういった流れになっていると思う）のですが、日本では、触りもしないで評論・敬遠する人も未だにおおいのが実態です。ただ、今後はクラウドを実際に体感した上で、「選択しない」という方向も出てくるでしょう。いろいろ体感した上での選択と、評論家的な選択では意味はまるで違うのですが、表面上は同じに見えてしまうな、と思っています。あまり良いことではないですね。

可用性の強化や運用負担のコストの低減、ソフトウェアをハード環境から引き剥がすことによるライフサイクルの管理強化等、業務システムのクラウド化は相当のメリットはあるわけですが、そこまで進むのはまだまだですね。ということがよくわかる一年ではありました。

クラウド化については、今後はどうなるかはちょっと不透明だなと思っています。クラウドのメリットは非常に大きいけど、その一方で、サポート問題も含めて業務系で使うには、それなりの課題があるのも事実です。大規模業務で使いこなすには技量と経験が必要でしょう。

2.ユーザーさんの試行錯誤のコストが異様に高いこともわかってきた
これは間違いなくユーザーさんのIT部門の弱体化が原因だと思います。SI屋さん以上に、ユーザー側の弱体化のほうが致命的になりつつあるな、という感じがします。正直、人を削りすぎた後遺症が発生している感じです。先に向けての試行錯誤ができていません。

スタッフ部門の役割はバックエンドの事務処理ではありません。フロントとは別の視点からビジネスを俯瞰して、会社の戦略・戦術案を経営層に提示することが仕事であるはずです。これはIT・物流・人事・調達すべてにおいてそうなるはずなのですが、全般的に人手が足りなくて機能不全になりつつあります。まわすので精一杯という感じです。

人員削減の埋め合わせとして期待したSI屋さんへのアウトソーシングも、SI屋さん自身の技術向上の劣化がキャップになり、ただの人員派遣になりつつあります。アウトソーシングは、ソーシングがなくなってしまって、ただのアウトだろ・・というところもあります。

スタッフ部門の人員不足は、以前はリストラ的な意味合いでの積極的な人員削減がベースにあったのですが、最近はむしろ、優秀な若年就労層の縮小で、そもそも補充が効かなくなっている気がします。ユーザーサイドでは、この現状について有効な手を打てていないどころか、問題として認識すらしていないところもあり、先はなかなかに厳しいでしょう。

僕らのようなエンタープライズで勝負しているベンチャーは、このあたりの状況には積極的に対応していかないとまずいわけですが・・・いままでもこれからもこれは課題だと思います。

3.ビッグデータの「次」がポイントになってきた。本来、Asakusa等は「ビッグデータ」とは違うドメインにいるわけですが、プラットフォームとしてHadoopを利用している手前、どうしても「ビッグデータ」ブームの流れには巻き込まれてしまいます。場違い的に呼ばれることもしばしばありましたし、今もあります。とはいえ、分散環境の普及は自分らにとっても歓迎すべきことではあるので、一応距離を取りながらフォローしているという状況です。んで、この一年を見てみると、かなり進み方が変わったな〜と思います。

現状の「ビッグデータビジネス」は、世の中で期待されるサイズには届かない一方で、そこそこビジネスになっているところもあるね、という一年だった気がします。従来のCRMや分析的なマーケットよりは、確実に拡大しているけど、少なくとも二倍以上にはなっている感じはしません。いわんや、マスコミの方が言われるマーケットサイズにはまったく届いていません。うまくマネタイズしているところもある一方、まったくお金にできてないところも多いです。なんとかビジネスになっております、というぐらいが関の山でしょう。

全体の傾向としては、「もっとデータをちゃんと使った方がいいわね」という非常に当たり前の結論が、当たり前になってきているところが、ここ一年で確実に違ってきている点だと思います。ただし、この「データをちゃんと使いましょう」という発想は従来からもあったわけでして。それがうまく回らなかった理由は様々にあったわけですが、その反省はされていません。なので、また肝心なところで詰まる可能性は高いと思うし、実際詰まっていますね。

現在のビッグデータの利用での成功は、かなり限定的でリコメンデーションや不正検出のフィールド等の一定のドメインに限られていると思います。これらが成功している理由は簡単で、サービスのデリバリーに「不必要に人間の介入がない」からだと思います。データを利用した業務向上は、データ分析の結果をどのように業務に反映させるか、という点が大切です。これは40年間変わっていません。このためには、携わる人間のマインドセットを変える必要があり、これは非常に難易度が高い。

データをちゃんと見ましょうということを業務に活かすのであれば、現場、管理職、経営上位層のすべての階層にわたってマインドセットを変えていく必要があり、統計解析ができる人間をそろえればよい、という話ではまったくありません。ビッグデータ系のIT屋・コンサル・評論家・書籍・データサイエンティストな人たちを見ていると、意図的に、この「マインドセットを変える」という論点を避けているように見えます。曰く「それはユーザーさんの仕事です。」それができれば苦労はないです。

そもそもビッグデータに限らず、なんらかの業務メリットをとるために、関わる人間のマインドセットを変える必要があるIT技術は、導入にハードルが高いのが相場です。その上、中間管理職が壮年層から老年層に移りつつあり日本では、「マインドセットを変える」コストはさらに天井知らずです。なおさら導入が困難なのが実態でしょう。

要するに今の路線ではうまく行きません、ということも明確になったと思います。とはいえ、データを利用していきましょうという機運はあるわけで、また成功している事案もないわけではない。観点もそれなりにある。よって「ビジネスにするには、何がまずくて、どうすればよいか？」を模索していく段階になっていると思います。まぁ次の一手を考えましょう、とそんな感じかと思いますので、この辺は横目に睨みながらいろいろ考えるというのが今後ですね。

4.次に向かっていかないといけませんね。んで、3年目のノーチラスはどーすんだ、という話ですがAsakusa-Hadoopはそれはそのまま拡大路線は続けていきます。ユーザーさんも確実に増えていますし、「ま、バッチ処理時間は短いにこした事はないし、確かに分散させればそれは速いよ」という結論は出たと思います。これはこれでいいと思います。

Asakusa-Hadoopの導入だと「分散環境を準備するための、まず環境コストが高い」という課題があったため、ここ半年ぐらいは、Asakusaの実行環境としてのクラウドを開発、提供してきました。んで、そのフィードバックとして前述のように業務系のクラウド移行が事前の想定よりもなかなかハードルが高いということも見えてきているので、オンプレ・クラウドの両者を見ていく必要があるな、と今はそういう感じです。

それに加えてもっと「ユーザーよりの方向」に進めて行きたいと思っています。もともとそちらが自分の得意なフィールドではあったので、そちらに軸を打つ方向で次の年は進めたいと思っています。個人的には業務系処理で重要なのは「データ量」ではなくて、「計算量」だとおもっているので、ちょっと現在のビッグデータ的な流れとは違う目線で進みたいなと・・「分散処理を業務に利用するとこんなこともできますよ」ってのを出せればいいな、と思っています。

　例によって一緒にやっているメンバーとは
「こんなんあるとオレ的に画期的だけど、どう思う？」
「オレ的に画期的の意味がよくわかりませんが・・・それができればそれはそうでしょ」
「技術的にはギリできそうな気がするけどw」
「技術的にはギリ無理そうな気がしますがw」
なんて会話しながら３年目に突入してます。

いろいろやり方が試行錯誤できるのがいいところなので、そんな感じです。この試行錯誤も「もっと早くやれ」とか「もうちょっと様子見ろ」とかいろいろ意見がありまして。このあたりは・・まぁ苦労しています。いやはや。まずは体調第一で。

というわけで3年目なので、今後とも宜しくお願い申し上げます。

業務系システムのクラウド適用の現状

2013年の夏・秋の状況の整理として記録しておきます。数年したら変わっているか、そもそも自分の仮説が違うかわかるのでそのポイントとしても記述しておきます。

4月以降、「業務系システムのクラウド化」ということで、顧客各社やマーケットへのヒアリングを行ってきています。対象はいわゆるWeb系は除いてあります。曖昧な言い方になりますが一般に「IT業界でエンタープライズ」と言われるセグメントにフォーカスしています。結果としてわかったのは、企業のクラウド利用についての意識は、言われているほどには高くはない、というのが現状です。ただし、これは一様に低い、ということではなく、かなり業界やセグメントや企業規模によって違いがあります。この違いの要因と今後どのようなところに影響するのか、というのが興味の焦点です。尚、これは自分個人の印象や某社でのヒアリングの整理のみをよりどころにしているので、たかだか200社弱程度のサンプルでしかないです。そんなわけで合っているかどうかは各自で勝手に判断してください。

また、クラウド利用については、特に「バックエンドの業務系の仕組み」のクラウド化に絞っています。Web系のフロントの仕組みとしてのクラウド利用については、ここについてはそれほど異論は見受けられません。単純にフロントのサイトだけを立てるという意味ではレンタルサーバーの延長線上（というかほぼ同一）の見方としてクラウドを利用する、というスタイルは普通のユーザー企業で一般的です。

この種のクラウド利用は、エンタープライズ企業においては「とりあえずクラウド対応しておけ」という経営陣のいかにもな指示に現場がとりあえず応えたというものが散見されます。特にB2Cのビジネスに強くコミットしているのでなければ、フロントに対外的な強力なサーバーを立てる必要もないので、とりあえず使ってみたいという要望にはうってつけというものが多いですね。よってその用途で使われるという事になります。また情報システム部経由だと予算や稟議の兼ね合いで社内処理が面倒なので、広報等の部署が費用化できる範囲でアウトソースの一つとして利用しているケースもあります。

いずれにしろここでは、このレベルではクラウドを利用しているとは言わないとします。

企業がクラウドを利用している、という意味では後段のバックエンドの仕組みとして利用しているか、どうかが大きな試金石になります。逆に言うと、バックエンドでクラウドが利用できないのであれば、企業ユースでのクラウド利用はインパクトはあまりないですね。（あくまで個人の意見です）

それで、バックエンドの業務系の仕組みの実行基盤としてクラウドを見た場合ですが、まず企業レベルでそもそも意識がかなり異なります。大手企業においてクラウドに注意を払っていない企業はない、というくらい意識はあるように見えます。実際に「検討はすべきではある」という声も多いです。その一方で中規模会社においては、その存在すらも視野の外、というのも現状です。これは、中規模以下の企業の、情報システム部のそもそも実態がきわめて弱い、ということが原因として大きいです。

[中規模会社以下]
中規模以下の企業については、ヒアリング・営業をした先では、件数として多かったのはERPやパッケージを導入かつ、SI屋に丸投げという状況です。クラウド以前の話として、そもそもIT投資自体も主導権がない、という企業もかなりの確度で散見されています。遠目で見ると、結果として資本装備率が低く、よって労働生産性の向上の余地が少ないように見えます。

本来的には低い資本装備率でも稼働できることがクラウドの一つのメリットなんですが、この前提にはそれを使いこなす人材の存在があります。中小規模企業ではそもそも人材の確保が出来ていません。よって、クラウドでのレバレッジのメリットは、中小規模企業では現状のままでは享受することが難しいという印象です。クラウドにしろ、SaaS（公共系の某SaaSが典型ですが）にしろ、初期コストが不要で、中小規模企業向きというメリットがあると喧伝されていますが、実態としてはその受け皿の中小規模企業は自社の人材のアウトソースをSI屋に丸投げしているため、まったく利用できない形になってしまっているようです。

余談ですが、個人的には、この現状は今後の中小規模の企業の行方の試金石に見えています（もちろん、外れる可能性も大ですが）。日本の産業構造的には、今後の労働市場では就業人口の供給が少なくなることが容易に推定できるため、景気の上向き時には賃金上昇圧力はかかることが想像されます。この場合は中小規模会社では、賃金上昇に見合う生産性向上が本来は必須なのですが、投資余力がなければ対応ができません。たしかにITは投資としては、そのひとつの例にしか過ぎないとは思います。しかし、今後の物流・ITへの投資能力が、各企業の投資余力のリトマス試験紙であることが多いことを考えると、今後の公共投資を中心とした（闇雲の）景気回復はむしろ中小企業にとっては決してプラス要因にはならないでしょう。むしろ、（現状よりもさらに）統合を促すことになるような気がします。逆に言うと、中小規模であってもクラウドを利用するようなレバレッジを効かせられる企業であれば、生き残る機会はあるかもしれません。が、現在はこのような企業は例外でしかない印象です。ま、個人的な印象です。

いずれにしろバックエンドのクラウド化というのは、中規模以下の企業のセグメントでは一部の例外的な扱いになるでしょう。例外的な企業やユースケースをピックアップして、「クラウド化は進んでいます」という声も”いろいろな思惑”から聞こえますが、少なくとも自分らの現場の素直なヒアリングの結果は正反対になっています。

ということでは問題は以下。

[大規模会社]
・大手企業におけるクラウドの位置づけ
セグメントによって大きく異なる、というのが現状のとりあえずの結論ですね。しかもかなり、あからさまに違います。これは各産業の歴史的・文化的な背景が大きいという印象があります。もちろん、ま、社内でも異論はかなりありますが、個人的な経験にも一致する印象なので、それほど間違っている気もしません。

○金融・証券・保険、および社会インフラ系
　ベースとしてクラウドの利用はあまり考えていませんねｗ。勿論例外はありますが、例外に過ぎません。現状では数社程度でしょう。（繰り言になりますがバックエンドでの利用という意味です。フロントエンドでの利用であれば、なんらかの形で利用しているところもそれなりにあります。）それ以外は利用は毛頭考えていない、というのが現状です。

　勿論、当局の規制、という側面はあります。実際、当局サイドの指導がなければ検討したい、というところもあるにはあります。が、では当局がゴーサインを出したとして、積極的に利用するか？ということに関しては疑義が残ります。（実際のところ、当局は明示的かどうかは別としてゴーサインはすでに出しているという話もあります。）

背景はそもそも以下ですね。

・そもそもインフラでは困っていない
　金融・社会インフラをはじめとした規制産業は、例外を除き基本的に保護産業としてスタートしているため、コスト意識が相対的に低いのが現状です。異論は各種あるとは思いますが、少なくとも、後述する流通サービスのセグメントに比べるとその差は残念ながら歴然です。
　したがって、多少のオーバーコストであっても社内にインフラを持つことが可能であり、良くも悪くも、インフラコストが一気に増加しないのであれば、既存のインフラを保持する方向を選択することが最初の選択になります。この点でクラウドの利用は積極的ではありません。

・あくまで自分のコントロール化で情報システムを管理することが責務であるという意識が強い。
　当局が要求する過当競争からの保護の見返りは、社会コストの負担です。その一部は間違いなくすべての顧客をちゃんとサポートしろ、ということに帰着しています。したがって顧客情報・個人情報の維持は企業としての責務であり、情報流失のリスクが最終的に定量化できないクラウドは一義的には敬遠されます。もちろん、セキュリティレベルが自社とクラウドでどちらが高いのか？という第三者的な定量的・定性的な分析では、一概に言えない（むしろクラウドの方がリスクが低い）というオピニオンは出ていますが、自社でリスク管理を行うことが社会的要求という背景がある以上、本来的にクラウドは使いにくいという側面は常につきまといます。
　また、クラウドセキュリティの「セールス・トーク」の大半がワールドワイドでFUD的な印象が強いのも腰が引ける要因に見えます。

○大規模製造業
・そもそもバックエンドに大きな仕組みが必要か？という問題もあります。IT的なバックエンドとして、FA的なものとの一体導入という意味ではERPが非常に浸透しており、同時にSI屋依存も強いです。その点ではバックエンドがクラウド化に進むのか？という問題はERPベンダー依存になっています。もちろん、販社のような組織体を同時に持つようなケースもありますが、この観点からは、後述する流通・サービスにその性格が近いでしょう。

・生産管理的な側面から見ると、ITのあり方としては、「巨大装置産業のデータ処理」という位置づけが強いですね。この場合、そもそもデータ量と処理能力がオンプレミスでまかなえるのか？という話が主軸になります。ここでクラウドの利用についての検討が始まる可能性があります。特にデータの取り扱いは、「よりリアル（というか細粒度と多層化）」というざっくりした方向性がマーケットの要請になってくるため、粒度感はともかくレイヤーリングは従来のようなSCM的な「横のつながり方」ではなく、より上位・下位に多層化し、より複雑化していく可能性があります。この場合は、さすがにオンプレミスでの計算空間ではサポートができません。この分野はまだまだ検討の余地があり、クラウド利用の可能性は高いと思われます。実際にそのような用途でクラウドをちょいちょい試しているという話も聞けてはいます。

ただしこの場合のクラウド要求は、従来とは異なり以下の二要素が求められている気がします。

・インスタント的な要素
収縮性はいらない、Elastic性は必須ではない、ということです。要するにまとめて計算機をある期間貸してくださいよ、とこういう要求に見えます。この場合はなるべくその期間で「いきなりスムーズに」借りられるということが大事ですね。そういうスキームが必要とされているように見えます。現行のクラウドのサービスとはちょっと違う感じです。「大量のレンサバを一気に簡単に借りる」という方向の方がむしろ近い気がします。

・貸しスタジオ的な要素
ある程度のテイラードのサービスをやってちょうだい、というニーズ。これ現行のクラウドと全然違います。ベア・サービスではなく、とはいえフルカスタムでもなく、ASPでもない、なんというか一種の「簡単なSI」なんですけどね。こういうニーズが強いように見えます。現行のSI屋さんだとこれは間接オーバーヘッドが強すぎてコストが合わないのですが、専門のブティック的なところだとうまく回るので、中小のSIがうまく回せるチャンスがある気がします。現行、徐々に中小規模のクラウドSIが頭角を現している現状も背景としてはマッチしてると思います。

○流通サービス
　前述の金融・社会インフラと対照的に、流通・サービスのセグメントの大手企業でのクラウドの積極的な利用は、各産業別に見た場合は群を抜いています。現状の業務系システムのクラウド利用の事例のほぼ80%がこのセグメントに集中しているのは故なきことではありません。確かに表に出ている絶対件数は少ないと思いますが、少なくともクラウド利用に対する抵抗感のなさは異常とすら言えます。

・非常にコストコンシャス
金融等の保護産業とは異なり、流通サービス業はむしろ当局から「規制される産業」であり、今現在もその流れにあります。常に競争に晒されており、また、競争優位になった途端に手足を縛られるということ方が多いのが実態でしょう。結果として、コスト的な余裕はまったく取れない環境におかれているようです。そのため、産業として相対的にコストコンシャスであり、その意味でクラウドへの注目が非常に高いです。曰く「一円でも安く」というカルチャー。コストコンシャスな割にはデータが量が多い、ということもこのセグメントの特徴です。

・使えるモノはなんでも使え
産業的に、使えるモノはなんでも使うという文化も背景にあります。これは過剰競争からの顧客ファーストの発想の延長線上に、手段よりも目的を重視しないとやっていけないという文化があるためです。目的達成のためなら手段の重要性は下がる、というプラグマティックな発想ですね。ま、このため、正直、オンプレとクラウドの区別はまったくしていない、というユーザーもかなりの確度で存在します。金融・社会インフラ業界とは好対照です。

という感じで、各セグメントでのバックエンドのクラウド利用のスタンスは、かなり異なるという印象です。

以下はこういう文化的な差がどうなるか？という個人的な予測です。たぶん外れます。が、こうなる可能性はなくはないです。

・クラウドを技術的な位置づけから見たときに

現状のIT側の新技術はハード・ソフトを含めて、ほぼすべてクラウド・サイドから供給されつつあります。したがって、IT技術へのキャッチアップはクラウド上で発達した技術を自分のモノにするということの延長線上にあります。その意味では、クラウドに親和性のある流通サービスや製造業がIT技術選択の先端に進む可能性もなくはないですね。つまり、現在の各セグメントにおけるIT技術の使い手としての優位性が、従来の金融系・社会インフラ系のセグメントから、流通や製造のセグメントに移る可能性があると思っています。

確かに汎用機・オープン系の採用や検討実績は、間違いなく試験研究のレベルではよりコストをかけられる産業の方が技術優位であることは間違いありません。実際にユーザー・セグメントから見た場合に、ITの先端性は金融・社会インフラ・通信と言った産業が常にリードを取っています。現状のスタッフィングや技術をドライブする能力、評価・実装・維持メンテ能力の人材のトップノッチは、間違いなく、金融をはじめとした社会インフラ系に人材が偏っているのは事実です、これはあと10年は変わらないでしょう。

とはいえ、技術選択・維持の能力は、採用している全体の環境に制限されます。いかに優秀な人材を抱えていても、新技術の発現ドメインに業務として直接コンタクトできないのであれば、総合的な技術力の向上も鈍化します。その意味では、普通に行けば、ITにおける従来の金融・社会インフラ＞製造業・流通サービスの構図というのは変わらないのですが、クラウド技術の利用という点では、この図式は変わる可能性もあると思っています。このあたりのユーザー・セグメントへの勢力図はITセグメントのあり方にも一石を投じるかもしれません。

こんな印象を漠然ともっています。今後どうなるかですね。・・・

・・・・・・・・・・

以上は、実は現行のクラウドとオンプレミスのあり方の構造が大きく変わらない、という前提での観察なのですが、この話とは別に“オンプレミス”の位置づけが「対クラウド」という意味で変わってくるかもしれないな、と最近思っています。

「今のところの新技術」は残念ながらクラウドからしか出てきていないということで、クラウドベンダーの技術優位がはっきりしているのは間違いないのですが、これは実は例外があってユーザーそれ自身がクラウド的なものを“オンプレミス”で実装し始めるということになると話は全然変わる、と思っています。えっと、誤解のないように言っておきますが、これはいわゆる“プライベード・クラウド”と今言われているものではないです。まったくの別ものです。本来であれば別の言葉を当てるべきですが、今のところは適切な言葉がないですね。

・クラウドベンダーと「オンプレミス」ユーザーの競争について

ここが現在の興味のある部分です。日本企業はユーザーとベンダー両者含めて、残念ながら（一部を除いて）この競争の圏外なので、もっぱら海外での話になります。

現行のクラウドベンダーの技術的な最大の競合は巨大ユーザー企業になる可能性があると思っています。もっとも、そもそもクラウドベンダーとは名ばかりで、オンラインでの大規模小売と広告業が代表選手で、実際は巨大ユーザー企業ですよね？ということであればその通りなのですが。・・・ま、一応俯瞰で見れば、MS・IBMがAWS・Googleにクラウドに負けたという図式は、ピュアITがユーザーITに負けたという絵ずらにも見えるわけでして。んで、その勝者たるAやGに対抗するところはどこか？といえば、要するに別のでかいユーザー企業が本気出したとき、というのはあり得る話ではあります。

要するに、まだ登場していない（実際は登場してますが、ステルスモード全開っぽいです・・）別の巨大ユーザー企業がクラウド的な技術を「オンプレミス」的に発展させて、突然技術競争のトップに出てくるという、そんな話です。現在のクラウドベンダーの本質的な弱点は、アプリレイヤーからハードの下の建屋や土地までの一気通貫での最適化が難しいということです。そこをつくことができるユーザーは確かにいるでしょう。何しろ業務系アプリケーションの性格・必要性・課題を全部手元にもっているのがユーザーなので。ま、クラウドベンダーの人たちは鼻で笑うかと思いますが、いろんなプレイヤーが暗躍しているように見えます。油断大敵かと。

クラウド系の技術の一角は大規模分散系処理であることは間違いないです。前提としてはある程度の大数の法則が効くレベルのサイズが必要ですが、そのような本当の意味で“ビッグ・データ”を持っているグローバルのユーザー企業はいくらでもあります。（極東の某国ではデータを持っていないユーザー企業が多いので、マスコミやその手のコンサルタントの方々が、なんとか商売にするために、”ビッグ・データ”を矮小化する傾向が特に強いのですが、本質的に間違っていると思います。非常に退行的で褒められたものではないです。）特に、ある程度「現実をシミュレートする」という方向でデータ利用が進むのであれば、明らかにデータ量が級数的にふえるでしょう。したがって、そういう前提条件が現実に満たされる可能性は確かにあると思います。

また、その一方で大規模分散系処理は一般に制御が困難です。特に制約条件をつけないのであれば、まともに動かす事すら困難でしょう。よって、「どのような制限を、アプリからハードまで、垂直につけるか」ということは非常に大切です。能力のあるユーザー企業は、間違いなくこの制約については熟知しているわけで、そういったユーザー企業が、制限をうまく設けられない現状の「オールド・クラウド」に対して、新しい形のクラウド的なものあり方を追求し始めると、それはそれで別のゲームが始まるように見えます。

そもそも、某国のITベンダーは、海外のクラウドベンダーに数光年の差をつけられてますね、ということはもはや周知の事実ですが、ユーザー・セグメントのITにおいても同じ轍を踏みかねない状況かな、とちょっと思ったりもしています。いずれにしろ、「オンプレvsクラウド」といういかにもな対立軸だけを観点にしていると、いつの間にかゲームのルールが変わっていたということになるような気がしています。

とりあえずそんな感じで。