会議はコミュニケーションの場ではなく、判断を進める装置である - 構造で育てるプロダクト組織シリーズ付録3

会議が多いのに何も決まらない組織は、何を設計できていないのか

構造で育てるプロダクト組織シリーズでは、プロダクト組織を「人の集まり」ではなく、観測・判断・実行・振り返りが流れる構造として見てきました。

その中で何度も扱ってきたのは、組織の問題を「人が弱い」「コミュニケーションが足りない」で片付けない、ということでした。

経営と現場がズレるのは、翻訳層がないからかもしれない。
組織図を変えてもチームが機能しないのは、責任境界と判断レーンがないからかもしれない。
ロードマップがあるのに優先順位が揺れるのは、判断の記録が残っていないからかもしれない。
振り返りが感想戦で終わるのは、構造更新に接続していないからかもしれない。
採用しても組織が変わらないのは、何を構造として増やしたいのかが定義されていないからかもしれない。

今回は、その流れの中で、ほぼすべての組織に存在するものを扱います。

会議です。

会議はどの組織にもあります。

定例会、朝会、週次レビュー、ロードマップ会議、仕様検討、デザインレビュー、技術レビュー、1on1、振り返り、経営会議、横断連携会議。

そして、多くの組織がこう感じています。

• 会議が多い
• 会議に出ているのに何も決まらない
• 決まったはずなのに後から蒸し返される
• 何のための会議かわからない
• 関係者が多すぎる
• 議事録はあるが判断が残っていない
• AI議事録で要約はきれいになったが、結局何が決まったのか曖昧

このとき、よくある改善は「会議を減らそう」です。

もちろん、不要な会議は減らした方がよいです。

ただし、会議の問題は量だけではありません。

本当の問題は、その会議が、何を観測し、何を判断し、何を決め、何を記録し、次に何を動かす場なのかが曖昧なことです。

会議を「話し合う場」として見ると、ここがぼやけます。

会議は、本来、コミュニケーションの場というより、組織の判断を進める装置です。

今回は、その話を書きます。

---

会議の問題は「多いこと」だけではない

会議が多い組織は、たしかに疲れます。

一日中カレンダーが埋まっている。
集中時間がない。
会議から会議へ移動しているうちに一日が終わる。
Slackを見る時間すらない。

これは問題です。

ただし、会議が少なければよいかというと、そう単純でもありません。

会議を減らした結果、

• 必要な観測が共有されない
• 判断が個人に閉じる
• 横断依存が後から発覚する
• レビューが遅れる
• 責任境界がさらに曖昧になる

こともあります。

つまり、問題は「会議が多いか少ないか」だけではありません。

より重要なのは、その会議が何の判断機能を担っているかです。

会議が多くても、観測・判断・実行・振り返りがきれいに流れているなら、組織は動きます。

逆に、会議が少なくても、判断がどこにも残らないなら、組織は不安定になります。

だから、まず問うべきなのは、

この会議は、何のために存在しているのか。

です。

ただし、ここでいう「何のため」は、ふんわりした目的ではありません。

「情報共有のため」
「認識合わせのため」
「相談のため」
「進捗確認のため」

だけでは足りません。

もっと具体的に、

• 何を観測するのか
• 何を判断するのか
• 何を決めないのか
• 誰が決めるのか
• 何を記録するのか
• 次に何が動くのか

まで見ないと、会議は設計できません。

---

会議を全部「会議」と呼ぶから混ざる

会議設計で最初にやるべきことは、会議を分けることです。

多くの組織では、性質の違うものを全部「会議」と呼びます。

でも実際には、会議にはかなり種類があります。

たとえば、最低でも次のように分けられます。

• 観測会議
• 論点整理会議
• 意思決定会議
• 同期会議
• レビュー会議
• 振り返り会議

これらは、それぞれ目的が違います。

しかし、ここが混ざると、会議は一気に弱くなります。

何が起きているか観測する場なのに、その場で意思決定まで始めてしまう。
論点整理の場なのに、誰かが結論を求める。
意思決定の場なのに、必要な材料が揃っていない。
同期の場なのに、未決論点の議論が始まる。
振り返りの場なのに、個人の感想で終わる。
レビューの場なのに、何をレビューするかが決まっていない。

