オフィスソフト間の整合性を妨げるものはマクロ
フリーソフトウェアのオフィスソフトとして最も人気のあるOpenOffice.org（OOo）では、普通、マクロがStarBasic言語で書かれている。だが、現在、StarBasicマクロには2つの問題点が指摘されている。1つは、私がFixing the problems with OpenOffice.org extensionsで触れた問題である。たとえば、GNU/Linuxシステムでは、ディストリビューションのネイティブなパッケージ管理がマクロと相容れず、そのため、自己実行型OOoファイルに含める形ではマクロを配布できない。
2つ目はもっと一般的な問題であり、長期的にはこちらのほうがフリーソフトウェアのユーザにとって厄介かもしれない。OOo 2.0リリースでは、OpenDocumentフォーマットがデフォルトのファイルフォーマットになる予定であり、新リリースの目玉機能の1つとして話題になっている。OpenDocumentフォーマットは、StarOfficeとKOfficeでも採用されており、欧州委員会もこれを推奨していて、ISO標準になることも想定されている。
OOoやKOfficを始めとするオフィスソフトがOpenDocumentoをネイティブフォーマットにするのは、すばらしいことだと思う。だが、マクロを中心に考えると問題が残る。いずれどこかで、OOoユーザとKOfficeユーザがOpenDocumentファイルを交換したとき、そこに含まれるOOoマクロがKOfficeプログラムでは動かないという事態が発生する。プログラム間でファイルフォーマットが共通なら、当然、マクロも両方で使用できるはず、とユーザは考えるだろう。「だって、マクロもファイルの一部じゃないの？ それに、OOoとKOfficeでは共通のフォーマットが使えて便利だって、常々、宣伝してるじゃないか」だが、OpenDocument仕様のどこを見ても、マクロ言語に関する規定はない。しかも、誰に聞いても、規定するべきではないという答えが返ってくる。
私がこの問題に気づいたのは、もう1年以上前のことになる。すぐに、どうすればいいかを尋ねて回った。当時の平均的な答えは、「うーん、確かにそうだ。考えたことがなかった。だが、たぶん、すぐには何も起こらない」だった。そして、OpenDocumentが標準化され、OOo 2.0がすぐにやってくるというのに、解決策はどこからも現れてこない。
そもそもマクロとは何か
エンドユーザの立場からすると、OOoにおけるマクロの使い方は基本的に2通りある。すなわち、プログラム全体の機能拡張（操作されるすべてのファイルに適用される）と、特定ドキュメントの機能拡張である。この状況は、Webブラウザで起こったことに似ている。一方にFirefoxの機能拡張があり、他方にFirefoxに限らずどのブラウザでも実行できるJavaScriptアプレットがある。前者は特定ブラウザのために書かれているが、後者は特定Webページのために書かれている。ユーザは、どのWebブラウザにもJavaScriptとHTMLのサポートを要求するが、Internet ExplorerやOperaがFirefoxの拡張機能をサポートすることまでは期待していない。
プログラム機能を拡張するためのOOoマクロは、他のオフィスソフトでは必要ないものがほとんどだろう。プログラムごとに独自のやり方があるはずである。ディクショナリ、スペルチェッカ、ワードカウント、複数ファイルでのテキスト検索などは、いずれもこの範疇に属する。
もう1種類のマクロとは、たとえばユーザ入力検査のためのボタンをドキュメントに追加する、などのマクロである。当然、これはドキュメントについて回るはずのもの、とユーザは思うだろうし、どのプログラムでオープンでしても所定の機能を実行してくれるはず、と期待もするだろう。現実世界にこの種の機能を探すと、OpenDocument質問表に基づくe学習講座などが考えられる。そういうドキュメントは、OpenDocumentに準拠するあらゆるプログラムで完全に使用できなければならない。
StarBasicで統一？
StarBasicは、StarOffice/OOoですでに地位を確立しており、企業にも受け入れられ、入門書や参考書も数多く出ている。
一般に、OOoマクロはOOo APIかUNO（Universal Network Object）のディスパッチコールを使用する。OOo APIなら、開発者がすべてをコントロールできるうえ、インタフェース記述言語（IDL）で定義されていて、さまざまな言語からアクセスできる。ただ、BASICランタイムを用意しなければならない。OOo 2.0以降では、独立したURE（UNOランタイム環境）が提供されることもあって、UNOのほうが実装しやすいかもしれない。
外部から見ていると、KOfficeがStarBasicインタープリタを一から書き上げるより、OOoのものをそっくり取り入れるのが最も簡単な解決策であるように思える。ただ、ライセンス問題が浮上するのは必至だし、たとえそれがなくても、StarBasicインタープリタコードのモジュール性がどうか（つまり、簡単に移植できるのか）、開発者側に将来もそのモジュール性を維持する意図があるか、という問題がある。
要するに、どの解決策をとっても苦労が多そうである。
加えて、「プログラム」マクロと「ドキュメント」マクロの違いが、APIレベルでは定義しにくく、実装も難しいという問題がある。ドキュメントマクロだけをサポートする場合でも、APIのほぼ全体が必要となる。この方法を真剣に推奨する人は、OOo開発者自身を含め誰もいない。
次の1歩は？
最も現実的な解決策は、第3の道を探ることだろう。たとえば、KOffice開発者の一部は、Pythonインタープリタの採用を考えている。また、OOo 2.0の側も、簡単なロジックくらい（つまり、ここで言う「ドキュメント」マクロくらい）プログラミングなしで実装できるよう、何らかの方法を用意するべきだろう。W3C XForms標準はどのプログラムとも結びついていない。伝統的なマクロなど忘れ、XFormsをサポートするというのはどうだろうか。
方向が決まるまで、履歴書でStarBasicの技能を強調することはほどほどにしておいたほうがいいかもしれない。
原文
