2012年5月25日

モバイル・エンタープライズ・アプリケーション・プラットフォーム(MEAP)とは何か?


MEAPは、銀河系のセキュリティ・エージェントでも、キプロスのサッカーチームでも、ミシガン州の教育アセスメントプログラムでも、某社の複合機向け組込アプリプラットフォームでもありません、念のため。本題に関係のないこれらMEAPに興味のある方は、こちらへ。

以下、Glenn Johnsonによる簡便な座学です。ただし、ガートナー以外の引用の出典はやや怪しいので、そのつもりで。


 

辞書的にいえば...
MEAP (名詞)モバイル・エンタープライズ・アプリケーション・プラットフォーム。統合化された開発および配備環境。単一の開発環境でありながら、幅広いスマートフォン向けにネイティブ・クライアントの実装を可能にする。

ガートナー曰く「MEAPとは開発および配備のフレームワークであって、モバイルに関して、クライアント、サーバ、ミドルウエア用のツールを提供する。対象範囲は、あらゆるデバイス(スマートフォン~タブレット)上で動作するあらゆるモバイルアプリケーション。スケーラビリティがあり、オンライン・オフラインで動作すること。単一のインフラ上で複数のアプリケーションを配備したい企業向け」
[訳補:同ソースによれば、モバイル・コンシューマ・アプリケーション・プラットフォーム(MCAP)と対置されるが、両者の統合化も進んでいる]

マルチプラットフォーム・アプリへの正攻法はコストがかさむ

観念的に言うと、MEAPは、モバイル・アプリケーションを開発し配備する一元化されたアプローチを提供する。MEAPがないと、開発工数は指数関数的に増加する。すでに、多くの企業が何百万ドルも費やして学んだのは、変化の途上にある複数のモバイル・プラットフォーム向けの開発がいかに難しいかということだ。

Jones他が言うように、「例として、小さなアプリを企業がiOS、Android、Windows Phone7向けに開発することを考えてみよう。この企業は3つのチーム(往々にしてスキルセットの異なる)を抱えなければならない。これらチームは、3つの異なるコード資産を保持しながら、追加開発やバグ対応を同期化しなければならない。これはぞっとするようなチャレンジであり、リリースの遅れにもつながる。さらに、3つのプラットフォーム毎に、品質やデザインの一貫性にもばらつきがでる。アウトソーシングする場合はなおさらだ。サポートコストも増大するだろう。プラットフォーム毎のドキュメンテーションが必要となり、したがってサポート用のドキュメントも3通り必要になるのだから。」(Jones他, The Clash of the Ecosystems Report, 2012年2月, VisionMobile [訳補:出典未詳])

MEAPは、企業のITチームに、単一のスキルセット(MEAP言語・パラダイム上で開発する能力)をレバレッジする方法を提供し、初手からiPhone、Android、 BlackBerry、Windows Phoneなど幅広いデバイスにまたがるモバイルアプリを生成することを可能にする。

MEAPは、存続しうる唯一の開発・配備方法であるという考えはコンセンサスを得ているとは言えないが、影響力あるコミュニティからの支持するに至っている。CIO.comが言うように「ITのコンシューマライゼーションは乱用されているかもしれないが、一時的な流行ではない。会社の社員たちは、総じて、パーソナルデバイスが会社のネットワークにつながることを期待するに至っている」。だから、幅広いデバイスで動くモバイルアプリを制作するよう、IT部門には明らかにプレッシャがかかっている。IT意思決定者が、好みのモバイルデバイスへの殉教的な熱意から自らを引き離し、ことモバイルデバイスに関しては多元論を認めることが重要だ。技術分化が進んだ現代において、他人に自分のモバイルデバイスへの好みを押しつけることは、不遜なことと知るべきだ。

なぜ、HTML5ではないのか

MEAPは、HTML5かネイティブかという議論には免疫がない。マジックソフトウエアのアプリ・プラットフォームはHTML5マージにも対応するし、プラットフォーム毎のネイティブRIAクライアントの配備にも対応しているが、それであってもなお、この議論でどちらの立場を支持すべきか悩んでいるくらいなのだ。

