iTunesのデザインに見るAppleの狙い

by tanabe on September 29, 2005

iTunesは非常によくできたアプリケーションだ。その使い心地はすばらしく、iPod、iTunes Music Storeの成功もiTunesという優れたソフトがあってのことだ、という意見も多く見られる。

たしかにiTunesというアプリケーションはオンライン楽曲配信におけるAppleの戦略を体現していると思う。そのコンセプトは、「ストレスフリーに聴く・イイ!・買う」を実現することだ。

店舗での販売などでも言われることだが、購買客には二種類のパターンがある。目的のものを買う人と目的ではなかったものを買う人だ。Appleがターゲットにしたのは、まさにこの目的ではなかったものを買う人である。

目的を持って品物を買いに来る人をターゲットにすると、すでにあるパイの奪い合いになる。だから、iTunesに来る人には目的ではなかったもの、知らなかったすばらしい音楽との出会いを提供し、パイを大きくしようというのが基本にある。

このパイを大きくするためには、『音楽を聴く→良いと感じる→買う』という流れをいかにストレスを感じない形で実現できるかがキーとなる。

この視点でiTunesを見てみると、iTunesやiTMS(iTunes Music Store)のあの形態が計算されて狙いどおりにデザインされているのが分かってくる。

ストレスフリーに『音楽を聴く』

まずは、『音楽を聴く』だ。これはプレイヤーとしての能力も当然だが、それ以上に試聴機として優れているか、が問題になっている。iTMSを見て回っていて、「おっ」と気にかかったものはストレスなくすぐに聴いてみることができるか、ということだ。ここにこそ、iTMSがあえてiTunesにビルトインされている理由があると思っている。iTunesにiTMSがビルトインされているということは、つまりiTMSを見て回っているときはプレイヤーが常駐で起動していることを保証してくれるのだ。

これは他の楽曲配信サイトと比べてみるとそのストレスの違いに気づくと思う。

楽曲配信サイトを見て回る。気に入った曲がある。試聴をダウンロードする。・・・。プレイヤーを起動。・・・。・・・。・・・。起動中。・・・。・・・。起動。音楽がかかる。

やっと曲が聴けるころには、最初に曲を見て惹かれた興味がやや冷めていることに気付く。

iTMSでも試聴するファイルをダウンロードする時間は避けられない。しかし、ローカルでプレイヤーが起動し音楽がかかるまでのタイムラグが体感上発生しないため、感じるストレスははるかに低い。

iTunes and iTMSでもよかったはずだ。むしろアクセサビリティを追求するのならば、ブラウザ単体で誰でもアクセス&購入できるサイト形式の方がメリットはある。

しかし、あえてiTunes with iTMSにしたのは、この狙いが明確にあったからだと思っている。

ストレスフリーに『良いと感じる』

この点に関しては「良いと感じさせる」ための工夫というのはあまり見当たらない。

その代わりに「良いと感じるものに出会う」ための工夫に力が注がれている。

この工夫は、iTunesの中の小窓を見てもらえればいくつも散りばめられている。試聴をしたりアルバムの曲目を見たりすると、小窓には関連した情報がパッと表示される。Amazonなどでおなじみの手法で目新しさはないが、ついつい興味を惹かれクリックしてしまう。

また、iTMSオンリーで提供されるオリジナル楽曲があるというのもとても魅力的だ。このオリジナル楽曲を目当てに訪れた人が、そこへたどり着いた後もついつい興味のある曲を探ってふらふらしてしまうだろうことは想像に難くない。

そして気になった曲を試聴する際には、その曲の魅力を損なわない程度に良好な音質でサンプルが提供されている。(他のサイトでビットレートを落としたサンプルを置いているところもあるが、これはむしろ逆効果だと思う。どんなに魅力的な曲もすかすかの音を聴かされると買う気が失せてしまう)

ストレスフリーに『買う』

最後、ショップとしては買ってもらわなければ仕方ない。この部分でもストレスを軽減するつくりで、自然な流れでどんどん曲を購入できる作りになっている。

Amazonのワンクリック購入のような作りで気に入った曲はその場ですぐにダウンロードして聴くことができる。面倒な入力は初回にまとめられ、二回目以降は非常に簡単な手順でダウンロード可能だ。

