ザカードクラウド第二弾

よく知られている、起業家が投資家にプレゼンする時の心得にこういうのがあります。

製品やサービスの話はするな。マーケットの話をしろ。そうしたら投資家は興味を持ち、逆に「それで、どういう製品なのか?」と聞くはずだ。

一旦マーケットさえ見えてしまえば、その規模や成長率を検討し、あとはそこにあるニーズをどう満たすか(製品やサービスの本質)、という話に落とす事ができます。

さらに、そのマーケットでConsumer Webのてこ(成功するウェブ起業に共通している、広告/セールスが不要=ユーザー獲得コストが限りなく低い)が効くなら、既存のライバル企業に勝てるチャンスがぐっと増します。

この視点で見た時、特に日本で面白いマーケットの一つに、セールスが幅を利かせている(広告やセールスにコストがかかる=高い)中小企業向けのパッケージソフトのマーケットがあります。そして中でも顧客管理というのは、企業活動に必要不可欠なソフトで、今でも全く衰えない需要があります。

今回ザカードクラウドで参入しようと考えたのは、この顧客管理のマーケット。条件は、Consumer Webのてこを効かせる事。つまり、セールスや広告は行わない。

ところがこれが難しい。昨今のSalesforceの日本での輝かしい成功でさえ、とある事務機器の営業部隊の力だったといいますからね。

さて、ザカードクラウド第一弾はどうだったか?

登録ユーザー数の増加
8月 +70(40日分、プレスリリースあり)
9月 +50
10月+80

正直なところ、クラウドでデータベースを使おうというユーザーがどういう方々なのか絞りきれず、それでいて既存の顧客管理やデータベースが持っている機能は非常に多く、そもそもどれぐらいの性能で信頼性のあるシステムがクラウド上で作れるかが見えなかったため、非常にシンプルな機能にまとめ、どういう方々がどういう風に使おうとするか(そもそも使われるのか)フィードバックをもらうのが第一弾の目的でした。

そういう状態でありながら、安定して登録ユーザー数が伸び(衰えず)、むしろ伸び率が伸びているという事実、さらにはたくさんのフィードバックを頂けたのは、非常に良いサインであり、このチャンスに第二弾開発をすることにしました。

主な変更は以下の通りです。

OutlookiTunesのような、ナビゲーション(データベース)、一覧、フォームが一体となったレイアウトの採用
・より多くのブラウザ、そしてモバイルへの対応
・インポート/エキスポート
*現在のデータは引き続き利用可能
*複雑な機能は対象データをエキスポートして実行してもらうことで、本体はシンプルに
*移植性と開発効率を重視し、CappuccinoからSenchaへフレームワーク変更


それでは引き続き、よろしくお願いします。

ザカードクラウド

しばらくぶらぶらしていましたが、昨日私がプロデュースするデータベースがリリースされましたので報告させていただきます。

フリーウェイ、無料のカード型クラウドデータベースを発表 (japan.internet.com)

データベース名は「ザカードクラウド」。12年以上前からお世話になっている社長の経営するフリーウェイジャパンから提供されています。


一度はやらなければと思っていたのですが、誰でも直感的に使えるデータベース、というものを、クラウドという技術によってインフラが大きく変化しているこの時期に、いちからデザインしてみました。

スクリーンショットはこんな感じです。

技術的には、Google App Engineのデータストア(BigTableとprotocol bufferをベースに作られている)でインフラを、Objective-JのCappuccinoでクライアント部分を開発しました。この先は技術的な話に触れて行きますので、そんなことに興味はないという方は、こちらから実際に触ってみてください。ブラウザはGoogle ChromeまたはアップルのSafari、ログインするにはGoogleのアカウントが必要です。

ザカードクラウドのアプリへ



元々このアイデアは、パソコン黎明期にアスキーサムシンググッドという会社から提供されて人気を博していたザカード、というデスクトップソフトウェアをクラウド上で使えたらいいな、というニーズからスタートしました。ザカードというのは、今ではファイルメーカーぐらいしか無くなってしまったカード型データベースに分類されるもので、図書館の貸し出しカードのようなカードで、データを管理するシステムのことです。技術的にはリレーショナルデータベースというものに圧倒されて完全に隅においやられてしまいましたが、その分かりやすさと操作のしやすさから、今でも根強いファンがいるのがカード型データベースであり、その日本製の代表格がザカードという製品だったわけです。

そのザカードの良さをできるだけ残しつつ、クラウドという環境に今使える技術を考慮し、設計したのがザカードクラウドになります。特に注意したのは、ブラウザで提供するという決定から、ホームページの延長のようなウェブアプリケーションではなく、きちんとデスクトップ製品の競合と認識されるレベルのものを作ろうという事でした。これには以下のようなチャレンジがありました。

  1. 非同期/分散が特徴のクラウドデータベースでどうやって確実なデータ操作を実現するか
  2. デスクトップ級の複雑なコードをJavascriptでどうやって書くか(かつスピーディーに改善していくか)


非同期/分散が特徴のクラウドデータベースでどうやって確実なデータ操作を実現するか

例えばデスクトップのアプリケーションを開発しようとする場合、ファイルシステムがOSから提供され、ファイルシステムの操作が開発環境から提供されるので、基本的にはアプリケーション自体に専念することができます(あなたがOSをいじっている奇特な技術者で無い場合)。ところがブラウザではどうでしょうか?HTML5でローカルディスクへのアクセスができるようになったとはいえ、サイズの問題に、何より共有の問題があります。そう、唯一できるのはHTTPプロトコルでサーバーにアクセスすることだけです。

これはいってみればハードディスクへのデバイスドライバを書いているようなもので、信頼できるフレームワークファイルシステム)を構築することなしに、一定以上の複雑なシステムをその上に構築することはできないと考えました(私一人では)。インフラが慣れ親しみ、四角四面のリレーショナルベースだったらまだ多少の救いはありましたが、なんでも受け入れてくれるNoSQLのBigTable。リレーショナルではそもそもコストに見合うものが作れない。

そこでまず考えたのは、どういうデータをどう扱うか、それを定義し管理する役割の層を作ろうということでした。参考にしたのはMacの開発環境であるCocoaのCoreDataフレームワークでした。EntityDescriptionにデータが定義され、各EntityのインスタンスはManaged ObjectとしてContextの中でidentityを与えられ管理される。これは非常に良さそうに思え、そっくりObjective-Jに移植する作業から開始してみました。データストアへのアクセス部分を管理するCoordinatorは簡略化しましたが、当初これはなかなかうまくいきました。

うまくいかないことが分かったのはそれから一ヶ月程経ってからのことで、事前にEntityDescriptionを定義しなければ使えないということでした。当たり前と言えば当たり前なのですが、今回作ろうとしているのはザカード。ユーザーが自由に項目は定義できるようでなければならないのです。具体的に問題だったのは、どこのサーバーにどうアクセスしたらよいかでさえ、事前に定義するのではなく、Entityに処理させるようにできないと、フレームワーク化できない点でした。

そこで、ManagedObjectModelをブートストラップとすることにし、そこに含まれるEntityDescriptionから必要なデータのロードを行い初期化することにしました。後はユーザーの操作に応じてEntityDescriptionが解釈してサーバーにアクセスする指示を行います。

こうしてようやく何か確かなものが、あらゆるものが定義可能(何も決まっていない)な世界に登場しました。ファイルシステムが出来上がった感じです。


ところがこれでもまだまだ。ようやく土俵に上がったところです。ここからはいよいよ非同期/分散のデータベースを確実に処理できるようにしなくてはなりません。

Google App Engineのデータストアはkey/valueのデータベースで、isolationはserializable/read committed、コミットはログベースで開始と完了の同期操作(ログは非同期で世界中のどこかのGoogleのサーバーに並列に書き込まれます)、ancestorとnamespaceによる空間があるのが特徴です。実際必要なものは全部揃っていて、後はこれらをどう設計し、使えるようにするか、そこが実際のチャレンジでした。

