A1.今までの実績的には「ありえません」

Flashは、3と4、「5&MX」,「MX2004」と、ほぼ全てのバージョンでアクションスクリプトの言語仕様の大幅な進化が行われていますが、常に後方互換性に関しては保たれています。最悪でも互換モードみたいな形で後方互換性は今後も維持されていくことが想像されます。

Flashの今後の進化として、後方互換性が足かせになりオブジェクト指向対応で限界があるのは間違いなく、OOPとしての厳密性を追求するか、互換性をどう維持していくか？はマクロメディア次第というか、OOPとしてのFlashのジレンマであり、そりゃ今後どうなるかはわからない部分があるのは事実です。完璧を求めるなら、後方互換性をすっぱり切って、Javaアプレットの本格的な代替を狙うのも一つの道なのかもしれません。しかし、それはもうFlashではありません。

もし後方互換性を捨てたときは、同時に、Flashという製品がここまで育った素地（軽量プレーヤーであること、ほぼ、どのブラウザでも動くこと。後方互換性を維持し続けること）を捨てることであり、すなわち、Flashという製品の寿命を迎えるものと考えても良いと思います。

少なくとも、MacromediaにはDirectorという上位製品があるため、彼らのビジネスとして高機能のニーズはDirectorでどうぞという言い分が可能なので、いろいろな機能が実装されても、コアのFlashの文化は守り続けられるものと考えるのが、基本的なFlashの哲学であると考えており、その中の一つに後方互換性の維持は続けられるものと考えるのが自然です。

A2.これはある程度、真実かもしれません。そりゃJ2EE(Not　EJB)やVBのエンジニアのようには簡単に探せません。

自分も自社以外のリソースを求める時は少なくとも人材派遣の会社にアクションスクリプトを「使える」エンジニアを期待することは考えられません。ただしFlash MX 2004のOOP的アプローチであれば、VBとJavaを経験している（つまり曖昧なプログラミングにも慣れているし、OOPもできる人）にFlashを教えて、人材開発していくことは可能だと思っています。

そのためFlash慣れしているWeb開発会社が開発者を新規開発していく環境は揃ったというのが印象です。そのような企業を開拓していくことで、開発後の保守や仕様変更などをし続けていくことは可能でしょうというのが現状。

今はNECなどもFlashに力を入れ始めているようですし、Javaに続く新たな人材開発ビジネスネタとして派遣市場でのFlash開発者の開拓も進んでいくことが期待されます。

A3.Q1で書いたような後方互換性であったり、FlashPlayerの元々の作りからして、まだちゃんとしたOOPができない部分はあります。ただし、そこまで厳密性を期待するほど大規模なFlashを実際に作るのか？というのが思うところです。Flash一つにバカみたいに大量の工数をかけるようであれば、設計を見直すのがRIAのミソなのではないでしょうか？別に何も一つのswfにまとめる必要はありませんし。

HTML（含むDHTML）と適材適所でまとめることこそが設計の腕の見せ所であり、なんでもかんでもFlashに期待するものではないと思います。

また、Flash自体はオブジェクト指向で設計されている製品だと考えています。
Flashの本質はムービークリップというアニメーションオブジェクトの集合ですが、その仕組み自体がオブジェクト志向だということです。

いろいろな絵がかかれ、それぞれのタイムフレームにアニメーションが組み込まれたムービークリップというオブジェクトに対して、アクションスクリプトというムービー制御コードをオーバーライドしていくのが昔からのFlash開発の基本的なスタイルでした。1/15秒とか1/30秒ごとに順次に呼び出されるフレームごとのメソッドに、必要な制御コードを記述していくスタイルです。

そのため隣のflaファイルのムービークリップを、他のflaファイルにドラッグアンドドロップするだけで、そのムービークリップおよび、そこから参照している他のムービークリップや画像素材などもまとめてインポートすることができます。

ひょっとしたらオブジェクト指向というよりコンポーネント志向と言うのかもしれませんが、オブジェクトの再利用性はアニメーションの素材という形で実現されており、これはFlashがまともなプログラミングができなかった時代から持っているアーキテクチャです。

そもそもムービークリップに「インスタンス名」をつけることから、ライブラリウインドウに置いてある「クラス定義」からオブジェクトをインスタンス化するコードをGUI化し隠蔽しているのが、Flash作成の基本的なオペレーションです。

つまり、オブジェクト指向を「変数の隠蔽」「クラスの継承」「コードのアクセス制限」などの、いわゆる「OOPの定義」に照らし合わせるなら、今のFlashは中途半端ですが、Flashなる製品のアーキテクチャは間違いなくオブジェクト指向に根ざすものであり、多人数開発や再利用性の部分でオブジェクト指向のメリットは、アクションスクリプトを書かないデザイナーでも知らないうちに享受しているものと考えます。

A4.ビジネスに直結するものは、アクションスクリプトの多人数開発がやりにくいのとパフォーマンスですかね。

多人数開発は、MX2004から可能になったクラス開発などで工夫できると思います。ただし、適切に設計を切り分けることが重要です。GUIのクラス設計は、実はあまり慣れていないかもと最近実感しました。（結局メインの制御コードは、flaに書くんだよね？ここが凄く悩んでます。）

パフォーマンス問題は、Flashでは一番重要なポイントになります。
Flashは作り方でいくらでも遅いものを作ることができますので、設計段階でオブジェクトの使い方に関しては十分考慮する必要があります。

主に描画に関することではないでしょうか。特にフレームアクションで大量のムービークリップの描画制御を書くなど避けなくてはいけません。1/15秒のタイマーをぶん回してひたすら描画し続けるような動作になりますので、すぐにCPU使用率が100%になります。

ムービークリップなどは独自にタイムラインを持ち自律的にRedrawしてくれるものですので、大量の配置はパフォーマンス低下の元になります。この辺は、VBのActiveXが持っていたパフォーマンスの問題と同じと考えて良いので、VB的経験があれば、すぐに理解できる問題です。

そうでなくとも、こういうのはコンピューターのセンスがあれば、カラダでわかるはずですので、これが特殊能力や経験が必要だとは思いません。GWにでも3日ぐらいじっくり、Flashのヘルプを読めば、まともなエンジニアであれば、十分、わかるようになるぐらいの情報量だと思います。（体験版をダウンロードすれば手に入ります）

とはいえ、所詮はFlashPlayer上で動く上流アプリケーションで、問題点は上に指摘したとおりですが、VC++のようなビットマップ描画もなければ、Redrawのタイミングが任意に制御できるわけでもないので、ニーズによっては多くの期待を求めるのも無理があることは事実です。

昔のアプレットのように死ぬほど遅い場合は、まずは設計の問題を疑うのが筋ですので、なんでもかんでもFlashが悪いと言って逃げるのはやめるべきですし、また逆に、なんでもかんでもFlashで実現しようとするのも、また間違いだといえると思います。

いずれにせよ、Flash採用に当たって必要なリスクマネジメントのネタはここで書いたとおりです。長くて、とても読める文章でないことは重々承知ですが、みなさまの不安が少しでも緩和できれば幸いだと思って書いてみました。