アル中プログラマの備忘録。もはやコーディングしてないけど。

酔いどれまさになう。プログラマとして就職し、システムエンジニア、プロジェクトマネージャーと立場を変えながら、システム開発に関わるとあるアル中の成長記録。

プロジェクトマネジメント

会議を効率的に進めるにはきちんと準備しよう

投稿日:

meeting

会議

必要だからやっている会議ではあるものの、多いときには一週間でいったい何時間費やしているのでしょうか?
1回の会議にしても、例えば5人で1時間行う場合、仮に一人月が80万円、労働時間が160時間/月(8時間/日✕20日)とすると(80 ÷ 160) ✕ 5 = 2.5万円かかっていることになります。
ということは、少なくともそれ以上のものを得る必要があるということですね。そのためにどうしたら良いか、考えたり試していることを書きます。

よくある問題

会議については以下のような問題がよくあると思います。

  • 長い
  • 決まらない
  • 脱線
  • 決まっても守られない

しかもこれらが悪循環になっています。長いと脱線しがちですし、脱線してたら長くなかなか決まりません。長くなってくると妥協で決めてしまったり、決まったことで満足してしまうので、実行に移されにくくなります。

少しでもよくするために

ではどうしていけば良いのでしょうか?段取り八分と言いますが、やはり準備が大切です。

なぜその会議をするのか?

まずはこれからです。数万円の買物を意味もなくしないのと同じで、何らかの目的があるはずです。情報共有かもしれませんし、アイデア出しかもしれません。顔合わせ程度の軽いものから、経営方針の決定のようなものまで様々だと思います。

会議が終わったときどうなっていたら良いのか?

なぜ会議をするのか?の目的を満たせて入れれば良いはずですので若干重複しますが、これも大切です。もちろん思ったとおりの結論になるとは限りませんが、はじまり(理由)とゴールを用意しておけば、脱線に気づきやすく修正もしやすくなります。

例えば、この時点では有力案が2つあるのでそのどちらかに決めるのがゴールだとしても、実際に会議してみたらより良い第3案が見つかることはあります。でもそれは脱線せず両者を比較検討していて見つかったものなのでやはりゴールを見据えて議論を始めたことは役に立っています。

ゴールは会議によって様々だと思いますが、もしこの時点で払うコストに似合うゴールがないのであれば、その会議は不要なのかもしれません。

誰に参加してもらうか?

例えば顔合わせであれば関係者全員いたほうが良いでしょうし、相談や決め事であればステークホルダーや専門知識のある人を呼ぶことも大切だと思います。ただし、呼び過ぎて人が多くなると会議はまとまらなくなるので、あとで情報共有だけすれば良い人は外したりします。

具体的にその人に何をして欲しいかを考えると呼ぶべきかどうかを判断しやすいです。そして参加依頼する際も、何を期待しているか伝えたほう良いです。相手もよくわからない会議にいきなり呼ばれるよりは、何を求められてるか分かっていた方が安心して参加できます。

先に議事録(議題)を作ろう

議事録は会議後に書くのが普通かもしれませんが、ここまで考えたのをまとめるために先に書いてしまいます。
できれば日時や決定事項の他に、先に検討した項目を記入できるテンプレートを作っておくとそれを埋めながら準備ができるので楽です。

まだ会議は開かれてないので議論の内容は空欄ですが、いつ、どこで、誰が、何のために会議を行い、終わったあとにはどうなっているかが明確になります。

参加依頼と合わせて議事録を送ってしまおう

せっかくまとめたので、参加依頼と一緒に記事録もアジェンダとして送ってしまいましょう。先に書いたとおり期待している役割も添えることで、呼ばれた人は何をすべきかがはっきりわかります。

正直なとこと全員が予め議事録を読んでくれるわけではない点が今後の課題ではありますが、ここまでしておくと当日ようやく集まったのに経緯の説明だけで半分以上かかってしまったとかということがだいぶ減ります。また、議事録を渡した時点で意見をもらえることもあります。例えば「そもそも論」などは会議中に出てくると厄介ですが、この時点で出てくれれば会議を延期して再検討など柔軟に対応できます。

会議中は議事録に従って進める

すでに整理しているので、会議中はそれに沿って進めれば良いので比較的に楽です。アイデア出しで意見が出なくなってしまったり、逆に拡散しすぎて収拾がつかなくなることもありますが、それはまた別のやり方があるので機会があれば書きます。

何を話し合うかを事前に共有しているため、脱線しかけてもそれはまた今度と言えば伝わります。

最後に決まったことを確認することと、次にやることはできるだけ期限と担当者付きで合意すること

準備のおかけで良い感じで会議ができたとします。でも、本当は会議で決まったことを実行してやっと価値があるので、最後にもう一踏ん張りします。

会議が終わると次にやることや確認しておくべきことが出てくるので、できるだけその場で担当を振って期限を設けましょう。ここで決めておかないとまた集まるのは大変ですし、それぞれ他にもやる事を抱えているので、実行されないままになってしまいます。

最後に追記した議事録を送ろう

参加依頼で送っていますが、実際の議論の内容や決定事項、次やる事、その担当や期限を追記して再度送りましょう。よくやるのは会議中に議事録を映しながら追記していき、最後に内容確認と合意、解散後すぐに送付という流れです。こうすると送り忘れも減りますし、追記内容に間違いがないことを全員見ているので再度確認も不要で楽です。

難点は司会と追記を同時にやると辛い点です。書記を用意できるなら誰かにやってもらったほうが楽だと思います。

さいごに

慣れないと準備にすごく時間がかかってしまいますが、自分の時間が少し無駄になっても会議参加者全員の時間が有効に使えたならトータルではお得なはずです。まだまだ改善の余地があると思うのでこれからも試していきたいと思っています。

酔いどれまさになう。



-プロジェクトマネジメント

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

関連記事

要求

要件定義について思うこと、依頼主との関係性が一番大切で一番難しい

要件定義 まさに要件を定義するのですが、実際には要求、要望など似た表現が微妙なニュアンスの違いで使い分けられていたり、その分け方も現場によってまちまちだったりして難しいです。 しかし、細かい差異を無視 …

入り口

Developers Summit 2012に参加してきました

Developers Summit 2012 名称:Developers Summit 2012 (デブサミ2012) 会期:2012年2月16日(木)・17日(金) 会場:目黒雅叙園(東京・目黒) …

完了

プロジェクトマネージャーとしてのはじめてのプロジェクトを終えて

ふりかえり このブログのタイトルは「アル中プログラマの備忘録」ですが、プログラマではなくなってしまいました。仕事でソースコードを書くことは当分なさそうです。(アル中な部分はそのままですが) さて、プロ …

カテゴリー