nDiki : 会議

ミーティング すごい会議 ホワイトボード 問題解決 コミットメント・リスト アジェンダ ポイント アイデア コミットメント 議事録 メール 戦略的フォーカス お薦めの本 メモ コミュニケーション 開発 目標 投票 プリント キックオフミーティング KPT A4 書評 プレゼンテーション 選挙 Wiki デジカメ すごいやり方 ノート TeX

■ 「すごい会議」と問題解決のスコープ

前回は松下君と2人で。 2人だとホワイトボード1枚で書ききれて、ある程度手書きでノートできる範囲。 3人を越えると厳しくなってくる印象。

今日は別のプロジェクトで、体調不良のプロジェクトマネージャーと飛び入り総務部スタッフ。 2時間で「いま直面している問題はなにか?」+「コミットメント・リスト作成」まで。 過去3回と同じ進み具合。

若手出席者中心で適用してみた今までとは違い、今回は「いま、うまくいっていることはなにか?」「達成したいことはなにか?」「この会議で、達成したいことはなにか?」はサクサク進んでいく。 この辺りは年の功か。

この方法でミーティングを進めていくと核心をついた問題解決に辿りつけるのだが、スコープが大きくなりすぎるきらいがある。 プロジェクトの範囲を越えて、組織の体制のプロセスの改善まで包含してしまうものもしばしば。

裏を返せばそこから改善しないと適切な問題解決にならないということで、それを実行すれば効果も大きい。普段なおざりになっている部分も出てくるし。

しかしながら労力とコストも結構なものになるので、どの程度までやっていくかのバランスが難しいところだ。

• すごい会議はじめての全手順(1/2) (2005-06-30)
• 「すごい会議」2度目 (2005-06-03)
• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごくない会議 (2005-06-29)
• すごい会議の正しい手順 (2005-07-04)

■ ぜんたろう氏から nDiki にコメントを頂く

いやー、実際にどう使われるかの情報おもしろいです！（書き手にためになります！） -- ぜんたろう

え? 大橋禅太郎氏ご本人からのコメント? であれば大感激!

今まで意識的な会議進行をした事がなかったし、された事もなかった。 そこで出会ったのが「すごい会議」。 これはおもしろい。

すぐにできる範囲から適用しはじめた。一度他の人がやっているすごい会議というのを見てみたいのだが、なかなかそうもいかない。唯一は本にかかれている内容だけだ。 きっと他の人も、他人がどう実践しているかを知りたいはず。

ならばということで手探りで試してみている様子を、自分の備忘録、また(反面教師にせよ)すごい会議をやろうとしている人の参考になればと思って記事にしているというわけである (実際はそれほどタイソウではなくて、nDiki のネタにしたいとうのもあるのだが)。

あわよくば、誰かの意見をもらったり周囲を巻き込んだりできればと期待していたのだが、そんな記事を筆者の方に見ていただけたということは光栄だ。

「将来私が会社を回していくつもりですから」と言った手前、これからもはりきってまいる次第。

• 「すごい会議」2度目 (2005-06-03)
• すごいKPT事後評価セッション (2005-10-07)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• すごい会議の正しい手順 (2005-07-04)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)

■ すごくない会議

今日は自分ではない人が議長となった「普通」のミーティングに参加。

自分は一参加者として何か変革できないかと、「提案」「リクエスト」「明確化の質問」などすごい会議のポイントを書いた紙を手元におき常に意識するようにして望んでみた。 しかしながらそれでも、ついつい上の3点以外のタイプの発言が口をついてしまう。

すごくない会議に参加すると、あらためてすごい会議のすごさを実感。

今日のミーティングで感じた事:

• 書いて発表しないと、声が大きい方が勝つ。
• ホワイトボードに書かないので、空中に消えていきがち (今回はミーティングスペースの都合でホワイトボードが確保できなかった)。
• スピーチ多すぎ。
• 提案少なすぎ。
• 明確なコミットメント(誰、期日、成功のクライテリア)があまり決まらない。上の立場の人がコミットしているという感蝕がうすい。

議論自体は有意義に感じたのだが、コミットメントが決まっていかないと気持ち悪い。

• すごい会議はじめての全手順(1/2) (2005-06-30)
• 「すごい会議」をしてみる (2005-05-27)
• 「すごい会議」と問題解決のスコープ (2005-06-15)
• 「すごい会議」2度目 (2005-06-03)
• すごい会議の正しい手順 (2005-07-04)

