2011/11/26
UbuntuのターミナルをTerminatorに変更
Ubuntuにterminatorを入れてみました。画面分割が簡単にできて、動作も軽く、設定もしやすいです。あとguakeの機能の入っているものを利用しているので、キーボードショートカットの設定が結構融通効きます。ColorSchemeはいつもどおりSolarizedです。
あとはChrome拡張のVichromeを試していました。vimiumよりも使いやすく、拡張もしやすそうです。
今日はジムに行って帰ります。
【参考】
Ubuntuで最高のターミナル環境を構築する方法 - ノヴァちゃん日記2
http://d.hatena.ne.jp/NovaEra/20110829/1314583270
ColorScheme設定はこのgistを参考に。
terminator config solarized — Gist
https://gist.github.com/943715
tenshu.net: Terminator
http://www.tenshu.net/p/terminator.html
2011/11/25
リベルテ・マンドリン・オーケストラ第8回演奏会を終えて
今年最も時間を費やした演奏会の一つ、リベルテ・マンドリン・オーケストラの本番が昨日終了しました。ご来場いただいたみなさま、どうもありがとうございました。そして今回の演奏会に編曲・作曲・指揮・演奏・運営に携わってくださった方々にまずは御礼したい次第です。重ね重ね、どうもありがとうございました。
今回のリベルテの演奏会は、本当に出てよかったなぁと思えるものでした。終わってみて今感じるのは、この一週間はずっと演奏会のことを頭のどこかで考えていて、他のことになかなか意識が回っていなかったということです。僕の中で音楽が生活の中に占める割合がどこかうまく調整できていなくて、没頭することができない時期がありました。今回の演奏会は、完全に集中した状態で迎えることが出来ました。
振り返りを兼ねて、一曲一曲について個人的な反省を書いておきたいと思います。
橋爪さんに編曲していただいたドビュッシーの「スコットランド風行進曲」。始曲にして、もっともギターの音数が多い曲だったかもしれません。橋爪さん自身がギタリストということもあって、ギターパートの演奏についてのアドバイスをうけることができました。マンドリンオーケストラの中で、ギターは左手での音色の変化をつけやすい楽器です。特にビブラートについての指示をいただきました。音を伸ばすときには最初はゆっくりと徐々に速く左手でビブラードをかけるようにするということ、そして、ソロのときと同様にビブラートをもっと強めにかけてよいというアドバイスをいただきました。ビブラートの速度の変化については今回うまく付けられなかったので、次回は慣れるようにしたいです。それによって、例えば中間のCalme Meno tempoの部分についてはもっと叙情的な演奏ができたように思います。
ヴィオロンチェロの丹羽さんのコンチェルトでした。編曲はスコットランド風行進曲と同じく、橋爪さんです。この曲を弾いているときは、とにかくチェロの音に聴きいってしまいました。しかしなかなかチェロとの拍感がうまく測れず、もっとアンサンブルすることができたなぁと思っています(すみません…)。マンドリン系の楽器だとトレモロの揺れで拍感がつかめるのですが、擦弦楽器の場合にはビブラートを頼りに弾こうと試みたものの、うまく合わせることができませんでした。エレジーの重さや哀愁といったものを出すのにも、課題が残りました。アンサンブルに関してはもう少しでコツが掴めそうなので、次またこういう形で演奏できる機会があれば嬉しいです。
壺井一歩さん作曲の抜忍アスタリスクが第1部の最後の曲でした。コンサートマスターの望月さんによるコンチェルトです。この曲を初めて聞いたのは去年の大阪国際マンドリンフェスティバルでした。その時の印象は不思議な空間のある魔性的な曲だなぁと感じたのですが、今回演奏してみてさらにその感覚を深めました。中間の長いカデンツァを終えた後のppの瞬間に、音が時間をまるで止めるかのように、何の音もない音楽が存在していて、その後にすっとその空間に溶けこむように音を出し始めたときは、本当に演奏を楽しんでいました。
実は演奏会前日に大好きなギタリストの一人であるイョラン・セルシェルさんのコンサートに行ってきました。その演奏会のキャッチフレーズが「時は止まって−限りない静けさと沈黙へ」でした。このキャッチフレーズはダウランドのある一曲から取ったものだそうで、コンサートでは音の余韻を意識した、スローな音楽を中心に演奏されていました。そのアンコールの最後に演奏されたある一曲の終わりに、演奏会を締めくくる最後の余韻がありました。11弦ギターの響きが消えて行く中に、時間が解き放たれたように、あるいは止まるように、素晴らしい時間が過ぎて行きました。なんだかその感覚が、翌日の演奏会本番の舞台上で同じように蘇ったのです。素晴らしい瞬間でした。
Kagel作曲のMusi。Kagelは現代音楽の作曲家として有名な方で、MusiはKagelの作曲した唯一のマンドリン合奏のための曲です。この曲は本当に演奏するのが難しかったです。初めて合奏で音出ししたときは、どんな曲なのかまったくわからなかった程です。音の数もリズムも多くて、演奏するのがやっとだったというのが実際のところです…。しかし、練習をしていく中で、だんだん楽しくなっていったのもまたこの曲でした。冒頭から持続している8分のリズムが形を変えながら跳ねていくようでした。とある日の練習後の飲み会では、この曲が一体何を表しているのだろう、どんなイメージで作曲されたんだろうなどという話で盛り上がりました。結局のところ何だったのかは演奏者自身もわからないのですが、ある側面としてきっとこの日常にある音の抽象的な表現の集まりというものが表現されているのかもしれません。例えば机を平手打ちした時の音や、何かに擦れる音や…。突然fffのところである種の作為的な意志があって、もしかしてそれは人間なのかもしれません。しかし、やはり答えはわかりません。
今回の終曲です。編曲は鷹羽先生でした。ラヴェルのもつピアノからのイメージを個人的には大事にしようと思っていて、編曲の中にもそんなエッセンスを感じました。音の粒感・広がり・透明感といったものを表現するのに、マンドリンオーケストラというのはきっと面白い方法がまだまだたくさんあるのではないかと思います。最後の土日で急激に良くなったのはこのクープランの墓でした。これがもっと準備期間があったら、もっと違う形の演奏になっていたかもしれません。それでもクープランの墓を演奏できたことは良かったなぁと思っています。フーガでは良い瞬間がありましたし、トッカータではこの曲の面白さを感じることができました。ピアニストがピアノを弾く一瞬間前に描いているイメージを、より詳しく書いたような印象をトッカータからは受けました。しかし、終曲ということもあってか、何度か周りも僕も力みが多い場面があり、音ミスも聴こえる範囲であったように思います。きっとテンポに関してももっと魅力的なところまでいけたのではないかと思います。それでも、なんとかこうして本番で演奏することができて、僕は純粋に嬉しく思っています。
音楽的には何より、鷹羽先生との練習から学ぶことがたくさんありました。練習の進捗がいつもより遅くなってしまったこともあり、直前の土日で一気に良くなっていたというのが実際の所ではありますが、その分直前2回分の練習は本当に濃いものでした。内心多くの演奏者は今回演奏会で演奏するのに練習が間に合うのだろうかと不安でした。もっと早くから集中して取り組んでいればもっと充実した内容になったであろうということも否定できないのですが、今回の本番については演奏していて気持ちのいい瞬間がいくつもあり、弾いていて楽しかったです。
また来年度も意欲的に取り組んでいきたいと思っておりますので、どうぞよろしくお願いいたします。そして来年は是非、今年ご来場いただけなかった方々にも聴きに来ていただきたいです。長くなりましたが、どうもありがとうございました。
今回の演奏会詳細は以下のとおりです。アンコールはドビュッシー作曲「小組曲」よりバレエでした。
ギターの時間で練習風景を取材していただいた時の記事のリンクも掲載しておきます。
今回のリベルテの演奏会は、本当に出てよかったなぁと思えるものでした。終わってみて今感じるのは、この一週間はずっと演奏会のことを頭のどこかで考えていて、他のことになかなか意識が回っていなかったということです。僕の中で音楽が生活の中に占める割合がどこかうまく調整できていなくて、没頭することができない時期がありました。今回の演奏会は、完全に集中した状態で迎えることが出来ました。
振り返りを兼ねて、一曲一曲について個人的な反省を書いておきたいと思います。
Debussy/橋爪皓佐 「スコットランド風行進曲」
橋爪さんに編曲していただいたドビュッシーの「スコットランド風行進曲」。始曲にして、もっともギターの音数が多い曲だったかもしれません。橋爪さん自身がギタリストということもあって、ギターパートの演奏についてのアドバイスをうけることができました。マンドリンオーケストラの中で、ギターは左手での音色の変化をつけやすい楽器です。特にビブラートについての指示をいただきました。音を伸ばすときには最初はゆっくりと徐々に速く左手でビブラードをかけるようにするということ、そして、ソロのときと同様にビブラートをもっと強めにかけてよいというアドバイスをいただきました。ビブラートの速度の変化については今回うまく付けられなかったので、次回は慣れるようにしたいです。それによって、例えば中間のCalme Meno tempoの部分についてはもっと叙情的な演奏ができたように思います。
Faure/橋爪皓佐 「エレジー」 ※チェロ独奏:丹羽あいり
ヴィオロンチェロの丹羽さんのコンチェルトでした。編曲はスコットランド風行進曲と同じく、橋爪さんです。この曲を弾いているときは、とにかくチェロの音に聴きいってしまいました。しかしなかなかチェロとの拍感がうまく測れず、もっとアンサンブルすることができたなぁと思っています(すみません…)。マンドリン系の楽器だとトレモロの揺れで拍感がつかめるのですが、擦弦楽器の場合にはビブラートを頼りに弾こうと試みたものの、うまく合わせることができませんでした。エレジーの重さや哀愁といったものを出すのにも、課題が残りました。アンサンブルに関してはもう少しでコツが掴めそうなので、次またこういう形で演奏できる機会があれば嬉しいです。
壺井一歩 「抜忍アスタリスク」 ※マンドリン独奏:望月豪
壺井一歩さん作曲の抜忍アスタリスクが第1部の最後の曲でした。コンサートマスターの望月さんによるコンチェルトです。この曲を初めて聞いたのは去年の大阪国際マンドリンフェスティバルでした。その時の印象は不思議な空間のある魔性的な曲だなぁと感じたのですが、今回演奏してみてさらにその感覚を深めました。中間の長いカデンツァを終えた後のppの瞬間に、音が時間をまるで止めるかのように、何の音もない音楽が存在していて、その後にすっとその空間に溶けこむように音を出し始めたときは、本当に演奏を楽しんでいました。
実は演奏会前日に大好きなギタリストの一人であるイョラン・セルシェルさんのコンサートに行ってきました。その演奏会のキャッチフレーズが「時は止まって−限りない静けさと沈黙へ」でした。このキャッチフレーズはダウランドのある一曲から取ったものだそうで、コンサートでは音の余韻を意識した、スローな音楽を中心に演奏されていました。そのアンコールの最後に演奏されたある一曲の終わりに、演奏会を締めくくる最後の余韻がありました。11弦ギターの響きが消えて行く中に、時間が解き放たれたように、あるいは止まるように、素晴らしい時間が過ぎて行きました。なんだかその感覚が、翌日の演奏会本番の舞台上で同じように蘇ったのです。素晴らしい瞬間でした。
Kagel 「Musi」
Kagel作曲のMusi。Kagelは現代音楽の作曲家として有名な方で、MusiはKagelの作曲した唯一のマンドリン合奏のための曲です。この曲は本当に演奏するのが難しかったです。初めて合奏で音出ししたときは、どんな曲なのかまったくわからなかった程です。音の数もリズムも多くて、演奏するのがやっとだったというのが実際のところです…。しかし、練習をしていく中で、だんだん楽しくなっていったのもまたこの曲でした。冒頭から持続している8分のリズムが形を変えながら跳ねていくようでした。とある日の練習後の飲み会では、この曲が一体何を表しているのだろう、どんなイメージで作曲されたんだろうなどという話で盛り上がりました。結局のところ何だったのかは演奏者自身もわからないのですが、ある側面としてきっとこの日常にある音の抽象的な表現の集まりというものが表現されているのかもしれません。例えば机を平手打ちした時の音や、何かに擦れる音や…。突然fffのところである種の作為的な意志があって、もしかしてそれは人間なのかもしれません。しかし、やはり答えはわかりません。
Ravel/鷹羽弘晃 「クープランの墓」
今回の終曲です。編曲は鷹羽先生でした。ラヴェルのもつピアノからのイメージを個人的には大事にしようと思っていて、編曲の中にもそんなエッセンスを感じました。音の粒感・広がり・透明感といったものを表現するのに、マンドリンオーケストラというのはきっと面白い方法がまだまだたくさんあるのではないかと思います。最後の土日で急激に良くなったのはこのクープランの墓でした。これがもっと準備期間があったら、もっと違う形の演奏になっていたかもしれません。それでもクープランの墓を演奏できたことは良かったなぁと思っています。フーガでは良い瞬間がありましたし、トッカータではこの曲の面白さを感じることができました。ピアニストがピアノを弾く一瞬間前に描いているイメージを、より詳しく書いたような印象をトッカータからは受けました。しかし、終曲ということもあってか、何度か周りも僕も力みが多い場面があり、音ミスも聴こえる範囲であったように思います。きっとテンポに関してももっと魅力的なところまでいけたのではないかと思います。それでも、なんとかこうして本番で演奏することができて、僕は純粋に嬉しく思っています。
音楽的には何より、鷹羽先生との練習から学ぶことがたくさんありました。練習の進捗がいつもより遅くなってしまったこともあり、直前の土日で一気に良くなっていたというのが実際の所ではありますが、その分直前2回分の練習は本当に濃いものでした。内心多くの演奏者は今回演奏会で演奏するのに練習が間に合うのだろうかと不安でした。もっと早くから集中して取り組んでいればもっと充実した内容になったであろうということも否定できないのですが、今回の本番については演奏していて気持ちのいい瞬間がいくつもあり、弾いていて楽しかったです。
また来年度も意欲的に取り組んでいきたいと思っておりますので、どうぞよろしくお願いいたします。そして来年は是非、今年ご来場いただけなかった方々にも聴きに来ていただきたいです。長くなりましたが、どうもありがとうございました。
参考
今回の演奏会詳細は以下のとおりです。アンコールはドビュッシー作曲「小組曲」よりバレエでした。
The 8th Concert演奏曲目
Debussy/橋爪皓佐 「スコットランド風行進曲」
Faure/橋爪皓佐 「エレジー」 ※チェロ独奏:丹羽あいり
壺井一歩 「抜忍アスタリスク」 ※マンドリン独奏:望月豪
Kagel 「Musi」
Ravel/鷹羽弘晃 「クープランの墓」
(アンコール)
Debussy 「小組曲」よりバレエ
ギターの時間で練習風景を取材していただいた時の記事のリンクも掲載しておきます。
2011/11/09
第2回 ONLAB Startup School「シリコンバレー流UXアプローチ」 @ SFCに行っ てきました。
久々にSFC(慶應大学湘南藤沢キャンパス)に行ってきました。Janice Fraserさんの講演を聴くためです。詳細は以下のとおりです。講演の内容は極めて実践的で、特にスタートアップの開発者としては思うところが色々とありました。まずこの講演でのメモを書き、その後に僕の考えや感想をまとめておきます。
イベント詳細: http://atnd.org/events/21153
以下、講演概要です。
これが最初であり、もっとも大切なこと。アジャイル開発はスタートアップにとって大事なものたくさんの開発者が集まって開発する。
従来の開発のモデルは以下のようなもの。
|Rest of World | Product owner | development team |
Rest of Worldとはmarketing etc.Product ownerはみんなのことを考えなければならない。マーケティング、投資家、開発チームに何を作らせるか。これはウォーターフォール型の開発。ニーズ聞いてからやり直す。product manager は悲惨な状況。仕様書作って流す。ユーザからのフィードバックも開発チームのフィードバックも得られない。
今の開発はアジャイル。これからスタートアップをやる人は以下のようにやるべき。みんな同じ権限を持つ。
|Design | Manager | Developer |
UX, DEV, Businessそれぞれの共通部分がある。みんながownershipを感じる。
"Product Stewardship" by Tim Mc Coy
UX: ユーザを見て問題を認識し、ニーズを知ることが最も大切。ターゲットユーザと共感することが仕事。
DEV: 屋根を上げるような人(by J. D. サウンジャー)。今まではプロダクトマネージャーが出した要望に答えていた。しかし、これからは、どういうふうにどういう技術を使って最大限UXから与えられた課題に答えられるかを考える人。Developerがinnovationをおこす。
Business: Scale of Justice。難しい決断をする人。ユーザはこう言っている、しかし、ユーザの言うことを聞き過ぎるとよくない。また、開発するときに機能の優劣をつける。
この体制はバランスを重要視した体制。組織が大きくなっていくと、各部門のリードが責任の重なる部分を担当する。どの部分が偉いとかはない。3つの部門が平等に責任を感じながら、各々のスキルを活かしてユーザの課題を解決していく。
外に出す!実物にして外に出す。デザイナーにありがちなのはスケッチ書いて捨て、また書いて捨てること。そうじゃなくて、書いたことをすぐに壁に貼る。とりあえず壁に貼って、チームの他のメンバーの眼に見えることにおく。
開発者もやるべきことは一緒。シリコンバレーのスタートアップは現在の開発の進捗状況を全て表示する大きなディスプレイがある。自分の状況をみんなに共有できるようにする。そうするとチームでコミュニケーションが進む。そしてよりコラボレーションが生まれる。
Developer: build - measure -learn
流れ。流れを作ることが大事。エリックリースの本に書いてある。(※日本でも翻訳版が2012年出るとのこと。)Build - Measure - Learn、この流れが大事。「こんなにいっぱい機能作ったから進んだ!」は嘘。そうじゃなくて、会社の進展は開発者が書いたコードの行数じゃなくて、どの程度その開発者が学んだかで測るべき。開発者が学んで、よりよいプロダクトになっていく。
Designer: think - make - check
デザイナーにもこの流れがある。デザイナーの成長も測るべき。prove - improve。証明して、良くする。Janiceさんがコンサルするときにもこれを行なっている。なぜそれが必要かを証明して、良くなるのであれば実際につくる。
繰り返し可能にする。ルーチンにする。作って測って学ぶフローができたら、routineを作る。チーム内で、課題を見つけたら、フローを通して課題を検証しよう。作って検証しよう。というroutineを作ることが大事。これをすることでチームの効率が上がっていく。
繰り返しのルーチンができたら、会社が大きくなって新しい人が入ってきてもすぐに会社のフローに入れることができる。日本に企業はルーチンとかプロセスを作るのが得意だからたやすくできるかもしれない。
適切な問題を見つける。正しいことに集中して適切な問題を解く。ユーザヒアリングやユーザテストを通して、自分の製品を使って抱えている困難について解決していく。
今まではプロダクトロードマップみたいなものに基づいて開発していた。けれど最後どうなるかわからない状態で模索していく中で、ユーザの課題を知ることで新しい課題がどんどん生まれてくる。このプロセスの中で新しい課題を解決していくというサイクルをつくることが大切。
コードをリリースするときに重要なことは、目標を立てることと、数値での計測対象を作ること。ユーザの課題を解決するために作った機能がちゃんとそれを解決できているかどうかを測る。もし解決できていたら次のサイクルへ。解決できていないなら機能を外して、もう一度作りなおす。ユーザの動向を見つめる。そうすることで、スタートアップがモノを作るときに出てくるムダを省ける。小さくリリースして、いらなかったら外す、というサイクルを取るべき。
課題を解決するオプションをたくさん、素早く生み出すことが大事。Janiceさんは実際にUX, Developer, Businessの人が10分間で18のアイデアを出すということをやっている。それぞれの立場で課題が解決できないかアイデアを出す。3人でアイデアを出すことで良い案が出てくる。
18個のアイデアから1つを決める。失敗してもいい。間違える前提で決めたほうがいい。一番大事なのは、ユーザについて学ぶこと。一つのアイデアをとってうまく行かなかったら次の、と3人で決めることが大事。このプロセスに間違いはなく、重要なのは学ぶこと。
リーンスタートアップで重要なプロセスなのは、いろいろ試すこと。アイデアを試して、そのアイデアがあってるかどうかを検証すること。結果ユーザのことを学んで、次にやることを決めるというのがものすごく重要。どの仮定を検証するかを見定めるのは難しいけれど、たくさん回数をこなせばわかってくる。デザインの分野では仮説検証をするのは新しい。けれどやるべき。
ものを検証するときに真っ先に行くべきなのがユーザのところ。analyticsを使って検証することもできるが、実際にユーザがサービスを使っているところを見て、うまくいっているかどうかを検証することが大事。ユーザのところで実際に話すことで得られるインスピレーションもある。常にユーザと距離を縮める事が大事。
講演はここで終了でした。
聴いていた感想としては、ああ、やはりそうだよなぁと納得することが多かったです。プロダクトを少人数で作っていると、アジャイル開発は必須だとして、その次の段階としてユーザを見るということが意外にうまく行かず、気がついたら大きすぎるフェーズの話をしていたり、なんとなく良さそうなデザインにしてみよう、という話になりがちです。僕は講演の中での話の核は2つあると感じていて、1つはUX / Business / Developmentで責任を平等にチームとして働くという点、もう1つは仮説検証を徹底しチーム全体で学ぶという点です。まずチームとしてUXをメインに据えているのは、Lean Startupならではなのかもしれません。でもこれは本当に大事です。実際にプロダクトを作っていると、なぜこのプロダクトを作るのか、誰のためにどのように使ってもらうことを僕らは期待しているのか、実際にちゃんと意図した通りに気持ちが遷移して誘導できるだろうか、といったことをチームで話し合います。それ自体は良くても、作り始めてからは各々がバラバラに動いてしまい、反省の機会を得ずに止む無くリリースする、ということが大いにあります。要するにちゃんとサイクルを回すことができていないのです。確かにこのサイクルを回すのは大変なのです。全員がちゃんと集まって、プロダクトについて話しあい始めるとなかなか終わらないですし、そこで決まったfeatureを実装してリリースすることにはまたbusiness面での次のフェーズの話に進んでしまいがちです。
一開発者としては、ソリューションとしての技術をもっと磨かなければならないなと、背筋の伸びた一日でした。知らないことはわかっているのに、調べ尽くして、試しきれていないことがあって、それらを今すぐに1つ1つ取り組んでいきたいです。学びながら、プロダクトを作るということを継続していきます。
運営のOpen Network Labと慶應藤沢イノベーションビレッジの皆様、貴重な機会を提供していただいたことに感謝しております。あと、やっぱりSFCはいいキャンパスだなぁと思いました。SFCで学部4年間過ごしたら、かなり価値観が変わりそうです。
イベント詳細: http://atnd.org/events/21153
ユーザーエクスペリエンス(UX:ユーザー体験)は、提供するサービスに対する印象や、サービスそしてセールスの成長にも大きな影響を与える、インターネットサービスを構成する要素の中でも最も大切なものの一つです。今回のONLAB Startup School@SFCでは、このUXを設計するインタラクションデザインの第一人者としてシリコンバレーで15年間活動してきたJanice Fraser(ジャニス フレイサー)氏を講師として招き、プロダクト開発デザインについてのイベントを開催します。
≪Janiceプロフィール≫ 起業家、ウェブとモバイルのUXデザイナー。 15年に渡るシリコンバレーでのスタートアップの成功と失敗の 両経験を活かし、アーリーステージと大企業をターゲットとし た経営コンサルタントとして活躍している。ウェブサービスの デザインを手がけるAdaptive Path社の共同創業者で、初代 のCEOを務めた。
在職期間中、Adaptive Path社の収益とスタッフを3倍に増やし、 開発したプロダクトをGoogle社に売却した。「Ajax」という言葉 の命名者でもある。現在、Haas, Kellogg, Stanford, Presido Graduate School of Management等、数多くの大学やカンファ レンスで講演を行う。
日 時: 2011年11月8日(火) 18:00開場 ~18:30開始
場 所: 慶應義塾大学湘南藤沢キャンパス τタウ11教室
参加費: 無料
定 員: 100名 (主に学生)

