2012年3月22日木曜日

AgileUX NYC 2012 Redux in Tokyo - パネル・ディスカッション




Agileuxnyc_original

2012/03/14に行われた『AgileUX NYC 2012 Redux in Tokyo』のノート。これは後半のパネル・ディスカッション分。なんだか刺激的でいいですよね?


パネリスト



・和波俊久氏 / LeanStartupJapan

・樽本徹也氏 / 利用品質ラボ

・川口恭伸氏 / アギレルゴ・コンサルティング

・坂田一倫氏 / 楽天





◆自己紹介


◇樽本氏

・開発がどんどんアジャイルになってきている。

・開発がウォーターフォールだからUXやUCDもウォーターフォールになっていた。開発がアジャイルになったらUXやUCDもアジャイルをやらざるを得ない。

・UXからアジャイルを仕掛けているわけではない。

・アジャイルに巻き込まれると今までのやりかたが通用しなくなる。その日は日本でも近い。

・UXをやっている人は早くアジャイルを勉強した方がいい。


◇和波氏

・スタートアップとアジャイルには決定的な違いがある。アジャイルはプロジェクトに適用するものなので絶対に終わりがあるが、スタートアップは絶対に終わらない。
・中身の動かし方は基本的に一緒で、非常に親和性が高い。

・リーン・アジャイル・顧客開発それぞれの源流をまとめたのがリーンスタートアップである。
・顧客開発を先にしないと駄目、というウォーターフォールへのアンチテーゼが元々のリーンスター・トアップ。ここには開発は全く含まれていない。
・Eric Riesはリーンスターアップに開発プロセスを追加した。


スタートアップ側からすると、どうやって終わらせていくか?というところに興味がある。




◆パネル・ディスカッション


◇UX(デザイナー)の悩みとリーンスタートアップ

坂田 「社内でもアジャイル勢が増えている。自分はデザインだが、デベロッパの方でも勉強会が頻繁に行われていて、デザインがいなくてもできるのではないか?という風になってきている。カードソートやストーリーマッピング、そういう手法がどんどんできるようになっている。で、スクラムマスターとかプロダクトマネージャーさえいれば、そこからイテレーションやスプリント・顧客の開発の方法を立てるといったことは回していけるという認識がある。さっきの話と繋がるのだが、つまり、デベロッパとビジネスだけでもプロジェクトが周ってしまうということ。たしかにそちらの方が早い。

我々みたいにブラックボックスでぶっこむと「金も時間もかかるじゃん」ということで、結果的に(周りが)離れていってしまう、という危機感がある。我々も今回のようなセッション等を設けて「アジャイルエクスペリエンスデザインという本の中にも、UXという手法が取り入れられているんですよ」といいったことなど「実は普段からこういうのをやっていたんです」っていうのを、どんどん打ち明かしていく必要がある。

最近ではユーザビリティテストというプロジェクトに被験者を1週間に1回呼び、そこにステークホルダーとエンジニアを呼んで、さっきのペアインタビューに近いのだけど、やって、精度を高めていくという。ことをじょじょにやり始めている」


川口 「聞く限りでは、デザイン(UX)とデベロッパが分かれていますよね。ビジネスというのは何をやっているんですか?」


坂田 「さっきの話でいうと、要件を作っている。ウォーターフォール型っていうのがまだあって、要件を出して、というところをやっている。技術的なフィーザビリティーっていうのを、デベロッパが検証して、デザインに落とすと」


川口 「ビジネス・デベロッパ・UXの3つがあると …もう少し頑張ったらリーンスタートアップじゃないですか」


坂口 「リーンスタートアップに話を戻せば、このの構造はたしかに理想。プロダクトストアドシップを考えたときに、ビジネスデベロップメントという舞台と、カスタマーデベロップメントという舞台と、デベロッパという舞台と、三つの舞台があると提唱した人物がいて、まさにその通りの図になっている。 …が、うまくいっていないというのが現実である」


樽本 「なんで3つに分けているのか? 一緒に勤務はしていなのか? プロジェクト毎には?」


