こんにちは！
いやー、勉強会っていいですね。
関 (@fullvirtue)さん主催の「POStudy Conference 2012」に参加しました。
このカンファレンスは「関さん祭り」と言っても過言ではありません。なぜなら、企画、運営、プレゼンターのすべてをこなしているからです。
POStudyは定期的に開催されていて、今回のカンファレンスはその集大成だったと思います。
発表の様子。
勉強会の情報は、下記から発信されています。
- twitter：@POStudySmile
- Facebook：POStudy（公開グループ）
IT勉強会スタンプラリーの参加コミュニティなので、参加するとスタンプをゲットすることもできます。
IT勉強会スタンプラリーの告知の様子。
私は今回、準備のお手伝いをしたので、裏側の話も交えつつ、ワークショップについてレポートします。
ワークショップは、プロダクトオーナー向けの4本でした。
■ハンパない準備力
POStudyのお手伝いをして思うのは、準備力がすごいということです。
それは、この1枚の写真が物語っています。模造紙、付せん、ペンなど、ワークショップに必要なアイテムが入っています。
会場は、青山のmixiさんのオフィスでした。
会場の交渉も一転ありましたが、すぐ次の候補が見つかるのは人脈のなせる業です。
mixiの原田さん、ありがとうございました！
朝食は、近場のSUBWAYにて調達。前もって参加者分が予約してありました。
ドリンクも、参加者×3〜4本分を準備。
お昼のお弁当はハンバーグが人気でした。
朝の打ち合わせ前の様子。
Facebookグループ上の事前のやり取りで役割などを決め、打ち合わせは、当日の20分程度だけで乗り切ることができました。
今回、良いなと感じたのは、関さんが「こんな困ったことがある」と書き込むと、すぐに他の人から解決案が書き込まれていったところです。全員、自分から手を挙げて参加した方々なので、それぞれの自走力でこなせたのでしょう。
■マシュマロチャレンジ
マシュマロチャレンジは、短時間に限られた材料で、いかに高いタワーを建てるかというチャレンジです。
材料はこちら。
チームごとに紙袋に入っていました。この辺のマメな準備がすばらしいんですよね。
チーム分けは、ワークショップごとにプランニングポーカーで決めました。
毎回、ランダムにチームが決まるのは、いろいろな人と話せると好評でした。
私たちのチームの完成プロダクト。パスタ1階建ての高さでした。
1回めが終わった後、プロトタイプの重要性について。
幼稚園児のように、トライ＆エラーを繰り返す方が、結果的に良いプロダクトができる。
チーム替えをして2回戦のプロダクト。
パスタ3階建てくらい、66cmくらいにできました。他の1チームと同着1位に。
1回戦の優勝チームの方法をマネしました。
このワークショップは、プロトタイプの重要性を学べることもさることながら、盛り上がるので、1発めにもってくるのは良い作戦だと思いました。
■The Specification Exercise（要件定義エキササイズ）
ユーザーの仕様を伝えることの難しさを体験するワークショップです。出題者（ユーザー）が作った絵と、どれだけ近い絵（プロダクト）を再現できるかを競います。
方法
- 出題者は、課題の絵を準備する。
- 参加者チームを、プロダクトオーナー（仕様を伝える人）とデベロッパー（絵を描く人）に分ける。
- 出題者の絵は、デベロッパーが居る部屋とは別の部屋に置き、プロダクトオーナーだけが見ることができる。
- プロダクトオーナーは、出題者の絵を文章だけでデベロッパーに伝える。
- デベロッパーは、プロダクトオーナーの文章を読んで絵を描く。
ワークショップ
プロダクトオーナーが出題の絵を見ながら、仕様を起こしている様子。
うちのチームがすばらしかったのは、デベロッパーがまず、大ざっぱにプロトタイプを3つくらい作ったところです。
最終プロダクトの候補たち。
各チームのプロダクトを関さんとかわぐち (@kawaguti)さんが発表しました。
ワークショップ後のKP（Keep, Problem）
ワークショップ後、各チームのKPを発表しました。その中のいくつかを紹介します。
Keep
- プロトタイプを何パターンか出す。
- プロダクトオーナー、デベロッパーの担当分けで、ざっくりと詳細フェーズで分けたのが良かった。
- ペットボトルのキャップのサイズを物差しにしたのが良かった。
- 紙をまず、16の区画に分け、位置を決めやすくした。
- まず、中心となる十字を決めた。
Problem
- 長さを伝えるのが難しかった。
- 色の概念が抜けてしまった。プロダクトオーナーの認識から抜けると、デベロッパーはそれを作れない。
- 実装（作画）を交代でやったので、デベロッパー間で認識の食い違いが起きた。
- まずはざっくり、デベロッパーに伝えた方が良かった。
実際の現場での取り組み
実際の現場で、仕様を伝えるのにどういった取り組みをしているか、課題があるかといったことも共有しました。
各チームから
- まず目的を伝える。
- 優先度を決める。
- 開発者も交えて仕様を考える。
- 大枠から入る。
- 顧客も巻き込む。
- 文字だけではなく絵も利用する。
- 雰囲気よく伝えるのが大事。
- 顧客の中で仕様が眠っているケースがあるので、どうやってそれを取りにいくかが課題。
- 顧客のフィードバックが無いと進まない。
- 文章で伝える力をつけるのも重要。
関さんから（プロダクトオーナーとして）
- 自分の中で一本、柱を持っておく。ゴールを示せれば助けてもらえる。
- 自分の味方はどこにでもいると思っておく。
■プラグマティック・ペルソナ
開発プロダクトのユーザー像（ペルソナ）を作り上げるワークショップです。ペルソナを利用して、どんな機能が有効か不要か、判断材料にすることができます。
今回は、Jeff Patton氏がScrum Gathering Tokyo 2011で実施したものをマネしたもので、関さんいわく
「引用するときは、資料内に引用元を明記し、各スライドにも引用元を載せるとよい」
とのことです。
UXの伝道師、かわぐちさんの意見を代弁した関さんいわく
「ペルソナの名前は重要です。名前を決めることで愛着が湧いてくる」
とのことです。
ウォームアップ
手始めにウォームアップとして、このカンファレンスに来るまでの道中で印象的だったシーンを絵にしました。また、カンファレンスに参加したきっかけ、持ち帰りたいことを、隣の人からヒアリングしました。
このカンファレンスのユーザー像（ペルソナ）を、自分たち自身で作るワークショップです。
私は、朝一でSUBWAYのハンバーガーをたくさん運んだことが印象的だったので、それを絵にしました。小学生レベルです。
チームメンバーのカンファレンスに参加したきっかけと持ち帰りたいもののメモ。
ワークショップ
本題のペルソナ作成に。お題は同じく「このカンファレンスに参加するユーザー像（ペルソナ）を考える」でした。
フレームワークは下記です。
私たちのチームは、まず名前と顔以外の枠を埋めました。
その後、周りの関係図を含めた似顔絵を描くことに。
「要望がきつくて変わりやすいBossと、動いてくれないスクラムチームに板挟みになるプロダクトオーナー」というユーザー像になりました。その名も「POえもん」。
私たちのチームのContextとAboutとValuesです。
Context
- Web開発4、5年め。
- スクラムを導入しろとBossに言われている。
About
- チームビルディングがうまくいかない。
- チームのコミュニケーションが無い。
- Bossの要求が多く、変わるので対応できない。
- スクラムの効果がよく分からない。
Values
- プロダクトオーナー向け情報がいち早く入手できる。
- ワークショップによる気づきがある。
- 事例を聞ける。
- 仲間が増える。
最後に、チームごとにペルソナを発表しました。
実際の現場でも、ある程度ペルソナを作っておくと、いろいろなプロジェクトで使い回せていいかもしれませんね。
■ユーザーストーリーマッピング
ユーザーストーリーとは「ユーザーが欲しい機能とその理由」を記述したものです。
フォーマットは下記のようになるそうです。
ある「役割」のユーザーが、ある「結果」が欲しい。それは「理由」のためだ。
Ron Jeffriesさんは、ストーリーマッピングを下記のようにまとめると良いと言っているそうです。
今回は、ストーリー（機能の要望）とストーリーに合った機能を付せんに定義、それを模造紙にマッピングすることで、どういう優先順位で、どういう見積もりでユーザーの要望を解決するかをまとめました。初回リリースで実現する機能の線引きも行いました。
今回のお題
今回のお題は、飲み会幹事向けのアプリです。
ユーザーストーリーとユーザーは、あらかじめ定義されている情報を基に進めました。どちらかというと、詳細機能の見積もりと、初回リリースでどこまで盛り込むかにフォーカスしたワークショップでした。
あらかじめ定義されていた情報。
完成したユーザーストーリーマップは、こんな感じです。
上の青い付せんがユーザーストーリー、黄色い付せんが、それを実現する機能と見積もり。線より上が、初回リリースする機能です。
ワークショップ
私たちのチームがどうやって進めたかを共有します。
まずは機能の洗い出しから。
それを模造紙に貼付けてグルーピングします。
グルーピングした機能を、ユーザーストーリーを書いた青い付せんに沿ってマッピングします。
プランニングポーカーを使って、各機能を見積もります。
各メンバーが「いっせいのせ」で、見積もった工数のカードを出します。カードの数値が一致しなかった場合は、なぜズレたのかを議論して、メンバー全員が納得したら再度「いっせいのせ」でカードを出します。僅差の場合は、多い方を採用します。
こうして完成したのが、最初に紹介した、初回リリースまでのユーザーストーリーマッピングです。
最後に、チームごとに完成したマップを説明しました。コンセプトと困難だった点を共有しました。
■おわりに
さてさて、充実度満載のワークショップが終わり、後片付けです。
会場は元通りに。
そしてお待ちかねの打ち上げです。
今回、私にとって良かったのは、関さんの準備力と、基本的かつ重要で分かりやすいワークショップでした。ワークショップでは、特にユーザーストーリーマッピングは実用的だと感じたので、来年頭あたりに社内のTeckTalkで再現したいと考えています。
ではでは、最後まで読んでいただいてありがとうございました！
次回POStudyで会いましょう！
公認レポーター 松田 敦義