これでは、会議が多いわりに何も前に進みません。

会議を設計するとは、まずその会議がどの種類の会議なのかを明確にすることです。

---

観測会議 - 何が起きているかを見る場

観測会議の目的は、何かを決めることではありません。

まず、何が起きているかを見ることです。

たとえば、

• KPIの変化を見る
• 顧客の声を見る
• 障害や問い合わせの傾向を見る
• 開発の詰まりを見る
• 採用パイプラインの状態を見る
• AI利用で起きた問題を見る

このような会議です。

観測会議で重要なのは、結論を急がないことです。

ここで必要なのは、

• 何が変わったのか
• どこに異常があるのか
• 何がまだ見えていないのか
• 次に判断すべき論点は何か

を揃えることです。

観測会議が弱い組織では、何が起きているかが揃わないまま、すぐに対策の話になります。

「解約が増えています」
「ではオンボーディングを改善しよう」

「レビューが詰まっています」
「ではレビュー担当を増やそう」

「AI生成コードの品質が不安です」
「ではガイドラインを作ろう」

もちろん、すぐに対策が必要な場合もあります。

しかし、観測が粗いまま対策に進むと、原因ではなく見えやすい現象に反応するだけになります。

観測会議の出力は、決定事項ではなくてもよいです。

むしろ、

• 観測された変化
• 未確認の前提
• 次に整理すべき論点
• 判断会議へ渡す材料

が残れば十分です。

---

論点整理会議 - 何を判断すべきかを分ける場

論点整理会議の目的は、結論を出すことではありません。

何を判断すべきかを分けることです。

組織の議論が混線するとき、多くの場合、複数の論点が混ざっています。

たとえば、ある機能改善の議論で、

• 顧客価値の話
• 事業優先度の話
• 技術負債の話
• デザイン一貫性の話
• リリース時期の話
• 営業要望の話
• 運用コストの話

が同時に出てくる。

全員が正しいことを言っている。
でも、決まらない。

このとき必要なのは、すぐに多数決することではありません。

まず、

• どの論点は今決めるべきか
• どの論点は別会議に渡すべきか
• どの論点は材料不足か
• どの論点は誰が判断すべきか
• どの論点は今回は扱わないか

を分けることです。

論点整理会議が弱い組織では、毎回「全部大事」になります。

全部大事なので、全部話す。
全部話すので、何も決まらない。
何も決まらないので、次回また話す。

こうして、会議は当初の想定を超えて増えていきます。

論点整理会議の出力は、結論ではなく、判断可能な論点のリストです。

これがあるだけで、次の意思決定会議はかなり軽くなります。

---

意思決定会議 - 採用・棄却・保留を決める場

意思決定会議の目的は、文字通り、決めることです。

ただし、ここでいう「決める」は、単に「やる」と言うことではありません。

最低でも、次を決める必要があります。

• 採用する案
• 棄却する案
• 保留する案
• 判断理由
• 前提条件
• 次に見直す条件
• オーナー
• 期限

意思決定会議が弱い組織では、「なんとなく方向性は合意した」で終わります。

これは危険です。

なぜなら、方向性の合意は、実行可能な決定とは限らないからです。

「オンボーディング改善を進める」
「AI活用を強化する」
「レビュー体制を見直す」
「横断連携を改善する」

これらは方向性としてはよいです。

しかし、決定としてはまだ粗い。

本当に必要なのは、

• 何をやるのか
• 何をやらないのか
• 誰が持つのか
• どの範囲まで任せるのか
• 何をもって前進とみなすのか
• いつ見直すのか

です。

意思決定会議の出力は、議事録ではなく、判断記録であるべきです。

---

同期会議 - 決まったことを揃える場

同期会議の目的は、議論することではありません。

決まったことを、関係者が同じ状態で持てるようにすることです。

たとえば、

• 今週の重点
• 変更された優先順位
• リリース予定
• 依存関係
• 担当者
• リスク
• 次のレビュー日

を揃える。

同期会議が弱い組織では、同期の場で新しい議論が始まります。