坂田 「プロジェクト毎になっているが、入るステージがそれぞれの担当で違うというのが現実」


樽本 「各々3人ずつくらい引っこ抜いてきて、7-8人のチームを組んで、プロジェクトを回すっていうのが一番いいような気がするが? 同時にやればリーンUX。本当のアジャイルUXになる」


川口 「ちょっとしたことって感じですよね」


樽本 「うん。ちょっとしたこと。やれるじゃないですか」


川口 「でも、そんなことはないと思います(笑)」


樽本 「だから分かれてるからおかしいだけで、坂田氏はもともとUXですけど …今はこのプロジェクトのチームメンバーです。あなたはデベロッパだけれども、今回はここのチームメンバーです。で、あなたはビジネスだけど、でもこのプロジェクトはここにいてくださいと。で、全員でヨーイドンでスタートする。ユーザリサーチから全員でやると。で、開発の終わりまでビジネスも全部付き合う …という風にやると、いま海外でやろうとしていることになります。

日本ではそこが違って、それぞれドキュメントを渡したりとかですね。1つのチームになってしまえば、お互いにハッピーに仕事ができると思うんですけどね。それは駄目なんですか?」


◇アジャイルと決算

和波 「中身のやり方って、どんどん進化させて時代のスピードにあわせていくべきだとは当然思うんですけど …実は先週、僕の方も大企業で、リーンスタートアップは採用できるのかみたいな勉強会をやってきたんですね。その中で、すごく心に響いた、ここを乗り換えなければ駄目なんだというのがあったんです。

株式会社である以上、決算を迎えなければいけないと。

で、決算を迎えるということは、動かしたプロセスに対して、何らかの定量的な結果を報告しなければいけない、というのがあるんです。サービスを開発しているときに、じゃあそれってどうやって定量的に図るんですかっていう、まさにブラックボックスの中で何やってるんだっていうのを、どこかのタイミングでは必ず定量報告をしなければいけないという。そこはつらそうだなーと思いましたね。
そこを乗り越えられるような、何か報告の仕組みのようなものができると、もしかしたら導入が楽になるのかな、という感じでしたね」


川口 「逆に、決算に紐付いた予算という仕組みが実は歪みを生むという …その、ビジネスに合ってない決算期だったりすると、歪みを生むので。

もう1つのムーブメントとしてはアジャイルの方で言われている、Beyond Budgetting Round Table (BBRT)っていう。2003年くらいなんですけど、予算を撤廃してしまった会社というのが世の中にはあるらしいと。決算は当然でるんだけど、それは結果だと。だから年間の予算をたてるなんて
全然当たらないじゃん、みたいな。ただしマイクロな計測はものすごくやって、さっきの …経営のダッシュボードを常に更新することで、経営の健全性は保てるんだから、予算いらないんじゃね? というムーブメントがあるらしいという」


樽本 「それはアジャイルなの? 完全に?」


川口 「アジャイルには寄せているけど、アジャイルが発信ではないらしいです。予算を作るのを止めよう …超える、みたいな。」


樽本 「これはいいね」


和波 「その点スタートアップの場合、すごくわかりやすい。レベニューあげるか、次のラウンドでお金を作るか、どちらか適えないと死んでしまうという。単純に非常にわかりやすい、と。バーンレートといって、いかに資金(お金)を使わないで先まで生き延びるか、その間に顧客を掴むか、という。いかにバーンレートを先延ばしにしている間にイノベーションを起こすか、という戦いなので」


坂田 「すいません。このままずっと話をしていると質問に答えられないので… 1つくらい行きましょうか」



◆質疑応答

坂田 「『顧客開発のためのPDCAについてなんですけど …何かインプットがあれば共有いただきたいです。特に顧客セグメントの仮説立案のtipsやスケーラビリティを意識した検証方法などありましたら、お願いします』といったところです。多分、リーンとか意識しやすいと思うんですけど」


