オープンスペース(オープンスペーステクノロジー)のやり方

オープンスペースとは

手軽な準備でディスカッションを開催することができるワークショップ。オープンスペーステクノロジーと呼ばれることもある。 参加者がトピックを提案し、ディスカッションが必要な課題を話し合う。参加者の当事者意識・主体性を引きだし、活発な対話を促す。

複数チーム間の知識伝達に使ったり、カンファレンスで皆が気になるテーマのディスカッションが実現できる。

やり方

1. 参加者を集め、この後の流れ(オープンスペースのやり方)を説明する。
2. 皆の見える場所に「場所(議論するスペース)」と「時間(タイムボックス)」からなる表を描く。
3. 参加者にディスカッションしたいトピックを提案してもらう。提案されたトピックを表の空いている箇所にトピックをあてがっていく。
   • 付箋にトピックを書き、前に出てもらって簡単に説明してもらい。早いもの順で表を埋めていくと良い。
4. 全部埋まったらタイムボックスにしたがってディスカッションを開始する。各トピックのファシリテーションは提案者に行ってもらう。
5. 参加者は興味がある場所へ移動してディスカッションを行う。「思っていたトピックと少し違った」、「参加者が多くて話しにくい」、「ディスカッションに貢献できそうにない」などを理由に、他のトピックへ移動してもよい。
6. 必要であれば内容をまとめ、参加者間で共有する。

参考

speakerdeck.com

オープン・スペース・テクノロジー - Wikipedia

bliki-ja.github.io

www.youtube.com

オープン・スペース・テクノロジー ~5人から1000人が輪になって考えるファシリテーション~

posted with amazlet at 18.06.28

ハリソン オーエン
ヒューマンバリュー
売り上げランキング: 95,111

Amazon.co.jpで詳細を見る

人と組織の「アイデア実行力」を高める――OST(オープン・スペース・テクノロジー)実践ガイド

posted with amazlet at 18.06.28

香取 一昭 大川 恒
英治出版 (2018-06-13)
売り上げランキング: 6,463

Amazon.co.jpで詳細を見る

アジャイル開発に使う文房具の使い方・選び方

模造紙の貼り方

対角線の上をなぞるように貼るとたわまないようになる。

ワークショップにおけるコツの研究（9）模造紙の貼り方 | 経験デザイン研究所

付箋

強粘着を買う

貼って・剥がしてを繰り返していると粘着力が落ちてくるので3Mの強粘着ポストイット一択。 値段のことで購入を渋られても強粘着を買いましょう。

剥がし方

上にめくらない、横にめくる

www.youtube.com

付箋に書くためのペン

ボールペンで書くと読めないので、サインペンで大きく書く

お道具箱

サインペン、付箋を入れておく箱は用意しておいた方がよい。

参考

www.ryuzee.com

scrummasudar.hatenablog.com

バックログ管理でデジタルツールを使わない方が良い理由

概要

JIRAとかRedmineとかVersionOneとかXXXとか。 プロダクトバックログはまだ良しとして、スプリントバックログは絶対に避けること。

1. 拠点分散されていませんか
2. ツールを強制されていませんか
3. PCを向いて話すことになり、ミーティングでの雰囲気が悪くなりませんか
4. タスクが増えても気がつきにくいと思いませんか
5. 顔を上げると見えるようになっていますか

1. メンバが拠点分散されていませんか

離れた場所で働く人がチームにいることがデジタルツールを使う理由になっていませんか。 地理的に離れた人とアジャイル開発を行うことは難易度が高いです。 ツールを導入するよりも同じところで働く解決策が取れないかをまず考えましょう。

2. デジタルツールを強制されていませんか

「全社標準」の名の下にデジタルツールを使わされていませんか? 強制的に使わされるものではチームの生産性は上がらないでしょう。

またデジタルツールを使う場合、チーム内のやり取りがツールの仕様に制限されてしまいます。 チームが開発効率を高めるための施策を思いついてもツールの限界がチームの改善の限界になってしまいます。

3. PCを向いて話すことになり、ミーティングでの雰囲気が悪くなりませんか

スプリント計画ミーティングで皆がノートPCを覗き込んで話すことになります。 お互いの顔を見て話した方がいい雰囲気になりませんか。

4. タスクが増えても気がつきにくいと思いませんか

スプリント途中で誰か(例えばスクラムマスター)が新規タスクを追加したとして、デジタルツールで気がつきますか? アナログだと視覚的に差分が見えるので気がつきやすいでしょう。

5. 顔を上げると見えるようになっていますか

スプリントが順調に進んでいるかはこまめに確認が必要です。 ブラウザやアプリを起動して画面を切りかえないと見えないのと、顔を上げると自然と目に入るのでは大きな違いがあります。

備考

スプリントバックログはカンバンボードでなくてもよいです。 例えばソフトウェアの全体図を描き、改善を入れるポイントに付箋を貼るだけでも役割を果たすことができます。

ネタ元

2018年5月 LeSS実践者研修にて

10分間で説明できないコードならリファクタリングを始めよう

解説

複数人でプログラムを書いていると実装スキルの差やドメイン知識の差からコード品質にばらつきができてきます。 中・長期で安定した成果を産んでいくにはこまめなリファクタリングが必要ですが、「リファクタリングをこまめにやろう」と呼びかけると終わりのないリファクタリングを始める人が出てきたりします。綺麗なコードは際限がないので相手にリファクタリングを依頼するにもきっかけがつかみにくくなってしまいます。