■ すごい会議はじめての全手順(1/2)

6カ月間のプロジェクト*1のちょうど半分ということで、担当とコミットメントの再確認を含めたすごい会議を開催。 このプロジェクトでは約1カ月前にすごい会議をしてみているが、その時は「いま直面している問題はなにか?」の手順を終えたところでタイムアップ。

今回は長めに時間を用意して、全ての手順をやってみるというのもミーティングの一つの目的。

出席者は自分を含めて4人。

@ いま、うまくいっていることはなにか? 13:05 - 13:25 (20分)

前回より時間短縮。 皆慣れてきている感じ。

@ 達成したいことはなにか? 13:25 - 13:40 (15分)

やはり実務者ほど、短期間で設定する傾向がある感じ(いい悪いではなく)。

@ この会議で、達成したいことはなにか? 13:40 - 13:50 (10分)

実験。 今回はホワイトボードではなくA4の紙 (RHODIA No.19) 1枚を 4つに区切りそれぞれの達成したいことを書いてもらって、その後ミーティングのあいだテーブルの真中に置いておくことにした。

「ミーティング中それぞれ自分の達成したいことを意識できるようになるのでは?」という狙いであったが、結局あまり見返さなかった様子。

紙に書いたという点では:

• 席を立ちホワイトボードの前に移動してそこで書くより圧倒的にはやい
• 各自ノートする必要がない (後でコピーできるものが、その場にできるから)

というメリットはあるようである。

• A3以上のより大きい紙
• 大きい字で
• 太ペンで書く

にすればもっと目について効果があるかもしれない。

@ いま直面している問題はなにか? 13:50 - 14:35, 休憩, 14:45-14:50 (50分)

前回同様「解決案があれば赤で併記する(自分の/他人のどちらにでも)」というルールで。 それなりにアイデアが出る。

今回は別途担当者決め手順を行うので、終了後ホワイトボードをデジカメで撮って次へ。

この手順は皆の発言個数が増えるので、書き込みシートも余白を多めにしておいた方が良さそうだ。

@ 言えない問題はなにか? 14:50 - 15:35 (45分)

ここからは、今まで実施しなかった手順。

第一印象は「もっと過激なものが出てもいいのでは?」

いや「どのようにすれば～」形式にすることで、過激さが柔らいでいるのかもしれない(かつ、問題解決へ思考が向いた状態になっていると)。

それほどドラマチックな展開にならなかったが、「2段階で問題出しをする」ことで確かにより深く本質に近い問題が目にみえるようになるようだ。

@ あなた自身のひとい真実はなにか? 15:35 - 15:45 (10分)

それぞれが感じている倦怠感などが明らかに。 それぞれ何となく笑える感じ。本質に近づけているのか? いないのか?

自分自身としては、襟を正して気合いを入れなおさねばなという思いを持ったので意味はそれなりにあった。

ただし今回は

会議室のセットアップ (3) やばい話ができるぐらいのプライバシーがキープできる -- すごい会議 p.20

が実現されていなかったというマイナス要因があった。 会議の出席者ではない、別のスタッフ(特に上の人)がふらふらと来てのぞかれる可能性があると思うとなかなかズバンと書きにくい。

@ これからの6～12か月で、このチームが達成する成果はなにか? 15:50 - 16:20 (30分)

残り後3カ月に対する戦略的フォーカス決め。 てっきり全員最終日をターゲットに指定すると思っていたのだが、そうではなかった。

総意的には大きなブレが無かったのは助かった点。 既にチームとしての目標がしっかり共有できているということかな。

そうだとすると素晴らしい。

@ 今日はここまで (計3時間20分。休憩約10分を含む)

明日残りを行う予定。

• 「すごい会議」2度目 (2005-06-03)
• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごいKPT事後評価セッション (2005-10-07)
• 「すごい会議」と問題解決のスコープ (2005-06-15)
• すごい会議の正しい手順 (2005-07-04)

■ 東京都議会議員選挙

投票。

以前テレビで「投票用紙には、折って投票しても投票箱の中で自然に開くような紙が使われている」という風にいっていたので、実際に記入したあと4つ折りにして手元にポトリと落としてみた。

ほんとだ。

