Google App Engine上でJRuby on Railsを動かす

Google App Engine上でJRuby on Railsを動かす記事が気になっている。
以下メモ書き。

【元ネタ】
グーグルのクラウドがJava対応、JRubyも稼働か － ＠IT

ぽかぽか陽気 - ずっと君のターン

GMailが普及してもはやローカルのメールアプリは特に必要がない。
多くの日本の会社は、コンプライアンス重視と言い出してGMailなどGoogleのサービスを使わせないようにしているが、それでどれだけ業務の効率が落ちているだろう。

GAEはクラウド系サービスあるいはSaaSに位置づけられる。

従来のSIerは、販売したメインフレームを中核に、その上で動くCobolの業務システムを開発して運用している。
Web受託開発のSIerは、データセンターにあるサーバーに受託開発した業務系Webシステムを稼動させている。

GAEがまともに普及したら、ハード販売を中心に受託開発を行うSIer(IBMを中心とするメインフレームのメーカー)、サーバーのホスティングを中心とするWebに特化した受託開発のSIerはことごとく仕事が来なくなるだろう。

GAE上でWebアプリの開発がスタンダードになってしまったら、サーバーを買う必要もない。
必要なのは、Webプログラミングを中心とする技術力だけだ。
ユーザ企業に技術力があれば、SIerへシステム開発を受託する必要もない。

GAEでWebアプリがPythonだけでなく、Javaで動くのは上記の記事のように重要だ。
何故なら、GAE上でJRuby＋Railsが動作する環境になったからだ。
そうなれば、Webアプリをもっと速く作り、稼動させることができる。

エンタープライズなシステムをJRuby＋Railsで開発して稼動させるのは、もうすぐ普通になるだろうと思う。

WebブラウザのJavaScriptエンジン高速化がもたらすもの

「SaaSに追い風、桁違いに速い次世代Webブラウザたち」の記事を読んだ感想。

Ver３のFireFox、Safariは性能がすごくいいのは知られていた。
その秘密は何か？

そもそもWebアプリの弱点は、一つはネットワーク遅延で応答性が悪いこと。もう一つはHTMLコンテンツを動的に扱うJavaScriptエンジンが遅いことだった。

しかし、前者は、Ajaxと総称される非同期通信のテクニックが進化したことでほぼ解消されつつある。
Googleが編み出すサービス群がその良い例。

後者は、次世代Webブラウザに搭載されるJavaScriptエンジンが高速化することで、今後解消されていくだろう。

そして、それは何をもたらすか？

近い将来、殆どのデスクトップアプリはWebアプリへ置き換わるだろう。

例えば、Google Docsの表計算アプリケーションは、Web上でExcelっぽく使える。

メールソフトも今やGMailを使う人が殆どではなかろうか？
GMailならば、外出先でも携帯からでも閲覧できる。

上記2点とも、Ajaxによる非同期通信のおかげで、ネットワーク越しの応答の遅延が気にならなくなったということ。
ユーザがブラウザで閲覧している裏で、Ajaxが必死になってDOMを生成して、HTMLをレンダリングしている。

利点は、ネットワーク上の人たちと情報共有がすごく簡単になることだ。
使いこなせれば、もっとコミュニケーションを活発化できる。

Appleケア店員は優しかったヨ！

3ヶ月前に購入したお気に入りのiPodに、液晶に白いノイズが混じるようになってしまった。
先日、Apple心斎橋店に行く時があり、何とかしてもらえないか頼んでみた。

すると、購入1年以内だったということで、交換してもらえたヨ。
ラッキー♪

それ以上に驚いたのは、お気に入りのiPodに張ってある薄い透明のシールカバーをわざわざ外して、交換したiPodに張り替えてくれたこと。
セロハンテープを使って、やや手間取りながらも、丁寧に張り替えてくれた。

iPodは単なる音楽プレーヤーだけでなく携帯フォトストレージと化していたから、すごく大切にしていたからね。
Appleさん、ありがとう♪

お金ができたら、MacBookを買うかもしれないヽ(^o^)丿

最近のお気に入り

iPod classic(white 80G)を買った。
携帯音楽プレーヤーだけでなく、携帯フォトストレージとしても使える。
すごくイイ！

Web 2.0で一番重要なのは価値あるデータベース

　ベンチャー企業の代表者が解くWeb 2.0と経営の本質という記事で、「Web 2.0で一番重要なのは価値あるデータベースだ」という意見が載っている。

　Googleにしても、Amazonにしても、自分たちが持つ地図や商品のデータベースへつなぐAPIを公開することで、自分たちのサイトへのリンク、更には訪問者を増やすというビジネス手法を取る。

　この発想の根本は、データベースが重要なこと。そのデータベースへリンクさせるためにAPIの公開が必要だし、サーバーにアクセスが集中しても、その負荷に耐えられる仕組みが必要。

　その公開手法はオープンソースとは違うけれど、依然とは違い、自分たちのシステムの情報（の一部）を公開する方が実は利益になるという逆説。

　今後、インターネットを使ったビジネスの発想は、Webを通じて自社のデータベースへリンクするAPI公開にあるのかもしれない。

Ruby関西とiPod

　昨日、Ruby関西の勉強会に出てきました。

　「IE+iPod」「DRUM（ドラム）」「Ruby/TkORCA」「かずひこさんの初級者レッスン～継承と委譲」を聞いてきましたが、初級者向けで聞きやすかった。

　毎回、素敵な講演を用意して下さる講演者、会場準備担当者の方に心から感謝します。

　iPodにはまっている自分にとって、「IE+iPod」が一番興味深かった。

　Yahooの株式情報を自動検索させるとか、iTunesの曲からGoogleイメージ検索でジャケット画像を探して貼り付けるとか、使い方によっては色々と出来そう。Rubyのソースを見ましたが、Unixのシェルスクリプトみたいでそんなに難しそうには見えなかった。

　テキストファイルをWindows付属の音声認識で読み上げた音声ファイルをiPodで聞くサンプルは一番印象に残った。この使い方ができれば、通勤電車や歩いている時間を丸ごと勉強時間に当てることが出来る。朝の通勤ラッシュ時間は無駄な時間になりがちだから。

　cuzic さんは丁度勉強されているという中小企業診断士のテキストを音声ファイルにしていましたが、聞いてみたらお経のようで、慣れないと聞き取れないのは笑いました。

　Windows付属の音声認識コントロールパネル付属のSumは声質が悪い(^^)　音声ファイルはVectorでも買えるそうで、女性の声が一番聞きやすかった(^^)

　速聴は、脳内活性にいいそうです。でも、お経は勘弁だなあ(^^)

 　iTunesのクラスライブラリをRDoc形式で初めて見ましたが、講演者のcuzic さんが話したように、すごく綺麗な構造をしている。

　ライブラリ、アルバム、アーティスト等のクラスは、iTunesの表示メニューそのものに対応していて、メソッドもこんなものかな、とすぐに連想できる。
　COMって僕には印象が悪いのだが、iTunesの場合は勉強してみる価値があるかも。

　iPodの普及で、大量の音声データを持ち運べる環境が整ったことで、Apple自身も予想しなかった使い方が生まれている、という記事を新聞でも読んだ。

　落語をPodcastで無料配信して落語のマーケットを増やそうとする試みや、大学で生徒全員にiPodを配って英語リスニングに使ったり、予備校で簿記や資格試験の授業を音声ファイルで配ったりする例があった。単に音楽を聴くだけでなく、授業や勉強に使ったりもできる。

　テキストの音声読み上げは色んな可能性を感じる。MacOS8の頃から音声読み上げは簡単にできていたけれど、こんなこともできますねえ、ぐらいで、その頃は実用になるとは思えなかった。今は、iPodを使えば、歩きながら聞くことが出来る。現代のように、まとまった時間を取りにくいサラリーマンにとって、重要なツールの一つなのかも。

　一番欲しいのは、詩や本の朗読、ラジオドラマの音声ファイル。特に、詩は読むよりもリズム感があり、すごくイメージしやすい。ネット検索してみたが、まだ発展途上の状況で、まだ量が少ない。

　最近の僕のお気に入りは、下記の「今夜の一冊～湘南BeachFM　Relaxin'Mode 今夜の一冊」。

　金子みすヾさんの詩の朗読などもあり、すごくいい！

　童話や詩は、子供に本を読み聞かせるものだから、Podcastのような使い方が一番似合っている気がする。

Web 2.0メモ

　最近、巷で流行しているWeb 2.0のメモ。

Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（前編）

Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（後編）

　アプリケーションはOSではなくサーバーにあるべき。
　Windowsは古い。
　Googleが生み出すWebのサービスの方が、はるかに刺激的。

インターネットが既成メディアを脅かす

　今日の朝日新聞のオピニオン欄に、TBSと楽天の騒動に対する藤田晋氏と氏家斉一郎氏の二人の意見が記載されていた。意見が全く違いすぎるのが面白かった。

　氏家斉一郎氏は日本テレビ社長。内容に新鮮味はない。規制緩和で守られた官公庁の立場の意見にすぎない。

　対して、藤田晋氏はアメーバブログを作っているITベンチャー社長。
　現状のネット企業の強み・弱みを認識している。強みはIT技術をビジネスに展開できる能力に長けていること。これは誰でも知っている。

　弱みは、ライブドアとフジテレビのバトルから判明してきたが、ネット企業にはコンテンツがないこと。だから、楽天は欲しがる。AppleもiTunesで音楽コンテンツだけでなくビデオまで販売している。
　そもそもネット上の情報は信憑性が薄い。信用がない。だから、テレビ等の既成メディアのコンテンツがあると、少なくとも信用価値は高まる。それによるアクセス数、広告収入、等のビジネス上の価値。

　何故、コンテンツを欲しがるのか？
　「楽天は本当にAppleに対抗しようと考えたのか？」の記事では、もっと泥臭い事実を指摘している。
　
要するに、もう楽天の「ショッピングモール」というビジネスは、寿命間近なのだ

　楽天にしてもライブドアにしても、ビジネスの基盤ははるかに脆い。