これも別に技術的に目新しくはない。しかし、非常に実用的で快適だ。

今後の音楽配信サービスはAppleとは別の新しいコンセプトが要求される

当然、Appleの音楽配信に関する戦略はこれだけではない。iPodシリーズを始めとして、音楽配信の周りにいくつもの魅力的なアイテムをそろえている。

そして、その中で中核を担うであろうiTunesとiTMSのデザインというのは本当によく練られていて、一貫したコンセプトから生まれている。技術や一つ一つのアイデアは数年前からあったものが大半だし、誰にもできないようなとんでもないものを作り上げたわけではないと思う。

ただ、一つのコンセプトの基に本当に必要で効果的なツールだけを組み合わせてデザインされている。思いつきで生まれたグッドツールではなく、周到に用意されたアプリケーションであり、稀に見る戦略的なアプリケーションだと思う。

これでAppleは一つのハードルを作った。後進の音楽配信事業者がAppleと競争するためには、もう価格を\50にするとか無料にする、あるいは月額固定にするというような小手先の打ち手ではAppleの脅威になることはできないだろう。彼らはAppleとは違う価値を音楽配信事業で提供しなければならなくなったのだ。

このAppleの打ち出したコンセプトは非常にシンプルだ。でも、実はなかなかこれを越えるコンセプトを見つけるのは骨だと思う。なんせ、この「気になった曲があったら試聴して、パッと買う」という流れはまさにTower Recordsで2時間も3時間も過ごした挙句、1万も2万もCDを買っちゃうような音楽中毒者の行動パターンなんだから。

  

blogに期待するもの

by tanabe on September 26, 2005

codemaniaxさんのところで読んだ「blogの信頼性」 についてちょっとだけ。

「二次情報のコピペの集積に過ぎない『blog』は本当に信頼できるのか?」

情報が増えれば確実性が増すというわけではない。

以前おいらも書いた通り、「趣味的」で「自分に都合のいい情報」を羅列されているに過ぎない。

一緒にメシ食ってる目の前の人の言うことすら信用できるかどうか分からないのに、どこの誰かも分からない人間の情報をなぜ信用できるというのか?

ブログから得るのは情報というよりは、考え方かなぁ。

考え方を自分の持ってる情報で検証して、納得すれば受け入れる。自分が情報を持っていないものは鵜呑みにしない。新しい情報があったら、ソースあたったりそのものを確認したりで第一報としては使ってる。

信頼をしているとは言えないけど、信頼してないからと言って価値がないわけではなくてやっぱり不可欠なんだよね。ま、その辺はやっぱりブログ書いているcodemaniaxさんも同じなのだろうけど。

  

オブジェクト指向で継承は使うべきではない?

by tanabe on September 26, 2005

DB Magazine 10月号(古!)の『柔軟なシステムを作成するためのC♯によるオブジェクト指向開発の実践』という記事で、少し気になる記述があったので、ちと書いてみます。

「なお、継承は、ポリモーフィズム(多態性)を利用するときのみ使用するのが基本となっている。」
「オブジェクト指向による設計では、既存クラスを継承することはあまりない。」

ということで、たしかにJavaやC#によるプログラミングでは委譲によって実装の再利用を行うことが定石となっています。継承はポリモーフィズムのための手段でしかないのかもしれません。記事はC#に関するもので、その意味では問題視するほどの記述ではありません。ただ、これだけ言い切られてしまうと、オブジェクト指向入門的な内容とも相まって誤解する人が増えるのでは、と気になりました。

本当に「継承は悪で、委譲は正義」なのか?

これは言語の制約によるものです。ここで本来やりたいことは実装の継承です。
言語が十分に実装の継承を生かす仕組みを用意できなかったので、仕方なくプログラマが実装の継承を模した形で「委譲」という方法を取っているだけなのです。

問題は、「実装の継承は危険だ」ということではなくて、「安全な実装の継承の仕組みが言語からサポートされていない」ということです。

「仕様の継承」と「実装の継承」

