@rivayama です。世の中には数多くのスクラムワークショップが存在します。私の所属するチームでも以前に紙飛行機のワークショップを実施してスクラムに対する理解を深めてきました。今回は当チームのスクラムマスター @r0bins-egg さんがオリジナルで作成した「伝聞お絵かきワークショップ」を紹介します（本人の許可を得ています）。
伝聞お絵かきワークショップ
こちらのワークショップは @r0bins-egg さんがスクラムマスターの目線から「チームに足りていないある要素」を発見し、その重要性を体感するために自ら設計されたものです。これからワークショップの内容を紹介するので、どんな要素の重要性を体感するためのものなのかぜひ予想しながら見てみてください。
ルール
参加者は「伝聞お絵かきで高いポイントを取ること」を目標にしてワークに取り組みます。まず参加者を2つ以上のチームに分け、そのうえで各チームからプロダクトオーナー（PO）を1名選びます。残りは開発者（Devs）になります。やることの概要は以下の通りです。
- PO はファシリテーターから題材となるイラストと評価表を受け取ります
- PO はイラストの内容を仕様書にまとめます
- Devs は受け取った仕様書の通りに絵を書きます
- PO は Devs の成果物を確認し、評価表を元にポイント計測します
各工程はスクラムの流れに沿って行います。
ワークショップの流れ
PO と Devs はそれぞれに制約が用意されており、各工程はその制約を守って行う必要があります。
PO の制約
- イラストと評価表を Devs に見せてはいけない
- 仕様書は言語化されたリストでなくてはいけない
- 絵を描く人にはなれない
- 原則作業場には入れない
- 仕様書を渡す以外の Devs とのコミュニケーション禁止。質疑応答も禁止
Devs の制約
- 作業場でしか作業を行うことができない。作業は「絵を描く」か「調査する」のどちらか
- 作業場には原則ひとりしか入れない
- 作業者が連続してはいけない
- 作業場には決められた時間（30秒、もしくは120秒）しか入れない
- 成果物は A4 一枚に規定の色鉛筆・ボールペンで書いてあるもののみ
- 原則ひとりのみ PC を操作・閲覧することができる
- 30秒 x 2回までモブ作業を行うことができる
- 行動フェーズ中のコミュニケーション禁止（筆談もNG）
コミュニケーション禁止の制約が PO と Devs の両方にあります。一見、不自由にも感じられるかもしれませんが、これがワークショップの肝となっています。
初回の実施
PO に渡されるイラストと評価表は以下のようなものでした。
お題1
PO はこれを制約通り「言語化されたリスト」の形式で仕様書にし、Devs に渡します。Devs はそれを元に絵を書きます。我々が取り組んだ際の成果物は以下のようなものでした。
左が成果物、右2枚が仕様書
取得ポイント
満点が226ポイントのお題なので、チーム1は58%、チーム2は82%のポイントを取得したことになります。コミュニケーション禁止という制約の中では健闘したほうではないでしょうか。しかしワーク中は仕様書の意味を確認できず、誤った理解のまま絵を描いてしまうことが両チームに見られました。
2回目の実施
続いてお題を変えてもう一度同じワークをします（我々はここでチーム替えもしました）。2回目は制約を変更します。新しい制約は以下の通りです。
PO の制約（2回目）
- イラストと評価表を Devs に見せてはいけない
- 仕様書は言語化されたリストでなくてはいけない
- 絵を描く人にはなれない
- 原則作業場には入れない
Devs の制約（2回目）
- 作業場でしか作業を行うことができない。作業は「絵を描く」か「調査する」のどちらか
- 作業場には原則ひとりしか入れない
- 作業者が連続してはいけない
- 作業場には決められた時間（30秒、もしくは120秒）しか入れない
- 成果物は A4 一枚に規定の色鉛筆・ボールペンで書いてあるもののみ
- 原則ひとりのみ PC を操作・閲覧することができる
- 30秒 x 2回までモブ作業を行うことができる
PO の「仕様書を渡す以外の Devs とのコミュニケーション禁止。質疑応答も禁止」と Devs の「行動フェーズ中のコミュニケーション禁止（筆談もNG）」が消えています。その他の制約は初回と変更ありません。コミュニケーションが解禁されるのです。
この制約で行う2回目のお題は以下のようなものでした。
お題2
このお題に対する成果物と取得ポイントは以下のようになりました。
左が成果物、右2枚が仕様書
取得ポイント
今回の満点は358ポイントです。チーム1は63%、チーム2は88%のポイントを得ているので、初回に比べて全体的に取得率が上がっています。ワークに対する慣れもあるでしょうが、コミュニケーションが解禁され PO と Devs、Devs 間の会話量が一気に増えたことも一役買っていそうです。
振り返り
振り返りでは参加者から以下のような声が上がっていました。
- こまめなコミュニケーションがあると、手戻りせずに済む
- 効果的に同期コミュニケーションが取れると仕事効率だけでなく、メンバー１人ひとりの開発体験が上がる。作業を楽しめる。
- 仕様書だけでは伝えられないことの方が多い。口頭などの双方向コミュニケーションが重要
- POが欲しいものを完全に言語化するのは非常に難しい
- 文章と口頭と視覚的イメージみんな大事
- 文字だけで伝えるのは難しいので、ポイントを仕様書に書きつつ、細かい所は口頭補足みたいなバランスが大事そう
- 仕様を書くの大変だなってみんな思ってくれたの嬉しい＼(^o^)／
- 作りたいものの品質が決まってないと、どこまで頑張って良いかわからないので、品質目標ってだいじ
- 事前の段取り(プランニング)を決まった時間内に終わらせつつ、共通認識を得るのが難しい
- 絵心がなにより必要だった
仕様書を作り切ることの難しさと、それを補うためのコミュニケーションの大切さを感じたようです。派生して品質目標やタイムボックスに対して思いを馳せるメンバーもいました。
まとめ
このワークショップを通じて @r0bins-egg さんがチームに感じてもらいたかったのは、スクラムの3本柱の一つである透明性の重要さでした。初回と2回目の違いは PO と Devs、または Devs 間のコミュニケーションの有無だけです。コミュニケーションを通じて要求や優先度、各自の作業状況に対する透明性を上げることが、それぞれの状況にうまく適応するための第一歩です。これを今後の業務でどのように活かせるか、普段の業務でよりコミュニケーションを活発にするにはどうしたらいいかを考えた上でワークショップは終了になります。
こちらのワークショップが気になった方はぜひご自身のチームでも実施してみてください。何かの気付きやきっかけになれば幸いです。
