エクストリームミーティング - 版の履歴

2020年11月24日 (火) 15:58にPirotoによる

2020-11-24T15:58:21Z

2020年2月16日 (日) 04:19にPirotoによる

2020-02-16T04:19:23Z

Piroto: ページの作成:「==エクストリームミーティング== http://www.itmedia.co.jp/bizid/articles/0610/24/news008.html この記事のまとめ ===会議の何が問題なのか…」

2020-02-15T07:28:57Z

ページの作成:「==エクストリームミーティング== http://www.itmedia.co.jp/bizid/articles/0610/24/news008.html この記事のまとめ ===会議の何が問題なのか…」

新規ページ

==エクストリームミーティング==
http://www.itmedia.co.jp/bizid/articles/0610/24/news008.html
この記事のまとめ

===会議の何が問題なのか？===
=====会議の一般的な問題点=====
実際の会議では、これら4つの特徴がスパイラル的に悪循環をなし、悪い会議を生み出してしまいます。
*会議が迷走する
*会議が決まらない
*会議で決まったことが実行されない
*会議が長い
===会議が終わったときに議事録は完成してますか？===
会議術によって改善できるのは、何かを達成したいと信じている人たちの気持ちが削がれないように、うまく仕事を進めていくお手伝いをすることに過ぎません。
会議の生産性を上げたいと思うほどメンバーが熱心に仕事に取り組んでいることなのです。そしてメンバーが熱心になればなるほど会議は迷走しますし、会議の問題は深刻になります。
====プラクティス１議事録ドリブン（minute driven meetings and projects）====
議事録ドリブンとは、会議中に議事録をプロジェクタなどで投影し、みんなで議事録を協力して書きながら議事進行を共有し、会議の終了時点で議事録を完成させてしまうという方法
*会議が迷走しない
**いま何のトピックを話しているのか」が明確
**議論を脱線することなく議論に戻ることができます。
**「意見」にしか過ぎない発言と全員の合意が得られた「結論」は、マークや色分けなどで分かりやすく可視化
*会議が決まる
**「結論」の可視化によってどこまでが決まっているかが明確
*会議で決まったことが実行される
**議事録ドリブン会議では「いつまでに」「誰が」も必ず書くというルール
*会議が短い
**スパイラルに陥る要因を1つ1つ解決することによって、会議全体の時間を短くできます。
*会議が終わった後
**次の会議までの間に、議事録に書かれた結論やToDo（やるべきこと）に基づいて、各メンバーはタスクをこなしていき、次の会議のアジェンダを議事録として共同で作っていく
===この会議のゴールを知っているか？===
====プラクティス2──ゴールの共有（shared goals）====
*よいゴールは、達成したいことが具体的
*ゴールでは、何が達成されたら会議は成功なのかを、具体的に定義
*トピック＝　テーマ＋ゴール
*ゴールは決定されていることが重要なのではなくて、共有されていることが重要
*ゴールが納得をもって共有されて、初めてゴールは有効に機能
====プラクティス3──リマインド（remind meetings）====
*重要な問題を解決するためには、会議開催の前日に、会議時間と場所、会議のゴール、議題（アジェンダ）についてリマインドをする
===会議をいきなりはじめてないか？===
====プラクティス4──時間管理（time management）====
会議のファシリテイション（議事進行技術）で最も難しいものの1つ
#会議のゴールの確認
#会議の終了時刻の確認
#ToDoの見直し
#スケジュールの確認
#トピックのゴール、時間と優先順位の設定
===会議で「じゃあ、そういうことで……」と言ってないか？===
====プラクティス5──一度に1つのトピック（one topic at a time）====
*1つのトピックで結論が出ていないのに別のトピックに移動しても、時間を消耗して憔悴感が残るだけ
*相互に依存関係があるようなテーマのときは、複数の細かいトピックに分けて、最適な順番を考えてみましょう。
*複雑だからこそ、単純な論点の積み重ねによって事態の打開を図る
====プラクティス6──議事録の共同注視（joint attention on the minute）====
*参加者全員が議事録を共同注視する方法が有効
====プラクティス7──意味の明確化（clear definitions）====
*議論がかみ合うためには、いま話されていることが、「意見なのか」「結論なのか」「ToDoなのか」「雑談なのか」を、参加者全員が意識しなければなりません
*曖昧なままでトピックを変えてはなりません
*結論は一言一句その場で確認
*結論になった意見の先頭には、【結論】と書いて色付け
*ToDoを決めるときには、「誰が」「いつまでに」「何を」の3つが絶対に必要
*議論が迷走してきたら、議事録に【定義】と書いて、その後に言葉の定義を書いてみましょう。
===終了のホイッスルは次の会議の始まり===
====プラクティス8──終了時確認（final confirmation）====
#今回の会議で何が決まったのか（結論とToDoの確認）
#次に何をすべきか（次回会議までのToDo確認）
#次の会議はいつ誰が参加し、何を話すのか（次回会議設定）
===議は終わってもプロジェクトは終わっていない===
====プラクティス10──ロギング＆トラッキング（logging and tracking）====
*ToDoには確認者を必ず割り当て、担当者は確認者に報告をする
*ToDoのロストはかなり減ります
*ToDoのアウトプットの品質も向上
*報告会議はだめな会議の典型
====プラクティス11──マイルストーンの設定（set milestones）====
*プロジェクトのゴールとToDoの間を補完する中間的なアウトプットのことをマイルストーンといいます。
*プロジェクトが長期にわたる場合は、マイルストーンの設定によって、会議の議論の質は劇的に向上
*プロジェクト、マイルストーン、会議、ToDoは入れ子構造
===議事録はみんなが書けるか？===
普通いわれる情報共有は、「個人が持っている情報を組織に公開すること」を意味します。しかし、XM（エクストリームミーティング）では「そもそも個人では情報は持たない」ことを推奨しています
====プラクティス12──議事録の共同所有（collective minutes ownership）====
*議事録ドリブンならば、たとえ会議が始まる前でも会議参加者はアジェンダを勝手に追加できます。
*会議の進行役も、会議前にそのアジェンダの優先順位を上げたり下げたりできます。
*すでに上がっているアジェンダであれば、議事録に意見を書き込むことで、会議前に議論を始めてしまうことができます。
*会議中も議事録は共同所有されています。誰でもいつでも、誰かの意見を修正することができる
====プラクティス13──ToDoの共同所有（collective ToDo ownership）====
*誰がどんなToDoを担当していて、どんな状態なのかを、プロジェクトのすべてのメンバーがお互いに見えるようにしましょう。
*ToDoには担当者だけではなく、必ず確認者を置くことによって、デュアルチェックを働かせます。
====プラクティス14──共通の用語（common vocabulary）====
*会議中も、しばしば言葉の定義が人によって異なるために迷走します。
*会議やプロジェクトの問題の多くは、「何か」が共有されていないことによって起こります。
**議論のゴール、プロセス、結論　→　議事録
**仕事のゴール、プロセス、結果　→　ToDo
**概念　　　　　　　　　　　　　→　用語
*特にプロジェクト全体のゴールやプロセスの共有が重要
**プロジェクトのゴール　　→　プロジェクトの目的
**プロジェクトのプロセス　→　マイルストーン
**プロジェクトの結果　　　→　反省会
===会議に頼り過ぎない会議術===
*会議室では、問題を打開するための仮説が「ああかもしれない」「こうかもしれない」と次々と出されます。
*必要なのは、仮説の巨塔を積み上げることではなく、仮説を検証する具体的な手を打つこと
====プラクティス15──ラフコンセンサス＆エグゼキューティングタスク（rough consensus and executing task）====
*IETF（Internet Engineering Task Force）というインターネットで使われる技術の標準仕様を決める組織があります。この組織には“Rough Consensus and Running Code”という有名な標語があります。「ラフなコンセンサスを作ったら、プログラムを書いて走らせて試してみる」という考え方です。
*「世の中は会議室で頭を使って考えたとおりにはいかない」という経験則から導かれた実に優れた手法
*会議が長くなるばかりで何も生み出せないのは、実は小さなアウトプットをしないからです。多くの成功したプロジェクトは、小さな実験から始まっています。
*不可能だといわれたら、小さな既成事実を作ってしまえばいい