• 品川区議会議員選挙 (2007-04-22)
• 東京都知事選挙 (2007-04-08)
• 品川区長・品川区議会議員補欠選挙 (2006-10-08)
• 第20回参議院議員通常選挙 (2004-07-11)
• 第21回参議院議員通常選挙 (2007-07-29)

■ すごい会議の正しい手順

すごい会議FAQによると、付録の手順には誤りがあるらしい。

「最初の1、3、5が準備段階で一人でやる部分で、2からが参加者と一緒にやる部分」 すごい会議FAQより。

とのこと。すっきり!

• 手順5がミーティング前に行うというのは自明なのでミーティング時にはパスしていた(事前の招待メール時に適用)。
• その前に手順1、手順3 がくる事で手順5がパワフルかつ明確にできるようになると。
• 手順3。どおりで出席者が悩むわけだ。今回は既に走っているプロジェクトのメンバだった事からある程度方向性を共有していたのでそれなりに書けていたんだけれど、これは1人でやる手順なワケね。手順3と手順9がかぶっていて進をちょっと迷ったのだが、これですっきり。

@ 答えを作らない場所

また次の点も非常に参考になった。

ここでは、手順6、7、8は答えを作る場所ではないのです。 問題を前向きな形でたな卸しするだけです。 「答え」を提示する人がいたら、それはストップします(経営者自身がやってしまいそうになることも多くみます) ここで、誰かが「答え」を言ってしまうとドチッラケなのです。その答えが、各自、意識的または無意識のうちに手順11でコミットメントとしてその解決策が約束される可能性を最大化するためにやっているとお考えください。-- すごい会議FAQより。

もしや、思いっきりドッチラケだった?

さすがに手順8では答え作りしなかったけど、手順6、手順7では思いっきりアイデア出しに利用しちゃってたからなぁ。

• 初期の頃やっていたミーティングでは、手順6までしか時間的に進まなかったこともありそこでコミットメントに落としてしまっていた(担当と期日設定)。
• 先週の木金でやったミーティングでは、全手順を通してやるために手順6、手順7ではアイデア出しまでやった後、先に進めてみた。手順11でコミットメントを作る際、手順6、手順7で上がったアイデアを漏らしてしまわないかちょっと心配だったんだけれど、もともと答を作る場所でなかったのでなければ構わなかったということか。

@ リストにしてオシマイ

光栄な事にまた著者の大橋禅太郎氏よりコメントをいただいた。

初期のころの「この会議で達成したいことはなにか」を発表してもらってから、司会者がどうすればいいか? といったところがありましたが、司会者は特にそれについてはなにもすることはありません。そのほかにもグループとしての統一した「意思決定」がなくても進むやつは、リストにしてオシマイです。

ありがとうございます。非常に参考になります!

手順を眺めてみると、参加者と一緒にやる部分のうち前半はリストにしておしまいだ。確かにすごい会議の本文でも、実際に出席者が順に発言するところが描かれているけれどそれ以上は書かれていない。

そこに書かれていない何かをしているんじゃないかなとも思ったのだが、本当にリストアップだけで良かったのか。安心。

となると合意は

• 戦略的フォーカス
• 担当分野と担当
• コミットメント・リストと、そのチェックのしくみ

となる。

やはりすごい会議は最後の手順までやらないとオイシイところが食べられないわけだ。 ふむふむ。

はやく次のすごい会議の機会こーい。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• 「すごい会議」2度目 (2005-06-03)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• 「すごい会議」をしてみる (2005-05-27)
• すごいKPT事後評価セッション (2005-10-07)

■ すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく?

すごい会議をしてみて

• ホワイトボードに書き出したもののうち、後の手順で参照できるようにしておけるようにした方が良いのはどれ?
• ホワイトボードに書き出したもののうち、会議終了後に参照できるようにしておけるようにした方が良いのはどれ?

という点が悩ましい問題であった。

その点について大橋禅太郎氏に質問して教えていただいた。 回答を私のサイトで掲載することのお許しをいただいたので、以下にとりまとめ。

@ ホワイトボードに書き出したもののうち、後の手順で参照できるようにしておけるようにした方が良いのはどれ?

手順6,7,8,9,10,11。コミットメントリストをつくる際に、手順6,7,8,9,10の内容が見えればOK。 ホワイトボードでやるとはまるので、やはり巨大ポスト・イットを使うのがよい。

