毎週会議を開き、営業、現場、経理、情シス、開発会社が意見を出している。それでも入力項目、承認条件、例外処理が決まらず、次回までの持ち帰りが続くことがあります。
参加者を増やせば情報は集まりますが、意思決定が進むとは限りません。全員の意見を聞くことと、誰かが責任を持って選ぶことは別だからです。
一つの会議に4つの目的が混ざっている
- 現状や前提を共有する
- 問題と影響を確認する
- 選択肢について相談する
- 最終的に一つを決める
情報共有に時間を使い切ると、判断は次回へ送られます。相談会なのか決裁会なのかも曖昧になります。
人数が増えるほど責任者が見えにくくなる
LatanéとDarleyの研究は、緊急状況で他者がいることが介入行動へ影響する、いわゆる傍観者効果を示しました。Group Inhibition of Bystander Intervention in Emergencies
この実験を会議へそのまま当てはめることはできません。ただし、多人数で「みんなで決める」とすると、誰が最後に判断するのか見えにくくなる点には注意が必要です。
会議で必要なのは参加者を減らすことだけではなく、決定責任を個人または明確な役割へ置くことです。
仕様ではなく業務判断が未決になっている
「承認ボタンを付けるか」は画面仕様に見えますが、本当に決める内容は次です。
- いくら以上を誰が承認するか
- 承認前後で誰が修正できるか
- 承認者不在時にどうするか
- 締め後の修正を認めるか
- 誰が結果へ責任を持つか
業務上の判断を開発会社へ預けると、画面案は出ても決定はできません。
論点ごとに決定カードを作る
論点：締め後の金額修正を認めるか
決裁者：経理責任者
相談先：現場責任者、システム担当
判断基準：会計影響、顧客影響、修正頻度
選択肢：禁止／承認付きで許可／翌月調整
期限：9月15日
未決時：現行運用を期限付きで継続
決定理由：
議事録の長さより、未決論点が誰の判断待ちかを見えるようにします。
全員合意を求めない代わりに残すもの
決裁者が単独で決めればよいという話でもありません。次を残します。
- 影響を受ける人の意見
- 各選択肢の便益と負担
- 少数意見と懸念
- 決定理由
- 見直す条件と日付
- 問題時に戻せる範囲
納得できない人がいても、なぜその判断になったかをたどれるようにします。
会議を3種類に分ける
事実確認
現在の業務、件数、例外、問題を揃えます。ここでは解決案を急ぎません。
設計相談
選択肢と影響を比較します。参加者は意見を出しますが、全員一致を目的にしません。
決裁
決裁者が必要情報を確認し、選択、保留、追加調査を決めます。保留にも期限を付けます。
意思決定が進んだかを測る
- 未決論点の件数と滞留日数
- 決裁者不在で持ち帰った回数
- 一度決めた論点が再度開いた回数
- 決定理由が記録されている割合
- 決定から実装までの日数
- 見直し条件に基づいて変更した件数
会議時間を減らすことより、必要な判断が期限内に終わったかを確認します。
まとめ
会議を重ねても仕様が決まらないのは、意見が足りないからではありません。情報共有、相談、決定が混ざり、論点ごとの決裁者と判断基準がないことが原因です。
業務判断を画面仕様として開発側へ渡さず、決定カードで責任者、期限、選択肢、見直し条件を明確にします。
説明会で懸念が出ない問題はシステム導入の説明会では賛成されたのに使われない理由、DX担当者の権限はDX担当者が経営と現場の板挟みになる理由で解説しています。
