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月18日日曜日

『Developers Summit 2012』2月17日(金) - 2日目メモ

今更ながら、『Developers Summit 2012』2月17日(金) - 2日目メモ。




17-C-1 Business Model generation


◆ビジネスモデルとは

・全ての(会社だけではなく、NPOやその他のものも含めた)組織が持っているもの。

・組織がどう回っているのかを書いたもの。

・誰の為にどのような価値を生み出しているのかを表現するもの。



◆ビジネスモデルキャンバス

・これにビジネスモデルを記述する。ビルディングブロックで構成される。

・コンサルタントや管理職だけではなく、一般の社員も理解できるもの。

・これを使えば、この中の共通の言葉で話すようになるので、非常にパワフル。

・組織というとより、事業のモデルを記述する為のもの。
ただし、組織の分析や改革にも使用できる。



◆ビジネスモデルを変更したい場合

・キャンバス内のオブジェクトを動かし、その際の影響を考える。



◆ビジネスモデルキャンバスと、その構成要素(ビルディングブロック)について。

・収益と支出について、キャンバスを2分する。

収益と、それを生み出す構成要素が右側。

支出と、それを作り出す構成要素が左側。


◇収益に関するビルディングブロック

・レベニューストリーム

 これらがうまく繋がれば、収益の流れが生まれる。
 収益を生み出す構成要素


・カスタマ

 最も重要な顧客だけを書く。

・バリュープロポジション

 顧客にもたらす価値。サービスそのものではない。

・チャネル

 顧客との接点。マーケティングの5Pと同じもの。

・カスタマリレーション

 コミュニケーションの手段。
 どれだけ自動化されているかが重要。
 新規顧客と既存顧客のどちらを重視するのかという優先順位がはっきりしていることも重要。


◇支出に関するビルディングブロック

・コストストラクチャ ビジネスを回す為に必要な支出。

 支出を生み出す構成要素

・キーリソース

 モデルを回す為に必要最低限のものだけ。
 それが無くなったら、即座に業務が止まるようなものを書く。

 例えばgoogleなら、キーリソースは社員ではなくプラットフォーム。

 googleのサービスに繋がらなくなれば、その瞬間にビジネスモデルは成り立たなくなる。
 社員が全員いなくなったとしてもすぐに収入がなくなるわけではない。

・キーアクティビティ

 毎日BPをつくり、カスタマとコミュニケーションする為のもの。
 普段当たり前にしていること。


・キーパートナー



17-C-2 仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り



◆waterfall or agile

・パッケージ開発など、見積もりが効くものはウォーターフォールがよい。それ以外はアジャイルの方がよい。



◆excel or チケット

・まともなプロジェクトかつ、時間軸が不安定なタスクばかりならチケット駆動開発がよい。
タスクの前後関係が見えなければいけない or 安定しているならexcelで管理するのがよい。



◆課題管理について

・まずは時間管理ができていなければならない。

・切り出したタスクの中で、それでも不確定なものを課題管理システムで管理する。

・情報公開範囲との兼ね合いがあるので、Q&Aやバグなど機能毎に切り分けること。

・リーダーがタスクを割り振ること。

・計画的な(繰り返して行う)ものには使わない。



◆課題管理表のデザインのポイント

・タスクを階層化しすぎない

・複数のコミュニケーションツールを併用せず、一本化する
(電話での依頼はexcelに書き、メールの依頼はnotesに書く、みたいな使い方は駄目)。



◆課題管理表の書き方のポイント

・誰がクローズするのかを決める。

・言葉使いには気をつける。

・事実のみを書かせる。






17-A-4 Scrumで組織改革



◆はじめに

市場・会社が急拡大している。人を増やしているが、次のようになっていた。


◇経営

・業務遂行の質やスピードが上がらない。

・意味のあるアウトプットが増えない。

・スケールする為の取り組みがない。


◇現場

・周囲や自分のしていることが分からない。


このような課題を自己解決できるような会社にしようと考えた。 



◆仕事の現状

次のとおり。


◇スケジューリングが困難

・案件が突発でやってくる。

・状況認識できない。

・今が忙しい。

・タスクが多い。

・優先順位がついていない。


◇責任範囲が不明瞭