@ ホワイトボードに書き出したもののうち、会議終了後に参照できるようにしておけるようにした方が良いのはどれ?

• 戦略的フォーカス　
• 担当分野と担当
• コミットメント・リストと、そのチェックのしくみ

@ 手順6で思い浮かんだアイデアを活用するには?

目標達成に今役立つなら「コミットメント・リスト」に日付を入れた形で入れる。 そうでなければ(もしどうしても残したければ)どこか個人的にメモに残しておくのがお勧め(扱う情報は少ない方がよいとのこと)。

@ ぜんたろう節

上は私が要約しちゃったけれど、メールでいただいた返信は本の文章と同じ気さくでやさしい感じの文調であった。 いやむしろ、普段の雰囲気がそのままうまく本になっているというべきなのかな。

p.s.「すごい会議」で大きな敵は、「薄いホワイトボードマーカー」ですね。

には

そのとうりです。で近くにいいゴミバコがないことがほとんどなので、薄かったら、「床にすてる」が手順です。(あとでゆっくりゴミバコに入れればいいです)

とコメントいただいた。最高!

• 「すごい会議」2度目 (2005-06-03)
• すごい会議の正しい手順 (2005-07-04)
• すごいKPT事後評価セッション (2005-10-07)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• 情報カードを使って高速すごい会議 (2005-10-27)

■ 早朝会議革命 - 元気企業トリンプの「即断即決」経営

トリンプの吉越浩一郎社長による「会議を通したスピード経営」についてを、会議出席や社員へのインタビューを通して著者がまとめあげた1冊。

会議を中心とした内容であるが、「すごい会議」と同様ただ単に会議手法を述べた本ではない。 会議を通した経営についてが述べられている。

同社のMS会議 (Marketing and Sales 会議) は吉越社長が自部門の改革として始め、粘り強く改善・継続して全社的なものになったもので、そう簡単に真似ることができるものではないが、そのエッセンスには学ぶものが多い。

@ 朝開催

• 多くの人間が集まる時間帯。
• 集中できる時間。
• 同日に即行動に移せる。

特に最後のは魅力的。やる気がみなぎっている間に行動に移せる。 しかし、自分はオフピーク通勤が気にいっているからなぁ……。

@ 毎朝開催

当然週1回よりスピードがある。

回数は多いが、きちんと問題について意思決定しコミットメントに落としていくので無駄がない。

@ トップダウン

ただし民主的、フラット。

@ 「決める」会議

• 「誰が、何を、いつまでに」

ここら辺はすごい会議と通じる。

@ デッドライン

• ドイツ系の会社から。
• 厳しく。でないとみんな逃げる。
• 最大限で1週間。それ以上はスケジュール化。
• 稚拙でもいいから速く。

毎朝会議が開催され議論されることで、1週間でまわしていける。

@ プレゼンテーション

• プレゼンテーション自体を目的にしない。無駄に準備に時間をかけない。

@ コミュニケーションの場・情報共有の場

• 「和」を形成。
• 共通認識が広がる。
• 判断・決断までのプロセスを共有。プロセスから参加することに意味がある。
  • 意思決定に変化があっても理解できる。
  • 教育の場
    • 技は盗むもの。「教育なんてほんとはできっこない」。
• オープン、フェアネス。

見習いたい。 どのようにすれば我社で判断・決断プロセスから共有していけるようになるだろうか。

@ 継続

• 継続はトップの責任
• 改善こそ継続の母
• 成功するまでやれば、成功する。p.207

@ 結論から言え

• 言いにくくても、結論から言え。p.207

@ 感想

「決める会議」、「誰が、何を、いつまでに」という方針のメリットを再確認。

• 早朝会議革命 - 元気企業トリンプの「即断即決」経営

[ 書評 ] [ お薦めの本 ]

• すごい考え方 (2005-12-10)
• すごくない会議 (2005-06-29)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• すごい会議の正しい手順 (2005-07-04)
• 一緒に仕事をしたい人のタイプ (2006-03-17)

■ すごいKPT事後評価セッション

先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。

@ 招待状

参加者には、以下の事前準備をメールでリクエストしておいた。

• 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
• 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」)
  • スコープ、スケジュール、リソース、欠陥レベル
  • プロジェクト運営
  • コラボレーション (スタッフ間)
  • 個人・チームとして学習した点
  • その他 (開発手法など)
