この記事についてaiに評価してもらいました




■「沈黙は部下の主体性の問題ではない」という指摘

「何か意見ある人?」

会議の終盤、上司がそう問いかける。

少し間があっても、誰も口を開かない。

ところが会議室を出た途端、

「あれは現場では無理じゃない?」
「私もそう思っていた」
「たぶん、この部分で詰まるよね」

と意見が出てくる。

ある記事では、このような「会議室での沈黙」を取り上げ、原因を「最近の若手は受け身だから」「自分の意見を持っていないから」といった個人の性格や能力に求めるべきではないと指摘している。

そして、

「どう思う?」ではなく、「この案の懸念点を一つ挙げてください」と聞く。
会議前に資料を共有する。
上司が最初に意見を言わない。
チャットやメモでも意見を受け付ける。

といった方法を紹介し、

「人を会議に合わせるのではなく、会議の設計自体を調整するべきだ」

と結論づけている。

この問題提起は重要である。

実際、会議室では黙っていた人が、会議室を出た直後には意見を話しているのであれば、「そもそも意見を持っていなかった」という説明は成立しにくい。

しかし、この記事にはもう一段掘り下げる余地がある。

「人ではなく会議を変える」と言うだけでは、なぜ発言が起きなかったのかをまだ説明できていないからである。

■元記事は「人」から「環境」へ原因を移した

元記事の重要な転換は、沈黙の原因を見る場所を変えたことである。

会議で発言しない
↓
主体性がない
↓
本人を変える

という発想ではなく、

会議で発言しない
↓
発言しにくい環境になっている
↓
会議を変える

と考えている。

これは一歩前進である。

しかし、ここで注意したい。

「本人に問題がある」という説明が粗いのと同じように、「環境に問題がある」という説明もまた粗いのである。

元記事自身が挙げている例を見ても、それがわかる。

「どう思う?」では何を答えればよいかわからない。

上司が20分説明した案なので、反対してよいかわからない。

その場では考えがまとまらない。

口頭より文章のほうが意見を伝えやすい。

以前に意見を出しても退けられたので、「どうせ言っても変わらない」と考えている。

これらはすべて「発言しにくい環境」とまとめることはできる。

しかし、発言しない理由はそれぞれ違う。

したがって、必要な対策も違う。

ここを区別しないまま「会議の設計を変えよう」とまとめてしまうと、結局は会議改善のテクニックを並べることになる。

■「どう思う?」の問題は、問いが自由すぎることではない

元記事では、「どう思う?」という問いの曖昧さが指摘されている。

何について意見を求めているのか。
アイデアを広げたいのか。
問題点を指摘してほしいのか。
上司の案に反対してよいのか。

それがわからなければ発言しにくい。

これはその通りである。

しかし、重要なのは「質問を具体的にしたほうがよい」というテクニックではない。

なぜ具体的にする必要があるのかである。

組織における行動を、次のように考えてみる。

行動 = 機会 × f(想起 × 理解 × 納得 × 実行可能 × 評価期待)

それぞれの意味は次のとおりである。

機会 = その行動をする人・場面・頻度が存在すること。
想起 = その場面で、その行動を思い出せること。
理解 = 何をすればよいかわかっていること。
納得 = その行動の意味や価値を受け入れていること。
実行可能 = 時間・能力・権限・環境などの客観的制約を踏まえ、自分は実行できると認識していること。
評価期待 = 行動したときに、評価や成果が返ると期待できること。

今回の行動を、

「会議中に必要な意見を表明する」

と置いてみよう。

「どう思う?」と聞かれたとき、

賛否を答えるのか。
問題点を挙げるのか。
代案を出すのか。
現場への影響を説明するのか。

がわからないのであれば、行動生成式でいう理解が成立していない。

だから、

「何でもいいから自由に言って」

と自由度を高めても解決しない。

むしろ、

「この案を実行した場合、現場で問題になりそうな点を一つ挙げてください」

としたほうがよい。

「問いを具体的にする」という方法が有効なのは、それが優れた会議テクニックだからではない。

発言に必要な理解を成立させる操作だからである。

■元記事が挙げる対策は、それぞれ違う問題を処理している