・可視化できていない。


◇課題・問題が放置される

・目先の仕事もそうでない仕事も、価値はどのくらいかを図る必要がある。

・目先はアウトプットの価値が図りやすい。

・結果として目先の仕事ばかり処理される。


スクラムなら解決できそうだと思われた。 



◆1回目


◇やってみた結果

・スプリントで優勢順位が付いた

・なんだかんだで、スクラム外の仕事もせざるをえない。

・ツールなどが意図したとおりには機能しない。

・リリース品質に近づかない。

・助け合うマインドができた。

・大きな問題が後回しになった。

・バックログが増えていく。

・明確化や意思決定が遅れた。


◇振り返り

・問題の可視化・共有ができる。

・スプリント毎に成長する。

・スクラムは難しい。


これなら課題を解決ができそう。



◆2回目


◇したこと

・開発者を一箇所に。

・スクラム前に1週間ほどスプリント0を行なう。

・ミッションの明確化。

・責任分割。

・優先順位。

・バックログを作成。

・ツールを整備。


◇振り返り

・タスクをストーリー化したが、意思決定で迷う状況があった。

・振り返りを嫌うチームがでてきた。


◇この段階での結論

・スクラムを知らない(理解が浅い)人にただ行わせるのは逆効果。

・スクラム意外の方法で解決すべき問題がある。

・スクラム自体は有効。



◆3回目


◇ 行ったこと

・各チームにアレンジしてもらった。

・突発の対応を許可した

・大規模な開発に適用した

・チーム内メンバーの入れ替えをした

・業務改善に適用した

・スプリント0の前にプレプランニングをした。

・スクラムマスター会議をした。

・チームを超えた共通なルールを作った。

・チーム毎の個別のルールを作った。

・エピックというストーリーの上位概念を入れた。


現在実施中。



◆結論

・組織間のコミュニケーションが増えた。

・自己解決するように組織化された。

・メンバーが自分からやりたいことをするようになった。






Tim Clark様、今津 美樹様、鈴木 雄介様、貝瀬 岳志様、お疲れ様でした。



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がプログラムを学んだという件について

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

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


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

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






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

2012年3月13日火曜日

『第10回スクラムプロダクトオーナー勉強会』メモ


『第10回スクラムプロダクトオーナー勉強会』のメモです。



◆はじめに

現場でスクラムを実践する為には?というのが開催の動機。

2週間毎に行う。

テーマを変えることと、ワークショップをすることは前提。



◆?コミュニケーションのプロセス?(ノートが足りていなくて詳細がわかりません)

→話す→相手の理解というフィードバック
→更に話す→相手からフィードバック
→最後には一致する



◆オーラルストーリーとスピーチは違う

オーラルストーリーとスピーチは異なるものだということです。

◇オーラルストーリー

ダイナミックで対話・感覚的なもので、オーディエンスにリアルタイムでメッセージやパフォーマンスを伝えるものを指します


◇スピーチ

登壇してただ読み上げるようなものということです。

オーラルストーリーを行う為には相手を知っていることが重要です。相手を知らなければスピーチになってしまいます。



◆うまくやる為にはどうすればよいでしょうか?

自分自身のパフォーマンススタイルを確立させましょう。
また、ストーリーは何度も話して練習しましょう。

自分が理解していなければ、相手とのギャップは判らないですよね? それでは伝わりません。



◆オーラルストーリーのポイント

話のテンポ、話す早さ、ストーリーを進める早さがあります。

声量を変えたり、アクセントを加えるのは止めましょう。そんなことするより、きちんと話すように言われるのがオチです。

話しが迷ってきたら、短くまとめるようにしましょう。だらだらと続けてしまうと、オーディエンスは聞くのを止めてしまいます。

沈黙(間)を恐れないようにしましょう。



◆文書のストーリー

いつでも編集できます。

オーディエンスは自分のペースで読むことができます。

行間は読み手次第になります。書いてないことは読み手が勝手に埋めるということです。




◆オーラルストーリーの練習


何回も読みましょう

ストーリーの魅力を分析しましょう

ストーリーの背景・文化を考えましょう

ストーリーとうまく付き合いましょう。どう接し、どう伝えるかを考えましょう。

