2009年5月アーカイブ

ちょっと思いついた比較的軽めの話題について、気軽に書き込んで行くためのミニブログを、tumblr で始めてみました。

kimada's tributary weblog

タイトルのtributaryという単語は、このブログを本流と例えた場合の、「支流」というのイメージしたものです。

tumblrは、アカウントを作って、その瞬間に始められるので、まだ、ブログを持っていない方が、ちょっと試してみようという感じで、やってみるのもいいかもしれませんね。

現在、多くのWebアプリケーションは、Ajaxと呼んでいる、一連の高度なJavaScriptの応用技術によって、リッチなユーザインタフェースを持っています。クライアント側でのプログラミングを行わず、プレーンなHTMLだけで構成されているものはほとんどなくなって来ています。そんな中、ここ最近は、さらに進化した、クライアントサイドのデスクトップアプリケーションとして動作するRIA技術が、注目されています。

RIA技術の代表的なものとしては、以下の3つが挙げられます。

• Adobe AIR
• JavaFX
• Microsoft Silverlight

この中で、Adobe AIRについて、ちょっと調べてみました。とりあえず、AIRを選定した理由にはあまり深い意味はなく、これまでのWebアプリケーション開発技術をそのまま引き継いだものなので、JavaEE系を始めとする、多くのWebアプリケーション開発者が、比較的入りやすいのではないかといったところです。

Adobe AIRのアーキテクチャを分類すると、以下の3パターンに分けることができます。

• Ajaxベース
• Flexベース
• Flashベース

この中で採用するアーキテクチャを選択する場合、企業向けのアプリケーションを開発しているJavaEE系の開発者の場合は、まず、直感的にAjaxベースにすることが多いでしょう。「Ajaxベース」の技術要素を整理すると、以下のような感じです。

• 開発言語
  HTML + CSS + JavaScript
• 実行環境
  Adobe AIRランタイムに組み込まれている、WebKit HTMLエンジン上で動作する。
• 開発環境
  
  • 無料で使えるもの
    • Adobe AIR SDK + テキストエディタ
    • Aptana Studio(Eclipse + Aptana用Adobe AIRエクステンション)
  • 有料のもの
    • Adobe Dreamweaver CS3＋Adobe AIR Extension for Dreamweaver CS3

ここから見ると、従来のブラウザ上で実行されていた、Ajaxアプリケーション開発のスキルが生かせるという印象を持つことができます。あと、無料で使える開発環境でも、今までの開発作業と、あまり変わらずに行けそうな感覚もありますね。

では、「Flexベース」の方はどうでしょうか。こちらも、同じ観点で技術要素を整理してみます。

• 開発言語
  MXML + ActionScript
• 実行環境
  Adobe AIRランタイムに組み込まれている、Adobe Flash Player 9の仮想マシンで動作する。
• 開発環境
  
  • 無料で使えるもの
    • Flex 3 SDK + テキストエディタ
  • 有料のもの
    • Adobe Flex Builder 3 Professional(Adobe Flex Builder 3.0.2 Professional Eclipse Plug-in)

FlexはふつうのGUIアプリケーションを、Flashコンテンツとして開発するためのフレームワークです。コンパイルすると、MXMLもActionScriptに変換され、最終的にはSWFファイルとなります。
すでにFlexでアプリケーション開発を経験しているのであれば、迷わずこちらを選択するでしょう。
未経験の場合は、MXML、ActionScriptという「独自言語」を習得しなければならないことが気になるところかと思います。それに関しては、HTML、XML、JavaScriptがわかっていれば、容易に習得できるので、あまり重要な条件ではないでしょう。
そういうことだけでなく、例えば、以下のようなことも考えた上で、総合的に判断することが必要です。

• 現在、Ajaxベースで、効率の良い開発ができているか?
  WebアプリケーションのAjaxに比べて、明らかにJavaScriptのコーディング量は多くなるので、そのあたりのことも考慮しておくべき。稼働環境が、AIRランタイムのWebKitエンジンに限定されるので、
  • クロスブラウザの考慮が必要ない
  • AIRやFlushで用意されているAPIが使える。
  といった部分によって、開発しやすくなる部分はあると思われる。
• 要件として、Flashの機能が必要かどうか?
  クールなGUIが要求され、それがFlashだと作りやすいのであれば、無理にAjaxでがんばるのは考えもの。
• 新しい技術にチャレンジする状況かどうか?
  これには、プロジェクトの状況や、会社の方針、開発者の想いなど、いろいろな要素があるが。。。
• 有償の開発環境を導入できるか?
  Flexの場合、SDK + テキストエディタベースで開発するには、熟練が必要と考えられる。Flex Builderを使った方が、効率よく開発できる。

すでに、Ajaxベースの開発で、高い技術を持ち、Flushテクノロジーを使わずに機能が実現できるのあれば、「Ajaxベース」を採用するのが自然な流れです。どうしてもFlushは採用できないという事情がある(AIRを前提で、そんなものはないと思いますが。。。)以外の場合には、楽に簡単にできそうな面があるのなら、Ajaxで無理をすることばかりを考えず、Flexの採用を検討してみてもいいかもしれません。

新しい技術にチャレンジする時は、できること、やりたいこと、必要なこと、コストなど、いろいろな角度から見て判断することが重要ですね。

システム開発プロセスについての話の中で、ウォーターフォール型 vs. アジャイル型という観点で議論されることは、よくあることです。その場合、ウォーターフォール型を、単なる思想とか文化として捉えられていることが多いように感じます。

ウォーターフォール型プロセスの誕生の背景的なことが、こちらに説明されています。
ウォーターフォール・モデル

