それで、そういうリーダー役の人が、ミーティングをつうじて了解した事をたんたんと記録していけばいいんです。あとで読んでわかりやすいように、適当にグルーピングしたり、前後を入れ替えたりするのもあり。
議事録はプロジェクトのメンバーにまずドラフトとして公開され、メンバーはリーダーの現時点の主観に対して、いやそれは勘違いだとか、あのことをもう忘れているのかとか、それは妄想で勝手な書き足しだとかつっこむ。そういうやりかたのほうが、実は安全だと思います。
議事録が大事なのは、議事録自体をリリースするための確認もふくめて、あとで読み返せるところにあるんで、議事の進行をそのまま記録しているようなやつは、あとで読み返しにくい。まずつまらないから読みたくない。リーダーの主観がむき出しになっているようなもののほうが、メンバーも緊張して読めるというものです。リーダーがまとめ上手ならさらに言うことなし。
でもリーダーっていうのもヒマそうにみえて、案外忙しいもので、できれば議事録くらいもっと楽に書きたいと思っているかもしれない。楽に、というか、たとえば、プロジェクト管理で Trac のチケットを使うように、あるいは、 Jude でユースケース図やクラス図を書くように、はたまたソースコードが、Subversion でバージョン管理されているように、もっと合理的に書けて、そして管理できないものかな、と。
Jude のようなアプリで、アジェンダごとにクラスのようなボックスを作業エリアにクリエイトする。ボックスの中は大きくふたつに区画されていて、それぞれ要求と仕様を書くエリアになっている。そして各区画には、さらに要求や仕様の説明を書けるスペースが用意されている。
この要求と仕様と説明の区別、清水吉男の「要求を仕様化する技術」で強調されていることです。わけのわからない仕様書って、要求と仕様が区別なく列挙されていて、なおかつその合間あいまに、要求でも仕様でもないたんなる説明が挟み込まれているもんだといっていて、たしかに思い当たります。昔はそんなのばっかりでした。
要求というのはシステムがどんな効用をもたらすべきなのかということ。仕様というのは、要求が具体的にどのように実現されるのかということ。説明は、どうしてそのような要求がなされるのか、どうしてそのような仕様が選択されるのか、その理由を述べることです。
この区別を意識することって、議事録を書く上でも有用だと思うんですよね。そう思って、それを一種のパターン言語にしたてて、入力支援アプリを使って議事録を書いてみる。
あるテーマをめぐってなされる最初のブレストやエキスパートに向けられた質疑とその応答なんかはみんな説明の枠に書くことになります。
そうした応酬をへて、結局、会は何かを決定するわけです。決定されたことは、だいたい要求か仕様かのどちらかになるでしょう。要求として、プロジェクトのさまざまな目標が明記され、そして、仕様のほうには、誰がいつまでにどうやって何をするのかという、プロジェクトの ToDo リストの一項目になりえる事柄が書き込まれていきます。
そうして出来上がったアジェンダごとのボックスは、線で連結して相互に関連づけることができる。関連線には、クラス図のように関連の仕方やタイプをあらわす名称を与えることもできる。関連づけは、別の会議のボックスとの間でもできる。
それから、議事を進行しながらライブで記述していく場合は、ボックスを作成した時刻や入力が行われた時間が記録できる。記録された時刻や時間は、会議にかかった時間やアジェンダごとの時間の配分がわかるようにあとでグラフ化して見ることもできる。
また、音声入力ができる場合は、会議中の音声も録音される。録音は現在アクティブなボックスごとに再生できるように行われる。そうなると、書記も兼ねるリーダーは、話題の振れ方におうじてアクティブなボックスを切り替えなくちゃいけなくて忙しいかもしれませんね。
あとは、もちろんキーワード検索はできるし、ボックスを記録された時刻にそって順番にスライド風にビューできたりもするし、関連づけにこだわらず、似た話題のボックスを出現する特徴語で機械的に分類してもらえたりする...。
なんてまあ、そんな議事録アプリがあって、実に立派な議事録が作れちゃったりすると、それを眺めているだけでぽーっしちゃって、厳しいプロジェクトのリーダーなんてつとまらないかもしれませんね。
-----------------
sent from W-ZERO3
0 件のコメント:
コメントを投稿