RIAをSIerの仕事道具として普及させるには
SIerで働いているが、RIAが今一流行っていない。Ajaxはいまだに様子見の段階で、要件上どうしようもないところだけ恐る恐る導入している感じだし、Flexも実案件で結構トラブルが起きていて今一みたいな風潮になっている。自分の身の周りだけの話かもしれないが、お客さんはRIAを望んでいるにも関わらずSIerがRIAを敬遠しているように感じる。
なんでなのか、ちょっと考えてみた。
SIerの技術要素を選択する際の判断基準を２つ挙げると工数と品質になる。
まず工数だが、リッチな画面の要件がどのくらいあるかとか、メンバーのFlexに対する習熟度とかあるので普遍的な数値ではないが、今までの経験から得た実感としてFlex開発にかかる工数はJSP/Strutsによる工数の3倍程度かかる。そして全体で見ると、リッチな画面の開発よりも、通常の範囲内の機能を持った画面の開発に工数がかさむ。
そのため、必然的に、リッチな機能が必要な画面のみRIAを採用し、それ以外の部分は従来どおりJSP/Strutsで開発するという選択をおこなうが、これはこれで覚えないといけない技術要素が増えるのでチーム編成を考える上で頭を悩ます種となる。また、リッチな画面が当たり前になると、お客さんは当然のようにそういう機能を要求してくるわけで、結合テスト終盤ぐらいになって突然JSPで作った画面を次から次へとRIA製品で置き換えていくような案件が一つのトラブルパターンとして最近よくある。
企業の基幹システムなんかのリッチな機能はほんの一部分しかいらないみたいなアプリケーションの構築でRIA製品が採用されるためには、リッチではない画面の開発をJSP/Strutsでの開発効率に近づけていくことが絶対必須だと思う。
次に品質だが、SIerのいう品質っていうのが何かというと、「低スキルなプログラマーを大量動員した時に最低ラインの品質を確保できるかどうか」ってことだと自分は思っている。普通、プロジェクトは、開発費用を抑えるために高スキルな技術者数人と低スキルな技術者大多数で構成される。プロジェクト内には、高スキルな技術者は必要最低限な数しかいない。
高スキルな技術者は技術要素を選択して低スキルな技術者に開発の仕方をガイドすることが主な役割となり、ドキュメンテーションと打ち合わせが業務時間のほぼ全てを占める。昔は内製のフレームワークの実装なんかもやっていたが、今は通常の案件で必要な機能がほぼすべてOSSとして存在しているのでフレームワークはそれを組み合わせるだけでだいたい出来上がってしまうため、プログラミングはほとんどせず組み合わせを考えることがメインの作業となる。プログラミングは低スキルな技術者だけがおこなう作業となる。なので、低スキルな技術者向けが使うことを想定してどうなのかという視点で技術は評価される。
で、こういう観点でいうと、開発環境の貧弱な現状のRIAはSIerの仕事道具としては選択しづらい技術にカテゴライズされてしまうのである。Flexの場合ベンダーが開発環境を整えていこうとしているものの、それでも画面開発をGUIツールでやるのは現実的でなかったりするわけで、Javaの世界のようにIDEのプラグインのコマンド一発でスケルトンコードがすべて吐き出されて、手作業では業務ロジックしか書かないみたいな状態にまで持っていく必要がある。
エンタープライズをターゲットにしたRIA製品は、開発環境を充実させること、とくにリッチではない部分の開発効率を良くすることに主眼をおくべきで、リッチではない画面が今まで以上に効率よく開発できればSIerのデフォルト技術がJSP/StrutsからRIAに一気に流れると思う。
Android Developer ChallengeのTOP50アプリ
http://code.google.com/android/images/adc1r1_deck.pdf
Android勉強しようと思って、公式サイト見てたら応募1788件の中から選ばれた50作品が紹介されてた。これ見てるとAndroid携帯が欲しくなってくる。既存のデスクトップPCでの利用を想定しているサービスと一見似ているんだけど、モバイル上で使ってみるとまるで別のエクスペリエンス、みたいな感じのやつが多いのかな。まあ、実際に使ってみないとなんとも言えないけど。
ドコモもiPhone獲得だったりAndroid携帯リリースとかやってるよりも、既存のシステムの開発環境を整備して開発者に解放していけば、もっと面白いアイデアが出てきそうな気がする。もうやってる？
ちなみに個人的には今使ってる携帯の一番不満なところってキーレスポンスの悪さだったりするんで、一番欲しいのは軽快に動く携帯だったりする。
セカンドライフなんかよりもっと上手に現実世界を再構築したい
音楽、映像、小説、演劇、彫刻。
優れた芸術作品には、永遠の命を持っている。
完璧な構成。完璧な構図。完璧な対比。完璧なシチュエーション。完璧な旋律。
普遍の真理に基づいて構築されているので、どうやっても崩せない。どの一部分をとっても置き換えが不可能である。
それらは偉大な芸術家たちが現実世界に対する深い観察から学びとった結晶である。
現実世界をWeb上に再構築せよ。リアルな世界を見ろ。感性を磨け。
セカンドライフなんて歪みまくってるよ。あんなん何にも美しくない。
もっと巧妙に、もっとでたらめに、全能感に溢れる世界を構築できるはず。
無関心な世界を破壊しろ。窮屈な世界から抜け出せ。
架空の国の架空の物語を誰かに聞かせてやりたいって奴は世界中に山ほどいる。
Google Developer Day 2008に行ってきたぜ
http://code.google.com/intl/ja/events/developerday/2008/home.html
面白かったよGoogle Developer Day。会場は満員で、どのセッションも立ち見だらけだった。肩書きがソフトウェアエンジニアだったりのいかにも技術者っていうGoogle社員がセッションを担当していて、プレゼン慣れしてませんって感じが全開で（良い意味で）、〜営業部長とかが出てきてセールストークし始めるIBMやMicrosoftのセミナーとは全然違う。
以下気になったところのメモ。
基調講演
3つのC（Client, Connectivity, Cloud）
- クライアントをよりパワフルに（Gears）
- コネクティビリティをユビキタスに（Android）
- クラウドをよりアクセスしやすく（Google App Engine）
Gears
- MySpaceで検索機能にGearsを利用しており、オフライン機能にとどまらないブラウザをよりリッチにするという面白い使い方をしている。
- Raise the bar of baseline mobile functionality
- ウェブが人やサービスを結びつける基盤へ
- ソーシャルサイトはVertical=縦に閉じている
- サイトオーナー、アプリ開発者のための共通基盤
- 現在、利用者：2億7500万、開発者2万、インストール可能アプリ5000万
- 話を聞いていて、将来的にはWebOS（＝Browser+AddOn）の一部になるコンポーネントなんじゃないかと思った。
Google Maps API for Flash
- 先月発表したばかりのAPI
- デモ失敗
Communities
- デベロッパー交流会
- 認定エキスパート
Google GearsからGearsへ
Webアプリの将来
- 1アプリケーションで1URLにするのが理想
- オンライン／オフラインのシームレスな切り替え
Firefox3対応は、Firefox3正式リリース（今月末）に合わせて公開できるのでは？とのこと。
Worker Poolのデモ
- 画面上のUIの動作とは別にバックグラウンドで演算処理が実行されるので画面が固まらない
- 実際にデモを見ると、おおおおおと思う
GearsMonkey
- Gears+GreaseMonkey
- GreaseMonkey経由でGearsを利用するので、サイトオーナーの許可無しにGearsが利用できる！！！
今後の展開
- Desktop API
- Notification API
- ポップアップが画面右下にブラウザのウィンドウとは別に出てくる
- File System
- 複数ファイルを同時にアップデート可能
- Large Upload
- Geolocation
- BLOB API
- バイナリデータをJavaScriptで扱うためのAPI
もうすぐGoogle Developer Day
Wifi情報端末として様々な形のガジェットが登場している。chumbyなんかはまだ日本では入手できないが、数年以内に数百万台出荷みたいな大ブームになるガジェットが登場してくるのは目に見えている。
デスクトップPCはなくなり、ノートPCやPDAや携帯はWifi情報端末の1つと位置づけられるようになる。そして様々なインターフェースを持つWifi情報端末で部屋やカバンの中が溢れかえるようになる。
で、そういう時代になったときに、それらの端末のオペレーティングシステムまたは開発プラットフォームとしてブラウザ+Gearsが活用されるんじゃないかとふと思った。
すでにコンシューマ向けWebサービスはPCでの利用を前提に考えていてはいけない。
来週のGoogle Developer Dayはそういう視点を持ってセッションを聴講してみたい。
http://code.google.com/intl/ja/events/developerday/2008/home.html
Webのヒエラルキー化現象はたぶん不可逆なものになる
先日のエントリーでWebのヒエラルキー化について書いてみたが、こういう現象のことをWeb3.0というそうだ。
ウェブ3.0と黒川紀章
http://japan.cnet.com/blog/sasaki/2008/05/27/entry_27001839/
ユーザーのもとに情報を再集約する仕組みは、検索エンジンやRSSリーダー、ソーシャルブックマークなどの試みの延長線上にある。
こうしたさまざまな試みの進化の先には、ライフログの概念も交錯してくる。非常に巨大なブルーオーシャンが待ち受けているように見えるが、しかし情報アクセスを高度化させるため、どの部分まで個人の行動や内面を取得して良いのかという存在論的な問題も浮上してくることになる。こうした進化はおそらく、激しい議論を引き起こすことになるだろう。
Web2.0というフラット化の状態は、Webの歴史で唯一のヒエラルキーの存在しない時代なのだろう。バージョン番号が偶数はフラット化の方向で、奇数はヒエラルキー化の方向でみたいには多分ならない。アナーキーであった幸福な時代は既に終わりを告げようとしていて、これから徐々に形成されていくであろう新しい秩序は、数百年後くらいにWebに変わる何かが出てくるまでは根本から覆ることはないと思う。そして、数百年機能させなければいけない世界全体で利用されるシステムの構築という、向こう見ずな試みに参加できるチャンスを逃す手は無い。
だから「Web3.0」なんていうネーミングはいかにも安っぽくて全然好きになれないし、現象をリアルに表現しているとも言えない。ジャーナリストである佐々木さんには、何か別のもっと的確な表現を考えてほしい。と書いてみる。
生活習慣や文化、美的感覚の違いによる地域性がWebでも顕在化してくる
5/17 ブンデスリーガ2008最終節
バイエルンミュンヘン vs ヘルタベルリン
カーンのブンデスリーガ引退試合であり、試合後に今シーズンのチャンピオンとなったバイエルンの優勝セレモニーがあったこの試合をテレビで見て度肝を抜かれた。プレーがどうのこうのとかではない。
映像の美しさが別次元に突入してしまっている。いやまじですごい。
あたかも印象派の絵画だったり歴史スペクタクル映画だったりを鑑賞しているような映像。荘厳で温かみがあり、その場の熱気が伝わってくる。色彩、カメラワーク、音響。すべてがこうでなくちゃダメというような一体感がある。
この映像を作り出したエンジニアが、普段どんな生活をしていて、どんな知的バックボーンがあって、どんな価値観を持って、何を表現しようとして、この映像をつくりだしたのか知りたい。
映画でいうと、日本、アメリカ、ヨーロッパ映画それぞれ異なる映像の美しさがある。根っこのところで目指している美しさが違う。そこには生活習慣だったり、宗教だったり、気候だったりっていう深層的な部分での違いが投影されている。首題のテレビ放送は、まさにヨーロッパ映画が持つ映像美をそのままサッカー中継に持ってきたような感じ。
日本の放送局やメーカーには、こういう質感を持った映像はつくれない。それは先ほども触れたが、技術的な問題ではなく、もっと文化的なところで最初から目指している美しさの基準が違うから。逆に、日本の持つ高精度な映像や緻密さは他の国では表現できない。
サッカーの醍醐味のひとつに、世界中でプレーされていて、各地域各国それぞれでサッカーをとりまく人や環境が全く違うところがある。ヨーロッパと南米ではもうレフェリングの基準からして違う。同じヨーロッパでもドイツ、イングランド、スペイン、イタリアそれぞれの国の定義したサッカーがあり、独自の観戦スタイルや放送スタイルがある。
Web上では物理的な距離は意味をなさない。だが、それでもインターネットが洗練されていくに従い、Webを利用する人間の生活習慣や文化、美的感覚の違いによる地域性が徐々に顕在化してくると思う。その時に世界から一目を置かれるような、技術的な部分でなくセンスの部分で誰も真似のできないようなWebサービスが日本で生まれているといいと思う。日本は世界に通用しない独自の言語を持つ国だが、そういう意味ではマイノリティであることは決してハンディキャップではない。
