Agile
- 横浜道場 特別編 「アジャイル開発 基本のキ」に参加しました。 (25 May 2012 | Tags:
横浜道場 特別編 「アジャイル開発 基本のキ」に参加しました。 )横浜道場 特別編 「アジャイル開発 基本のキ」に参加しました。
今回のアジャイルサムライ横浜道場は、特別編 第２回目。アジャイルサムライの監訳者、@nawoto さんにお越し頂き、Agile Japan 2012で講演した「アジャイル開発 基本のキ」を講演して頂きました。
この講演を通しての内容については、私以外の他参加者の方々が良い記事を書かれているので、そちらをご参考ください。
・http://d.hatena.ne.jp/absj31/20120525/1337976374
・http://d.hatena.ne.jp/y_sumida/20120526/1338030740
・http://grimrose.blogspot.jp/2012/05/agilesamurai_26.html
この記事では、私がこの講演を通じて感じたこと、気づきをベースに書いています。
ですので、必ずしも講師の@nawotoさんの意図したことを汲み取れていない可能性があります。
何が違うのか？
この章では、とにかく従来のやり方と同じであることの肯定を１つ１つ丁寧に積み上げているように感じました。
アジャイル≒カウボーイ(無計画)のイメージや、変化に対する拒否反応に対して、
これまでの計画駆動なやり方でいう上流工程を“準備”と言い換えて説明しているように感じました。
こうすることで、「何が必要か」から「どう実現するか」、「いつまでに出来るか」、「確認する」のサイクルを回すイテレーティブな作業の合理性を納得できる形で示しいるんだなと思いました。
どう進むのか？
この章では、アジャイル開発における3本の柱、「透明性」「検査」の具体的なプラクティスと「適応」の重要性を伝えるためのものと思いました。
明日から始める
この章で伝えようとしていたことは、「少しづつで構いません 良くする事を続けてください」に集約されているのだなと思いました。
最後に
今回この講演を通じ、アジャイル開発を如何に伝えるか？のエッセンスを学ぶことができたように思います。 1つ1つのプラクティスがどうであるか、よりも、具体的なアクションを如何に継続できるか、そしてそれが如何に重要であるかを伝える・実感してもらことが、 アジャイル開発を知ってもらうキーポイントなのではないかと思いました。
LinkLatest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- スクラム道 StaffMeetup20120523に遊びに行ってきました。 (23 May 2012 | Tags:
スクラム道 StaffMeetup20120523に遊びに行ってきました。 )スクラム道 StaffMeetup20120523に遊びに行ってきました。
@nawoto StaffMeetup遊びに行ってみたいです！
— imae masatoshiさん (@modal_soul) 5月 14, 2012こんな流れで、スクラム道のスタッフミーティングに遊びに行ってきました。
スクラム道の活動がどのように運営されてきたのか、イベントに参加するだけではわからないことところを見学でき、愉しかったです。
どうもありがとうございました
スクラム道 StaffMeetup20120523-［PARTAKE］
勉強会スタイルではないので、覚えている限り雑感をば。
※多分にミーティング後のものも含まれています。
・イベントにストーリーがある
・ストーリーが無いものは売り切りになる、続かない
・モチベーションマネジメントがすごい。コミュニティとスタッフがWinWinな関係。
・大崎はロスっぽい
・たすけてハラえもん
・地獄のちゃんげ
・母親のような心境
・西のちゃんげはいらない
・SlideShare有料プラン押しすぎ
・Speaker Deck馬鹿でいいやつ
・プロレスから学べ
・信頼のayayaレスポンス、でも東京じゃん
・Bで素振り
・uedyo大阪夏の陣
地方コミュニティ募集
スクラム道と組んでくれる地方のコミュニティ求む #scrumdo
— Nishimura Naotoさん (@nawoto) 5月 23, 2012ちなみにネタじゃなくて本気で一緒にやってくれるとこを募集中です。メンションだけじゃ分かんないんで俺にメールしてくれ #scrumdo
— Nishimura Naotoさん (@nawoto) 5月 23, 2012スクラム道では、スクラム道と組んでくれる地方コミュニティを募集しているそうです。
我こそは！という地方コミュニティは名乗りを挙げてみてはどうでしょうか？
※個人的には、会津若松のコミュニティ（あるのか？）にでてきてもらいたいな、と
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- 「全員スクラムマスター。」に参加しました。#devlove (21 May 2012 | Tags:
「全員スクラムマスター。」に参加しました。#devlove )「全員スクラムマスター。」に参加しました。#devlove
キャッチーなイベントタイトルに釣られて参加してきました。 私はスクラムマスターではない(自称ですらない)ですが、まぁ細かい事を気にしてはいけません。
今回、CSM研修同期のMTIのイケメンスクラムマスター岩崎さん（@niwa303）が、事例発表をされるということと、CSM,CSPO数ぶっちぎりだけど勉強会でなかなか遭遇しないMTI社の事例が聞けるということで、その辺りも期待していました。
イベント本編は、事例発表＆ダイアログの形式でした。私以外の他参加者の方々が良い記事を書かれているので、ご紹介。
・[悩めるアジャイルに贈りたい『銀の弾などない』には続きがあるということ #devlove 世界 - daipresents!!](http://daipresents.com/2012/%E6%82%A9%E3%82%81%E3%82%8B%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%81%AB%E8%B4%88%E3%82%8A%E3%81%9F%E3%81%84%E3%80%8E%E9%8A%80%E3%81%AE%E5%BC%BE%E3%81%AA%E3%81%A9%E3%81%AA%E3%81%84%E3%80%8F/) ・【ミッションたぶんPossible】 #devlove0521 全員スクラムマスター。 に参加してきました。
・全員スクラムマスター。 #devlove #devlove0521 - Yukarin’Note
スクラムマスターとチームの距離感について
MTI 岩崎さんの事例発表を聞いて、「チームとコミュニケーションをとるが、巻き込まれない」よう振舞っていると言われていたのがとても印象に残りました。
MTIさんでは、1人のスクラムマスタが4チーム(多い方は8チーム)兼務するそうで、チームの細かい問題にスクラムマスタが介入していると、スクラムマスタの役割が回らなくなる。(朝会だけで軽く1時間かかる等)
そのため「タスクをこなす」ではなく「改善を見出す」という考えのもとスクラムマスタがチームに働きかけているそうで、完全にチームの外側の立ち位置を取っているようでした。
私の周りのスクラムマスターはどちらかというとチームよりで、内圧的にチームに作用するパターンが多く、 外圧的にチームに作用し、チームで完結する領域を最大化するというのがとても新鮮で、スクラムマスタというよりアジャイルコーチに近いのでは？という印象を受けました。
スクラムマスタがチームに作用するために必要なコミュニケーションをとりつつ、巻き込まれない。適切な距離感を保ち続けるにはどうしているのでしょうか？
MTIさんのようなスクラムマスタとチームの関係性は、チームを1つのチームとして完結させ、多くのチームをまわすにはとても効率の良いやり方なんだろうなと思いました。
※ただ、チームが開発を楽しめているのかどうか？、個人的に気になる点ではありますね。
チームへの働きかけについて
ダイアログ中に共通して「スクラムを導入したいが、プラクティスがなかなかチームに浸透しない」といった問題を聞くことが多かったように感じました。
私がスクラムをやめた理由 - 全員スクラムマスター。＠DevLove -View more presentations from Takao Oyobe「スクラムを導入するためにスクラムのことを説明したが、スクラムに対する質問攻めに会い、質問者に納得の行く回答ができず理解を得られなくて失敗した」というお話もありました。
個人的にはこういう場合、
・プラクティスベースではなく、課題ベースで話す。
・相手にとって「何が」モチベーションになるのかを見極める。
の2点が重要なのかなと思っています。
プラクティスを実践する人が納得してプラクティスを行う、
これは王道、覇道、邪道関係なくチームに働きかける上で最も大事なことだなと思いました。
最後に
今回この様な有意義なイベントに参加させていただき、DevLove運営スタッフ、発表者、会場提供くださったMTIの皆様、ありがとうございました。
※次回は、是非事例発表する側になって、還元できればと思います。
Latest 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:
- Agile Samurai Dojo Gathering(#agilesamurai)でろくろ回しました。 (24 Mar 2012 | Tags:
Agile Samurai Dojo Gathering(#agilesamurai)でろくろ回しました。 )Agile Samurai Dojo Gathering(#agilesamurai)でろくろ回しました。
「Agile Samurai Dojo Gathering」とは？
以下公式サイトより抜粋
アジャイルサムライ他流試合から半年、原著者を迎えて他流試合はAgile Samurai Dojo Gatheringと名前を改め、ふたたびの道場大集合となるイベントを開催します。 今、日本で一番熱心にアジャイルについて語っている人達の経験に触れ、それを自分の言葉で議論する事でアジャイルサムライへの新たな一歩を!!
Agile Samurai Dojo Gathering全体の内容については、他方々の良質なまとめ記事があるので そちらにお任せしたいと思います。
なぜ私はろくろを回したのか？
前回開催されたアジャイルサムライ他流試合では道場紹介ＬＴをさせていただき、今回は実践トラックのスピーカーをさせていただきました。
前回の他流試合では、私はスクラム開発チームに入って3ヶ月少々の新米で、 他流試合で出会った多くの方々から学ぶことはあれど、還元することはできませんでした。
他流試合以降、スクラムやアジャイルなプラクティスについての学びを継続し、自身の現場で実践してきました。
そして、今回のAgile Samurai Dojo Gatheringが開催されることを知り、 多少なり自身の経験が還元できるのではないかと思い、実践トラックへの登壇をさせていただきました。
以下に発表資料を掲載しています。
Agile samuraidojogatheringView more presentations from Imae Masatoshi発表時のツイートまとめはこちら Agile Samurai Dojo Gathering サムライ戦記 実践トラック(@modal_soul) - Yukarin’Note(ゆかりんのーと)
今回お話させていただいた内容は、Developmentではなくどちらかと言うとDirectionの内容であり、スクラムといいつつあまりスクラムっぽくない話になってしまいました。 （開発関係の話を期待されていた方には本当に申し訳ないです。。）
ただ、私がこの発表を通して言いたかったことは
”顧客に価値を届ける”ことを考えたとき、”役割”がかえって邪魔になることがある
ということです。
人が行動を起こすとき”専門家”としての誇りを持つことは大変重要なことですが、”専門家”としての自覚があるがゆえに、行動を制限することもあります。
例えば、「私は開発チームだから、○○はやらない」といった具合です。
アジャイルな組織にとって”自己組織化”が必須であるのに対し、これでは真逆の結果になってしまします。
Wouldn’t it be nice if the whole world got along Even on a small scale change is possible （世界の流れを止めなくたって小さな変化は起こせるはず）
大切なのは、スキルセットではなくマインドセット。
そんな意味をこめて、最後に
Agile is attitude, not practice. (アジャイルはプラクティスをつぎはぎすることじゃない、態度が重要なんだ)
とさせていただきました。
さらに、
同じ実践トラックの次のスピーカーは、同じアジャイルサムライBIGLOBE道場の上田さんでした。
上田さんの発表では、インセプションデッキに取り組んだ際の内容が紹介され、とても良い発表でした。併せてどうぞ
cantbeatinceptiondeckView more presentations from Yoshinori UedaAgile Samurai Dojo Gathering インセプションデッキが倒せない - Yukarin’Note(ゆかりんのーと)
最後に、
どなたか私がろくろを回している写真お持ちではないでしょうか？ お持ちの方は、是非 @modal_soul までメンションいただければと思います。
追記
＠joker1007 さんに”ろくろ”写真いただきました！感謝！
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:
