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

DevRel Guild Meetup #6 にて登壇
https://devrel-guild.connpass.com/event/397389/

Transcript

1. 勉強会企画をアプリで構造化してみた 〜そこで見えた、AIとの付き合い方〜 株式会社ビットキー / 2026.07.06 DevRel Guild Meetup #6
2. 実用可能なツールと、 納得感のある業務プロセス構築を
3. パウリ @pauli_agile 株式会社ビットキー / 技術広報チームマネージャー ひとこと：子がかわいい
4. 早速ですが、 こういうのを作りました
5. こんなの
6. こんなの
7. こんなの
8. 作り方
10. 完
11. 完 …ではなく
12. 勉強会企画をアプリで構造化してみた 〜そこで見えた、AIとの付き合い方〜 株式会社ビットキー / 2026.07.06 DevRel Guild Meetup #6
13. 勉強会企画をアプリで構造化してみた 〜そこで見えた、AIとの付き合い方〜 株式会社ビットキー / 2026.07.06 DevRel Guild Meetup #6
14. 1. なぜ作ったのか 2. 実際に運用してどうだったか 3. 今後どうしていきたいか …をお伝えします
15. 前提
16. 先日の登壇 (DevRel Guild Meetup #5) 技術広報のダイヤモンドサイクルを紹介
17. 継続的な発信・関係性構築が必要 カンファレンスなどで認知獲得はできているが、技術領域毎の継続関係が弱い 「ハードウェアの会社でしょ？」 → 「WEBサービスいっぱいあるよ」的な 各技術領域において、継続的な発信・関係性構築が必要そう 技術広報をしていく中での課題①
18. 技術広報をしていく中での課題② 組織の変化による標準化が必要 各種施策は技術広報チームから、開発部主体で実施するよう移行中 会社として技術広報活動におけるアセットが溜まっており、採用が人事から開発部主体 に切り替えていくと同時に、技術広報も開発部主導にし一貫性を保ちたい 一方で発信の見せ方や、関係性構築など技術広報チームに専門性がある部分もあるた め、実行から支援にロールを変化 …ただし、実際のところ一部の施策の立案と承認が個人に依存している状態
19. 技術広報をしていく中での課題② 組織の変化による標準化が必要 各種施策は技術広報チームから、開発部主体で実施するよう移行中 会社として技術広報活動におけるアセットが溜まっており、採用が人事から開発部主体 に切り替えていくと同時に、技術広報も開発部主導にし一貫性を保ちたい 一方で発信の見せ方や、関係性構築など技術広報チームに専門性がある部分もあるた め、実行から支援にロールを変化 …ただし、実際のところ一部の施策の立案と承認が個人に依存している状態 課題領域の整理
22. AAARRRPファネルで整理
23. AAARRRPファネルで整理（強み）
24. AAARRRPファネルで整理（弱み）
25. AAARRRPファネルで整理（弱み） 継続的な発信活動により改善を期待
26. で、その施策立案、 誰でもできますか ?
27. 「調査して、ターゲット決め、企画組む」の壁 ステップの名前は言えても、判断基準は言語化できていなかった 重かったのは前半4つ。ここに一番、暗黙知が詰まっていた
28. tech-pr-generator を作った
29. 判断を言語化し、システム化する 目指したのは「完璧な施策」ではない 「テーマを入れたら企画書のたたきが出てくる」 状態を目指す これにより、アジリティの高い技術広報施策の実行をしたい
30. 8段階のパイプライン 「入れた単語がそのままタイトルになる」ことを意図的に避けた設計
32. GUIにしてインナーソース配布 ここまでをGUIツールにして、チーム内に配布した 「テーマを入れる」だけで、企画書のたたきまで自動で出てくる状態
33. 正直な現状
34. 配布した、で終わっていません 正直に言うと、そのツールを中心に業務が回っている、という状態には まだ届いていない
35. 成功事例: QAイベント tech-pr-generatorで企画した「AI時代に、品質エンジニアとして何者になるか」 登壇者満足度・参加者満足度ともに高かった キーワードからの叩き、仮説検証がうまくハマった
36. 成功事例: QAイベント tech-pr-generatorで企画した「AI時代に、品質エンジニアとして何者になるか」 登壇者満足度・参加者満足度ともに高かった キーワードからの叩き、仮説検証がうまくハマった 初動で施策立案の慣性が働いていなかった から、ツールを使うタイミングが合致
37. しかし、自然とは使われていない ツールとしては利用価値はありそう、、、 が、インナーソース展開しても、 このツールが使われていない
38. 見えた課題：ツールそのもの 1. 生成に時間がかかる → 「とりあえず生成」のハードルが高い とっかかりとなるキーワードを考える時間もなく、またキーワード 2. 施策が思い通りの方向性に出力されないことがある リサーチや戦略策定時の視野が広く、多角的にしすぎていることからコン テキスト肥大化 結果として（待った上での）出力結果が満足のいくものにならず忌避して いく
39. 見えた課題：業務プロセスとのミスマッチ 1. 「ラフに施策作成しアジリティを生む」という構想とミスマッチ （先述の通りなので割愛） 2. 言語化できていないことをコーチング的に引き出す納得感も必要 叩き台として作成する「プロセス」には重要な文脈並びに、 その文脈をともに形成したという経験 が含まれている それを飛ばして施策が生成されるため、AIスロップのような扱いに
40. 今後の展望とまとめ
41. AIツール・Skillは資産だが ... ・AIで業務フロー・観点を言語化したツール/Skillは資産になる 　が、体制変更で業務プロセスは変動する ・ツールを作るだけでは足りない 　変動に耐えられるAI利用や、ツールの役割を可変にする運用プロ　セ スも合わせて構築する と良い
42. 実用可能なツールと、 納得感のある業務プロセス構築を
43. ありがとうございました！ 技術広報チームリーダー募集中 @pauli_agile の DM にてご連絡ください！