----

@@ 26行目: / 26行目: @@
 **スパイラルに陥る要因を1つ1つ解決することによって、会議全体の時間を短くできます。
 *会議が終わった後
-**次の会議までの間に、議事録に書かれた結論や[[ToDo]]（やるべきこと）に基づいて、各メンバーはタスクをこなしていき、次の会議のアジェンダを議事録として共同で作っていく
+**次の会議までの間に、議事録に書かれた結論やToDo（やるべきこと）に基づいて、各メンバーはタスクをこなしていき、次の会議のアジェンダを議事録として共同で作っていく
 ===この会議のゴールを知っているか？===
 ====プラクティス2──ゴールの共有（shared goals）====

@@ 1行目: / 1行目: @@
-==エクストリームミーティング==
+==[[エクストリームミーティング]]==
 http://www.itmedia.co.jp/bizid/articles/0610/24/news008.html
 この記事のまとめ
@@ 26行目: / 26行目: @@
 **スパイラルに陥る要因を1つ1つ解決することによって、会議全体の時間を短くできます。
 *会議が終わった後
-**次の会議までの間に、議事録に書かれた結論やToDo（やるべきこと）に基づいて、各メンバーはタスクをこなしていき、次の会議のアジェンダを議事録として共同で作っていく
+**次の会議までの間に、議事録に書かれた結論や[[ToDo]]（やるべきこと）に基づいて、各メンバーはタスクをこなしていき、次の会議のアジェンダを議事録として共同で作っていく
 ===この会議のゴールを知っているか？===
 ====プラクティス2──ゴールの共有（shared goals）====