　そんな弱みを持ちながらも、藤田氏のチャレンジャー精神が興味を惹いた。

　経営実態よりも高い株価は、批判もあろうが、なにかをやってくれるのではという期待感の現れ。その期待にこたえず何もしないのは、仕事をしていないのと同じだ、と。
　
　全くその通り。その期待に対する経営責任を背負いながらビジネスをやっている。
　既成メディアにいるビジネスマンから、こんな言葉は出てこないのではなかろうか？

　最近、メディアとネットが反発している背景には、その企業を支えるビジネススタイルが根本的に違うからだろう。
　木村剛のBlog「マスコミはインターネットが嫌いなのか？」を読むと、少なくとも、ブロガーと既成メディアの間に緊張関係が存在している事実が読み取れる。
　しかも、既成メディアは、世の中の人達の意見を吸い上げて、展開していく能力がなくなってきている。
　既成メディアは現状に安住しすぎて、ムーブメントを起こすだけの力をなくしつつあるように見える。

インターネットが及ぼす変化とは？

　「フォーサイトクラブ・セミナー「ウェブ社会『大変化』への正しい対応・間違った対応」梅田望夫さん講演ログ」を読むと、以前書いた「インターネットは高速道路」の内容を煮詰めている気がする。

【１】インターネットは能力増幅器

　計測データや考え方のフレームワークは、Googleで検索すれば、少なくとも集めることは出来る。インターネットは能力増幅器、というフレーズは鳥肌が立った。
　インターネットをうまく利用できれば、簡単に飛び級できる。梅田さんの話によれば、若い人ほど、そのツールをうまく使いこなせるし、それによって過去の世代よりも大きな可能性を秘めていること。

　ただ、これから問われるのは、知識よりも、論理的に自分の考えを組み立てて、仮説を作り出す能力だろうか？

【２】インターネットが人間関係の精神的距離を狭める

　上記の内容は、大前研一と似たようなことを言っていたなあと思う。
　「考える技術」を立ち読みしたけれど、こんな一節があった。
　大前研一の理論を研究している人達との会合で、ニュージーランドやヨーロッパでも、彼だけでなく奥さんの趣味まで知っていたことに彼は驚き、そして、初対面なのに色んな話が出来て、以前から友達だったような懐かしい雰囲気を感じた、と。
　この感覚は僕も分かる。メーリングリストやインターネット上のコミュニティで知り合った人達とネット上でやり取りした後、リアル世界で会ってみると、あまり違和感なく、以前から友達だったように、すぐに親しくなれる。

　インターネットがもたらす波及効果はまだまだあろうが、この2点が僕には、自分自身の経験も込めて、大きく感じる。

「リーンソフトウェア開発」～アジャイルとウォーターフォールを繋ぐミッシングリング

　とある勉強会で「リーンソフトウェア開発」第4章「できるだけ速く提供する」を発表した。
　レジュメを作りながら、そして、議論しながら、色々と考えさせられる所があった。

【１】「リーンソフトウェア開発」の読者層は、オブジェクト指向や反復型プロセスを知らない計画主導プロセス経験者である

　XPの解説本を読んでも、原則やプラクティスの本質が何なのか、ペアプロやイテレーションなどのプラクティスがどのように関連付けられているのか、分かりにくい。
　この本では、２２個の思考ツールを使ってアジャイルの本質を説明している。4章では、制約理論や待ち行列、リトルの法則などを使って、計画主導プロセスのどこに弱点があるか、アジャイルプロセスで気を気を付けることを明らかにしている。
　オブジェクト指向開発者やアジャイラーが当たり前に思っていることと、計画主導経験者がどうしても理解できないギャップを埋める本ですね、と仰った人がいたが、その通りだと思った。

【２】アジャイル開発の優位性を、もっと理論的な説明で補強できないか？

　制約理論や待ち行列、リトルの法則などを使って論理的に説明を組み立てているのは面白かった。
　でも、細かく疑問をぶつけてみると、アナロジーは分かるのだが、しっくりこない点がある。自分が説明できるほど理解し切れていないのかもしれないけど。
　もう少し理論的に補強できないだろうか？　また、他の理論を使って、説明を補強できないだろうか？

　久しぶりに面白い本だったな。

概念に正しい言葉を当てはめないと混乱の原因になる

　要件定義のプロセスで、コンサルタントが作った要求定義書から不明点を洗い出している時、「概念に正しい言葉を当てはめないと混乱の原因になる」ことを経験した。

　とあるシステムの要件で、データを論理削除する処理があったのだが、「この文脈では論理削除と言うべきではなく、法律用語に従って、廃棄とか廃止と呼ぶべきだ」と指摘を受けたことがある。
　論理削除という言葉では、削除という意味合いが強すぎて、本来は、データが別の異なる状態に移ったことを強調すべきだ、ということだった。

　要件定義では、用語集を作るのが大事ですが、その理由をもう一度再認識した。

　ネーミングは難しい。
　だが、XP祭りで会ったXPerたちはネーミングが上手かった。
　例えば「ふりかえり」「ペアボード」「ニコニコカレンダー」「あんどん」のように。