このデータベースについて分かりやすく言うと、同じグループ(ancestorでつながっている)にあるものはserializableに処理され、そうでないものはread committedになります。つまり同じグループであれば同期的に処理されるので整合性のないデータを見る事はないが、その分グループが大きくなると全体が同期処理されるので性能が出ないという問題に直面します。

この、整合性を維持しながら性能を出すには、やっぱり大部分はread committedにせざるを得ません。幸い今年の春に、更新の度に増加するversionがサポートされましたので、トランザクションの中で操作を行い、versionを常に確認しながらデータ処理を行えば、上書きを防ぐことができます。

〜ちなみにGoogleのデータストアではデータの取得コストは1。つまり保有するデータ数に依存しません。すごいと思いませんか??(ただし検索のページ送りなどのオフセットはその分のコストもちゃんと計算されますので要注意。代わりにcursorを使うことが可能です)〜

チャレンジは、こうした上書きを含め、以下に示すようないろんなデータの状態を正しく管理することでした。

・サーバーから読み込まれたままの状態
・サーバーから読み込まれてクライアントで更新された状態
・サーバーから読み込まれてクライアントで削除された状態
・以上のケースで、他のユーザーによって既に更新されてしまった状態
・クライアントで追加された状態

結局これらの管理は全てcontextが行うことにしました。容易に想像できるように、これらを確実に管理するには高度なデータバインディングが必要だろうということです。Cappuccinoを採用した一番の理由はここにあります。CappuccinoはObjective-Jですが、Objective-Jはjavascriptのスーパーセットなので、javascriptでもあります。つまり、これはManagedObjectのコードの一部ですが、javascriptとObjective-Jを同時に使うことができます。

- (void)setValue:(id)aValue forKey:(CPString)aKey
{
    // avoid implicit conversion
    if ([self valueForKey:aKey] === aValue)
        return;

    if (_changeAware)
    {
        [[_description managedObjectContext] setChange:self forEntity:[_description name]];

        [self willChangeValueForKey:aKey];
        if (!_modified)
            _modified = {};
        _modified[aKey] = aValue;
        [self didChangeValueForKey:aKey];
    }
    else
    {

        if ([self isNew])
            _original = {};

        // update _original
        _original[aKey] = aValue;
    }
}

Cocoaに詳しい人はお気づきだと思いますが、このコードはKVC/KVO対応であり、javascriptに詳しい人は、javascriptjavascript objectのプロパティ操作をしていることが分かると思います。

Javaに長く携わってきた経験より、JavaかCかと言った議論ではなく、必要に応じてJavaとCの両方というのが現場には必要だと痛感しており、Objective-Jとブラウザのネイティブ言語であるjavascriptを同時に使えるObjective-Jはこうした点で非常に強力であり、これを使う事でチャレンジを克服することができました。


デスクトップ級の複雑なコードをJavascriptでどうやって書くか(かつスピーディーに改善していくか)

さて、これについてはもうすでに話が出ましたが、Cappuccinoという解決策を選びました。もちろんこれ自体もチャレンジであるわけで、もし他に確実な解決策があるならそれを選択しますが、まだそういうものがない以上、解決策自体がチャレンジだったのもやむを得ませんでした。

当初気にしたのは以下の点でした。

  • デバッグできるか
  • パフォーマンスチューニングできるか(プロファイリングできるか)

至極当然な話ですが、javascriptの世界では大変です。ほとんどの関数はanonymousで誰が誰だか分かりません。Cappuccinoではこんな感じでデバッグできます。

ご覧のように実際のコードがほとんどそのまま残されて読めるようになっています。実はこのためにザカードクラウドSafari/ChromeWebKitブラウザに限定しています(Cappuccino自体はInternet ExplorerでもFirefoxでも大丈夫)。

パフォーマンスチューニングも特定の部分に限定してプロファイリングさせることができるので、かなり正確に数字が取れます。ただチューニングが本当に試されるのはもう少し先だと思いますが。



最後に、面白いと思ったらCappuccinoを使ってみてださい。私はCappuccinoのreviewerでissueをチェックしていますので、issueやグループへの質問にはいつも目を通しています。もし英語が不慣れであれば日本語でもどうぞ。

本を作る