Jones他が言うように、「多くの開発者が問い続けているのは、配備を中心に考えてWEBブラウザアプローチを取るべきかどうか、それとも、ネイティブアプリを制作すべきかどうかという点だ。WEBアプリのマーケットは広いけれど、WEBのもつ技術制約と、提供するユーザエクスペリエンスの底の浅さという代償がある。ネイティブアプリは、より深いデバイス統合や経験を要求されるけれど、マーケットがプラットフォームに限定されるという代償がある」(Jones他 同上)

しかし、KrebsとKleinの意見は明確である。曰く「企業が、B2B/B2Eのより洗練されたモバイルアプリを幅広いモバイルプラットフォーム向けに、多数のユーザ向けに開発しようとするなら、MEAPをレバレッジとして用いることは、もっとも実効性のある選択肢である」。(Krebs & Klein, Native & HTML5 Mobile Apps: Not an either or, but a where and when…, 2012年2月, VDC Research [訳補:出典未詳])

HTML5に対する負のバイアスは理解できるものだ。最近の互換性テストでわかったことだが、Windows Phone 7.5のMangoブラウザは、HTML5の全機能の1/3以下しか実装していなかった。HTML5との親和性が高いといわれるFirefox Mobile 10ですら、2/3程度の機能実装に留まっている。

断片化=プラットフォーム毎に準拠標準が異なっていることは、コスト要因以外の何物でもない。「その結果、WEBアプリ開発者は膨大な時間とリソースを費やして、メジャーなスマートフォン・プラットフォーム向けに、横断的な最適化を続けなければならない。おそらく最も著名なケースは、Assanka社だろう。Financial TimesのHTML5化で有名な同社は、24人月をiPad向けのHTML5ニュースリーダアプリ開発に費やし、12人月をAndroid向けの同アプリにつぎ込んでいる」(Jones他 同上)

この断片化は、プラットフォームのGUI標準が変化していくなかでも発生する。ビジネスアプリは、デバイスとバンドル販売されるわけではないので、単独でアテンション・エコノミーのなかを勝ち残っていかなければならない。一言でいえば、ブラウザの機能標準化は遅々としているのに対して、高い期待だけが独り歩きしているということだ。

標準の欠如に打ち克つため、企業には近道が必要だ。MEAPが注目されるのも、この近道になる点を買われているからに他ならない。

MEAPマーケットの成熟はこれから

ただし、MEAPが現在置かれている場所は、必ずしもよいものではない。「クロス・プラットフォーム・ツール(CPT)のマーケットは、開発者の心変わりにさらされる状態にある。CPTを現在使っている開発者と、予定しているないし使うのをやめた開発者と比べてみると、流動性が認められる。開発者はツールを試し、そして、次のツールに移っていく。CPTマーケットでは、勝者も敗者もはっきりしない。開発者のロイヤリティが低いマーケットであり、マーケットの認識はいまだ形成されつつある段階だ。資金のあるベンダにとっては、開発者のマインドをほんの少し動かし、開発者向けマーケットに橋頭堡を築くチャンスである」(Jones他 同上)。

マジックソフトウエアは、そうしたなかでよいポジションにいる。最大のMEAPベンダの一つであり、分野特化されている。技術面ではスケーラビリティを担保するブローカーが、体制面では世界11拠点に支えられている。

マジックソフトウエアのアプリケーション・プラットフォームからのアプリ配備は、大変フレキシブルなものだ。配備に当たっては、プラットフォーム特有のオプションがサポートされている。マジックのアプリは、iOS上ではホームスクリーンから、Androidではアプリドロワーから起動することができる。一方、開発の面では、WYSIWYGフォームで、イベント・ドリブンでビジネスロジックを実装することができる。

マジックのモバイル・エンタープライズ・アプリケーション・プラットフォームの方向性は、多くの中堅大手企業のIT部門から好意的に受け止められており、MEAPマーケットの成長とともに大きな成果を上げることになるだろう。

MEAPは、コンシューマ市場やビジネスにおいてITコスト意識が高まっている今日、シリアスに受け止められねばならないコンセプトである。


Glenn Johnson
Magic Software Enterprises, Inc.  副社長。1984年以来ソフトウエア業界で活動。
しばしばIT産業のコンファレンスで講演。寄稿も多々にのぼる論客。

原文はこちら


0 件のコメント:

コメントを投稿

Copyright 2011, Magic Software Japan.