@@ 41行目: / 41行目: @@
 #会議のゴールの確認
 #会議の終了時刻の確認
-#ToDoの見直し
+#[[ToDo]]の見直し
 #スケジュールの確認
 #トピックのゴール、時間と優先順位の設定
@@ 52行目: / 52行目: @@
 *参加者全員が議事録を共同注視する方法が有効
 ====プラクティス7──意味の明確化（clear definitions）====
-*議論がかみ合うためには、いま話されていることが、「意見なのか」「結論なのか」「ToDoなのか」「雑談なのか」を、参加者全員が意識しなければなりません
+*議論がかみ合うためには、いま話されていることが、「意見なのか」「結論なのか」「[[ToDo]]なのか」「雑談なのか」を、参加者全員が意識しなければなりません
 *曖昧なままでトピックを変えてはなりません
 *結論は一言一句その場で確認
 *結論になった意見の先頭には、【結論】と書いて色付け
-*ToDoを決めるときには、「誰が」「いつまでに」「何を」の3つが絶対に必要
+*[[ToDo]]を決めるときには、「誰が」「いつまでに」「何を」の3つが絶対に必要
 *議論が迷走してきたら、議事録に【定義】と書いて、その後に言葉の定義を書いてみましょう。
 ===終了のホイッスルは次の会議の始まり===
 ====プラクティス8──終了時確認（final confirmation）====
-#今回の会議で何が決まったのか（結論とToDoの確認）
+#今回の会議で何が決まったのか（結論と[[ToDo]]の確認）
-#次に何をすべきか（次回会議までのToDo確認）
+#次に何をすべきか（次回会議までの[[ToDo]]確認）
 #次の会議はいつ誰が参加し、何を話すのか（次回会議設定）
 ===議は終わってもプロジェクトは終わっていない===
 ====プラクティス10──ロギング＆トラッキング（logging and tracking）====
-*ToDoには確認者を必ず割り当て、担当者は確認者に報告をする
+*[[ToDo]]には確認者を必ず割り当て、担当者は確認者に報告をする
-*ToDoのロストはかなり減ります
+*[[ToDo]]のロストはかなり減ります
-*ToDoのアウトプットの品質も向上
+*[[ToDo]]のアウトプットの品質も向上
 *報告会議はだめな会議の典型
 ====プラクティス11──マイルストーンの設定（set milestones）====
