変態扱いされそうなので、あまり他人に話したことがないのだが、私は「角が丸くなった四角」が大好きである。iPhoneのUIにも随所に見られるし、CSS3にも採用されたし、実は世の中には「隠れ角丸フェチ」がたくさんいるのではないかと思っている今日このごろである。
そんな私が作るiPad用のベクターエディター（参照）には、当然「角が丸くなった四角」を描画する機能は付くのだが、「四角が角丸に出来るなら、三角だって。いや、星形だって可能なはず」と色々と試行錯誤しているうちに、「これって一般化すれば、ポリゴンをベジェ曲線に連続的に変化させることも可能なはず」と妙に燃えて来てしまい、できたのがこれ。やはり角丸は見ているだけでなんとも心地良い。
先日もここで少し触れたが、最近は neu.Notes の姉妹品の開発に集中している私である。いきなりAdobe Illustrator 並みの豊富な機能を実装することは無理としても、最低限必要な機能を備え、iPadならではのインターフェイスを最大限に活用した、「パソコン＋マウス＋Illustratorよりも生産効率の高いベクターエディター」を作ることは十分可能なはずである。
ここ数日は、ベジェ曲線の作成・編集にチャレンジしている。ベジェ曲線は表現力は豊富だが、コントロール・ポイントが多いために、それをIllustratorのようにそのままインターフェイスに反映させると、やたらと複雑になり、直感的な操作がしにくくなるのが難点である（「イラレのベジェ分からん！」という声が今日だけで３つほどTwitterに流れていた）。そこで、あえてIllustratorやPhotoShopが採用しているインターフェイスを否定し、より直感的な操作を実現しようと色々と工夫しているところである。
しかし、この手のUIデザインになると実際に使ってみないと使い心地が分からないので、「作っては壊し」を繰り返す必要があり、とても手間がかかる。ベジェ曲線の処理だけで、すでにもう２０回ぐらい書き直しただろうか。
今日になり、ようやくインターフェイスがイメージするような形になって来たので、「生産効率」のテストのためにマリリン・モンローのサインの模写にチャレンジしてみた。
サインの画像を下に置いて、ベジェ曲線を重ねるように生成して行く。この手の作業が効率良くできるかどうかが、「パソコン上のIllustratorより使いやすい」かどうかの大切な鍵となる。
結果としては、トータルで１５分ぐらいで上の図（実際にはベクターデータ）を作ることができたので、まあ満足できる結果である（パソコン上のIllustratorでやってもよほど慣れた人でない限り同等かそれ以上の時間がかかる）。この作業をしながらも、細かな点でいくつか修正すべきものが見つかったので、ひとつひとつ直しているところだ。
こうやって、一つ一つ石を積み重ねて行くようにアプリを作って行く。この過程が楽しくてたまらない。まだまだやらなければならないことがたくさんあるので、リリースは少し先になるが、良いものが出来つつある感触は十分につかめているので、乞うご期待である。
日本にも「五体不満足」を書いた乙武さんがいるが、まさにこの人は米国の乙武さん。障害を持ちながらも前向きに明るく生きる姿勢を示すことにより、拒食症や鬱病のティーンエージャーに生きる勇気を与えるという活動をしている。親や先生から何を言われようと「フン」と話を聞きもしないティーンエージャーが、彼が「自分がみにくいとか、生きている価値がないなんて発想は間違っている」「人生はどんな境遇にあろうと生きているだけでそれに感謝しなきゃ」と力説すると涙を流して聞くという。
今朝、久しぶりにFacebookにアクセスしたところ、昔の知り合いの間でちょうど１５年前の今日にWindows95がリリースされたことがしきりに話題になっていた。Windows95は、マイクロソフト自身にとっては大きな飛躍の始まりだったし、パソコン業界全体にとっても「誰もがパソコンを持つ」時代の幕を開けたOSとしても大きな意味のあるものであった。
私が、Windows95の開発に関ることになったのは色々な偶然が重なった結果だが、直接のきっかけは頭でっかちのアーキテクトばかり集めて会議ばかりしていたJim Allchin率いる「次世代のOSを担う」Cairoチームを飛び出して、「Cairoが出るまでの中継ぎ役」だったBrad Shilverberg率いるChicagoチームに移籍したのが原因。
コンピューター・サイエンスの博士号を持つアーキテクトを何人も抱えるCairoチームに「ハッカーの寄せ集め」と蔑まされていたChicagoチームが結果的にはWindows95を出すことになったのだから、何とも皮肉なことだ。
今考えてみると、Cairoは「賢い連中が会議室でアーキテクチャを決めて、下々のエンジニアがコードを書く」というウォーターフォール的な開発をしようとして破綻し、Chicagoは「エンジニア自身がコードを書きながらアーキテクチャを固めて行った」という今で言うところのアジャイルな作り方をして世界を制したわけで、私のウォーターフォール嫌いはこのあたりから来ているのかも知れない。
まあ、そんな話はおいておいて、Windows95のローンチビデオを見ていただきたい。あのころは元気があったよな、マイクロソフト。しかし、あのころは毎日のようにWindows OS上でC++コードを書いていた私が、今や一切Windowsマシンに触れず、iPhone/iPad上のコーディング（たまにGoogle-App-Engine）に明け暮れる日々。世の中のトレンドがこれほど早く変わるとは誰が予想できただろう...
私も交換書簡およびアプリの開発を担当している、梅田望夫さんの「iPadがやってきたから、もう一度ウェブの話をしよう」、電子書籍ならではの目玉は、発売後に読者からいただいた質問に私と梅田さんが答えるという「増える交換書簡」。
すでに二つの質問に対する回答がアップロードされているが、これからも順次答えて行く予定なので、質問の方、よろしくお願いする。
興味深いのは、最初の二つの質問がどちらもソニーに関するものであること。「なぜソニーがアップルになれなかったのか？」「ソニーとグーグルの提携に未来はあるのか？」。
株価総額でもあっさりとアップルに抜かれ、ここのところいまいち元気のないソニーだが、「もし日本のメーカーでアップルに対抗することができる企業があるとしたら、それはソニーだろう」という多くの人の期待を込めた質問なのだろうと解釈している。
私の回答は交換書簡を見ていただくとして、逆に私からこのブログ（もしくはこの電子書籍の）の読者に質問を投げかけてみたい。質問はずばり「なぜソニーはアップルになれなかったのか？」だ。
アップルが瀕死状態だった２０００年前後、家電ビジネスには多少問題があったものの、プレステのビジネスは絶好調でメディア・ビジネスへの投資にも効果が現れており、色々なものがデジタル化する中で、当時のソニーは「デジタル家電の覇者」になるのに必要な人材・技術力・ブランド力・カルチャーのすべてを持ち合わせていたように思える。
しかし、実際にはiPodで足元をすくわれ、iTunes Music Storeではまさに「ソニーがやりたかったこと」を目の前でされ、iPhoneがあっと言う間にソニエリを抜き去りスマートフォンの頂点に達し、電子書籍端末に関して言えば、iPad vs. Kindle の戦いの土俵にも上げてもらえない状態だ。
なぜこんなことになってしまったのだろうか？そして、これからどうすればソニーは復活できるのだろうか？もしくは、真っ向からアップルと戦わないのであれば、ソニーはどんな企業になれば良いのだろうか？
このエントリーへのコメントでも、はてぶでも、Twitterでも（タグは #sonyap）、自分自身のブログへのエントリーを書いてトラックバックをする形でも良いので、ぜひとも皆さんの意見・味方を聞いてみたいと思うのでよろしくお願いする。活発な意見交換を期待する。
編集担当の方から、「これから電子書籍アプリを作ろうという人向けにノウハウなどを公開して欲しい」とのリクエストに基づき、CloudReadersの開発経緯とアーキテクチャを解説してみた。
ノウハウとは言っても、基本的には「ちゃんとMVCで作れ」「できるだけCPUじゃなくてGPUに仕事をさせる」「Interface Builderを最大限活用して、UIとロジックを分離しろ」などの話なんだが、実際のアプリを題材にそのアーキテクチャを語っているので、その手の「基礎」と「応用」のギャップをなかなか乗り越えられない人には良い教材だと思う。
ちなみに、アーキテクチャの解説部分は、
ユーザーが読みたいドキュメントを選択するとロードされるのが、ComicReaderViewControllerだ。これが「他のリーダーよりも、はるかにサクサク動く CloudReaders」の評判を支える知恵の固まりである。
ComicReaderViewControllerの初期化は、initWithBook:メソッドの呼び出しで行われる。ユーザーがライブラリの中からドキュメントを1つ選択したことを感知したRootViewControllerは、ComicLibraryから選択されたドキュメントに相当するComicReaderBookオブジェクト（後述のModelクラスの1つ）を取り出し、それを新しく作ったComicReaderViewControllerオブジェクトのinitWithBook:メソッドに渡す。さらに、view stateからそのドキュメント向けのview stateを取り出して、restoreViewState: メソッドを介してComicReaderViewControllerに渡す。...
の様にソースコードを交えて書かれているので、iOS上での開発経験の全くない人には少し辛いかもしれない。iOS上でアプリを作りはじめてみたものの、Interface Builderがうまく使いこなせない・View/Controllerの切り分け方が分からない・アプリがなかなかサクサク動いてくれない、ぐらいの人にちょうど良いだろう。
特にはっきりとしたビジネスモデルがあるわけでもないが、「とりあえず良いものを無料で提供して、たくさんの人に使っていただいて、それから考えよう」とリリースした、iPad用の手書きメモアプリneu.Notes。とりあえず当面の目標の「仕事効率化カテゴリーで１位」を達成（日本のアプリストア）。瞬間風速かも知れないが、Evernote、Dropboxなどの強豪がいるこのカテゴリーでの１位はうれしい。
iPadアプリの市場は、私が予想した通りのレッドオーシャン。有料だろうが無料だろうが、たくさんの人に使ってもらってランキングに載らないかぎり試合に出れない野球選手と同じ。これだけの数の玉石混淆のアプリが並ぶ中で「目立つ」ためには、単に「良いものを付くる」だけでなく、「どいういうシナリオで使ってもらうのか」「どうやったら使い続けてもらえるのか」を考えつつ、ユーザーの声を反映させながらこまめにアップデートして行く必要がある。この状況で本当の意味の「黒字企業」はごくわずかだ。
このneu.Notesだって、この業界のベテランの私とPeteの二人が無給でフルタイムで３ヶ月働いてようやくここまで来たわけで。これが普通の会社だったら、給料＋諸経費で既に数百万は使っている計算になり、資金回収は簡単ではない（もちろん、ITゼネコンに頼めば最低５０００万円はかかるし、とうてい３ヶ月じゃできない、という話は別のところで...）。
継続的にビジネスとして行うためにも、早く有料版を出したいとは思うのだが、まだまだ無料版を使ってやりたいこと、できることがあるのでしばらくの辛抱だ。リリースしたばかりの、iPhone版のneu.Notesもなかなかの検討をしているが、こちらももう少しユーザーを増やす必要がある（現在、同７位）。
もちろん、バージョンアップも定期的にして行く。現在、罫線とマップとの連携（「いまココ」機能）をサポートした version 1.4 のベータ版をテストしている所なので、１〜２週間後にはiTunesストアに並ぶと思う。
ちなみに、neu.Notesと並行して開発を進めているのは、neu.Notesの「姉」に相当する本格的なベクター・グラフィックスの描画アプリ（名前はまだない。ノスタルジックにCANDYにするという案もあるが、やめておこう）。
「ささっとメモを書く」というシナリオに重点に置いているneu.Notesと異なり、「出来上がりのきれいなベクター画像を作る」というシナリオに重点を置いているので、「描画済みのものを選択してさまざまな変更を加える」などの複雑な操作を（かつ、直感的なUIで）サポートしなければならないので、UIデザインも開発も簡単ではない。先週になって、ようやくいくつかの技術的な障壁を突破できたので、一息ついている所だ。
現在悩んでいるのは、具体的な商品のポジショニング。パソコンで言えば、Illustratorを目指すのか、Visioを目指すのか、それともPowerpointの作図機能に対抗するのか、というあたりである。もし、iPadを色々なものの作図・作画に使いたいと考えているユーザーの方でご要望やご意見、もしくは既存のアプリへのご不満などがあるのであれば、ぜひともこのエントリーのコメント欄などに書いていただけると助かる。
ちなみに、この描画モジュールは思いっきり使い回しがきく様に作ってあるので、それを活用すれば「オフィス家具レイアウトアプリ」「４コマ・マンガ作成ツール」「福笑い」「プリクラ」のような特殊用途のアプリも簡単にできる。そのあたりの共同開発の話もぼちぼちと始めようかと思う。
iPadに関しては、「ウェブサイトを閲覧したり、電子書籍を読んだりという『メディアの消費活動』には適しているが、『何かを作る』という部分ではパソコンにかなわない」という評価が一般的である。そういう評価を聞けば聞くほど「そんな考えが間違っていることを俺が証明してやろう」と思ってしまうアマノジャクな私である。最終的に目指すところは、もちろん「パソコン上のIllustratorとマウスで描くより、neu.XXXを使って指で描く方がずっと簡単じゃん」と言ってもらえるものを作ること。簡単な話ではないが、少なくとも何ヶ月間はそれに没頭する価値のあるプロジェクトだ。
往復書簡の中でも触れたが、私がiPhone/iPadのアプリケーションの開発にこれほどまでにコミットしているのは、この新しいデバイスの上で、従来のデバイスでは不可能だった「何か全く新しいもの」が可能になるという確信があるからだ。かといって、具体的にそれが「何か」を知っているわけでもなく、こうやって色々と作っているうちにその「何か」を見つけて作り出して行く過程そのものが楽しくてしかたがないのだ。
この電子書籍も、単に「本来ならば紙の本として出しても良かったものを電子化したもの」ではなく、「増える往復書簡」いという電子書籍ならではの新しい試みをしているという意味で、その「何か」に向かう過程の作品の一つとしてとらえていただければ良いと思う。
ちなみに、「電子書籍ならではの新しい試み」というと、安易に「ビデオとの融合」だとか「サムネールがぐるぐる動くUI」だとかのギミックに走る傾向が見られたが（"Alice for iPad"が良い例）、その手のことがガンガンやりたいのであれば、書籍ではなく「マルチメディア・アプリケーション」を作ったり、FlashなりHTML5を使ってウェブでコンテンツを提供すれば良いわけで、「紙の本よりすぐれた書籍」という方向性とは少しずれているように思う。
子供はいざしらず、大人が書籍に求めるのは「読んで面白い・役に立つ・考えさせられる文章」なわけで、そこでの主役はあくまで文章＝コンテンツそのものだ。コンテンツが充実していないのに、ギミックばかりで飾り立てた電子書籍は、中身がないのにアニメーションとページ遷移ばかりがすばらしいパワポのプレゼンと同じだ。
電子書籍におけるアプリは、単にそのコンテンツを読者に届けるための道具でしかない。アプリを作った私が言うのも変な話だが、この電子書籍を買う人は、決して「（OEM版の）CloudReadersの読み心地を楽しむために」買うのではなく、「梅田さんの文章、もしくは梅田さんと私の往復書簡が読みたいから」買うのである。アプリそのものはできるだけ黒子に徹し、読み心地とか使い勝手をユーザーが意識せずに、コンテンツに没頭できることが一番望ましいのだ。
ということで、この電子書籍を購入していただいた方には、ぜひともコンテンツそのものをお楽しみいただきたい。特に、巻頭の「増える往復書簡」はごく最近私と梅田さんが交換したメール書簡で、とても鮮度の高いものだし、ウェブ上にこれから展開される読者との質疑応答は、紙の書籍では絶対に不可能なものだ。ぜひとも質問を投稿して「iPad/iPhoneならではの新しい体験」に参加していただきたい。
私がコラムを書いている「WEB+DB PRESS」の最新号が発売されたので、ここで宣伝させていただく。今回のコラムのタイトルは、「「なぜ日本のソフトウェアが世界で通用しないのか」。
...(前略)...そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること、そして、日本のソフトウェア・エンジニアの境遇が悪すぎるということ。そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。
詳しくはコラムを読んでいただくとして（宣伝だと言ったでしょう）、この問題はいまやソフトウェア業界だけにとどまる話ではないから始末が悪い。世界で一番進んでいるはずだった日本の携帯電話メーカーが、今や袋小路に追い込まれているのもこれが原因。
通信業界にはもちろん、携帯電話メーカーにもソフトウェアを自分で書ける人がいない今の日本の状況を考えれば、世界のトップクラスのソフトウェア・エンジニアを自社で抱えるアップルやグーグルにおいしいところを持って行かれても当然。いままでさんざん「ITゼネコンや下請け」にソフトウェアの開発を丸投げにして来たツケが今になって回って来ただけのこと。
これから携帯電話に限らず、家電メーカーにとってもますますソフトウェアが差別化の重要な武器になって行く。そろそろ「ITゼネコン」から脱却して、社内に「自分でコードが書ける」ソフトウェア・エンジニアを育成する時期だと思うんだがどうだろう。前にも別のところで書いたが、「コードを自分で書かないエンジニア＝自分で料理をせずにレシピだけ書いている料理人」と同じだと覚えておいて損はない。
以前、ここで少し触れたCloudReadersのOEM版ビジネスの話、ようやく第一弾をリリースすることができた。梅田望夫さんの「iPadがやってきたから、もう一度ウェブの話をしよう」だ（出版は、株式会社産経デジタル）。
基本的にはCloudReadersのコードをそのまま使っているので、開発はとてもスムーズにできた。違いと言えば、iPad版だけでなくiPhone版もリリースしたことぐらい（これを機会にiPhone版のCloudReadersを出すのもありかと考えている）。ちょっとした工夫として、ウェブ上でのリアルタイム書簡も読めるようになっているのも特徴。電子書籍だからこそ可能な仕組みだ。
本文は、梅田さんの書いたものだが、それに私と梅田さんの間の「メール書簡」が付いていて、それだけでも結構読み応えがあると思うが、それに加えて、読者からの質問に私と梅田さんが答るという、リアルタイム書簡が読めるようになっているのが特徴。本書を読んだ後で、なにかもう少し突っ込んだ議論が聞きたい人はぜひとも質問を投稿していただきたい。
ちなみに、一番苦労したのは、アプリをiTunesコネクトを使ってアップルに提出する部分。以前は、第三者のapp ID + Certificate + Profile での提出が可能だったのだが、ごく最近になって第三者のapp IDでの提出が不可能になったので、そこでつまずいてしまった。第三者を認めないとなると、Development CertificateのPrivate Keyのやり取りなどが必要となり、あまり賢いとは思えないのだが、そのあたりは「あまり考えずに厳しくしてしまった」というのが本当のところなんだろうが、それがアップルらしいといえばアップルらしい。