継承には二つの考え方があり、仕様の継承と実装の継承があります。そして実装の継承の強力さを十分に生かすには、多重継承ができることは本来望ましいのです。

JavaやC#では仕様の継承を重視し、それをinterfaceという概念で表しました。複数interfaceの継承を許すことで、仕様の継承(関係の表現)としては柔軟性を残しました。一方で、実装の継承は継承関係の複雑化やダイアモンド継承のような危険を避けるために、単純継承のみに制限をしています。

C++では実装の継承において多重継承を許し、リスクを享受しました。一方で仕様の継承を表現するために「public virtualで中身のない(=0)関数」というinterface相当の宣言を生み出しました。

C++の問題は明らかです。多重継承によって発生するリスクがフォローされていないことです。またJava, C#での問題は、リスクを抑える代償として実装の継承の持つ強力さがスポイルされていることです。

Mix-inという考え方

この多重継承の問題を解決する一つの方法として、Mix-inというものがあります。

Mix-inは、多重継承の一つの使い方です。多重継承に制限をかけ、機能は生かしつつ、安全性を高めようというものです。

日経Linux 2005年7月号の連載「まつもと直伝プログラミングのオキテ 第3回 多重継承の光と影」からMix-inの解説を抜粋します。

Mix-inというのは元々Lisp界で始まった多重継承の使い方です。Mix-in手法には次の2つの条件があります。

  • 通常の継承は単一継承に限る
  • 2つめ以降の継承は,Mix-inと呼ばれる抽象クラスからに限定する

Mix-inクラスは以下のような特徴を備えた抽象クラスです。

  • 単独でインスタンスを作らない
  • 通常のクラスから継承しない

これらの規則に従うことで,クラス階層は単一継承と同じ木構成になりますし,機能の共有を実現するには,共有する機能だけを持つMix-inをクラス階層木に「差し込む」ことで達成できます。

このMix-inを使うと、継承関係がすっきりとします。ただし、スーパークラスとの属性(メソッド名など)の衝突は課題として残ります。それでも、安全性と強力さのトレードオフを考えると、非常に魅力的な手法です。

Java, C#では活用できませんが、C++ではやり方次第で実現できます。また、Rubyでは言語仕様としてMix-inをサポートしており、そのパワフルさが言語標準のAPIでもフル活用されています。

継承はけして悪いものではありません。ただ、使い方に注意をしてメリットを十分に生かし、危険は少しでもコントロールしてやる必要があるだけです。

・・・と、Ruby界隈で見かけた継承に関する話をまとめてみました。自分メモにも使えるし。おかしなところがあれば、バシバシ突っ込んで頂けると理解を深めることができるので助かります。(元ネタは社内で回覧しているDB Magazineの記事紹介。一部内容を修正。)

  

Pathnameでmkdir_p

by tanabe on September 19, 2005

RubyのPathnameクラスはとても便利だ。でも、mkdirメソッドでは親ディレクトリが不完全な状態だとパスを補完してディレクトリ作成をしてくれない。

ということで、こんなのを書いてみた。

class Pathname
  def mkdir_p(*args)
    require 'fileutils'
    FileUtils.mkdir_p(@path, *args)
  end
  alias mkpath    mkdir_p
  alias makedirs  mkdir_p
end

直後に、既存でmkpathメソッドがあることに気付いた。ははは・・・

  

Marc Benioffが作るビジネスアプリケーションのiTunes Music Storeとは?

by tanabe on September 14, 2005

Marc BenioffのSalesforce.comがまた何か新しく面白いことを始めようとしているらしい。

CNET News.comの記事、"Salesforce.com to launch software marketplace"から。
http://news.com.com/Salesforce.com+to+launch+software+marketplace/2100-1012_3-5861423.html

Salesforce discussed plans Monday to launch an online marketplace for business applications.

Salesforce.comがオンラインのビジネスアプリケーション市場・AppExchangeを開始するとのこと。

それが、ただのパッケージ販売では面白くないのだが、

Any software developer or Salesforce customer can sell programs or give them away through the store. Salesforce will encourage developers to make their programs available "on demand," via Salesforce's hosted computing platform.