もちろん、必要な議論が発生することはあります。

しかし、毎回同期会議で議論が始まるなら、それは同期会議の問題ではなく、前段の観測・論点整理・意思決定が弱い可能性があります。

同期会議は、判断の場ではなく、判断の結果を揃える場です。

ここを混ぜると、参加者はこう感じます。

「共有会のはずなのに、毎回何かが決まり始める」
「自分は聞くだけのつもりだったのに、急に判断を求められる」
「決まっていると思っていたことが、また揺れる」

これはかなり消耗します。

同期会議の出力は、関係者の状態が揃うことです。

新しい判断が必要になったなら、それは別の判断レーンに送る方がよいです。

---

レビュー会議 - 前提と判断を見直す場

レビュー会議の目的は、進捗確認だけではありません。

本来は、前提と判断を見直す場です。

たとえば、

• このテーマを今やる理由はまだ生きているか
• 進め方は妥当か
• リスクは増えていないか
• 判断レーンを変える必要はあるか
• AI利用のレビュー強度は足りているか
• 期待していた成果に近づいているか

を見る。

レビュー会議が弱い組織では、進捗報告だけになります。

「何％進んでいます」
「少し遅れています」
「次週までに対応します」

もちろん、進捗も必要です。

しかし、進捗だけを見ると、そもそも進めているものが正しいかを見失います。

レビュー会議で見るべきなのは、進み具合だけではありません。

進め続けてよいのかです。

第5回でロードマップを判断記録として扱ったように、レビュー会議でも、前提が変わったなら判断を更新する必要があります。

レビュー会議の出力は、

• 継続
• 修正
• 保留
• 中止
• 上位レーンへエスカレーション

のいずれかです。

ただ「進んでいます」で終わるレビュー会議は、判断装置としては弱いです。

---

振り返り会議 - 次に違う結果を出すために構造を更新する場

振り返り会議の目的は、感想を言うことではありません。

もちろん、感情や違和感を出すことには意味があります。

しかし、そこで終わると、次に違う結果は出ません。

振り返り会議の目的は、次に同じ条件が来たときに、少しでも違う結果を出せるように、構造を更新することです。

見るべきなのは、

• 何が起きたか
• 想定と何が違ったか
• どの判断が効いたか
• どの責任境界が曖昧だったか
• どの観測が足りなかったか
• 次に何を変えるか

です。

振り返り会議が弱い組織では、結論がだいたいこうなります。

• もっと早く相談しよう
• 認識合わせを増やそう
• コミュニケーションを改善しよう
• 次は気をつけよう

これらは悪くありません。

しかし、構造更新にはなっていません。

本当に必要なのは、

• 共通基盤に触れる変更は設計前に横断レビューへ出す
• AI生成コードは本人の説明コメントを必須にする
• 仕様決定時に「やらないこと」を必ず残す
• 次回からレビュー会議で見直し条件を確認する
• 採用面接で「何を構造として残したか」を聞く

のように、運用が変わることです。

振り返り会議の出力は、気づきではありません。

次の構造変更です。

---

会議が「関与の証拠」になってしまう問題

ここで少し嫌な話をします。

会議は、組織の判断を進める装置である一方で、関与の証拠にもなりやすいです。

重要な会議に出ている。
横断会議に参加している。
複数部署を巻き込んでいる。
経営会議に接続している。
会議体を立ち上げた。
関係者を集めた。

これは、外から見ると成果っぽく見えます。

もちろん、必要な会議を設計することには価値があります。

しかし、その会議によって何の判断が進んだのかが残っていなければ、それは成果ではなく活動です。

付録1・付録2で書いたように、役割期待や成果責任が曖昧な組織では、「担当した」「巻き込んだ」「組織を動かした」が成果として扱われやすくなります。

会議は、その温床になりやすい。

なぜなら、会議は目に見えるからです。

カレンダーに残る。
参加者がいる。
議事録がある。
資料がある。
会議体の名前がある。

つまり、「動いている感」を作りやすい。

しかし、組織が本当に見るべきなのは、

• その会議で何が決まったのか
• 何が保留されたのか
• 何をやらないと決めたのか
• 誰が何を持つことになったのか
• どの判断理由が残ったのか
• 次に再利用できる構造が増えたのか