-*プロジェクトのゴールとToDoの間を補完する中間的なアウトプットのことをマイルストーンといいます。
+*プロジェクトのゴールと[[ToDo]]の間を補完する中間的なアウトプットのことをマイルストーンといいます。
 *プロジェクトが長期にわたる場合は、マイルストーンの設定によって、会議の議論の質は劇的に向上
-*プロジェクト、マイルストーン、会議、ToDoは入れ子構造
+*プロジェクト、マイルストーン、会議、[[ToDo]]は入れ子構造
 ===議事録はみんなが書けるか？===
-普通いわれる情報共有は、「個人が持っている情報を組織に公開すること」を意味します。しかし、XM（エクストリームミーティング）では「そもそも個人では情報は持たない」ことを推奨しています
+普通いわれる情報共有は、「個人が持っている情報を組織に公開すること」を意味します。しかし、XM（[[エクストリームミーティング]]）では「そもそも個人では情報は持たない」ことを推奨しています
 ====プラクティス12──議事録の共同所有（collective minutes ownership）====
 *議事録ドリブンならば、たとえ会議が始まる前でも会議参加者はアジェンダを勝手に追加できます。
@@ 80行目: / 80行目: @@
 *すでに上がっているアジェンダであれば、議事録に意見を書き込むことで、会議前に議論を始めてしまうことができます。
 *会議中も議事録は共同所有されています。誰でもいつでも、誰かの意見を修正することができる
-====プラクティス13──ToDoの共同所有（collective ToDo ownership）====
+====プラクティス13──[[ToDo]]の共同所有（collective [[ToDo]] ownership）====
-*誰がどんなToDoを担当していて、どんな状態なのかを、プロジェクトのすべてのメンバーがお互いに見えるようにしましょう。
+*誰がどんな[[ToDo]]を担当していて、どんな状態なのかを、プロジェクトのすべてのメンバーがお互いに見えるようにしましょう。
-*ToDoには担当者だけではなく、必ず確認者を置くことによって、デュアルチェックを働かせます。
+*[[ToDo]]には担当者だけではなく、必ず確認者を置くことによって、デュアルチェックを働かせます。
-====プラクティス14──共通の用語（common vocabulary）====
+====プラクティス14──共通の[[用語]]（common vocabulary）====
 *会議中も、しばしば言葉の定義が人によって異なるために迷走します。
 *会議やプロジェクトの問題の多くは、「何か」が共有されていないことによって起こります。
 **議論のゴール、プロセス、結論　→　議事録
-**仕事のゴール、プロセス、結果　→　ToDo
+**仕事のゴール、プロセス、結果　→　[[ToDo]]
-**概念　　　　　　　　　　　　　→　用語
+**概念　　　　　　　　　　　　　→　[[用語]]
 *特にプロジェクト全体のゴールやプロセスの共有が重要
 **プロジェクトのゴール　　→　プロジェクトの目的
@@ 97行目: / 97行目: @@
 *必要なのは、仮説の巨塔を積み上げることではなく、仮説を検証する具体的な手を打つこと
 ====プラクティス15──ラフコンセンサス＆エグゼキューティングタスク（rough consensus and executing task）====
-*IETF（Internet Engineering Task Force）というインターネットで使われる技術の標準仕様を決める組織があります。この組織には“Rough Consensus and Running Code”という有名な標語があります。「ラフなコンセンサスを作ったら、プログラムを書いて走らせて試してみる」という考え方です。
+*[[IE]]TF（Internet Engineering Task Force）というインターネットで使われる技術の標準仕様を決める組織があります。この組織には“Rough Consensus and Running Code”という有名な標語があります。「ラフなコンセンサスを作ったら、プログラムを書いて走らせて試してみる」という考え方です。
 *「世の中は会議室で頭を使って考えたとおりにはいかない」という経験則から導かれた実に優れた手法
 *会議が長くなるばかりで何も生み出せないのは、実は小さなアウトプットをしないからです。多くの成功したプロジェクトは、小さな実験から始まっています。