和波 「リーンスタートアップを実際に薦めてみると、デモグラとかジオグラとか関係なくなっていって、とにかく課題にセグメントしていく以外にないと思ってるんですけど …そういうことですかね?」


川口 「あと、今回の資料にはでませんでしたけど、37SignalsっていうRuby On Railsで有名な会社が出している『小さなチーム、大きな仕事』。ユーザとペルソナをがーってデータで集めるよりは、自分がペルソナになるのが一番早いって、自分が使いたいと思うものからまず仮説を立脚するっていうのが早い、みたいなことが書いてありました」


坂田 「あと、去年、Janice FrasierさんというLuxrのファウンダの1人が日本にこられたときに、リーンワークショップというイベントがありまして、そこでやられていた方法というのが、正にペルソナを作って検証していくという方法でした」



◇インタビューは強力


坂田 「…(Janice Frasierさんリーンワークショップは、)ずっと6時間くらいやっていたんですけど、そこでやられていた方法というのが、「自分が使ってもらいたいサービスを1つ考えてください」そして「そのサービスを使うであろうセグメントをプラグマティックペルソナで4つの枠にざっとでいいので書いてください」と。で、そのユーザーが本当にいるかどうかというセグメントの検証のために、インタビューをしにいってくださいという。

で、その、さっきのLane Hallayのペアインタビューでもあったんですけど、それでペルソナをどんどん進化させていって、本当に我々がこれ使ってほしいユーザ・セグメントっているんでしたっけ? っていうところからそもそも入るっていう。

そのペルソナの内容があっているかあっていないか …というか、本当に実在するか否かっていう考えではなく、そのセグメントって本当にいるんですか?っていうところから入っていくのがポイントでした」


川口 「ペアインタビューのときに、今日はちょっとスライド乗ってないんですけど、実はLane HallayとJeff Pattonが2人でインタビューをした写真とかが出てて、僕的にはすごいウキウキして見てたんですけど、あのー、やはり、開発者でないとわからないアイデア・解決・問題もある。で、UXの人だけでインタビューするっていうのは、やっぱりその方が早いんですね。それを持って帰ってきて、その場で、後でトークするという方が解決が早いんで、やっぱり壁があると巻けですね。

で、アジャイルの人達ってすごくて、もともとアジャイルの考え方の一つが完璧なドキュメントを求めない、っていうんですけど、それは何故かというと、求めない変わりに、人と人が話してコミュニケーションするという、っていうのを重要視していて、その方が100倍早いって言っていて、そちら側にみんな吸い寄せられてる感じはしますね。どちらが偉いという話ではないんですけど。そういうことはすごいいいアイデアだと思います」


樽本 「インタビューはUXの専門家でなくてもできるんですよ。Contextual Inquiry(コンテキスト調査法)っていって。ちょっとやり方を教えて挙げれば、開発者、自分でもできちゃうんですよね。それでね …多少インタビューのテクニックがひどかろうと、だいたいデータはとれるんです。一番大事なのは、できればインタビューを全員で聞くのが一番いいんです。

誰がインタビューしても構わないけど、他の関係者も全員そのインタビューを聞くと。そうすると、いろんなところでアイデアが出てくるンですよ、製品のアイデアが。で、勿論、全てのセッションにチーム全員を同席させるっていうのは、これかなりのコストになってくるので、時間の都合もつかなくなるのでね。

いまよくやるのが、録音するか、それかもう、その場で、みんなブラインドタッチできるしょ? 入力しちゃうんですよね。テキストをばーっと。適当に。で、その速記録をみんなに渡して、あとその、録音とセットにして、イントラネットかなんかにあげといて、そしてみんな自由に見られるようにしてあげると。で、そのインタビューの記録を読んで、そのインタビューの様子をビデオや音声で聞いて、で、ブレインストーミングをやるんです。そうするとぼっこぼこアイデアが出てくる。エンジニアの方から」



◇リーンとリリース


