2011年9月29日木曜日

Yesterday



昨日は大学マンドリンクラブの練習に遊びにいってきました。今週末が演奏会なので、練習も追い込みの真っ最中でした。曲はペールギュントより抜粋。僕は5年前、大学1年生の頃の冬の定期演奏会で演奏したことがあったので、当時のことを思い出しながら練習を見ていました。

演奏会の詳細はこちらです。

ALL KMC - 第48回 ALL KMCコンサート
http://www.keiomandolin.net/allkmc/temp/20111002.html

今日はイエスタデイ(John Lenon and Paul McCartney arranged by Toru Takemitsu 「ギターのための12の歌」より)を録音してみました。月曜日のレッスンで弾いたので、それを思い出しながら弾いています。Yesterdayのメロディはとても好きで、よく弾いています。

武満さんの編曲はギターの響き方の色が少し違います。他の編曲を弾いている時と比べて、青っぽいというか、音の混ざり方が不思議な感じがします。

余談ですが、今回の録音はいつもと違うギターを使っています。今週末の演奏会のために、僕のギターを後輩に貸しました。本番、ホール中に音を響かせてきて欲しいです。

イエスタデイ / yesterday

2011年9月18日日曜日

フェルナンド・ソル 練習曲 op.29-21

ハーモニクスだけで構成されている曲です。最近好きでよく弾いてます。今日は昼からアンサンブル練習に行ってきます。

sor_29_21

2011年9月9日金曜日

デザインから逃げない

屋上から。

サンフランシスコに来てから12日が経ちました。企業を訪問したり、実装をしたり、サーバを整備しているうちにあっという間に時間が過ぎていきます。サンフランシスコの環境にもだいぶ慣れました。気候はよく、野菜は安くておいしく、道行く人に話しかけても怪しまれません。どこに行ってもフランクで、この開放感はどこからくるのだろうと思ってしまいます。

実際にこちらに来て何をしているのかというと、主に開発、そしてミーティングです。今trippieceは再度コンセプトについて煮詰める時期を迎えました。α版のローンチから約1ヶ月経って、ユーザのみなさんから反応をいただくと共に、公開されたアプリケーションを眺めながら感じることが多々ありました。改めてtrippieceというサービスの目指すべき方向やコンセプトをとことん話しあって、よりよいサービスを作っていく、そういう再出発のフェーズにあります。

ここ数日、trippieceメンバーとミーティングをしていて、うまくものづくりに結びつかないことがありました。たしかにサービスはローンチされているものの、各々がtrippieceの方向性を別にもっていました。サンフランシスコの開放的な雰囲気もあってか、またこうしてゆっくりと話をできる環境に身をおくと、相手を信頼しながらも思いの丈を述べるようになるのです。お互いに率直な意見を述べ合い、ときには喧嘩のような模様になりながら、話を続けていきました。全員がプロダクトを良くしようとしているのに、一人ひとりの言葉が噛み合わず、意見が違っていき、喧嘩のようになるのです。喧嘩にならないまでも、どんどんとお互いの方向性がずれて行ってしまって、気が付けば対立した話し合いになっているという場面をよく見かけました。そういうときにいつも僕がとる方策というのがあって、今日はそういう点について話をしていきたいと思います。

まずは、敢えて冗長な文章によって導入をしたいと思います。trippieceのサイトを例にします。ログインをすると、ホーム画面が出てきます。画面の上にはサイトの大まかなナビゲーションとしてグローバルナビゲータ、左カラムにはユーザに関する情報及びナビゲーション、そして中央の広いスペースにはプランの一覧を表示させています。各プランの画像かタイトルをクリックすると各プランの詳細ページに移動し、プランの詳細な情報を閲覧することができます。プランの詳細ページには参加者の一覧やプランの詳細情報を掲載しています。プランに参加するとディスカッションボードというものが表示され、プランの参加者同士でコミュニケーションをすることができます。プランの作成は左カラムから常に行うことができ、ログインしたユーザは好きなときにプランを作成できます…。

非常に退屈です。あくまでもこれは見えているものについて説明しただけです。次に、もう少し変わった見方をしていきます。

