 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||
|
||||||||||||||||
| 日常業務と隔離された開催場所とする | ||||||||||||||||
|
開催場所も重要だ。極力、メンバーを日々の業務から途絶できるような環境としたい。 議論が盛り上がってきた際の中座は、デメリットが大きいからだ。対話が膠着した場合に、ターニングポイントになるような一言や、見解がポツンと突然でて視界が開けることがある。ところが、中座して戻ってきた当人からすれば、浦島太郎のような状況に陥ってしまう。そのため、盛り上がりかけたコンセンサスのムードが、トーンダウンしてしまうことが往々にして起こり得る。 実際に、こんなケースがあった。「業務をERPにあわせるのか」、それとも「従来通りスクラッチ開発がよいのか」という議論になった時のことだ。ERP肯定派の役員にとっては、願ってもないテーマだったようで盛んに怪気炎をあげていた。それが、その総大将の中座によって論議が沈静化してしまった。 ところがその直後、たまたま「自社独特のビジネスモデル形成はERPでなければできないのか？」という疑問が呈され、「ERP vs.スクラッチ開発」から「当社のビジネスモデルとは何か？」へ議論が移った。IT化の革新部分の話がいよいよ展開されると思いきや、ERPの総大将が帰還すると、たちまちERPの表層的な話題に戻ってしまった。 こうしたことも頭において、短い中座で済むなら会自体に休憩を入れるなど、運営の工夫は欠かせない。 対話テーマは、「経営者から日々指摘されていること」や、「経営者に理解してほしい事柄」から構成するのがよい。 「今まではこうしてきた、これからはこうする」という論調では報告になってしまう。これでは、承認する・しないのレベルになって目的は達成できなくなる。 話を発展させるには、「どのように考えたか」、「何が障害か」を軸にしたい。その過程で、経営者とIT部門が、ギャップを認識できさえすればよい。つまり、経営者や現場の意見を認識する。そしてその上で、結果として、「何をどのように判断し、何をこれからしようとしているか」を先に話していくべきだ。 例えば、「基幹システムの整備意図」、「効果の再認識」、「現時点で困っていること」を順に話題としていくという具合だ。 対話の進行は、あまり意図的にコントロールしない方がよい。基本となるテーマと見解は提供するが、流れはその場任せとする。ただし、間違った理解がなされた場合や、さらに議論を理解してもらうための話題のスイッチなどでは、積極的に介入すべきだ。 先ほどの例では、中座後にERPの話に戻ってしまった際に「退出された後にこんなやりとりがありまして、このような意見がでました」と、簡単に要約して流れを戻しておくべきところだ。 残念ながら先の話では、内容に気を取られてた上に少々遠慮したことで、スイッチし損ねるという結果になってしまった。 最後に議論の簡単な振り返りは実施してよいが、議論の蒸し返しにならないように配慮することは必要だ。 加えて、先に述べたように結論付けや、実行責任の明確化といったことの義務付けは極力しない方がいい。このミーティングは、結論を出すことや責任を明確化するものでなければ、承認を得る場でもない。あくまで、相互の意見を「交流」させて相互の「気づき」を誘発する場なのだ。自発的に責務を負うのでなければ避けるべきだろう。 ただし、後日の経営会議等でオフサイトミーティングの話題をミッションに昇華させるような行為は大いに奨励したい。 オフサイトミーティングを導入した多くの企業で、その後の活動が停滞してしている要因の1つにこの昇華プロセスが欠けてことがあげられる。 しかるべき場で意思決定を行うようになれば、ミーティング自体のメリハリは効き、サクセスパスがより明確になる。そして、長きにわたっ熱意を持続させることも可能になる。 |
||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