アプリケーションを売ったり、配布したりするのは誰でもOKで、そのためのアプリケーション基盤はSalesforceが用意する。なので、アプリケーションを作る人はオンデマンドでアプリを公開できるそうだ。

"What if there was an eBay of applications, where companies could buy and sell software, running on our platform?" Benioff asked during a keynote speech here at a Salesforce convention. "What if there was an iTunes Music Store of online applications?"

BenioffはこれをビジネスアプリケーションのeBayやiTunes Music Storeになぞらえている。

以前レポートしたsalesforce.comのフォーラム・Summer '05で、Marc BenioffがSummer '05のバージョンアップでSalesforce.comはThe Long Tailを吸収するサービスとなると言っていた。

「ビジネスアプリケーションには様々な要求があり、それらがロングテールを形成している。Salesforce.comはsforceとmultiforceによる柔軟なアプリケーション提供方式を準備することで、このロングテールを一々拾い上げられるようになる。」という主旨の話だった。

この時は、sforceとmultiforceはたしかに強力だけど、それでもロングテールを拾い上げられる要素としては弱く、たんに日本でフォーラムを開くリップサービスとしてアメリカの流行り言葉をスピーチに織り込んだだけだと思っていた。

しかし、どうやらMarc Benioffは本気だったようだ。このAppExchangeはまさに彼が言ったロングテールを拾い上げるための仕組みだろう。アプリケーション開発者へのインセンティブも用意されるだろうし、十分に魅力的な試みだ。今後の動向を期待して見守りたい。

(関連記事)
Salesforce.com Summer '05のMarc Benioffスピーチに関するエントリ

  

HOLIDAY INN BLACK 9.11 EBISU

by tanabe on September 12, 2005

a314f974.jpg最高でした。曽我部恵一がアンコール前にやってた曲はなんだろ?あれ、めちゃくちゃ好き。名曲すぎ!  

エビス

by tanabe on September 11, 2005

9e09d7e7.jpg川ができてる!  

小泉メソッド(またはほりえもんメソッド)

by tanabe on September 03, 2005

本質的でない部分で二極化された対決劇を作り出して、状況が自分に有利に働くよう仕掛ける小泉メソッド(ほりえもんメソッド)というエントリを書こうかと思ったけど、まったく自分が興味を持てないことがわかったのでだらだらエントリに仕上げてスルーしておく。

  

ソフトウェアは携帯のカメラのように部品産業化する?

by tanabe on September 01, 2005

Bloglinesやdel.icio.usをウェブサービス経由でデータサーバーとして使ったり、Railsのような形でソフトウェア開発にもチープレボリューションの波がやってきたり、というのを見ていると、もしかしてソフトウェアには部品化の波が来ているのかもしれない、とか考えている。ソフトウェア設計でいうような部品化というよりも、文字通りパーツとしての部品化。

携帯電話にカメラが組み込まれるようになって、カメラ産業という産業がカメラという部品を提供する産業へとルールが変わったように、ソフトウェアも部品化されることで何か変化するルールがあるんじゃないだろうか。

del.icio.usもBloglinesもASP事業だと思って競争していたのが、実は部品産業の中で争うようになる。そうすると、部品を統合して有意味な製品化するところがきっと出てくる。

そうなったときに、現在のような広告による収益モデルはルールを変えざるを得ないだろう。そして、きっと何か新しい世界にあった収益モデルが出てくるに違いない。それがGoogleから出てくるか、MSから出てくるか、それとも今は誰もしらない誰かさんが次代のGoogleになるのか。

部品産業のBloglinesやdel.icio.usの競争力は、使いやすい部品であることと使う価値のある部品であることだろう。つまり、いかに価値のあるデータを自分に集めるか、そしていかに他者が使いやすいインターフェースを公開するか。Web上でスケールさせられないデータは無価値になるんじゃないか?

なんてことをぼんやりと妄想してみたりした。

ちなみに妄想の種になったのは、「Bloglines を Gmail で読む」だったり、「del.icio.usをスムーズに検索するdel.icio.us direc.tor」だったり、「XMLはメタデータというより生データとしての利用価値が高まりつつあり、AjaxによるUIの切り離しがそれを加速する」だったり。