ネタ元で提唱されている案は「詳しそうな人に説明してもらい、10分間で何をやっているコードなのか理解してもらえなければリファクタリングする」というものです。10分と時間を区切ることで短期間で判断することができ、始めるきっかけも「ちょっとこのコード説明してよ」と詳しい人に依頼するのみです。10分で説明できたとしても話を聞いた人はコードに対する新たな知見を得ることができ、無駄になりません。

ネタ元

medium.com

スプリントレビューを配信する

概要

複数チームでスプリントレビューを開催する際の解決策の1つ。

プロダクトオーナー、ステークホルダーを会議室に集め、チーム代表者が代わる代わるスプリント成果のデモを行う。この様子をテレビ会議システムなどを使って配信し、開発メンバはそれを視聴する。

背景

開発メンバが増えてくるとレビューに参加する関係者が「開発メンバ >>> ステークホルダー」となり、1箇所に集めて行うスプリントレビューではディスカッションが十分にできない。 バザー形式のスプリントレビューとすると、ステークホルダーが分散されることでステークホルダー同士の議論が深まらないことも起きうる。開発メンバはステークホルダーがどう感じたか生のコメントで誤解なく知りたい希望を持っていたりする。

詳細

開発チームが調達できるテレビ会議/配信システムを用意し、デモを社内/関係者が見れるようにする。利用するシステムによってはスプリントレビューを録画し、あとで参照することもできるかもしれない。

視聴メンバからの質問は音声チャット/テキストチャットなどの仕組みを設け、レビュー中に適宜取り上げるようにすると良い。。

ネタ元

実体験。アジャイル開発に取り組んでいる海外の関係会社メンバに教えてもらった。

バザー形式のスプリントレビュー

概要

複数チームでスクラム開発をするときのレビューのやり方の一つ。 プロダクトオーナー、ステークホルダー、開発メンバが参加し、各ブースに自由に立ち寄ってスプリントの成果を確認し、ディスカッションを行う。

コツ

1. 時間を区切り、ブースの説明員を変更する。説明員も他のブースの説明が聞けるようにする。
2. 時間を区切り、参加者に他のブースに移動するように定期的に促す。
3. バザーの終了後、全員で集まってどのような話が各ブースで挙がったのか、次に何を優先するべきかをステークホルダーを交えて話し合うと良い。

参考

www.youtube.com

LeSSカンファレンスでのバザー開催の様子を映した動画。

Review bazaar – Agile and Scrum Blog

ネタ元

Sprint Review - Large Scale Scrum (LeSS)

複数チームでのバックログリファインメント

概要

LeSS(Large Scale Scrum)で推奨されている複数チームでのバックログリファインメントのやり方。

詳細

LeSSは「基本スクラム」なので、定期的にリファインメントを実施し、直近数スプリントのバックログの見通しがつくようにしておく。

1. Overall Product Backlog Refinement (全体バックログリファインメント)

プロダクトオーナー、スクラムマスターまたはチームの代表者が集まり、Multi-team Product Backlog Refinementへ回す項目をピックアップして選択する。Multi-team Product Backlog Refinementに先立って実施する。

2. Multi-team Product Backlog Refinement (複数チーム混成バックログリファインメント)

開発チーム(スクラムチーム)で見積もりをしてもらうのではなく、チーム横断の混成グループをつくり、グループで分担して見積もりをしてもらう。例えばOverall Product Backlog Refinementで15のストーリーを詳細見積もりする必要があると判断し、開発チームが3つある場合、全開発メンバを3グループにわけ、5つのストーリー詳細見積もりを各グループに依頼する。アイテムの詳細見積もりにステークホルダーの知識が必要になることもあるので、同席してもらえるならばMulti-team Product Backlog Refinementに招待するとよい。

全グループが1箇所に集まり、バザール形式で開催する。ステークホルダーやグループ外メンバの知識が必要であれば声をかけて場所を移動してもらい相談する。

チーム横断グループを構成することで下記のメリットがある。

1. 見積もり(ストーリーポイント)のチーム間のズレが抑えられる。
2. チームがストーリーに着手した際に、見積もりに参加したメンバがいることが期待できる。

プロダクトオーナーはMulti-team Product Backlog Refinementに参加しない。これは開発メンバが増えるとプロダクトオーナーが開発全体のボトルネックになってしまうからである。プロダクトオーナーがいないと見積もり時に生じた疑問を解消できない課題があるが、逆に開発メンバに考えてもらう好機と捉え、各グループで「疑問」とそれに対する「決断」を簡単に残すようにするとよい。開発メンバには決断する練習機会となり、チームが自律的に開発を進める土台が固まる。またプロダクトオーナーは「疑問」と「決断」の記録をあとで参照することで、自らの考えがどの程度開発メンバに伝わっているかを確認することができる。

ネタ元

Product Backlog Refinement - Large Scale Scrum (LeSS)

参考

• draft/product-backlog-refinement.jp.md at master · LeSSStudy/draft · GitHub
• プロダクトバックログ・グルーミングとはなにか？ | Ryuzee.com