川口 「この中でユーザーテスティングとか、…開発に関しても、アジャイル以前のウォーターフォールを目指していたときは、どちらかっていうと、科学的な根拠、大数の法則だったり、5人調査しないとそれは知見にならないとか、考え方から、もっと少ない人数でいいじゃんと。アイデアが得られるなら、少ない人数でもどんどんと定期的にやっていこうよ、という流れがあります」


樽本 「そうですね、アジャイルUXとかアジャイルUCD、リーンUX、それはもう全てその考え方ですね。精度よりもまずアウトプットを出してしまう。データの精度をあげるよりはまずアウトプットを出して、それを早くユーザで検証すると。

とにかくアイデアの数勝負なんですよ。どんなに素晴らしい調査データがあったからって、アイデアでなきゃしょうがないじゃない。それでアイデアなんて、どの瞬間にでるかわからないんだから、
1人の話を聞いてる頭の5分でアイデアがでたら、それで充分役に立つわけだから。それで必ず成功するわけではないけども、でもアイデアを出すことがまず大事で、そのアイデアを紙のまま置いてたって、そのユーザには仕えないんだから。

早くコードにして、動く形にしてユーザに見せて、試してもらって、それでそれがうけるかどうか。それ検証した方が早いじゃないですか」


川口 「アウトプットからアウトカムっていうのが正にそれで、アウトプットっていうのは精度の高い、すごく品質の高いもの。でも品質が高くたって、使われないなら意味ないじゃんって」


樽本 「そういうこと」


川口 「その無駄を減らして、リーンにしようということなんですね」



◇結果が全て。データを集めるより作る


樽本 「結果が全てなんですよね。今は。どんな立派な調査やったって、製品売れなきゃしょうがないでしょ?って。だからリーンスタートアップなんですよ。製品作るところをスティーブ・プランクも書いているし、マーティン・ケイラーも全部書いているんだけど、製品みんなで一生懸命作ったってね、売れなかったらどうするんだって。売れなかったらあなたの苦労全部無駄になるでしょう、って。だったら作りながら売ったらどうか、って。売れるものちゃんと考えながら作ったらどう、って。それがリーンスタートアップの考え方ですよね?

だから製品開発に対して顧客開発って言葉を使っているんです。今までは製品開発が終わってから、営業するって言っていた。それじゃ間に合わないっていう。その製品もしかしたら間違っているかもしれないよって。お客さん欲しいと思ってないかもしれないよって。だから作りながら売ったらどうって。そしたら、売れるかどうかすぐわかるからって。売れなかったらピボットしちゃえって。

だからデータ集めるより作れって。早くコード書いた方がいいんだって」


和波 「最初からそのつもりでいるっていうのがいいですよね。そうすればいいんですよね。ユートリ(ユーザーストーリ)とかも最初から、何か学びに行くんだって言う気持ちがちゃんとセットされていると、どんな人でもちゃんとインタビューできているという。そういうことですよね。




◇AgileUXはどんどん進化している


樽本 「そのとおりです。もうね、インタビューなんて誰でもできる。Contextual Inquiryなんて、エンジニアに教えればどんどんできるようになる。どんどん教えてるよ。だから、UXの人これから大変ですよ。開発者がみんなUXの技術見につけちゃうから。

さっき坂田さんが言っていたよね? 彼らだけでできるんじゃないか? って。できるようになってきてるんですよ。UXだけじゃ食っていけないはずです。絶対に」



川口 「すごいですよ。その話。僕がリアルに感じるのは、AgileUXの最初の頃って、UXの部署、専門家の人達と開発の専門家の人達をどうやって組み合わせるかっていうところで、最初はパラレルトラックアプローチっていうのが割と言われていたんです。

どうやってやるかっていうとスプリント・イテレーションで期をあわせてクロスに、ユーザ調査の成果がでたら、それは次のスプリントで開発にわたって、開発が終わったら次のスプリントでユーザのテストをする …UXチームに渡すと。

これを組み合わせると、こう、メッシュ上に仕事を受け渡して、仕事がうまく一緒にできるよ、と。これが頭書言われていたパラレルトラックアプローチなんですけど、今回のAgileUXのカンファレンス、誰もパラレルトラックアプローチって言ってないんですよ。

