● Mac OS Xに対する開発者からの15の提言（2001/12/12）

12月８日と９日に、MOSA主催の第8回「Macintosh Software Meeting 湘南2001」が開催されました。ウエルカムパーティも終了し、多くの人が夢うつつの丑三つ時（笑）「Mac OS Xに対する開発者からの10の提言をまとめようではないか！」と言う趣旨のもと、有志の面々が喧々諤々の大討論会を繰り広げました（ちょっと大げさ）。今回は、そこで提案された提言の詳細を、まとめて紹介していみたいと思います。

結論から言うと、とてもじゃないですが10に収めることはできず（涙）、何とか圧縮して、結局「15の提言」というところに落ち着きました。ちなみに、各提言には番号が割り振られていますが、それらは優先順位を意味しておりません。Macintoshデベロッパーにとって、すべての提言は同等の重みを持ち、いずれも大変重要であることを強調しておきます。また、これから取り上げる提言に対し、Apple社が今まで何も行動を起こさなかったわけでもありません。「さらなる努力をお願いしたい」という主旨なので、くれぐれも誤解無きようお願い致します。まあ、中には本当のバツ印（笑）もあるのですが、二重丸ぐらいあげてもよい項目だってあります。つまり、「Apple社は現状に満足することなく三重丸や花丸を目指して頑張って欲しい！」と言う、開発者からのエールだと受け取っていただければ幸いです。



（1）Mac OS X関連ドキュメントの完全な提示と日本語訳の配布

これについては詳しい説明は必要ないでしょう。Mac OS Xや、それに付随するテクノロジーに関するドキュメントは不十分です。それに輪をかけて、日本語訳されているドキュメントは少数です（と言うより皆無に近い）。最近のアップル社を見ていると、この件についてはあきらめてしまっている感じさえあります。これでは「母国語ドキュメントも用意せずにソフト開発して欲しいとは片腹痛し！」と言われても仕方ありません。確かに、開発者が英語ドキュメントを読むことは必要不可欠なのですが、その負担をなるべく軽くするのもメーカの勤めのはずです。Macintoshの環境が大きく変化しようとしているこの時期こそが、ドキュメントの日本語化を再度見直す良い機会だと感じます。参加者からは「著作権の問題さえクリアーにしてくれれば、ボランティアで分担して訳しても良い」という声も上がっていたことを付け加えておきます。

（2）CarbonLibの完成とMac OS Xへのすみやかなる搭載

CarbonLibの安定なくしてMac OS Xの成功はありえません。Mac OS X自体がいまだ未完成で開発が継続している現状では仕方がないかもしれませんが、とにかくCarbonLibの動作を安定させバージョン番号を固定してもらいたいものです。CarbonLibは、Mac OS 9用アプリケーションをMac OS Xへと移植するために、大変重要な役割を担っています。CarbonLibのバグが減り、ユーザが安心してアプリケーションを使える環境が整うことこそ、デベロッパーが自社製品をMac OS Xへ移植しようと思い立つ重要な条件なのです。

（3）Carbon、Cocoa、Javaなどサンプルソースコードのさらなる充実

Mac OS Xでは、ドキュメントの不足と同様に、サンプルソースコードの不足も目立ちます。確かに、開発途中の技術に関するサンプルソースコードを提供する事については、色々と難しい問題が存在すると思います。しかし、何の手がかりも無く問題を解決することは不可能です。カッコつける必要はまったくありません。「このAPIはこんな感じ使える...」程度で良いのです。どんなレベルでも構いませんので、新技術に関するサンプルソースコードの提供を充実させて欲しいと思います。私的には、ヘッダーファイルから機能を推測する「探偵ごっこ」は、もうこりごりです。

（4）ドライバ開発のための情報提供と人材育成サポートの充実

これは、現在のMacintsh市場でもっとも深刻化している問題を指摘しています。パソコン周辺機器天国の日本においては、USやヨーロッパ市場以上に、優秀なドライバの開発が自社製品成功へのカギとなります。また、一般ユーザがMac OS Xへ移行する判断基準にも、自分が所有している周辺機器が動くかどうかという点があります。現在、Mac OS X用のドライバ開発者は絶対的に不足しています。Apple社は、ドライバ関連のドキュメントやSDKの日本語化、それに付随する情報の提供、開発に必要なツールや対象機種の貸し出し、定期的なキッチンやセミナーの開催など、人材育成に対してもっと積極的に行動すべきだと思います。そうしないと、大々的にぶち上げた「デジタルハブ構想」も絵に描いた餅に成りかねません。

