勉強会企画をアプリで構造化してみた〜そこで見えた、AIとの付き合い方〜 / I've structured a study group plan using an app.

by Pauli

Embed

Start on current slide

Slide 1

Slide 1 text

勉強会企画をアプリで構造化してみた〜そこで見えた、AIとの付き合い方〜株式会社ビットキー / 2026.07.06 DevRel Guild Meetup #6

Slide 2

Slide 2 text

実用可能なツールと、納得感のある業務プロセス構築を

Slide 3

Slide 3 text

パウリ @pauli_agile 株式会社ビットキー / 技術広報チームマネージャーひとこと：子がかわいい

Slide 4

Slide 4 text

早速ですが、こういうのを作りました

Slide 5

Slide 5 text

こんなの

Slide 6

Slide 6 text

こんなの

Slide 7

Slide 7 text

こんなの

Slide 8

Slide 8 text

作り方

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

完

Slide 11

Slide 11 text

完 …ではなく

Slide 12

Slide 12 text

勉強会企画をアプリで構造化してみた〜そこで見えた、AIとの付き合い方〜株式会社ビットキー / 2026.07.06 DevRel Guild Meetup #6

Slide 13

Slide 13 text

勉強会企画をアプリで構造化してみた〜そこで見えた、AIとの付き合い方〜株式会社ビットキー / 2026.07.06 DevRel Guild Meetup #6

Slide 14

Slide 14 text

1. なぜ作ったのか 2. 実際に運用してどうだったか 3. 今後どうしていきたいか …をお伝えします

Slide 15

Slide 15 text

前提

Slide 16

Slide 16 text

先日の登壇 (DevRel Guild Meetup #5) 技術広報のダイヤモンドサイクルを紹介

Slide 17

Slide 17 text

継続的な発信・関係性構築が必要カンファレンスなどで認知獲得はできているが、技術領域毎の継続関係が弱い「ハードウェアの会社でしょ？」 → 「WEBサービスいっぱいあるよ」的な各技術領域において、継続的な発信・関係性構築が必要そう技術広報をしていく中での課題①

Slide 18

Slide 18 text

技術広報をしていく中での課題② 組織の変化による標準化が必要各種施策は技術広報チームから、開発部主体で実施するよう移行中会社として技術広報活動におけるアセットが溜まっており、採用が人事から開発部主体に切り替えていくと同時に、技術広報も開発部主導にし一貫性を保ちたい一方で発信の見せ方や、関係性構築など技術広報チームに専門性がある部分もあるため、実行から支援にロールを変化 …ただし、実際のところ一部の施策の立案と承認が個人に依存している状態

Slide 19

Slide 19 text

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

AAARRRPファネルで整理

Slide 23

Slide 23 text

AAARRRPファネルで整理（強み）

Slide 24

Slide 24 text

AAARRRPファネルで整理（弱み）

Slide 25

Slide 25 text

AAARRRPファネルで整理（弱み）継続的な発信活動により改善を期待

Slide 26

Slide 26 text

で、その施策立案、誰でもできますか ?

Slide 27

Slide 27 text

「調査して、ターゲット決め、企画組む」の壁ステップの名前は言えても、判断基準は言語化できていなかった重かったのは前半4つ。ここに一番、暗黙知が詰まっていた

Slide 28

Slide 28 text

tech-pr-generator を作った

Slide 29

Slide 29 text

判断を言語化し、システム化する目指したのは「完璧な施策」ではない「テーマを入れたら企画書のたたきが出てくる」状態を目指すこれにより、アジリティの高い技術広報施策の実行をしたい

Slide 30

Slide 30 text

8段階のパイプライン「入れた単語がそのままタイトルになる」ことを意図的に避けた設計

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

GUIにしてインナーソース配布ここまでをGUIツールにして、チーム内に配布した「テーマを入れる」だけで、企画書のたたきまで自動で出てくる状態

Slide 33

Slide 33 text

正直な現状

Slide 34

Slide 34 text

配布した、で終わっていません正直に言うと、そのツールを中心に業務が回っている、という状態にはまだ届いていない

Slide 35

Slide 35 text

成功事例: QAイベント tech-pr-generatorで企画した「AI時代に、品質エンジニアとして何者になるか」登壇者満足度・参加者満足度ともに高かったキーワードからの叩き、仮説検証がうまくハマった

Slide 36

Slide 36 text

成功事例: QAイベント tech-pr-generatorで企画した「AI時代に、品質エンジニアとして何者になるか」登壇者満足度・参加者満足度ともに高かったキーワードからの叩き、仮説検証がうまくハマった初動で施策立案の慣性が働いていなかったから、ツールを使うタイミングが合致

Slide 37

Slide 37 text

しかし、自然とは使われていないツールとしては利用価値はありそう、、、が、インナーソース展開しても、このツールが使われていない

Slide 38

Slide 38 text

見えた課題：ツールそのもの 1. 生成に時間がかかる → 「とりあえず生成」のハードルが高いとっかかりとなるキーワードを考える時間もなく、またキーワード 2. 施策が思い通りの方向性に出力されないことがあるリサーチや戦略策定時の視野が広く、多角的にしすぎていることからコンテキスト肥大化結果として（待った上での）出力結果が満足のいくものにならず忌避していく

Slide 39

Slide 39 text

見えた課題：業務プロセスとのミスマッチ 1. 「ラフに施策作成しアジリティを生む」という構想とミスマッチ（先述の通りなので割愛） 2. 言語化できていないことをコーチング的に引き出す納得感も必要叩き台として作成する「プロセス」には重要な文脈並びに、その文脈をともに形成したという経験が含まれているそれを飛ばして施策が生成されるため、AIスロップのような扱いに

Slide 40

Slide 40 text

今後の展望とまとめ

Slide 41

Slide 41 text

AIツール・Skillは資産だが ... ・AIで業務フロー・観点を言語化したツール/Skillは資産になる　が、体制変更で業務プロセスは変動する・ツールを作るだけでは足りない　変動に耐えられるAI利用や、ツールの役割を可変にする運用プロ　セスも合わせて構築すると良い

Slide 42

Slide 42 text

実用可能なツールと、納得感のある業務プロセス構築を

Slide 43

Slide 43 text

ありがとうございました！技術広報チームリーダー募集中 @pauli_agile の DM にてご連絡ください！