です。

会議を増やすことは、組織を動かすことではありません。

会議によって判断が進み、記録が残り、次の行動に接続して初めて、組織は動いたと言えます。

---

AI議事録で「決まった気」になる問題

AI議事録やAI要約は便利です。

会議の内容を整理してくれる。
長い議論を圧縮してくれる。
発言者ごとの要点をまとめてくれる。
アクションアイテムらしきものも出してくれる。

これは、会議運用にとってかなり有効です。

ただし、危険もあります。

要約がきれいになると、会議そのものも良くなったように見えるからです。

しかし、AI要約がきれいでも、

• 何が決まったのか
• 何が決まっていないのか
• なぜそう判断したのか
• 何を棄却したのか
• 誰が責任を持つのか
• いつ見直すのか

が曖昧なら、会議は強くなっていません。

第10回・第11回で書いたように、AIは提案や圧縮には強いです。

しかし、AIは会議の判断責任を引き受けてはくれません。

AI議事録は、観測と記録の補助にはなります。

しかし、会議を判断装置にするのは組織の仕事です。

だから、AI議事録を使うなら、要約だけでなく、最低限次を分けた方がよいです。

• 決定事項
• 未決論点
• 棄却した案
• 判断理由
• 次のアクション
• オーナー
• 見直し条件

ここまで残って初めて、会議記録は判断記録に近づきます。

きれいな議事録は、良い会議の証拠ではありません。

良い会議の証拠は、次の判断や実行に使える記録が残っていることです。

---

会議設計の最小セット

では、会議をどう設計すればよいのでしょうか。

最初から重い会議運用ルールは要りません。

まずは、各会議について次の項目だけでも定義するとかなり変わります。

会議設計シート

• 会議名
• 会議の種類
• 目的
• 入力
• 判断対象
• 決定者
• 出力
• 記録場所
• 次回見直し条件

これだけです。

会議名

名前は意外と重要です。

「定例」や「共有会」だけでは弱いです。

たとえば、

• 週次ユニット観測会
• 横断論点整理会
• 仕様意思決定会
• AI利用レビュー会
• ロードマップ前提レビュー会

のように、何をする会議かが名前で分かる方がよいです。

会議の種類

観測なのか。
論点整理なのか。
意思決定なのか。
同期なのか。
レビューなのか。
振り返りなのか。

ここを最初に決めるべきです。

目的

「情報共有」ではなく、もう少し具体にします。

たとえば、

• 今週の異常を観測する
• 次に判断すべき論点を整理する
• 仕様A/B/Cの採否を決める
• 決定事項を関係者に同期する
• 前提が崩れていないか確認する
• 次回から変える運用を決める

のように書きます。

入力

会議に入る前に必要な材料です。

• KPI
• 顧客の声
• 仕様案
• 技術調査
• 依存関係
• 前回の判断記録
• AI要約
• レビュー観点

など。

入力がない意思決定会議は、かなり危険です。

判断対象

その会議で何を判断するのかです。

ここがないと、話し合いは広がります。

逆に、判断対象が明確なら、会議は短くなります。

決定者

誰が決めるのか。

全員で話すことと、全員で決めることは違います。

意見は多職能で出してよい。
しかし、最終判断を誰が持つのかは明確にした方がよいです。

出力

会議後に何が残るのかです。

• 観測結果
• 論点リスト
• 決定事項
• 棄却案
• 判断理由
• アクション
• オーナー
• 構造更新項目

など。

出力が曖昧な会議は、再利用できません。

記録場所

会議で決まったことがどこに残るのかです。

議事録があっても、誰も見ない場所にあるなら弱いです。

判断記録は、次に使う場所に残す必要があります。

次回見直し条件

いつ、何を見たら判断を見直すのかです。

これは特にレビュー会議や意思決定会議で重要です。

決めたことは固定ではありません。

前提が変われば、判断も更新する必要があります。

---

具体例 - 週次プロダクト会議を設計し直す

たとえば、よくある「週次プロダクト会議」を考えます。

悪い例では、こんな状態になります。