ここから見ると、元記事が紹介している複数の対策が、実は同じ目的で行われているわけではないことがわかる。

たとえば元記事では、上司が長く説明したあとに「どう思う?」と聞くと、

「ここからひっくり返していい話なのだろうか」
「反対するなら代案まで出さないといけないのでは」
「上司はもうやりたいと思っているのでは」

と部下が考えてしまう例が挙げられている。

この人は、意見を持っていないわけではない。

何が問題なのかも理解している。

それでも言わない。

自分にそこまで言ってよい権限があるのかわからないからである。

これは実行可能の問題として捉えられる。

実行可能とは、単に能力があるかどうかではない。

時間・能力・権限・環境などの客観的制約を踏まえ、「自分はこの行動を実行できる」と本人が認識しているかどうかである。

この場合に必要なのは、

「今日はまだ決定前なので、この案そのものへの反対意見も出してほしい」
「代案がなくても問題点だけ指摘してよい」

と発言可能な範囲を明示することである。

一方、元記事が指摘する「その場では考えにくい人」については事情が違う。

会議前に資料を渡す。
考える時間を設ける。
文章でも回答できるようにする。

という操作が必要になる。

これも実行可能に関係するが、制約になっているのは権限ではなく、時間や表現環境である。

つまり元記事が一括して「会議の設計」と呼んでいるものの中には、異なる制約に対する異なる操作が混在しているのである。

■「どうせ変わらない」は、会議形式を工夫しても解決しない

元記事の中でも、とくに重要なのが、

「どうせ変わらない」という諦めが蔓延する前に

という指摘である。

反対意見を出しても、すぐに退けられる。

何を言っても結論は変わらない。

そんな経験が続けば、人は「ここでは黙っていたほうがいい」と学習する。

この指摘も妥当である。

しかし、これは「どう思う?ではなく具体的に聞く」という問題とは、まったく種類が違う。

何を言えばよいかはわかっている。
発言する能力もある。
発言してよいこともわかっている。

それでも、

「言ったところで何も変わらない」

と思っている。

これは行動生成式でいえば、評価期待の低下である。

発言しても、意思決定の改善や適切な反応という成果が返ってこないと期待している。

それが続けば、

「そもそも発言する意味がない」

と考えるようになり、納得まで低下する可能性がある。

この状態の組織に、

チャットを導入する。
事前に資料を共有する。
質問を具体的にする。

といった対策を行っても、本質的な問題は解決しない。

必要なのは、

出された意見をどう検討したのか。
なぜ採用したのか。
なぜ採用しなかったのか。
意思決定にどう影響したのか。

を返すことである。

元記事が紹介している対策は、どれも一定の意味を持つ。

しかし、どの対策が有効なのかは、発言を阻害している制約が何なのかによって決まる。

この構造が説明されていないことが、元記事の限界である。

■「人と環境の組み合わせを見る」だけでは、まだ粗い

元記事では、

「組織では、人を変えようとする前に、人と環境の『組み合わせ』を見ることが大切です」

と述べられている。

この考え方も方向としては正しい。

しかし、「人と環境の組み合わせ」という言葉だけでは、実務で何を見ればよいのかがわからない。

必要なのは、

その環境において、目的とする行動のどの成立条件が欠けているのか

を見ることである。

理解が成立していないのか。

実行可能が成立していないのか。

評価期待が成立していないのか。

納得そのものが失われているのか。

そこまで特定して初めて、

問いを具体化する。
発言可能な範囲を明示する。
事前に情報を渡す。
別の表出経路を設ける。
意見と意思決定の関係を変える。

という操作を選べる。

したがって、元記事の、

人を変えるのではなく、環境を見る

という転換は正しい。

しかし、もう一段進める必要がある。

環境を見るのではなく、行動を成立させていない制約を見るのである。

■元記事には、さらに一つ重要な前提が隠れている

そして、元記事をさらに批判的に読むと、もう一つ検討すべき前提が見えてくる。

それは、

「会議では意見が出るほうがよい」

という前提である。

もちろん、元記事が単純に「発言数が多いほどよい」と主張しているわけではない。

しかし、「誰も意見を言わない会議」を問題として設定し、「話せるようにつくられた会議」を目指している以上、発言が起こることを望ましい状態として置いている。

