ラベル リーン の投稿を表示しています。 すべての投稿を表示
ラベル リーン の投稿を表示しています。 すべての投稿を表示

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人掴まる(笑)」







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


2012年3月16日金曜日

AgileUX NYC 2012 Redux in Tokyo - AgileUX NYC ハイライト


Agileuxnyc_original

2012/03/14に行われた『AgileUX NYC 2012 Redux in Tokyo』のノート。これは前半のAgileUX NYレポート分。非常に濃かったです。



◆Eric Burd

◇same problem statement

1. アジャイルやリーンはテクノロジやデザインというチームにフォーカスを当てがち。

2. だが、HRやマーケティング・セールスなどの関係部署にもアプローチする。

3. 全社的にみて共通の課題はなんだったかということを重視し、定義する。


◇ステークホルダーをどう巻き込むか?

1. ステークホルダーは忙しいのでなかなかプロジェクトに巻き込めない。

2. ランチはあるので、このランチ時間を借りる。

3. ユーザを呼んでその一時間でセッションをする。

4. これを週一で行ない、ユーザのフォローをしている。


◇スモールウィンを探す

・小さな成功を社内に探し、成功させ、エッセンスを社内に確立する。

・どこまでいったらこれサクシードだよねっていうのを見極めて探す。

・顧客やらビジネスプロジェクトやら、どこから導き出されたものかって言うのを整理する。




◆Phin Barnes

◇investing in design

デザインに投資するという、インベスターによる話。

・社内に導入するには、果たして私達にできるのだろうかというハードルや壁がある。

・アジャイルという言葉になじみがある人達にそういう壁がある。

・スキルセットではなくマインドセット。

・デザインはカスタマーデベロップメント(顧客開発)という原点をリードする立場にならないといけない。

・じゃあ組織を動かすものってなんだろう?定性データ?定量データ?

・データを見据えるだけではなくて、どのようなインサイトが組織内に成果をもたらし動かすのかっていうのを考えていく必要がある。

・(単なる)成果をもたらすものとしてではなく、持続的な文化として発信していく。

・リーンスタートアップでいうところの、カスタマーディスカバリー・バリデーション・クリエーション・ビルディングっていうのを回していくというのを我々の作業に落とすと、課題定義・スケッチ・プロトタイプ・ソリューションの改善・最適なソリューションの開発っていうのを回していく。そういったことを推奨していた。


  ※ Phin Barnes の発表について、坂田氏が気になった点

   共通課題をどう見せていくかというのでダッシュボードが採用されていた。
   ・数字は継続的にアップデートされていて、全社員で見れるようになっている。
   ・ダッシュボード化 = tamgible(触れるようになっている)
   ・この数字をカスタマーデベロップメントサイクルで改善していく
   ・↑が結果的に1つの文化になっていく。


◇定量データは、もはや遅れている

・我々はデザインドリブンの会社であり、もはや遅い。全然響かないし新しくない。

・次は、定性的な要素を加え、コンテキストを導入することが人を動かす力になるのではないか?


※アジャイルではダッシュボードが流行っている。リーンスタートアップでも最後のメトリクスが重要視されていて、定性定量も含めてインフォグラフィックスのような一枚絵、しかも自動で更新されるものをみなで見て判断を下す。そういう文化である。



◆Josh Seiden

◇要件を仮説に置き換える

1. アジャイルやリーンのコンセプトを社内に導入するにはそもそも要件という考え方じゃ駄目。

2. 要件は断固たるもので、いくら我々がUCDプロセスとか回したとしても変えることは不可能or困難。

3. 仮説はもちろん仮説なので正しくない。検証していく必要がある。

4. これにより不確実性がエッセンスとして取り込まれる。

5. それゆえにテストしたり学ぶ姿勢をチーム全体が保ってくれる、という力がある。




◇要件について

1. ビジネス責任者のこれがやりたい、というニーズはそのまま要件として認識される。

2. それを元に作業する人達は、その背景にあるユーザやマーケットニーズを知るすべが無い。

3. 要件ではビジネス側が要件を考えて、それを開発やデザイナが作るという風になる。

4. フェーズが完全に切り分けられてしまうが、それはウォーターフォールではないか?



◇ケーススタディ - アプリのインストーラー

1. 我々の顧客は無料で提供されているインストーラに価値を見出すのではないか?という仮説。

2. 具体的に何を造ればいいかを頭に浮かべる。

3. それをいくつかのsub-hypothesisにブレイクダウン。

4. テストを早く回せる感じのミニシナリオを作る。

5. インストールのプロセスが早ければ、顧客は無料のアプリをダウンロードするのでは?となる。

6. 仮説は検証するため、mbpで最小限にこれを達成する方法を考える。

7. インストーラをサポートするような画面や機能が必要なのではないか?となる。

8. 結果として、最初の要件とは全然違っている。

※mbp - minimum variable product。リーンスタートアップの概念。



◆Lane Halley

もともとデザイナー。どうやったらアジャイルと一緒にやれるのか?を考えてきた人。

デザインの立場になってアジャイルやリーンスタートアップをとらえてみた、という話。


