2011-03-13
まだそれを考える段階でないかもしれないが、巨大地震に遭ってSI業界は今後どうなるのだろうか？
日本列島を突然東北地方太平洋沖地震（東日本巨大地震、東北関東大震災）が襲いました。このような時期に、今回の地震に関してブログエントリを書くことは畏れ多いこと、不謹慎なことと感じられるかたもいらっしゃる思いますし、しばらくブログを書くのもお休みにしようかとも思いましたが、個人ブログですし「自重はダークサイド」*1という警句もあるくらいですから、今後も基本的に正直ベースで考えたことを書いていきたいと考えております。
現時点では被害の全容は正確に把握できていないようですが、震災を受けて亡くなられた多くの方々のご冥福をお祈りするとともに、大切な家や家族を失われたり、孤立した避難所で不安で不自由な生活を余儀なくされている被災地の方々に対して心からお悔やみ申し上げます。*2私自身は東京で今回の地震に遭遇しました。震源地に近い東北地方と比べると被害の程度は遥かに低いとはいえ、震度5強の強い揺れが5分近くにわたって続き、電車などの交通機関も麻痺して家に帰れなくなるなど、私としては今までここまで大きな地震に遭い恐怖を味わったことは初めての体験でした。
コンビニでもおにぎりやカップラーメンなどの食品はいち早く売り切れてしまい、品切れの状態が続いています。また、便利なので最近よく利用していたネットスーパーも閉店して利用できなくなっています。電車で家に帰ることや、おなかがすいたらコンビニで腹ごしらえの食料を買出しに行くといった日常生活で当たり前と考えていたことが今までどおりにはできなくなっています。関東ではしばらく前代未聞の計画停電ということが現実に行われるようですし、製造業や流通業などを中心に今回の震災が日本の経済に与える影響は本当に計り知れないものがあると思います。また、東北地方があれほどひどい災害に見舞われているということは、お米や魚介類、乳製品なども今後値段が高騰して手に入りにくくなるといった問題も当然出てくるのではないかと思いますし、被災地以外の人の生活にも大きな影響を及ぼすようになることは必至であると思われます。今まで都会での文明的な生活に慣れきった私たちにとって本当の試練はこれからやってくるのではないかという気もしています。
そういった状況の中でも、とにかく私は職業プログラマーとして業務システムの開発の仕事をしているのですが、今後この業界はどうなってしまうのだろうと思うと正直なところ将来がイメージできない不安もあります。とにかく、今までこのブログではSI業界で働くプログラマーの視点から業界での仕事や今後目指すべき方向についていろいろな考察をしてきました。
今になって思うと、外国人に対するコンプレックスやネガティブな意見が結構多かったかなと反省もしていますが、今まである意味恵まれすぎていたというか、厳しい競争も少なくぬるま湯につかった馴れ合いの環境でソフトウェア開発が行われてきたという事実は否定しがたいことなのではないかと思います。それでも、最近は景気低迷に加えてクラウド技術などの話題もあり、今後はもっと業界を効率的なものに変えていかなくてはというところがあったのですが、もともと危機的な状況の業界に対してとどめを刺すように今回の大震災が起こりました。まだ、地震が起こったばかりで業界の将来のことを冷静に考えるという段階ではないのかも知れませんが、地震の被害で従来のような費用対効果の少ない単純バージョンアップのような案件が激減するのは誰の目にも明らかなことだと思います。まずは、電気、水道などのインフラの復旧が何よりも最優先ですし、少なくとも一時的にせよITへの投資は激減するのは明白なことです。ショック療法と呼ぶにはあまりも厳しすぎた今回の大地震だったわけですが、今度こそはSI業界は生まれ変わらなくては本当にどうしようもないという事態に陥るのではないかと思います。
ただし、悲観的に考えてばかりいても未来がありません。世界中から祈りや応援のメッセージが届けられています。
【prayforjapan】世界から届いた日本への祈り - NAVER まとめ
また、今回の震災に関連して、以下のサイトでは本当に励まされるようなツイートがいくつか紹介されています。
元気の出るつぶやきを集めました・・・ | IDEA*IDEA
また、日常わが国において当たり前に見られる協力や好意といった日本の文化に加え、日本の防災対策や技術が外国の多くのメディアからは非常に高く評価されているのは本当に誇らしく思います。以前、日本文化は外人プログラマーから意外に尊敬されている？ - 達人プログラマーを目指してで、
実際、個人を尊重する外国の文化だとPG一人一人が個別のオフィスを与えられるそうですが、逆に日本のタコ部屋開発の文化はXPのペアプログラミングとかやりやすそうですし、極端な個人主義ではなくチーム全体の成果を重んじるという文化もアジャイルの考え方と適合します。カイゼンなどはリファクタリングに近い発想であると思いますし。だから、本来は日本の文化はアジャイル開発に非常に向いているのではと思いますね。1000年以上の歴史を誇る日本の伝統文化に対して、ゼネコンSIerのウォーターフォール文化はわずか数十年の歴史しかありません。そういうことから、日本で未来永劫アジャイルは絶対に流行らないと絶望することはないのかと思いました。本来であれば、外国よりももっとよいソフトウェアを作れる文化的な素地は十分にあるのかと思います。
と書いたことがあったのですが、本来日本的な文化に備わっているよい面がもっと発揮されるような開発手法が採用されるようになれば、海外への輸出できるような高品質で効果的なソフトウェアがもっとたくさん開発されても不思議ではないと思います。歴史的には第二次世界大戦の敗戦など多くの困難を克服してきた日本なのですから、今回の国難も乗り越えることができると信じています。とにかく、失うものが何もないという状態で再スタートすれば業界の改革も急速に成し遂げられると思います。いまこそ業界のリファクタリングの実行に具体的に着手し、従来の非効率な業界の構造や作業方法を改める絶好の機会です。（今のSI業界もリファクタリング可能だと思います - 達人プログラマーを目指して）
起こってしまったことは事実として受け止めるしかないのですが、明るい未来を信じ、前向きな気持ちで、これからまたプログラミングの勉強や仕事をがんばっていきたいと考えています。
*1：自重はダークサイドに込めるメッセージ - Life is Really Short, Have Your Life!!
*2：今のところ私としては小額の義捐金を寄付するということくらいしかできていないのですが、被災地の方々には本当にがんばっていただきたいと思います。 とりあえず自分にできることをやれる範囲でやろう - ふと、思いついたんだ
放射能、巨大地震、エレニン彗星 超サバイバルキ...
2011-03-03
クラウドが昔ながらのSIerの仕事を奪うようになってきてはいるけれど
Salesforceといえば、ちょうど最近行われたno titleというイベントに参加された方もSI業界では多くいらっしゃるのではないかと思います。私はそのイベントには参加していませんでしたが、先日会社でSalesforceのSE*1の方からお話を伺う機会がありました。
Salesforceの提供するForce.comのようなパブリッククラウド上での開発を最初からなんとなく敬遠してしまう組織もあるかもしれませんが、多くの業務システム開発に対しては開発生産性がJavaや.NETの5倍という宣伝文句は決して大げさでないケースが多いと考えます。実際この5倍という数字は日本における実績というよりワールドワイドでの実績に基づくものと思われますが、海外ではそもそもSalesforceが対象とするような領域ではもともと生産性の高いフレームワークやパッケージを使い、アジャイルで開発するのが多いと思われます。対照的に日本の業界では、伝統的に簡単なシステムであっても大量の画面定義書やExcelの設計書、テスト仕様書の作成が義務付けられていることが多いと思われますし、このブログで何度も指摘しているように、オブジェクト指向を使った再利用なども十分浸透していませんから、実は工数ベースで考えると生産性に10倍や20倍といった具合にもっと大きな開きがあっても不思議ではないかもしれません。
Force.comはSaaSとして提供されるCRMのフレームワーク部分の拡張であり、もともと、かなり業務ロジックが単純な（いわゆるガラポンの）社内システムを短期間に構築するためのものというイメージがありました。しかし、最近ではコンシューマー向けのサイトを構築するためのSiteforceという技術や、社内でTwitterのようなやり取りを行うChatterといった機能も提供されるようになっています。また、Database.comという技術を利用することで、Force.comをデータベース的に利用するといったことも可能になっています。また、将来的にはvmforceやHerokuの技術を使うことで、画面周りをSpring MVCやRubyの技術で作成するといったことも可能になると思われます。つまり、従来は全レイヤーがSalesforceの独自技術に拘束されるという制約が非常に大きかったのですが、だんだんとレイヤーごとに、よりオープンな技術と連携可能になってきています。
ただし、SalesforceもGolden Hammer的に常に最適なわけではもちろんなく、以下のような制約があると思っています。
- データベースが独自（内部的にはオラクルを使っているらしいけれど普通のTableとしては利用できない）のため、場合によっては既存データの移行などに相当の工数がかかる危険性がある。
- 現状の開発環境や言語からは、大量のビジネスロジックを記述するのは非常に困難と想定される。
- 大量データのバッチ処理が困難
- governorリミットなど性能上の上限値が存在することを考慮する必要があり、スケーラブルでない。
- 外接インターフェースをうまく設計しないと、結局情報サイロ*2になってしまう。
全体的に技術が独自ということもありますが、結局Access VBAやExcel VBAのアプリケーションをクラウド上で実行するようなイメージに近いところもあるためベンダーロックインが心配なのと、ユーザー数や運用年数に応じてコストもかかるわけですから、機能が多く、かつ、長期にわたって運用するようなシステムにはまったく向かない気がします。それゆえ、SIerの大切な仕事である大規模な基幹業務システムの分野とは住み分けができると思われます。
GAEもそうですが、従来のPasS環境はプラットフォーム独自の制約というのが大きく、その上で展開できるシステムは限られるというところがありました。しかし、今後の傾向としては、クラウドのPaaS環境もよりオープンで柔軟性の高いものになっていくというのは自然な流れだと思います。そして、独自の性能要件や機能要件を満たす必要があるようなシステムもデプロイ可能なプラットフォームがパブリックなクラウド上でより安価に利用できるような環境が提供されるようになっていくだろうと容易に想像されます。ちょうど、Amazon Web Service（AWS）が東京に上陸したというニュースがありましたが、
Amazon Web Services ブログ: 【AWS発表】 クラウドが日本に上陸: AWSの東京データセンターが開設
レイテンシーの問題や海外拠点にデータを持ち込むことに対する精神的な障壁、日本語サポートの問題といったことがクリアされたことで、今後publicクラウドを導入する企業が確実に増えていくと思われます。アプリケーションの開発も基盤運用も含めて、従来SIerが伝統的に担ってきた仕事は、当然ですがどんどん少なくなってくると思われますね。
こうしたことは当然誰でも予測していたことなのですが、いざAWS上陸のニュースを聞くといよいよ本当に黒船が来航したかという気になりますね。幕末の時は黒船から明治維新まで15年くらいかかっているのですが、変化の急速な現代のIT業界のことですから、業界の大きな変革が起こるのにはそれほど時間はかからないのではないかという気もします。この1年〜2年のうちに業界のビジネスモデルが大きく変革せざるを得ないという事態になることもまったくありえないことではないなと思います。（もちろん、レガシーシステムのメンテナンスの仕事は一定期間続くことにはなりますが。）ISIDさんもISID、Amazon Web Services上での企業向けクラウドサービスを強化（2011年3月3日）：プレスリリース| ISIDのようなサービスを開始するそうですが、今後他のSIerもクラウドを対象としたサービスについて、何らかの変革を迫られることになると思います。（今のSI業界もリファクタリング可能だと思います - 達人プログラマーを目指して）
クラウド関連のネタで、私も含めてSI業界で働くものとしては、ちょっと悲観的な話になってしまったのですが、今後本当に技術力が試される時代になってきているということでもあるのですし、本物のプログラマー（エンジニア）としては今後ますます面白い時代になっていくだろうという楽観的な希望も述べておきたいと思います。
2011-02-19
Developers Summit 2011参加メモ（2日目）
勉強会・セミナー, PGのキャリアーパス, プログラミングの勉強, クラウド
Developers Summit 2011参加メモ（1日目） - 達人プログラマーを目指してに続いて、2日目のレポートです。
【18-B-1】プログラマが知るべき、たったひとつの大事なことがら
タイトルはもちろん、以前もすべてのプログラマーに読んでもらいたい本 - 達人プログラマーを目指してで紹介させていただいた、きのこ本のタイトルからきています。この本を監修された和田卓人 氏（id:t-wada）の講演です。個人的には2日間の中で最も感銘を受けたセッションでした。*1
現時点では講演スライドはアップされていないようですが、以下が参考になります。
#devsumi【18-B-1】プログラマが知るべきたったひとつの大事なことがら - @tmtms のメモ
デブサミ2011【18-B-1】プログラマが知るべき、たったひとつの大事なことがら和田卓人 氏 - Togetter
プログラマが知るべき、たったひとつの大事なことがら - Developers Summit 2011 - techlog
講演スライドは以下The only one big thing every programmer should know
いきなり、講演の最初でたった一つのことという「タイトルは釣り」との発言がありましたが、お話の中で（通奏低音として）終始一貫して鳴り響いていた主題（テーマ）は
きのこ本で一番大事なキノコ「18, 学び続ける姿勢」
ということでした。確かに、プログラマーとして学ぶことは無数にあるのだけれど、結局、学び続けるという姿勢は一つということですね。通常我々が「学ぶ」という言葉を聞いた場合、読書やネットの情報、勉強会への参加などを通して、外部から情報を受け取るという受身的な行為を想像してしまうのですが、
- （読む）プログラム本をただ読むのではなく、コードを写経しながら自分なりに考える
- （書く）ブログを書いて、自分から積極的に情報発信することでコメントやトラックバックなどを通してより多くの情報を学ぶことができる
- （話す）書くだけでなく、自分から勉強会やセミナーで積極的に話すことでさらに深く勉強する
というように、段階的にステップアップするにつれ、よりアクティブな活動も加わってくるようです。自分は対人恐怖症などで回り道したこともあって時間はかかったのですが、（プログラマーの定年*2を過ぎた）5ヶ月前からふと思い立ってブログとTwitterを始め、この歳になってようやく「書く」段階にシフトしてきたばかりです。確かにブログを付け始めてから情報の吸収力は以前と比べ物にならないくらいのスピードとなり、圧倒的に増えた気がします。*3「話す」はまだプロジェクトや社内に留まっている段階なのですが、まずは小さな勉強会のLTからでも、勇気を出してコミュニティー活動で自分から積極的に「話す」ようなスタイルの勉強にも挑戦してみたいとこの講演を聴いて思いました。
もう一つ、「年配」プログラマーの一人として感銘を受けたことは、
若い人から学ぶ。一生プログラマーでいられるかどうかは年下から学べるかどうか。
ということですね。確かに、これができないと自分自身若いプログラマーから本当に老害とdisられる*4存在になってしまいそうです。ただし、以前の経験は完全に無駄になるわけではなくて、何度も原点に返りながらも螺旋階段を上るようなものであるとのこと。
ちなみに、お話の中で達人プログラマーの書籍に何度か言及されていたこともまた良かったです。毎年新しい言語を一つ覚えるとか、プレゼンもプログラミングの対象にしてしまうなどの発想は達人プログラマーの教えですね。
私も常に学び続けるという姿勢を大切にしつつ、経験を積み重ねることでプログラマーとして確実にステップアップしていきたいと思います。
【18-B-3】これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル
永和システムマネジメントの木下史彦 氏から、受託開発におけるアジャイル開発の実際についてお話がありました。
デブサミ2011【18-B-3】これからの「アジャイル」の話をしよう 木下史彦 - Togetter
おそらく、多くの人が既にご存知かと思いますが、永和システムマネジメントと言えば
新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメント
というニュースが昨年末話題になりました。人月ビジネスが当たり前のSI業界において、作業工数に比例しない、新しいビジネスモデルというパンドラの箱を開けてしまったのは、木下氏の提案によるものらしいです。今のところ、人月ビジネスはまだこの業界の常識ですし、今後すべてがこうした新しいモデルに移行するわけでもないと思いますが、SI業界のリファクタリングという意味でも大いに期待されるところです。
今のところ、このモデルでの案件がようやく1件受注できたということなので、まだまだ駆け出しの状態のようですが、がんばってもらいたいですね。なお、Ask the speakerコーナーで質問したところ、実際の開発はRubyを使ったスクラッチのWebアプリケーションが多いとのことでした。Javaプログラマーの私としては、Java EEでも同様にできないかなと思いましたが。
もちろん、
魔法なんてないよ
ということですし、アジャイルを取り入れればすべてがバラ色ではないということをも強調されていました。そういうところは実践に基づいてアジャイルを実業務に取り入れている木下氏ならではの重みのある発言だったと思います。でも、2006年以降
離職率ゼロパーセント
というのはすごいですね。これは、業界の一般的な職場では考えられないことだと思います。
【18-B-5】クラウド時代のソフトウェア開発
講演者の及川氏（id:takoratta）は
大学を卒業後、外資系コンピュータメーカを経て、マイクロソフトにてWindowsの開発を担当。Windows Vistaの日本語版および韓国語版の開発を統括した後、Googleに転職。ウェブ検索やGoogleニュースをプロダクトマネージャとして担当した後、2009年10月よりエンジニアリングに異動。現在、Google ChromeやGoogle日本語入力などのクライアント製品の開発を担当。また、Google Developer Dayなどの開発者向けイベントにてスピーカーも務める。
のようなすばらしい経歴をお持ちの方なのですが、まさに、常に学び続ける姿勢というか、いわゆる老害と呼ばれる人とはまったく異なるタイプの方のようで、実にすばらしいですね。経歴の前半でいわゆるSIも経験されたことがあるようですが、Microsoft入社以降はWindowsなどの大規模な製品の開発に携わってこられたようです。
講演では、Microsoft時代製品開発経験と現在のGoogleにおける開発経験の比較を元に、クラウド時代のソフトウェア開発はどうあるべきかについて説明されました。
Microsoftのパッケージに象徴されるように、従来の大規模製品開発では、リコールを避けるために文言といった些細なバグでも完全につぶしこんでから出荷するというのが求められました。そういう失敗の許されないところがあったため、ある程度アジリティーを犠牲にしてもトップダウンの品質コントロールやマネジメントが求められたということです。一方、対照的に最初からクラウドをターゲットにしたGoogleの開発では、よりアジリティー（機敏さ）とサービサビリティーに重点が置かれるようになっているとのことです。
- デプロイメントのコストはゼロに近くなった
- リリースしてからが本番
- 避けるべきはサービスダウン
それから、Launch & Iterateという考え方についても紹介されました。実際、Webアプリケーションだとユーザーがクリックした情報などが簡単に収集できますから、そうした情報に基づいて機能改善や拡張を行った方が効果的ということでしょう。その他、従来の離散的なVersion番号に従ったリリース管理から、Versionlessの連続的な進化への対応するためのスケーラブルな開発インフラ、リリースサイクルの改善、オープンソース化などについても説明されました。
確かに、受託のSI案件とは違う側面もあると思いますが、クラウドを前提として開発において、Googleのこうした先進の取り組みはSI業界で開発を行う我々も大いに参考にすべきであると感じました。
Developers Summit 2011参加メモ（1日目）
創発 未来につながるために 世界に帆を立てるために Developers Summit 2011に参加してきました。記憶が薄れない前に、ノートに取ったことを以下にまとめておきたいと思います。基本的にはこのブログで日ごろ書いている内容と同様に、エンタープライズ開発やプログラミング技法、アジャイル開発プロセスなどを中心に話を聞いてきました。
なお、多くの講義資料は404 error. Page Not Found.で公開されていますし、詳細な議事録は他にも多くの方が記述されています(デブサミまとめまとめ:2011)ので、ここでは私が参加した講演に対して、私が（主観的に）感じたことも含めて書いていきたいと思います。（聞き間違えていた箇所があれば、ご指摘いただければと思います。）
【17-B-1】エンタープライズパッケージ開発の今
梅田弘之 氏が進行役となり、小野和俊 氏、小林達 氏、萩原純一 氏の3人に順次意見を伺うという形式で、「エンタープライズパッケージ開発の今」について議論されました。私は知らなかったのですが、登壇者の方々の所属している会社はMIJIというコンソーシアムに参加しているそうです。日本のソフトウェアパッケージは完全に輸入超過の状態となっています*5が、日本のソフトウェア製品を世界に向けて発信していくというのを目指している団体のようです。
エンタープライズといっても、一般のSIの受託開発とは違い、各社アジャイル開発手法を取り入れているということで、ペアプログラミング、TDDなど具体的なアジャイル開発手法の導入事例について説明がありました。特に、私の印象に残ったのは以下の点です。
- ジョエルテストは有効。（小野氏）
- パソコンは遊びの道具なので一人にすると半分は遊んでしまう*6からペアプロの方が工数が得になることもある。（小野氏）
- ペアプロとソロプロの使い分けをしているがコミットレビューは必ずペアで実施している。（小野氏）
- ペアプロスキルとプログラミングスキルとは分けて考えるべき。（小野氏）
- テスト自動化とテストファーストは別物として考えるべきで、たとえば後者はプロトタイプでは必須でない。（小野氏）
- ペアプロは疲れるし、上司に遠慮する必要もあるので片方が帰りたくなったら帰宅するルールを作っている。（萩原氏）
- コーチング、QMSなどの手法は特に導入していない。（萩原氏）
- ペアプロは導入していないが、一日の半分はふらふら遊んでいる人がいる（？）（小林氏）
残念ながら時間の関係もあったのか、それぞれの登壇者の説明を聞く形式で、パネルディスカッションのように深い議論にはなりませんでした。
【17-C-2】クラウド上でのエンタープライズアプリケーション開発
英語講師予約システムをGAE（Slim3利用）、Force.com、Amazon Simple DB、Azureで実装検証した結果の報告が行われました。簡単なサンプルアプリケーションですが、こうした予約システムでは同一の講師に対して複数の受講生から同時に予約が入ってしまうなどのバグは絶対に避ける必要があります。CAP定理により、NoSQLを使ってスケーラビリティを求めようとすると、RDBでは当たり前に保障されている読み取り一貫性や複数テーブル更新時のトランザクション原子性が保たれないなどの問題があります。具体的なPaaSのテクノロジーを利用した場合に、こうした問題をいかに解決するかについて、検討事例が説明されました。工夫次第でNoSQLでもエンタープライズアプリケーションは構築可能であるとのことでした。ただし、現時点ではパターンカタログ化されていませんが、しばらくすれば経験がカタログ化されるのは確実でしょう。
Force.comは裏でRDBを使っているので、一般的なNoSQLとは一応別ですが、作成したアプリケーションの特性に応じて従来のRDBとNoSQLを正しく使い分けることも大切なのではと私は思いました。
【17-B-3】チケット駆動開発〜タスクマネジメントからAgile開発へ〜
もともと「もう一つのTDD」ということで提唱されたチケット駆動型開発（TiDD）について説明されました。発表者の方は以下の書籍の著者でもあります。（私は翔泳社ブースにて購入）
- 作者: 小川明彦,阪井誠
- 出版社/メーカー: 翔泳社
- 発売日: 2010/10/13
- メディア: 大型本
- 購入: 16人 クリック: 337回
- この商品を含むブログ (50件) を見る
従来のプロセスは障害の発見のみに注力し、段階的な改善プロセスというのが軽視されがちでしたが、TiDDの導入によりこうした経験を生かしたプロセスが導入できるようになるそうです。そして、TiDDにより作業抜けを無くすと同時にプロジェクトの活性化が図れるそうです。
なお、チケットの管理には
- ワークフロー型（起票には管理者の承認が必要。手順もれ削減）
- オープン型（誰でも自由に起票できる。作業漏れ削減）
の2種類があるそうです。
BTS自体はバグ管理システムとして以前からあるのですが、このツールを単にバグ管理だけでなく、タスク管理に活用するという新しい使い方により以前とまったく違った効果が得られるという点で、TiDDはAjaxみたいな存在とのことでした。
個人的にはTicketの粒度をどう考えるかという点がポイントになりそうだと思いました。No Ticket、No Commitを徹底させるには、従来のタスクカードのように気軽に起票できることが大切だと思いますが、あまり自由にしてしまうと管理性が下がります。Redmineの親子チケット機能を活用したり、レポート機能を活用したりするような工夫が有効だと思います。
【17-E-4】未来はどこにいても誰にでも平等にある。 未来を創るのは自分自身だ。 〜SIerの中で生きるということ〜
SIerの将来については、このブログでもいろいろ書き綴ってきたので、かなり期待していました。講演内容が決まったのが結構後の方だったこともあり、他のセッションに比べると空席が目立ちましたが、さすがにスーツ率が高かったように思われます。講演者の川島氏はTISでアーキテクトをされている方で、業務では入社以来、10年以上にわたって特定のお客様先に常駐されて仕事をされているというバリバリのSIer技術者の方です。ただし、上流専門でプログラミングをしないSEというわけではなくて、以下のようなオープンソースの開発にも携わっておられます。*7
solr-jdbc - JDBC Driver for Apache Solr - Google Project Hosting
講演の最初のメッセージは、SIerは製造業や建設業ではなくてサービス業になるべきという主張がありました。美容院の腕利きのスタイリストのようにお任せでもいいようにやってくれる、プロフェッショナルなサービスを提供できるようになるべきとのことでした。上流だけに限ると従来のコンサルティングファームに近い感じなのですが、実装まで含めて面倒を見るプロフェッショナルサービスを提供する集団として生まれ変わるということでしょうか。今のSI業界もリファクタリング可能だと思います - 達人プログラマーを目指してなどで、私が主張してきたことと共通点もあるかと感じました。（SIerはIT業界のゼネコン構造の象徴なので、そこまで変わるとSIerでなくなってしまうという主張もあるかと思いますが。）
あと、興味深かった点は従来権限がプロジェクトマネージャーに集中していて、技術者たるアーキテクトの専門性が発揮できていないという点です。
- ITA プロジェクト計画に責任を持つ
- PM プロジェクトの遂行に責任を持つ
ということで、戦国時代で言えば、ITAは戦略を司る軍師、PMは侍大将のようなものですから、ITAにはもっと権限と責任が与えられるべきということだと思います。実際、システムのアーキテクチャにより組織の体制が左右されるというコンウェイの法則についても紹介されました。
同業者として全体的には共感できる内容だったのですが、やはり、どうしてもSIer脳の発想というか、万能なアーキテクトやPMが多数の無能なプログラマーを統率するという、大人数の人月ビジネスの枠組みが前提となっているような気がしました。アジャイル開発のようにアーキテクトやPMなどの上位職だけでなく、個々のプログラマーの専門性やスキルがもっと尊重されるようにならなくては、SIerは本当の意味で顧客にとって価値のあるサービス業には生まれ変われないのではないかと思いました。
【17-C-5】Spring as a Cloud Platform
日本Javaユーザグループの幹事であり、現在はSalesforceでコンサルタントをされている河村嘉之 氏の講演です。Javaは終わったのか、Java EEは終わったのかという点に対して、今後もSpring Frameworkは面白いとのことです。私の以下のブログでも書いていますが、まったく共感する内容でした。SpringはエンタープライズJava開発者に夢と希望を与えている - 達人プログラマーを目指して
講義の中で、時間軸、垂直軸、水平軸への3方向へのSpringの拡張について説明がありました。
- 開発環境（ビルド）→実行環境→運用環境（時間軸方向への拡張）
- 下方向にはVMWare、OS（SuSE Linux）、上方向にはRoo、Grailsのような上位FW（垂直方向への拡張）
- vmForce、GAE連携、プライベートクラウド（水平方向への拡張）
以下の資料も参考になります。Springの今
後半は実際のコード例を示しながらのvmForceの紹介がありました。（ただし、デモではない。）JPAの設定は一部書き換える必要がありますが、コードはほとんどそのままでForce.comのDBを参照できるようです。（もちろん、実際には単純にRDBをそのままForce.comに移行できるわけではないそうです。）
【17-C-6】SpringのこれからとJava開発者向けの次世代RAD、Spring Roo
Stefan Schmidt 氏はオーストラリアでSpring Rooの開発にも携わっているVMWareのコンサルタントです。講義の前半はSpring Rooを使った開発のデモ、後半は（Rooだけでなく）Spring Frameworkの将来のロードマップについての紹介でした。
前半のRooの説明では、以下の点について説明がありました。
- getter、setter、toString()などはAspectJで自動的に追加されるのでコードの記述が不要（もちろん、必要なら追記できる）
- Rooは日本語を含めて現在9ヶ国語をサポート
- 以下のUIテクノロジーをサポート（予定）
- Spring MVC
- GWT
- JSF
- Vaadin
- 既存のテーブルを元にした自動生成。
なお、Grailsとの違いで、Rooの特徴としてRooは完全に開発時のツールであり、実行環境はPure Springのアプリケーションなのだという点を強調していました。そういう意味では、実績重視のSI案件への導入の敷居も低いはずだと思います。
後半はこの春にもうすぐ登場予定のSpring 3.1の以下の新機能について紹介されました。
- 環境プロファイル（開発、ステージング、本番などでBean定義を使い分けられる）
- キャッシュ抽象化
- 会話管理（ただし、デフォルトはステートレス。クラウドではやはり原則ステートレスがよいとのこと）
- Servlet3.0対応、JSF2.0対応
また、今年の夏には早くもSpring 3.2が登場する予定とのことです。
その他、以下のプロジェクトについても紹介されました。
- Spring Data（SpringからNoSQLを使うためのフレームワーク）
- Spring Mobile（モバイルデバイス向けのSpring MVC拡張）
- Spring Android（nativeのアンドロイドアプリケーション開発フレームワーク）
- Spring Social（ソーシャルアプリケーション開発用拡張）
- Spring Gemfire（分散データ管理）
- Spring Payment Service（課金サービス連携）
- Spring AMQP（SpringからAMQPを使えるようにする）
【17-D-7】C#(VB)プログラマのためのF#入門
私は.NETの開発経験はほとんどないのですが、Scalaと共に、.NETと親和性の高い関数型言語として知られるF#についてちょっと興味があったため参加しました。
- 関数型言語では式が主役（手続き型は文が主役）
- 関数でさえ値
- すべての言語要素が式
- より安全
- パターンマッチ
- Option型によるnullの回避
- 型が軽い（簡単に型が定義できる）
- キーワードが少ない
- |>演算子
- コンピテーション式
- use束縛
などについて、説明がありました。
F#の弱点については
- IDEサポートが弱い
- Express Editionがない（無料で開発環境を作ることは一応可とのこと）
- 日本語の情報が少ない
とのことでした。ただ、言語系の日本語の本は充実しているという一般的な傾向の例に漏れず（エンタープライズ開発者が負け組として軽蔑される日本のSI業界って - 達人プログラマーを目指して）F#の本は既に日本語の本も出ているようですね。
- 作者: 荒井省三:いげ太
- 出版社/メーカー: 技術評論社
- 発売日: 2011/01/07
- メディア: 大型本
- 購入: 6人 クリック: 264回
- この商品を含むブログ (24件) を見る
- 作者: Chris Smith,頃末和義,鈴木幸敏
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/08/26
- メディア: 大型本
- 購入: 4人 クリック: 47回
- この商品を含むブログ (19件) を見る
最後に、ロジックの記述はF#、画面デザインはC#、VBという使い分けが重要との事ですが、まったくその通りかなと思いました。
*1：当日、この本のサイン会があったとは知らず、本を持参し忘れたので、サインをもらいそびれてしまったことが残念です。TDDの勉強会など、別の機会に是非リトライしたいです。
*2：一般的には30歳とも35歳とも言われるようですが、私はどちらも超えていますね。
*3：リア充、disる、orzなどのネット用語のリテラシーがついたのがここ最近の一番の違いかもしれませんがw。
*4：disrespect、軽蔑される。
*6：ゲームやツイッターなど
*7：Ask the speakerコーナーで質問した際には、少なくとも現在までは、SIerでプログラマーとして生きるということは、プログラミングは趣味と割り切って業務と切り離して行う必要があるとも。私としては、今後は業務でもプログラマーの価値が認められるようになってほしいと思いますが。
2011-01-27
想像以上にガラパゴス化した日本のIT業界？
出版されている技術書のタイトルやネット上での情報を元に、なんとなくシステム開発で使われる技術が国によって差があるように感じるということを、これまでいろいろな記事で書いてきたのですが、はたして実際のところはどうなのでしょうか？300年前なら、Manningのin actionシリーズの表紙に描かれている人物*1のように国ごとにいろいろな衣装があって多様な文化が存在していたのでしょうけれど、文明化された現代では、服装も食べ物もそれほど違いがないというところがあります。IT業界は文字通り情報を扱う産業なのですから、世界中の最新の情報が集まってきてしかるべきなわけであり、どの国でも大差がないはずという推測もできないわけではありません。
あくまでも目安なのですが、Google Insights for Searchというサービスを利用すると、単語の検索回数を地域ごとに集計することで、各地域でどういった用語が関心が高いのかを知ることができます。ここでは、このサービスを使って、さまざまな技術の関心度に対する地域ごとの差が実際にどのくらいあるのか調べてみたいと思います。
SI向けのGroovyと研究向けのScala
まず、Groovy言語とAspectJの人気が今ひとつな本当の理由でも取り上げた、Groovy言語とScala言語の地域ごとの人気の違いを見てみます。
http://www.google.com/insights/search/#cat=31&q=scala%2Cgroovy&date=1%2F2009%2025m&cmpt=q
面白いことに、結果を見るとなんとなく予想通りな結果となっていますね。Scalaは、日本では世界で3番目に検索数が多いのに対して、Groovyではトップ10以内にランキングされていません。また、Scalaは日本を除くと北欧を中心としたヨーロッパで人気が高く、逆にGroovyはインド、東欧、ロシア、中国、米国などで人気が高くなっています。学術的、研究開発的なScalaに対して、多人数でのSI開発向けのGroovyという構造がよく表れているのではないでしょうか。*2
Java EE開発における国際地域の違いによる差
Struts1での検索結果は以下の通りです。
http://www.google.com/insights/search/#cat=5&q=struts1&date=1%2F2009%2025m&cmpt=q
中国がダントツ1位で、ついで、インド、日本の順になっています。一方、Spring MVCは
http://www.google.com/insights/search/#cat=5&q=spring%20mvc&date=1%2F2009%2025m&cmpt=q
となって、インドがトップでついで韓国、香港の順となっています。割合としては少ないですが、欧米諸国もトップ点に入っています。日本はランキング外です。JPA、JSFといったJavaEEの比較的新しい仕様については、
http://www.google.com/insights/search/#cat=5&q=JPA&date=1%2F2009%2025m&cmpt=q
http://www.google.com/insights/search/#cat=5&q=JSF&date=1%2F2009%2025m&cmpt=q
ともにインドがトップとなっている一方で、日本は10位以内に入っていません。ちょっと興味深いことに、OSSのJavaEEサーバーであるjbossの検索結果も同様の傾向となっています。
http://www.google.com/insights/search/#cat=5&q=jboss&date=1%2F2009%2025m&cmpt=q
一方、最新の技術としてSpring Rooを見てみると
http://www.google.com/insights/search/#cat=5&q=spring%20roo&date=1%2F2009%2025m&cmpt=q
となっていて、ドイツ、イギリス、米国がランキングしています。
以上の結果から、以下のことが推測されます。
- Struts1の勢力で中国が1位なのは日本のオフショア開発によるものではないか。そうすると3位の日本と合わせて日本のSIerが世界の中でも唯一時代遅れのStruts1を使い続けているという事実が裏付けられたことになる。
- JPAやJSFを使った比較的最近のJavaEEを使ったエンタープライズ開発の中心はインドである。英語力と技術力を生かした欧米からのオフショアが多いから？
- Spring Rooのような最新技術を使った開発は欧米で行われている。
Ruby関連技術の国際人気比較
日本生まれのプログラミング言語といえば、やはりRubyですね。実際検索してみると日本が1位でした。
http://www.google.com/insights/search/#content=1&cat=31&q=ruby&date=1/2009+25m&cmpt=q
ただし、Railsとなると
http://www.google.com/insights/search/#cat=31&q=rails&date=1%2F2009%2025m&cmpt=q
日本は4位に後退し、上位にベラルーシ、インド、米国がきます。これはScala対Groovyの比較でも傾向があったように、SIerが開発の中心であるエンタープライズ系でRubyがまだまだ十分に浸透していないということを示しているのでしょうか。
日本でのみ使われている固有技術（いわゆるガラパゴス）
一方、日本で生み出された固有技術といえば、Seasar2やSlim3などが有名ですが、これらはGoogle Insightsの結果を見る限り現状は日本でしか使われていないみたいですね。（Seasar2は明示的にガラパゴス戦略で開発されたようですが、Slim3はグローバルを意識して開発されているようです。そろそろSeasar2のガラパゴス戦略について語っておくか - ひがやすを blog、および、コメント欄のひがさんのコメントを参照。）
完全に日本国内だけで使われているという意味では、MixiやGREEなどと傾向がよく似ています。（SNSの国際勢力図は以下を参考World Map of Social Networks | Vincos Blog）
SI業界からはさっさと抜けだしたほうがいい。
サービスを作る側に回ったほうがいい。
というid:higayasuoさんの最近の名言がありますが、日本のガラパゴス市場のみをターゲットにしたサービスはどこまで将来性があるのでしょうか？どうせサービスを作るなら最近話題のFacebookのようなグローバルな市場を狙いたいところですが、英語音痴の日本人に果たしてそういった仕事ができるのでしょうか。もちろん、不可能ではないとは思いますが。
クラウド関連の用語
PaaS、SaaSなど、最近よく耳にするクラウド用語はどうでしょうか。
http://www.google.com/insights/search/#cat=5&q=SaaS%2CPaaS%2CGAE%2CAWS&date=1%2F2009%2025m&cmpt=q
どれも日本は世界で1位、2位にランキングされています。日本のSI業界は上流重視で、実装技術よりパワーポイント上のバズワードをありがたがるという傾向を示唆しているのでしょうか？
まとめ
ここで述べたことは、あくまでもGoogle Insights for searchの結果を元にした考察であり、Google検索ユーザーの割合や人口などさまざまな要素を十分に考慮していないため、結果の解釈がどこまで真実を表しているかどうかは不明確なところがあります。ですから、あくまでもここでの個別の比較結果に関しては一応ネタとして考えていただきたいです。しかし、少なくともIT業界というのは想像以上に国際地域の差や文化の違いが事実として存在しているということは確実にいえるのではないでしょうか？やはり、日本語という言語の壁もあるのでしょうか、日本のIT業界を取り巻く環境は想像以上にガラパゴス化した状態となっていると思います。
（追記）
ガラパゴス化という言葉を結論とタイトルに使用したのは不適切でした。ここでは国によって想像以上に関心のある技術が異なっている、多様な文化が存在しているということが言いたかったのですが、「ガラパゴス化」と書くと進化から取り残されているというネガティブなイメージが強くありますので。日本のIT業界における仕事の仕方や技術の関心対象が英語圏を中心とした世界の標準的な方法と比べて独特であるくらいの意味で考えていただければと思います。
*2：日本のソフトウェア産業は「製造業」 - My Life After MIT Sloanも参考になります。日本のIT業界が製造業は認識が違うと思いますが、ヨーロッパ→研究、アメリカ→ビジネス、インド→プロフェッショナルサービス（SI）という傾向が結果に表れていると思います。
2011-01-17
SpringはエンタープライズJava開発者に夢と希望を与えている
Spring Frameworkというと、Seasar2と共にDIとAOPの軽量コンテナーとして知られており、オープンソースのJavaのフレームワークであるというというのがいまだに多くのJava開発者の間では常識かもしれません。しかし、SpringSource社が2009年の夏にVMWare社に買収されてから、クラウド上の標準Javaアプリケーション開発プラットフォームとしての色彩を急激に濃くしているようです。残念ながらJavaEE標準が現時点では明確なクラウド対応の標準プラットフォームにはなっていないこともあり、クラウドの時代になってJava開発者は今後どうすればよいのだろうとちょっと不安になってしまうところもあったのですが、デファクトスタンダードであるSpringベースのアプリケーションが今後クラウド環境上で動作するようになるのであれば、現在のフレームワークの知識も生かせるし、将来に対してちょっと希望を持てますね。Springのクラウド対応については、現在いろいろなものが存在していてちょっと理解が難しいのですが、以下にまとめます。
まず、買収直後に発表されたCloud Foundryというのがあります。
Spring のCEO のRod Johnson氏が、強調したのは、SpringSourceは、開発者がクラウド技術を無意識に利用できるようにして、彼らの日々の開発業務や作っているアーキテクチャにおける混乱をできるだけ小さくしたい、ということであった。
つまり、IaaS(Amazon EC2)上にSpringベースのアプリケーション実行環境をPaaSとして提供することで、独自言語や独自APIに制約されるForce.comやGAEのようなPaaS環境と違ってベンダーロックインしないし、開発者も既存のスキルを活用できるという考え方のようです。現時点ではベータ版で、実行環境もEC2に限られるようですが、SpringはOpen PaaSという考え方を提唱しているため、今後はプライベートクラウドなどを含めてより広いターゲットへの配置が可能になるかもしれません。
それから、昨年の春ごろにはForce.comとの提携が発表され、VMforceという製品が発表されました。現時点ではまだ開発途中で、一般には公開されていませんが、早ければ今年中には利用できるようになるかもしれません。ダウンロードできないため中身の詳細は不明なのですが、発表されているデモの内容からは、VMWareの仮想環境であるvSphere環境上にデプロイした普通のSpringアプリケーションをSalesforceのデータベースやサービスと連携させるAPIがセットになったもののようです。
VMforce は、POJO、JSP、サーブレットなどの標準的なJavaコードを、人気の高い Spring フレームワークとあわせてサポートします。VMforce では、既存のエンタープライズ Java アプリケーションをクラウドへ移行するのも簡単に行え、クラウドのロックインを回避することができます。
だから、Force.comのApex言語がJavaで置き換わるというイメージではなく、あくまでもForce.com環境とは切り離されたJavaアプリケーションとして配置されるため、GAEなどと違い普通のRDBを使ったSpringアプリケーションを配置できるし、おそらく、オンプレミスの環境やプライベートクラウドへの配置も可能になるのではないかと想像しています。発想はMicrosoftのAzureに近いかもしれません。
それから、SpringはGoogleとの連携も行っています。
VMware to Collaborate with Google on Cloud Computing
この連携により、Spring Tool Suite上で開発したSpringアプリケーションをGAE上に配置することが可能になるようです。また、最近ではSpring RooアプリもGAE上への配置をサポートしているみたいですね。
最近は、SI業界の不人気からか
java業務アプリなんか書いてるのはとっくの昔に負け組。
SI業界からはさっさと抜けだしたほうがいい。
サービスを作る側に回ったほうがいい。
などという極端な意見がよく聞かれるようになりましたが、このような発言がまことしやかに語られるのは世界の中でも日本くらいなのではないでしょうか。むしろ、世界ではクラウドの登場により、本当の意味でのSIというものが必要とされる時代になってきていると私は思いますし、エンタープライズアプリケーション開発者もプロフェッショナルな本物の仕事のできる人は引き続き多くの需要があると考えています。
(追記)
AmazonもついにJavaのエンタープライズPaaSのビジネスに参入してきたようです。VMWare、Googleとの対決はどうなるのでしょうか。いずれにしても、従来のJava EE開発のスキルをクラウド上で活用できそうです。