• 各自が進捗を話す
• 気になったことを相談する
• その場で優先順位の話になる
• 議論が広がる
• 決まったような気がする
• でも翌週また同じ話をする

これはよくあります。

ここで、会議を設計し直すなら、まず種類を分けます。

週次プロダクト会議を、全部盛りにしない。

たとえば、こう分けます。

週次ユニット観測会

目的は、今週の変化を見ること。

• 入力
  KPI、顧客の声、進捗、問い合わせ、障害、リスク

• 判断対象
  まだ判断しない。異常と論点を出す。

• 出力
  観測結果、次に整理すべき論点

隔週論点整理会

目的は、判断対象を分けること。

• 入力
  観測会で出た論点、依存関係、制約

• 判断対象
  どの論点をどの会議で扱うか

• 出力
  意思決定に渡す論点、保留論点、追加調査

仕様意思決定会

目的は、採用・棄却・保留を決めること。

• 入力
  仕様案、制約、トレードオフ、レビュー結果

• 判断対象
  仕様案A/B/Cの採否

• 出力
  決定事項、棄却理由、オーナー、見直し条件

このように分けるだけで、会議の混線はかなり減ります。

全部を一つの会議でやろうとするから、会議が重くなります。

会議を減らす前に、まず会議の役割を分ける方が効くことがあります。

---

良い会議とは、発言が多い会議ではない

良い会議というと、参加者が活発に発言している状態を思い浮かべるかもしれません。

もちろん、発言があることは大事です。

しかし、発言が多いだけでは良い会議とは限りません。

みんなが話した。
いろいろな観点が出た。
議論は盛り上がった。
心理的安全性もありそうだった。

それでも、何も決まっていなければ、意思決定会議としては弱いです。

逆に、発言が少なくても、

• 必要な観測が揃った
• 論点が分かれた
• 判断が決まった
• 判断理由が残った
• 次の行動が明確になった

なら、その会議は機能しています。

良い会議とは、気持ちよく話せた会議ではありません。

次の判断や実行が進む会議です。

---

この記事から持ち帰れること

もし、自分の組織で「会議が多いのに、何も決まらない」と感じるなら、まず次の問いを見てみてください。

• その会議は、観測・論点整理・意思決定・同期・レビュー・振り返りのどれか
• その会議に必要な入力は何か
• その会議で判断する対象は何か
• 誰が決めるのか
• 会議後に何が残るのか
• その記録は次に使える場所に残っているか
• AI議事録は、要約だけでなく判断記録になっているか

これらが曖昧なら、問題は会議の数だけではありません。

会議が、組織の判断装置として設計されていない可能性があります。

会議を減らすことは大事です。

しかし、会議を減らす前に、まずその会議が何のための装置なのかを見る必要があります。

---

まとめ

会議は、単なるコミュニケーションの場ではありません。

本来は、組織の判断を進める装置です。

しかし、会議の種類が混ざると、

• 観測の場で意思決定が始まる
• 論点整理の場で結論を求める
• 意思決定の場に材料がない
• 同期の場で議論が再燃する
• レビューが進捗報告だけになる
• 振り返りが感想戦で終わる

ということが起きます。

その結果、会議は多いのに、判断が進まない組織になります。

さらに、会議は「関与の証拠」にもなりやすいです。

重要な会議に出ている。
横断会議に参加している。
会議体を立ち上げた。
多くの人を巻き込んだ。

これらは活動としては価値があります。

しかし、本当に見るべきなのは、その会議によって何の判断が進み、何が記録され、次に何が動いたかです。

AI議事録やAI要約も同じです。

要約がきれいでも、判断が残っていなければ、会議は強くなりません。

会議を設計するとは、

• 会議の種類を分ける
• 入力を揃える
• 判断対象を決める
• 決定者を明確にする
• 出力を残す
• 次に使える場所に記録する

ことです。

会議の価値は、話した量ではありません。

判断が進み、組織が次に動ける状態になったかです。

会議が多いのに組織が進まないとき、必要なのは、会議を根性で減らすことだけではありません。

その会議が、観測・判断・実行・振り返りのどこを担う装置なのかを設計し直すことです。