（5）Java環境や開発ツールの日本語に関わる問題の解消

開発ツールや動作環境など、まだ完全に日本語対応されていない箇所を改善してもらいたいと思います。たとえば、Javaで作成したアプリケーションの日本語表記が化ける問題、Interface Buildeには日本語版がない問題、Terminalで日本語が通らない問題などなど。せっかくMac OS XでUnicode標準のシステムを構築したわけですから、宝の持ち腐れにならないように、Apple社が提供するツールソフトや起動環境ぐらいは、多国語対応を完璧にして欲しいと思います。

（6）バグレポートを日本語で受けるサイトや日本語版専用MLのオープン

現在、開発者側からApple社へのバグリポートは、以下のサイトで一括フィードバックできるようになってます。

http://developer.apple.com/bugreporter/

ただし、その内容は英語で記述する必要があり、バグの内容が日本語環境に依存するような時には、Apple側とのコミュニケーションに手間がかかり、問題解決の障害となります。英語の苦手なデベロッパーでも、見つけた時点ですみやかにバグレポートが報告できるように、アップル社内に現在のMac OS Xのフィードバッグサイトと同じサイトを設置したらどうでしょうか？加えて、直接Apple担当者とコミュニケーションするのは無理だとしても、日本の担当者経由や開発者同士のコミュニケーションを行う場として、開発者用の日本語メーリングリストや掲示板などの提供も望まれます。

（7）Carbon、Cocoa、Java Framework間の機能差の徹底的解消

一般ユーザにCarbonアプリ、Cocoaアプリ、javaアプリｎ違いを意識させることは筋違いです。そのためには、各環境で開発されたアプリケーションの機能差を極力無くす必要があります。また、同じことをするのに、各環境で違う方法を採用しているのもナンセンスです。例えば、ユーザがカラーを選択する時に利用するカラーピッカーは、CocoaアプリとCarbonアプリで同じダイアログが表示されるべきです。フォント選択に使うフォントパレットやMac OS X標準のツールバーが、Cocoaアプリからしか使えないのも納得できません。また、CocoaからはFSRefでファイルアクセスができないなど、API内部で生じているFramework間のギャップも、システム側で吸収し解消して欲しいと思います。

（8）クリエータとファイルタイプ使用の徹底と拡張子問題の解決

今回のセミナーで、Apple社は、ドキュメントにクリエータとファイルタイプを付けることを推奨していることが判明しました。これには一安心しましたが、その約束をApple社提供のアプリケーションが守っていないのはマズイと思います。また、現状の場当たり的な拡張子の取り扱いについても、色々と不満が噴出していました。拡張子のコンフリクトを防ぐために、現在のクリエータやファイルタイプと同様、どこかの組織が管理する必要があるはずなのですが、その仕組みも確立されていません。（まあ、Macintosh環境だけが行っても意味が無いのですが...）また、拡張子の扱いを確認できる最良のお手本アプリケーションが無い（アップル担当いわく）のも混乱の元です。参加者の中からは拡張子を隠すという手法にも「ユーザに混乱を招くだけ」との疑問の声が上がっていました。

（9）リソースのサポート継続とInterface Builderの機能拡充

現状のCarbonアプリケーションでは、たとえリソースフォークを使わないとしても、リソース自体の呪縛から逃れる術はありません。メニュー、コントロール、ウィンドウだけが扱えるNibファイルでは不十分なのです。Macintoshにとってリソースとは、誕生した時からのの歴史的産物であり膨大な資産なのです。ResEditやResorcererなどの外部ツールにたよるだけではなく、Interface Builderにも、アイコン、カーソル、文字列、PICTといった典型的なリソースを編集する機能があるのが理想だと思います。リソースファイルでなくても、Nibファイルとしてデータ出力できれば問題ないわけですから。

（10）APIや技術仕様変更の差別なき速やかなる通達

この件は、開発最前線のデベロッパーにとっては死活問題です。近々出荷を控えてパッケージ化したアプリケーションが、APIの仕様変更で突然動かなくなってしまうケースを想像してみてください。Apple社にすれば、何らかの大きな理由があるため、そうした行動をとるのでしょうが、それについては開発者側への事前連絡（それもなるべく早い時期に）が不可欠だと思われます。どうも、こうした情報通達は大手ソフトウェアーベンダーが優先される傾向にあるようですが、情報開示の差別はいけません！だって、次世代のキラーソフトを開発してくれる会社は、どこに存在しているか分からないのですから。

