イベントレポート（AD）

失敗事例に学ぶFlexプロジェクトの第一歩

2009/02/02 15:16

ポスト

Adobe MAX 2009、2日目のセッション「失敗事例に学ぶFlexプロジェクトの第一歩」では、NECシステムテクノロジーの坂田泰平氏が、同社がFlexアプリケーションを使ったプロジェクトを進めてきた中でうまくいかなかった事例を挙げ、その原因を分析した結果を紹介した。

ポスト

　Adobe MAX 2009、2日目のセッション「失敗事例に学ぶFlexプロジェクトの第一歩」では、NECシステムテクノロジーの坂田泰平氏が登壇、同社がFlexアプリケーションを使ったプロジェクトを進めてきた中でうまくいかなかった事例を挙げ、その原因を分析した結果を紹介した。

坂田泰平氏

　「Flexを使ったプロジェクトの場合、最初にFlexの特徴をよく理解する必要がある」と坂田氏。画面構築面では「Flex Builderで簡単にUIをデザイン・構築できる便利さ」「HTMLと違い、複数の画面を1つのファイルに収めることができる管理のしやすさ」「必要なコンポーネントが多数用意されている環境の良さ」などを挙げ、ロジック実装面は「オブジェクト指向言語なので独自のクラスが定義しやすい」「スクリプト言語なので習得しやすい」という初心者にも敷居が低い点や、カスタマイズ性の良さをFlexの特徴として挙げた。

　しかし、Flexプロジェクトの場合、これらの良さがかえって裏目に出てしまうことがあり、それがプロジェクトの失敗へとつながってしまうという。

Flexを使ったプロジェクトが失敗する2つのパターン

　「失敗プロジェクト」と呼べるものはいくつもあるが、ここでは大きく分けて2つのパターンを取り上げた。1つはプロジェクト遅延による「赤字化」、もう1つはパフォーマンスが悪いなどの「品質問題」だ。

赤字化の場合

　Flex Builderを使うことで、いろいろなデザインがすぐに作れてしまい、また見栄えもよい。すると「いつでも変えられるから」「良い物がすぐにできるから」という理由で要求仕様のハードルが高くなったり、延々と仕様変更が出るなどして、プロジェクト遅延が発生しやすくなってしまう。これは画面仕様が未確定なプロジェクトによくあるという。

　また顧客の要求をどんどん盛り込むため、画面も重くなりがちで、思ったほどのパフォーマンスが出ず、かえって顧客の要望に応えられなくなってしまう。「どんなプロジェクトでも、必ず画面仕様をフィックスさせる必要がある」（坂田氏）。

　実際にこのような問題が起きたプロジェクトでは、仕様を確定させた上で、RSLの利用やクラスの再設計、スクラッチ＆ビルドでべた書きしていた部分を排除しオブジェクトを使うようにするなどして、パフォーマンスを改善したという。

品質問題の場合

　また、顧客が期待しているパフォーマンスや処理スピードが出ないといった品質問題が発生する場合がある。これはFlex初心者が多いプロジェクトでありがちだという。

　Flex Builderのおかげで、初心者でもFlexを深く理解せずに画面が組めてしまったり、スクリプトをなんとなく実装できてしまう。しかし実際はよくわからずにコーディングしているため、期待した動作にならない場合や、トラブル箇所の発見の遅れなどを引き起こしてしまう。

　Flexでは、UI上の全てのコンポーネント、描画オブジェクトはインスタンス化されるため、パフォーマンスを上げるためにはインスタンスが生成されるタイミングの理解が必要になる。また、似たようなふるまいをするコンポーネントでも重量級クラスと軽量級クラスがあることや、非同期でも処理が行われること、アプリケーションのボトルネックを調べるプロファイラの使い方についても知っておいた方がよい。

　問題が発生した実際のプロジェクトでは、既存コンポーネントをカスタマイズして軽量化する一方で、メンバーに対してはFlex中級レベルの再教育を実施、プロファイラやデバッガの使い方をマスターし開発に役立てるなどして、品質問題を解消したという。

Flexコンサルタントの導入

　Flexの場合、製品としての完成度とFlex Builderの利便性があわさり、手軽に見栄えの良いアプリケーションを作れるという特徴がある。しかし、挙動を理解していなかったり、Flexプログラミングの「べからず」を知っていないと、期待しているパフォーマンスを出すことができず、プロジェクトの遅れにつながってしまう。Flexプロジェクトでは「何をしたいのか」「何をどう見せたいのか」を念頭に置きながら仕様を確定させていくことが必要だという。