目的

補足議題
• 遊技機（パチンコ・スロット）制作経験者の確保
• 24日の集まりの参加人数の確保と、スカイラウンジの扱い
• 依頼タスクの進捗を把握するレポートライン（GitHub）の整備
• 営業用のAI動画（ショートドラマ等）の作り方

決定事項

• フィールズ（ボード未登録）向けの営業資料は、「サンプル映像 → 一社完結 → 費用 → 期間」の順で見せる構成に作り直すと決めた商談は1時間と限られるため、コード生成か動画生成かといった作り方の説明は不要。最初に映像を見せ、前工程から仕上げまで一社で対応できること、費用、期間を示し、カスタマイズも可能と伝える。先方が気にするのは「一社で完結するか」「費用」「納期」「トラブル時の対応」の4点。この進め方は、メンバー全員で共有する営業の型とする。
• フィールズ案件に対応するため、パチンコ・スロットの制作経験者（3D制作経験者を含む）をチームに迎える方向で動くと決めた遊技機の制作工程を知る人がいれば「内容を分かったうえで一社完結できる」と伝えられる。候補は、研修生の中の経験者や、AE研修を受けたあと遊技機の制作会社に入った人。まず話を聞くところから始め、オンラインでも早めに打合せを設定する。
• 24日の集まりは、3期生を動員して参加人数を確保する方向で進めると決めた現状の参加見込みは約6人にとどまる。深屋さんから3期生に魅力的に伝えてもらい、人数を詰める。研修生が作ったサンプルも活かす。
• スカイラウンジの予約を維持するかは、3期生の集まり具合を見て判断する（未確定）人数が少ないままならキャンセルして通常の部屋に切り替える案が出ている。3期生を集めて人数が多そうなら予約を維持する。
• GitHubを使ったタスク管理とレポートラインを、試験的に導入すると決めた依頼を受ける側が依頼タスクの一覧を手元で作り、進捗の動きはGitHubから抽出して、判断に必要な情報だけを案件ごとにまとめて報告する。対応中の案件のリポジトリを移管し（今週中が目安）、最初の接続作業だけ手間をかけて、以降は報告の手間を減らす。移管後は依頼する側がGitHub側を確認する。

タスク・ネクストアクション

背景や理由

• 今回のリハーサルの位置づけ

  フィールズ向け提案を、先方の担当者役を立てて質問を挟みながら説明する形で確認した。質問を受けても、すぐ本題に戻って説明を続ける練習も兼ねている。フィールズは「最重要案件」として、必ず落とし込んで収益につなげたい案件と位置づけられた。

• 作成された提案の概要

  パチンコの演出映像の制作にAIを活用し、修正・量産・プレビズ（事前の映像イメージ）検証の高速化と低コスト化を図る提案。フィールズでは年間約5億円がアフターエフェクト中心の工程に使われていると想定し、そのうち何割かをAIで効率化して、浮いた予算を演出の強化や量産に回せるという考え方。作り方は、コード生成（狙った通りに出せる）と動画生成（自由な表現ができる）の2つを組み合わせる想定。文字・ロゴ・テロップなどはコード、エフェクト素材などは動画生成で対応する。

• 要再確認 数字の根拠について

  「年間約5億円」は推定。「1機種の開発に約23ヶ月」は、先方の開発本部長の採用サイトの情報をもとにした認識。いずれも商談前に根拠を確認しておく。

• 営業の見せ方を絞る理由

  先方の担当者は、自分にとってメリットがあるか、気持ちよく仕事を任せられるか、実力と分かりやすさ・安さ・早さ、トラブル時の対応、といった点を見ている。技術の詳細はほとんど関心を持たれないため、「サンプル映像 → 一社で完結 → 費用 → 期間」と短くまとめるほうが決めやすい。納期が遅れそうな場合は、クリエイターが多数いるため緊急チームを編成して対応する、とあらかじめ伝える。

• ワンストップ体制の伝え方

  複数社の連携で進める他社の提案資料とは異なり、AIC側は制作チームやクリエイターが多数おり、案件の規模や複雑さに合わせてチーム構成をカスタマイズして、外注を挟まず自社でワンストップに対応できる。最初に「自社で何ができるか」を示すのが重要、という整理。

• 遊技機の制作経験者が必要な理由

  遊技機の制作工程や既存の技術環境を分かっていると、「そもそも何のことか」と詰まることがなく、どの部分ができるかを具体的に話せる。「実は経験者もいます」と言えることが強みになる。話を聞く先として、AE研修を受けて遊技機の制作会社に入った人が挙がった。

• 24日の集まりの参加見込み

  この集まりは、10/5の定例で決めた「研修生のスキルを見極めるテストイベント」と同じもの。24日（土）は研修と重ならないため、仕事のある人や地方在住でない人は参加しやすい。一方、1期生・2期生は仕事や遠方在住、予定の都合などで、合計しても一桁（約6人）にとどまる見込み。3期生は他の検証と並行して動いているため、この機会に巻き込んで雰囲気を高めたい。スカイラウンジは一部だけ借りる方法もあり、その点も視野に入れる。

• GitHubでの進捗報告を試す理由

  依頼しているタスクが多く、現場の状況を細かく把握しにくいため、依頼タスクを並べて「進んだ／進んでいない」を毎日短時間で確認できる形にしたい、という提案があった。報告を受ける側が毎回思い出して聞き取るよりも、整った情報が届く仕組みのほうが効率が良い。GitHubは作業ログから状況を抽出できるが、「何を依頼されたか」の一覧は別途必要なため、手元のタスク一覧と組み合わせる。移管は最初の接続作業だけ負担がかかり、以降は管理コストが下がる。複数のリポジトリがあるため共同編集者の形も案として出たが、まず移管を試してみることになった。

課題や要望

• →
  提案の理解と根拠の整理提案資料に出てくる遊技機の用語（繰越・形式試験など）や数字の根拠を、商談前に理解しておく必要がある。資料に出てくる内容は事前に読み込んでおく。
• →
  遊技機制作経験者の不足フィールズ案件を確実に取るには、パチンコ・スロットの制作を知る人材が不可欠。現時点では足りていない。
• →
  24日の参加人数現状は約6人の見込み。3期生の動員で増やせるかを確認する。
• →
  依頼タスクの進捗が見えにくい報告を3秒ほどで把握できる形（案件ごとに1行程度）にして、判断だけに集中できる状態を目指す。報告が少ない理由は「見たくない」のではなく、タスクが多すぎて追えないため、という共通認識を確認した。

その他情報共有