"trippieceサイトにログインした。まずはプランが大きく取り上げられているな。なるほど、左上からプロフィールに移動できるのか。プランはたくさん並んでいるようだ。他のプランはどこから探せるのだろう。左にプラン作成のボタンがあるな。フォームが出てきて…、ああなるほど、こうやってプランを作成するのか。結局これらの入力項目が検索対象になるのだろうな。トップに並んでいるプランには人が集まっているのだろうか。どんな基準でこのプランは並んでいるんだろうか。プランに参加するにはどうしたらいいのだろう…、各プランのページに行けば参加できそうだ。参加すると何らかの責任が生じるのだろうか?…"

差こそあれ、初めてサイトを使うときはこのように考えながら進んでいくのではないかと思います。ユーザの体験そのものです。

ではもうひとつ、違う観点から話をします。Webアプリケーションをつくる目的とは一体なんなのでしょうか。文脈的にはユーザの体験、と言えそうですが、ちょっと待ってください。きっとWebアプリケーションというからにはもっと多岐に渡る要素があるのではないでしょうか。場合によっては、面倒なことを効率良く解決できるという役割であったり、お金を稼ぐことであったり、世界観を伝えることであったり、新しい価値観を作ることであったり、世の中を少しだけ幸せにすることかもしれません。僕はどれであってもいいと思います。しかし、ユーザの体験を向上させる、と一言で済ませてはいけない。その後に何をしたいのか、どんな変化があるのか、他のサービスにはないどんな違いが生まれるのか。もっと掘り下げて考える必要があります。

目的自体を汎化させては話が収束しないので、今回はtrippieceというサービスの目的、及び、コンセプトデザインについてここに書き、具体的にプロダクトに落としていく今後のフェーズについての僕なりの考えと方法を展開していきたいと思います。

上で述べたような話し合いを経て、僕らはやっとコンセプトを全員で作成することができました。そして作成したコンセプトに基づいて、今デザインのフェーズに移っています。コンセプトの話し合いではひどくコミュニケーションが行き違いになり、お互いに理解できず、まったく共感を得られない場面もありました。このままじゃユーザの体験を作ることはできないだろうと感じることもありました。ミーティングを重ねました。何度も、何度も、自分たちが何をやりたいのか、何のためにサービスを作るのか、どういう影響を与えたいのか、ということについて話し合いを重ねました。前回のミーティングで決まったことも、次のミーティングでは違う言葉に置き換えられてしまい、また一人、また一人と感じることが変わっていき、コンセンサスを得られずに話が流れて行きました。話し合いで全てについて決定するのは限界があるのではないかと、悩みました。

僕らの導き出した答えは、旅の理由、それをトリガーとしてユーザを惹きつける場所をつくるということでした。非常にシンプルでした。しかし、会社の立ち上げから半年経過して、やっと全員が自分たちのサービスの役割を認識しました。長い時間でした。良い答えがでたと感じています。この目的から全て始めることができるのだと思うと、それまでのどんな過程も関係なく感じられるのです。

全員で納得をした瞬間に、僕はそれを確実な言葉の塊としてメンバーの記憶に残すように努めました。同じ認識に基づいた言葉は、どんなルールよりも人を動かします。CEOもGMもデザイナーも、やっと自分の仕事につけるのです。確実な言葉に落としこむ。世界観を確定させる。だから制作し始めることができるし、PRや広報、資本の政策も決定できる。サービスの目的が決まって、初めて全員の仕事をお互いに理解できたように思いました。