以下、講演概要です。
演題: 10 principles of Lean UX
- Design + Prod. Mg. + development = 1 product team
- Externalize!
- FLOW: think/make/check
- Repeatable and routinized
- Solve the right problem
- Gobal-driven and outcome-focused
- Generate many options
- Decede quickly and hold decisions lightly
- Recognize hypotheses & validate them
- Research with users is the best source of information ( & inspiration)
1. Design + Prod. Mg. + development = 1 product team
これが最初であり、もっとも大切なこと。アジャイル開発はスタートアップにとって大事なものたくさんの開発者が集まって開発する。
従来の開発のモデルは以下のようなもの。
|Rest of World | Product owner | development team |
Rest of Worldとはmarketing etc.Product ownerはみんなのことを考えなければならない。マーケティング、投資家、開発チームに何を作らせるか。これはウォーターフォール型の開発。ニーズ聞いてからやり直す。product manager は悲惨な状況。仕様書作って流す。ユーザからのフィードバックも開発チームのフィードバックも得られない。
今の開発はアジャイル。これからスタートアップをやる人は以下のようにやるべき。みんな同じ権限を持つ。
|Design | Manager | Developer |
UX, DEV, Businessそれぞれの共通部分がある。みんながownershipを感じる。
"Product Stewardship" by Tim Mc Coy
UX: ユーザを見て問題を認識し、ニーズを知ることが最も大切。ターゲットユーザと共感することが仕事。
DEV: 屋根を上げるような人(by J. D. サウンジャー)。今まではプロダクトマネージャーが出した要望に答えていた。しかし、これからは、どういうふうにどういう技術を使って最大限UXから与えられた課題に答えられるかを考える人。Developerがinnovationをおこす。
Business: Scale of Justice。難しい決断をする人。ユーザはこう言っている、しかし、ユーザの言うことを聞き過ぎるとよくない。また、開発するときに機能の優劣をつける。
この体制はバランスを重要視した体制。組織が大きくなっていくと、各部門のリードが責任の重なる部分を担当する。どの部分が偉いとかはない。3つの部門が平等に責任を感じながら、各々のスキルを活かしてユーザの課題を解決していく。
2. Externalize!
外に出す!実物にして外に出す。デザイナーにありがちなのはスケッチ書いて捨て、また書いて捨てること。そうじゃなくて、書いたことをすぐに壁に貼る。とりあえず壁に貼って、チームの他のメンバーの眼に見えることにおく。
開発者もやるべきことは一緒。シリコンバレーのスタートアップは現在の開発の進捗状況を全て表示する大きなディスプレイがある。自分の状況をみんなに共有できるようにする。そうするとチームでコミュニケーションが進む。そしてよりコラボレーションが生まれる。
3. FLOW: think/make/check
Developer: build - measure -learn
流れ。流れを作ることが大事。エリックリースの本に書いてある。(※日本でも翻訳版が2012年出るとのこと。)Build - Measure - Learn、この流れが大事。「こんなにいっぱい機能作ったから進んだ!」は嘘。そうじゃなくて、会社の進展は開発者が書いたコードの行数じゃなくて、どの程度その開発者が学んだかで測るべき。開発者が学んで、よりよいプロダクトになっていく。
Designer: think - make - check
デザイナーにもこの流れがある。デザイナーの成長も測るべき。prove - improve。証明して、良くする。Janiceさんがコンサルするときにもこれを行なっている。なぜそれが必要かを証明して、良くなるのであれば実際につくる。
4. Repeatable and routinized
繰り返し可能にする。ルーチンにする。作って測って学ぶフローができたら、routineを作る。チーム内で、課題を見つけたら、フローを通して課題を検証しよう。作って検証しよう。というroutineを作ることが大事。これをすることでチームの効率が上がっていく。
繰り返しのルーチンができたら、会社が大きくなって新しい人が入ってきてもすぐに会社のフローに入れることができる。日本に企業はルーチンとかプロセスを作るのが得意だからたやすくできるかもしれない。
5. Solve the right problem
適切な問題を見つける。正しいことに集中して適切な問題を解く。ユーザヒアリングやユーザテストを通して、自分の製品を使って抱えている困難について解決していく。
今まではプロダクトロードマップみたいなものに基づいて開発していた。けれど最後どうなるかわからない状態で模索していく中で、ユーザの課題を知ることで新しい課題がどんどん生まれてくる。このプロセスの中で新しい課題を解決していくというサイクルをつくることが大切。
6. Gobal-driven and outcome-focused
コードをリリースするときに重要なことは、目標を立てることと、数値での計測対象を作ること。ユーザの課題を解決するために作った機能がちゃんとそれを解決できているかどうかを測る。もし解決できていたら次のサイクルへ。解決できていないなら機能を外して、もう一度作りなおす。ユーザの動向を見つめる。そうすることで、スタートアップがモノを作るときに出てくるムダを省ける。小さくリリースして、いらなかったら外す、というサイクルを取るべき。
7. Generate many options
課題を解決するオプションをたくさん、素早く生み出すことが大事。Janiceさんは実際にUX, Developer, Businessの人が10分間で18のアイデアを出すということをやっている。それぞれの立場で課題が解決できないかアイデアを出す。3人でアイデアを出すことで良い案が出てくる。
8. Decede quickly and hold decisions lightly
18個のアイデアから1つを決める。失敗してもいい。間違える前提で決めたほうがいい。一番大事なのは、ユーザについて学ぶこと。一つのアイデアをとってうまく行かなかったら次の、と3人で決めることが大事。このプロセスに間違いはなく、重要なのは学ぶこと。
9. Recognize hypotheses & validate them
リーンスタートアップで重要なプロセスなのは、いろいろ試すこと。アイデアを試して、そのアイデアがあってるかどうかを検証すること。結果ユーザのことを学んで、次にやることを決めるというのがものすごく重要。どの仮定を検証するかを見定めるのは難しいけれど、たくさん回数をこなせばわかってくる。デザインの分野では仮説検証をするのは新しい。けれどやるべき。
10. Research with users is the best source of information ( & inspiration)
ものを検証するときに真っ先に行くべきなのがユーザのところ。analyticsを使って検証することもできるが、実際にユーザがサービスを使っているところを見て、うまくいっているかどうかを検証することが大事。ユーザのところで実際に話すことで得られるインスピレーションもある。常にユーザと距離を縮める事が大事。
講演はここで終了でした。
聴いていた感想としては、ああ、やはりそうだよなぁと納得することが多かったです。プロダクトを少人数で作っていると、アジャイル開発は必須だとして、その次の段階としてユーザを見るということが意外にうまく行かず、気がついたら大きすぎるフェーズの話をしていたり、なんとなく良さそうなデザインにしてみよう、という話になりがちです。僕は講演の中での話の核は2つあると感じていて、1つはUX / Business / Developmentで責任を平等にチームとして働くという点、もう1つは仮説検証を徹底しチーム全体で学ぶという点です。まずチームとしてUXをメインに据えているのは、Lean Startupならではなのかもしれません。でもこれは本当に大事です。実際にプロダクトを作っていると、なぜこのプロダクトを作るのか、誰のためにどのように使ってもらうことを僕らは期待しているのか、実際にちゃんと意図した通りに気持ちが遷移して誘導できるだろうか、といったことをチームで話し合います。それ自体は良くても、作り始めてからは各々がバラバラに動いてしまい、反省の機会を得ずに止む無くリリースする、ということが大いにあります。要するにちゃんとサイクルを回すことができていないのです。確かにこのサイクルを回すのは大変なのです。全員がちゃんと集まって、プロダクトについて話しあい始めるとなかなか終わらないですし、そこで決まったfeatureを実装してリリースすることにはまたbusiness面での次のフェーズの話に進んでしまいがちです。
一開発者としては、ソリューションとしての技術をもっと磨かなければならないなと、背筋の伸びた一日でした。知らないことはわかっているのに、調べ尽くして、試しきれていないことがあって、それらを今すぐに1つ1つ取り組んでいきたいです。学びながら、プロダクトを作るということを継続していきます。
運営のOpen Network Labと慶應藤沢イノベーションビレッジの皆様、貴重な機会を提供していただいたことに感謝しております。あと、やっぱりSFCはいいキャンパスだなぁと思いました。SFCで学部4年間過ごしたら、かなり価値観が変わりそうです。
登録:
投稿 (Atom)