MOSAic コラム
Flashに思う… 小池邦人
（2010.05.18）
iPhoneで話題になっているFlash問題は2つの異なる局面で発生しています。ひとつはSafariで「Flash Player Plugin」がサポートされないため、ウェブ上のFlashコンテンツが表示（再生）できないことです。もう一つは、Apple社からiPhone SDK以外で開発されたiPhoneアプリを認可しない規約が提示されたため、Adobe社が用意したクロスプラットフォーム向けFlash環境でiPhoneアプリを開発しても、それをApp Storeへ登録申請できないことです。
これらの問題、どうしてもJobs個人や政治的な話題が前面に出てしまい、現場からの技術的考察が少ないような気がします。何やらJobs一人ですべてを決めているように歪曲し脚色されがちですが（笑）当然、Apple社の屈強なソフトウェアチームが技術的な裏付けを取り上部へレポートを上げることで企業としての最終意思決定となっているはずです（多分）。Flashを使うとバッテリー消費が大きくバグも多いと言及されている点は、そうした調査レポートからの引用だと思われます。
また両方の問題を混同している人も多数見かけますが、もともとこの2つは異なる状況下で発生しています。ただし、両者の根幹にはまったく同じ原因が横たわっている可能性もあるようで、その中のひとつは、iPhoneやiPadの「ユーザ体験（User Experience）の劣化」に対する大きな懸念です。加えて、Apple社側には「Adobe社の長きに渡る技術的怠慢」という認識（恨み？）もありそうです…。実際、少なからずあるでしょう（笑）。
・ 良好なユーザ体験が最優先
この問題を議論する場合に、iPhoneやiPadを今までのPC（パーソナルコンピュータ）と同列に並べて話を進める人がいますが、おそらくそれは間違いです。Apple社の最終ゴールは、PCでの劣悪なユーザ体験を撤廃し、現在の環境（物理的制約はある）において最善なユーザ体験を提供することだと思われます。つまり「脱PC」です。よって、この問題を議論するのに旧態依然としたPCの状況を持ち出しても、妥当な結論は導かれない気がします。
iPhoneやiPadを旧PCから脱却させて別カテゴリーの製品にするには、PCでの反省点を生かす必要があります。例えば、PCでの劣悪なユーザ体験の中でも最も改善すべきは「セキュリティ問題」でしょう。Apple社の行動には、セキュリティを保つためならユーザに対して幾らかの不便を与えても、それを保全する仕組みを優先するという判断が見受けられます。例えば、iPhoen OSでの機能限定や、App Storeでの審査などがそれです。
現在のPC体験を思い浮かべてみましょう。ウェブ閲覧とメールだけを使うユーザが、パソコン購入後に高価なウィルスチェックやセキュリティソフトを購入、何故か処理が遅くなったのでパフォーマンスアプリを購入、するとシステムが不安定になりクラッシュを繰り返すのでバックアップを取る仕組みの構築に奔走…。こうした異常なユーザ体験はもう二度と繰り返したくない。今度こそ絶対に避けるべきだという決意があるのでしょう（そうは思いませんか？）。
・ 臨機応変に対処できないのか？
iPhone OSでは、セキュリティ対策としてJavaScript以外の言語処理系の実装は禁止されています。セキュリティの穴を防ぐためにシステム全体に影響を及ぼす言語処理を禁止するのは良策です。そう言う意味ではFlashだけが特別な訳ではなく、iPhone OSにはJavaなども実装されていません。この制限は徹底されており、Safari（ウェブ環境）だけでなく、一般アプリで言語処理を扱うこと（例えば簡易スクリプトなど）も禁止です。よって、これに反するアプリはApp Storeへ申請しても間違いなくリジェクトされます。
デバイスがiPhoneならばそうした制限もOKだと思いますが、教育機関へも大量に導入されるだろうiPadを考えると、この処置を回避する道も残しておいて頂きたい。そうでないと、子供や学生にiPadを用いたプログラミングを体験させる手段が無くなります。例えば、Smalltalk環境のひとつSqueak（スクイーク）を利用した「Squeak EToys」などは、教育機関でも高い評価を得ています。絵画や音楽、デザインと同等にプログラミングの楽しさを広めるためには、何らかの言語の習得は避けて通れません。
プログラミング教育のために、Sandbox内でインタープリタ系の言語を使う程度は許してもらいたいところです。 これ以外の制限や検問に関しても、Apple社の「臨機応変」の対応が望まれますが、今までの流れから「あれが良いのにコレがダメなのは何故？」という議論が巻き起こるのは必至であり、Apple社の対応にも難しい側面が有ることも理解できます。とにかく言語は何でも構いません、それを使えるHyperCardのような教育用プログラミング環境がApp Storeで認可されることを切望したいと思います。
・ 伝言ゲームをやってみる
話を元に戻して、もうひとつのFlashの問題について考えてみます。ちなみに、こちらの問題もFlash環境だけの話ではありません。別の開発環境についても言えることです。ここでは、アプリ動作の仕組みを伝言ゲームに例えてみます。何人かのメンバーが一列に並んで左側の人から右側の人へと順に伝言を伝えます。一番左側の人がプログラマが書いたソースコードの役割だとすると、一番右側の人がある機能を実行するために最終的にデバイスへ命令を伝えるわけです。
例えばFlashでiPhoneアプリを開発すると言うことは、この伝言システムの列の中にさらに何人ものメンバーを追加することを意味します。実は、どの位置に何人加えるかも大きな問題なのですが、とにかく物理的に見れば（加えた人が優秀かどうかは別として）処理が完結するまでの人数が増えます（アプリ容量の増加）。伝言が伝わるスピードも遅くなります（処理速度の低下）。そして今までより伝言のミスが起こる確率が高くなります（バグの増加）。
つまりアプリの処理スピード低下、 容量増大 、バグ増加、といったユーザ体験を劣化させる要因が確実に増えるわけです（確率的に）。実際の例を挙げてみますと、ネイティブ環境で開発すれば数十Kバイトの容量で収まるアプリも、Flash環境で開発すると7〜８Mバイトの容量になります。これは、Flashから変換されたすべてのiPhoneアプリに「Flash Player Plugin」に準ずるソフトモジュールが付加されている結果です。今風に言えば「エコでない」ということです（笑）。
・ 更なる大きな問題点
更に大きな問題点があります。システムが一新されて最初のメンバーが入れ替わったとします。しかし、後で外部から投入されたメンバーはそのままです。この状況下、最悪の場合には最初のメンバーと後のメンバーで「言葉が通じない」問題が生じます。つまりクラッシュです（笑）。仕方がないので、後からのメンバーを再教育し（もしくは交代）新規メンバーのレベルに合わせる必要がありますが、その作業にあまり時間がかかると、システムとしての競争力を保てなくなります。
ネイティブ開発環境であれば、最初のメンバー（OSやFramework）が一新された時点ですべての最新機能が利用できるようになります。例えば、iPhone OS 4.0で導入されたアプリの高速スイッチ機能であれば、実際のところ3分もあれば対応可能です（Xcodeでビルドし直すだけ）。しかし、もしこれがFlashコンテンツから変換されたアプリだとすると、Flash自体の変換処理が4.0のランタイム環境をサポートしないかぎりは、この機能に対応できないことになります。
この仕組みには、アプリ開発可能なデベロッパー数を増やすメリットもあります（伝搬距離が長くなるので）。昔のMac市場のように、デベロッパーが少なくてMacオリジナルアプリの開発が困難な場合、こうしたクロスプラットフォーム開発環境を活用しWindows用アプリを移植して需要を満たしていました。しかし、iPhone OSの場合には既に多くのネイティブデベロッパーがいて、20万以上ものアプリが提供されています。 今さらそうした仕組みが必要かと問われれば「必要ない」と判断されても仕方がないでしょう。
・ パソコンの悪夢が蘇る
ところで、FlashアプリはiPhone OSで使うAPIやメソッドを使っていない可能性があります（追加メンバーの並び位置の問題）。この場合、iPhone OSが最新にアップデートされた時に特定の機能が使えなくなったり、アプリ自体が起動できなくなる可能性が高まります（Photoshop Elementsみたいに）。加えて、APIやクラス＆メソッドを追跡することで「アプリが何をしているのか？」を解析することも困難となり、Apple社が「セキュリティ面の大きな脅威」と見なすのも仕方がないことです。
新しいOSにしたらアプリが起動しなくなった。特定の機能が使えなくなった。なのに新OSへの対応はまったく進まない。これもパソコンで繰り返されてきた劣悪なユーザ体験のひとつです。逆にルールを守りネイティブなAPIのみを正しく利用したアプリの寿命は長く、多くのユーザから信頼を勝ち得ます。例えば、筆者が1986年にMacのToolBox APIのみを使い開発した「QuickScan」（当時はDesk Accessary）は、現在でもMac OS Xのクラシック環境でちゃんと動きます。
Adobe社がFlashコンテンツをiPhoneアプリに変換する仕組みを何としても世に広めたいのならば、FlashのコードをiPhone OSのAPIやメソッドに変換し、それをXcodeのソースコード（C、C++、Objective-C）として吐き出す仕組みを提供することです。その後デベロッパーがXcodeでiPhoneアプリをビルドすれば、Apple社も文句の付けようがありません。「Flashはクロスプラットフォーム対応だ」と叫ぶのであれば、Adobe社にはそのくらいの技術と根性を見せて欲しいところです（笑）。
・競争力あるアプリの開発
Jobsが「iPadにはiPhoneで使い方をマスターした何千万人の潜在ユーザがいる」と話していました。共通で快適なユーザ体験だけでなく、ハイブリッドアプリを購入すれば両デバイスで使える「お得感」も大きな購入動機になるはずです。これからは、iPadを購入したユーザが逆にiPhoneを選ぶケースも増えるかもしれません。また、将来的にはMac上でiPadのアプリが起動できる可能性もあります（既にシミュレータ上ではx86コードで動いている）。間違いなくターゲット市場は拡大しています。
現在では、OpenGLやCoreGraphicsを用いた優秀な2D＆3Dや物理エンジンも多数あります。それらを活用すればFlashコンテンツのiPhoneへの移植も割と簡単でしょう。既に多くのFlashゲームがiPhoneアプリとして登場している実績もあります。また、iPhoneのネイティブ開発環境をマスターすれば、その経験と知識はそのままiPadアプリ開発に生かせます。加えて、いくらかの追加学習でMacアプリの開発も可能になるわけです。今、CocoaやObjective-Cにチャレンジして損をすることはないと確信します。
誰もが自分の使い慣れた環境でアプリを開発したいものです。そういう意味では、今回の制限は、FlashによるiPhoneアプリ開発を考慮していた人にとって不幸な出来事でした。しかしデベロッパーの視点からすると、競争力のあるアプリを世に出したければ、ネイティブアプリを開発する以外に選択の余地はありません。素晴らしいアイデアを実現したFlashコンテンツがあり「これなら絶対にiPhone界を征服できる」という確信があれば、今すぐネイティブアプリへ移植し、速攻でApp Storeへ登録申請されることをご推奨いたします。
iPadに思う… 小池邦人
（2010.02.01）
この比較、あまり意味がないと思います。iPadでiBookStoreから購入した書籍を読むという行為は、所有するであろう多数のアプリの1つを使う事でしかありません。Apple社がこのデバイスを登場させた主目的はそれだけではないはずです。でなければ、iWorkの移植などしないでしょうしね。片方しか購入してはいけないという法律でもあれば別ですが（笑）適材適所で良いのではないでしょうか。それより、日本ではそうしたデバイスで書籍を読むという習慣が定着するのか？ コンテンツ所有している出版社はどう対処するつもりなのか？ といった議論の方が大事だと思います。
・Flashがない理由
「セキュリティの懸念（前科アリ）」「不安定（確かに）」「CPUリソース大食い（確かに）」「パフォーマンス低し（確かに）」「CEOが嫌い」。 前記の理由から最後の結論に至るのかもしれません（笑）。ところで、イベントのデモでPlug-inがインストールされていないサイトが大きく表示されました。デモは念入りにリハーサルしたでしょうから、何故わざわざあのページを開いたのでしょうか？「断固採用しない意思表示」「HTML 5を使え！」「コンテンツ購入して専用アプリで見ろ」「直前に実装して対iPadのポジティブ感情をアップ」「開くページを間違えた」。$1,000事前リーク作戦（多分）の見事さを見ても、我々は偉大なる策略家に躍らされているだけなのかもしれませんね…。
・カメラが搭載されていない理由
こちらも色々な推測があります。「iPhoneとiPod touch（次期機種で予定）の需要が大きすぎてカメラモジュールが不足してしまい今回は見送った」（笑）。もしくは、搭載予定のカメラモジュールに何か問題があったのかもしれません（前回のiPod touch発表の時もそんな感じ？）。 iPadの性格上、本体上部にあると被写体を固定することが難いですから、ワイアレスの外付けカメラの方が（サードパーティが提供）使い勝手が良いとの判断でしょうか？ 米国サイトの情報によると、iPhone SDK 3.2βにはカメラからの画像取り込み機能の痕跡があるそうなので、カメラからの画像や映像入力をまったく考慮していないという訳ではなさそうです。
・複数アプリが同時起動できない理由
「ハードウェアリソースの消費」 「セキュリティの懸念 」「フラッシュメモリ劣化の加速」「ユーザ経験向上の熟慮」「社内意見がまとまらない」「CEOが嫌い」。一番最初が正式発表されている理由です。加えて、現状のパソコンと同じ道を歩む訳にはいかないので、セキュリティの懸念も大きいでしょう。ユーザ体験を重視するのはターゲットとなる購入層を見極めての判断かもしれません？ まあ、最後の理由でなければ（笑）近々解決され、コピー&ペーストの様に遅まきながらの登場となるでしょう。何せバックグランドプロセスを含めてOS側の能力としてはまったく問題ない訳ですから、素直にiPhone OS 4.0に期待しましょう（Resolution Independentはどうなった？）。
・で、どんな感じの実装が良いのか？
ちなみに、Macの最初のFinderは一度に1つのアプリしか起動できませんでした。その不満を糧にアンディ・ハーツフィールドがスイッチャーを作り、その後マルチFinderに代わり、Mac OS Xでついに真のマルチタスクに到達しました。こちらはOS能力とリソース不足の長き歴史です。 今思うに、初期Finderでもあまり不便を感じなかったのはDA（デスクアクセサリ）のおかげでした。これ、iPadで復活しませんかね？ ステイタスバーの左上にAppleマークがありPA（パッドアクセサリ）を選択できる。PAはiPhoneアプリそのものを使うのです。ウィンドウサイズ的にもピッタリですし、iPhoneアプリをiPadユーザに購入させる大きな理由付けとなります。ぜひ採用してください＞CEO殿（笑）
・iPhone Boot Campの効果は抜群！
iPhoneはモバイルデバイスと言う利用形態が前提で、画面サイズが狭いという制限がありました。よって、その条件から外れるカテゴリーのアプリを開発しているデベロッパーは参入をためらっていたでしょう。そのタガが外れましたので、さらにバラエティに富んだアプリが登場するはずです。iPadで使うフレームワークはiPhone版の「ちょい拡張」なので、iPhoneアプリ開発経験者の参入は容易です。iWorkレベルのアプリが￥1,000で登場し、ステージレベルはワンランク上がりましたが、iPhone Boot Campで鍛えられた何万人のデベロッパーの次なるストステージへ進むための激しい競争が起こるはずです（アプリの質は上がる）。 そしてiPad Boot Campでさらに鍛え、さらに上のステージ（Mac）へと誘導するのがApple社の狙いかもしれません。
・とにかく待ちましょう…。
販売開始までまだ2ヶ月あります。その間に何か追加発表があるかもしれません（どうも臭う）。「あれがないからダメ」とネガティブな話をするより「あれもこれも出来る」とポジティブな発想に思いを巡らせていた方が健全です。 何か理由を付けて論じないと仕事にならないアナリストでもないかぎり、新製品に期待しワクワクしながら待っていた方が人生楽しいですよね。
iPhoneとAndroid 小池邦人
（2010.01.26）
米国Googleが「Nexus One」の直売を開始したり、ドコモが「Xperia」を発表したりと、マスコミの話題先行で大いに盛り上がっています。そんな中、Mac（インテル版）にAndroid SDKをインストールし、エミュレータでアプリを動かすことを試してみました。その時の経験と感想を、iPhoneの個人（もしくは小規模）デベロッパーの視点から述べてみたいと思います。
ここではアプリの実機へのインストールやAndroid Market（iPhoneで言うところのApp Store）への登録は行っていません。また、iPhone SDKの全仕様の詳細を把握したわけでもありませんので、その分は差し引いて読んでください。詳細な技術解説はしませんが、これからAndroidプラットフォームを主用ターゲットにしようと考えているデベロッパーの方々の参考になればと思います。
・オープンソースプロジェクト
Androidはオープンソースの携帯端末プラットフォームです。これはOSやそれに付随するフレームワークがオープンソースプロジェクトとして開発され、適切なライセンスの元に配布されることを意味します。 携帯メーカはプロジェクトの成果物を無償で利用し自社製品に搭載できるだけでなく、製品により適合させるための調整や改良を行うことが可能です。そう言う意味では、Apple社も、オープンソースプロジェクトによる多くの成果物（WebKitなど）を効果的に自社製品（Mac OS XやiPhone OSなど）に活用している代表的なメーカです。
世間には「オープン、オープン」と呪文を唱えることで素晴らしい製品ができ上がると錯覚している人がいるようですが（笑）その仕組みと成果物を活用した個々の「製品のデキ」とはまったく関係ありません。また消費者の中には、このオープンの意味を、携帯キャリアの選択が自由になると取り違えている人もいるようです（笑）。加えてこうした状況の中では、意図的に「呪文」をミスリーディングさせようという意思も働いたりしますので、言葉の鵜呑みは禁物です。
携帯メーカーにすれば、プロジェクトの成果物がオープンソースとして提供されることで最新機能を搭載した携帯端末を開発しやすくなります（なにせ無償です）。それに伴うユーザ側のメリットは、Windows搭載パソコンのように、様々なメーカからAndroidを搭載した携帯端末が登場することで自分の好みに合った商品を選択できるようになることです。 例えば外付けキーボードある機種とそうでない機種から好きな方を選ぶといった感じです。 ただし、現状はキャリアとの契約に縛られてしまうため、パソコンほど自由にメーカや機種を選択できないかもしれません。
・歴史は繰り返す
片やiPhoneは製品全体（キャリアを除く）をApple一社でコントロールしています。よってiPhoneとAndroidの関係を、パソコンが普及し始めた時代のMacとWindowsに例える人もいます。しかし、筆者はちょっと違う気がしています。Windows OSはオープンソースではありませんし、Microsoftはそれを企業へライセンスすることでちゃんと収益を上げていました。AndroidをWindowsに例えるならば、携帯端末の世界には「Windows Mobaile」プラットフォームと言う前例があります。
どちらかと言うと、Android登場はパソコンの世界にLinux OSが登場した状況に近いような気がします（ちなみにAndroidのCore OSもLinuxです）。ただしLinux登場時とは異なる点も多々あります。例えばLinuxとMacが対局にあると想定すると、その真ん中辺りにWindowsがいるわけです（笑）。まあ、ここからはあくまでも個人的な見解なのですが、AndroidはLinuxほど極端に寄ってはおらず、ちょうどLinuxとWindowsの真ん中あたりの位置取りだと考えると分かりやすいかもしれません。
「iPhoneはAppleに縛られているから」と言う人をよく見かけますが、AndroidもそれなりにGoogleに縛られていると思います。つまり、Googleとて慈善事業でオープンソースプロジェクトを推進しているわけではありません。より多くの携帯端末から自社クラウドサービスを利用してもらい（主に広告から）利益を増やそうという狙いがあるはずです。よってオープンソースと言えども、それなりの方向を持ってコントロールされているでしょうし、成果物のアプリやフレームワークにしても、ある程度Googleの意図が反映された形となるはずです。
携帯端末で自社サービスを利用してもらうのなら、それがiPhoneでもかまわない訳ですが、それだけでは不十分であり、端末普及にさらなる推進力が欲しいようです。ところで、もしGoogleのライバルとなる「何か別のサービス」が世に広まり、Android自体がその普及に拍車をかけてしまったら？ この時、GoogleはAndroidにどう対峙するのでしょうか？ Appleは製品で儲け、MicrosoftはOSライセンスで儲け、Googleはクラウドサービスで儲ける、確かに現状はそうですが、これからはどうなるか分かりません。それぞれの思惑が交錯して面白い状況になったことだけは間違いないようです。
・アプリの開発環境
将来どうなるかと言うことはさておき、さっそくAndroidアプリの開発環境を構築してみましょう。嬉しいことに、AndroidアプリはMac上でも開発可能です。ちなみに、iPhoneの場合とは異なり、Androidは、Mac、Windows、Linuxのどの環境でもアプリを開発することができます。まずは、Googleサイトから「Android SDK」をダウンロードしてMacへインストールします。筆者の場合、そのSDKフォルダをiPhoneとMac SDKが保存されているDeveloperフォルダに入れて利用しました（仲良く共存）。
次に統合開発環境 IDE（Integrated Development Environment）の「Eclipse」をダウンロードしてインストールします。こちらはIBM（多分）が推進するオープンソースプロジェクトの成果物で、iPhoneで言う所の「Xcode」に相当します。Carbon版とCocoa版、そして32bit版と64Bit版が存在します。最初にEclipsを起動したら、Android用プラグインのADT（Android Development Tools)を追加インストールします。その後、Windows環境であればJDK（Java Development Kit）6.0のインストールも必要なのですが、Snow Leopard（Mac OS X 10.6）には既にインストール済みですので、その必要はありません。
MacはAndroidアプリの開発環境として相性が良いようです。珍しいことに、Androidの解説本の中にもMac環境を前提に（図版がMac画面なのですぐ分かる）書かれているものが幾つかあります。こうした解説本に従えば、インストールはそれほど難しくなく時間もかかりません。ただし、iPhoneのようにSDKをダウンロードしてインストールすればそれでOKといった簡便さはありません。それなりに行ったり来たりは発生します。 また、解説本によっては使用しているEclipsのバージョンが異なり、図版や手順が若干違う場合もあるので注意が必要です。
Androidの開発環境では、「プラットフォーム OS」「SDK」「IDE」「JDK」といった幾つかの構成要素（モジュール）が別々の管理者から提供されています。開発環境に関わる構成要素の出所が多くなると、トラブルが発生した時に、その切り分けが難しくなるのが常です。つまり「誰が悪いのか？」と言う犯人探しの手間です。こうした環境では、各モジュールに対してバージョンセンシティブに成らざるおえません。iPhoneの場合には、開発環境に問題があればAppleに文句を言えば済むわけですが、Androidでは「どこに怒りの矛先を向けて良いのか？」という混乱がついて回りそうです。
こうした混沌とした状況（それほどでもないですが）を楽しむ「若い衆」も多いと思いますが、いいかげん年を取ると面倒な事が嫌になります（笑）。 以下個人的な話で恐縮ですが「奥底にあるソースを自分で直す」と言うパワーは既に無く、いい加減に開発環境でのトラブルは勘弁（今まで苦労しすぎ）！余生は静かにアプリ開発のためのプログラミングだけに集中させて！と思う今日この頃です。余談ですが、Androidエミュレータを起動すると「NSQuikDrawViewはDEPRECATEDだからCoreGraphics APIを使ってね」と警告が表示されます（笑）。う〜ん、これを見るだけでも、この先ちょっと心配になりますね…。
・開発言語はJava
Androidアプリの開発言語は「Java」です。Javaのソースコードは中間言語に翻訳され、それをDalvik仮想マシンが解釈して実行します。データベースのSQLiteや3D描画フレームワークのOpenGLも、Javaソースコード内から利用できます。また、AndroidではWebKitも使えますので、一部のフレームワークはiPhoneと良く似ています。ただし、処理スピードに関しては、ネイティブコードにコンパイルされるObjectiv-Cには及ばないかもしれません。また、状況によっては一般的に言われるガーベージコレクションによる処理の遅延という問題も発生するかもしれません（最近のJavaシステムではかなり改善されているそうですが…）。
ところで、速度が必要な処理ではネイティブコードを使いたいと考えるデベロッパーも多いでしょう。そのために、GoogleからAndroid NDK（Native Development Kit）がリリースされています。これにより、昔からあるJNI（Java Native Interface）を用いた仕組みが追加されます。CやＣ++ソースコードからネイティブコードライブラリを作成し、それをAndroidアプリパッケージに埋め込みます。このネイティブコードライブラにゲームなどで速度が要求されるモジュールを隔離するのが有効な手段です。しかし、開発のメインルーティンから工程が分離されますので、日常的な使い勝手が良いかどうかは疑問です（ライブラリ内からJava APIが呼び出せるかも未確認）。
iPhoneでは「開発にObjective-Cを使うのがちょっと…」と言う話を良く聞きます。確かに、ユーザインターフェース制御にはCocoaの習得とObjective-C表記が必須ですが、それ以外のコードについてはCやC++でも記述可能です。C++はソースファイルの拡張子を「.mm」とするだけです。ゲーム等であれば、Objective-Cのソースコード使用量を1%未満に留めることも可能でしょう。筆者もMac版のCarbon（Cocoaではない）アプリを移植してみましたが、Objective-Cのコード量は全体の1/3程度となりました。速度を要求される個所はそのままＣやC++で記述すれば追加処理は必要なく、そのルーチン内ではObjective-C表記も使え、Cocoaメソッドを呼ぶことも可能です。
・開発工程を試す
Androidアプリの開発工程は、iPhoneのそれとそっくりです。アプリの挙動を定義したXMLファイル「AndroidManifest.xml」は、iPhoneの「info.plist」と似ています。レイアウトに配置するウィジット（iPhoneのコントロール）や文字列などのオブジェクトもXMLファイルに定義しておき、アプリから読み込んでインスタンス化します。これは、iPhoneでのnibファイルの仕組みに相当します。当然レイアウトやウィジットはAPIを使いダイレクトにソースファイルへ記載することも可能です（これも同じ）。また、各国言語に対するローカライズ作業は、こうしたXMLファイルを複数作成してアプリパッケージに埋め込む手法を取ります（これまた同じ）。
ウィジットのレイアウトには、携帯端末の画面サイズの多様性を考慮して相対配置を使うことが推奨されています（iPhoneは絶対位置）。この仕様が関係しているのかどうかは分かりませんが、Androidには「Interface Builder」に相当するビジュアル・レイアウトツールがディフォルトで付属していません。つまり、レイアウト用XMLファイルを効率的に編集するツールが無いのです。確かにEclipsのプラグインツールには簡易エディタがありますが、機能が貧弱です。解説本に別のツールアプリも紹介されていましたが、一見したところ、Mac開発者が昔々に使っていたResEditよりも底機能な感じです。
ですから、ウィジット操作で発生するイベントをソースコードのアクションに結びつける作業は手作業（テキスト編集）となります。Interface Builderであれば、ビューに配置したオブジェクトは、インスタンス変数ならIBOutletをアクションならIBActionをターゲットとして、ラインを引っ張りながらビジュアルにリンクできます。Androidには、そうした仕組みが無いようです。XMLに文字列で固有のID（iPhoneのビューのTagに相当）を定義しておき、それをソースコード上で表記することでリンクを完成させます（Carbonアプリのコントロールリソースのリンクと同じ）。
レイアウト用XMLを編集し指定オブジェクトをソースコードと結び付ける作業は、実際にソースコードを書いてプログラミングする作業と同等の手間がかかります。現在のプログラミングではこの傾向が顕著なので、Interface Builderを操作していると「俺は本当にプログラマーか？」と悩んだりします（笑）。この作業に対処する優秀なツールの存在は間違いなくアプリ開発の効率を上げます。Androidにもオープンソースの強みを生かした優秀なツールが登場することを期待したいと思います。ちなみに筆者が知らないだけで、既に優秀なツールがあるかもしれません。その場合はご容赦ください。
・フレームワーク
プログラミングでは、OSの仕組み以上にフレームワークのデザインやコンセプト（完成度）が重要です。Javaフレームワークは、元々ウェブサイト上でアプレットを起動させるために開発されましたが、現在では多用な業務現場で利用されています。Android SDKは、これに独自のフレームワークを追加することで構成されています。片やCocoaフレームワークは、NEXTSTEP（懐かしい）に搭載されていたものがMac OS Xへ移植、拡張された生粋のパソコンアプリ構築用フレームワークです。iPhone OSへの実装はそのサブッセットなのですが、実はiPhoneに搭載されている方が先進的な部分もあります。調べてみると、両フレームワークを使って出来る事は似たようなものであることが理解できます（ターゲットカテゴリーが同じなので）。
しかし、両者には微妙に異なる雰囲気が漂っています。Androidには、携帯を拡張してインターネットサービスを使いやすくしようというコンセプトが見えます。iPhoneでは、パソコンをそのまま携帯に収めてしまおうと言う野望を感じます（笑）。フレームワークは単純に数多くのクラストとメソッドが存在していれば良いというものでもありません。ある目的を達成するには、それぞれのクラスが密接に協調して働く必要があります。協調できるということは、すべてのクラスがある目的を想定して統一されたデザインで設計されていると言うことです。プログラミングにおいては、デベロッパーの意図を清く正しく実装できるフレームワークが重要です。その能力の差が、それを用いて開発されたアプリの「質」の差となって現れるわけです。
ところで、フレームワークとは関係ないのですが、Androidでひとつだけ気になる点があります。それは、ユーザインターフェースに関する「ガイドライン」がどこにも提示されていないことです。これだと、アプリのユーザインターフェース実装をデベロッパー各人に任せることになります。携帯端末のアプリをマニュアルを読みながら使うことなど稀なので、ひとつのアプリの操作経験が別アプリに生かせないのはユーザにとって苦痛です。オープンソースの性格上UIの実装方法はデベロッパーの自由という方針も理解できますが、いくらかの規則と束縛は、もう一段階高いレベルのユーザ経験を提供するためには必要ではないでしょうか？
・アプリの実行環境
ソースコードやリソースの編集が終了したら、コンパイル＋リンクを実行しAndroid携帯端末のエミュレータを起動して動作確認を行います（これはiPhoneと同じ）。この作業でiPhoneと大きく異なる点は、色々と特性（画面の大きさ等）の異なるエミュレータを複数タイプ用意できることです。この機能により、自分のターゲットとする携帯端末を模したエミュレータを選択して動作確認が行えます。もしあらゆる端末が開発ターゲットであるとすれば、複数のエミュレータで順次確認することになります。
Androidでは単独でバックグランドに常駐するアプリ（サービスと呼ぶ）作ることができます。また、各アプリの画面表示（アクティビティと呼ぶ）は、切り替える毎にスタックに積まれてメモリに常駐します。iPhoneで言えば、UINavigationControllerがUIViewControllerを切り替える処理と似ています。違う点は、この処理は別アプリのアクティビティにも適用されることです。ですから一度ホームへ戻らなくても即座に前のアプリへ戻ることが可能です。メモリ使用状況がタイトになれば、一定のルールに従い優先順位の低いアクティビティから順次解放されます。同時に起動しているアプリが増えてくるとかなりヤバそうな仕様ですが（笑）、空きメモリが豊富にある状況なら快適なユーザ体験を提供できます。
iPhoneでは、Appleが供給している特定アプリ（MailとかSafari）以外のメモリ常駐は許されていません。OSの機能としてバックグランドタスクやマルチタスクは可能なのですが、敢えてそれをデベロッパーに解放していません（マルチスレッドはOK）。その機能の実装はユーザ体験を阻害するデメリットの方が大きいと判断し「それは今は使わない」という決断を下しています。デバイスのメモリ容量やバッテリーの問題が解決すれば、それなりの手法を用意してから、バックグランドやマルチタスクの解放が始まるでしょう。iPhone OS 4.0に期待しましょう！
セキュリティを強固にするために、AndroidもiPhoneと同じく、各アプリは隔離された「サンドボックス」に保存されます。そこから別アプリへのコンテンツへアクセスすることは禁止されています。問題なのは、アプリの保存可能スペースが現状では200MByte前後しかないことです（OSの制限？ Appleのフラッシュメモリ買占めの影響？）。これだと、コンテンツやリソースを大量に含んだアプリのインストールは苦しくなります。多分、大きな辞書とか大作ゲームは不可能でしょう。同じくファイルへ大量データを保存するアプリ（画像データベースなど）も制限されます。iPhoneは搭載されたフラッシュメモリの最大容量（例えば32G）までアプリを保存することが可能です。
・アプリの配布方法
物事にはすべてにメリットとデメリット（裏と表）が存在します。兎角人は片方にだけ目を向けがちですが、両方見極めての判断が必要です。iPhoneアプリを実機にインストールしたりApp Storeで配布したりするには「iPhone Developer Program」との年間契約（費用 \10,800）が必要です。Androidの開発ではこうした費用は発生しません。確かに費用がかかるのはデメリットですが、この費用、何かトラブルに遭遇した時に「Appleに文句を言う権利」を手に入れたと思えば納得できます。契約に10万もかかるようなら考え直しますが、配布手続きを含めたポータルサイトの整備、新着情報の配布、メンテナンス、個別Ｑ&Aなどが付いていると思えば、この年間費用は安いと思います。
Androidで完成したアプリ（商品）を置く店舗は「Android Market」です。アプリをAndroid Marketへ登録するには、App Storeとは異なり特別な承認審査は必要ありません（若干はあるという噂あり）。加えて、Androidアプリはそこに置かなくても自由に配布することができます。こうした点をメリットと見る向きは多く、実際に様々なビジネス展開が可能になると思われます。しかし「商品の品質を維持する」と言う意味では 承認が無いことがデメリットへと変わるケースもあります。実際に、ユーザのセキュリティに被害をおよぼすアプリが登録された事件がAndroid Marketで起こったようです。
それにしても、Android Marketの国内外での評判が芳しくありません。アプリを置いたり買ったりしている筆者からすれば、現状のApp Storeでも数多くの不満があります。商品レビュー、図版やデモ、カテゴリー分け、検索と閲覧などなど…改善して欲しい個所が山ほど有ります。しかし、それ以下だと言うAndroid Marketの評判を聞くに及んで、何故すぐに改善されないのか首をひねります。クラウドサービスが本業のGoogleらしくないですね。AndroidアプリはAndroid Marketに置かなくても配布できるというメリットを誇示したいのでしょうか？ しかし、ユーザとデベロッパー両方の視点として、流通アプリをまとめる魅力的なフラッグシップ店は欠かせないような気がします。
・多様性はもろ刃の剣
それではアプリをAndroid Marketで販売しようとした時の懸念事項は何でしょうか？ Android携帯端末が多数登場すれば、Android用アプリの供給が劇的に増え、将来的にはApp Storeの商品数を抜くだろうと言う予想もあります。しかし「理想論」としてはそうであっても、そんなに簡単に物事が運ばないのが現実です。パソコンの世界でも、もし当時のアナリストの予想通りに事が運んでいたら、はるか昔にLinuxはコンシューマーデスクトップ市場でWindowsを駆逐していたはずです。
パソコンの場合、MicrosoftはIntelと共に各メーカのプラットフォームを強力にコントロールしていました。Androidにおいては、Googleによるそうしたコントロールは希薄なように見えます。すると端末メーカもライバルとの競争があるので、他社よりアピールできる機能を積極的に自社製品へ搭載しようとします。その結果、機種間の互換性に亀裂が入り、アプリ開発者への重荷が表面化することになります。ちょうど、Linuxのデストリビューションが多様化し開発者やユーザが分散してしまったのと同じ状況です。
デベロッパーからすると、開発対象デバイスの種類は少ない方が助かります（理想は1機種）。そう言う意味では、 iPhoneは かなり理想的なのですが、それでも3Gと3GSの間には多くの相違点があります。
・CPUとGPUの処理速度
・メモリ容量（128Mと256Ｍ)
・外部記憶容量（8Gから32G）
・カメラの能力（画素数）
・ビデオ撮影の有無
・コンパスの有無
ターゲットにiPod touchを含めるともう少し要因が増えます（カメラの有無、スピーカーの有無、3G回線やGPSの有無など）。Android携帯では画面（スクリーン）サイズが違うという要因も追加されます。それとは別に、個別デバイスのOSバージョンの違い（iPhoneなら2.0.0〜3.1.3）も考慮すべきです。ちなみにカメラやGPSの有無であれば、フレームワークに用意されている判定用APIを使いソースコードで切り分けられるでしょう。
ところがメモリ容量の違いやCPUとGPUの速度差はやっかいです。ターゲットデバイスをiPhone 3GSに固定して開発した（3Gの実機での確認を省いた）デベロッパーは、App Storeのレビューに3Gユーザからの苦情が殺到したのではないでしょうか？ そのほとんどはメモリ不足で起こるクラッシュや、CPUやGPUの違いが引き起こす処理速度低下に対するクレームです。また、メモリがタイトになった時だけOSに潜むバグが目覚めて悪影響を被る場合もあります。機種数の少ないiPhoneであっても、実機対応を怠ることで後から深刻な問題に遭遇することになります。
Android携帯は画面サイズは様々ですし、メーカによっては特別な機能が追加されている可能性もあります。 実機テストをせずにエミュレータだけで動作確認したアプリを配布するには相当な勇気がいります（ギャンブル）。開発時にはなるべく多くの実機でテストすることが必須ですが、とは言っても全実機を入手することは不可能ですので、エミュレータに頼るしか手はありません。そうなると、アプリを全機種対象に配布しようとするデベロッパーには大きな不安とリスクが付きまとうことになります（まあ、開き直るという手もありますが…）。
・Androidで食っていけるか？
Androidは新たに登場したプラットホームとして技術的にもビジネス的にも大変興味深い側面を持っています。MicrosoftのWindows Mobaileが即座に反撃のノロシを上げないかぎりは（笑）当分の間は多くの携帯メーカの有力な選択肢になるでしょう。しかし、いちデベロッパーの立場として、Android Marketでアプリを販売して食っていけるかと尋ねられれば、正直その自信はまったくありません。ちなみに、iPhoneならいける気もしますし、実際に食っている人もいます。またiPhoneの場合には、MacやiPadアプリ開発へと習得技術の継承が可能な利点もあります。
先ほども延べましたが、今後登場するだろう数多くのAndroid携帯を物理的にすべてカバーする時間も資金もはありません。かと言って、エミュレータで動作確認しただけの作品を売る度胸もないのです。Android携帯端末の市場が大きくなり、特定の機種に絞ったカスタムメイドのアプリの需要が上がれば、それを受注して仕事にできる可能性は高いと思います。ただし、Android Marketが存在していることが仇となり「報酬は売上の一部を」といった仕事が多数を占めてくると（最近はiPhoneでも多い）、かなり辛いものがあります。その時には、多分その仕事は受けないでしょう。
さて、AndroidとiPhoneの開発環境を比較しながらデベロッパーとしての個人的な感想を色々と述べてきましたが、実際に使ってどう感じるかは、使う人の経験値により大きく異なります。当然、Java開発環境に慣れ親しんだ人にはAndroidアプリ開発の方が楽でしょうし、MacでCocoaアプリを開発していた人は圧倒的にiPhone SDKを好むでしょう。将来の「生業」の有力候補と見なすかどうかは別として、技術的に興味ある方は、ぜひ一度自分で試して確認してみてください。より多くのことを勉強しておけば、必ずどこかでそれに助けられるものです。
WWDC 2009に思う 小池邦人
（2009/07/30）
Philip Schiller副社長（このために少し痩せたのか？）のちょっと緊張気味の司会と、担当重役のそつのないナビゲートでキーノートも順調に進みました。何とか笑いを取ろうとした場面がことごとく失敗に終わったのは、まあ愛嬌です（笑）。 WWDCのセッション内容はNDA（秘密保持契約）扱いで詳細開示は不可ですが、キーノートはNDA適用外なので、その概要については、既に関連サイトに多数掲載されています。今回も詳細については、そちらにお任せしたいと思います。噂通りにiPhone 3GSが登場しましたし、低価格MacBook Proの発売、Snow Leopardの最終日程と驚きの＄29バージョンアップの発表など、ネタ的には十分満足できるキーノートだったと感じました（不満はCEOの不在のみ？）。ただし、iPhone OS 3.0やSnow Leopardの機能は既に発表済みの内容だったわけで、ソフト屋としては「次の一手」が何も示されなかった点に、若干のモヤモヤを感じたことも事実です。
初日はiPhoneのみを所有している参加者が多かったのですが、2日目からは、会場の多くの人がMacBook Pro（17インチ多し）を持ち歩いていました。 キーノートでお買い得13インチMacBook Proが発表されたおかげで、それを現地調達して使う人もいたようです（会場のゴミ箱に空き箱が捨てられていた）。ほとんどの人は、セッション内容のメモ取りなどでMacBookを活用していますが、後ろから画面を覗くと、自作アプリを一生懸命デバッグしている人も結構いて「ちゃんとセッション聞けよ！」とか、声をかけたくなります（笑）。また「変なデスクトップだな？」と見ると、そのまんまのWindows XPが走っていたりして（昔からLinuxは結構いた）吹き出すことも多々ありました。そうそう、今はやりのネットブックをハックしてMac OS Xをインストール（大胆）している人にも結構遭遇したことも追加しておきましょう。
昨年のWWDCでは、Apple社のWebサイト（参加者のみ入れる）へと最新スケジュールがアップされ、それをiPhoneやiPod touch（もしくはMac）で参照していたのですが、今回は、iPhone&iPod touch専用の「WWDC09」アプリが用意されていました。それをダウンロードし自分のiPhoneにインストールすることで、参加者は最新のイベントやセッションスケジュールを参照できるわけです。アプリへは逐次最新情報が転送され、未読情報は画面の数値バッチで忠告してくれます。また、別途デバイスへインストールする「Provisioning Profiles」（認証ファイル）も同時配布されたのですが、これがオールマイティ版（デバイス識別子のUIDIを判断しない）と分かり、デベロッパーの中から「この仕組みを利用できるサービス形態が欲しいぞ！」と言う「大きな声」が上がっていたことも付け加えておきましょう（後に追記有り）。
昨年のWWDCの感想で「美しきスツールのために、次のWWDCでは4本目の足（ビジネス分野への進出）についての戦略を公開して欲しい！」と書いたのですが、残念ながらそちら方面については、Snow LeopardのExchange対応が強調された程度で、これといった大きな発表はありませんでした。当然「Mac OS Xのライセンシング」の話などはこれっぽっちも出ていません。また「パソコンを生産をしていないSunやIBMとMac OS Xがらみで提携したら？」とも書きましたが、そのSunも既にOracleに買収されてしまったわけでして、状況の変化の速さに驚かされる今日この頃です。まあ、Apple社のことですから「抜き足、差し足、忍び足」で、知らない間に自社製品をビジネス分野へジワジワ浸透させていくための準備をしているかもしれません…。iPhoneがらみに関しても、その傾向が見え始めている気もしています。
今回開催された多くのセッションは「iPhone OS 3.0」関連が中心です。また、全体の60%が初参加だと言うこともあり、「入り口」としての開発環境（Xcode Tools）関連のセッションも活発だったようです。しかし、十数年もWWDCへ通い続けているデベロッパーから見ると、それ以外は「成熟」の極みといった雰囲気が漂っていました。今まで何度も主役を演じてきたQuickTimeもQuickTime Xがらみのセッションがひとつだけ、今回はCocoaにしても目新しいトピックスはほとんど無い状況でした（当然Carbonセッションなどは皆無）。Snow Leopardで導入予定の、64Bitカーネル、OpenCL、Grand Central Dispatchなども、企業や大学のサイエンス系研究室では大いに力を発揮しそうな技術なのですが、コンシューマに直接結びつくトピックスではないことから、盛り上がり方も今ひとつ限定的なようです。
しかし、こうした地味なテクノロジーが、OS自身や付属アプリの開発に大いに生かされている可能性は無視できません。つまり、Apple社の自社開発におけるソフトの処理速度の改善や、より強固なシステム構築に大きく貢献しているわけです。そのことは、間接的ですがコンシューマにとっても大きなメリットとなるはずですから、Snow Leopardの登場が本当に楽しみになってきました。 さらに気になった点は、キーノートでも見え隠れしていた、Mac OS XとiPhone OSの「統合」の流れです。現在、両OSでは「Core OS」と呼ばれているシステムモジュールが共通で存在しており、その割合は全体の80%を占めます。後は、両OSのユーザインターフェース・フレームワークであるAppKitとUIKitの差異を縮めれば、2つのOSは割と簡単に統合の道を歩むことになります。つまりCPU依存でコンパイルし直せば、MacでiPhoneのアプリが起動し、iPhoneでMacのアプリが起動することになります。
まあ、統合自体は少し未来の話かもしれませんが、「一歩先を行く」iPhoneアプリの開発を目指し、その先行メリットを得たい開発者は、iPhone OSと同時にMac OS Xの最新テクノロジーも勉強しておくことをお勧め致します。iPhone OS 2.0から3.0では「Core Data」「Spotlight」「OpenGL 2.0」「Pastebord」「VoiceOver（Accessibility）」などが、Mac OS X側から降りてきました。次の機会には「QTKit」「ImageKit」「CoreImage」「QuartzComposer」「Binding」「OpenCL」などが降りてくる可能性があります。逆に、Mac OS Xではトラックパッドによる「Multi Touch」機能が充実してきており、将来的にはiPhone OS特有の機能「MapKit」「GameKit」「StoreKit」「LibraryAccess」などが実装されるかもしれません。MacやiPhone（将来登場するかもしれない新デバイスも）を区別せず、総合的にApple社のテクノロジーを習得しておくことは、今後さらに重要性を増すことになるかもしれません。
今回のWWDCで一番残念だった点は「App Store」の改善について何も言及されなかったことです。iPhone 3.0でアプリ内からコンテンツを購入できる機能は追加されましたが、 App Store自体の機能拡張については何も新しい発表がありませんでした。現在、5万以上の商品が店頭に並べられているApp Storeですが、どうひいき目に見ても、自分の欲しているアプリを簡単に見つけて購入できるという「ショップ」の心地良さはありません。商品数が多くなっていくペースに店舗のリソースの整備が追いついていないわけです。やはり「欲しい商品を見つけてくれる優秀な店員」が絶対に必要です。まあ、AIを駆使した検索エージェントを搭載しろとまでは言いませんが、もう少し買う人に優しい店舗に改築して欲しいところです。これはiPhoneアプリ開発者とユーザのために早急に改善すべき問題だと思うのですが、Apple社はいったいどうするつもりなのでしょうか？
もうひとつの不満点は「iPhone Developer Program」契約形態の拡充が示されなかったことです。現在、このプログラムには「スタンダードプログラム」と「エンタープライズプログラム」の2種類が存在しています。このうち「エンタープライズプログラム」は社員数500人以上の大企業（加入している企業を聞いたことがないが…）が対象なので、ほとんどのiPhoneアプリ開発者は「スタンダードプログラム」へ加入しているはずです。しかしこの契約では、開発したiPhoneアプリはApp Store経由でしか販売できません。それ以外の手段としては、デバイス100台限定でAdHocによる配布が利用できます。「あれ、AdHocは200人までじゃないの？」と思われる方も多いでしょうが、現状のAdHocでは配布用リストには200人まで登録可能ですが、対象デバイスの方は何故だか100台までしか登録できないのです（Portalサイトのバグ？）。そんな訳で、AdHoc対象者は100人までに限定されてしまいます。
システムインテグレートを生業としているMac関連企業が、iPod touchに独自の自社アプリをインストールし、Mac関連ソフトや周辺機器と一緒に販売しようと立案したとします。 例えばMacで組んだPOSシステムの端末にiPod touchを使い、そこに専用アプリをインストールするようなケースを考えましょう。さて、このiPhoneアプリをどうやってデバイスにインストールするのか？「App Storeに無料アプリとして置き、ユーザにダウンロードしてもらえば良い…」という考えもあるでしょう。しかし、何らかの理由 で（配布タイミング、セキュリティ、環境設定、ライバル対策など）、それが不可能だと判明したら…そう、AdHocを使うしか手がないのです。つまり、商品が100セット売れる度に、さらに1万円を支払って「iPhone Developer Program」を追加契約するといった冗談のような話が現実となります。
Apple社が「それはレアケース」と考えているなら大間違いです。例えば一番の例は、今回参加者に配布された「WWDC09」アプリです。これは、不特定多数にApp Store経由以外でアプリを配布するケースです。 こうした状況は、iPhoneが想定する「ビジネスシーン」でも頻繁に起こるでしょう。 これを無料としてApp Storeに置かなかった理由は「一般ユーザによるダウンロードを避けたい」「プロファイル設定でWWDCが終われば起動不可にしたい」などが考えられます。つまり、自社でアプリをきめ細かくコントロールするのには、App Storeによる配布形態は大変不向きなのです。より多くの用途にiPhoneを活用したいと考えた時、現在の「iPhone Developer Program」の契約には大きな不備があります。会場でも多くの参加者の方に「何か良い方法はありませんか？」と尋ねられたのですが、現状ではうまい解決方法はありません。Apple社には、 早急に何とかしてもらいたいものです。
どうやらiPhoneの改訂ペースは1年毎で確定したようなので、次回もWWDC開催時期と重なる可能性があります。また、Macがらみの次なる展開（Snow Leopard後）にも注目が集まるでしょう。加えて、噂の「新デバイス」が登場しており、そのOSやSDKの話題で、いつも以上に盛り上がっていることを期待したいと思います。
NDAとはいったい何ぞや？ 小池邦人
（2008.07.04）
ところで、英語表記のNDAですが、日本人のほとんどはその内容を読んでいないのではないでしょうか？ つまり、長々と色々な事が書かれているようですが、誰もその内容を正確に知らないわけです。パッケージを開けたら自動的に締結される「ソフトウェア使用許諾契約」みたいなもんですね（笑）。私は法律の事は詳しくありませんが、素人考えとして、秘密を開示する側が不利にならないよう、ありとあらゆる条項が詰め込まれているのでしょう。まあ、細かい点は理解していないとしても、NDAの目的が「知り得た技術内容を公の場（雑誌とかウェブサイトとか不特定多数の集会など）で公開してはいけない」ことぐらいは理解できています。その点に関してだけは常識と言う事で、良い子のデベロッパーはそれを守ろうと一生懸命努力するわけです。
ここで、iPhone SDK β版の例を考えてみましょう。この開発用ソフトは、ADCオンライン会員（無料）以上であれば誰でもダウンロードできます。当然、ADC会員になる時やSDKのダウンロード時にNDAが結ばれます。ただし、メンバー認可の過程に何らかの選別や認証は存在しません（年齢制限だけ）。メールアドレスや住所を登録すれば誰でもなれるので、うちの奥さんでもOKです。当然、iPhone SDK β版に対しても「使用許諾契約」は必要でしょう。しかし、ほとんど誰でもダウンロードできるソフトの使用許諾にNDA（技術情報の開示の禁止）を含める必要があるのか？という疑問が残ります。ADC会員以外に秘密を漏らさないため？ それは変ですよね。だって、ADC会員には誰でもなれるわけですから、秘密を欲しい人は参加してダウンロードするだけです。
それでは、他に何か理由があるのでしょうか？予想よりデキが悪いことがバレて騒がれたくない？ それは情報開示側の問題でしょうね（笑）。それとも、マスコミに現状を湾曲して伝えられるのが嫌だから？ そんな事は秘密事項でなくても良くあることです。逆に真実を隠した方が、不必要な憶測で事実を曲げられてしまう場合が多々あります。秘密にすることで、まだダウンロードしていない人の興味をあおり、ダウンロード数を伸ばすため？ う〜ん、これは使えそうな作戦かもしれません（笑）。バレルことで秘密開示側が明らかな不利益を被る場合「秘密を得た特定の人」に対しNDAを結ぶという事は理解できるのですが、不特定多数の人が結ばなければいけないNDAの意味とはいったい何なのでしょうか？
WWDCの場合もそうです。WWDCはADC会員なら誰でも参加できます。やはり認証や選別はありません（年齢制限のみ）。ところで、WWDCへ参加すれば、もれなくApple社の新製品情報を入手できるでしょうか？ 「 Snow Leopard」の販売開始日を知ることが可能でしょうか？ iPhoneの出荷台数の各店舗への配分が分かり、販売日に入手するのに有利に働くでしょうか？ そんな事はありません。今まで参加してきた私の個人的見解ですが 、外に漏れると「こりゃマズイな」と思うような情報開示は皆無なのです。事実、何年か前までのWWDCは、セッション内容に対してNDAはかかっていませんでした。では、何のためのNDAなのか？ ライバルに最新テクノロジーの動向を知られたくないため？ 冗談でしょ！ WWDCにはマイクロソフト社員も数多く参加しており、セッション終了時に、Apple技術者に対しバリバリ質問を投げかけております（笑）。
デベロッパー側はDNAで厳しく縛られるのですが、その傍らでシーディング（テストパイロット）ソフトの情報はすぐにウェブサイトに流れますし、「Snow Leopard」のスクリーンショット等も堂々とアップされ、その詳細な内容を詳しく掲載しているサイトまであります。こういうサイトに対しApple社は、速やかに法的処置を取ると思いきや、多くは野放し状態です。また、 Apple社のディスカッションボードで、iPhone SDKの技術的な内容が頻繁に話されていたりもします。こういう状況を見るにつけて「興味をアオルため、いくらか漏れることを計算してNDA結ばせているのでは？」と勘ぐりたくなるのが正直なところです。
そしてWWDC終了後、MOSAで「WWDC参加者情報交換会」（対象は参加者のみ）を開催しようと企画した時です。毎年「WWDC報告会」と称して似たようなイベントを開催していたのですが、その企画の一部を変更したわけです。すると、すかさずアップルからクレームが入りました。 アップル曰く「WWDC期間中会場内であれば参加者同士が情報を交換することは問題ございませんが、WWDCを離れますと、WWDCで得た情報を交換できるのは同じ会社の同じプロジェクトに携わっている方でADC Online以上にご登録の方同士に限られます。参加者同士であってもこれに当たらない場合は情報を交換することはできません」だそうです。つまりこの企画は、NDA違反にあたる可能性があるそうです。「WWDC参加者同士の情報交換」もダメだと言うわけです。
ちょっと待ってください。 このアルゴリズムに準じれば、ツアーのホテルで同室になった参加者や、WWDCの帰りの飛行機で隣の席に座った参加者と仕事関連でWWDCがらみの話をするのも規約違反になります。それどころか、MOSA開催の現地パーティー（アップル関係者も参加）での情報交換も間違いなく規約違反です（笑）。Apple社は、デベロッパー1社から10人ぐらい参加していると思っているのでしょうか？ うちはたった1人です（笑）高い旅費と参加費を払い（MacBook Air上位機種が買える）WWDCへ参加し、どう考えても、あのセッション量を1人でこなすのは不可能ですから、参加者同士（みんな似たような環境）が集まり、聞けなかったセッションの情報や感想を交換して仕事に生かそうと言うのが企画の趣旨です。「鉄は熱いうちに打て」ですね。
これは、ごく普通の考え方でしょう。 だいたい、我々の仕事とはMacやiPhone関連ですから、Apple社にとっても大きなメリットがあるわけです。もともと、WWDCとは、そうした目的のために開催されるカンファレンスでなわけで、これでは何のためのWWDCなのか？ 誰のためのWWDCなのか？ と言うことになってしまいます。 また、iPhone SDKは正規版になってもNDAが取れないという噂もあります。だとすると、iPhone開発関連の書籍や技術セミナー、加えて雑誌やウェブでの技術解説や議論などもすべてダメという事になります。iPhoneの場合、誰でもオープンにアプリケーションを開発できるのが素敵なわけですから、「やってみよう！」と思い立つ人達の間口を狭くするような愚行だけは止めていただきたいと思います（7月14日時点でSDKは正式版となりましたが、まだNDAは取れていません…）。
スティーブ、あなたの会社が世に出す製品は美しいです。ボタンもただひとつで操作も簡単、ユーザの才能や感性をうまく引き出します。しかし、あなたの会社が世に出すNDAは、まるで日本家電のリモコンのごとく、不必要な多くのボタンがユーザの才能や感性を阻害しています。
WWDC 2008に思う 小池邦人
(2008/06/20）
ところで、毎年WWDCではセッションスケジュールを記した小冊子が配布されるのですが、今回は無し！ 環境に配慮したわけでもないでしょうが、Apple社の参加者サイトの最新スケジュールを参照する方式に変更されました。このサイト、ちゃんとiPhoneやiPod touch用も用意されており（良くできている）、参加者は会期中このサイトを見ながら会場を移動していました。筆者は、いつもはあまり外出しないので、常時インターネット接続のモバイルデバイスを試す機会がなかったのですが、今回の会場におけるサイト回覧やメール利用で、この種のデバイスがこうした状況で本当に有用であることを痛感いたしました。まあ、参加者の多くは同時にMacBook Proなども持ち歩いていたので、全体的にはiPhoneなどを使っている人は少なかったとは思うのですが…。
さて、キーノートの会場に足を踏み入れて驚いたのは、その取材陣とテレビカメラの多さです。 事前にiPhone 3G発表が確実視されていた事もありますが、WWDCがコンシューマ向けの展示会ではなく、MacやiPhone対象のデベロッパー会議であるという点を考えると異例のことです。そして会場は参加者で満杯！ キーノート会場の収容人員は決まっていますので、余った人は強制的にオーバーフロールーム（映像のみ放映）へ回されてしまいます。Jobsから本年度の参加者は5,200人という発表がありましたが、チケットが売り切れていなかったら、もう1,000人ぐらいは集まったかもしれません。MOSAへも、売り切れ後に「チケット何とかならないか？」という問い合わせが相次いだそうですが、それは流石に無理（問い合わせ先が違う）と言うものです（笑）。
ご存じのとおり、WWDCのセッション等で話された内容はNDA（秘密保持契約）扱いですので、それらの詳細を一般開示することはできません。ただしキーノートだけはNDAが適用されず、自身のコラムや記事等で自由に言及してもOKです。ですから、キーノートに関する情報や解説、そして各関係者の感想は、雑誌や関連ウェブサイトに氾濫しています。筆者としては「iPhone OS 2.0」「iPhone G3」「App Store」「Mobile Me」などについては、前々から聞いていた噂に近い内容でしたので、それほどの驚きはありませんでした。それより「Snow Leopard」に関しては、キーノート内で詳細を紹介してほしかったと思います。どう見ても時間切れのため午後からのセッション（キーノートの延長だった）に回された感が強く、結局、その内容の開示は不可となってしまいました（Apple社のウェブサイトに少し開示されている）。
Apple社と四半世紀の間付き合ってきた筆者が、今回のキーノートで最も感慨深く眺めたのは「三本足のスツール（背もたれのない一人用腰掛）」のスライドでした。このスツールの三本足ですが、Jobsいわく、Apple社を支える3本柱のMac、Music、iPhoneだそうです。Apple社は、iPod登場以前の20年近くをMacintoshという「一本柱」だけで生き抜いて来ました。それも製品シェア数パーセントのビジネス環境で、です。よく考えると（考えなくてもか…）ビジネスの世界において、これは奇跡的な事かもしれません。途中で、この一本柱を削りもう一本の柱を立てようとして（クローン容認とOSライセンシング）あやうく本体が倒れそうになりましたが（笑）その柱がついに3本になったことを直接Jobsから聞ける時代が訪れようとは、ただただ感激です。
ところで足が3本に増えたとは言え、スライドに映ったスツール、安心して座るのには少し不安定な感じが漂っていることにお気づきでしょうか（笑）。筆者が今回のWWDCに参加して感じたのは、「Apple社は、このスツールに新たな4本目の足を追加しようとしているのでは？」と言うことでした。そして、4本足をそれぞれ?（ホゾ）で接ぎ（お互いに補強し）より丈夫で安心して座れるものを作ろうとしているように感じました。4本目の足が具体的に何なのかは、今のところは謎のままです。各足をハードウェアに例えるなら、Apple TVや噂になっているタブレット型Mac（iTouch？）なども候補かもしれません。しかし、Apple TVはMusicにまとめて「メディア」と呼べそうですし、タブレット型MacはiPhoneも含めて「モバイル」へと格上げできそうです。
4本目の足は、Apple社が今のところまったく参入していない分野がターゲットとなる可能性が高いように感じます。今回のWWDCでは、それに対する幾つかのヒントが提示されていたのかもしれません。まず最大のキーワードは「ビジネス」と言う単語でしょうか？ あちらこちらでプンプン臭っていましたね（笑）。iPhone OS 2.0は、Exchange対応を含めてビジネス分野のサポートが大きく強化されました。また、Snow LeopardでもExchangeがサポートされることが明言されています。「iPhone Developer Program」に参加している企業が、Fortune誌による500のトップ企業の中の35%をしめている点も強調され、Mobile Meに関しても、現在は「 Exchange for the rest of us」だそうですが、状況によってはビジネス分野への展開や拡張もありそうな雰囲気です。
iPhoneが関わる分野についてはまだ始まったばかり、これからが勝負であり、おのずとビジネス分野への参入準備を整えることができます。しかし、Mac（パソコン）に関しては、すでに存在している「別勢力」を大きく浸食する必要があります。逆に言えば、それだけ奪取できる大きなシェア（チャンス）が残されているという事にもなります。筆者は、Apple社は、こうしたビジネス分野へ進出するための「切り札」を持っていると考えています。それは「Mac OS Xのライセンシング」です。前にも書きましたが、この切り札は1本足の時に大失敗したビジネスモデルの再演となります。しかし現在、足は3本もあるわけでして（笑）1本に若干の悪影響が出たとしても、残りの2本でそれをカバーできる（逆に効果を得られる）だけの余裕もあるはずです。
この場合、ライセンシングはすべての分野に及ぶ必要はなく、コンシューマ分野については、Macintoshというブランドを維持すれば良いわけです。つまり、ターゲットをビジネス分野のみに絞るという作戦です。例えば、パソコンを生産をしていないSunやIBMと提携して、Mac OS Xを搭載したマシンをビジネス分野へ販売してもらうと言うのはどうでしょうか？CPUをインテル x86へ切り替えたMacに、もはやハードウェア的制約はありません（どこでも簡単に作れる）。また、こうした企業は、ハードウェア販売による利益ではなく、システムインテグレートやそのサービスを含めたソフトにより収益をあげています。ですから、その末端ツール（クライアント）として、システムの能力を正当に引き出せ、ユーザ側にとっても管理しやすい優秀なOSが確保できるのであれば、何の文句も無いでしょう。
Mac OS Xがライセンシングされれば、ひょっとするとDellやHPといたメーカも諸手を挙げて喜ぶかもしれません（笑）。Apple社にとっては、それが製品的には何ら面白みのない黒い箱の中で起動されようとも、Mac OS Xのシェア・アップが「4本足のエコシステム」の形成には重要なはずです。実際のところ、個人的にも「Mobile Me」や「App Store」のコンシューマ展開の方が面白そうですし、ビジネス分野（何をそう呼ぶかが問題ですが…）で使われるiPhone用アプリにもあまり興味がありません。また、Jobs自身も「ビジネスマシン」などという製品分野には、ほとんど興味が無いでしょう（彼がビジネス回りの話をする時、いつもちょっと嫌そうな雰囲気が漂う）。しかし、そこから得た利益や情報、経験、知識が、より良いコンシューマ製品（Apple社らしい）の開発へと反映されるのなら、小さな労力で大きな効果を上げられる戦略だと思います。
筆者としては、Apple社がコンシューマの世界に新風を吹き込んでくれる画期的な製品を出し続けてくれるのが一番です。 デベロッパーの一人として、そうした画期的な製品から刺激を得て、それを成長させるためにソフトウェア（アプリケーション）開発で貢献できれば、こんな楽しいことはありません。 そのためには、新たな収益を求めてビジネス分野へ足を踏み込むことも必要だと考えます。 会社自体が健全経営で収益を上げ、優秀な人材を確保し、適切な研究開発費を捻出できなければ、決して良いものは作れません。正直言って、1本足を削っていた時代のWWDCには暗い雰囲気が漂っていました。毎年技術チームのエンジニア（社員）は交代し、提示される技術内容も貧弱で魅力無く、デモする彼らからは自信のカケラも感じられませんでした。今回、各セッションを熱く堂々と仕切る若いエンジニア達を見ながら、そんな昔を思い出してしまいました。
来年のWWDCのキーノートでは、美しきスツールのために「4本目の足」の話が中心となることを期待したいと思います。
iPhone SDK登場に思う 小池邦人
（2008.03.08）
オンラインADCメンバーでもダウンロード可能ですので、配布対象制限は存在しないのに等しいのですが、相変わらずお堅い話です。まあ、中途半端な完成度のSDKについて色々と論評されるのを避けたいのでしょうが、「だったら約束通り2月末までに正式版を出してね！」と、突っ込みを入れたくなります（笑）そんなわけで、技術的な話題として取り上げることができるのは、スペシャルイベントでの発表内容（そこからの推測事項）のみと言うことになります。これでは、詳細な技術議論は何もできません。SDKを普及させ、出来る限りiPhoneアプリケーションを増やしたいという気持ちは、Apple社もユーザも同じでしょうから、もう少し柔軟な取り扱いはできないものかと思ってしまいます。
ところで、今までiPhone搭載のOSは「OS X」と呼ばれていましたが、iPhone SDKの登場により、正式に「iPhone OS」と呼ばれることになったようです。 スペシャルイベントでの発表では、iPhone OSは「Core OS」「Core Services」「Media」「Cocoa Touch」の4つのレイアに分かれています。個人的に嬉しいのは、各レイアには、Mac OS Xでなじみ深い「Framework」が多数採用されていることです。これであれば、Mac OS Xで習得した技術の多くが無駄にならず、iPhoneアプリケーションの開発にそのまま生かせます。特に、MediaレイアにおけるQuartz 2D、Core Animation、OpenGLの採用は（個人的にもお得意のFrameworkなので）自作iPhoneアプリに即生かせそうです。
iPhone OSに置ける3D描画環境は「OpenGL ES（Embedded System）」が担当します。 最近では、3Dだけでなく2D描画にも大きな役割を持つOpenGLですが、iPhone OSでの採用により、その認知度がさらに上がる事を期待したいと思います。OpenGL ES は、携帯電話などの組み込み用3Dシステムとしてはよく知られていますが、パソコンの3D描画環境としては、やはりWindowsの「Direct X」が主流であり、どうしても、そちらに関する書籍や資料の充実が先行します。そのため、GPUメーカの目も、まずはそちらに向きがちで、機能的にOpenGLが後手を踏む状態が続いています。iPhone OSの採用により、OpenGLの有効性が広く認知されれば、パソコンにおけるOpenGL環境の充実にも一役買うかもしれません。
今のところ、iPhone SDKβ版はLeopard（Mac OS X 10.5）用しか提供されていません。つまりMacintosh専用ということになります。XcodeやInterface Builderなどの既存Mac OS X開発ツールがそのまま使われるので、Windows版やLinux版が登場するかどうかは怪しいところです。ちなみに、iPhoneシミュレータの仕組みを実装することは、特定のFrameworkには依存しないでしょうから、そんなに難しくはないと思われます。たとえCocoaやObjective-Cが必須だとしても、Mac OS Xの開発環境自体を別プラットフォームへ移植する（例えばCocoa for Windowsとか）よりは壁は低いはずです。ただし、実際にMacintosh以外のプラットフォーム用のSDKが出るのかと言えば、それはあり得ないかもしれません。
なにせ、SDKの使用環境がMacとMac OS Xに限られますから、iPhone用ネイティブアプリを開発しようとすれば、必ずMacを購入することになります。Apple社としは物理的「ハロー効果」と言うべきか…大変美味しい商売になるわけです（笑）。iPhoneが全世界でどの程度普及し、その有用性がどの程度認知されるかにも関わりますが、Apple社が言うように、2008初年度だけで1000万台の販売目標が達成できるとすれば、現Macデベロッパー以外のiPhoneデベロッパーによるMac需要も、かなりの数になると予想できます。間違いなく、短期間で現在のMacデベロッパーの数を抜くでしょうね。今から、今年のWWDCでの基調講演や朝食の席取りが不安になってきます…。
iPhone用アプリ開発に魅力を感じるソフトメーカや個人が増えれば、他のプラットフォームからの乗り換えや両刀使いも促進され、Macintosh自体に目を向けてくれる技術者や開発者も増えるかもしれません。今は「仮想環境」の普及で、MacでWindowsやLinuxも利用している技術者が増えていますが、さらにその傾向に拍車をかけることになります。これは、MacプラットフォームとMac OS Xに関しても大きなメリットとなるでしょう。現在、Mac用アプリケーションの主流はCocoa FrameworkとObjective-Cで開発されています。しかし、CocoaやObjective-Cによる開発作業があまり一般的でない（マイナーな）ために、Mac OS Xでのソフト開発には興味はあるのだが、二の足を踏んでいる別プラットフォーム開発者（潜在的なMac開発者）がかなり存在しています。
iPhone OSとSDKは、そういう人達をMacに引きつける起爆剤になって欲しいところです。また、Carbonや別Frameworkを使うMac開発者は、旧資産の活用やメンテナンス、技術資料の不足といった理由から、CocoaやObjective-Cへ移行しづらい状況が続いています。つまり、個人的にはいつでもOKなのですが、会社としてそうは動けないという問題です。 Apple社も、QuickTimeやCarbonの64Bit化を中止するなど、移行促進をサポートしていますが（笑）現実はなかなか難しい状況です。ところが、iPhone SDKでは、今のところCocoaとObjective-Cを使うしかありません。やるしかないとなれば、会社としても即実行となるでしょう。それは、Cocoaの素晴らしい特徴を多くの開発者にアピールする絶好の機会にもなり、関連技術資料や書籍の充実にも貢献するはずです。
今回、開発者（特に小規模や個人）にとって最も魅力的な発表は、開発したアプリケーションの配布に「App Store」が用意されている点だと思います。 ソフト登録の仕組みや利益配分率なども「ざっくり」とシンプルで分かり易く定義されています。アプリケーション登録（出店）についても、難しい認定を得る必要もなく、$99の費用で「iPhone Developer Program」に加入しさえすればOKのようです。このあたりの仕組みは、さすがにApple社、さすがにJobs CEOと言ったところでしょうか（笑）。ただし「iPhone Developer Program」は米国先行となっています。その点は、日本の開発者としては少々不満なのですが、すみやかに加入手続きが始まることを期待したいと思います。
まあ、インターネット経由でのソフト販売そのものは珍しい事ではありません。筆者も何度か販売経験がありますが、供給元が一本に絞られているというのは結構魅力的です。購入したいお客を集約でき、煩雑な手間を省けます。Webアプリケーション開発者であれば、サイトにアクセスするためのアプリを有料で提供することで、今までは個人レベルでは難しかった「課金」という仕組みを簡単に実現できそうです。また、iPhoneアプケーションは物理的に小規模ですので、膨大な資金と人材を使い力ずくで開発した「モンスターソフト」が市場を荒らす可能性も少ないでしょう。つまり、個人や小規模といった点がデメリットとはならず、アイデアに対して小回りが利くというメリットになる可能性が大きいのです。
パソコン自体、もしくはApple IIや初代Macが登場した時もそうでしたが、新しいプラットフォームが登場したばかりには、それを所有しているユーザには大きな「飢餓感」があります。つまり、面白くて変わっていて興味ある物なら何でも購入するのです（笑）。それの価格が1万であれば、少し「ためらい」が生じますが（昔はそれも無かった）1000円なら一瞬考えるだけ、100円なら間違いなく「即ポチ」するでしょう。自動販売機で缶コーヒーを購入する気軽さと同じです。価格の妥当性まで考えが及ぶ暇もなくダウンロードされていくわけです。最初のうちは英語版さえ作成しておけば（多分）市場ターゲットは全世界です。100円の商品を年間10万本販売できれば1000万の収入となります。大企業であれば大したことはないのですが、個人であれば大変魅力的な金額です。
App Storeが成功するかどうかは、今後、iPhoneが魅力的なプラットフォームとしてユーザを魅了するかどうかにかかっています。しかし、たとえ成功したとしても、上記の様な活況は一定期間経てば収束するでしょう。今回はその期間が短いかもしれません。いかなる時もそうでしたが、大量の製品が登場し出せば、同様なアイデアを実装したライバルも増えます。一旦そうなってしまうと、幾らか技術的アドバンテージがあろうとも、多くの類似品の中に埋もれる可能性が高くなります。そして、10円単位の価格競争が起こるかもしれません（笑）。ですから、もし素晴らしいアイデアがあるなら、誰よりも先んじて実現し、App Storeに出店することが肝心です。それが多くのユーザに受け入れられれば、短期間で大きな利益（個人的レベルの話です）を生み出せるはずです。
ある意味、筆者が夢に描いていた「ソフト屋商売のビジネスモデル」が登場することになります。 人生の中でもこうした大きなチャンスにはそうは何度も遭遇できません。また、Mac開発者には間違いなく先行アドバンテージがあるわけですから、それを生かせるかどうかは「あなた」次第なのです。さて皆さん、お互いに頑張りましょう（笑）。
MOSA Software Meeting 2007（ MSM2007）の展望 MSM2007 実行委員長 小池邦人
（2007.11.6）
10月26日に待望の「Leopard（Mac OS X 10.5）」が登場しました。Macデベロッパーには、Leopardの最新テクノロジーを盛り込んだソフト開発という大きなテーマが与えられました。また10月18日には、Steve Jobs CEO自らiPhone用SDKを来年の2月に出すことを発表しました。Macデベロッパーは、今まで積み上げてきたMac OS X環境での開発スキルを、iPhoneやiPod touch用アプリの開発にも生かせることになります。
現状では、Mac OS Xに対するソフト開発技術を習得しても、それを生かす場所はMacプラットフォームに限定されています。Objective-C＋Cocoaという開発環境も然りです。しかし、今後はそうした状況が一変するかもしれません。「OS Xを搭載した新しいデバイスとそこで動くソフト、そしてiTunes Store経由の流通という新市場」が登場する予感がします。これは、現在のMac市場よりはるかに大きな市場となりえます。
そうしたことから、今回のMSMのテーマを「Mac OS Xの新潮流」と決め、その趣旨にマッチしたセッションを多数用意しました。デベロッパーが、このような将来の市場に対してアドバンテージを得るには、なるべく早い時期にMac OS Xの最新テクノロジーと向き合い、それを習得し、その可能性を追求しておくことが必要でしょう。デベロッパー同士のオープンな交流の場を提供しているMSMへの参加は、まさにそうした機会にもってこいのはずです。
セッション中の質疑応答、セッション間の休憩時間での談笑、初日に行われる参加者全員参加によるパーティーなど。こうした交流の場を提供できることが、MSMを開催する最大の意義です。毎年こうした場において、デベロッパー同士による内緒話の交換、共同作業の開始、仕事の発注受注（笑）などが実現しています。新しいパートナや情報入手経路を確立するという意味において、MSMはデベロッパーに重要な機会を提供しています。
MSMでのセッションには純粋な技術解説もありますが、90分という短い時間ですべての内容を消化することは不可能です。ですから、各セッションで未体験の技術やコンセプトと出会い、刺激を受けてもらい、次なる開発の方向性を見つけてもらうのが最大の目的です。斬新なアイデアはどこに眠っているかわかりません。職業柄、同業者以外との交流が限定されているデベロッパーにとっては意義ある機会となるでしょう。
ここでは、MSM2007で行われる各セッションを簡単に紹介しておきます。
まずはMSM名物キーノート、テクノロジーライター大谷和利氏の「ソフトウェア・アーティスト宣言！」です。 工業製品とはひと味違うソフトウェアの「アートとしての一面」を熱く語ってもらいます。同様に、Macのソフトウェア開発現場はどうなっているのか？我々はソフトウェア・アーティストとして生きていけるのか？という疑問には、株式会社デジタルステージ 平野友康氏による「デジタルステージのソフト開発の裏側、全部見せます！」が答えてくれるはずです。
発表されたばかりのLeopard（Mac OS X 10.5）関連セッションとしては、アップルジャパン協力の「Mac OS X Leopard対応アプリケーション開発について」と、筆者による「Leopardのグラフィックス＆開発環境入門」があります。Leopardから搭載された新機能（CoreAnimationやQuickLookなど）をアプリケーションから活用する方法や、一新されたXcode 3.0開発環境などについて解説する予定です。
加えて、いつも開催要望が多いMac OS X対応ハードウェア関連セッションについては、三洋電機 塩路昌宏氏の「Xactiにおけるビデオ処理技術の紹介およびH.264を使用した今後の展開」と、inADA 稲田元彦氏の「SecureSuiteDK for FeliCa on MacOS X入門」の2セッションが用意されています。どちらのハードウェアもまさに「旬の技術」ですので、Macintosh用ドライバ開発者の方々は見逃さないでください。
Apple社のパートナーであるインテルの菅原清文氏には「Leopard対応インテルソフトウェア製品アップデート」を解説してもらいます。関係者でも、インテル社がMac用開発ツールを提供していることを知らない人が多いのですが、なにせ本家本元が提供するツールですので、Core 2 Duoのマルチスレッドに最適化された非常に優秀なコンパイラやフレームワークがそろっています。Xcodeスタンダード以外の優秀な演算ライブラリなどを探している大学やメーカの研究者の方々は、多くの有益な情報が入手できるでしょう。
iPhone用SDKが登場するまでは、iPhoneやiPod touchの活用手段としてはウェブアプリケーションが主役となります。今回のMSMでは、そちらに関するセッションも充実させました。まずはアップルジャパン協力の「Safari 3.0 およびその開発ツールについて」です。また、インフォテリア・オンライン 藤縄智春氏には「オンライン表計算「OnSheet （オンシート）」でつながろう!!」で、ウェブアプリについて解説してもらいます。
LeopardにはCocoaアプリ開発用の「RubyCocoa」が搭載されていますが、その開発者であるフリープログラマ 藤本尚邦氏には「今どきのRubyCocoaプログラミング」において、最新のRuby関連情報を紹介していただきます。また、Ruby同様にOS Xとオープンソースとの関わりは深いのですが、そうしたオープンソースとフトウェア開発ビジネスのあり方について情報を得るには、フリーランスITジャーナリスト 林信行氏とMozilla Japan 瀧田佐登子氏による「ソフト開発ビジネスの新潮流」に参加してみてください。
最近は、Parallels、VMware、CrossOverなどを用い仮想環境でWindows用アプリを使うMacユーザも増えています。プログラマー・ライター 田中俊光氏には「Windows仮想環境に関するディスカッション」でその可能性について追求してもらいます。WindowsアプリとMacアプリとの同時開発を考えているデベロッパーの方々には、Trolltech 及川寛氏と朝木卓見氏が解説する「Qt APIを使用したマルチプラットフォーム向けアプリケーション プログラミング」が参考になります。 「Qt」は、マルチプラットフォーム開発環境として実績があり、AdobeやGoogleが提供するアプリでも利用されています。
「Mac OS Xの新潮流」を直に感じる場としての「MOSA Software Meeting 2007」を大いに盛り上げたいと思います。スタッフ一同、皆様のご参加をお待ちしております。興味のある方は以下のウェブサイトをご参照ください。
開発環境をMacProに移行する 小池邦人
（2007.6.7）
ところで、6月開催されるWWDC2007ではLeopard（Mac OS X 10.5）のβ版が配布されることが確定しました。「Xcode Tools」や、それに付属するFrameworkもかなり変更されることが予想されるので、それらを最新のIntelマシンで試してみたいと言うのが次の理由です。「新しい酒は新しい器に」「鉄は熱いうちに打て」と言ったところですね。続いて、開発アプリケーションの中に早急に64Bit化しなければいけない物があるのが3番目の理由です。もちろんPPCマシンの方はPowerMac G5で大丈夫なのですが、現状手元にあるIntelマシンはCore Duo CPU搭載のものだけで、残念ながら、こちらは64Bitアドレッシングに対応していません。また処理に複数スレッドを使うアプリケーションで、2コア以上（4コアや8コア）のマシン環境における最適化（チューニング）を色々と試験してみたかったことも大きな理由のひとつです。
さて、さっそく購入マシンスペックの検討です。筆者は、8コア版が登場した時点で4コア版MacProの価格が値下げされるとふんでいたのですが、残念ながらその予想は外れました。2.66GHz 4コア版の価格は据え置かれ、3GHz 8コア版に拡張すると、何とプラス188,790円もかかってしまいます。この価格レベルはさすがに厳しいですね（笑）。とりあえず、メモリの値段が少し下がりましたので（でも高価）2.66GHz 4コアマシンに4GB（4x1GB）実装し、搭載HDDの容量も500GBにアップしました。これでトータル424,700円となります。購入先はどうしたものかと悩みましたが、ADC Selectメンバーにはマシン1台+周辺機器（モニタなど）の開発機購入割引特典があるので、これを利用することにしました。この特典をうまく使えば、ポイント付販売店で購入するよりも割安となります。この特典、昔はSelectメンバー加入2年目からしか有効になりませんでしたが、現在は加入1年目から有効のようです（最終購入価格についてはアップルから見積もりが届く）。
続いては、届いたマシンのセットアップなのですが、初回起動で立ち上がるセットアップアプリケーションで大きな問題に遭遇しました。必要なデータを別マシンから移行するように設定し、FireWire経由でターゲットモードで起動した別マシンを接続したのですが、いつまで経ってもデータのコピーが始まりません？ターゲットマシンを別マシンに変更してもダメ、ならばと移行データをネットワーク関連だけに絞ってみてもダメ、ウンともスンとも言いません。筆者の環境だけの問題かもしれませんが、この仕組みがうまく動いてくれないと移行の手間がかなり増えてしまいます。仕方がないので、とりあえず手入力でセットアップし、まっさらの状態から「移行アシスタント」アプリケーションを使いホームディレクトリやアプリケーションをコピーしました。ただしXcode Toolsはコピーされませんので、再インストールが必要となります。
後はシリアル番号を移行できなかったアプリケーションを再レジストしすれば、以前とほとんど変わらない環境の出来上がりです。唯一違う点はClassic環境が存在せず、Mac OS 9用アプリケーションを起動できないことです。筆者の環境では、そうしたアプリケーションはResEditだけでしたが、20年以上もお世話になってきた旧友との別れは辛いものがあります（笑）。PPC版アプリケーションの方は、Intel版Mac OS Xに搭載されている「Rosetta」が面倒を見てくれます。このRosettaの処理速度と交換性は大変優秀でして、例えば、Metrowerks CodeWarriorなども問題なく起動でき、古いタイプのアプリケーションをメイクすることが可能でした。あまり期待していなかったのですが、これにより古いアプリケーションをチェックするためだけに（時々ある）PPCマシンを起動する必要がなくなります。ちなみに、Rosetta上でのMetrowerks CodeWarriorのコンパイルスピードはPowerMac G5 2GHzと同等でした。
当然のことながら、ネイティブアプリケーションのパフォーマンスは素晴らしいの一言です。筆者が開発したEmonCというボクセル表示アプリケーションでの処理（マルチスレッドで複数コアをすべて使う）を比較してみると、PowerMac G5 2GHzで46秒かかっていた処理がたった11秒で終了してしまいます。Xcodeでのコンパイル処理も4倍近いスピードを発揮します。もともと、同クロックのPowerPC G5と比較して、Core 2 Duo CPUは整数処理パフォーマンスが2倍以上ありますので、この結果は予想範囲内です。ただし、浮動小数点演算やSSE演算（PPCのAltiVecに準拠）は5割から7割ぐらいのパフォーマンスなので、中には不得意とする処理もあるでしょう。しかし、こちらのパフォーマンスも、次世代CPUに新しい除算ユニットやSSE4が実装されることで大きく改善される見込みです。
ソフトウェア的な移行が完了したら、続いてハードウェア環境を整えます。MacProは4台までのHDDを内蔵でき増設作業も簡単ですから、RAID等を組むのには最適です。また、開発者は昔々に開発したアプリケーションの動作確認用として旧バージョンOSをインストールしたパーテーションを多数用意します。加えて、これから登場する新OSをチェック（Seeding）するための独立ボリュームも確保したいところです。当然バックアップ用HDDも必要ですから、それらをすべて内蔵ディスクとして管理できるのは実に効率的です。さっそく500GのHDDを2台購入して増設してみました。バルク品であれば500G HDDは13,000円〜15,000円で購入できます。購入したのは日立製でしたが、元々の内蔵HDD（シーゲート製？）よりアクセス音が静かでしたので、こちらをメインボリュームに変更してしまいました。また、MacProには2つのCD-ROMベイがあるので、将来Blue-Rayドライブが安くなったら装着してみたいと考えています。
ところで、今回の移行で一番嬉しかったのは、このマシンが大変に静かだと言う点です。以前のPowerMac G5は処理が煮詰まってくると、ファンが「ブオ〜〜」と飛び上がりそうな轟音を立てうるさくてたまりませんでした。大画面ディスプレイに対応させるためにビデオカードを上位機種へ差し替えてからは特にその傾向が強くなり、歴代で一番「熱くてうるさいマシン」のレッテルが貼られていました。ところが、MacProの方はコア数が倍になったのにも関わらず大変静かです。開発作業中はHDDのアクセス音だけが部屋に響き、あまりにも静かなので、スリープしているのか画面が暗くなっているだけなのか区別が付きません（笑）。開発中にiTunesを使いバックグランドミュージックを楽しんでいる筆者にとっては、この静寂性が移行最大のメリットかもしれませんね。これから開発環境をIntelマシンへ移行しようと考えている方に、筆者の体験談がいくらかでも参考になれば幸いです。