エンタープライズアプリケーション向けリッチクライアントとしてのMicrosoft Office

作者 Mark Figley, 翻訳者 編集部 投稿日 2008年7月15日 午前12時45分

コミュニティ

Architecture

トピック

インターロップ,

Office Business Applications,

SOAプラットフォーム

タグ

Microsoft Office

Ted Neward氏(リンク)のことでわたしがつねに気に入っていることの1つは、「裸の王様」を分かりやすく説明する際に取り入れる喜びである。ソリューションアーキテクチャーを定義する一方、Microsoftテクノロジーを無意識に除外した場合、どれほどの価値を見過ごしているかを、Javaコミュニティに説明し ようとするときに、必ずと言って良いほど彼自身がその立場にいるとわたしは感じる。先週Ted氏は、短いブログ(リンク)を書いたが、(本当にパワフルな)リッチク ライアントとしてMicrosoft Officeを使用することについてBruce Wilson氏が書いた記事(リンク)を指摘している。Wilson氏の記事を紹介した後で、Ted氏は核心をついている。

興味深いことは、ここで話しているほとんどの考えが.NETバックエンドと同じくらい簡単にJavaバックエンドやRubyバックエンド上に実装すること ができるかもしれないということである。Officeは多くのエンドユーザが即座に手にするツールで(Microsoftのユーザインターフェイスメタ フォーに同意しようがしまいが、もしくはOfficeがこの地球上で最も広範にわたってインストールされているソフトウェアパッケージの1つであるという 事実に同意しようがしまいが)、サポートインフラストラクチャーが数多く内蔵されている。

リッチクライアントプラットフォーム(またはすべてのクライアントプラットフォーム)における唯一、最も重要な性質はユビキティーといって差し支え ないと考える。MS Officeがまだブラウザほどユビキタスではないが、これらの作成者が語っていることは、エンタープライズオートメーションをサポートするアプリケー ションの開発である。ここでフォーカスしているのは、その組織外の状況下では決して使用されることのない、内部アプリケーションである。ほとんどの企業に おいて、MS Officeは偽りなくユビキタスである。

Wilson氏の記事はかなり高レベルな書き出しであるが、先に進むにつれ興味深い展開を見ることができる。以下はOfficeアプリケーションをうまく論証した氏の記事からの抜粋である。

わが社では、「ユーザエクスペリエンス」を向上させる能力を自負しています。本質的にこれは、ユーザが触れてソフトウェアをもっと自分に合うようにする、 ソフトウェアの一部をカスタマイズすることを意味しています。近年、より多くのユーザにより多くのバックエンドを利用できるようにするシステム開発に対する関心が高まっています。これまではデータベースのスペシャリストのみしか利用できなかった情報を、ビジネスユーザにも利用できるようにするシステム開発 については特に著しいです。大企業においてさえも、これまでどおり驚くほど頻繁に情報のリエントリーが見られます。両方のシナリオにおけるソリューション には、しばしばSOA (Webサービス)、OBAおよび関連するMicrosoftテクノロジーが含まれます。

内部的に開発されたエンタープライズアプリケーションのほとんどが、ユーザエクスペリエンスに対するフォーカスがひどく不足しているのを見てきた。 自然で効率的なユーザエクスペリエンスを備えたWebアプリケーションを作成することは可能であるが、高くつく上にたいていは、「十分に良い」ことで仕事 を終えられるので、それに費用をかけることはビジネスの面から見ると、意味がない。すでにユーザが知っている一連のツールにソリューションをもたらすとい う展望およびその状況を利用して直感的なユーザエクスペリエンスを大幅に低い価格で提供することは、道理にかなっている。

わたしの見解では、相当意味があるソリューションに対して企業においては、比較的理解していないようである。このことについてTed氏に尋ね、考えを聞い た。わたしの質問は言い換えると、以下のようになる。 Q：「Ted氏、このトピックについて何年も話してきたことと思いますが、まだ広いコミュ二ティにおけるこの概念の導入段階にすぎないところにわれわれは いるのではないかと感じています。また、あなたがわれわれと同様の立場にあったら、それを永遠にあきらめるまで、われわれはみなXFromsがあった数年前の状況ではないでしょうか。そして、そのことで、わたしはXFormsが明らかだったと思ったのです。HTML形式よりはるかに良かったです。起こる予定でした - 起こるに違いなかったのです。そのことについて記したO'Reillyの書籍がありました。それから、われわれは立ちすくみお互い向き合い、「どうして起こっていないのか？」と言いました。サービスバックエンドとOfficeフロントエンドの組み合わせもまた、非常にパワフルであるけれど、せいぜい最低限 の理解度といった感じです。今となっては、「なぜこれがはっきりしていないのか？」と尋ねるに違いありません。

予想通り、Ted氏の回答が洞察に富み、考えさせられるようなものであった。そういうわけで要約するのではなく、加筆することなくそのままの形でここに掲載する。

人びとにとって明確だと思います。… 具体的にはOffice Business Appsを開発してきた人びとにとっては。:-)

TechEd ITを見ると、このような人たちをたくさん見つけるでしょう。彼らはわれわれが「エンタープライズ」や「CompSci」の意味で思い描くような、これまでのデベロッパではないのです。彼らはMicrosoftが呼ぶところの「Information Workers」なのです。適度にテクニカルであるのみだけれど、非常にビジネス経験豊富であり、Officeを使いさまざまな方法で問題を解決します。 (われわれが結局OracleやSQL ServerバックエンドWebフロントエンドエンタープライズシステムへ「スケールアップ」したAccessデータベースの取得先の人びとと同じです)。時としてアプリケーションやシステム上のビジネスルールを解明する際に、われわれが頼る人びとです。

もっと率直に言うと、リッチクライアントとしてのOfficeの考えには、XFormがしなかったことが1つあります。それは組み込まれた市場占有率で す。すぐにOfficeがなくなることはないです(Officeの市場占有率が10位を獲得した成功者の名を出してください)、そしてOfficeがプレーヤーであり続ける限り、リッチクライアントとしてのOfficeの概念も消滅することはありません。わたしがやりたいことは、Officeを検討したときに多くのデベロッパが抱く「リアルプログラミングではない」考え方から実現することです。

本当に興味深い予想をするならば、それが「オブジェクト」や「クライアントサーバー」より長く続いたように、OfficeがSOAを出し抜くことです。これは従来のデベロッパが聞きたくないことだと思います。

好奇心がそそられたならば、こうした概念を網羅したInfoQによるTed氏のインタビュー(参考記事・英語)を見ることができる。

原文はこちらです：   http://www.infoq.com/news/2008/07/ms-office-rich-client

• 次へ >