このコンセプトを受けて、デザインを作っていく段階においても、ことばは常に大事な役割を果たします。今回はデザイナーだけでなく、チーム全員でインタフェースを作成していくという手法をとりました。デザイナーは手段として画像を作成しますが、プロダクトデザインは全員できるはずなのです。リビングのテレビにFireworksの画面を広げながら、具体的な画面を基に話しを進めています。ログインした後にユーザは何を考えるか。目に見えているものから考えることと、前からの遷移でユーザが想起しているであろうことをその都度思い描きながら、最小限のコンポーネントに落としこんでいきます。プランへの参加はどのような経緯で行われるのだろう。プランの作成者は何を考えるだろう。どんなプランだったら人を惹きつけられるだろう。その人を惹きつけるプランをどうやって見せることができるだろう。プランを一緒に作るにはどのようにすればいいのだろう。ああ、考えることは山ほどあります。でも、この過程はすごく楽しく感じられるのです。きっと、コンセプトの設計から全て全員で行っているからだと思うのです。結果としてインターフェースのデザインを落としこむのはデザイナー、実装するのはエンジニアであっても、このアプリケーションを何のために作るのかということを自発的に感じられているからこそ、発揮できる創造性もあると思うのです。デザイナーやエンジニアにとっては結果として負担が増えてしまったとしても、自分が納得したものを作るときには。どんなに技術的に難しく思えても、案外頑張れてしまうものなのかもしれません。きっとそれが小さなチームで良い仕事をするためのプロセスなのではないかと、今になって感じています。

そういったフェーズの中において、エンジニアとして僕は2つ気をつけていることがあります。1つ目はシステムにかかるコストを丁寧に知らせること。そして2つ目は全員が認識できる言葉でデザインについて語ることです。1つ目はエンジニアの義務としての役割で、持続可能なシステムの中で最大限可能なボーダーラインを示すということを行っています。固定費といった面もそうですし、各フェーズごとの自分の負担及び予想される作業時間についてもある程度見積もって、プロダクトデザインのミーティングの差異に共有しています。特に今のチームはエンジニアリングについては僕一人の領域なので、これを伝えないと完全にエンジニアサイドがブラックボックスになってしまうのです。これを避けるため、デザインのフェーズからある程度の内容を共有するようにしています。2つ目については義務ではなく、努力目標に近いようなものです。デザイナーだけがデザインをするのでは決してありません。インタフェースについて、ユーザの行動をつぶさに観察して、シームレスなアプリケーションになるよう、全員を説得するように心がけています。実際のところ、多くのエンジニアはユーザの行動を細かく観察可能なはずなのです。ユーザのクリック、スクロール、視点の移動といった物理的要因、及び、「このボタンはどのような意味を持つのだろう」「プランに参加するっていうのはどういう概念なんだろう」といったような認知的要因の2つの側面からユーザを観察すべきです。2つの側面からのユーザ観察は、コンセプトを反映させたアプリケーションを作るための手段として大いに有効だと感じています。そしてもっと多くのエンジニアがそういった面についても常日頃から言及すべきだと感じています。WebアプリケーションであればユーザインタラクションはJavaScriptによるDOMの制御がメインになりますし、裏側ではデータベースがスキーマを抱えています。アプリケーションのシステム的な全ての側面についてエンジニアは想像できるはずなのに、デザインとなるとあまり強く言い切れないのは、自分がデザインを作ることができないという思い込みがあるのかもしれません。でもデザインというのは見た目を作るだけないのです。ユーザの考えるモデルができて初めてデザインを行うことができるのだと思います。

今回の滞在においてはたくさんの発見をすることができています。今日ここに書いたことは、話した内容の10分の1も表現しきれていなくて、正直歯がゆいところもあります。それに、まだ実装フェーズに入っていないものがたくさんあって、エンジニアリングとしての説得力に欠ける部分も多々あります。ですが、今感じていることをストレートにまとめてみて、きっといろいろな場面で同じようなことを考えている人がいたとしたら、何かしら共有できるものがあるのではないかと思い、文章に起こしてみました。

こちらでの滞在はあと1週間となりました。いろんな人と会い、話し、そして思う存分吸収して、帰国後のエネルギーに変えていきたいと思います。


<今後の予定>

Samurai Venture Summit in Silicon Valley
Friday, September 09, 2011 from 5:00 PM to 10:00 PM (PT)
Ca 94301,


IT飲み会 in サンフランシスコ
When: 9月8日(木)19:00~23:00 太平洋標準時(Pacific Standard Time)
Where: NEW PEOPLE: 1746 Post St, San Francisco, CA 94115



Japanese Start-up Party
San Francisco (very close to 24th street mission station) · Saturday, September 10, 2011, 6-9:00pm