　以前、数セミで、数学者よりも物理学者の方が概念に対するネーミングがうまい、彼らは抽象的な方程式に隠れている物理的意味を知っているからだろう、みたいな記事があったのを思い出す。

　最後に関係ないけれど、ウイスキー「Early Times」がありますが、どのような言葉を当てはめるべきか？
　僕は、「早すぎた日々」などとトンチンカンな訳をした。
　後輩の子は「若気の至り」と訳していた。さすが文系出身(^^)

ITの技術革新はOSよりもWebソリューションへ移っている

M$が次期WindowsOS　Vista　を来年に売り出すらしいが、盛り上がってないように見える。
理由は、OSの技術革新の衝撃が薄くなっていて、むしろGoogleのようなWebソリューションへトレンドが移行しているからではないか？

WindowsOSやOfficeのバージョンがUPしたからといって、我々ユーザの環境が劇的に変わるわけでもない。バージョンアップを煩わしいと皆呟いている。
ActiveDirectoryの導入で余計に手間がかかっていないか？

むしろ、Googleが生み出すサービスの方が我々のWebの使い方そのものを劇的に変化させている。
例えば下記のサービスがある。

１．容量１GものWebメールサービス　GMail
２・デスクトップ検索サービス　GoogleDesktop
３．地図検索サービス　GoogleMaps

【１．容量１GものWebメールサービス　GMail】
GMailをまず使ってみて驚いたのは、勝手にリフレッシュし、メール一覧を更新してくれること。
さすがAjax。

【２・デスクトップ検索サービス　GoogleDesktop】
以前まで、ローカル内のテキスト・Office・PDFファイルを検索できるようにするために、Namazuをインストールし、定期的にバッチファイルでインデックス検索させるようにしていた。
ActivePerl＋Kakashi＋Namazuを入れて、日本語で検索できるように設定するために結構手間取った。
GoogleDesktopなら、ファイルだけでなくメールまで検索で来てしまう。

【３．地図検索サービス　GoogleMaps】
GoogleMapsは面白い。
市販の地図情報システムは今だにC/Sアーキテクチャの古いシステムが多く、有料のため使っていて楽しくない。
記事「渺望と俯瞰　：keyhole　が　3D地図と検索を関連づけるか：Google　Earth　スタート」ではGoogleMapsの威力を下記のように説明している。

（引用開始）
(前略)
GoogleMapを見ればわかるが、日本の地図表示・検索サイトよりも遥かに豊かな情報が関連付けて閲覧できる。
１．Mapまたは衛星写真
２．現在のレストランなどのWebコンテンツ
の２つを、検索エンジンが、位置座標と関連付けてView+スクリプト表示しているだけである。
一方、多くの一般の地図サイトは、なんと時には有料で、サーバーに入力させて、（労力と費用を使って）、ほとんどのレストランが参加していないレストランガイドサイトとなっている。
このGoogleMapと同様の機能をMyサーバー上に、実現できるのが　GoogleWebAPIである。思わぬアイデアが出現しそうなので、お楽しみである。
（引用終わり）

つまり、日記を手軽にUpできるBlogのように、自分オリジナルのレストラン地図とか、自分の地区の選挙マップとか作れる。

例えば、GoogleMapsEditorを使えば、こんなに簡単に地図が作れてしまう。

なにわのお笑い劇場：ワッハホール

他にも、AmazonのWebサービス、ライブドアが提供したWikiサービス、Skypeもワクワクする。

次から次へと現れるWebソリューションに触れると「IT技術は、コスト削減のようなつまらないことに使われているが、本来は、新しい産業を生み出すことに使われるべきだ」とXP祭り2005で講演したM$の萩原さんの意見を思い出させる。

XP祭り2005の公式記事

XP祭り2005の公式記事は下記が一番詳しい。

http://itpro.nikkeibp.co.jp/article/NEWS/20050905/220618/
XPの祭典「XP祭り2005」開催，「顧客にすらわかっていない要求をいかに引き出すか」が大きなテーマに

XP祭り2005の感想

9/3にお台場で開かれたXP祭り2005に行ってきました。
面白かったー。
朝5時に起きて新幹線で東京へ向かい、夜12時まで講演＋懇親会＋2次会で騒いだので、1日がすごく長く濃かった。
代表の倉貫さんほかスタッフの皆さん、感動をありがとう。

受けた刺激があまりにも多すぎて整理し切れていないので、感想を箇条書きで残す。

【XP祭りの会場　お台場】
「お洒落なお台場」のイメージがあったが、場所はちょっと離れたオフィス街。
会場は、円形劇場の座席に講演者が舞台で発表するため、場の雰囲気がどんどんヒートアップしていく感じだった。
スタッフによると200人もの来場者が来たとのこと。遠く沖縄（！）から来たエンジニアもいた。
大阪から来たエンジニアは、僕を含めて6人ぐらいだろうか？

【平鍋さんのProject Facilitation】
最近よく聞く「見える化」のお話。
ソフト開発はプロセスも成果物も見えにくいという難点を解決するために、こんな手法を考えてみました、という話。

