伝統的な問題解決
- 問題点を挙げる
- 原因について議論する
- 原因を取り除く対策を議論する
- 対策を実施する
伝統的な問題解決の欠点: 原因を特定しようとする
- 因果関係の証明には時間と労力がかかる: 現実世界は因子(パラメータ)が多すぎる → 非現実的
- 間違った原因に対策を講じてしまう危険性がある → 努力が無駄になる
- 原因を特定できてもコントロールできるとは限らない
すごい会議
特徴
- すべて紙に書いて表現する
- 全員でひとつの方向性を共有する
- 「ひどい事実」「言えない事実」と正面から向き合う
- 会議終了後に全員が自信を持って退出できる
- チームのコミュニケーションツールになる
- 冷静・提案ベース・システマティックな会議！
- 最短ステップで必ず解決策にたどり着く！！
進め方 (所要時間:15~25分程度)
- 問題を挙げる (1分程度)
- 理想に言い換える (1分程度)
- 事実を集める (5~10分程度)
- 解決アイディアをブレスト (5~10分程度)
- 解決策を選定 (5分程度)
- 解決策の実施
1.問題を挙げる
- 手元のポストイットに各自書き出す。1問題ごとに1枚。
- 全員が見えるように張り出して発表する。
- この会議で解決する問題を選ぶ。選び方: 優先度をつける。
2.理想に言い換える
- 問題を「どのようにすれば_____になるか？」に言い換える。イーゼルパッドの一番上に書く。
問題=理想-現実。
人によって理想が異なる。課題を理想に言い換えることで、会議の方向性を合わせる。
例:
「SaaSの利益が少ない」→「どのようにすればSaaSの収益が増えるか?」
「SaaSが利益が少ない」→「どのようにすればSaaS開発のムダを削減できるか?」
「SaaSが利益が少ない」→「どのようにすれば新規ユーザにリーチできるか?」
- さらに「〜なくてもいいようになるか」など否定系は肯定系に言い換える。
- さらに、誇りに訴えかけるようなよりパワフルな表現に言い換える。
まるまる言い換えたり「世界一」「すごい」「驚くほど」などの副詞を使う。
例: 「どのようにすればのユーザが喜びにあふれ、SaaSの収益が増えるか?」
3.事実を集める
- みんなで手元のポストイットに事実を書き出す。1事実ごとに1枚。
- イーゼルパッド上半分に張り出して発表する。
多い程よい
普段は言えない事実・ひどい事実 = 価値が高い
事実=客観的なこと、定量的なこと
例:「未着手が半分しかない」→「未着手が半分ある」
例:「残業が多い」→「先月と比べて残業が多い」
自分が感じていることも事実のひとつ: 「〜と感じている」をつける
例:「ガラケーのほうが使いやすい」→「ガラケーのほうが使いやすいと感じている」
感じていることは具体的な体験に言い換えると表現しやすい
例:「ガラケーのほうが使いやすい」→「スマホの画面を間違ってタッチして大事なデータを消してしまった」
主張は客観化する: 「私が言うには〜」をつける: ニュアンスが変わり反発が起きにくくなる
例:「○○さんのコードがキレイ」→「私が言うには、○○さんのコードがキレイ」
「〜ので」「〜から」「〜せいで」「〜のに」のような接続詞は不可: 2つの事実に分ける
例:「開発期間が1ヶ月だったので納期に遅れた」→「開発期間が1ヶ月だった」「納期に遅れた」
4.解決アイディアをブレスト
- みんなで手元のポストイットに解決アイディアを書き出す。1アイディアごとに1枚。
- イーゼルパッド下半分に張り出して発表する。
- 多い場合はカテゴリ分けする。
事実を参考にして良い。
馬鹿げたアイディア、遊びのあるアイディア、くだらないアイディア、できそうもないアイディアも考えてみる → 思考の枠が広がる。
例: ラリー・ペイジにレビューしてもらう
注意: この段階ではアイディアへの評価はしない。
5.解決策を選定
- 解決アイディアの中から、実施するものを選定する。
ヒント: 「今直ぐできるか」よりも「最も効果的か」で選ぶと良い
6.解決策の実施
- だれが、いつまでに、なにをやるかを決める
ルール
発言してもいいのは2種類
- 建設的な提案: 「提案ですが、〜しませんか?」
- 明確化のための質問: 「明確化のための質問ですが、〜ですか?」
この場で発言してはいけないコト
演説、コメント、ダメだし、脱線 → 提案として発言する
「無理」→「難しい」
必要なもの
| 強粘着ポストイット 人数*冊 |  |
|---|---|
| プロッキー 黒 人数分 |  |
| イーゼルパッド 1冊 |  |