タイトル	【MacWIRE配信予定】小池邦人のプログラミング日記》2001/12/11＜Mac OS Xに対する開発者からの提言＞(1)	カテゴリー	開発情報, Mac OS X, 小池邦人のプログラミング日記
作成日	2001/12/12 16:24:54	作成者	新居雅行

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 Builderには日本語版がない問題、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環境だけが行っても意味が無いのですが...）また、拡張子の扱いを確認できる最良のお手本アプリケーションが無い（アップル担当いわく）のも混乱の元です。参加者の中からは拡張子を隠すという手法にも「ユーザに混乱を招くだけ」との疑問の声が上がっていました。 （続く） [小池邦人/オッティモ]

関連リンク

オッティモ