Enhance organizer documentation with failure patterns and facilitation guidance

docs/organizer/day0.md

@@ -187,6 +187,33 @@ Listen から Test/Iterate まで終わった後、次回改善編の説明を
 
 ワークショップ前の準備の開始をお願いします。
 
+## Follow up 
+
+ML Enablement Workshop がうまくいかないケースにはいくつかのパターンがあります。Day0 を通じリスクを感じた場合、対策を検討してください。
+
+1. 行き先不明パターン
+   * 開発計画全体の中で MLEW がどのような役割を果たすのか明確でなく、単にチーム研修/アイデアソンの場になる
+   * 処方箋 : Day0 の段階で実施意義と現状の開発ロードマップ上どのような役割を果たすか明確にする
+2. 顧客の不在パターン
+   * ターゲットにした顧客の実在性が疑わしい、あるいは規模が非常に限られた顧客を対象にしている
+   * 処方箋 : Day0 時点で検知し、「この像に従う具体的な顧客を上げられるか」「どれぐらいの市場を狙うのか」といった質問でターゲットの検討を深めて頂く
+3. 影の支配者パターン
+   * プロダクトマネージャーが未経験者でビジネス上の有効な意思決定ができない。背後に「真の意思決定者」が控えていて暗に陽に挙動を操っている
+   * 処方箋 : 「真の意思決定者」をワークに参加させ明示的に PdM 役に任命する。もしくは、PdM 役判断の受容を約束いただく
+4. 反逆者パターン
+   * 自分たちの開発手法にこだわりがあり、Working Backwards / MLEW の進行方法に明示的な抵抗を示すか「これはあくまで研修」と線を引く行動をとる
+   * 処方箋 : Day0 段階で検知し、スポンサー/上長から意図を伝え説得頂くかやむをえない場合チームメンバーから外して頂くよう要請する
+5. 優等生パターン
+   * ワークショップの手順や時間内の進行にこだわり、課題や発明の質にこだわりがない
+   * 処方箋 : 営業や部長クラスなど、数字(結果)にコミットメントを持つロールに MLEW の貢献を説明したうえで参加いただく
+6. 誇大妄想パターン
+   * 自分達では到底開発しきれない規模の発明を採用してしまう
+   * 処方箋 : 事例の規模や粒度を開発可能なサイズに押さえておく (進行上、発明に使う事例の粒度が非常に重要になる)
+7. 失踪パターン
+   * MLEW 実施後に、主に業務都合や忙しさを理由に責任者や開発計画が失踪するパターン
+   * 処方箋 : Day0 で、スポンサーの意思と現場の PdM の意思が一致しているか事前に確認し、終了後の開発計画への決裁・予算承認等が下りているか確認する
+
+
 ## 参考書籍
 
 ワークショップを推進するにあたり、必要な事前インプットがないか確認します。インプットに有用な書籍やリソースを紹介します。

docs/organizer/day1.md

@@ -20,6 +20,48 @@
 
 生成 AI を使いワーク、またモック作成を進行します。**ツールの設定等でつまずくとワークショップの進行に致命的な影響を与えるため、全参加者が事前準備を完了しているかの事前確認、ワークショップ冒頭での改めての確認は入念にしてください**。
 
+## 実践編のファシリテーションのポイント
+
+**Listen**
+* よくある課題
+   * 顧客のイメージ (customer.png) が曖昧であるため、顧客の行動がすごいアバウト
+   * 時系列に出てこない
+   * サマリされていて行動の粒度が荒い
+* 対応
+   * `customer.png` を見て情報が薄いようであれば再作成するよう検討を促す。"顧客の不在パターン" をここでケアできると Good
+   * プロンプトの語尾に「必ず時系列に沿い記載してください」を追記など
+   * プロンプトの語尾に「一次情報を記録するため要約を避けてください」を追記など
+
+**Define**
+* よくある課題
+   * 質問の内容がよくわからない、イマイチ
+* 対応
+   * 率直に生成 AI に立て直しをさせる
+   * 数を出して選ぶ方がうまくいく
+   * プロンプトの語尾に「各問いが日本語、状況として素直に理解できるか診断し必要があれば修正してください」など
+
+**Invent**
+* よくある課題
+   * ペアの別れ方がわからない
+   * どれも同じ感じの発明になる
+* 対応
+   * ガイドがあるが、工程で分けるとかぶりにくい。もしくは、顧客を細分化するなど(Free顧客と課金顧客など)
+   * `solutions.md` の粒度を見直す : 1 課題を 1 ソリューションで解決するような事例を並べるとベスト。「AI で全部解決できる」みたいな包括的ソリューションがあるとかなりそれに引っ張られます。
+   * ジェフ・ベゾスとして～など、考える人を変えるワークを集中的に行う
+
+**Refine**
+* よくある課題
+   * テンプレートの内容を削ってしまう、答えない
+* 対応
+   * テンプレートにはクリティカルなものを書いているので、回答拒否している場合は答えてもらう (時期、価格プランなど)
+
+**Test/Iterate**
+* よくある課題
+   * Who/What/How の違いが判らず混乱する
+* 対応
+   * Who は社内の人、What は計測方法、How は Go/No Go を決める具体的なメトリクス
+   * 実践編で立てるのは「社外に出すまで」の価値検証で、実ユーザーに触ってもらって計測する指標は改善編以降でたてる
+
 ## 実践編の進行
 
 下記が全体のタイムテーブルです。進行する際の参考にしてください