# ML Enablement Workshop 進め方ガイド

本文書は、ML Enablement Workshopの開催者に向けて、資料/ハンズオン解説のポイントを伝えるためのガイドです。

## Day1: 機械学習インプット

座学が中心となるので、飽きないようスライド中のクイズを活用する、説明の合間に質問に回答するなどして双方向性を持たせると良いです。Day3に向けての準備の量はワークショップの成功を大きく左右するため、個社ワークになるべく時間を割り当てられるよう調整してください。

1. MLの入門
   * 簡易な統計によると[97%のプロダクトマネージャーは機械学習に興味を持っていないので](https://speakerdeck.com/icoxfog417/yan-jiu-topurodakutokai-fa-nojing-jie-woyue-etatimingudeyuzanijia-zhi-wojie-keru?slide=6)、 **なぜ時間をかけて機械学習を学ぶ必要があるのか** を厚めに解説するとよいです。「MLの可能性」の部分です。
   * 「MLの活用例」は、お客様のプロダクトに関係がありそうな事例を厚めに解説すると良いです。競合企業が先行している事例をさせるとモチベーションも高まると思います。
2. MLプロジェクトの計画
   * 「ユースケースの特定」で、機械学習活用プロジェクトの80%は失敗するといわれている、その理由が技術面でなくビジネス面にある点は強調しておくと良いと思います(プロダクトマネージャーがしっかりしないと80%失敗するということです)。
   * 「ML拡大の要件」はMLを競争優位につなげるためには特に重要なポイントです。
3. ML活用組織へのシフト
   * 「データ戦略」で、データが自動で蓄積する仕組みを作っておくことは特に重要です。
4. アイデアソン解説(Day1用)
   * 「Event Storming解説」は、Event Stormingを一度自分で試しておかないとなかなか腹落ちして話すことができないので試してみることをお勧めします。
5. Event Storming演習
   * プロダクトマネージャーがEvent Stormingのキーマンになるため、プロダクトマネージャーの理解度を優先的に確認してください。必ず発表者として指名する、など。
   * 演習完了時点で「よくわからなかったのでできてないです」と言われるリスクを避けるため、定期的に確認ポイントを入れましょう (Step3までできましたか?など)
   * 演習でStep3’まで進むことは強制しません。Event Stormingの使い方に慣れることが先決です。
   * コマンドから集約を経由してドメインイベントが発生している点について。意思決定をし、内部/外部のリソースを使用して実行した結果がイベントとして残る、というイメージです。最終的にコマンドはAPIの実行で、データ(集約)とドメインイベント(振いまい)を持つクラスを起動する形になります。最初からクラスを意識して設計するのは難しいため、集約/外部システムの経由は本ワークショップでは意識する必要はありません。内部なのか外部なのかのざっくりした切り分けのイメージです。
6. 個社ワーク(ML Usecase Discovery Worksheet)
   * 課題解決のインパクトが大きいユースケースを書き出してください。MLが適用できそう、Event Stormingでかき切れるか、を書き出す条件にしないでください。
   * ML Usecase Discovery Worksheetへ書き出ししてからEvent Stormingに移るようガイドしてください。優先度の高いユースケースを事前に整理し、そこにフォーカスしてストーミングするためです。プロダクトが複数のペルソナに扱われる場合(学生も社会人も使うなど)や複数の機能がある場合、適切なサイズのユースケースでないとEvent Stormingの対象範囲が大きくなりすぎてグダグダになります。
   * ML Usecase Discovery Worksheetの緊急度と重要度の違いについて。緊急度は例えば法令対応など対応完了までに時限性がある場合に高くなります。重要度は、解決できた場合の効果の大きさです。例えば、英会話を身に着けると就職の幅が広がので効果は大きい(=重要度は高い)ですが、今すぐやらなくても今の仕事に差し支えないので緊急度は低い、などです。上司がいきなり海外の人になり報告が全て英語になったら緊急度は高くなります。
   * ユーザーや機能、重要度や緊急度の観点からユースケースを複数出してください。複数ないと優先度の評価ができないためです。
7. 個社ワーク(Event Storming)
   * 主導権がプロダクトマネージャーに渡るようファシリテーションします。プロダクトマネージャーの発言が少ない場合、ファシリテーターは参加を促してください。プロダクトマネージャーがEvent Stormingの内容をコレジャナイと感じたら絶対に実装につながりません。
   * 発言量が多い人に主導権が移りがちなので、Event Stormingは最初黙って行い。後でマージする流れを徹底してください。マージはもちろんプロダクトマネージャー主導で行います。
   * コマンドから集約を経由してドメインイベントが発生している点がしっくりこないと思いますが、これは集約が最終的にプログラム上のクラス(データと振いまい=ドメインイベントを持つオブジェクト)になるためです。最初からクラスを意識して設計するのは難しいため、集約/外部システムの経由は本ワークショップでは意識する必要はありません。内部なのか外部なのかのざっくりした切り分けのイメージです。
6. 個社ワーク
   * ML Usecase Discovery Worksheetへ書き出ししてからEvent Stormingに移るようガイドしてください。適切なサイズのユースケースでないとEvent Stormingの対象範囲が大きくなりすぎてグダグダになります。

## Day2: ハンズオン

プログラミングの演習と、コミュニケーションの演習があります。プログラミング演習が少なくて座学のようだった、とならないように適宜コードを修正する時間を取るようにしてください。開始の段階で参加者のロールを聞いておくことで、コミュニケーション演習が進めやすくなります。

1. Introduction
   * 「ハンズオンの概要」の解説するプロセスの範囲、「ハンズオンのゴール」、「ハンズオンが生まれた理由」のロール名称を中心に解説してください。ハンズオンの構成などはやっているうちにわかるので、ここで厚く説明する必要はないです。ロール名称の中で、「この中で自分に近いロールをチャット欄で教えてください」とリクエストし、参加者のロールを把握しておくとコミュニケーション演習が進めやすくなります。
2. Environment Setup
   * 「どうやるのか」の仮想環境周りは細かいので、あまり深く説明しなくてよいです。`Git`の説明は開発者の方にとっては不要なので省いてください。
   * Extra Tutorialで、手を動かしてもらってください。
   * コミュニケーション演習は、1人参加者の方を指名 or 挙手して応えてもらう形式で進めます。
3. Business Understanding
   * 最初にNotebookをすべて実行してもらってください。
   * 「なぜやるのか」の「Exercise: 他にどんなパラメーターが調整されれば当初予定された期間で投資額が回収できるか試してみましょう。」で、`after_workers` / `after_worktime` / `hourly_pay` などをいじってもらって、シミュレーションを促してください。
   * プログラミング演習はすべて話しているとかなり長いので、どれか一つ聞きたいものを参加者から募ってください。
4. Analyze
   * Business Understandingが話中心だったので、ここでExerciseの時間をとってください。簡単なpandasの関数の使い方をデモするなど。
   * クラメールの相関係数は頭痛くなっちゃうと思うので軽く触れる程度で構いません。
5. Prepare
   * 解説は軽めなので、時間の調整に使ってください。
6. Preprocess
   * コードが結構複雑なので、丁寧に説明をしてください。
7. Train
   * 時間に余裕があれば好きなモデルを試してみてもらってください。
8. Test
   * 二乗誤差や決定係数はなじみのないキーワードなので、少し丁寧に解説してください。
9. Ending
   * ゴールの確認と、アイデアソンでの期待値を伝えてください。Step3'で機械学習のユースケースを実装するためのプロセスの構築に、今日の知識を役立ててください、など。

## Day3: アイデアソン

ファシリテーターのナビゲーションが成功するかが満足度を大きく左右しています。適切なユースケースが発見できるよう、適宜アドバイスを行ってください。

* 「正しい」Event Stormingを行うことが目的ではないので、ポストイットの使い方や厳密性にあまりこだわらなくてよいです。
* 最終的にお客様自身が推進できるようにならないと意味がないので、誘導するようなファシリテーションは避けてください。機械学習に関する質問であれば研究開発者の方に振る、ユーザーの課題に関する議論があればプロダクトマネージャーの方から聞き出す、など参加者同士のコミュニケーションを引き出すファシリテーションを意識し、誘導にならないよう注意してください。