はじめまして。この度ファシリテーションに関する記事を連載させて頂くことになりました,有限会社NTXの野口和裕と申します。この連載では,私が実際の現場で試してみたファシリテーションのコツを紹介していきます。
ファシリテーションとは?
ファシリテーションとは何か? 最近は関連書籍もたくさん出版され,一昔前に比べたら随分と認知度が高まっているようです。言葉として聞いたことがある人も多いかと思います。
ファシリテーションは一般的には会議・話し合いの技術というふうに思われていることが多いのですが,この連載では会議技術はもちろん「コミュニケーション・チームワークの技術」という側面でも解説していきたいと思います。
エンジニアにとってのファシリテーション
さて,「話し合い」というのは,エンジニアの仕事でどれぐらいの時間割合になるのでしょうか? 社内的には,プロジェクト内のミーティングや上司への作業の報告,対外的には顧客折衝や外注さんとのやりとりなど,エンジニアは技術職といいつつ,仕事の中で「話し合い」の占める割合はかなり大きいのではないでしょうか? 一説によるとプロジェクトマネージャの仕事の90%は「話し合い」ともいわれています。そこまで行かなくても日々の仕事のなかで「話し合い」の割合はかなりの部分あるのは実感するところだと思います。
つまり,エンジニアとしてこの部分の技術を磨くことは,自分自身の仕事をレベルアップさせる近道といえます。
エンジニア最大の悩み
エンジニアの悩みの1つは時間が足りないということではないでしょうか? できる人ほど忙しい,そしてベテランになればなるほど忙しい。私も会社員時代は,日々仕事に追われていました。なぜこんなにも忙しいのか? 仕事が予定通り進めばなんとかなるものの,そんな夢のようなことはなく,必ず何らかのトラブルに巻き込まれます。
トラブル対策会議
トラブルが発生した場合,その対策を練るために会議をすることも多いでしょう。普通は有識者を集めてトラブルの対策を練ります。例えばこんなケースを考えてみてください。ある機能を開発中に顧客の要求仕様を満足できないことが発覚したケースです。使っている開発ツールの制約事項だったとしましょう。開発メンバーからの報告であなたはこの問題を知ります。さぁどうするか?
とりあえず,開発ツールに詳しいメンバーや,関係しそうな人たちに声をかけると思います。場合によっては上司も招集するかもしれませんね。
ここで考えて頂きたいのは,こうした会議の時間です。
会議時間の間は参加者の作業も当然ストップします。この時間はロスタイムです。さらにロスは会議時間に留まりません。エンジニアは知的労働です。いい感じで調子に乗ってきたときに,一時中断されると,再び調子を取り戻すのにまた時間がかかるのは,みなさんも経験があるのではないでしょうか?
つまり気軽に会議を招集するのは楽ですが,プロジェクト全体でみたら作業効率は大幅ダウンになります。
時間の余裕を作り出すコツ
以前参加したプロジェクトで,私は1日中このような対策会議に出ていたことがあります。午前も午後も会議。本来の作業は進まず,深夜になってやっと自分の仕事ができるありさま(深夜2時から会議が始まったこともありました。勘弁してほしかったです)。
時間の余裕を作り出すコツは,まず『ムダな会議』をしないことです。情報をみんなで共有することは大切ですが,困ったからとにかく人を集めるということをしていれば時間はなくなります。
とはいえ,必要な会議もあります。効果的に情報の共有化をはかったことにより,あっと言う間に問題が解決したことも,何度もあります。
何がムダで何が必要か? その見極めが重要なのです。そのためには,次のことを事前に考えてみてください。
必要な会議の見極め方
もし,あなたが会議を主催できる立場にあるのなら。会議を開く前に次のことを考えるのです。
- 目 的…なんのために会議を開くのか?
- 目 標…今回の会議では,どこまで決めればよしとするのか?
- 参加者…だれを会議によぶか?
また,主催できない立場であれば,会議が始まって最初の段階で,目的・目標について,会議の主催者に確かめてみましょう。目的が不明の会議には断固として出ないという態度で臨みましょう。会議に参加することで何か仕事したような気分になっている人が多くいる場合は要注意です。
案外目的が不明確でも会議をしていることはないでしょうか? あるいは会議の参加者についても,とりあえず声をかけてみた,ということも結構あるのでは?
余談ですが,最近テレワークで仕事をすることが増えてきました。その場合プロジェクトメンバーが遠隔地に点在して開発を進めているので,顔をつき合わせて会議をするには全員がどこかへ集まる必要があります。交通費もかかるし,移動時間もいれるとかなりのコストがかかります。
そうなると事前に会議の目的・目標・参加者を時間をかけて十分吟味するようになりました。結果的に会議の数は少なくなりましたが,プロジェクト自体はむしろうまく進むようになりました。会議時間減少による時間の余裕がプロジェクト全体の余裕につながり,品質が向上したというわけです。
よい会議か,無駄な会議か。それは会議が始まる前にかなりの部分決まってしまいます。目的や目標,参加者を吟味するのに多少時間をかけても,その後のロスを考えたら十分時間はとりもどせます。会議が始まる前に,目的・目標・参加者を検討してみましょう。それだけでも結果は随分違ってくるでしょう。
よい話し合いのためのファシリテーションは会議が始まる前から始まっているのです。
-
会議に参加すると疲労する・・・
高田さん
こんにちは(返信おそくなり、すみません。。)
>たしかに会議が終わった後には疲労感があるので、
>仕事した気になっちゃいますね(汗)。
そうですよね、何もきまらずもめた会議であればあるほど、疲労感もかなりですよね。
コメントありがとうございました。Commented : #2 野口和裕 (2008/05/31, 16:31)
-
一日中会議
野口さん
こんにちは。
私が今仕事している開発現場では、一日中会議です。
会議が仕事、というくらい会議ばかりしてます。
たしかに会議が終わった後には疲労感があるので、
仕事した気になっちゃいますね(汗)。
毎月15日楽しみにしてます。Commented : #1 システムエンジニア高田 (2008/05/21, 07:48)
