InfoQ

News

カードゲームで分散プロジェクトのコミュニケーションを学ぶ

作者 Chris Sims, 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年8月20日 午後6時50分

コミュニティ
Agile
トピック
チームワーク,
コラボレーション
タグ
Agile2008,
教育,
分散チーム

Charles Suscheck氏が(リンク)、Agile2008でプロジェクトのコミュニケーション、計画、そして、コラボレーションの重要性について教えるため、どのように何種類もカードゲームのラミーを使うのかを示した。このゲームで、チームが様々なレベルで分散することによる影響と、プロジェクト期間中にチームに専門家を追加したり、外したりする影響を調査する。

トロントで開催されたAgile2008カンファレンスで(リンク)、Charles氏のセッションは(リンク)水曜日の午後2時に始まった。参加者は3つのグループに分かれ、各グループは5、6人から成っていた。

  •  第一グループは、Eメールだけでコミュニケーションできると言われた。そこで、書かれたメッセージを「メールサーバ」係がグループで順に回すことによってEメールの代わりにした。
  • 第二グループは、「電話」だけでコミュニケーションできると言われた。
  • 第三グループは、彼らがどのようにコミュニケーションできるかについて制限がなかった。

各チームには、「ユーザ」として指定された一人のメンバがいた。ゲームが始まるとすぐに、ユーザは完全なゲームのルールと、ゲームの各ラウンドで紹介されるルールの変更についても教えられた。もう一つのまとまったルールはチームの残りのメンバの間で分配され、各プレーヤーは一部分のルールしか持たなかった。

Charles氏のゲームの雛型は、ゲームで同時に最大6種類の異なるタイプのグループを持つことができる。

グループ 1: Eメールのみ。追加ユーザなし。
いくつかのタイムゾーンにまたがる地理的に分散しているチームを表す。

グループ 2: Eメールのみ。追加ユーザあり。
いくつかのタイムゾーンにまたがる地理的に分散しているチームを表す。

グループ 3: 電話のみ。追加ユーザなし。
文書を使わないチームを表す。

グループ 4: 電話のみ。追加ユーザあり。
 文書を使わないチームを表す。

グループ 5: オープンなコミュニケーション。最後の5分にユーザーを追加する。
助けを得るために専門家を入れることに遅れをとったチームを表す。

グループ 6: オープンなコミュニケーション。ユーザは最後の5分まで参加する。
うまくやっているので、専門家を外すチームを表す。

チームは3分間与えられ、コミュニケーションの制限なしで、自分たちを組織化し、どのようにコミュニケーションするか、チームの役割は何か、概ね彼らの戦略は何かを計画した。

次に、ルールが分配された。参加者はお互いルールを見せたり読んだりしないように言われた。しかし、彼らは、自分たちのグループで利用できるコミュニケーションチャネルを使って、ルールを自分自身で解釈して説明をすることができた。各チームで明白に規定されたゴールは、異なる種類のラミーでできる限り多くのラウンドを終えることであった。もっとも多くのラウンドを終えたチームが勝利者となるのだ。チームの中で、少なくとも一人のプレーヤーにあるルールが与えられていた。そのルールは、もっともよいスコアを持つ一人のプレーヤーが、チームの中で「勝利者」になることを示すものであると解釈できた。

このゲームは20分間行われ、チームは次々と別の種類のラミーを行った。ゲームが行われるにつれて、各チームのプロセスのギャップ、ルールの理解、明らかにされていない戦略とチームを適応していかなければならなかった。

20分が過ぎたとき、コミュニケーションに制限がないチームはほぼ11ラウンドのラミーを終え、同時に、追加の成果物として要求された実績を表すドキュメントを作成した。このチームは素早く決めたのだ。このゲームの目的はできる限り多くのラウンドを終えることなので、手のうちをすべて見せて、最初に「あがり」になりそうな人を手伝うように協力した。個々の「スコア」にはこだわらなかった。

「電話チーム」は、できる限り多くコミュニケーションするために電話会議のモデルを使うことに決めた。それでも、1ラウンドプレーするまで、誰か一人を「あがり」にするよう手伝うために協力する考えが浮かばなかった。結局、このチームは2ラウンドのラミーを終えた。

Eメールチームは、協力する段階にたどりつけなかった。一人か二人のメンバが、チームで「勝利者」になるために攻撃的にプレーしていた。このチームは、20分間でなんとか1ラウンドのラミーを終えた。

ゲームをした後で、Charles氏(リンク)は報告のセッションの司会をした。そこで、参加者は、経験や学んだ教訓を共有し、実際のプロジェクトの経験と比較した。多くの参加者が共有したのは、内部的な競争の力が、彼らが働いたチームで本当に協力するためには大きな障害物となったことであった。すべてのチームが、前もって計画の時間を与えられていてさえ、進行中に計画を調整するための高い処理能力を持つコミュニケーションの価値は目立つものであった。コミュニケーションの制限に関するこの側面は、ゲームをするスピードに制限が直接影響することよりも、その結果にさらに意味があったのかもしれない。

ゲームをするためのガイドライン一式は(リンク)、Agile2008(リンク)ウェブサイトで見つけることができる。

原文はこちらです:http://www.infoq.com/news/2008/08/11

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

ジャンル別一覧

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。

消費者主導契約を使ったサービス指向開発

この論文では、組織のサービス開発能力改善を目指した実用的な提案をします。

スケーラビリティの構築とパフォーマンスの達成:バーチャルパネル

InfoQ.com向けのこのバーチャルパネルでは、大企業やプロジェクトからスケーラビリティやパフォーマンスの著名人を招待し、みんなが夢に描いているような結果を達成するための秘密を明かしてもらいました。

アジリティのためにコンポーネントチームより機能チームを選ぶ

Craig Larman氏とBas Vodde氏は、どのように、そして、なぜ機能チームがうまくいくのかを説明し、この主要な組織の変化が価値あるものであることを主張します。

仮想化とセキュリティ

仮想化にはたくさんの利点がありますが、かと言って、その上に実装するアプリケーションのセキュリティをないがしろにしてはいけないのです。

Rubyのオープンクラス:猿のようにパッチを当てない方法

最近リリースされたRuby 1.8.7のプレビューリリースをウオッチしていたRails開発者はすぐに1.8.7プレビュー1に関してあることに気がつきました。それは、1.8.7プレビュー1がRailsを破壊してしまうということです。