システム要件の手戻りを防ぐためには「適切な議論の促進」が必要

「炎上しない会議」はよい会議なのか?

 ときどきこれいう人いるんですけどね。

「指摘も何もなく終わったんですよね?こちらの言う通りでよかったじゃないですか」

 大体議論が咀嚼できていないか、ちゃんと準備できていないといった大事な問題が隠れていることが多いのです。

 で、後になってからいろいろ言われたり、炎上したりするパターン。

テストフェーズで無理な指摘を受けたりしてね。
「そんなことまで気づかなかった!」って言われるのである

情報量が多すぎる

 これは大体において、議論を持っていく側に原因があることが多いです。大体、システムにかかわることで「その場」でぱっと理解できることって多くないですからね。

いきなりこんなに大量のことを説明されても困るよってもんです

 かといって「会議の時間を長く」しても冗長化したり発散するだけであまり意味がありません。

 事前に「ある程度」内容を展開しておいて、向こうでもインプットしておいてもらって話をするべきだと思います。

 まああとは、資料でもわからないことたくさんあるので、説明をしながら疑問を解消していく感じで行くと、本気度は上がっていくと思います。

会議の目的を理解していない

 これもあります。説明したいのか、合意形成の場なのかみたいなところですよね。

 これは必ずしも参加者だけに問題があるわけじゃなくて「ここで全部決めるよ」みたいなことが伝わっていなかったり、当日になっていきなり呼び出されたりとかまーいろいろあるんです。

 そこをある程度理解してあげないと、うまくすすみません。

そもそも会議というもの自体を理解していなかったりしてね。
むっちゃ疲れるパターン。

事前の「プレ打ち合わせ」をしよう

 なので、これをよくやりますね。どこに影響が出るかを事前に少人数ですり合わせておいて「合意形成」の場は別に設けるパターン。

 で、事前の打ち合わせと「合意形成」の場それぞれにベンダーを呼んじゃったりする人、結構いるんですけど、これは止めた方がよいと思います。

・ベンダーのいる場で要求をだすとそれが要求になっちゃう
・整理されていない状態で議論を重ねるとベンダー側のモチベーションが落ちがち
・無駄な工数を消費しがち

「なぜ発言できないのか?」を考えてみる

 私自身は割と無邪気ベースで話すタイプですが、発言できないにはいろいろと理由があります。

 いろいろありますが、一番根底にあるのは「否定されることへの不安」ではないかと思っています。

 本来会議なんですから、否定されることなんて当たり前なんです。そこでは、参加者も上司(まとめ役)も、双方「会議のルール」を理解することが必要だと思います。

 会議は進行一つでかわりますからね。

 そこでは、ファシリテーションスキルなんていうものも参考になると思います。

 まあ議論って体力使いますからね。。。「情シスで全部考えといてよ」みたいな話になることも少なくなくて、これ、すごい疲れるパターンなんですけどこれは頑として聞きません。

 そういった意味では「推進できる」「強い」情シスであらなければいけないと思っています。

 しかし、だんだん求められるものが高くなってきているような。。。
 昔ながらの意識の情シスにとってはキビシイ時代だなあって思ってます。


いいなと思ったら応援しよう!