ビルドが失敗したら赤ランプが付く「ソフトウェアあんどん」。
開発者の気分を1日の最後に赤と青でカレンダーに張っていく「ニコニコカレンダー」。
こういうツールがあると、開発者のモチベーションも上がるだろう。何よりも楽しい。

劇団ぺけぴー（XPを日本語で読み直したみたい(^^)）による朝会のアンチパターン例は面白かった。
・一人の話が長い
・リーダーがメンバーの話を遮る
・誰も喋らない
朝会だけでなく会議でも、場の雰囲気が建設的でないケースによく当てはまる。

PFの価値や原則、アンチパターンの解決方法など、もう少し詳しく聞きたかったなあ、というのが率直な感想。

【ひがさん】
今日のひがさんはオールバックの金髪に、黒Tシャツとジーパンでカッコイイ(^^)

講演する時は、会場の雰囲気に呑まれないように「スター」になりきるために、いつも外見を大きく変えるらしい。他の講演者がひがさんのなりきりメガネを借りてました。

業務マニュアルを作ることで上流工程を進める話は興味深かった。

僕の現場では開発プロセスそのものが標準化されていないため、ひがさんのやり方がおそらく一番しっくり来る気がする。
きちんと仕様書が揃った環境でないとプログラミングできない若手がいるし、マニュアルや仕様書が最終的に納品物に含まれるから。

でも、話はXPにあまり関係なかったかも。

【ディスカッション】
豆蔵の荻本さん、M$の萩原さん、Seasarのひがさん、関さん、平鍋さんを交えて、言いたい放題のディスカッションも面白かった。

ひがさんも関さんも萩原さんも皆揃って、フレームワークは嫌いだ、という発言はビックリ！
理由は「俺様が作ったフレームワークを、下々のPGに押し付ける」のが嫌いらしい。
「メンバーがフレームワークとアプリケーションのチームに分かれるのが嫌だ」
「アプリ開発者が見つけたFWのバグをすぐに直せない。だから、そのFWのバグを回避するようなぐちゃぐちゃのプログラムを書いてしまい、後でメンテナンスするのが大変」
という関さんの話が最も率直だった。

M$の萩原さんの話が興味深かった。

「私はソフトウェアアーキテクトであってITアーキテクトではない」
「アジャイルはソフトウェア工学ではない。工学的基盤の上でアジャイルのプラクティスがあると理解している」
「今の私の興味はSoftware Factoriesにある」

「個々の日本人は技術者として能力は高いが、集団になると質が落ちる」
「欧米人はマネジメント能力が比較的高い」

ソフトウェア開発の動機は何ですか？というコメンテーター倉貫さんの質問に対し、M$の萩原さんの答えが一番印象に残った。

「ITを使って革命を起こしたい」
「現在は鉄道が普及し始めた時代と同じ。百貨店は鉄道という産業が興隆して作られた。鉄道によって、消費都市と生産都市が結ばれ、都市の拠点に百貨店が作られて、新しい産業ができた」
「ITも同じで、ITの普及によって新しい産業を作り出せるはず。今はコスト削減とかつまらないことにITを使っている」

「ソフトウェアで世界を変えたい」と言った(はずの)ビルゲイツの言葉を思い出させる。
ITエンジニアもこれぐらいの気概を持たないとね。

最後に、劇団アンプラーズ（Anti-Practiceからひねたらしい）の活劇が面白かったので、2コマほど載せます。関西人ならボケツッコミを入れて、もっとひねることができるかも。

弟：あにきー、ペアプロって何だ？
兄：ペアプロっていうのはな、ペアで入る風呂のことなんだよ。





The End

IT業界は残業が多いのですか？

　今日、母校の大学へ会社説明会に行ってきました。
　3回生の人から
「IT業界は残業が多いと聞いたのですが、本当ですか？」
と尋ねられて、返答に正直困りました(^^;)
　この業界のビジネスマンは、後輩から上記の質問をされた時、どのように答えているのだろうか？

　僕の少ない業界経験では、1年に1回は修羅場が津波のようにやって来る。終電帰り、休日出勤、徹夜の開発が1ヶ月くらい続いて、本番システムリリース後、ようやく落ち着いて元の生活に戻る。初めて徹夜で作業させられたときは、皆さんこんな安月給でよく仕事しているなあ、と他人事のように思っていた。

　この業界、1ヶ月200時間労働なんて当たり前。
　はぶさんの本
では「月40時間程度の残業が3ヶ月続いたくらいで過労死なら、この業界の人間90%は死んでいます」と書かれていますが、同感。
　青色ダイオードの中村修二さんは、その業績にもかかわらず低収入だったため、「スレイブ中村」と言われたそうだが、IT業界で働いている人達も奴隷と言われても仕方ないのかもしれない。

　学生さんには、「確かに残業する時はありますが、普通は1時間程度の残業で退社できますよ」とかわしておいたが、最初から最後までそんなプロジェクトは滅多にない。
　学生さんにこれだけIT業界の評判が悪いと、今後、優秀な頭脳はこの業界に入って来ないかもしれない。

