第29回 議論すべき会議とそうでない会議
野村隆(eLeader主催)
2007/8/28
| 将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点=“私点”からそれらの悩みの背後にあるものに迫り、ITエンジニアを続けるうえでのヒントや参考になればと願っている。 |
■リーダーシップトライアングルにおける位置付け
この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点=私点」を皆さんにお届けしております。
今回は、リーダーシップトライアングルのCommunicationに関係します。Communicationについては、第8回「コミュニケーションはリーダーシップの基礎」を、参照いただければと思います。
![]() |
| 図1 リーダーシップトライアングル。今回は「Communication」に関連する内容について解説する |
■ある社長のヒトコト
先日、あるテレビ番組を見ていたところ、製造業系の企業の社長が出演されていました。番組内で、その社長が、いろいろな示唆に富んだ発言をされていたのですが、「会議で発言できない人は会議に出席してはいけない」という内容をおっしゃっていました。
| フリーエンジニアになりたい、フリーとしてどう生き残ればいいか分からない。そんな人のために、@IT自分戦略研究所では、「フリーエンジニアカンファレンス2007」を企画しました。「安定した案件を受注するテクニック」など、具体的なノウハウを伝授。詳しくはセミナーページを! |
これは本田技研工業の創業者である本田宗一郎氏のいうところの、「ワイガヤ手法」が、Hondaのものづくりの力の源泉であるといわれているように、ワイワイ、ガヤガヤと闊達(かったつ)な議論をすることで、ものづくりの力が醸成されるという考え方に基づくのかもしれません。つまり、「会議で発言できない人は会議に出席してはいけない」という考え方は、製造業系の会社では美徳とされるのだろうと考えられます。
また、製造業系の会社でなくとも、アイデア出しの手法としてブレインストーミング(ブレスト)という手法を取ることは珍しくありません。ブレストを実践された方ならば分かると思いますが、ブレストのような会議においては、出席者の積極的な発言がないと会議自体が成り立たないので、「会議で発言できない人は会議に出席してはいけない」という考え方は正しいと思います。
ただ、私が、ここでの社長のひと言を聞いたときに、少しばかり釈然としないものを感じました。なぜ、釈然としなかったのかを考えたところ、会議の性質によっては、「会議で発言できない人は会議に出席してはいけない」という考え方が正しい場合と、必ずしも正しくない場合があると思ったからです。
それでは私が考えたことを、具体的に説明してみましょう。
■「検討会」と「報告会」という分類
私が、上記の例で挙げた社長のヒトコトが当てはまると考えた会議、つまり、「ワイガヤ手法」や「ブレスト」のような会議は、事前に定義された明確な議題・テーマについて、何らかを検討する会議といえるでしょう。このような会議をここでは「検討会」とします。
一方で、システム開発プロジェクト、特に大規模プロジェクトなどでのリーダー格の人が集まる会議があります。このような会議では、上記のような「検討会」を経て、テーマや議題が検討された結果の報告を受けたり、報告に基づき意思決定をしたりする会議となります。このような会議をここでは「報告会」とします。このような「報告会」を適切に運営して、プロジェクトの円滑な運営につなげることは、私のプロジェクトマネージャとしての主要作業の1つです。
私が「会議で発言できない人は会議に出席してはいけない」という考え方に、釈然としないものを感じるのは、「報告会」のような会議を日々運営する経験上、「報告会」においては、この考え方が当てはまらない場合が多いのではないかと思っているためです。
■「報告会」は「検討会」と異なる
ここで、「報告会」と「検討会」の違いについて考えましょう。
上で説明したように、「検討会」は、事前に定義された明確な議題・テーマについて、何らかを検討する会議です。議論は積極的にすべきです。また、「検討会」において、自分が正しいと思う方向性や結果に議論を導くためには、ある程度、発言を多くしないと、ほかの参加者に主導権を握られてしまいます。会議を実り多きものにするために、発言が多いことはよいことだとされるべきでしょう。
一方で、「報告会」は「検討会」と異なります。「報告会」では、「検討会」において、現場・チームで各種検討した状況(進ちょく状況も含みます)や検討結果(課題やリスクなども含みます)をまとめ、現場・チームのリーダー格が報告し、それを受けて、意思決定する会議といえます。
「検討会」との大きな違いは、特定のテーマ・議題を検討することが目的ではないということです。あえていえば、プロジェクトの運営という漠然としたテーマがあるだけです。
このように、「検討会」と「報告会」とでは、会議の性質やレベルが異なります。
■「報告会」での発言の考え方
ここまで考えて、話を元に戻します。
「検討会」においては、発言することが求められますが、「報告会」では発言しなければダメなのでしょうか?
私は必ずしもそうではないと思います。その理由として、前述したとおり「報告会」と「検討会」では性質を異にしているからです。
会議での発言に関して「報告会」における望ましい態度は、参加者の発言をよく聞いて、皆の意見を総合し、正しいと思われる方向性を熟考し、結論に導く。こういう態度が「報告会」を運営する人には望まれるわけです。
いい換えると、「報告会」においては、議論百出の状況をつくり出してはいけないわけです。「報告会」と「検討会」の違いを認識し、かつ、「報告会」の時間が限られていること、「報告会」の参加者には、忙しいリーダークラスの人がいることを考えれば、「報告会」が長引くことは避けなければなりません。従って、「報告会」では闊達な議論をさせないように会議を運営すべきであることは理解できるはずです。
■「報告会」での失敗例
「報告会」と「検討会」の違いをうまく認識できていない場合の悪い例として、以下のようなものが挙げられます。
例えば「検討会」でたくさんの発言をして主導権を握って成功してきた人が「報告会」でも、同様に主導権を握ろうとする場合です。「検討会」のように「報告会」で主導権を握ろうとするために多く発言しようすると、たいてい、失敗します。検討が目的ではない「報告会」では、自ら発言して仕切るよりも、むしろ発言は控えて、誰が何を主張しているかを正確に把握するくらいがちょうどよいのです。
さらに悪い例としては、プロジェクトにおけるシステムや業務に関する知識について、特に必要がないのに延々と自説を述べる場合です。これでは、自己顕示欲を満たすために「報告会」に参加しているメンバーの時間を浪費しているだけです。
決して、こんなことをしてはいけません。
それにもかかわらず、「報告会」において、誰かが知識を自慢すると、それに負けじと、自分の知識自慢を始める人が少なくありません。こういう人を見ると、非常に残念に思います。
ほかにも残念に感じるのは、リーダーのマネジメントをする管理者が「報告会」にて、断片的な知識で現場を語るときです。現場からある程度離れてしまった人の、過去の経験に基づいた現場感というのは、時として、情報として古かったり、記憶のあいまいさも手伝って不正確だったりします。
無論、リーダー格の人が現場を把握しようと努力すること、現場にハッパをかけることは否定しません。しかし、報告を受け、決断をする「報告会」において現場を熱く語る必要はありません。
■5分以上議論する人間はばか?
今回の「検討会」と「報告会」の違いについて考えているときに、ふと、思い出した言葉を紹介します。
明治・大正を通じで名宰相といわれた原敬氏は、よくこういったといいます。「5分以上議論する人間はばかだ」
これをこのまま、「検討会」に当てはめることはできません。「検討会」において、ある程度時間をかけて議論する必要があります。
ただ、「報告会」について考えると、これは真理なのではないかと思います。
「報告会」において、細かい議論が目安として5分以上続いたら、「報告会」の目的から外れ始めていると認識した方がいいでしょう。
その議論をしている人を、原敬氏の発言の文字どおりにばか呼ばわりすることは避けるべきです。ただ、「報告会」の目的を考慮して、「議論するならば、別途、検討の会合をスケジュールしませんか」と、議論すべき会議の提案をすることをオススメします。
| 筆者プロフィール |
| 野村隆●大手総合コンサルティング会社のシニアマネージャ。無料メールマガジン「ITのスキルアップにリーダーシップ!」主催。早稲田大学卒業。金融・通信業界の基幹業務改革・大規模システム導入プロジェクトに多数参画。ITバブルのころには、少数精鋭からなるITベンチャー立ち上げに参加。大規模(重厚長大)から小規模(軽薄短小)まで、さまざまなプロジェクト管理を経験。SIプロジェクトのリーダーシップについてのサイト、ITエンジニア向け英語教材サイト、人材派遣情報サイトも運営。 |
ITエンジニアを続けるうえでのヒント バックナンバー
- 第1回 WhyとHow、どちらで悩みますか?
- 第2回 なぜ「決めただけではダメ」なのか?
- 第3回 失敗を恐れず行動しよう
- 第4回 現場で学び、将来への不安を減らす
- 第5回 リーダーシップは生まれつきの才能ではない
- 第6回 正しい行いは将来を変える
- 第7回 中心は「ココロ」、リーダーシップトライアングル
- 第8回 コミュニケーションはリーダーシップの基礎
- 第9回 ソフトウェアは目に見えない
- 第10回 正しいことをし、行動力を発揮するココロ
- 第11回 信頼は河原の石のように
- 第12回 「見える化」だけでは見えないもの
- 第13回 プロジェクト成功につながる100年の杉苗
- 第14回 「もっとスキルを」が引き起こす問題
- 第15回 困難に立ち向かうリーダー、逃げるリーダー
- 第16回 自分を陥れた人に感謝する理由
- 第17回 苦境でも人を恨んでいる暇はない
- 第18回 スペシャリストはリーダーになれない?
- 第19回 プロジェクト運営で重要な「リアリティ」とは
- 第20回 その「リアリティ」はプロジェクトに不必要
- 第21回 石につまずいて怒りますか?
- 第22回 スキルや経験より大切なもの
- 第23回 最近、あなたは職場で人を褒めましたか?
- 第24回 人を育てるためには我慢して待ちましょう
- 第25回 やる気を重視すれば将来は明るい!?
- 第26回 筋の通ったプロジェクト運営を目指そう
- 第27回 最後まであきらめないココロ
- 第28回 デキる技術者になるためのちょっとした心掛け
- 第29回 議論すべき会議とそうでない会議
- 第30回 せきばらいで会議をコントロールする?
- 第31回 なぜか、頑張らない人たちの行く末
- 第32回 欲しいのは、PDCAサイクルが短い人
- 第33回 朝令暮改は悪いこと?
- 第34回 オフショア成功に必要な「ある特性」
- 第35回 何でオフショア開発しなくちゃいけないの?
- 第36回 「面倒」なオフショアを、それでも行う3つの理由
|
|
| スキルアップに役立つ問題を無料で出題 | |
| ITスキル研修4000件、最新情報の検索できます |



公認会計士試験合格者数がさらに削減へ、金融庁が「一層抑制的に」