■自作アプリとアップルの新技術の関係について
これから画像データベースのGrandMusee 3.0というソフトをお見せします。同時にひとつ前のバージョン2.0もお見せします。それからもうひとつは懐かしいのですが、ハンディスキャナ用ソフトのQuickScanです。これはDA（DeskAccessory）だった物です。1989年の製品ですが最新のシステムでもちゃんと起動します。容量は25KByteです。白黒画像をスキャニングしてマックに取り込むぐらいなら、昔はこのくらいの容量で作れたんですね。それに対してGrandMusee 3.0の容量は1.2MByteです。なぜこのようにアプリの容量が増えてしまったかについては、後でゆっくりご説明します。
■バージョンアップの功罪
GrandMusee 3.0のひとつ前のバージョン2.0は４年ぐらい前に作りました。スクロールバーが横に無いしデザインは完全に白黒基調です。フォルダ登録というボタンを押して画像ファイルをデータベースへ登録し、実際にダブルクリックすると画像が表示されるという仕組みです。ところで、これを発表してしばらくしてから、なんでグレースケール表示でカッコよくしないのかとユーザから言われたことがありました。その理由は簡単で、ユーザの中には速いマシンを使っている人もいれば、遅いマシンを使っている人もいる。それぞれマシン性能に違いがあるからです。遅いマシンの人には変に凝った画面のカラー化は、表示処理を重くして使いずらくするだけで何の利点もありません。
つまり、あるユーザからのフィードバックというのは、そのユーザ個人の都合しか考えていないわけです。大勢のためのソフトウェアを作る人はそのへんをちゃんと頭に入れておく必要があるわけです。まあ、バグはいけませんけど、あんまりまじめになってもいけません。カッコ悪いとかなんとか言われるかもしれませんが、白黒でいくときは白黒でいく（笑）カッコなんてちょっと使っているうちに気にならなくなりますからね。
例えば前バージョンでは、検索情報の入力にダイアログを使っています。どうしてこうしたかというと、この方法が一番簡単だったからです。検索方法もとてもシンプルです。ファイル名で検索をする場合には、ダイアログでファイル名を入れて「OK」ボタンを押す。なんでもかんでもダイアログでやってしまおうという作りですね。今見ても「しぶい」です。数値検索も、開始と終了の数値を入れて「あいだ」とか「以下」をボタンで選ぶ、実にクラシックなインタフェースです。
でも、これで４年間ずっと使われ続け、ついこの間までちゃんと売れていたんです。というのは、GrandMuseeというのは画像データの格納場所を階層化できるという大きな利点があったからです。そこが、他の画像データベースとかビューアとかと差別化できるポイントだったのです。これが大きな「売り」だったわけですね。この機能を利用したいがためにGrandMuseeを購入したユーザがかなりの数いたわけです。
つまりソフトウェアっていうのは、何かしら「売り」が一箇所だけでもあれば、他に欠点があってもある程度は評価されるわけです。人間と同じなんですね。非常にいい所が一箇所あれば、ちょっと細かい欠点があっても、みんなからあいつはいい奴だと思われるわけです。ひょっとするとMacintosh自身がそうかもしれませんね。必ずそういう長所を見て使ってくれているユーザが何人かはいるわけです。だからGrandMusee 2.0を出してから、次の大きなバージョンアップ（3.0）まで４年間のブランクがあったわけですが、古めかしいインタフェースと古めかしい白黒2値の画面で売れ続けることができました。
さすがに4年も経てば、ユーザからバージョンアップの要望があれやこれや出て来ます。例えば、先ほどの画面デザインをカッコよくしろとか３D表示で立体的にしろとか言うのもそうですし、スクロールバーを付けろとか、検索をもっとしやすくしろとか、階層をもっと深くできるようにしろとか、もうありとあらゆる要望が上がってきます。実はプログラマーから言うと、そういう変更はやろうと思えば割と簡単にできるのです。でも実際のところは、ユーザさんがそうした要望を言うのをあきらめるまで待つ「我慢」が必要です（笑）。
「バージョンアップしろ」と言ってくる人は、その要望が実現されれば個人的には満足するでしょう。でも、他のユーザにしてみれば、せっかく習得したやり方や使い方をバージョンアップによって再度リセットされてしまうわけです。こうしたことは、何らかのアプリケーションユーザの方なら一度は体験されていると思います。例えば、せかっくPageMakerのバージョン5.0を覚えたと思ったら、今度はバージョン6.0が出て使い方が全然違うとか、やっと昨日CodeWarrior Cでプロジェクトが作れるようになったのに、もう次のバージョンのIDEが出現してパニックに陥ったなどという体験です。
例えばCodeWarriorは、Javaも使えるようになりましたし、バージョンアップの度に色々と新しいことができるようになっています。まあそれはそれで、便利は便利なんですが、私などはC言語単独でしか使わないですから、そんなに頻繁なバージョンアップは必要ないわけです。ですから、ユーザから要望が出たら「ハイ、その通りですね。おっしゃる通りですね。お客様が正しいです」と、とりあえず納得した振りをして、そのままほおっておく（会場から大きな笑いがおこる）。そうした要望が溜まり、OS側の機能やマシンスピードがその要望や機能を実現しても誰も困らないレベルになったら「どーん」とバージョンアップをする方がユーザの為ではないでしょうか？もちろん、そうしている間に優秀なライバルが出てきたら、否が応でも対抗馬しなくてはいけなくなるケースもあるでしょうが、頻繁なバージョンアップが必ずユーザの為になるわけではないのです。
■ ソフトウェアを長生きさせるポイント
Mac版の画像データベースを製品として出している会社はそんなに多くないですが、画像ブラウザを出している会社は最近すごく増えましたね。重要な点は、そうした多くの製品の中で必ず生き残ることです。継続は力です。忘れらて消えちゃうのが一番寂しい。生き延びるポイントというのは、先ほども言いましたがソフトウェアになにかひとつ良い所、特徴があるということなんです。
GrandMuseeで言えば操作が簡単、登録方法が簡単だということで、データベースを「構築する」などという大それた感覚でなく使えるところが良かったかもしれません。扱いが簡単で階層化が簡単、今までのデータベースみたいにマクロ組んでレイアウトしてみたいなものが一切いらないという、それが「売り」だったのでしょう。４年間に溜まったユーザからの要望を実現しようとした時、ラッキーなことに、アップル側のシステムも大幅にバージョンアップしていました。ドラッグ＆ドロップもシステムで標準サポートされましたし、QuickTimeのバージョンもアップして、JPEGやGIFといったPICT以外の画像も表示できるようになっていました。QuickTime VRやQuickDraw 3Dにより今までにないタイプのメディアデータのハンドリングも容易になりましたし、なによりPowerPCのおかげでマシン性能が桁違いに良くなりました。
しかしアップル側のシステムアップも頻繁にやられると困りますね。微妙なタイミングでシステムのバージョンアップと自分のソフトのバージョンアップがすれ違うと、これはこれで大騒ぎになります。つまり、こちらがソフトウェアを出したばかりにシステムの特定の機能を大胆に変えられたりする場合です。ナウユーティリティとかノートンユーティリティとか、ユーティリティソフトが必ず遭遇する悲惨な結果が待ち受けるわけです。（会場から笑）。まあ、そのおかげで買い換え需要もでてくるわけですけど...。ショップに行くと7.5.3対応と書かれたパッケージの上に7.6対応のシールを貼ってあり「7.6.1に対応します」って店員がお客に説明しているような訳の分からない光景が見られるわけです。
ですからソフトはなるべくMac OSのガイドライン守り、どんなOSバージョンでも大丈夫なようにしておかなければいけません。「うちのアプリが動かない場合はアップルの方が悪いんだ！」ぐらいの自負がほしいわけです。まあ、ユーティリティ関係はガイドラインを外すところに「売り」があるわけですから難しいかもしれないですけどね。バージョンアップは慌てず、うまいタイミングまで待つのが得策です。それから買って使ってくれている人のことを第一に考えるという姿勢がアプリケーションを長生きさせるコツではないでしょうか。
■ 先生は身近にいる
自作アプリを作る場合に、アップルのシステム内で行われている「方法」を真似するっていうのは結構重要なんです。ユーザインタフェースなんかもそうなんですが、構造体の作り方、管理の仕方、ルーチン群の作り方などなど、インサイドマッキントッシュには非常にクールな方法が凝縮されています。まあ、中には「なんでこんなやり方するんだ！」っていう間抜けな方法もあるんですけど（笑）
私が一番最初にインサイドマッキントッシュを読んで素晴らしいなと思ったのはウィンドウの構造体とその管理方法です。WindowPtrからWindowRecordもGrafPortのどちらでも参照できるアイデアが非常に気に入りました。その後、私が作るアプリの主構造体は、WindowRecordの情報がGrafPortの下にあるように、すべてWindowRecordの下に追加するようにしています。つまりWindowPtrを参照すれば、その下にあるアプリに関する全パラメータを参照することができるわけです。こうすると、アプリの主役がウィンドウであることがはっきりし、処理の流れがすっきりして理解しやすくなります。また、各ルーチンの引き数にはWindowPtrをひとつ渡せば、そこからありとあらゆるアプリに関するパラメータが参照できて便利です。
私は、最初にMacintoshのアプリを作成する時に、ウィンドウマネジャを先生にしました。そのお陰で経験を積むに従ってアプリの構造がだんだんすっきりしてきました。見通しが良くなったって感じでしょうか？Macintoshのウィンドウマネジャを開発したとき、彼らは（アップルの制作者）頭の中では、それほどオブジェクト指向（Object Oriented Programming）を意識していなかったと思います。でも出来上がったものはかなりオブジェクト指向に準じていたわけです。そこがやっぱり最初にMacintoshのシステムを作った連中の天才たる所以だと思うんです。
つまり、「意識しなかったけど、完成したらそうなっていた」というのが正解なわけです。日本人が得意なのは、まったく逆ですね。オブジェクト指向が流行った時など、理論を先行させて、何にでも無理矢理使おうとしてました。C++が流行れば、書店の棚はC++の本でいっぱいになるでしょ。Javaが流行ればJavaの本で一杯になるじゃないですか。本当は逆なんです。オブジェクト指向というのは、開発をやっている最中にそういう考え方の方が便利なんで生まれたわけです。実際にソフト開発やっていて初めてオブジェクト指向という考え方に到達したわけです。やっている最中もしくはやり終えてから「俺がやっていたのはオブジェクト指向だったのか」というのが正解です。日本人はそうではないのですね。最初からオブジェクト指向の形でやろうと構えて無理矢理プログラムを組む。なんか違うなって感じです。
自分たちが管理しやすく美しいと思うシステムを組み立てていったらMacintoshができ上がったわけです。ですからToolBoxの各マネージャを見ると、確かにインプリメントはパスカルですけど、C++の変な使い方よりもよっぽど見栄えが良いわけです。ですからオブジェクト指向のソフト開発は、どんな言語でもできると思います。まあ、やりやすさの差はあるでしょうが。
■ある物はすべて利用する
話は元に戻りますけど、GrandMusee 3.0はバージョンアップでこういう風に変わりました。たとえば情報入力や検索に関しては、テキストカラムをドラッグ＆ドロップに対応させるためにもはやダイアログボックスは使っていません。またファインダ上への画像のドラッグ＆ドロップにも対応しています。これはアップルイベントが整備されたおかげですね。アップルイベントとアップルスクリプトが存在し、そしてファインダがスクリプタブルになったおかげです。せっかくある機能ですから、その機能をアプリからうまく使ってやるのが得策と言うものです。GrandMusee 3.0では画像ファイルの複製はアプリ自信が実行していません。ファインダにドロップしてやればファインダがその場所に複製してくれるわけです。例えばフォルダごと「どーん」とコピーしても、裏でファインダがせっせと仕事をしてくれ、表側のアプリは作業を継続できます。ファインダにファイルコピーを任せてしまったおかげで余分な手間をかけずにこうした機能が簡単に実現できるわけです。これは大きなメリットです。
例えば登録している画像データを消したいというときは、選択してdeleteキーを押せば消えます。GrandMusee 3.0では、この作業でデータベースへの登録を解除したことになります。本当にハードディスクから削除したい場合は、オプションキーを押しながらメニューから「消去」を選択します。そうすると、「消去と同時にごみ箱に移動します。取り消しはできませんので注意してください」とアラートが出て「OK」を押せば登録画像ファイルがゴミ箱に移動します。アプリは何もやっていません。実はこの作業を行っているのアップルイベントを受けたファインダなんですね。重要なのはファインダにそういうことをさせる「手段」を知っていることです。知らなければ全部自分で作らなければなりません。ファインダやシステムが何をやっているのか？何ができるかを良く知ることは、自分でしなければいけない作業をいかに楽にするかの大きな分かれ道になります。
やってもらえることは何でもファインダやシステムに任そうという態度が重要です（笑）QuickTimeの活用なんかもそうですけど、こうしておけばファインダやシステムが機能アップすると自動的に自作アプリも機能アップすることになります。これは相当ラッキーです。ここで紹介したバックグランドでのコピーや、表示できる画像ファイルのタイプがQuickTimeのバージョンアップと共に増えていくことなんかが良い例だと思います。
■例えばドラッグ＆ドロップを使う
今回のGrandMusee 3.0ではシステムのドラッグ＆ドロップ機能を多用しています。しかしドラッグ＆ドロップも自分のアプリの中だけで閉じて使う場合には快適なのですが、別アプリとの連携をやりだすと色々な問題に遭遇します。問題は、ドラッグしたデータを受け取る側のアプリ側（ターゲットアプリ）に個性があると言うことです。例えば画像データをドラッグ＆ドロップで他のアプリへ渡すときには２通りの渡し方があります。ひとつはPICT画像をダイレクトに渡してしまうという方法。もうひとつは、ファイルの保存位置情報、専門的に言うとFSSpecですね。その画像ファイルがボリュームのどこの場所に保存されているかという情報を渡してやる方法です。ここで、画像データベースに登録されている画像をドラッグ＆ドロップして別のアプリに渡すと想定します。これはユーザにとってはよくある状況ですね。しかし、これがなかなか大変な話なのです。
まず、ターゲットアプリがPhotoshop 4.0の場合から話しましょう。Photoshop 4.0はFSSpecは受け取ってくれませんがPICTデータは受け取ってくれます。ドロップした瞬間レイヤーを作成してそこに画像を表示します。次に、PageMill 2.0はどうでしょう？ データ形式がPICTであってもFSSpecであっても受け取ってくれます。画像ファイルをレイアウト中に割付けてくれるわけです。ですからJPEGやGIFデータで渡すときは、いちいちPICTに変換して渡すより、FSSpecとして渡した方が画像内容が変化しないので、都合が良いわけです。
では、PageMaker 6.0はどうでしょうか？バージョン5.0はドラッグ＆ドロップに対応していません。バージョン6.0はPICTを受け取ってくれます。でも本当はDTPソフトという性格上、PageMakerこそがFSSpecを受け取ってくれなければいけないような気がしますけど...。最後に、Quarkはどうでしょう？今のバージョンでは、システムのドラッグ＆ドロップはサポートしていないです（笑）バージョン４.0ではサポートされるのでしょうか？
アプリ側で、PICTで渡すかFSSpecで渡すかを固定しちゃいますと、ユーザが利用するターゲットアプリによっては「データが渡せない」という支障が出ます。仕方ないからどうするかというと「環境設定ダイアログ」かなんかでドラッグ＆ドロップ時はどちらの情報を渡すのかっていうのを設定できるようにしておくわけです。もっと困るのは、例えば同時に画像を３つ渡すようなケースですね。PageMaker 6.0は3つとも表示してくれますが、 PhotoShop 4.0は最初のデータしか表示してくれません。PageMill 2.0は３つ渡すと、ひとつ以上データが来た場合は「異常」と判断して３つともデータを無視するのです（笑）
じゃあ、アイデアとして一つの画像データを渡すときに、PICTデータとFSSPecの両方の情報を付加したらどうでしょうか？ドラッグ＆ドロップではこういうことも可能です。PageMill 2.0は、データが複数ですから残念ながら受け取ってくれません。PhotoShop 4.0はどちらかひとつを受け取ってくれます。多分PICTですね。それで、PageMaker 6.0はPICTだけ受け取るでしょう。ところがですね、世の中にデータを複数受けることができ、かつPICTとFSSpecの両方を受け取ってくれるというアプリケーションがるとします。多分あるでしょう。このアプリには同じ画像がふたついちゃうわけです。ドラッグ＆ドロップのインプリメントも、ユーザが実際に使う内容をシミュレーションしながら色々と練っていくと難しい難問にぶつかるわけです。
■例えばQuickTime VRを使う
難問にぶつかったのふたつ目の例を次に紹介しましょう。QuickTime VRです。このQuickTime VRというのは、APIがデベロッパーにオープンになったのは最近なんですね。バージョン2.0として機能拡張ファイルで提供されてからです。昔、QuickTime VR用のMovieを表示したい場合は、アップルからライセンス取って、QuickTime VR用の各種コンポーネン（QuickTime VRを動かすためのシステム一式）を自分のアプリケーションのリソースににくっつけなくちゃいけないんですよ。後でリソースを見てもらいますが、これがだいたい300KByteくらいあるかな？
少々アプリの容量が増えるけどQuickTime VR用のMovieをコントロールできるからいいやと思っていたんです。ところが、GrandMusee 3.0がもうちょいでGMになる時に、新しいバージョン2.0が出てきたわけです。「自分のアプリにバージョン1.0の機能をつけていたら、バージョン2.0をインストールしても2.0の機能が使えないのでは？」と嫌な予感がしたんですね。嫌な予感は見事に当たりました（笑）1.0用のコンポーネントを付加してあると、2.0をインストールしているにもかかわらず1.0の機能が優先してしまうのです。やられたって感じですよね。
アップルと長い間つき合っていると、結構こういうことに遭遇します。それでも、困っていてもしょうがないから、またまた「環境設定ダイアログ」なわけです。組み込みバージョン1.0か、外付けのバージョン2.0か、ユーザがどちらを使うか選択できるようにしたわけです。もし2.0の機能拡張をインストールして、そちらを利用したい場合には、組み込み側を強制的にOFFにするわけですね。こうしたことを何も対処しずにほっておくと「なんでGrandMusee 3.0のVRコントロールは2.0準拠じゃないんだ！」とユーザーからクレームが来るわけです。
■Appleの新技術を使う場合の宿命
次はQickDraw3Dのお話です。最初GranMusee 3.0をやりだしたころは、アップルが提供していたQuickDraw3Dのバージョンは1.0だったんです。確かバージョン1.0.6だったかな？素直に動いていたんです。ところが、途中でアップルがバージョン1.5.1を出しました。途端に1.0用に作ったアプリでは、3DMFファイルを読んでも表示しない状態になってしまったんです。どうにもならないから、これは1.5.1「のみ」対応に変更するしかなかったですね。もしユーザが1.0.6をインストールしている場合は「1.5.1に変えてください」と言うメッセージを表示しなければいけなくなりました。そしたら、ユーザから「うちでは1.0.6でしか動かない3Dソフトを使うから、このメッセージはうるさい！」なんてクレームが来たりして（笑）
本当だったらバックコンパチビリティを取って、1.5.1が入っていても1.0.6が入っていても、3DMFファイルをビューアで見るぐらいのことはできなきゃいけないわけです。アップルのできたての技術を利用すると、こういうことがままあります。まあ、これはできたて技術を使う時の宿命なんですね。なるべく早い次期にアップルの新技術を自分のアプリに取り込もうとすると、こういうリスクが生じるわけです。一番良いタイミングがは、やはり新技術が出た瞬間にアプリで完全にサポートできることですから....。まあ、新技術が外付けの機能拡張ファイルなどで提供され、ユーザがそれを外せば問題が解消されるような時は良いのですが、システム内に含まれてしまった状態で、思ったように動かない時などは非常に困ります。あせりますね。新しい技術を使う場合には、そのへんを慎重に考慮しなければいけないと思います。
ただ良い点は、先ほども言いましたが新機能の機能アップがそのままアプリ側の機能アップに結びつくことですね。例えば、スピーチマネージャは最初は英語版だけだったんですよ。「まさこ」「ひろし」なんてボイスはなかったわけです。ところがアップルジャパンが日本語対応ボイスを作ってくれたおかげで、英語版のスピーチマネージャに対応していた私のアプリは全部自動的に「ひらがな」を喋れるようになったわけです。アップルの技術の良い所は、たとえ、英語版であっても確実にサポートしておけば、あとで日本語版に対応したとき、特別なことをしなくてもそれなりの効果が得られるというところです。日本語が使えないからやめようと思うのではなくて、面白い技術があったら英語用でもサポートしておくことが重要です。そうすれば、少し待てばひょっとすると日本語のサポートが可能になるかもしれません。そうすれば何の苦労もなく自作アプリのアドバンテージになるわけです。
GrandMusee 3.0は、もうひとつそれを見越して音声認識に対応しているんです。当然、現在は北米英語の認識だけですけどね。音声認識でブラウジングできたりプレゼンテーションしたりすることができます。これも将来、音声認識が日本語対応になれば、なるかどうかは知りませんけど？なって欲しいですね（笑）結構なアドバンテージになります。ですから、あまり労力を使わなくてインプリメントでき「結構面白く有用で、今英語版しかないんだけど」というう技術は自分のアプリでどんどん活用した方が良いです。どんな小さなものでも入れておくと、後で大きなアドバンテージになることがあります。ただ、インプリメントするのに大変だったら話は変わりますけどね。スピーチマネージャとか、QuickTimeVRのMovieやQuickDraw 3Dの3DMFファイルの表示、音声認識などなど、この辺はインプリメントに大した労力がかからないんです。OpenDocをこなすのよりは、はるかに簡単でした（笑）
■いくつかの新技術が失敗したわけ
今までに、アップルがそれを広めることに失敗した新技術もいくつか沢山ありました。
PowerTalkやQuickDraw GX、OpenDocなどがその代表選手でしょうか。失敗にはいろいろなパターンがあります。ただ、偶然かもしれませんが、私がアプリに積極的に使わなかった技術はほとんど生き残っていません。なんで自分のアプリに使わなかったかというと、今思うに、まず第一にインプリメントが難しかったということでしょうか？ドキュメントが膨大である。それを読むのが面倒くさかったって言うのもあるかもしれませんね。（笑）もうひとつは、その技術を使って何をやっていいか分からないケースですよね。なにも面白いアイデアが出てこない。そうそう、もうひとつは誰もが使える形でシステムにバンドルされなかったということも重要なポイントでしょう。QuickDraw GXなんかが一番ひどいケースでしたね。メモリ不足で使えない人が沢山いたのです。アプリを供給する側としては、だれもが利用できないということは、新技術をインプリメントするのをためらう最大の原因になると思います。
また、MacintoshにはQuickDraw GXがない時からIllustratorとかFreeHandといった強力なPostScript系のアプリがありましたよね。QuickDraw GXには、そうしたアプリをいちから書きかえさせるほど、超強力なアドバンテージがなかったのかもしれません。労力に見合ったペイがないとデベロッパー側に判断されたんでしょうね。とにかく1000ページ以上にもなるドキュメントを読破して、自分のソフトに機能を取り込むのは並大抵の労力ではありません。それと比較してドラッグ＆ドロップやスピーチ、音声認識ならば、30ページくらいのドキュメントを読めば一通りの機能が実現できるわけです。この手軽さがQuickDraw GXにもあれば、もっといろんなアプリに使われたと思います。まあ、プリントアウトやフォントなど、あっちこっち手を延ばしすぎて、巨大になりすぎて自滅したって感じでしょうか。でも、最近やっと誰もが使える環境が整い、プリントアウトの部分もばっさり切り落としましたので、何かに利用してみようかなと考えています。
どんな新技術が成功するかを判断するのは大変難しいですが、私の基準としては自分が使って面白いな、割と簡単に利用できるな、と言うのを自然に選択しているように思います。やはり使い道があってこその技術ですものね。
copyright 2000 Ottimo, Inc. All rights reserved
無断転載・引用禁止
Contact Us: koike@ottimo.co.jp