＃余談ですが、最近の日本に犯罪が多いのは、日本人男性の働きすぎに原因があるんじゃないかと思う。
＃つい20年前までは、こんなに残業して働いている人はそんなに多くなかったのでは？
＃親子夫婦そろって朝ご飯、夕ご飯を毎日取っている日本人の家庭って、今の日本に存在するのだろうか？
＃多分、存在しないと思う。
＃殆どの日本人の家庭は壊れていると思う。多分、普段は母子家庭になっている。最近は共働きが主流だから、たまたま一つの住居に住んでいるだけで、皆バラバラに生活していないか？
＃そんな生活は人間的（むしろ、本能として自然）なのだろうか？　子供の成長にとって悪い影響しか与えていないのではないか？

　経営者だけでなく、現場のエンジニアも今の環境を改善していくことを考えないと。

システム開発のボトルネックはメインフレームに有り

　システム開発のボトルネックは、メインフレーム（ホスト）の存在そのものにあるのではなかろうか？
　JavaでWebシステムを開発していると、いつもそんなことを感じてしまう。

　どこの大企業に行っても、必ず10年以上稼動し続けているメインフレームが既に存在している。メインフレームなしでは企業活動そのものが存続できないようだ。最近の流行であるそのメインフレームをオープンシステムへリプレースすることは、どこの大企業でも殆どありえないように見受けられる。
　そもそも何故メインフレームが存在するのか、本当の理由を僕は知らないが、とあるBlogでは、「企業の基幹システムは最終的に財務諸表を作るために存在する」と書かれていた。
　しかし、財務諸表や損益売上決算書などは、オープン系システムでできないのだろうか？

　普通、どこの大企業でも、メインフレームは顧客データや請求・契約などの会計に関するデータを管理している。つまり、企業にとって死活的に重要なデータは、必ずメインフレーム内で管理している。
　いくらOOAをフルに使ったWebシステムを作ったとしても、Webシステムは、集めた受注データをホストへ送り、入出荷や請求のデータをホストからもらうだけ。業務的には、入り口のシステムに過ぎない。
　Webシステムがダウンするのは当然困るが、企業活動そのものが止まってしまうわけではない。

　僕がメインフレームを毛嫌いする理由は、OO技術者にとって、メインフレームがブラックボックスだから。メインフレームでデータをどのように加工し出力しているのか、全く意味不明だから。

　更に、ホストとのやり取りのために、無駄なインターフェイスが必要になる。
　例えば、受注データをリアルタイムにホストへ送信したり、月次請求や四半期決算のデータをホストから特定の日に受信する処理がある。
　仕組みとしては、ホストはバイト長データしか扱えないため、バッチプログラムがバイト長データを変換してRDBのワークテーブルに一旦保管し、Javaが扱うテーブルへ移し変える。そのプログラムは、典型的なCのプログラムで、オブジェクト指向以前の古い設計に基づく。しかもテストしにくい。

　オブジェクト指向をフルに使った設計やオープンソースのフレームワークを適用したオープン系システムを開発しようとしても、結局、メインフレームとの整合性を取るためのシステムテストがボトルネックになる。
　何しろ、受け入れテストに必要なシナリオやテストデータを洗い出し、実際の業務をシミュレーションするために、1週間とか1ヶ月も時間を費やす。オープン系システム内部で閉じたシステムなら、システムテストは楽なのに、ホストと連携するテストを行うために、無駄なコストがかかる。

　「メインフレームはオープンシステムに取って代われる」という記事を随分昔から見てきたけれど、未だに実現されているとは思えない。それらの記事は、単なるデマだったのだろうか？

【参考記事】「5年後，メインフレームはなくなる」　日経コンピュータ2003年3月24日号

　IT業界に入って、結局いつもぶち当たる壁は、ORマッピングとメインフレーム。
　それらを再考し直すと、結局、メインフレーム・RDB・オブジェクト指向プログラムの3つはどれも思想的に全く異なるシステムであって、それらのインターフェイスを合わせる為に、ORマッピングやバッチプログラムという無駄な中間レイヤーが必要になる。
　企業システムとは、結局、これら３つの相容れない混合システムであるべきものなのか？
　多分そうでないはず、と思うし、皆そう感じているのではなかろうか？

　メインフレームが今もなお存在する理由は、IBM・NEC・富士通・日立等のような大手ベンダーが過去あるいは今までメインフレームを製造し続けてきたからだろう。
　メインフレームというハードを中心にしたビジネスが長らく続き、そのビジネススタイルからなかなか脱皮できない所に原因がある気がする。

大いなる力には、大いなる責任が伴う

　プロジェクト管理者にいざなると、割り込みの仕事に忙殺されて、モチベーションが落ちてしまう時がある。
　そんな時に、自分の使命（？）を思い出させて、奮い立つ言葉を見つけた。　

　「大いなる力には、大いなる責任が伴う」

