スマートデバイス、モバイルデバイスをターゲットとしたアプリ開発では、従来のデスクトップアプリケーションや、デスクトップブラウザでの動作を前提としたWebアプリ開発とは、異なるスキルやノウハウが求められるケースが多くなる。そのため、できる限り開発のための工数やコストを削減しつつ、生産性を高める開発フレームワークやツールに対して注目が集まっている。
今回、CodeZine編集部では、スマートデバイス対応を積極的に進めているフレームワーク、開発ツールの提供ベンダー5社による座談会を企画した。前編では、各ベンダーの担当者から、自社が扱う製品の特長や、ツールの特性に基づいたメリットやデメリットなどを中心に語ってもらった。
後編では引き続き、自社の製品を特に使ってほしいユーザー像や、今後の方向性などについて話を進めていく。座談会のモデレーターは、CodeZine編集部の斉木崇が担当した。各ベンダーの代表者は以下の5名だ。
アドビシステムズ |
アンディ・ホール氏 (デジタルメディア部クリエイティブクラウドエバンジェリスト) |
---|---|
SCSK |
岡田 一志氏 (流通システム事業本部Curlソリューション部プロダクト課長) |
エンバカデロ・テクノロジーズ |
藤井 等氏 (日本法人代表) |
キヤノンITソリューションズ |
髙本 勉氏 (CNB推進部コンサルティングプロフェッショナル) |
マジックソフトウェア・ジャパン |
渡辺 剛氏 (マーケティング部課長) |
エンバカデロ・テクノロジーズ 藤井等氏、キヤノンITソリューションズ 髙本勉氏、
マジックソフトウェア・ジャパン 渡辺剛氏
![登壇者:左から、アドビシステムズ アンディ・ホール氏、SCSK 岡田一志氏、エンバカデロ・テクノロジーズ 藤井等氏、キヤノンITソリューションズ 髙本勉氏、マジックソフトウェア・ジャパン 渡辺剛氏](http://cz-cdn.shoeisha.jp/static/images/article/7568/7568_members_2.jpg)
標準への準拠と想定されるユーザー像
CodeZine:後半ではまず、将来的な運用やマイグレーションコストなどに関係してくる要素として、それぞれのツールが技術的なスタンダードにどのように対応しているかについて教えていただければと思います。併せて、特に想定しているユーザー像、現在どのようなニーズやスキルを持ったユーザーにとって、特にメリットがあると考えているのかについても教えてください。
アドビ:アドビは、以前から一貫して、プロクリエイター向けに、表現力の高い成果物をさまざまなメディアで展開するためのツールを作ってきました。特にWebの世界では「Flash」によって、Webそのものの表現力をクロスプラットフォームで高めてきたという自負があります。かつてはHTML自体の表現力が乏しく、その進化も遅いものでした。Webそのものの進化のスピードを加速させるためにも、Flashのような技術やツールは必要だったと思っています。
ただ、現在のHTML5で状況は変わりました。表現力は大きく増してきており、独自の技術にこだわる必要はなくなったと言えます。アドビでは現在、多くのリソースをHTML関連の発展とツールに対して割いています。アドビが持っている技術をW3Cに提案したり、オープンソース化することで、標準であるHTMLそのものの進化を促しつつ、並行してそれをうまく扱えるツールの開発を行っています。
現在複数のラインアップがリリースされている「Edge」ブランドの各ツールは、そうした取り組みの一部です。我々はプラットフォームやブラウザは作っていませんので、Webアプリケーションについては、純粋にスタンダードな技術に対する取り組みを行えばいい立場にあります。現在は、社内でもこの流れが主流になっています。
ネイティブアプリについては、PhoneGapやAIRといった技術を使い、HTMLに加えて、従来のFlashテクノロジをベースにしたアプリケーションも、容易にモバイルへと展開できるパスを用意しています。
![「PhoneGap」(左)/「Adobe Edgeツール&サービス」(右)](http://cz-cdn.shoeisha.jp/static/images/article/7557/7557_adobe.jpg)
SCSK:Caedeの開発言語であるCurl言語そのものは、いわゆる「標準」とはちょっと違いますね。ただ、我々がサポートすべきプラットフォームの側では、HTML5によるアプリケーションがスタンダードになりつつあるという現状があります。
かつては、Caedeのトランスレータから、それぞれのプラットフォーム向けのネイティブアプリを吐き出すような環境も考えていましたが、多数のプラットフォームが並行して使われるようになると、開発に時間がかかり、各プラットフォーム対応が遅れて、利用者の新しいデバイスの採用やバージョンアップに支障をきたすことになります。そのため、プラットフォームの側でスタンダードになっているHTML、JavaScriptをベースとしたアプリを吐き出せるアーキテクチャを採用しました。いわばHTMLという技術を「使わせてもらっている」といった状況でしょうか。
ただ、純粋なスタンダードのHTML5群だけでは、前編でも話しましたとおり、業務アプリの実現にあたってどうしても足りない部分というのも出てきます。その部分を補うためにも、Curl言語を引き続き推進していきたいと考えています。例えば、スクリプト言語として、スタンダードなJavaScriptに準拠しつつも、独自の拡張を施したものを生成するような仕組みは考えられるのではないでしょうか。
CodeZine:現状のCurl言語は、Javaに近いのでしょうか?
SCSK:そうですね。オブジェクト指向でJavaにも近いですし、個人的にはScalaが最も近いと思っています。いろいろな開発言語の良いとこ取りをしたものになっていると自負しています。
![「Curl」(左)/「Caede」(右)](http://cz-cdn.shoeisha.jp/static/images/article/7557/7557_scsk.jpg)
エンバカデロ:我々のツールでは、iOSやAndroidといったプラットフォームに向けたネイティブアプリを生成しますので、「標準技術への対応」という意味では、ちょっと立ち位置が違うかもしれません。
名前のとおり、「C++Builder」の開発言語は、業界的にはスタンダードになっているC++です。一方の「Delphi」は、Object Pascalを源流にしたDelphi言語を使って開発します。コンパイル速度は、プリプロセッサ処理などで複雑なC++よりもDelphiのほうが圧倒的に速いです。あと、一般的にDelphiのほうが習得が容易だとも言われています。
いずれのツールも、基本はコンポーネントを組み合わせての開発になるので、記述するコード量自体は少なくてすみます。また、いずれのツールでもコンポーネント自体の開発を、DelphiまたはC++Builderを使って行えます。
ユーザーとしては、IDEとして、これまでVisual Studioを使われていた方であれば、簡単に移行してもらえるのではないかと思います。特に、Visual C++からC++Builderに移られた方は、余計なマクロなどがコードに含まれない分、分かりやすくなったと言ってくださることも多いですね。
「C++Builder」:標準のC++言語でのiOSアプリ開発を実現した(右)
![「Delphi」:AndroidとiOSの双方のネイティブアプリを開発できる(左)/「C++Builder」:標準のC++言語でのiOSアプリ開発を実現した(右)](http://cz-cdn.shoeisha.jp/static/images/article/7557/7557_embarcadero2.jpg)
キヤノンITS:「Sencha」は本来、Webアプリの開発フレームワークですから、そこで使われるHTML5、CSS、JavaScriptといった技術はすべて標準技術です。開発言語は基本的にJavaScriptで、JavaScriptからDOMを操作して画面を描画する形式になります。また、オープンソースプロジェクトとして、透明性も確保されています。
なので、ターゲットとしては、まず業務アプリ開発を行うWeb開発者ということになります。Web開発に必要なJavaScriptのスキルは、そのままSenchaでも生かせます。もう一つは、これまでJavaなどで業務システムなどを手がけてきた開発者が、モバイルアプリを視野に入れて新規に取り組むケースです。この場合、JavaScriptについて学ぶ必要がありますが、オブジェクト指向が分かっていれば、習得はスムーズだと思います。
あと先ほど、エンバカデロさんが「DelphiではDelphi自身でコンポーネントを作れる」とお話しされていましたが、Senchaも同様に、Senchaを使ったコンポーネントの開発が可能です。
「Sencha Touch」:モバイル用フレームワーク(右)
![「Sencha Architect」:GUIによるアプリ開発(左)/「Sencha Touch」:モバイル用フレームワーク(右)](http://cz-cdn.shoeisha.jp/static/images/article/7557/7557_canonits2.jpg)
マジック:一般的な「標準」という観点では、Magicは完全に独自の世界ですね。コテコテの独自仕様です。日本では20年以上ビジネスをしていますが、多くのユーザーさんが、20年間がっちりロックインされています(笑)。
完全な独自の世界でも、20年間使われ続けているのには、Magicでの開発が高生産性、高メンテナンス性を実現するリポジトリベースの開発形式であるというというのが理由の一つだと思います。Magicの開発では一切ソースコードを書きません。「リポジトリを定義する」というスタイルをとります。実際にやっているのは、データベースのテーブルの定義だったり、ロジックを定義したりという作業になります。ロジックの定義についても、コマンドは10種類程度で、それもドロップダウンリストから選択するという形で行います。
そのため、データベースを設計して、ロジックをどう設定するかという、業務システム設計の経験とセンスがあれば、Magicの作法を覚えるだけでプログラムが作れてしまうということになります。
SCSK:Magicは、企業の情報システム部門に使える人が多そうですよね。
マジック:実際に、企業の情報システム部門で内製の開発を行っていらっしゃるユーザーさんもいらっしゃいます。また、ボリュームが大きいのは中小のソフトハウスさんですね。OSが変わっても、アプリケーションを作り直す必要がない。開発生産性が非常に高いので、少ない工数で良いプログラムを作れるというメリットを気に入って、使ってくださっている方が多いです。DOSの時代に作ったMagicアプリケーションを、最新のWindowsで動かしているようなケースも多いんです。クラサバのアプリのリポジトリ定義を引き継いでRIAやモバイルといった別形態のシステムに移植する機能も用意しています。
![「Magic」](http://cz-cdn.shoeisha.jp/static/images/article/7557/7557_magic.jpg)