◇デザインのアプローチが変わってきている

・デザインをチーム全体の責任にする必要がある。

・デザインというロールが変わってきている。

・部署や役割という垣根を越えたデザインが必要 = cross functional pairingを使う。

・デザイナーはプロジェクトのファシリテーターになるのではないか?

・デザインしているプロダクトやサービスの担当・責任を任せることができるチーム(プロダクトオーナーチーム)を作る。


◇cross functional pairing

1. デザイナ(特にフロント・ミドルエンドと呼ばれる場所のエンジニア)とペアで開発の人が実際に一緒になって作っていく。


2. 結果的に、クイックにビジュアルにすぐに形になる。

3. で、協力的・持続してcontinueousというのが可能になった。

※crossやコラボレーションがキーワード。

※ステージの最初からペアで行うなら、チーム体制を意識する必要がある。



◇インタビュー法

・early provisional persona - 本当に影も形も無いような、雑な仮説ベースを作る。

そういうセグメントがいるのでしたっか?というのをインタビューする。

・pair interviewing - インタビューはデザイナーだけではなく全員でやる。

・mutliple note takers - 1人に任せてノートを取らせない。あらゆる視点からノートをとり、気づきをシェアするという、

UXだけじゃなくてデベロッパも一緒にやる。同じ cross function paring の人もいれる。



◇プロダクトオーナーチームとcross functional paring は彼女達が作った仕組みに密接に関連している

1. プロダクトサービスの担当とコアのUXの人達と、開発者はアーキテクトくらいしか入っていない。

2. そのチームが製品全体を設計している。

3. デザインの骨格共通のデザインの部分も設計している。

4. ↑のフェーズが終わったら、各モジュールを作る。


l※デザインのコアをやった人がそのまま降りて、チーム(開発者)の横にいるようなペアを組む。


※ペアプログラミングはアジャイルでは良く言われるが、ここは、開発者同士ではなくてデザイナとやるという新しいやり方でやっている。



◆Anders Ramsay

アジャイルが良くするものは何かを突き詰めたものは、UXRagbyという表現になるのではないか。

◇リレー

1. トラディショナルな開発式、WaterFall。

2. 一人一人が走って、次の人にバトンを渡してじゃあどうぞって感じで、ハンドオーバーをしている。


◇ラグビー

1. 数人単位でボールを追いかけていて、トライをして、またトライを狙いにいくみたいな感じで連続したプレイを続けるスポーツ。

2. まさにアジャイルってそれなんじゃないか?と。

3. ラグビーのパスは言ったりきたりするが、まさにチームでもそう。

4. ペーパープロトから開発、というプロセスもバックアンドフォースのパスといった感じで、やっていくべきでは。



◆Jennifer Gergen

仕事をするためにプログラミングを自分で学んだということで拍手喝さいを浴びていた。

アジャイルUXをUXあるいはデザイナー側から対面している人。


◇デザイナーとプログラミング

・全部のプログラムを組めるようなスキルがあるわけではない。

・自分が少しプログラムを組めることで、会話がすごく円滑になる。

・ものすごく早くアウトプットが出る。


◇開発とデザイナのクロスファンクショナルペアリングをどうやってやっていくべきか

・イテレーションは機能とかページの開発には優れている。

・イテレーションは影響範囲が測定しづらい大きなデザインの変更には向いていないのでは?

・策としてAToMICデザイン(asset to markUp iterate colaboration)を提案する。



◆まとめ


◇UX/UXデザインはどう振舞うべきか -> demystifyする

1. 現在のUXデザインは、中で何が行われているかわからないブラックボックス状態である。

2. チームメンバーUXデザインってマジックみたいだよね、と考えている。

3. デザインは一筋縄ではいかない。いろいろ考えながら一本の縄を歩いているような状態。

4. だからこそ、ブラックボックス状態では納めない。

5. 頻繁に成果物を見せながら学んだことをプラスアルファしてシェアしていく必要がある。


◇共通言語で話す

・医者のように、他人が理解できる言葉で話すということを推奨。


◇要件と仮説


・要件は仮説になるべき。

・デザインは仮説を検証する実験になるべき。

・成果物は実験の結果。



◇その他

・UXにはメンタルシフトが必要。

・我々が日々していることを、スキルセットではなくマインドセットへのメンタルシフトを通して現場レベルに落とし、実行していく時代なのではないか?



◆補足

話の中に出てきたけど、放り込む場所が無かったものをここに記載。


◇アウトプット(成果物)とアウトカム(結果)の違い

・アウトプットはできたもの。

・アウトカムはそれを使ってユーザが何を得たか。


◇Jennifer Gergenがプログラムを学んだという件について

・デザイナーがプログラミングを学んでいるということに対して需要が高まってきている。

・デザイナーがプログラミングにシフトしつつある。


◇デザイナーは開発から招待されているが、デザイナーは彼らを招待していないのではないか?

・プロセスやコンセプトを理解して一緒に作業しよう、という風に招待をしていないので、コラボレーションが難しくなっているのではないか?






坂田一倫様、川口恭伸様、お疲れ様でした。