みんな言っているのはチームの中にどうやってUXが入るのかというのと、UXの人達がどうやってプログラムを学ぶか、とか。どうやってビジネスラウンドと一緒にやっていくかっていう話をしていて、もう、全然くっつき具合がだいぶ進んできたな、という感じがします。この三年くらいでだいぶ変化がでてきた気がします」




◇コアユーザ・エヴァンジェリストユーザを掴まえる


坂田 「話は戻るんですけど、さっきのユーザーインタビューで出ていたジャニスさんのリーンワークショップの中にヒントといいますか、1つこうやったらいいんじゃない? というのがあったんです。

インタビューのときに、ペルソナっていうセグメントって本当に実在するのか、という検証をするっていうのがあったんですけど、あわせてコアユーザーかどうかを見極めなさいっていうアドバイスを頂いて …まさにリーンだと思うんですよね。本当にこのサービスを使ってくれるという、需要があるのだろうか? というところを、質問を通してコアになるかなりえないかを発見していく。で、コアになるっていうフラグを立てたら、その人が本当に使うであろうサービスの領域を定めて。

多分それがMVPだと思うんです。なんでかというと、ピボットするというのは、ビジネスモデルを変えるという話に関わるんですけど、極端な話、全部変えたら元も子もない。どこまでを変えるかというところが、おそらく質問として上がってくると思うんですよ。ピボットをどこまですればいいんだ? という話は僕自身も(考える必要が)あると思うんです。ピボットする軸の振り幅っていうのを見極める必要があって。

それは、先ほどのコアユーザが逃げないような、引き続き使ってもらえるような、最低限の自分たちのコアとなるもので、それを見極めなさいっていうのがありましたね」


和波 「すごいわかりますね。あの、間違った人にインタビューしていると、すごく悲しい気持ちになってくるんです。本当に、この人の話は、あと何分聞こうがたぶん意味はない、というのが途中でわかる瞬間があったりすると悲しくなるんですよ。スティーブ・プランクはエヴァンジェリストユーザというものを見つけなさいということを行っているんですよね。で、その人達は、とにかくそのサービスって言うのを早く世に生まれて欲しいと、心から切に願っている人達。で、そういう人達が必ずいますという話があるんです。

ちょっと、具体例なんですけど、僕の場合は事業開発の支援というところをやっているので、スタートアップの人達ってものすごく世の中に対して新しいバリューを提供しようか、というのを頑張っているんですね。

でも、僕から見ると、そのサービスが本当に拡大するか否かって、例えば、BtoBのビジネスとかだと、企業さんがそれを採用する障壁っていうものをどんどん下げてあげる。そうすると、すーって採用できたりするんだけど、その機能を一向に開発しようとしないんですね。だから『たしかにあったら面白いなーと思うんだけど、うちの会社には馴染まんなー』と思ったら絶対採用しない、みたいなところが気づかないんですよね。ずーっと気づかないまま。

だから、そういうインタビュー繰り返しちゃうと、何を作れば採用障壁が下がるんだ、というインタビューをしなければいけないということに気づかぬまま、ずっとお金を浪費していくっていう、そんなパターンがあったりするんですね」


川口「最近、カンファレンスのインタビューで増えていたのが『あなたはこのカンファレンスを他の人に薦めたいですか』って質問で、これ正にエヴァンジェリストユーザがどれだけ付くか、ファンになってくれるか、っていうのを探している。すごく増えましたよね、最近。これ(AgileUX NYC 2012)のインタビューもありましたよね?」


坂田「はい」


川口「勧めたいですか?っていう」


坂田「そうですね。ぜひ薦めたいですって(答えました)」


川口「エヴァンジェリストユーザが1人掴まる(笑)」







和波俊久様、樽本徹也様、川口恭伸様、坂田一倫様、お疲れ様でした。


0 件のコメント:

コメントを投稿