Sub Title

アップル・ウォッチ

1997年4月13日・OpenDocに学ぶこと(その2)[4月19日アップデート]


OpenDocで得られたもの

以下のようにまとめることができるだろう。

  • ソフトウェアのコンポーネント化という流れ
    昨今のインターネット上でのJavaやActiveX(これはOLEをインターネットに対応させたもので、中身はOLEそのもの)などの動きを見ても、正しい選択であったといえる。アップルはOpenDocをJava Beansに置き換えるとしているが、OpenDocとJava Beansは本質的に異なるものであり、完全な置き換えはJava Beansの拡張・改造をともなう。なお、これに関してはSun Microsystemsが実際に検討を始めているようである。

  • アップルのサポート戦略の見直し
    これはコンポーネントソフトウェアから撤退せよ!ということではなく、これを推進するために、アップルにとって重要なソフトウェアベンダーを味方につけ、確実な普及のためのロードマップを作成することにある。

  • ユーザ本位な開発の再確認
    OpenDocを壮大な科学実験だったと見るベンダーもあるくらい、OpenDocの評価は様々であるが、ユーザに対しても曖昧な対応を取っていたことは事実である。すなわち、いつまで経ってもオプションインストール扱いであったため、ほとんどのユーザはインストールしなかったものと思われる(参考までにいうと、筆者はCyberdogのメールを使いたいためにOpenDocをインストールした)。PowerTalkが引き合いに出されることが多いが、PowerTalkこそ本当にオプションインストール扱いのまま終わったソフトウェア技術である。Macの関連雑誌などでは、これらの新しい技術を少しでも多くのユーザに理解してもらい、利用してもらうために特集として取り上げるが、その努力はアップルの対応によって打ち消されていると筆者は考える。
    アップルが本当にユーザに利便をもたらすために開発したものならば、勇気を持って最前列の展示棚に置き、ユーザの評価を受けるべきである。


    OpenDocの今後

    アップルのリストラ発表後、それに続いてOpenDocに関連したいくつかのニュースが3月末までに飛び込んできた。

  • アップルに続き、IBMもOpenDocの新規開発を凍結
    MacOS上よりWindows上での存在価値が低いことからも、この発表がされるのは時間の問題だった。現バージョンのサポートは続けられるが、メジャーバージョンアップはもうないという。日本ではジャストシステムが強い興味を示していたが、今後の動きが注目される(ジャストシステムはCI Labsの会員である)。

  • CI Labs(Component Integration Laboratories)は6月30日をもって解散
    行き場を失った管理組織に残された道は解散だけである。アップルやIBMから資金援助が受けられなくなるのだから仕方がない。今後は資産をどのように配分するかが焦点となるようだが、フリーで公開される可能性もある。

  • JODA(Japan OpenDoc Developer Association)は今後も活動を継続
    これは意外であった。しかし、単純にビジネスだけで割り切らない、いいものはいい、として理想を追求するスピリットを、筆者は大切にしたいと思っており、ぜひ頑張ってほしいものである。

  • ディベロッパーはどうなるのか?
    最も被害を受けたのはOpenDocをサポートしたディベロッパーである。既にOpenDocに対する開発投資が縮小傾向にあったという話もあるようだが、今後の対応については各社からの発表を待つ必要がある。だた、これらのベンダーは、今後アップルの新技術に安易に対応することはないだろう。


    コンポーネント・ソフトウェアの将来

    MacOSにおけるコンポーネントソフトウェアの未来は、OpenDocに委ねられていたが、まったく不透明なものとなった。かつて、OpenDocはアップルの最後の切り札とまでいわれ、アップルが生き残るためのキーとなる技術だと、アナリストの間で考えられていた。よくも悪くも、人員削減に伴う事業縮小策の1つとしてあげられたわけだから、我々は受け入れる以外に道はない。それが嫌なら他のプラットフォームに乗り換えるしかない。

    だが、今一度考えてみたい。コンポーネントソフトウェア技術は本当に必要なものなのだろうか。現状のアプリケーションの形態でも、ソリューション(結果)だけを考えれば同じことが可能だ。要は使う道具のあり方にある。
    結論からいうと、プラットフォームをまったく問わないコンポーネントソフトウェア連携技術が理想だ。ユーザからは、デスクトップPCだろうが、ノートブックPCだろうが、情報携帯端末(PDA)だろうが同じソフトが使いたい。しかも、わざわざそのことを意識したくもない。もっといえば、コンポーネントソフトウェアを自由に組み合わせて、使いこなそうとする人は全体のほんの一握りの人たちで、大部分の人は現在のOffice型ソフトや統合型ソフトで満足してしまうだろう。
    この点から考えると、マルチプラットフォームを目指したOpenDocのコンセプトは間違ってはいなかったが、PDAクラスにまで移植できたかどうかは疑問だったし、ユーザそしてベンダーがOpenDocの思想を受け入れるためには、より多くの時間が必要だった。

    OSが異なってもLive Objectsがリコンパイル程度で動かせるのであれば、アプリケーションレベルでの互換性は保たれる。PDAではLive Objectsの最小限の組み合わせ、デスクトップPCではより豊富なLive Objectsの組み合わせ、といった具合だ。わざわざデータ互換性を持たせたアプリケーションを各OS毎に作る必要もない。この環境がデスクトップPCからPDA、その他の情報家電にまで及べば、ユーザにとっては違和感なく利用できるようになる。

    今、この環境を構築できる唯一の選択肢は、Javaである(参考までにいうと、ActiveXもこの可能性をある程度秘めている。しかし、現時点ではマルチプラットフォームでないこと、およびベースとなるOLEが貧弱なことなどから不透明な点が多い)。Java Beansがその環境を担うことになるようだが、どのように実現されるかは不明である。ただ、SunがOpenDocをJava Beansのオブジェクト・コンテナとして採用できるかどうか検討しているらしいので、行き着くところは同じという気がしないでもない。

    コンポーネントソフトウェア環境の道は険しい。しかし、これが実現されないと、WindowsCEのような、まったく別のモバイルOSが新たに登場するという非効率的な現状が、いつまでも繰り返される。ある程度のデータ互換性が保証されるというだけで、多くのユーザに歓迎されるということは、まさにコンポーネントソフトウェアが主役に躍りでるチャンスではないか?

    (この項おわり/Mike)


  • Back