ブログトップ 記事一覧 ログイン 無料ブログ開設

急がば回れ、選ぶなら近道

2015-07-08

Asakusa on Spark

Asakusa on Spark

AsakusaがSpark上で動くようになりました。
Asakusa on Spark (Developer Preview) — Asakusa Framework Developer Preview 0.1.1 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回ぐらいは更新したいと思います。すみません。

2014-06-22

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

要するにデータセンターの「原価計算」です。いろいろこのあたりに関わっています。複雑な計算ロジックと大量のデータを扱う必要があるので、大規模並列計算の適用が必須になり、結果として当方の出番になった、という状態。尚、実行基盤に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ビジネスのコストモデルが、旧態依然とした土建屋的なものであれば、クラウド的なサービスを取り繕ったところで、それは限界があるでしょう。手を打つべきは、仮想化やコンテナといった表面的な技術ではなく、根っこにある「基本的なビジョン」にあるような気がします。

そんな感じ。

2014-04-29

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

とはいえ

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

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

ま、閑話休題

2014-01-26

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

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

2013-12-24

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今後ともよろしくお願いします。