（11）実装状況と技術ドキュメントとのギャップの解消と情報公開

ヘッダーファイルには定義されているのに、実際に使用してみると、まだ実装されていないAPIに遭遇することがあります。このような混乱を、いちいちApple側に問い合わせて確認していたのでは、手間がかかるだけで時間の無駄です。間違った情報を元に開発を進ねてしまう事ほど「むなしい」ことはありません。そうした情報は、どこかで一括閲覧でき、技術ドキュメントと実装のギャップをいち早く確認できる仕組みを作ってほしいと思います。また、技術ドキュメントの中には「ファイルアクセスにはFileURLを使え」とか「リソースフォークを使うな」など、理想論を展開している物があります。ところが、現実には、QuickTimeにはFileURLどころかFSRefが使えるAPIさえ存在しませんし、ドキュメントのプレビュー画像や用紙設定情報はいまだにリソースフォークに付加されています。現実とのギャップがあるドキュメントの提示は極力止めてほしいと思います。「出来ないことを書くな！」ですね（笑）。

（12）システムやユーザデータのバックアップとリカバー方法の確立

デベロッパーは、開発中のアプリケーションや周辺機器の動作確認のために、自分の環境内でユーザ環境をシミュレーションする必要があります。昔なら、１ボリュームに複数バージョンのシステムフォルダを置き、必要時に切り替えて確認することができました。しかし、Mac OS Xではバージョン変移が激しいにもかかわらず、こうした手法を取ることができません。また、一般ユーザに対してメンテナンスをする場合にも、気軽に「前のシステムに戻してください」「システムを入れ替えてください」と言えない状況に陥っています。何らかの仕組みを構築するかツールを提供することで、どんなユーザでも簡単にシステムやユーザデータのバックアップとリカバーが可能になることが切望されます。

（13）Classic環境の安定とMac OS 9.Xとの親和性の改善

Mac OS XがClassic環境との決別するのは、当分先のことでしょう。Mac OS XとMac OS 9.Xとが混在している環境をメンテナンスしているデベロッパーもいます。環境を切り替えるとメニュー形態が変わる現状は、ユーザの混乱を招いているだけで、ユーザサポートをしているデベロッパー側の負担も増大します。また、Classic環境とMac OS X環境間のカット＆ペースト、ドラッグ＆ドロップ、ネットワークなどによるデータ移動なども何の違和感無くスムーズに行えるよう、両環境間の親和性を高める努力を怠らないでほしいと思います。Classic環境の起動スピードや安定性をさらに改善する仕組みも必要になるかもしれません。

（14）開発ツールやシステムパフォーマンスのさらなる最適化

これも説明の必要はないでしょう。Mac OS X 10.1になり、システムのパフォーマンスや体感スピードは随分改善されました。しかし、Mac OS 9.Xと比較すると、処理がもたつく場合がまだまだ目立ちます。Project Builderのコンパイルやリンクスピード、画面描画スピード、Javaアプリの動作スピード、PowerBookでのバッテリーのもちなど。搭載ツールやシステムのさらなるパフォーマンスアップや最適化をお願いしたいと思います。

（15）FinderやDockを含めたMac OS Xの使い勝手のさらなる改善

この件は、一般ユーザからも大量にフィードバックされていると思われます。デスクトップ上に「ごみ箱」を置けるオプション、コマンド+Nキーによる新規フォルダ作成、シングルクリックによるファイル名変更、メニューの透明度の選択、カラーラベルやフォルダーナビゲーションの復活、アピアランスオプションの拡充などなど。Macintoshでは、FinderやDockの操作性の善し悪しが作業効率に大きく影響します。開発作業も例外ではありません。この点に関しては、一般ユーザと同様、手になじんだユーザインターフェースの復活や更なる改良を望みたいと思います。



以上で「15の提言」は終わりです。Apple社は、Macintosh市場でソフトや周辺機器を開発しているで日本のデベロッパーの苦労を再確認すべきでしょう。そして、それを解消するように努めることこそ、Macintosh市場を新しい局面に押し上げる一番の近道ではないでしょうか？

残され島の人々はまだまだ元気です。ハイハーバーを目指してがんばっています。お互い努力を継続すれば残され島も大きく隆起するでしょう！最後はきっと大団円さ（笑）