問題点はたくさん挙がるのに、どれから扱うか決まらない。解決策の議論が広がり、結局は『引き続き検討する』で終わる。改善会議でこうした状況が続いていないでしょうか。自由討議は柔軟な一方、発言量や役職の影響を受けやすく、時間内に行動へ進めないことがあります。
ライトニング・デシジョン・ジャム（Lightning Decision Jam、LDJ）は、問題の記入、投票、問いへの変換、解決案、優先付け、実行決定を短い時間枠で進めるワークショップです。多くの工程を個人で静かに行い、長い討議を避ける点に特徴があります。
45分という短さは魅力ですが、複雑な原因を調査せず決めてよい手法ではありません。扱う範囲を一つへ絞り、投票を事実認定と混同せず、最後に担当と確認日まで決めておく必要があります。この記事では、準備、8つの進行、向く課題、オンライン実施まで解説します。
この記事を読むと次のことがわかります
LDJは議論より個人作業と投票を先に置く
LDJでは、全員が同じ問いへ一人で書き、付箋を共有し、投票で扱う対象を絞ります。最初から意見交換をしないため、早い発言へほかの人が引っ張られるのを抑えます。
投票は正解を証明するものではなく、限られた時間で次に扱う候補を選ぶ仕組みです。選ばれなかった課題も記録し、別の機会に扱います。
良い点を共有するときは、称賛だけで終えず、今回の改善で維持すべき条件を一つ選びます。たとえば会議時間を短縮しても、顧客の未解決事項を確認する時間は残す、と解決案の評価基準へ使います。
How Might Weは日本語では『どうすれば私たちは～できるだろうか』と表現できます。主語の『私たち』を入れると、自分たちが動かせる範囲へ焦点を戻しやすくなります。外部要因だけを変える問いにしません。
参加者が十人を超える場合は、同じ対象について4～8人のグループへ分け、各グループで一つの行動を作ります。最後に全案を再投票すると時間が伸びるため、決定者が統合する規則を先に決めます。
LDJの冒頭で、今日は合意形成ではなく一つの試行を決める場だと伝えます。全員が案へ完全に賛成することを求めると、短い投票の後に長い説得が始まります。安全に試せる範囲なら、検証で判断を更新します。
効果の見積もりは、誰にとっての効果かを明示します。顧客の待ち時間、担当者の作業時間、ミス率など、問題文と対応する指標を使います。複数の利害があるなら副作用も欄へ書きます。
実行前に止める条件も決めます。顧客影響が一定値を超える、セキュリティ上の懸念が見つかる、必要な承認が得られない場合などです。小さな実験でも無条件に続けない仕組みを置きます。
短い時間枠が各工程の目的を明確にする
問題出し、選択、解決案、優先付けを数分ずつ区切ります。一つの付箋の言葉選びで長く止まらず、必要な工程を最後まで通します。
時間厳守は参加者を急かすためではありません。完璧な分析より、小さな行動を決めて検証する課題に使うという前提を守る役割があります。
サイレント記入で発言順の影響を減らす
最初に上司や専門家が話すと、その枠組みが全員の案へ影響します。個人で同時に書けば、発言が得意でない人の観察も同じ形式でボードへ出せます。
沈黙だけで権力差が消えるわけではありません。付箋へ名前を書かない、投票を匿名にするなど、テーマと関係性に応じた補助が必要です。
一度に扱う問題を一つへ絞る
似た問題を全部まとめると、How Might Weの問いが広がり、解決案も抽象的になります。投票上位から一つを選び、残りは保留欄へ移します。
上位問題が大きすぎる場合は、誰が、どの場面で、何に困るかを絞ります。『コミュニケーションが悪い』のまま進めず、観察できる状況へ変えます。
決定後の実験を重視する
LDJで選ぶのは、永続的な制度変更より次に試せる行動です。実行して結果を見れば、短時間で置いた仮説を修正できます。
法務、安全、重大障害など、事前調査や正式承認が必要な事項は、LDJだけで結論を出しません。調査項目や次の正式手続きまでを決めます。
開始前に範囲・決定権・ボードを準備する
参加者は4～8人程度が進めやすく、課題に異なる視点を持つ人を集めます。会議の対象、最終決定者、45分で決められる範囲を招集時に示します。
ボードには、うまくいっていること、問題、投票結果、How Might We、解決案、効果と工数、行動の欄をあらかじめ用意します。
問題付箋には、観察と解釈を分けます。『責任感がない』ではなく『期限を過ぎたタスクが三件あり、担当表示が空欄だった』と書けば、個人攻撃を避けながら仕組みを考えられます。
解決案では、既存手順をやめる案も認めます。新しいツールや会議を追加する案だけでは、仕事量が積み上がります。やめる、減らす、自動化する、順番を変えるという方向からも書きます。
次回確認では、行動を実施したかだけでなく、問題の観察値がどう変わったかを見ます。変化がなければ担当者の努力不足と決めつけず、仮説、実行条件、測定方法のどこを見直すかを選びます。
投票には専門知識の差が反映されないことがあります。高度な技術リスクを人気投票で決めず、専門家が満たすべき制約を事前に提示します。その制約内で候補を選ぶ形にします。
工数には実装時間だけでなく、承認、教育、移行、保守も含めます。小さく見えるツール導入が運用負担を増やすことがあります。不明なら『要調査』として、調査期限を行動にします。
同じチームで繰り返す場合は、毎回同じ人の付箋が選ばれていないかを見ます。匿名投票でも、テーマ設定や専門情報の差が偏りを生みます。参加者構成や事前情報を調整します。
対象を一文で具体的に定める
『会社の働き方』では広すぎます。『毎週の顧客レビュー会を45分以内に終え、決定事項を当日共有するには』など、活動、対象者、望む状態を入れます。
問題の原因が未確認なら断定しません。今回は観察された困りごとから試行案を作る場だと説明します。
誰が何を決められるか確認する
参加者だけで変更できる運用か、予算や承認が必要かを先に確認します。実行権限がない場合は、提案書の作成や検証データ収集を成果にします。
決定者が参加しないなら、結果をいつ誰が渡し、いつ回答を得るかまで予定へ入れます。決められない会議を短くしただけにしないためです。
付箋は一枚一内容で短く書く
問題と原因と解決策を一枚へ書くと、投票後に何を選んだか分かりません。『議事録が翌日になる』のように、観察できる一内容へ絞ります。
抽象語が出た場合は、記入時間後に短く具体化します。説明討議を始めず、本人が一文を補う程度にします。
投票数と同票時の扱いを決める
一人三票、同じ付箋へ複数票を置けるかなどを統一します。同票なら決定者が選ぶ、より狭い問題を選ぶ、短い追加投票を行うという規則を先に決めます。
投票結果を多数派の真実として扱わず、今回の時間を配分する基準だと共有します。少数票でも重大なリスクは別経路で扱います。
45分を8ステップに分けて問題から解決案へ進む
進行例は、良い点4分、問題7分、問題投票2分、問いへの変換3分、解決案7分、解決案投票2分、効果と工数10分、行動決定10分です。参加人数に応じて微調整します。
ファシリテーターはタイマーと工程を守り、内容の正解を決めません。議論が始まったら、今の工程で必要な情報かを確認します。
重複付箋をまとめる場合は、似ているように見えて対象者や場面が違わないか確認します。安易に束ねると少数の重要な問題が多数派の一般論へ埋もれます。本人へ一言確認し、違いを残します。
効果と工数の配置では、発言者が自分の案を守る討論にしません。まず各自が無言で仮置きし、意見が大きく分かれる案だけ必要な前提を確認します。正確な見積もりが必要なら別タスクへ分けます。
問題が人の態度として書かれたら、行動と環境へ戻します。『協力的でない』ではなく、依頼への回答時間、必要情報、権限、優先順位の衝突を確認します。人格を解決対象にしません。
高効果・低工数に見える案が複数あっても、一度に全部始めません。結果の原因を分けられるよう一つか二つへ絞ります。残りは次回候補として、採用しなかった理由とともに残します。
45分で終わらなかった場合は、参加者の集中力だけを原因にしません。対象が広い、付箋が抽象的、決定権が不明、解決案の評価基準がないなど、どの工程で時間を使ったかを記録します。
ボードには得票数だけでなく、選択した問題文とHow Might Weの対応を残します。問いを書き換える途中で問題の対象が変わると、投票で選ばれた困りごととは別の解決案を考えてしまいます。主語、場面、望む状態を照合します。
最初にうまくいっている点を書き出す
問題だけから始めると、残すべき強みを壊す解決案が出ることがあります。現状で機能していることを各自で書き、短く共有します。
成功要因を長く分析せず、解決案を評価するときの制約として残します。たとえば『顧客から率直な意見が出る』は、会議短縮でも守りたい条件です。
問題を書いて投票し一つを選ぶ
困っている事実を一枚ずつ書き、全員分をボードへ置きます。必要なら重複を本人確認のうえ重ねますが、分類作業へ時間を使いすぎません。
投票後は上位の一問題を選びます。重大度、頻度、今回動かせる範囲が明らかに違う場合は、決定者が短く判断理由を示します。
問題をHow Might Weの問いへ変える
『資料共有が遅い』を『どうすれば必要な確認を保ちながら、会議前日までに資料を共有できるだろうか』へ変えます。望む状態と守る条件を含めます。
答えを埋め込んだ問いにしません。『新しいツールを導入して解決するには』では解決策が限定されます。複数案が出る余地を残します。
解決案を出し、効果と工数で絞る
各自が静かに解決案を書き、再び投票します。上位案を効果と工数の二軸へ置き、高い効果を見込め、比較的小さく試せる案を候補にします。
軸の位置を精密に議論しません。不確実な案は仮の位置へ置き、検証に必要な情報を行動へ含めます。
担当・期限・確認指標まで決めて会議を閉じる
最後の10分は削らないようにします。案を選んでも、担当、期限、最初の一歩、確認方法がなければ実行されません。
LDJは速く決める手法ですが、実施後の振り返りまで含めて一つの循環です。結果が想定と違えば、次の問題情報として使います。
投票前に長い説明を許すと、話し上手な人の付箋が有利になります。分からない表現だけ本人に短く具体化してもらい、説得や反論は投票後にも行いません。情報が不足するなら調査課題として扱います。
オンラインでは付箋を同時編集できるボードを用意し、投票機能を事前に試します。接続トラブル用にチャットで回答できる代替手段と、タイマーを全員が見られる画面を準備します。
解決案の投票では、書いた本人が説明しなくても理解できる一文にします。内容が曖昧なら一文だけ補足し、魅力的なプレゼンテーションで票を集める時間にはしません。
決定事項は会議終了直後に普段のタスク管理へ移します。ワークショップのボードだけに残すと、日常業務から切り離されます。担当者自身が期限と内容を読み上げ、認識を確認します。
LDJの成果は付箋数や時間どおりの終了だけでは測れません。決めた行動の実施率と、対象問題の変化を確認します。行動が実施されないなら、会議形式より仕事の優先順位や権限に原因がある可能性があります。
終了時には、選ばれなかった問題と解決案も保留欄へ移します。ただし次回に自動で採用せず、状況が変わっていないか再確認します。履歴を残すことで、同じ課題を毎回ゼロから出し直す時間を減らせます。
行動を一週間以内の大きさへする
『情報共有を改善する』ではなく、『次回会議の資料テンプレートを金曜までに一度試す』とします。短期間で実行と確認ができる粒度を選びます。
大きな案は最小の検証へ分けます。全社導入ではなく一チーム、一か月契約ではなく試用環境など、戻せる範囲から始めます。
担当者と必要な支援を明記する
担当を部署名だけにせず、進行責任を持つ一人を決めます。作業を一人で抱える意味ではなく、関係者へ依頼し進捗を確認する窓口です。
権限、予算、データ、他部署の協力が必要なら、その確保も別の行動にします。期限だけを置いて実行条件を忘れないようにします。
成功を判断する観察項目を決める
会議時間、資料共有時刻、差し戻し件数、参加者の理解など、変化を確認する項目を一つか二つ選びます。測定自体が重くならないものを使います。
数値だけで判断できない場合は、利用者の短いコメントも残します。望ましくない副作用が出ていないかも確認します。
向かない課題は調査や正式会議へ渡す
原因が分からず影響が大きい問題、倫理や安全に関わる問題、不可逆な投資は、45分の投票だけで決めません。事実確認、専門レビュー、意思決定会議へつなぎます。
LDJで決められるのは、次に誰が何を調べ、いつ報告するかです。速さを保ちつつ、必要な慎重さを省かない境界を明確にします。
一つの問題を選び、小さな実行と確認日まで45分でつなげよう
ライトニング・デシジョン・ジャムは、個人記入と投票を使い、問題、解決案、行動を短時間で絞る会議手法です。発言順の影響を抑え、一つの課題を最後まで扱う点に特徴があります。
準備では範囲、決定権、投票規則を確認します。進行では良い点と問題を出し、問題をHow Might Weへ変え、解決案を効果と工数で整理します。
最後に担当、期限、必要な支援、確認項目を決めます。重大で複雑な課題は無理に解決せず、調査や正式手続きへの次の行動を決めましょう。
今回のポイント
