企画内容

さくらの開花状態を共有するソーシャルwebサービス

モチベーション

2005年に弊社製品であるMYSQをグッドデザイン賞に応募したのですが、この時コミュニケーションデザイン部門にてグッドデザイン賞を受賞したのが、某竹村先生プロデュースの「さくらスケープ」です。

「さくらスケープ」は、ケータイから投稿される日本各地の花見経験をジグソーパズルのようにつなぎ合わせて、日本列島のサクラ前線の北上を可視化する試みです。伝統的な言語芸術・俳句と、（花見の場で写真やメッセージを送れる）「現場性」のメディアとしてのケータイの結合。投稿者の郵便番号から位置情報を取得し、日本列島上にリアルタイムに表示してゆくことで、インターネット時代ならではの“地球大のお花見”が実現しました。
from グッドデザインファインダー

「さくらスケープ」は、サクラ前線の北上を可視化するものです。前線という言葉を用いていることから、この作品は『開花情報』をメイントピックに据えているような印象を受けます。俳句という時間を切り取る表現手法はまさにポエティックなのですが、ユーザ（投稿者）の完全たる主観体験は得てして他のユーザ(投稿者)にとっては有益な情報であるとは限りません。

花見をしようとするユーザにとって最も有益な情報とは、「どこの桜が現在どういった状態にあるのか」、この1点につきます。同じ都内でも井の頭公園と目黒川では開花状態は全く異なります。主観情報もたしかに世界を構築する要素なのですが、桜の開花状態をソーシャルな仕組みで共有可能なwebサービスを可視化するほうがシステムとしてよりポエティックだと思ったりします。

これはなにか

本サービスは、ユーザからの投稿に基づき視覚化されたさくらの開花状態を共有するwebサービスである。

投稿フロー

投稿フローは新規登録、既存から選択の2つに区分できる。

新規登録
まず、携帯のGPS座標情報からgoogle map上に現在の位置情報と名所の名前をマッピングした上で登録します。
次に、さくらの現在の開花状態を下記のいずれかで投稿します。このとき画像データも合わせて投稿できることが望ましいでしょう。
・未開花
・開花（0-120%)
・散り始め
・青葉

既存から選択
まず、携帯のGPS情報に基づき、ユーザの現在位置を取得します。
次に、登録された桜の名所から任意のものを選択します。
続いて、桜の開花状態を投稿します。開花状態のリストは上記と同様です。

桜の開花状態については登録された主観データからの平均値で現在の値を算出し、出力します。

閲覧

googleマップをインタフェースとし、マップから直接選択、ないし、さくらの名所(上野恩賜公園、井の頭公園など) で検索し、閲覧します。

画像データは時系列順にスライドショー形式で表示可能とすることで、現在の状態を実際の画像として閲覧可能とするだけでなく、アーカイブとしても有用なデータとなるでしょう。

企画内容

食材・味を中心としたレシピ検索・投稿webサービス

モチベーション

筆者の専門は，エンタテイメントコンピューティングにおけるフィジカルインタラクションデザイン，インタフェースデザインですけが，衣食住のいずれかのカテゴリに関するコンテンツ/システムを作る際に，最も難しいのは食に関するものだと思っています．

住環境の例は，Georgia TechのAware home projectをはじめ，様々な機関で行われいますし，ファッション/テキスタイルについてはSFCでも研究が行われています．これらに対し，食については，食事という行為そのものに対する満足度があまりに高いため，わざわざコンピュータによる拡張は必要ないわけです．

とはいえ，その行為を助長する，いかに食事において満足できるかどうかをキーポイントとしたシステムは必要ですし，筆者の所属する研究室でもそういったシステムを開発している学生もいます．VRやARの分野では食感再現に関するシステムやインタフェース研究が行われていますが，これらも，食の本質をを拡張するものとはいえないでしょう．

研究の場合，単なるwebサイトを構築しても評価対象にはなりませんが，ビジネスの場合，ユーザが便利だと思えば，それを利用するユーザの数は増加しますし，そうなれば，トラフィックも増加し，webサイトそのもの価値も増加します．

