勉強会
- みなとRuby会議01に参加しました。#minatork01 (02 Jun 2012 | Tags:
みなとRuby会議01に参加しました。#minatork01 )みなとRuby会議01に参加しました。#minatork01
当日のTwitterのまとめはこちら↓
・みなとRuby会議01 前半まとめ #minatork01
・みなとRuby会議01 後半まとめ #minatork01
初Rubyイベント参加
ずっとRubyは勉強したいと思っていたのですが、なかなか進まず放置状態でした。、(^^;)
そんな私は普段Rubyを書いているわけもなく、 たまたま勉強会でよくお会いする@joker1007 さん経由でこのみなとRuby会議が開催されることを知り、一念発起し参加と相成りました。
Rubyのコミュニティ力
言語やプラットフォームなどなど、新しい技術を学ぶとき、 その技術そのものの利点と同じようにその技術の「コミュニティ」が選ぶ理由になると思うのですが、 今回はじめてRuby界隈のイベントに参加させていただき、、 他のイベント・勉強会と比べても、Rubyコミュニティのレベルが高いなぁと関心するところが、随所に見られました。
なぜRubyはコミュ力が高いのか？は、わかりませんが、 スタートアップのプログラミング言語と言われるに納得できるAgilityの高さを感じました。
English Numeralsリベンジ
今回はじめてペアプロでのソーシャルコーディングをしました。
普段仕事ではペアプロをするのですが、こういった機会にするペアプロも新鮮で大変面白かったです！
ただ、、Ruby自体のインストールも当日の朝やってくるような準備の足りなさだったため、 ペアプロでは完全にナビ役になってしまいました。。
リベンジのため、ソーシャルコーディングの課題をScalaで書いてみました。
まだ冗長な部分もあって、いけてないですが、今のScala力ではこんなもんです。
＃この記事を見たもっと強力なScala使いの方が、もっとスマートに書いてくれるでしょう、だぶん。。
まとめ
今回この様な有意義なイベントに参加させていただき、運営スタッフ、参加者の皆様、ありがとうございました。
懇親会にも是非参加したかったのですが、諸事情により今回は断念となってしまいました。。orz
今回のはじめの一歩に続く次のイベントも開催されること期待しています。そのときにはもう少しRuby力を上げて参加できるようがんばります！
LinkLatest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- スクラム道 Full Boost 「青物横丁制圧作戦」#scrumdoに参加しました。 (11 May 2012 | Tags:
スクラム道 Full Boost 「青物横丁制圧作戦」#scrumdoに参加しました。 )スクラム道 Full Boost 「青物横丁制圧作戦」#scrumdoに参加しました。
この記事では、選手として参加させていただいて感じたことと、自分が壇上で発言した質問や意見の補足をメインに書いています。
イベント自体については、他方々の記事にとてもわかりやすくまとめられていますので、そちらを参考にして頂ければと思います。
・ スクラム道フルブーストに参加してきた #scrumdo #nawoto_girls - Shinya’s Daily Report
・ スクラム道フルブーストに参加しました。 #scrumdo - k_0kamotoの日記
・ スクラム道フルブーストでひと試合してきました #scrumdo - 炸裂！情熱の右フック！！
スクラム道とは？
スクラム道は、スクラムを中心にアジャイルを探究するための場です。 アジャイルは本を読んだだけでは大事な部分は伝わらず、そのため、せっかく現場でスクラムやアジャイルのプラクティスを導入しても上手く成果が出ないという悩みを良く聞きます。 スクラム道では、毎回、参加者と共に一つのテーマを深く掘り下げて探究し、現場の悩みを少しでも解消する事を目的にしています。スクラム道HPより引用
スクラム道へは、2011/12/26に読み手@ryuzeeさんで行われたスクラム道場.08[「Doneの定義 虎の巻」](http://www.taoofscrum.org/contents/post/214)、2012/03/28に読み手@nawotoさんで行われた[「良く書けたインセプションデッキとは？」](http://www.taoofscrum.org/contents/post/220)の2度参加し、 今回のスクラム道 FullBoostが3度目の参加となりました。
今回のテーマ
今回はスクラム道10回記念ということで、過去に行われた5テーマから参加者の投票で再演を行う形式で、@imagireさんによる「プロダクトバックログ」の再演となりました。
まとめ その１ スクラム道 Full Boost 「青物横丁制圧作戦」 壮大な前座 #scrumdo - Yukarin’Note
スクラム道場.07View more presentations from Takashi Imagire読み手の@imagireさんによる発表の後、「議論に参加したい」「プロダクトバックログについて悩んでいる」人が選手として登壇。
選手として登壇した人には、マイクロソフトさんからプランニングポーカーがもらえる！とのことだったので、物欲に駆られて登壇してきました。
ステマ
おぉ！マイクロソフトさんからプランニングポーカーの差し入れだ!! #scrumdo
— imae masatoshiさん (@modal_soul) 5月 11, 2012いただいたポーカーはこちら 外箱がVisualStudioになっているという、さすがマイクロソフトさん！
ディスカッションRound1
ディスカッションRound1まとめ スクラム道 Full Boost 「青物横丁制圧作戦」Round1 #scrumdo - Yukarin’Note
プロダクトバックログに関して「ストーリーポイントを見積もる際の基準ストーリーが、後々基準として不適格だった場合どうするか？」と質問させていただきました。
あの場の発言だけでは説明しきれていいなかった部分も多々あるので、ここではこの質問の件を補足したいと思います。
前提として
1つのプロジェクトが開始されるにあたり、プロダクトバックログ(以下、PBL)が作成されます。
このPBLの各項目にストーリーポイント(以下、SP)を見積もる際、基準となる項目(以下、基準ストーリー)を選び、その他のPBLの各項目について見積もると思います。 私のチームの場合、ストーリーポイントが２と５に相当しそうな基準ストーリーを選び、見積もりを行っています
これ以降、新たにPBLに追加された項目についても同じ基準ストーリーを用いて見積もりを行えば、以前見積もった項目と大きさの比較が可能であると言えます。 例）10kgは1kgの10倍の重さです。なぜなら同じ基準（＝単位、ここでいうkg）を用いているから
もしも基準が変わると？
基準ストーリーを実際に消化したところ、当初見積もっていたポイントよりもとても大きかったorとても小さかった、とします。
そうすると、その基準を用いた見積もりの結果の信頼性に疑問が出てきます。
例えば、SPが２と見積もっていた基準ストーリー「A」が実はSPが10に相当するボリュームで、SPが5と見積もっていた基準ストーリー「B」がSP2のボリュームだった場合
ある項目「X」の見積もりを、SP2の基準ストーリー「A」以上SP5の基準ストーリー「B」未満だからSP3と見積もった ここに基準ストーリーのSPの変化を適用すると、ある項目Xの見積もりは、SP10以上SP2未満となってしまい、この項目Xの見積もりが破綻してしまいます。
このような場合、新たに基準を設けて再見積もりを行えば問題は解消されると思います。
ただそうすると、各スプリントで計測したベロシティは、基準が異なるので単純な比較が行えなくなります。
ベロシティって重要ですか？
ベロシティを使う目的は様々あると思いますが、ざっと挙げると以下のような感じでしょうか。
・スプリントで消化するSPの見積もり
ベロシティはからないと、次のスプリントでどれぐらい積めるか基準値がわからなくなりません？ RT @ kanu_ : 別にベロシティで測らなきゃいいんじゃないのかぁ。ってか誰が欲しがってるのかな? #scrumdo
— SEO Naotoshiさん (@sonots) 5月 11, 2012・チームの成長度合い
"ポイントの基準が更新されると、ベロシティによるチームの成長の測定が難しくなる。" #scrumdo
— Tomohiro Hashidateさん (@joker1007) 5月 11, 2012
ディスカッションでの質問やツイートの反応にもありましたが、決して<h3>ベロシティを人事評価等に使いたい訳ではありません。</h3>この所は、特に強調しておきたいと思います。
ベロシティは「人事評価に使うべきではない」というのは大前提ではあるが、「自分達がどれくらい成長したの？」というのを測るための指標として「数値がぶれる」のはマズイのでは？ #scrumdo
— skowataさん (@skowata) 5月 11, 2012ただ、現実問題としてアジャイルなプロセスを取り入れたことによる効果を、実際にプラクティスを実行する人以外に説明することを考えたときどうでしょう？
「アジャイルなプロセスを用いることで、どの程度生産性が向上した」、であるとか<h4>プラクティスの有用性を理解してもらえなければ、 今後アジャイルなプロセスを継続することが出来なくなってしまうかもしれません。</h4>
「価値判断で計測すればいい」という意見は正しいと思いますが、スプリント毎のROIを正しく計測するのは（そうできることが理想であり、その努力を惜しむべきではありませんが）難易度が高く早い段階での導入は難しいと思います。
実際にプラクティスを実行する人以外も、アジャイルなプロセスについて本質的な理解をすれば、ベロシティによる説得を行わなくても有用性を理解してもらえるかもしれませんが、 これもかなりハードルが高いと思います。
この質問で知りたかったこと
PBL見積もりの基準が同じであれば、ベロシティの増減がチームの生産性を表す指標として機能するのではないか？
ベロシティの向上によってアジャイルなプロセスの有用性の説明の裏づけになるのではいか？
基準が変化することで、ベロシティが（見かけ上）減少しているような場合、生産性の低下を指摘された時どのように説明することで、見かけ上の誤解を解くことができるか？
ということです。
今の話（ストーリーポイントと実際のタスクの相関）は「通貨（経済の話）」に似てる by @ kawaguti #scrumdo
— skowataさん (@skowata) 5月 11, 2012この質問に対するコメントのなかで、@kawagutiさんの通貨のたとえが、とても腹落ちしました。
ディスカッションRound2
ディスカッションRound2まとめ スクラム道 Full Boost 「青物横丁制圧作戦」Round2 #scrumdo - Yukarin’Note
1Rだけのつもりだったのですが、もたもたして残留してしまい、居残り組みとして2Rも選手として参戦と相成りました。
折角の機会なので、壇上から見た景色を写メってみました。
POの価値判断にチームが納得できない場合
POが初心者の場合、「これってホントに正しい優先順位なの？」という場合がある。その場合チームとしてどうするべき？ #scrumdo
— skowataさん (@skowata) 5月 11, 2012POがPBLの各項目について優先順位付けした結果が必ずしもチームの意見と合致ばかりではないですね。
この話に対して私は「ビジネスとしての優先順位付けはPOの責任であり、チームが剥奪すべきではない」「チームが納得できないのであれば、その根拠をPOに説明必要はあるが、チームが優先順位決定するべきではない」とコメントしました。
これをもう少し補足すると、
- PBLの優先順位付け(≒事業判断)は、スクラムではPOというロールの責任(＝権限)。
- POが決定した優先順位付けをチームが覆すことは、POから責任(＝権限)を剥奪することになる。
- POから責任(＝権限)を剥奪することは、スクラムでのロールが破綻しているのでは。
ということです。
#scrumdo 「POに責任がある」といって自分達の自主性を殺すのも危険なかおりじゃまいか
— atsumi shibataさん (@JibrielShibata) 5月 11, 2012責任(＝権限)はPOにあるから、チームは一切口出ししないと言いたい訳ではなく、あくまで「判断、決定」するのはPOであって、その判断のプロセスをチームが手伝うのアリはだという話でした。 ロールに拘らず、助け合うのがスクラムチームの有るべき姿だと思っています。
最後に
今回この様な有意義なイベントに参加させていただき、スクラム道スタッフの皆様、選手・参加者の皆様、バンダイナムコ様、マイクロソフト様、ありがとうございました。
今回は、@imagireさんの再演となりましたが、他方々の再演も是非是非お願いしたいところです！
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- AgileUX NYC 2012 Redux in Tokyo(#AgileUXNYC_ja)に参加しました。 (14 Mar 2012 | Tags:
AgileUX NYC 2012 Redux in Tokyo(#AgileUXNYC_ja)に参加しました。 )AgileUX NYC 2012 Redux in Tokyo(#AgileUXNYC_ja)に参加しました。
「AgileUX NYC 2012 Redux in Tokyo」とは？
2012/02/25に、アメリカのニューヨークで開催された「AgileUX NYC 2012」へ参加された＠kawaguti さん(アギレルゴ・コンサルティング株式会社 川口恭伸さん)と＠sprmari0 さん(楽天株式会社 坂田一倫さん)による報告会を兼ねたパネル・ディスカッションです。
Want to Win with Agile? Pivot Your Culture First by Eric Burd( #agileuxnyc live at ustre.am/I3ND/1 )
— Yasunobu Kawaguchiさん (＠kawaguti) 2月 25, 2012私はAgileUX NYC当日の＠kawaguti さんのツイートを見ていて、AgileUX NYCの内容に興味を持ち、ATNDでこのイベントを発見して、すぐに参加登録しました。
AgileUX NYCについての＠kawaguti さんと＠sprmari0 さんのツイートに、一部意訳を交えたものをこちらにまとめています。
AgileUX NYC 2012 #agileuxnyc ほぼ＠kawaguti さんつぶやきまとめ Yukarin’Note
AgileUX NYC ハイライト
最初の30分は、実際にAgileUX NYC 2012へ参加された@kawaguti さんと@sprmari0 さんが、AgileUXの各セッションの紹介や感想について話されました。
AgileUX NYC 2012について
AgileUX NYCは、今年からはじまったAgileUXにテーマを絞ったイベントだそうです。 参加された方も、アメリカ特にニューヨークを中心とした東海岸から来られた方が多かったそうです。@kawaguti さん曰く「デザインだけで食っていける」ほどニューヨークは、UXへの関心が高くお国柄?らしく、デザイナーの需要が高く、そういった背景からAgileUXが開催されたようです。
AgileUXは、1セッション20分×3セッション、その間にコーヒーブレイクやランチを挟んで、朝8時から夕方5時までぶっ通しの、非常にタフなイベントだったそうです。
登壇された方も興味深いポジションの方が多く、UX デザイナーがいれば、経営者やデベロッパー、そしてデザイナーからマーケティング PR の担当者の方々でした。Early Stage Specialistなんていう、スーパーマンのような方もいらっしゃったようです。
Want to Win with Agile? Pivot Your Culture First
Want to win with agile?View more PowerPoint from eburdThe Laddersの Vice President of ProductのEric Burdさんのセッションでは、Agileで成功するためには、まず組織文化をピボットする必要性が紹介されていました。
組織へAgileUX/LeanUXのコンセプトを導入するために、以下のポイントを挙げられたそうです。
- Find a fire/Start a fire （発端を探す、火を灯す）
- Listen to customers （ユーザの声を聴く）
- Get sales in to the action （セールスを巻き込む）
- Train the executive team （常務陣を教育する）
- Words matter （言葉がすべて）
- Small wins （小さな成功を）
そして、技術やプロダクトのチームだけでなく、営業などの関係する部署を集め共通の課題を提示することが必要である。
Want to Win with Agile セッションより： 意思決定者は忙しいためつかまえづらい。なので、ランチをセッティングして定期ミーティングを行い、啓蒙してプロジェクトに巻き込む。 #AgileUXNYC_ja
— Yoshiki HAYAMA 羽山 祥樹さん (@storywriter) 3月 14, 2012“Small Wins”（小さな成功）に成りうるものを探して、成功させ、そこから得たものを組織に蓄積することが重要、とのことです。
このセッションの内容に付随して、@kawaguti さんが紹介していたのですが、 海外ではBrown Bag Lunch Meetingという、ランチミーティングが盛んに行われているそうです。
Developers Summit 2012のセッションでも紹介のあったFuture Centerの様に、色々なバックグランドを持った人が集まり話し合う機会・場が求められている、ということでしょうか。
Brown Bag Lunch Meetingについては、こちらに紹介がありましたので、参照ください。
Investing in Design: Horsepower vs. RPMs
Agile UX NYC -- 4 keys to success in a design driven companyView more presentations from Phineas Barnes「スキルセットではなく、マインドセットの問題だ」という言及がありました。
Investing in Design セッションより：共通課題をダッシュボード化し、共有する。定期的に更新していく。 #AgileUXNYC_ja
— Yoshiki HAYAMA 羽山 祥樹さん (@storywriter) 3月 14, 2012Replacing Requirements with Hypotheses
2012 feb 25 agile ux nyc, seiden, requirements to hypothesesView more presentations from Joshua Seidenこのセッションで強調されていたことは、「要件を仮説に置き換える」ことです。
ビジネスサイドのニーズがそのまま開発サイドへ要件として伝わってしまうことで、本来の顧客のニーズを把握できなくなるという弊害がおこります。
要件を仮説に置き換えることで、@kawaguti さんのツイートにもあったのですが、
"仮説はの利点はテスト可能であること"
— Yasunobu Kawaguchiさん (@kawaguti) 2月 25, 2012という特性が発揮されます。仮説を検証するサイクルが生まれます。
アジャイルを導入するためには、要件ではなく仮説。要件は断固としたものだが、仮説なら不確実性というエッセンスがある。 #AgileUXNYC_ja
— mocha_cocoaさん (@mocha_cocoa) 3月 14, 2012そしてこういったプロセスが言語化されることが最も評価できると@kawaguti さんも話されていました。
視覚化も大事だが、言語化も大きな課題。特に日本語はあやふやな表現を許しやすいが故に、英語環境より言語化の整備が要するとおもう。 #agileuxnyc_ja
— Yasuhisa Hasegawaさん (@yhassy) 3月 14, 2012Quick, Visual, Collaborative and Continuous
Quick, Visual, Collaborative & ContinuousView more presentations from Lane HalleyこのセッションのスピーカーのLane Halleyさんはデザイナーなのですが、「開発サイドを理解するためにプログラミングを独学で学んだぜ！」と言って拍手喝采を浴びた、コミュ力の高い方なんだとか。
ペアインタビューをして、複数の人（デザイナやUX担当だけでなく、エンジニアを含めて）がインタビューを聞き、それをノートに取るようなスタイルが紹介されていました。 そして、部署や役割に縛られず「速く、視覚的に、協調的に、継続的に」行うこのが重要、とのことでした。
Product Ownerチーム(エンジニアも入るがあくまでアーキテクト程度のみ)が大まかな部分を作り、そこから複数のチームに別れ、POチームメンバーだったデザイナがそのまま複数チームに分かれて所属するスタイルが紹介されていました。
Learning to Play UX Rugby
Learning to Play UX RugbyView more presentations from Anders RamsayUXデザイナーはAgileな現場においてもウォーターフォールな働きをしており、それはリレーのように個別に走ってバトンを繋いでいく状態になっている。
AgileUXとは協調中心設計(Collaboration Centerd Design)と紹介されており、ラグビーの様に各々のプレイヤーが走り、縦横無尽にパスが交わされるようになる。
Better. Faster. UXier. AToMIC Design
Better. Faster. UXier. AToMIC DesignView more presentations from Jennifer Gergenイテレーティブな開発では、機能の開発改善には強いが、デザイン変更に弱さが現れる場合が多い。変更に強いAToMIC Designが必要。 デザインの戦略をはじめに決めることで、共通化されたデザインをアセットとして管理する。
デザイナがプログラミングスキルを（共通言語として）身に付けることで、開発サイドとの会話・意思疎通が迅速になるそうです。
そうか。UX専門家が、プログラミングを理解するだけでも、大きな価値になるのか。 #AgileUXNYC_ja
— Yoshiki HAYAMA 羽山 祥樹さん (@storywriter) 3月 14, 2012Demystifying Design: Fewer Secrets, Greater Impact
UXデザインは未だブラックボックスな状態になっている。 デザイナ以外の人間にとって、UXデザインは過程が不明であり、このような状態では信頼を勝ち取ることはできない。
UXがマジックのように見えるが故にスケープゴートみたいになってることもあるな。「UXスゲー」みたいな。謎表現だ。 #agileuxnyc_ja
— Yasuhisa Hasegawaさん (@yhassy) 3月 14, 2012デザインは様々な要因(ビジネスとユーザのニーズ、ユーザビリティ、ブランド等)が絡み合っており簡単ではないが、 頻繁に成果物を見せ、学んだことをシェアする必要がある。
そのために、UXデザイナは「医者が話すように、他人が理解できる言葉」で話す必要がある。
まとめ
UXにはメンタルシフトが求められている。
Requirements(要件)はHypothesis(仮説)へ、
Design(デザイン)はExperiment(実験)へ、
Outputs(成果物)はOutcomes(結果）となる。
ここで言われているOutputsは作成されたプロダクトであり、 Outcomesはそのプロダクトをユーザが使うことでもたらされた（得られた）ものを指すそうです。
“We are being invited,but we are not inviting them to ours.”
開発チームはUXを一緒のチームへ招待しているが、UXは開発チームを招待していない、と締めくくられていました。
デザイナーがプログラムを覚えろ…というより cross discipline (横断型) であれってことなんだろうね。 きっと。 #AgileUXNYC_ja
— Yasuhisa Hasegawaさん (@yhassy) 3月 14, 2012パネルディスカッション
後半30分は、LeanStartupJapanの和波俊久さん、利用品質ラボの樽本徹也さんをパネラーに向かえ、パネルディスカッションとなりました。
ディスカッションの内容を大まかに紹介します。
樽本徹也さん(以下、樽)：これまでは開発がウォーターフォールだったから、UX・UCDもウォーターフォールだった。だがこれからは、開発がAgileになる、だからUX・UCDもAgileになる。これはUX・UCDが自発的にAgile化したのではなく、開発サイドの変化に強いられた結果だ。今後日本でもAgileへシフトする、だからUXはAgileを学ぶべきた。
和波俊久さん(以下、和)：AgileはProjectの中で完結するものであり、終わりがある。だがStartupは終わらない。終わらせ方を知りたい。
「プロジェクトは終わる使命をもっているが、スタートアップは終わらないという使命をもっている。」 #AgileUXNYC_ja
— Takehara.Masashi.3kさん (@take3000) 3月 14, 2012坂田一倫さん(以下、坂)：UXデザイナはエゴで仕事をしていないだろうか？DevelopmentがUXについて学んで来ており、DevelopmentとBusinnessのロールだけで開発が回るようになってきている。UXとして危機感を持っている。現状の職場ではUXはDevとBizと分断された状態になっている。
樽：セクションごとに分けずにプロジェクト単位で、UXもDev,Bizと一緒になってやるべきた。
坂：現状プロジェクト単位に分かれているが、入っていくステージが違う。同時ではない。
樽：同時に入れていればLeanStartupになる。
ビジネス、UX、開発、よーいドンでチームとしてユーザー調査から始められたらAgileUX。（樽本さん） #AgileUXNYC_ja
— Saori Babaさん (@sanochka) 3月 14, 2012和：株式会社である以上、決算が必要。決算をするにはどこかで定量的に見せなければいけない。そこがBlackBoxのままではいけない。報告のうまい仕組みが必要。
川口恭伸さん（以下、川）：予算がひずみを生んでいる。予算は結果としてもちろん付いてくるものだが、Beyond Budgeting Modelのようにマイクロな計測をして適宜見直しを行えば良い。経営はDashBoardで確認が取れれば問題ない。
川：Leanにおいては、バーンレ-トがあり、資金が生きているうちにイノベーションを起こせるかが鍵になっている。
Q&A
Q:顧客開発のためのPDCAについて、何かインプットがあれば共有いただきたいです。特に顧客セグメントの仮説立案のTipsや、スケーラビリティを意識した検証方法などありましたら、お願いします。
A: 和：課題をセグメントしていく
川：
37signalsからの著書から参照すると自らがペルソナになることが一番の検証方法となる。 #AgileUXNYC_ja qlive.co/events/FsSNS/p…
— QLiveさん (@QLive_jp) 3月 14, 2012坂：Lean Work Shopに参加した際は、 ・自分が使うサービスを出す ・ペルソナを4つ作る ・セグメントの人に検証のためのインタビューをする ・セグメントが存在するか検証する？ 川：開発者でなければわからないこともある。だから壁があったら負け。
樽：インタビューは誰にでもできる。全ての人が常に同席することは難しくとも、インタビューを録音・速記して、全員が見聞きできるようにする。そうすればアイデアは出てくる。
チーム内で持っている情報に差がないほうがいい。ユーザーインタビューもチーム皆で参加。役割超えてアイデアぼこぼこ出てくる。（樽本さん） #AgileUXNYC_ja
— Saori Babaさん (@sanochka) 3月 14, 2012川：ウォーターフォールは科学的根拠を重視する。「統計的に5人以上ヒアリングする必要がある」だとか。Agileではアイデアが出るのなら（体験的に）少人数でも問題ないとわかっている。
樽：データの精度よりもアイデア。アイデアを出し、動かして、検証する。なぜなら結果が全てだから。
インタビューデータの精度より早くアイデアを形にすること。結果が全て。立派な調査やったって売れなきゃ意味ないでしょ。（樽本さん） #AgileUXNYC_ja
— Saori Babaさん (@sanochka) 3月 14, 2012川：正にOutputsではなく、Outcomesが重要。
樽：どんなものでも売れなければ意味が無い。だから作りながら売るべき。従来型の作ってから営業が売りに行くでは遅い。売れなければ、途中でピボットすればいい。作りながら売っていればそれが出来る。
和：最初から”学ぶ気持ち”でいることが重要。フィードバックを得ることを前提に動いているからこそうまくいく。
樽：開発者は今後UXを学ぶ。UXだけでは立ち行かなくなる
UX専門のデザイナーは必要ない？開発者がUXを身に付けだしている。#AgileUXNYC_ja
— Kazunori Nishimuraさん (@nishimuu) 3月 14, 2012川：如何にチームに入っていくかが重要。
坂：インタビューに併せて、その人がコアユーザかどうかも見極める必要がある。製品・サービスのコアが何かを見極めて、ピボットの幅を考える。
インタビューする相手は合わせてコアユーザーであるのかを確かめる必要がる。#AgileUXNYC_ja
— Kazunori Nishimuraさん (@nishimuu) 3月 14, 2012和：コアじゃないユーザのインタビューはかなしくなる。エバンジェリストユーザを見つけることが大事。
和：インタビューでは、採用障壁を下げるインタビューをしなければならない。インタビューされる側は現状で考えている。採用障壁を下げることですんなり採用されるパターンは多い。
和波さん「BtoBの場合、『あったら便利』というサービスでも、導入側が『これは自社の文化に馴染まない』と思ったら導入はされない。その敷居を下げる昨日をつければ簡単に度付きしてもらえたりする。スタートアップの人たちは、なかなかそれに気がつかない」 #AgileUXNYC_ja
— Yoshiki HAYAMA 羽山 祥樹さん (@storywriter) 3月 14, 2012川：「これを他人に勧めたいか？」という質問がいい。
「あなたはこのカンファレンスを人に勧めたいですか？ という質問がある」 #AgileUXNYC_ja
— Takehara.Masashi.3kさん (@take3000) 3月 14, 2012最後に
このイベントを通して、これまでビジネス側にとって開発側がブラックボックスだったように、今までブラックボックスだったUX・デザインが透明化・協調化されようとしている雰囲気が伝わってきました。 私は開発者なので、UX・デザインについての見識が浅いですが、Businness, Development, UXが溶けてバターになれるよう、UXを学ぼうと改めて思いました。
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