　スパイダーマンが亡き叔父さんから言われた言葉。
　カッコイイ。。(^^)
　確かスパイダーマン１で、スパイダーマンとなった主人公の乱暴な振る舞いに見かねて忠告した場面だったように思う。
　
　プロジェクト管理者になると偉くなった気がするが、実際はそんなことはない。自分がプログラミングすれば早いのに、メンバーにお願いしてプログラミングしてもらっている。理由は、リーダーがプログラミングに携わるとチームが回らなくなるから。
　過去のプロジェクトを思い出しても、リーダー自らが実装していたプロジェクトは殆ど破綻していた経験がある。

　自分ならメンバーの2倍以上のタスクはこなせる自信はあるが、それを内に秘めて、チームの人数分の責任を感じて、チームを回している。
　その責任の重さに疲れる時があるけれど、その言葉を肝に銘じていると自分がスパイダーマンになったような気がして、何故かやる気が出てくる。

　しかし、自分も単純だよなあ(m_m)

「ソフトウェア企業の競争戦略」

　「「ソフトウエア企業の競争戦略」」の本が、ここやあそこに紹介されていた。
　内容は、ソフトウェア・ビジネスとして成立させるために必要なことは「製品とサービスのハイブリット形態」である、ということで興味津々。しかし、立ち読みしてみたが、いまいちピンと来なかった。

　ソフトウェア・ビジネスは製造業や小売業などのサービス業と異なるのではないか、と漠然としたイメージは常々持っていたが、本質はまだ分からない。
　僕の少ない現場経験を整理すると、システム開発は普通の製品開発と異なるプロセスなのに、現場の環境が古いため、ちぐはぐな印象をずっと持ち続けている。
　例えば、いくらJavaでWebシステムを作ったところで、請求処理など一番大事な基幹システムはメインフレームで動かしているため、データ転送で無駄なインターフェイスを作ったり、オブジェクト指向技術が徹底できなかったりする。
　更に、Webチームとメインフレームチームに分かれているため、Webチームがいくらオブジェクト指向に則った開発プロセスを応用しても、旧式プロセスでやっているメインフレームチームと共同作業せざるを得ない。
　又、日本のITビジネスは土建業界のような下請構造で成立しているため、いくらアジャイル開発をやろうとしても、ウォータフォール型プロセスから脱却できない。
　この辺りの矛盾をきちんと説明しているのか、と思ったがよく分からなかった。どこかにいい本はないのだろうか？

日本のIT産業は国際競争力がない

　「日本のソフトウェア産業は競争力がない」という記事を読んで、自分がいる日本のIT業界の現実を改めて思い知らされた。

　貿易収支をみれば一目瞭然なのだが、「2000年のソフトウェアに関する日本の輸出額はわずかに90億円であり、9189億円もある輸入額の１％弱しかない」。2004年でもそう変わらないだろう。　
　この事実は、日本のIT産業は海外勢と競争できるだけの財力も体力も知力も欠けていることを示している。

　中国やインドから発注されたシステムを日本で開発しているのか？
　日本で作ったソフトウェアをアメリカへ輸出しているのか？

　いずれも答えはNoで、現状は正反対。
　日本から発注されたシステムを主に中国で開発しているのが普通。
　アメリカで作られたハードとソフトを日本が輸入しまくっているのが普通。

　冷静に考えると、日本のIT業界の将来はやばそう。
　青色ダイオード発明者の中村修二さんは「今後の日本が生き残る道は、アメリカのような独創性ではなく、中国やインドのようなコストの安い製造体制でもなく、短期間に試作品を作り上げる所にある」とどこかの本で主張していたが、日本のIT業界にそのような道はまだ残されているのだろうか？

ウォーターフォール型開発は日本の業界構造と表裏一体

　「ソフトウェア開発におけるパラダイムシフト」の記事を読んで、日本でウォーターフォール型開発プロセスが幅を利かせているのは、大手SIerにとって土建業界のように階層化された業界構造が好都合な開発モデルだから、という一節にすごく納得した。

　元請から下請まで5層もの階層構造にするから、元請は上流工程と称して、要件定義しかやらない。しかし、詳細設計で初めて、仕様漏れが見つかるのが普通。結局、仕様漏れが積み重なってデスマーチ・プロジェクトに陥るのではなかろうか？
　最近は、最下層の下請は中国へ流す。だから、言語のコミュニケーションギャップも加わり、より問題が複雑になっているように思う。
　
　「アジャイル開発は元々日本的なものだ」という上記記事の主張は、なるほどと思わせる。完璧な計画を作って進めるスタイルは、どう見ても西洋式。トップダウンで物事を進めるよりも、ボトムアップのプロセスの方がはるかに日本的。
　そうならない理由は、結局、ウォーターフォール型開発プロセスが大手SIerのビジネス構造に組み込まれているからだろう。

　アジャイル開発の方が利益に直結するように、自分たちのビジネス構造を変えていかなくては。

インターネットは高速道路、そして大渋滞 part2

　別の記事「インターネットの普及がもたらした学習の高速道路と大渋滞」を読んで、僕がかつて生きてきた時代と現在が全く違う環境であることを再認識した。
　記事では、「この10年のITの進化とインターネットの普及によって将棋の世界の何がいちばん変わったか」という問いに対し、羽生名人の下記の話が載っている。