今回のレシピサイトの企画では，いかに日常の生活における食事を満足させることができるか，という点，特に平日など時間のないケースでいかに高いバリューを出せるかという点をキーポイントとして設定しました．更なるコンテキストを追加するならば，家にある食材だけで，おいしい食事を短時間で作りたいといったものでしょう．

現在もこのような視点から構築された情報配信型のwebサイトが存在します．そのうちのいくつかを掲載します．

おかずナビ
“おかずナビ”は家庭料理のレシピ・手作り料理のレシピを紹介しています．

しゅふしゅふーず
食材から検索できるレシピのデータベース．投稿レシピや情報交換掲示板．

レシピ大百科
味の素提供．数千種類のメニューレシピを掲載．食材・調理・フリーワードで検索可能

このような既存webサイトの問題点を踏まえて今回の企画案を設計しました．

コンテンツ

これはなにか

食材・味をパラメータとしてレシピを検索可能なwebサービスである．ユーザはレシピを検索することができるだけでなく，レシピを投稿でき，投稿されたレシピの評価を行うことができる．

検索機能

・ユーザは，食材からレシピを検索可能である．
例えば，冷蔵庫の中に，人参，しいたけ，なすが入ってるときにどういう料理が作れるか，といったことが検索可能である．

・ユーザは，味からレシピを検索可能である．
この味のカテゴライズはもれなくだぶりなくは困難であるため，タグにて管理することが望ましい．
例えば，ある料理は，甘い，クリーミー，コクがある，といったタグ付けが行われていることから，これらのワードで検索した場合，当該レシピが検索結果として，表示されることとなる．

投稿機能

・ユーザはレシピを投稿可能である．
ユーザはレシピをフェーズごとに投稿可能である．従来のレシピサイトと異なり，写真・動画・テキストが美しく配置されることが重要である．

評価機能

・ユーザはレシピを評価可能である．
高評価を得たレシピの投稿者は，ポイントを取得することができる．ポイントは本webサービス内で通貨として使用することができる．

企画内容

地図インタフェースを用いたランチ情報共有CGM

モチベーション

携帯サイトでgoogle mapを使ったコンテンツというのはなかなかあるらしいです。

ケータイグーグルマップ改め「ここらで」リリース
「ここらで」は、ケータイで今いる場所の地図や情報を収集するサービスです。明確な目的が無く、時間が空いたときの街歩きのお供のような使い道を考えています。
現在は全国ロケ地ガイドの情報やホットペッパー、じゃらん、スマッチ、テクノラティのWebサービスを使って、位置から情報を収集しています。他にも位置から検索できるようなWebサービスがあれば追加可能（何かないかな？）
地図の移動、拡大縮小はケータイグーグルマップと同様に数字キーで操作可能です。情報検索の結果画面で移動すると、自動的に再検索されます。

Google マップが携帯電話向けアプリで登場、まずはドコモに対応

ちなみに
携帯　googlemap に一致する日本語のページ 約 517,000 件中 1 – 10 件目 (0.22 秒)

筆者自身は職場の周囲に選択できるほどランチスポットがないためいつも同じ場所を使っていますが、丸の内や表参道付近では多くのランチスポットがあるわけです。
しかも職場から半径数10メートル以内で検索できたり、地図で視覚的に職場からの距離を確認できたり、直接利用者からのコメントまで一覧できると非常に使い勝手がよいと思うのです。
集合知の衆愚性などという言葉もありますけど、ランチ情報程度の軽めの話題の場合、有効な意見も多く見つかるのではないかと考えています。

これはなにか

地図をメインインタフェースとして利用し、ランチ情報を可視化する携帯CGMサイトである。

1. 事前にいくつかのショップ情報についてはgoogle map上に登録されている。
ショップだけでなく丸の内などにいる移動式のランチ販売車も網羅
事前登録ショップについては、スポンサーとして一定の広告料を徴収。