自分のスタイルを作り上げましょう。

話しのテンポをコントロールしましょう。

話すときには、避けるべき点に注意しましょう。

話す絶好のタイミングを選択しましょう

オーディエンスに直接会えない状況下(skype, ビデオ会議など)でもストーリーを伝えられるようにしましょう。




◆オーラルストーリーは1回では成功しません



◆ワークショップ

『 逆説の10カ条』を元にストーリーを作り、オーラルストーリーを実践してみる。



◆その他

説明無しでいきなりワークショップだけしてもらう、参加者は持ち帰るものがなくなってしまいます。

イベントには『知る 』 と『経験する 』 の2つの軸があり、主催する際にはどこを伸ばすかを考える必要があります。



fullvirtue様、お疲れ様でした。

2012年3月7日水曜日

『DDD(ドメイン駆動設計)をやってみよう』メモ


2012/03/05に開催された『DDD(ドメイン駆動設計)をやってみよう』のメモがこちらです。


メモを文章に書き改めたものなので、実際に話した内容とは必ずしも一致していません。

しかも、開始時間に間に合わなかったので、途中からという… 前半は適宜補完してください。



DDDのこだわりポイント

ドメインモデル = 利用者の関心事の模型です。

ドメイン駆動はトレンドではありません。ビジネスの要請によるものです。
事業やビジネスは、得たフィードバックを早く反映したいのです。
ビジネスを展開するうえで、まず作って何もいじらない …というモデルは成立しません。

逆に言うと、役所のような場所ではイテレーティブ・インクリメンタルな開発は成立しないということです。


xDD

