もともとは2016年の年の初めに書こうかと思っていたことですが、時間も経ってしまっていたところ、アリエルの井上さんとの対談 　IT屋はバズワードを使ってはいけない……のか？ (1/5)：EnterpriseZine（エンタープライズジン） も あって、ちょうどいいので記録的に思うところを書いておきます。 ・前提 ここではITと言う漠然とした言い方になっていますが、日本で最もマーケットの大きい、いわゆる業務システムを対象にしています。いわゆるSIの対象になるところです。と言っても一概に言えないので、売上2000億円程度の大規模企業の、下の方から、中小企業までの話にしています。売上が兆円単位の規模の社会インフラ系のシステムは、その2 ITは必要悪か？その2 - 急がば回れ、選ぶなら近道 で考えます。業務システムなのでコンシューマーものは考えてません。 ・ITは必要悪という認識 基本的にユーザ企

記事とか詳細とかはこっち http://www.atmarkit.co.jp/ait/articles/1708/28/news097.html https://cloud.vmware.com/vmc-aws http://www.publickey1.jp/blog/17/vmwarevcloud_air.html まぁ概ねこんな感じ 単純に見れば、AWS上でVMWareが使えるので、VMで動いているシステムがそのままAWSで使えるようになりました。便利ですね。はい、おしまいの話ではある。が、それは二重の意味で「表層的」な見方だ。そもそもVMWareがクラウドから撤退し、AWSの軍門に降ったというエポックメイキングなものとして見るべきだと思う。 ・ハード調達の争いの決着 結局のところ、DCを含めたハードウェアの調達という点で、競争に決着がつきつつあるということかと。VMWareの規模を

先日、分散システムをいろいろやっているメンバーで集まって、話題のブロックチェーンとかビットコインやらの勉強会をやってので、まとめておく。 いろいろ意見はあると思うけど、勉強会では問題意識は大体、共有できたと思う。まずは、キーノートやってもらったS社のMさんに感謝申し上げます。すごくわかりやすかった。やはり分散系をやっている人からの解説は、視点とか問題意識が同じなので参考になる。 以下、自分の個人的見解。合っているかどうかはシラン。 1.　現状の「ブロックチェーンとビットコイン」（以下オリジナルとする）は、そのままでは分散合意とは関係ない。 これはクリアだと思う。端的にいうとビザンチン将軍問題とは「まったく関係ない。」　だから「ブロックチェーンとビットコイン」がビザンチン将軍問題の解決になっているという話は、まずは「まとはずれ」だと思う。現状の「ブロックチェーンとビットコイン」は、分散合意は

一応、Asakusaのアドベントカレンダーのネタです。 いろいろ今後のAsakusaの対応について、現状を踏まえて一回まとめます。 1.ビックデータの敗北 まず、現状のビックデータの現状はちゃんと踏まえておきたい。というのは、いままでの分散処理の技術革新は、クラウド・ビックデータ関連を中心で進んできたわけで、当然次の流れはその「歴史」を考慮しなければ、ビジネス的な先はないでしょう。 まず、経験的には日本での「ビックデータ」の実行基盤としての大規模クラスターの展開はほぼ全滅に近いと思います。特に、日本ではPByteを越えるデータはその辺に転がっているものではありません。もちろん何百台・何千台ものクラスターを構成・運用しているところもありますが、おそらく十指を越える程度でしょう。日本の企業数が5万としても、99.9%の企業はそんなクラスターは持っていません。ただし、企業数が多いので結果としての

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