「クリフォードブラウンが好き」そういうと決まって聞き返された「じゃトランペットやってるの?」を思い出す。この、”趣味は音楽鑑賞”と双璧をなすのが”趣味は読書”であるが、「本が好き」と言って「じゃ書いてるの?」と言われる事はまずないだろう。ましてや「じゃ作ってるの?」と言われる事はない。

読書にまつわる誤解を私なりにここで一つ解いておこうと思うのだが、あなたは本を買うとき、1,700円のハードカバーの新宿鮫を買うとき、それはコンテンツを買っているのではなく、紙とそこに印刷されたインクのパターン、それらが綴じられた束、そして全体を覆うカバー、そういう物理的な本を買っているのだ。うそだと思ったらその横にある本を取ってみて、値段を見てみたらいい。1,900円?コンテンツはくだらない?そう、でも紙がいい。村上春樹の「象の消滅」のあの黄色い本と似た肌触りのいい紙だ。そうして見ると、本の物理的な量と質で値段が決まっている事に気がつくだろう。そう。あなたは「紙」を買っている。つまり読書とは、本との戯れなのだ。

まず読書をそのように再定義した上で考えてみると、明和電機の社長が「自分のブログを手作りで本にしてみた」の中で、次のようなことを言っていることがますますよくわかる。

持ってみると、さすがに一年分の記憶は重い!これはパソコンの画面では体験できない充実感ですな。紙の本の長所は、やっぱり情報を重さで体験できることです。そしてそれは安心とか、満足とか、自信とかを与えてくれる。単純なことだけど、大切なこと。

本棚に並べてみれば、こういう言葉がもれる。

できた本を本棚に並べてみた。なんたる充実感!!みなさんもお試しあれ!!

私も繰り返しましょう。”みなさんもお試しあれ”と。そしてひとたび経験したら、「じゃ作ってるの?」と、趣味は読書の方に聞き返す自分を発見するでしょう。

近い将来、地元のブロガー本と出会い、戯れることのできる場所が生まれることでしょう。かつてそこは、図書館、と呼ばれていた場所として。

本を作る

彼女の誕生日の贈り物にと、彼女の大好きなブログ「まあるいはあと」を本にしてみました。いつでも持ち運べるように、手のひらサイズです。



作ってみたい人はこちらの「簡単な豆本の作り方」を参考に。

Kickstarterのイノベーション

災害や不況、テロやデモなど何かと大変な2011年でしたが、そういう中で成長したものって何だったんでしょうか。

絆以外で。

これまでやってきたやり方が通用しなくなったり、災害によってダメージを受けると、再建が必要です。東北がそうだったと思うし、個人的には人生を再建してますし、そういう大変な時代になると再建の方法が成長します。

ニューヨークに拠点を持つKickstarterは、何かを再建したい、新しいプロジェクトを立ち上げたいという夢を手助けしてくれる会社ですが、なんと今日発表された2011年の統計によると、そこで産声を上げたプロジェクトやプロジェクトに集まった金額が、2010年の約3倍にもなったというじゃないですか!
*データの詳細はブログとコメントを参考

それではなぜKickstarterがそれほど支持されているのか、勝手にまとめてみたいと思います。

1. 何をしたいのかが分かりやすい

それぞれのプロジェクトのオーナーはプロジェクトの説明やプレゼンを用意しているのですが、なんと2011年は80%ものプロジェクトがビデオによる説明つきだったというんです。

ちなみに写真は2011年に最も速く目標を達成したプロジェクトで、何と24時間以内に目標の$75,000はおろか$165,910に達し、今日現在で30日以上を残して$500,000を超えてしまっています。

2. 何ができるかが分かりやすい(参加や支援、購入できるオプションがいっぱいある)

例えばこのプロジェクトは、もっともぎりぎりで目標を達成したそうなのですが、$1から$5,000まで以下のようなオプションを用意しています。