テスト駆動(TDD)、振る舞い駆動(BDD)、ユースケース駆動(UCDD)、チケット駆動(TiDD)、画面駆動(ScrDD、エクセル方眼紙駆動(ExDD)など、いろいろあります。ちなみに、リスクやアーキテクチャで駆動するのがRUPです。

xDDは華麗で楽しいのですが、それだけでよいのでしょうか? どこかに特化してそれだけをドライブすればよい、というのはリアルではありえないですよね。だからmultiDDが大切です。状況にあわせ、それぞれの駆動の強みや弱みをうまく組み合わせるのです。

8輪駆動の車があります。これはポルシェより加速性能がよく、燃費なら10倍もすぐれています。タイヤが8つもあるので、あちこちに制御する仕組みが入っています。普通は1輪の箇所に2輪あるのです。もし制御がうまくいかなくて、1つでもタイヤが逆向きに動いたら逆に効率は悪くなるでしょう。駆動の間の強調動作が入り、ものすごい効率を生み出すのです。

プロジェクトでも同じです。メンバーそれぞれが持っている駆動を信頼してうまくまわすのです。オブジェクトも同じです。そして、これがもっと大きなものを動かすというブレイクスルーのポイントです。

ところで、TDDですが、これは受け入れテストを自動化するためのものです。以外だけど、単体テストは必要ありません。単体テストはユーザの価値ではないですよね?



ドメイン駆動を実践


理論編

使ってみてわかったのですが、利用者の要求のキャッチ力が高まりました。だって、ドメイン駆動はユーザの言葉にアンテナを立てないとできないですよね? それから、関心事の構造がクラスや関連としてドメイン駆動設計から出てきたりもしました。また、要件の追加や変更が安全になります。それから、顧客の仕様変更が理不尽ではないこともわかります。ドメイン駆動することによって、単に自分達が見落としていただけということが分かるようになりました。

よい設計の原則というものがあります。関心事の分離 … 単一責任の原則、カプセル化、高凝集(モジュール化)。協調 … 疎結合、インタフェースの最小化(モジュール化)。これらをドメイン駆動に適用するのがドメイン駆動です。

関心事の分離には基本になるパターンがあります。whole-partパターンです。デザインパターンやアナリシスパターンはこれのサブです。wholeはパブリック(表)であり、クライアントが利用する為のものです。ユーザから見て、有用でシンプルなインタフェースにします。partには単一責任の原則です。単機能がいっぱいあるのがよいです。

partをどうまとめればよいでしょうか? これは表の内部設計の問題になります。コントロールもいいですね。委譲はどうでしょうか? 委譲すれば、ロジックはpartに集まります。wholeがコントロールすると、コントローラにif文が溜まりすぎてしまいます。


実践編

まず利用者の関心事の置き場所を作りましょう。これは、関心事についてだけ記述する場所です。
次に、要求を見つけましょう。関心事の中でコードにしましょう。そして、書いたものがユーザの価値になっているかの妥当性を検証しましょう。

※できるかどうかのハードルは高いです。特に関心事だけを置く場所を作るのは難しいです。どうしても関係ないものが混ざってきてしまうからです。

関心事の分離とはなんでしょうか? 画面、UIコントローラ、DBアクセス、メール、メッセンジャーといったものの外に関心事の置き場所を作りましょう。それを画面などが使いにいくのです。置き場所には呼び出し元が何であろうと関係ありません。これを徹底しましょう。こうすると、要求や仕様の変更は、まずドメインに行くはずです。

さて、関心事だけが置き場所にあることをどうやって確認すればよいのでしょうか? grepがあります。インポートしているパッケージがJava.Utilくらいであれば、問題ないでしょう。そうでなければ…

顧客登録の場合を考えて見ます。UIコントローラは顧客登録サービスを呼び出し、サービスはリポジトリ・トランスファー(メール)・顧客を使用するものとします。リポジトリとトランスファーが分離しているのは、これらが別の関心事だからです。ユーザから見ればそれぞれ保管と通知に対応しています。

顧客の言葉を手がかりに、モデル以下にサブパッケージ、クラス、フィールド、メソッドを追加していきましょう。これを繰り返しましょう。ごちゃごちゃしてきたら、リファクタリングの出番です。

また、本を見るのもいいでしょう。技術書ではなく、対象業務の入門書です。できれば洋書にしましょう。クラス・パッケージ名・メソッドの宝庫です。

接頭辞や接尾辞が並ぶモデルは駄目です。顧客XX, 顧客YYといったものが並ぶのは何かおかしいです。顧客.XXや顧客.YYとなるようにしましょう。

リファクタリングはよいものですが、それだけでは時間がかかります。パターンも使いましょう。
用語や概念、何が関心事であるか?どう設計するか?の参考になります。関心の分離のさせかたや協調のさせかたが分かります。パターン本は使えます。目次は種々の関心事を俯瞰できます。



ポイント

バリューオブジェクトを書きましょう。表現力の向上につながります。また、オブジェクトは不変なものとし、演算結果はコピーとして返すようにします。


6つの役割で考えてみましょう。
・外部への見せ方
・調整役
・制御役
・部品の構造化
・サービス提供
・情報保持

DDDのエンティティクラスに相当するものを作ることが大事です。

手順やルールはクラスにまとめてしまいしょう。
顧客の処理や手順、ポリシーはXxProcedure, XxPolicyというクラスにしてしまいしょう。ステートレスにすることもお忘れなく。



アドバンス編

以下はこれからの課題です。

1. 隣接ドメインとの領域の重なりをどう考慮しましょうか? 顧客は、同じように見えるコンテキストでも微妙に単語を使いわけることがありますよね? どういうことなのでしょうか?

2. 状態遷移をどうしましょうか? 状態マシン図はいいものですが、書いたものをユーザは見ませんよね? モデルを作ってもコミュニケーションもフィードバックももらえないってどうなのでしょうか?

3. イベントソーシングをどうしましょうか?

4. 顧客はリストではなく、表やキューブ形式のデータを扱うようになってきていますよね?

5. あいまい検索のニーズもありませんか?



~~~

書いていてつくづく思ったのですが、手書きのメモにはやはり限界があります。かなりの量をメモしたつもりでしたが、文章にするには圧倒的に情報が足りず、かなり補間する必要がありました。話すスピードと比べると、早さが圧倒的に足りていないのです。 …PCを調達しよう。



B面勉強会の皆様、増田 亨様、お疲れ様でした。

2012年3月4日日曜日

『DevLOVE x hcdvalue共催 ブレスト祭り』メモ


勉強会のメモ




DevLOVE x hcdvalue共催 ブレスト祭り
http://kokucheese.com/event/index/28198/



◆グループ紹介

◇hcdvalue

・hcdvalueのコンセプト = 現場で使えるhcd


・活動

試す→学ぶ→話す→飲む
体験→学習→外化→省察


◇devlove

・現場のハブになる。

・皆が集まり、そして現場に戻っていく。そのような場。



◆ブレスト祭り

1. アイデアだし

・スピードストーミング
・3人ブレスト


2. アイデアの具体化と絞込み

・ハイライト法


3. 残ったアイデアに対してブレスト

4. まとめ



◆使った / 解説があった手法

◇アイデアだし … スピードストーミング

1. とりあえずペアを作る。

2. どちらが内側か外側かを決める。

3. ペアを輪状に並べる。内と外があるので二重の輪になる。

4. ペアで5分間のブレスト。

5. 1分間のメモタイム。

5. 外側の人だけが一個ずれる。

6. 新しいペアができあがる。

7. 4. ~7. を繰り返す。


◇収束 … ハイライト法

・準備

1. アイデアをシートにする。

2. 全てのシートをテーブルに並べる。


・方法

1. 個々人でシートを見て周る。

2. 気に入ったシートに星を付ける。


・使っていい星の数に上限はない。
・いくら良いアイデアだと思っても、1つのシートにつけてよい星は1つだけ。


3. 全員が見終わった後に星の数が多いシートをピックアップすれば、優れたアイデアのリストができる。


・備考

星が1つもないアイデアは誰も伸ばせないアイデアということなので、拾わなくて良い。

星が少ないアイデアはダークホースの可能性がある。

ポストイットを使ってコメントを付加できるようにすると、集合知をすぐに集めることができる。

黄色のポストイット : よいところ。
赤色のポストイット : もっと良くできるところ。


◇収束 … 番付法

1. アイデアから2つ取り出して比較し、順位をつける。

2. アイデアを1個取り出す。

3. 最下位のアイデアと比較する。

4. 勝ったら1つ上のアイデアと比較。

5. 負けるまで比較を繰り返し、順位をつける。

7. 全てのアイデアに対して3. ~ 5. を行う。


・メリット

1人で絞込みを行うことができる。


・デメリット

量が多い場合は方法を工夫する必要がある。最下位から逐一比較せず、4位から比較をスタートするとか

優劣の基準が人それぞれなので、複数人ではできない。


◇収束 … ピューメソッド

1. 評価軸を3つ決める。

よく話し合って合意すること。
軸を統合する場合は慎重に。コストや時間といった総論的な軸ができないように気をつける。


2. 良いアイデアを選び出し、これを基準にする。

3. 残りのアイデアを3つの評価軸に関して比較し、+, -, sameを付ける。

マイナスしかないものは、重視したいものが全てにおいて劣るということなので消す。


4. 優れているものを新たな基準とし、改めて3つの評価軸で比較。

マイナスしかないものは消す。


5. 残ったアイデアを見て、相補的なものを掛け合わせる。

例えば、軸1のみ+のアイデアと軸2のみ+のアイデアを掛け合わせる。

掛け合わないアイデアもある。

足し合わせ元のアイデアが、明らかに負けている場合は消す。


6. 進化したアイデアと生き残ったアイデアがリストになる。



◆その他メモしたこと



◇会議のサイズを調整する

会議のサイズを小さくすることで、意見が出るようになる。

・会議でアイデアがでないとき、挙手で反応がないとき。

→ペアストをしてもらう。こうすることで会議のサイズが小さくなり、話しやすくなる。


・発表の後に設ける質問タイム。

→隣と話合ってもらう。自己解決すればそれでよく、2人ともわからなければその時に質問してもらう。
全体に対して挙手してもらう形式より、解決する質問の数が全然多い。


◇新規性と不確実性は相関する

不確実性を削ることは新規性を削ること。
不確実性を削りすぎれば、ぱっとしないアイデアしか残らない。


◇脱線をどこまで許容するか

IDEOの場合、2~3個まで脱線したら戻す。



◆調べるものリスト

UX白書
iso 209241-210
trizの発明原理
『創造的問題解決』
情報デザインの教科書
ユーザビリティエンジニアリング
subject to change
don't make me think






ポストイットの使い方が非常に巧みな方がいて、関心しました。


DevLove様、hcdvalue様、石井力重様お疲れ様でした。