しかし、本当にそうだろうか。

会議にはさまざまな目的がある。

情報を集める。
問題を発見する。
選択肢を増やす。
選択肢を評価する。
意思決定する。
決定事項を共有する。

単なる決定事項の共有なら、全員から意見を引き出す必要はない。

責任者が判断すべき問題なら、参加者全員の合意を取る必要もない。

逆に、現場にしか存在しない情報を集めなければ意思決定できない会議なら、その情報が表出しないことは重大な問題である。

したがって、本当に見るべきなのは、

発言が多いか少ないかではない。

その会議で成立させたい状態に必要な情報や判断が、必要な人から表出したかどうかである。

■「会議の設計」より先に、「会議で何を成立させるのか」がある

元記事は最終的に、

「人を会議に合わせるのではなく、会議の設計自体を調整する」

と結論づけている。

ここまでの議論を踏まえると、この結論も少し修正したほうがよい。

会議の設計から考え始めるのではない。

まず、

この会議で何を成立させたいのか

を定める必要がある。

そこから逆算する。

会議で成立させたい状態
↓
そのために必要な処理
↓
必要な参加者行動
↓
その行動の成立条件
↓
成立を阻害している制約
↓
制約に対する操作

たとえば、会議の目的が、

「新しい業務フローを実行した場合に発生する問題を、意思決定前に発見すること」

だとする。

そのためには、現場を知る参加者から懸念点が表出する必要がある。

ところが発言がない。

そこで初めて、

なぜ発言が成立していないのか

を調べる。

何を答えればよいかわからないなら、問いを変える。

反対してよいかわからないなら、発言可能な範囲を明示する。

考える時間がないなら、事前に資料を渡す。

口頭での即答が制約なら、文章でも回答できるようにする。

言っても無駄だと思われているなら、発言と意思決定の関係を変える。

こうすれば、施策は「会議をよくするための工夫」ではなく、特定された制約に対する操作になる。

■元記事は「人」から「会議」まで進んだ。その先がある

元記事の価値は、会議での沈黙を、

「若手が受け身だから」
「主体性がないから」
「意見を持っていないから」

という個人の問題だけで説明しなかったことである。

これは重要な転換である。

しかし、

人を見る
↓
会議を見る

まで進んだところで議論が止まっている。

「会議」という単位でも、まだ粗い。

必要なのは、さらに分解することである。

人を責める
↓
会議を見る
↓
会議で成立させたい状態を定める
↓
必要な行動を特定する
↓
行動の成立条件を見る
↓
制約を特定する
↓
制約に対応した操作を行う

ここまで進めば、

「質問を具体的にしよう」
「資料を事前共有しよう」
「チャットでも意見を集めよう」

という個別テクニックを超えることができる。

なぜその方法が必要なのか。

どのような場合には有効なのか。

どのような場合には効かないのか。

それを説明できるようになるからである。

■沈黙そのものを問題にしてはいけない

会議室では黙っていた人が、会議室を出た瞬間、

「あの案は無理だと思う」

と言い始める。

この現象を見たとき、

「だったら会議で言ってほしい」

と思うのは自然である。

元記事は、そこで人を責めるのではなく、

「この場は、本当に話せるようにつくられているだろうか」

と考えるべきだと主張した。

その問いは重要である。

しかし、そこで止まらず、さらに問う必要がある。

なぜ、この場では発言という行動が成立しなかったのか。

何を言えばよいかわからなかったのか。

言ってよい範囲がわからなかったのか。

時間や情報が足りなかったのか。

言っても意味がないと思っていたのか。

同じ沈黙でも、原因となる制約は違う。

だから、同じ処方箋を使ってはいけない。

沈黙は、相手に問題があることを示すものではない。

しかし同時に、単純に「会議の設計に問題がある」と示すものでもない。

沈黙は、必要な行動の成立条件のどこかに制約が存在している可能性を示す観察結果なのである。

組織を設計するとは、人に望ましい行動を要求することではない。

かといって、漠然と「発言しやすい環境」をつくることでもない。

実現したい状態を定め、必要な行動を特定し、その行動を成立させていない制約を認識し、制約に対応した操作を行うことなのである。