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

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

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

2013-11-10

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

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

ということで気がついたら設立から二年経過していました。正直、まだ二年しか経過していないのか、という感じがします。この一年は二年分ぐらいの時間感覚でした。まじで時間経過が速すぎて死ぬかと思った。去年の今頃は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年目に突入してます。

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

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