当時は、そのときの環境に適したプロセスとして、採用され、広まっていったものと考えられます。
個人的には、当時の開発環境が、1つの大きなポイントだったのではないかと推測します。
1980年代くらいまでは、メインフレームが開発環境の中心でした。メインフレームで運用されるアプリケーションだけでなく、ワークステーション上で実行されるプログラムも、メインフレームでクロスコンパイルすることもありました。なので、多くの開発者が、1つのホストコンピュータを共同利用して作業を進めていました。
ところが、端末はすべての開発者に1つずつ行き渡っているわけではなく、限られた数しか用意できませんでした。そのような環境下では、よほどの理由がない限り、一人の開発者が占有するなどということは許されませんでした。端末は、「作業場所」であり、ものを考える場所ではなかったのです。
では、ものをじっくり考える場所はどこかというと、「机上」です。「机上」の作業だけで、ある程度精度の高い設計ができていることが前提で、開発プロセスが策定されていました。ソースコードまでも、紙に書く場合がありました。
このような環境の中では、必然的にウォーターフォール型になるように思います。すでに、基本アーキテクチャは決まっており、開発という側面では、技術は安定していました。それにより、技術的リスクがあまりなかったということも背景としてあったと思います。

そのような状況からの変化が始まったのは、90年代前半くらいからかなと記憶しています。「ダウンサイジング」「クライアント/サーバ」「EUC(End User Computing)」などのキーワードとともに、それまでメインフレームでしか動かせなかったアプリケーションが、ワークステーションやPCという、ユーザに近いところに降りてきました。当然、基本アーキテクチャは大きく変わりました。それまで、書類が並んでいた「机上」に個人専用のPCが置かれ、インターネットを通じて、さまざまな情報にアクセスできるようになりました。言うまでもないですが、前段で述べたときとは、かなり環境は違います。
私の観点では、主要な変化として捉えるべき点は、以下のようなものだったかなと思います。

• 各自が専用のPCを持つことによって、考えながら開発することができるようになった。


• 技術トレンドの変化が激しくなり、「初物」に出会う確率が高くなった。


• マルチベンダー化により、1つのことを実現するための選択肢が増えた。

当たり前の話ですが、このあたりの開発では、「R&D」や「プロトタイピング」といった「トライ & エラー」を経由せずに、「机上」の理論だけで作業を進めて行くことは、不可能であり、やりにくいということは明白ですね。こういった環境の中では、仮にウィータフォール的にスケジュールが策定されていたとしても、実態はアジャイルっぽくなるのが必然ですね。

前置きがちょっと長くなってしまいましたが、ここで言いたかったのは、ウォーターフォール型 vs. アジャイル型というのを、単純に思想とか文化として考えたり、どちらか一方に偏るのではなく、必要に応じてやりやすい最適な方法を選ぶことが重要だと言うことです。
現在、企業システムの世界は、JavaEEによって基本アーキテクチャがかなり安定して来ており、90年代や00年代前半に比較すると、「初物」に出会う機会もかなり少なくなってきました。それでも、メインフレームの時代にくらべると、「トライ & エラー」が必要な場面は多いと思います。
ウォーターフォール型だけではやりにくい部分があるのは明白です。現実的に、最もやりやすいと思われる方法を検討し、柔軟に計画を策定することを考えて行くことが適切なのでしょう。

ちょっと前のことになりますが、ゴールデンウィーク直前の4/24に、アップルから、このような発表がありました。

アップルの革新的なApp Storeからのダウンロード、わずか9ヶ月で10億本を突破

この記事の中ではもう一つ、以下のような数字が出ています。

現在、画期的なApp Storeでは35,000本以上のアプリケーションが世界77カ国のお客様に提供されており、デベロッパには、世界中の何千万ものiPhone™およびiPod touchユーザにリーチする機会を提供しています。

1ユーザが平均で50本ダウンロードしていると仮定した場合でも、単純計算で2000万ユーザという数字になるので、「何千万ものユーザ」というのは、決して大げさではないでしょう。
ニンテンドーDSは、初代が発売開始から1年で、1637万台ということなので、それと比べても遜色ない数字ですね。

ニンテンドーDSシリーズ１億台販売

ただ、これはあくまでも、世界レベルでの比較です。日本国内に限定した場合は、また違うでしょう。
あと、AppStoreには「無料のアプリケーション」も多くリリースされており、それらがこの10億本という数字を底上げしてる可能性もあります。
このように単純比較はできないですが、勢いがあることは事実だと思います。

私も、昨年の秋くらいから、iPhoneアプリケーションの開発に参加しています。そんなわけで、インターネット上で、いろいろなIPhoneアプリケーションデベロッパーの方々のブログなども、よく読ませていただいてます。そこから感じるのは、こんなにさまざまなタイプのデベロッパーが1つのプラットフォーム上に集まっているというのは、今までに例がないのではということです。
たぶん、自らやってみたいと思う人々が、積極的かつ、自然に集まった結果なんでしょうね。
(「業務命令」で、仕方なくiPhoneアプリケーション開発をやっている人は少ないんじゃないかと感じてます)

そして、半年ほど前になりますが、AppStoreから、無料のアプリケーションを1本リリースしました。
自分のアプリが、海外の見知らぬ人からダウンロードされたり、どこかのブログや雑誌で取り上げてもらったりといった、今までになかった新しい経験ができました。でも、現時点では、今後自分たちのビジネスに、どのように結びつけることができるかについては、まだ未知数です。
ただし、この勢いは見逃してはいけないと思うので、これからもウォッチして行きたいと思います。

当然ながら、自分もiPhoneユーザの一人なので。。。