$1 - Facebookであなたのことをみんなに知らせる&もし実際に会う時には、抱きしめてありがとうと言います
$10 - Facebookで知らせるのに加えて、“I heart MyM”ステッカーを送ります
$25 - オフィシャルウェブサイトでサポーターとして名前を載せ、"Mosquita y Mari, Fuck the Rest! www.mosquitaymari.com."というメッセージ入りのコーヒーホルダーに、映画のオリジナルデジタル楽譜をプレゼント
$50 - 上記に加え、Behind the Scenes(たぶんビデオ)とサントラセレクション
$100 - 上記に加え、Aurora(監督)のこれまでの作品とこの映画のサイン入り台本
$250 - 上記に加え(たぶん)、サイン入りスペシャルポスター
$1000 - 監督がゲスト参加する上映権(たぶん非商用)
$2500 - 映画セットにまる一日ご招待 監督やクルーと話したり映画に飛び入り参加もあるかも
$5000 - "Associate Producer"として映画のクレジットに登場


Kickstarterイノベーションは、ただ訴えたりお願いするだけだった寄付に近い資金調達を、具体的に価値のあるものと交換できるようにしたことじゃないでしょうか。できるようにしたとは言っても、実際に考えているのはプロジェクトメンバーたちなのですが、消費できる形にするという考え方、そこにとんでもないブレークスルーがあったと思います。

北極星の終わり

db4o2011-12-29

こちらで縦書きで読むことができます

The accidental universe:Science's crisis of faith
の中で物理学者であり作家でもあるAlanは、ある大胆な主張をここでしている。

紀元前5世紀の哲学者デモクリトスに始まり、私たちは人間の周りで起こるあらゆる現象を、科学によって自然法則に基づく当然の結果(necessary consequences of the fundamental laws of nature)と説明してきた。または、あらゆる現象は何らかの法則によって説明可能であると信じてきた。

ところが、この北極星のように明らかで揺るぎのなかった目標が、いよいよ終わりを告げよう(This long and appealing trend may be coming to an end)としているというのだ。

それではどうなるのかというと、あのアインシュタインの言葉「神はサイコロを振らない」と真っ向から対立する、単なる「宇宙のサイコロ(a random throw of the cosmic dice)」でしかないという。

そしてこの考え方は、今年もっと広い範囲で見受けられた。

例えば3.11の大震災。「なぜ東京電力はしっかり対策をとってこなかったのか?」「福島原発は人災だった」「いつも後手に回る政府」これらは全て、原因と法則さえ考えておけば、全て対処可能だと言う前提で考えられた発言だ。だからできることをやっていない、つまり怠けていたということを言っている。

もう一つは欧州を中心とした国債不安による金融危機だ。高名な経済学者達の理論によって説明されてきた景気の変動、もっと言うと政府が景気を操作できるという考え方は、今回の金融危機では原因も分からなければ対策も分からないというとんでもない事態になり、最早信じろという人さえいなくなった感がある。

そしてどちらも、神の意志を探して動けなくなった人たちを尻目に、「宇宙のサイコロ」を受け入れ、何が出てもやれることをやろうと動き出す人たちの力で動き始めた。それは企業や個人のボランティアであり、資金調達については特にアメリカのKickstarterなどのクラウドファンディングがそうだ。

ここにあるのは、できないことは無理にやらない、できることやうまく行ったことをもっとうまく行くようにするという価値の転換である。

違う言い方をすると、百の文句や非難より、一つの協力ということかもしれない。

実はこの価値の転換は、私がシリコンバレーベンチャー(startup)企業と一緒に働いていた時に教わったものだ。ゴールを設定し、できないことを一つでもできるようにするというような日本的価値観でいた私は、チームを鼓舞することもあるが、文句や非難によってマイナスの効果をもたらすことも少なくなかった。そしてひどかったのは、それがあるべき姿だと信じて(知らずに)いたことだった。

果たしてそんなことは単なる例のコップの話、「半分しか水が入っていないコップ」か「半分も水が入っているコップ」のように、話のための話に過ぎないのか?そもそも高いゴールや理想からスタートしないのは怠けているだけじゃないのか?などなど当時はいろいろ考えたものだった。