「将棋が強くなるための高速道路が一気に敷かれたということだと思います。でも、その高速道路を走り切ったところで大渋滞が起きています」

　つまり、「ノウハウの共有と迅速な公開」と「インターネットを介して強敵との対局機会を常に持つことができる」環境が突然できあがったことにより、状況は下記のように変わった。

「将棋の駒の動かし方すら知らない小学校高学年生が5年くらいでプロ棋士にまで駆け上がる」ということが将棋界では起きているそうなのだが、そのことは、天才・羽生善治をもってしても、
「自分たちの世代の感覚からすると、全く信じられないスピードなんです」
ということになる。

　では、大渋滞の意味を問われて、羽生名人は下記のように答えている。

「確かにそのレベルまでは一気に強くなれるのだが、そこまで到達した者たち同士の競争となると、勝ったり負けたりの状態になってしまい、そこから抜け出るのは難しい。一方、後ろからも高速道路を駆け抜けてくる連中が皆どんどん追いついてくるから、自然と大渋滞が起きる。最も効率のよい勉強の仕方、しかし同質の勉強の仕方で、皆が、高速道路をひた走ってくる。結果として、その一群は、確かに一つ前の世代の並のプロは追い抜いてしまう勢いなのだが、そうやって皆で到達したところで直面する大渋滞を抜け出すには、どうも全く別の要素が必要なようである」

　この記事には、時代とか生き方について考えさせられた。
　自分が過ごした80年代は、根性論真っ盛り。授業中に先生が生徒を殴るのは当たり前だったし、運動中（特に野球）に水分補給は厳禁だった。（今じゃ考えられない(@_@)）
　でも今では、受験勉強やスポーツのノウハウなんて、インターネットでいくらでも探せるし、掲示板やMLの対話で得られる。
　将棋だけでなく、10代の勉強も同じ状況が起きているのではないか？

　その果てが、高校生・大学生の就職難だったり、オーバードクターだったり、公認会計士試験に受かったのに就職できない合格浪人だったりする。
　いずれも、前の時代に「良い」と言われていた生き方に従った真面目な人たちが、突然、生き方のルールが変わった現状に翻弄されている印象を受ける。
　現在の生き方が変わってしまったという事実に気づかない人たち、そして古い時代の生き方に忠実な人に教わっている人たちが一番苦労しているのかもしれない。

　結局、インターネットという高速道路で取得しやすい技術や知識、資格よりも、マネジメント等のようなメタな知識が求められているのかもしれない。
　インターネットという高速道路を使って追いかけてくる人たちとの競争と大渋滞を避ける生き方は何か？が問われている気がする。

インターネットは高速道路 part1

　「インターネットは高速道路」を読んで、インターネットの環境があれば技術力を伸ばせる可能性がある事を改めて痛感した。

　その記事では、「(人の成長に影響を与えるものとしての)インターネットは、高速道路だ」という一節がある。
　例として、Perlのハッカーが、昔は力技満載のスパゲッティ・プログラムしか書けなかったのに、インターネット上にある優れたソースコードを参考にしてどんどんプログラミング・スキルを伸ばしていったという話が載っている。
　他方、20年間のキャリアを持ったあるベテランプログラマがC言語で書いた最近のソースは、20年のキャリアを感じさせない力技ごり押しのソースコードだったという。
　記事では、二つの例を下記のようにまとめている。

片や数年で誰もが参考にするコードを書くハッカーに育ったかと思えば、20年経っても当時のままというプログラマもいる、彼らの決定的な違いは何だろう?
個人のセンス、能力?
いえ、それは成長の過程のなかにインターネットというメディアが存在していたか否かが決定的なのでした。

　プログラマにとって、プログラムを書くのと同じくらい、プログラムを読むことは大事だと特に最近思う。
　Javaの場合、フレームワークやライブラリを駆使したサンプルソースがいくらでもあるし、デザインパターンやリファクタリングでソースの構造を見通しよくする技術紹介がインターネット上にいくらでもある。DIコンテナやアスペクト指向等の最新の技術動向にもすぐに触れられる。
　だから、Javaプログラマは若い人ほど成長するスピードが速いように感じる。インターネットさえあれば、10年前のJava黎明期からやっている人と対等に話せるレベルまで駆け足で登り詰めることはできるから。

　でもC#やCの場合はどうなのだろう？Web系ではなく組み込み系はどうなのだろう？
　Java/PHP/Perl等のWeb系システムは、安いハードにオープンソースのフレームワークを組み合わせる技術力さえ磨けば、誰でも実現できる。でも、組み込み系の場合、高価なハード（例：大企業の家電製品）と密接に絡んでいると、いくら書いても動作確認できない。Javaよりも状況が異なるのかもしれない。

　IT業界に入ってJava一筋だけど、技術はまだまだ面白い。

SharpReader使ってます

　お気に入りのBlogを読むためにSharpReaderを使ってます。
　最近、あちこちの場で知り合った同じ業界の人たちのBlogを読むためです。
　Freeの割には、Outlookに似ているので使い勝手はいいです。
　.NET Framworkをインストールしないと使えませんが。

画面はこんな感じ