2008年4月10日木曜日

会議・提案のためのテンプレート - 議事録を予め作りこみ、事後条件を明確にしておく

1. 話し合う前に、フォーマットを決めておく

何らかの作業を共同で行い、「話し合い」が必要なとき、ダラダラとした雰囲気で進行しまうことがある。特に、小さなプロジェクトにおいて、話し合いの内容が不明確なときに生じやすい。

話しあうべき内容が明確なときは、話し合いもスムーズにいく。解決すべき対象がはっきりしているから、ゴールが見えやすい。

しかし、話し合いというのは、お互いに先が見えないから、

「どうしようか?」

と相談する場合が多い。

こういうとき、予め「話し合いの流れとなるフォーマット」を意識していないと、話し合いのテンションを維持できない。

  1. 話し合いで、「決める作業」と、
  2. 話し合いの結果、「行うべき作業」

が同時進行してしまい、迷走することがよくある。

 

2. 議事録は、予め、穴埋めするだけの状態まで作り込んでおく

「議事録」とは、話し合いをするときに、その内容を記録するための手段。

議事録は、会議の記録であり、結果を残すためのツ-ルという意味合いが強い。その形式は、組織や個人により異なり、バラエティに富んでいる。

どういった記録の取り方が、効果的なのだろう?

議事録のプロ:ITpro によると、

... 「決まったことだけ書いてください。それ以外は基本的にいらないといっていいでしょう」

書き方について、次のように述べられている。

会議が始まる前に既に議事録のフォームが用意されていて,その日の会議で決定すべき項目が列挙してあり,どう決まったかを書くところだけが空欄になっていた。

(同上より。太字は引用者による)

整理すると、

  1. 書き方の形式が決まっており、
  2. 会議で、決めるべきことが、列挙されていて、
  3. 決定されたことを埋める欄がある。

 

テスト ドリブンなソフトウェア開発との類似性

この議事録の取り方から、

テスト ドリブン

という言葉を連想した。

テストドリブン (TDD) とは、

  1. 予め、開発対象のモジュールに対して、仕様を満たすためのテストを書き、
  2. その後、テストを満たすように、仕様を実装する

というスタイルをとる、ソフトウェアの開発手法。テストが、満たすべき仕様の外観を示し、実装は仕様を満たすように記述する。

この類比として、上記の議事録の書き方を理解した。

会議に先だち、予め話し合いで決めるべきこと、つまり、外観を記述する。これがテストドリブンな開発スタイルにおける、「テスト」に相当する。具体的な手順 (how) を示すのではなく、何 (What) が必要なのかを列挙しておく。

会議では、列挙された内容について話し合う。これは、具体的な内容・手順を実装するすることに相当する。

 

3. 変化に対応するために、議事録はその場で共有し、会議を方向付ける

テストドリブンで重要なのは、上記に加え、リファクタリングと、一連のプロセスを繰り返し適用していくこと。

リファクタリングとは、仕様を満たしながら、実装を、後で変更しやすいように、実装を変更するための方法。実装を、理解のしやすさの視点から整理することにも用いられる。仕様が明確に宣言されていれば、リファクタリングの結果は、仕様によって妥当性が保証される。仕様が、検討している内容の道標となる。

ソフトウェアの開発において、仕様は頻繁に変更される。これは、話し合いにおいて、話し合う内容が変化していくことに類似している。話し合うことによって、それまで必要と思われなかったことが明らかにされたり、逆に、必要だと思われていたものが必要でなくなったり、優先順位が変化したりする。

そのような変化は、話し合う内容が迷走しないために、記録し、その内容が話し合いの場に反映されなければならない。そのため、話し合いに参加している人の間で、議事録はリアルタイムに共有される必要がある。

手法を明確にし、その手順に添っていくということが重要になる。人は、一定の手順を踏まないと、習慣化されるまでは、脱線し、思考が拡散し、迷走してしまう。ただし、脱線し、はみ出ることは、重要。はみでたものをうまくすくいあげる技法を整備しておけば、新しいものを産み出す萌芽となる。

第1回 会議の何が問題なのか? には、「議事録ドリブン」という言葉が用いらている。

議事録ドリブンでは、会議中に議事録を書いてしまい、会議終了時点では参加者全員の合意がとれた議事録が完成しているという状態を作ってしまいます。

先ほどの、議事録の書き方も、議事録ドリブンと言える。議事録が話し合いの方向を決め、テーマを拡散・収束させていく手段となる。

 

4. 会議のためのテンプレート

上記を実行するために、シンプルなテンプレートを作成しておくことにした。

以下を、話し合いの前に作成しておき、話し合いは、これを元にして行う。そして、リアルタイムに議事録を取り、その内容を見ることができるように、Google Docs を利用することにした。

Read this doc on Scribd: 会議・提案テンプレート

 

テンプレートの内容

内容は、以下の 5 つから成っている。

  1. 目的
  2. 時間
  3. 検討内容
  4. 事後条件
  5. アイディア

目的」は、簡潔に話し合いの目的を書く。できれば、一行で集約される文が望ましい。数行に渡って記述されていては、目的を把握するのが難しくなる。もし、それ以上になるようであれば、内容を分割する必要がある。

時間」は、話し合いに制限時間を設けるために必要な項目。時間内に済ませるというプレッシャーを刺激として利用する。

検討内容」には、「目的」を満たすのに必要な事柄を列挙する。話し合いでは、この内容をどのようにして実現するかについて話し合う。話し合いの結果、検討内容が増えることもあるだろうし、また、逆に減ることもある。場合によっては、別の「目的」が立てられ、後日、話し合うことになることもあるだろう。

事後条件」は、「目的」を満たすべく提案された「検討内容」を話し合った結果、どのような状態が実現されていなければならないかを予め書いておく。

この文書は、作成されたと同時に、話し合いに参加する人の間で共有しておくのがよい。会議の前に、予め読んでおくいてもらう。検討内容に対して、「アイディア」があれば、予め加えてもらっておく。話し合いをしている中で、ひらめいたことは、どんどん書いていく。

 

後で読む