・Disclaimer自分は弁護士ではないし、その手の専門家ではありません。よってここに書いてあることを信じて、何かを行ってヤバい事になっても一切責任は負いませんし、それは自身の責任で処理してくださいね。まじめに会社の公式見解でもなければ、クラウドベンダーの代弁でもありません。 ・問題 自分の問題は以下、単純に「業務系システムを日本国内のDCのクラウドに上げている状態で、パトリオット法が適用された時に、そのクラウド上の業務系データが、一方的に米局政府に差し押さえられるということが起こりうるか？」という点につきます。 ・個人的な結論 結論から言うと、それは「ない」ですね。つまり、一方的かつ直接的に国内DCのデータが米国政府に押さえられることはないと思います。勿論、一定の要件を満たしたテロ等の嫌疑がある場合にはすべて正式の手続きに則った上で、米国当局の要請をうけて日本の司法がしかるべき手続きを

某エントリーの話で、「なんでもかんでもクラウド化なのか？」というお話もご意見も多数頂戴いたしまして。一応念押しですが、そういうつもりはまったくないですよ。以下、個人的な補足メモです。会社の意見ではありません。一応、会社の公式声明は「できるものは、とっとクラウド化したほうがいいですよ。」です。 クラウド化の是非については、いろいろあるでしょう。ユーザーの所属する産業毎にシステムのあり方・考え方は違うでしょうし、当然クラウド化すべきだという意見や、いやそもそも無理があるという意見もあると思います。ただ、今までのように先例がないから無理、という理屈は通用しなくなっているのが現状でしょう。その意味では無茶な理屈ではなく、普通に選択肢としてクラウド化が候補になっている、と思います。その上で、クラウド化しない、するという議論が普通にできる状態になりつつあると思います。 そんな中でいろいろ思うところをち

Hadoop Conference Japan 2013 http://hcj2013w.eventbrite.com/ 先週終了。かなりの盛況で終わった感じです。まずは開催をサポートして頂き、相当の負担まで頂いたリクルート・テクノロジー様に感謝申し上げます。どうもありがとうございました。 さて、えっと、前回がそもそもいつだったのか、良く覚えてないわけで。2011 Fallだったような。 http://hadoop-conference-japan-2011-fall.eventbrite.com/ 2011年の9月なので、1年4ヶ月ぶりという感じですね。Track数が増えて2から3で、会場もベルサールからビッグサイトになっていました。人数も1000人超になっております。 以下、感想文です。記録としておいておく感じで。 ・内容で印象に残ったもの ・HBase~LINEのバックボーンで使って

某DevLoveというところで話をしろ、ということでありましたので、いろいろ話をして来ました。 http://devlove.doorkeeper.jp/events/1733 まとめはこちら http://togetter.com/li/387189 あと、しんやさんの詳細なブログがこちら http://d.hatena.ne.jp/absj31/20121009/1349795347 スライドはこちら http://www.slideshare.net/okachimachi/devlove1 以下、ちょっと自分なりにまとめを。 ■自分なりにどう話したか 自分の仕事的にはHadoopとAsakusaでの課題解決が現在の本業です。ただ、Asakusaの位置づけとして、SIのための道具立てという側面が強く、また結果として会社も直接・間接にSIにはかかわっているので、割と現状の問題も意識して

・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず

「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？　思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ

某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と

最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多

言うまでもなく、COBOLなベテランは非同期バッチ処理の達人が多い。 日本ではこの手のベテランが多い。 まず世界でも例がないほどだと思う。 クラウド時代はむしろ非同期処理のオンパレードであり、 学ぶべき点はたくさんある。 こと運用レベルや、対障害設計は神レベルの人が多いので まじでノウハウは受け継ぐべし。 個人的に達人系の技のポイントをまとめておく 1.コンテキストを外部から与える 一種のDI的な考え方である。 但し、あくまで運用目線であることが重要。 通常のDIは開発効率を目的に考えていることが多く見受けられるが 非同期処理についてのDI的な考えは運用効率性の重視だ。 対障害設計をする上で、もっとも大事なことは 「コンテキストがまっさきに見えることだ。」 これはDI的は発想とはまるで違う。 今走っている処理は、 ・どういうモノで、 ・何を想定していて、 ・どういうスケジュールになっていて