Previous month:
October 2010
Next month:
December 2010

neu.Notes for iPhone へのフィードバックに一気に返答してみる

前にもここに書いたが、iTunesストアへのコメントに答える方法が無いのがちょっと不便。読んでいただけるかどうかは分からないが、ここで返事をしてみる。今日は、neu.Notes for iPhoneへのフィードバック。

使いやすい♬♫ - ★★★

by Manako9 - Version 1.4 - 28 November 2010

すごくぃぃアプリ‼ カメラロールに保存できないのが残念 保存出来たら星五つにしたいぐらいです+.(○´∀`ノノ♬♫

ありがとうございます。カメラロールへの保存は1.5(現在、アップルによる審査中)で入ります。

Useful♪ - ★★★★★

by pinky1わん - Version 1.4 - 28 November 2010

操作性も良くてとっても使い易く、かゆい所に手が届くという感じです。 添付書類や写真のオーバーライトや、描いた物をメールで添付できたりするので、簡単なアニメーションを作ったりも出来ました。 もっと流行ってもおかしくないと思います。

私ももっともっと流行って欲しいと思いますが、ダウンロード数は順調に伸びています。一時的な流行ではなく、長く使っていただけるアプリにしたいと考えていますので、今後ともよろしくお願いします。

お願いです - ★★★

by mycoym - Version 1.4 - 23 November 2010

PDFにも書き込みたい。 画像も一気に複数取り込みたい。 ブックマークも付けられたら最高! 保存もフォルダ内のものを一括してアルバムか他のアプリにエクスポートしたい(goodreaderとか) 多分、そんな使い方は想定されてないと思うのですが、上記のことが出来たら有料でも絶対買います! 操作が快適だけに、ものすごく期待して待ってます。

PDFへの書込みは、ページ単位のものをCloudReadersとの連携でサポートしましたが、本格的なものは別のアプリ(neu.Annotate - 現在アップルによる審査中)でサポートしますので、試してみてください。他のアプリへのエクスポートの部分は少し考えさせてください。それから、有料オプションは現在開発中なので、その際はよろしくお願いします。

アルバム保存 - ★★★

by 疑問5 - Version 1.4 - 16 November 2010

すごく便利だけどアルバムに保存出来たらもっといいのになと思う

アルバム(カメラロール)への保存は1.5(現在、アップルによる審査中)で入ります。こういうフィードバックのおかげでアプリを進化させるべき方向が見えて来るので、とても助かります。

こういうの欲しかった - ★★★★★

by アルクカ - Version 1.4 - 28 October 2010

よくプリントの写真撮ってメールで送るということをやるのですが、そのときどこが重要か記すため、手描きでメモを付け足したいということがしばしばありました。 それに非常に適しているアプリだと思います。Twitterにも投稿できるそうなので、今度やってみたいです。 ただ、iPhoneでメールを飛ばすとき、softbankのメールアドレスを用いるので、"アルバムに保存する"というコマンドがあると良いなと感じました。

ありがとうございます。Twitterへの投稿もぜひとも試してみてください(#neunotesでサーチすると他のユーザーの作品を見る事ができます)。ちなみに、アルバム(カメラロール)への保存は1.5(現在、アップルによる審査中)で入りますのでよろしくお願いします。

よくできてる - ★★★★★

by mama- - Version 1.4 - 18 October 2010

Adobe ideasと同じ用途のソフトだが、以下の点で優れている。 •写真を好きな位置に配置でき、確定前なら大きさや角度も調整出来る。 •タグで管理できる。 •複数ページが作成できる。 •3種類のペンが設定でき、切り替えが楽。 iPhoneのメモ帳も無料でここまできたかという感じだが、単に文字を書くだけなら、メモ帳に書いて写真を取る方が実用的。ただし、写真を取り込んで気軽にコメントを書き込めるのはカメラを備えるiPhoneならではの快適 2010/10/19追記 なにかと便利なので今はホーム画面においてます。PDFで書き出したときも凄く綺麗!!なにより、二本指での移動と拡大が一番スムーズで、紙に描くのに近い感覚。(他のアプリは予想外の動きすることが多い)

ありがとうございます。紙とメモ帳にいつかは勝つようにがんばります。「二本指での移動と拡大のスムーズさ」にかけては有料アプリも含めてどのアプリにも負けないように作り込んだので、評価いただき光栄です。

最高です! - ★★★★★

by とみけー - Version 1.4 - 16 October 2010

使い方によっては写真の編集まで出来ます。 メモにはもってこいのアプリです。

これからまだまだ進化させる予定なので、よろしくお願いします。

すっごく便利です - ★★★★★

by あかりこ - Version 1.4 - 16 October 2010

ちょっとしたメモを書いたり、写真を貼って、メッセージを書いて友達に送ったりとか、とても便利に使ってます!!

ありがとうございます。どんどんお友達に送って、ユーザーを増やしてください。

試して損なしメモアプリ - ★★★★★

by magimagi - Version 1.4 - 08 October 2010

手書きメモアプリ難民の方は一度ぜひ。 UIもかなりいいです。 余計な機能無く必要なものは揃っていて、使いやすい。

この「余計な機能無く」という部分を評価いただき感謝しています。今後ともこの点だけは曲げないように進化させて行くのでよろしくお願いします。

GJ! - ★★★★★

by yuto tezuka - Version 1.4 - 29 September 2010

こうゆうん探してた! しかも無料! 最高やん(°∀°) customer-friendly application!

ありがとうございます。こういうコメントを読むと、とても元気がでます。

気に入った! - ★★★★★

by くろしろ - Version 1.4 - 29 September 2010

手書きアプリで色々試してみたけど、どれもこれも今イチだったけど このアプリはすごく気に入りました。 ありがとう!

どういたしまして!

これは良い - ★★★★★

by ryota2000 - Version 1.4 - 28 September 2010

非常に良く出来たソフト。説明がいらなく直感的に気軽に使えるのがいいです。若干、指の動きに描画がついてこない(もたつく)感がありますが、まぁ実用に問題ないです。 線の透過率変えられるのもいいです。地図とかの上にオーバーライトするときに重宝します。 無料かぁ。すごいなぁ。

Adobe Ideaのように「一度書いてからスムージングする」のと「描きながらスムージングする」のとどちらが良いかを色々と試した結果、今の「描きながらスムージングする」になっています。指の動きに描画が若干遅れて見えるのは、このスムージングのためです。オプションでオンオフにすることも技術的には可能ですが、オプションを増やすと使いにくくなるので、そのあたりのバランスが難しいところです。

素晴らしい◎ - ★★★★★

by kazun888 - Version 1.4 - 15 September 2010

これが無料でいいのでしょうか。 わかりやすく、使いやすい。 感謝です。

はい、このまま無料で走ります。近いうちに有料オプションを出す予定なので、その時はよろしく。

五つ星です - ★★★★★

by tobuen - Version 1.4 - 11 September 2010

良いアプリです。ありがとうございます!

五つ星、ありがとうございます。

いいんだけど - ★★★★

by えすぱー - Version 1.4 - 11 September 2010

作成したタグのリストは、変更又は削除出来ないのでしょうか? また、開いた画面を表示中うっかり手などが触れてしまうと、ダイレクトな形でとんでもないところに線が入力されてしまいますので、入力編集に関する「ON・OFF」機能が欲しいです。 って私の使い方が悪いのかな?? 誰か教えて!!

使わないタグはしばらくすると自動的に消えます。1.5から「描画をオフにするモード(「手のひら」アイコン)」を付けたのでお試しください(現在アップルによる審査中です)。

これは凄い - ★★★★★

by らいむ 2009 - Version 1.4 - 11 September 2010

手描きの有料のを以前買ったけど、それより遥かに素晴らしい。 有難いです。

ありがとうございます。

ダイレクト感が薄い - ★★

by tatsutanu - Version 1.4 - 04 September 2010

線の処理の分か遅れが感じられ、フィーリングがいまひとつです。 Adobe Ideasの方が好きです。

フィードバックありがとうございます。上にも書きましたが、Adobe Ideasのように一度「折れ線」で描いてから、あとでスムージングした方が好きというユーザーの方もいることは分かりますが、このトレード・オフは難しいところです。私も最初はAdobe Ideaの手法は面白いと感じていましたが、長く使っているとどうも好きになれなくて、描きながら同時にスムージングをかけるようにしてあります。このあたりは、皆さんのフィードバックを聞きながら微調整をして行きたいと思いますので、よろしくお願いします。

◇ ◇ ◇

また、これから投稿されるフィードバックにも必ず目を通すので、コメント・ご要望のある方はぜひとも、iTunesもしくはこのブログへのコメントをお願いする。特に気に入ってお使いいただている方には、とても励みになるので、iTunesストアでの4つ星なり5つ星をいただけるとありがたい。

ちなみに、iPad版のneu.Notesは初速でのダウンロード数は爆発的だったが、少し後に地味にリリースしたiPhone版がじりじりと追い上げ、今では日々のダウンロード数はiPhone版の方がはるかに多い。iPhoneの母数が多いというのもあるだろうが、「ちょっとしたメモを書く」「写真に何か書いて送る」などのユーザー・シナリオ的にはiPhone版の方がマッチしているのだと解釈している。

 

 


iPadアプリ開発日誌: ダウンロード数とランキングの関係

先日iPad向けにリリースした「加速する創作系マガジン『暫』」、とても好評で発売3日目には書籍部門で1位、4日目には総合で2位(瞬間風速では一時的に1位)という快挙。

「どのくらいダウンロードがあるとランキングの上位に食い込めるのか」という質問を良く受けるので、発売後8日間のダウンロード数と、(日本での)総合順位をグラフにしてみたのがこれ。

Graph

グラフの一番右下が初日の結果で(248ダウンロード/総合65位)、ダウンロード数が急速に伸びるとともに順位も上がり、4日目のピークで、2781ダウンロード/総合2位に達している。

アップルがどのくらいの期間のダウンロード数を目安にランキングを決めているかが不明なので、このグラフが100%正しいとは言えないが、大体の感覚はつかんでいただけると思う。重要なことは、このグラフが直線ではなく、大きくカーブしていること。

これは無料アプリのカーブだが、当然有料アプリも同じようなカーブを描く。「ランキングの上位に入れば儲かるが、そうでなければ開発費の回収もままならない」というアプリストアのRed Ocean状態を良く表している。

ところで、iTunesストアでのランキングは、国別のもの。上の数字は日本でのもので、母数がはるかに多い米国だとランキング上位に食い込むのに必要なダウンロード数もそれに比例して多い。

ちなみに、CloudReadersのダウンロード数を見ていると、中国でのダウンロード数が急激に増えており、日本や米国からのダウンロード数を超えている。それだけでも面白いのだが、もっと興味深いのはダウンロード数の割には総合ランキングが日本よりも低いこと。その数字だけを見る限り、「中国でのiPad販売数の方が日本より多い」ように見えるのだが、実際のところはどうなんだろうか。


加速する創作系マガジン「暫」

Default CloudReadersベースの電子書籍は既に何冊かiTunesストアに出ているが、高画質のマガジンはこの「」が初(iTunesストアへのリンク)。値段は無料。iPad専用。

ちゃんとしたフォーマット(ZIP化したJPEGファイル)で作ったマンガや雑誌をCloudReadersで読むとどのくらいサクサク読めるのかが実感できるので、ぜひともお試しいただきたい。

ちなみに、この雑誌に関しては、ホームページがあるので、興味のある方、作家として参加したい方、広告を出向したい方などはそちらへどうぞ。

電子書籍に関るアプローチは色々とあるが、その中でもあくまでクリエーターが主人公であるというアプローチがとてもユニークだと思う。その意味でも色々な可能性を持っていると思うので、ぜひとも応援をお願いしたい。


スパゲッティはオブジェクト指向の夢を見るか

雑誌 WEB-DB PRESSに連載中のコラムの記事がまた一つウェブで読める様になったので、紹介させていただく。

オブジェクト指向の本質

そもそも、単身赴任中の私が主に家族通信のために書いていたブログがこんな形のブログに変わったのは、何気なく書いた「日本語とオブジェクト指向」というエントリーがきっかけ。突然「はてなブックマーク」という不思議なサイトからのトラフィックが増え、「ブログを書く楽しさ」を教えてくれたエントリーだ。

いまさら「オブジェクト指向の本質」もなにもないとは思う人もいるだろうが、実際に現場で働いているエンジニアの中にも「オブジェクト指向プログラミング=クラスを使ってプログラムを書く事」と勘違いしている人もたくさんいるわけで、そんな人たちにぜひとも読んで欲しいと思って書いたエントリー。

そうは言っても、「粗結合」の大切さみたいなものは、何度も何度も(スパゲッティ・コードに)痛いめに合ってこそ「身につく」もので、こういう記事を読んだからと言って、すぐに実行できるほど簡単な話ではない。

ということで、今回はざっと目を通しておいていただいて、次にスパゲッティ・コードに悩まされた時に、「そう言えば、スパゲッティ・コードが出来る原因について書いた記事を読んだ覚えがあるな」と思い出していただけるだけで十分だと思う。


言語対決:JavaScript 対 Objective-C

ここのところ、サーバー側(Google App Engine)のコードはPythonで書き、クライアント側のコードはiPhone/iPad 向けはObjective-Cで、ブラウザー向けはJavaScriptで書く、という毎日が続いている私である。

それぞれの言語は難しくないのだが、さすがにこの3つを頻繁に行き来していると、pythonのコードに間違ってセミコロンを付けてしまったり、PythonとJavaScriptのどっちがTrueでどっちがtrueだか混乱したりする。

ちょうど昨日は、以前JavaScriptで書いたコード(写真をアップロードするコード)をObjective-Cに移植する機会があったのだが、とても分かりやすい結果が出たので、ここで比較してみる。

まずは元の JavaScript のコード。

            SNBinder.get("/blob/create_upload", {}, true, function(json) {

                SNBinder.get("/static/page_upload.htm", {}, false, function(htm) {
                    htm = SNBinder.bind(htm, { upload_url:json.upload_url });
                    $('#main').html(htm);
                    $('#form_upload').bind('submit', function() {
                        $('#wait_cursor').show();
                    });
                });
            });

SNBinderという自作のライブラリを使って、HTMLテンプレートのクライアント側でのバインディングを行っているのだが(このライブラリは希望者が多ければオープンソースにしても良いと考えている)、まずは "/blob/create_upload" というURLにHTTP GETを投げてアップロード用のURLを取得し(変数jsonの中に入ってくる)、"/static/page_upload.htm" という HTMLテンプレートをやはり HTTP GET で取得し、それを先に取得したURL( json.pload_url)と結合し(テンプレート中の文字列の置き換えをしているだけだ)、画面上に表示した上で、ユーザーがアップロードボタンを押したら、ページ中のGIFアニメをスタートする、というものだ。
すばらしいのは、HTTP-GETを2回と、HTTP-POSTを1回をすべて非同期でするという処理がわずか9行のコードで書けている事(そのうち3行は閉じカッコだけの行)。
全く同じことを Objective C で書くと、以下の様になる。これもやはり自作の、NBUploaderという汎用ライブラリを駆使して、できるだけ簡素に書こうとしている(ちなみに、エラー処理のコードは公平に比べるために除いてある)。ちなみに、ユーザーインターフェイスは、アプリそのものに含まれているのでその分のHTTP GETは節約できているし、NBUploaderがURLの取得とHTTP POSTの両方をしているので、アプリ側から見た非同期通信は1回だけである。にも関らず、この長さだ。

-(IBAction) pickPhoto:(UIButton*)btn {
    UIImagePickerController* picker = [[[UIImagePickerController alloc] init] autorelease];

    picker.delegate = self;
    picker.sourceType = UIImagePickerControllerSourceTypePhotoLibrary;
    [self.popover dismissPopoverAnimated:false];
    self.popover = [[[UIPopoverController alloc]
        initWithContentViewController:picker] autorelease];
 
    [self.popover presentPopoverFromRect:btn.bounds inView:btn 
            permittedArrowDirections:UIPopoverArrowDirectionAny animated:YES];
}
 
// <UIImagePickerControllerDelegate> method
- (void)imagePickerController:(UIImagePickerController *)picker  didFinishPickingMediaWithInfo:(NSDictionary *)info {
    viewImage.image = [info valueForKey:UIImagePickerControllerOriginalImage];
    [self.popover dismissPopoverAnimated:true];
}
 
-(IBAction) uploadPhoto:(UIButton*)sender {
    self.uploader = [NBUploader uploaderWithSession:sessionManager.session 
        data:UIImageJPEGRepresentation(viewImage.image, 0.8) type:@"image/jpeg" name:textField.text 
            description:textDesc.text uuid:textUUID.text];
 
    NSNotificationCenter* center = [NSNotificationCenter defaultCenter];
    [center addObserver:self selector:@selector(uploadComplete:) 
                name:[NBLoader didFinishLoadingNotification] object:self.uploader];
    [self.uploader connect];
    labelURL.text = @"uploading...";
}
 
-(void) uploadComplete:(NSNotification*) notification {
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

この差は大きい。どちらもプログラムを書く手間そのものはデバッグの時間を含めればそれほど大きな違いは無いのだが、私自身が数ヶ月後にこのコードを見た時に(もしくは他の人がコードを見た時に)、何をしているのかが一目瞭然と分かるのはJavaScriptの方だけだ。Objective Cの方は、少し腰を落ちつけてコードの解析をしなければ、非同期通信の流れが把握できない。これをもし、JavaScriptと同じように3回もの非同期通信をするコードをObjective Cで書いたら、それはそれは読みにくいコードになる。

こと非同期通信に関しては、JavaScriptの方が圧倒的にすぐれている、ということが分かっていただけるとと思う。何と言っても大きいのは無名関数で非同期通信のコールバックがその場に記述できてしまうこと。


google appengine に関してひと言

ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。

App Engine は純粋なソフトウェア・エンジニアにとっての天国

私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。

新しい言語を学ぶのが苦ならApp Engineは避けた方が良い

現時点で、PythonとJavaのみがサポートされているが、App EngineをやるならPythonがおすすめ。私もPythonはApp Engineが初めてだが、とても簡単な言語なのでそれほど苦労せずに使いこなせるようになる。「今さら新しい言語を勉強するのは辛い」とか「RubyかPHPが動くならApp Engineを試してみたい」と考えるような人はApp Engineには手を出さない方が良い。Pythonの習得を苦労しているようでは、Big Tableは使いこなせない(というか、そもそも新しい言語の習得を「楽しい」と感じないならば、ソフトウェア・エンジニアという職に向いていないと)。

フレームワークに頼るな

上に述べたように、App Engineの一番の魅力は、実行効率を直感的に意識してプログラミングできる(もしくは、それを強いられる)ことにある。なので、できるだけサードパーティのフレームワークや巨大なライブラリは避け、必要最低限のコードだけをGoogleが提供している最低限のフレームワーク上にサクッと作るべき。もし、Googleが提供しているフレームワークが難しいと感じたり、不十分と思うのであれば、App Engineは避けた方が良い。私自身、最初はいくつかサードパーティのフレームワークを試してみたが、すべてのソースコードを読まなければ気が済まないし、読むと気に入らないところがたくさん出て来る。で、結局は自分なりの最低限のライブラリ集を作ってそれを再利用してアプリを作る、というのが効率面でも品質面でも一番良いとの結論だ(gdispatchはその副産物)。

Data Modelはできるだけフラットに、かつシンプルに

このあたりが、RDBに慣れた人たちには一番取っ付きにくい部分かもしれないが、Big Table上でのData ModelはRDB上のものとは大きくことなることを理解すべき。私は現在、ファイルの共有サービスをApp Engineで作っているが、ModelはUserとBlobStoreの二つしかない。RDB上に作れば20個ぐらいのテーブルになりそうな複雑な処理をしているのだが、App Engine上ではたった二つである。「App Engine上ではJoinが出来ないから」という声を良く聞くが、そんな泣き事を言う前に、そもそもJoinが必要になるようなモデル設計(つまりBigtable向きでない設計)をしてしまっていないかを確認すべきである。

GQLはまやかしである

Googleは、App Engine上のQueryを記述するための言語としてGQLという言語を用意しているが、これはSQLに慣れた人に「App EngineにはGQLがあるから怖くない」と誤解させるための、まやかしである。本気でApp Engine上でプログラムを書くのであれば、GQLは使うべきではない。

Task Queueを使いこなせ

Big Tableの一つの大きな特徴は、ReadとWriteの非対称性である(Writeが何倍も遅い)。それゆえに、ループを回して連続でWriteをすのは得策ではない。そこで便利なのがTask Queue。Task Queueを活用したサーバー側での非同期プログラミングができるようになったあたりから、App Engine上でのプログラミングの自由度が大きく広がる。

テンプレートの処理はできるだけクライアントにさせろ

ガラケー向けのサイトでも作っているのならば仕方がないが、パソコン上のブラウザー向けのサービスを作っているのなら、テンプレート処理はクライアント側に処理させるのが得策。つまり、HTML/JS/CSSファイルに加え、HTMLのテンプレートファイルもすべてstaticファイルとしてクライアント側にダウンロードし、JavaScriptからApp EngineのModel APIを直接叩いてJSONの形で結果を受け取り、それをクライアント側でHTMLテンプレートと結合して表示する。つまり、Model/View/ControllerのModelをApp Engine上でPythonで書き、ViewはHTMLテンプレートも含めてすべてstaticファイルとして提供し、ControllerをJavaScriptで記述するのだ。こうすることにより、App Engine側での処理を極力軽くし、かつ、ユーザーにとっては見かけの待ち時間が少ないおもてなしを提供できる。

何と言っても「プログラミングに集中できる」のがApp Engineの醍醐味

そして、私にとってApp Engineの一番の魅力が、サーバーの台数を調整したり、ロードバランスをしたり、データベースのパーティションを気にしたりなどの「サーバーの構築・運営」などの雑務から解放されること。すでに、App Engine上で三つほどサービスを運営しているが、どれも一度走り出してしまえば基本的には「メンテナンス・フリー」になるところがすばらしい。何ヶ月か前にリリースしたTinyMsgも、発言する人や内容によって時々トラフィックが急増するのだが、そのあたりをキチンとハンドリングしてくれるのでとても助かる。

最大の欠点はGoogleにLock-inされてしまうこと

これに関してはあまり解説する必要もないとは思うが、App Engine上にサービスを作るということは、すなわち「Googleのインフラ上でサービスを提供することにコミットする」ことなることは覚悟して進めるべきである。「コンパチブルなオープンソースのプロジェクト」もあるにはあるが、それをサービスとしてGoogleほどの規模とコストで提供するところが現れるまでは(そう簡単には現れないと思うが)、Google が唯一の選択肢である。

 

長くなってしまったが、以上が私がApp Engineに関して感じていることのまとめだ。確かに「敷居は少々高い」が、一度その敷居を乗り越えてしまうと何とも心地よいプログラミング環境が整っているというのが実情である。その壁を乗り越えるのを「楽しい」と感じるのであれば、かつ、GoogleにLock-inされても良いと考えるのであれば、App Engineはとても良い選択肢だと思う。

 


Covia、世界初のkoukouTV搭載地デジチューナー発売

Koukoutv

iPad版のkoukouTVの紹介の際に、「本当の狙いはテレビ、セットトップボックス、車載機メーカーへのOEMビジネス」と書いたが、その第一弾がこれ。詳しくは、Coviaの製品ページを見ていただくのが一番良いと思うが、例の「実家に孫(の写真)を贈ろう」というコンセプトの元に作られたkoukouTVを搭載した地デジチューナーだ。

ちなみに、私がUIEvolutionを設立したのはちょうど10年前。「これからは携帯電話に限らず、テレビ・カーナビ・冷蔵庫のドア・クレジットカードなどがネットに常時接続する時代になる。そんな時代に向けたソフトウェアとサービスを提供する会社」というビジョンで作った会社だが、10年たった今でもようやくテレビとカーナビがネットに接続しはじめたばかりだ。冷蔵庫のドアやクレジットカードが常時接続しはじめるまでまだまだやることがありそうだ。

ということで、koukouTVのOEMライセンスは、テレビやカーナビに限った話ではなく、もちろん冷蔵庫のドアにも喜んで提供するので、そこのところよろしく(OEMビジネスに関しては、こちらを参照していただきたい)。


またまたお世話になってしまったアップルストアのGenius Bar

Geniusbar_graphic2_20091218 先日、日本から帰国する際に、持って行った Mac Book 二台のうち一台を間違ってボストンバッグ(それもソフトタイプ)の外ポケットに突っ込んだままチェック・インしてしまうという失敗をしてしまった。一度荷物室に積み込まれてしまってのだが、飛行機に乗り込んだ後ですぐに回収をし、かろうじて破損は免れたのだが、その後1週間ほどで充電が不可能になってしまった。

しかたがないので、近所のアップル・ストアのGenius Barに持って行くと、保証期間だということで無償で修理してくれることになった。「水没とかしていた場合、保証がきかなくなりますが」というジニアス・バーの店員に「水没はしていません」と強調してしまった私。「ボストンバッグに入れたままチェックインとかしていませんよね」と聞かれれば正直に答えたのに...^^;

ちなみに、最近は iPhone や iPad ばかり注目されているが、それと同時に MacBook を持つユーザーが回りに増えたというのがここ(シアトル)での実感。そのシェア拡大に大きな役割を果たしているのがこのGenius Barである。

まず何と言ってもすばらしいのは、「ネットで予約が出来る上に、保証期間でなくても、その場で直せるものはすぐに直してくれる」点。「買った時のレシートとか、保証書の提示」とかも全く不要なのも良い。以前も、保証期間が過ぎた古いMacBookにOS-Xの再インストールをしてもらったことがあるのだが(無償で、それも10分ぐらいで)、そのレベルのサービスを提供してくれるところは他にない。

もう一つすばらしいのは、保証期間内のiPhoneとかiPadにハード的な問題が出た場合、(水没でないかぎり)その場で無償で全交換してくれること。先日も、Apple TVのビデオ出力に妙なノイズが出るので持って行ったところ、その場でサクッと交換してくれた(ノイズの原因は、実はApple TVとテレビの間のレシーバーにあったことが後で判明したのだが、いまさら「この前のノイズの件は私の勘違いでした」とは持って返っても逆に迷惑だろうからそのままにしてある)。

当初は誰もが「いまさら小売店を持つなんて」と否定的に見ていたアップル・ストア、ゆっくりとだが着実に「アップル・ファン」の数を増やすことに貢献していることは今や誰も否定できない。

ちなみに、私のなじみのアップル・ストアのすぐ近所に、まもなくマイクロソフト・ストアがオープンする。単なるショー・ルームではなく、Genius Barに匹敵するようなサービスを提供してくれるのか、楽しみである。3年前に買って放置してあるToshibaのノートパソコンを持って行って、「ハードディスクを一度まっさらにして、Windows XPを再インストールしてくれない?ディスクも保証書もなくしちゃったけど」と頼んだらやってくれるだろうか?