• 問題点については「どのようにすれば〜(だろうか)」のかたちに書き換えてください。(すごい会議流)
• 良かった点のうち Keep のものがあるかご検討ください (KPT法流)。
• 問題点は Problem です。(KPT法流)
• 問題点について「次にやってみたいもの(Try)」が思い浮かんだらメモしておいてください。(KPT法流)
• 問題点に関係なく Try してみたいものがあれば、メモしておいてください。(KPT法流)
• 注意点 (「適応型ソフトウェア開発流」)
  • 良かった点を必ず書いてください。(すごい会議にも通じる)
  • 成功点、失敗点については3つ以上でも構いません (その際は、成功点と失敗点が同数程度に)
  • 特定の個人を批評はいけません。
• 事前に考えたメモを K・P・T 別にA5〜A4用紙各1枚程度ずつにまとめてプリントアウトして持参してください (発表時間短縮のため)。

@ セッション

メンバは4人。 ホワイトボードをK(Keep)・P(Problem)・T(Try)の3領域に分割。

それぞれ用意してきたプリントをマグネットや、テープでホワイトボードに貼りつける。4人分ぐらいならホワイトボードに貼れたし、前に集って座れば字もだいたい読むことができた。

【Keep】まず最初に成功点について各自発表。「うまくいっている」ことから開始するのはすごい会議流で。 次のプロジェクトで Keep しておきたい点について確認しておく。

【Problem】どのようにすれば〜でそれぞれ発表(すごい会議流)。この形式で表現することで、アイデアが浮かびやすくなる。アイデアが出れば ホワイトボードの Try の領域に書き込んでいく。

【Try】あらかじめ考えてあった Try をそれぞれ発表。

KPTの発表が終わったら、今度は Try をコミットメント化していく。 「担当」と「期日」を明確に設定 (すごい会議流)。

@ 完了

合計90分。ほぼ予定時間とぴったり。 事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

今までの事後評価セッションに比べて次のアクションが明確になり、コミットメント化した事で実行する可能性が高まった。 成功点・問題点をそれぞれ発表して確認しあう段階までだった過去の事後評価セッションよりパワーアップ。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• いまいちパッとしなかった「ふりかえり」 (2007-02-28)
• すごい会議の正しい手順 (2005-07-04)
• ソフトウェアかんばん「見えない化」 (2006-04-10)

■ 効果的な複数人電話会議は?

年初あたりから社内で Skype が利用されはじめて、複数人による電話会議もよく行われるようになっているようである。 離れている拠点のスタッフ間での連絡が密になるなど、効果はあるようだ。

しかし自分は特に複数人における効果的な電話会議手法を見い出せていないので、積極的に利用していない。

@ 長所

• 物理的に離れているスタッフを含めた会議が可能
• 既存のインターネット接続上で Skype を使う分には通信コストが余計にかからない

@ 短所

• 顔が見えない
  • 聞いているのか、理解できているのわからない
• 通常の会議より時間がかかる / 同じ時間で決まることがすくない
• 回線断などがあると、しらける

@ 効果的に行うには?

アジェンダにしても参加者の下準備にしても、集合して行う時以上に周到に準備しておく必要があるであろう。 Skype だと気軽に召集できる感があるが、ミーティング中に伝達できる情報量は少ないのだからそれぞれ事前に資料を用意してメールなり、Wiki なりで情報を共有しておく必要がある。

たとえば、共同創造に必要な情報は顔を突き合わせてやり取りしたほうが効果的なのに対して、情報伝達に必要な情報は紙や電子ファイルの形態でも直接やり取りするのと同じぐらい効果的である。-- 適応型ソフトウェア開発 p.119

普通の会議と同様、情報伝達と共同創造の区別が重要である。

いわゆるミーティング、特にコラボレーションが、否定的に捉えられがちなのは、共同創造と情報伝達という2種類の基本的な相互作用が区別できていないためである。--- 適応型ソフトウェア開発 p.118

ほとんどの組織では情報伝達を濫用している。--- 適応型ソフトウェア開発 p.119

• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• すごいKPT事後評価セッション (2005-10-07)
• 「すごい会議」をしてみる (2005-05-27)
• 「すごい会議」2度目 (2005-06-03)
• すごい会議の正しい手順 (2005-07-04)