2. ユーザによる投稿によりランチ情報がプールされていく。
ここでいうランチ情報とは、
・店の名前(既存or新規)
・場所
・お薦めメニュー
・コメント
を指す。

3. ランチ情報がある程度プールされ、個別ユーザの振る舞い(行動履歴)も蓄積されてくると、これらのデータをベイズエンジンにより最適化し、今日のお薦めショップなどのレコメンデーションを行うようなシステムへ発展させる。

ポイントはあくまで地図中心のインタフェースを採用している点です。
とはいえgoogle mapの場合、コージプスキーのいうところの地図と土地の違いが明確に意識されます。もう少し抽象度を下げたかたちとして、Flash 3Dによる擬似的3次元空間を構築し、実際に街を俯瞰するかたちでショップ情報を一覧できればもっと(ユーザエクスペリエンスの観点から)よいのではないかと思います。

一般意味論
アルフレッド・コージブスキー自身によると、 一般意味論の主な目標はその実践者に「抽象過程への自覚」と彼が呼ぶものを展開することである。それは「地図と現地の違い」の自覚であり、言語などの表現方法によってどれだけの現実が破棄されているかということへの自覚である。一般意味論はこれを散発的に知識として理解するだけでは不十分としていて、「抽象過程への自覚」を常に持って反射的に実践することで完全な正気が達成されるとしている。

しかしこのレベルにになってくると携帯の小さな画面では限界があるのでやはり詳細情報はPCサイトで実現するほうが現実的でしょう。

企画内容

不動産web3Dサービス

モチベーション

ここ8年間で引越しをしようと思ったこと，数回．そのたびに断念してます，諸事情により．．．
とはいえ家を探すのは割りと好きなのですが，どこのwebも似たりよったりで．独自サービスはほとんどないわけです．そんな中，某不動産デベロッパから企画依頼があった際，we上で図面，あるいは”適当な”写真以外の部屋を推し量れるサービスがあるとよいなぁと思ってちょっと考えてみました．

ちなみにこの企画を考えた後，チームラボのいえーいが発表されました．
やはり駅からの位置関係は視認できたほうがよいし，周囲になにがあるかというのも重要な非常に情報だと思う．
第三者とはいえ，いわゆるひとつの”おもてなし”の精神にあふれたサービスであり，こういうことができる会社はすばらしい．

コンテンツ

今回のねらいは，部屋の構造や眺望を視覚的にどうユーザに提示するか，ということです．ここでは，前者について，web3Dの技術を用いて，ユーザにバーチャルに物件訪問を可能とするサービスを提案したいと思います．

まず，web3Dを提案するのはよいですけど，結局は，いかに多くの物件情報を高い再現性でもって提供できるかということが重要だと思います．ということで不動産web3Dコンテンツ生成CGMみたいなものを実装する必要があるわけです．

このサービスが実装されたとして，物件情報を吐き出させるために，バイト君が1件の物件情報あたり10分程度で入力を完成させることが望ましいです．
6(1時間あたり)x8(労働時間)で1日約50件しか入力できないならば10,000件入力するには，200日ですが，20人雇えば10日で終了です．一人自給1500円で240,000でOKです．イニシャルはこれだけで，ランニングは社員で担当すればよいでしょう．

フォレントによれば，2007/11/24現在で首都圏には，249,806件の不動産があるようです.tokyoだけだと100,000件くらいでしょうか．

実際に不動産web3Dコンテンツを吐き出すために必要なパラメータとして，
・間取/構造
・部屋の実寸
・内装のテクスチャ(写真から)
が挙げられます．
あまり多くのパラメータを与えても作業が煩雑になるだけですし，10分でおわらないのでこの程度が妥当ではないかと思います．

実装は，Flash3Dベースで開発がスムーズのような気がします．なつかしのVRMLも好きなんですけど，SEO的にあまり芳しくないのではー，と思ったりします．

後者の眺望についてはgoogle earthでできそうですが，Tokyoという建物が短期的なスパンで移り変わりする都市であることから，再現性にかけるかもしれません．