そしてそれから数年かかって、ようやくそれを克服できたとき分かったのは、非常に不確実な状況下では、うまく行ったこと(既成事実として理由は何であれ)にリソースを集中することが、あるべき姿(理想だけで何ら事実を踏まえていない)にリソースを集中するよりもはるかに効率が良いということだった。


それでは結果として出来上がるものが何になるか分からないじゃないか、とか、あきらめずに一つのことを追いかけるから物事は達成できるんだ、といった反論もあると思います。実際そうした反論はもっともで、あくまでもこれは「非常に不確実な状況下では」という前提つきです。

しかしながら、ひょっとすると、こうして従来の考え方が広く通用しなくなってきたということは、「非常に不確実な状況下では」というのが最早特殊な状況ではなく、日常として誰もが捉えて物事を考えるようにした方がいいのかもしれないということなんです。

それは、小田嶋隆氏が「ネットでものを書くということ」の中で言っている、”「分からない」というスタンス”がますます求められるようになるということであり、そうした従来の考えや物理的な制約(紙で印刷する場合)から見ると、随分だらだらしたしたように見える文章こそ、来年以降さらにウェブ上で活躍するのではないでしょうか。

さて、もう北極星が頼れないとしたら、あなたならどう進みますか?


写真はサイコロを使ったギャンブルから偶然に潜む確率を研究したと言われるイタリア人数学者、ジェロラモ・カルダーノ

#ヨミモノ

英語メディアに限って言うと、日本では有料会員または実際の雑誌でないと読めないような非常に読み応えのある記事が、それこそ読み切れない程ウェブ上に公開されている。

村上春樹氏のコラムによく出てくるThe New Yorkerに始まり、150年以上の歴史を持つThe Atlanticアメリカンスポーツのディープストーリーを届けるGrantland、世界中から選りすぐりのアドベンチャーを伝えてくれるOutsideなど、調査報道(例えばProPublica)や科学報道(Scientific AmericanやNewScientist)だけでなくその他あらゆるジャンルでそうした記事を発見することができる。

ただ全ての記事がそうした気合いの入った記事(採算度外視?フリーランスの意地?)なわけではないので、実際サイトから発見するのはそう簡単ではない。

しかし心配することなかれ。Twitterの検索で#longreadsと打ち込めば、一網打尽。ただしちょっとバリエーションがあって、sのない#longread、ほぼ同義の#longform、調査報道に特化した#muckreadsなどもある。

こうしたハッシュタグは自然発生的に人々が使い始めたわけではなく、#longreadsはLongreads、#longformはLongform.org、#muckreadsはProPublicaが仕掛け、運用している。

さて、こうして読み応えのある記事を発見するインフラは出来上がったのだが、もう一つ問題が。せっかくの記事、後でゆっくり読みたいんだけど・・・、とこうして自然にLongreadsやLongform.orgと連動して登場したのが後で読むサービスであるRead It LaterやInstapaper、Readabilityなどだ。記事を発見するインフラだけでなく、こうしたiPadなど読みやすいデバイスでゆっくり読める時に読めるようなツールも整っているのだ。

そもそもどうしてこれだけ無料で読み応えのある記事があるのか、ということについては、たぶん競争のせいもあるのだろうが、根本的に2つの精神が大きく関与していると思う。一つは民主主義を機能させるにはこうした調査報道が欠かせないという精神であり、もう一つは何かを相手に論理的に伝えるという科学報道の精神だ。

それじゃ我らが日本はどうかというと、確かにマスメディアを中心に表面的にはそれほど無いように見える。ただブログなどを含めて考えると、結構な記事が溢れているじゃないか!

ただこれを汲みやすくする#longreadsのようなインフラや、後で読むサービスのようなツールが無い。

そこで、地味にではありますが、まずは#longreadsのように、「お、これっていい記事だね」というのを集める日本語のインフラを作ろうと思います。#ヨミモノというハッシュタグを使ってヨミモノというサイトで運用します。

そうそう、ちょっと昔になりますが、日本文学地図というのを作ったことがありました。この時は手動でしたが、今度は自動で、記事から地名を取り出して地名&年代で記事が読めるようにしてみようと考えています。高松で高松の記事を読む。たぶんちょっとだけ面白く読めますよ。