こんにちは、エンジニアの山田（@yamadashy）です。
この記事は、記念すべき COLOPL Tech Blog 100 本目の記事です。せっかくの節目なので、コロプラの技術広報がどのように始まり、どのように運用を変えてきたかを振り返ります。
コロプラでは現在、社内外の勉強会、カンファレンス協賛、スポンサーブース、技術ブログなど、さまざまな形で技術発信に取り組んでいます。こうした技術広報の活動は、最初から役割や運用が整理されていたわけではありません。社内の勉強会や LT、エンジニアの個別の発信、イベント運営の試行錯誤が少しずつ繋がり、いまの形になってきました。
振り返ると、変わってきたのは発信媒体だけではありません。社内の技術ネタや魅力を見つけ、話せる形にし、公開後の反応を次へ繋げる運用も少しずつ変わってきました。
この記事では、次の 3 つの変化を軸に振り返ります。
- 社内の勉強会や Slack での日常的な情報共有が、技術広報の起点になった
- 続けるうちに、ネタ不足だけでなく運用負荷や公開判断が課題として見えてきた
- Slack リアクション、GitHub、AI によるレビュー、公開後の反応共有などで、発信を続ける仕組みを整えてきた
技術広報を担当している方や、社内の技術発信を増やしたい方の参考になれば幸いです。
技術広報は、発信が続く状態を作る仕事
技術広報というと、記事を書く、イベントに出る、SNS で告知する、といった外向きの活動を想像しがちです。もちろんそれらも大事です。一方で、継続していくには社外発信を支える社内側の活動も同じくらい重要だと考えています。
社外に向けた取り組みでは、コロプラが向き合う技術課題や、エンジニア組織の文化が伝わる状態を目指します。特にゲーム開発のバックエンドやインフラは、外から仕事内容が見えづらい領域です。たとえば、Web サービスの経験があるエンジニアにとっても、ゲーム領域でその経験がどう活きるのかは、記事や登壇を通じて伝えていく必要があります。
発信を支える社内の取り組みでは、一部の慣れた人に偏らず、ブログや勉強会などの発信を継続できる状態を目指します。属人的な努力に頼りすぎず、ネタの収集や案出し、相談、レビューの仕組みを整え、持続可能な発信体制を作ります。
コロプラでは、技術広報の目的を大きく 3 つで捉えています。
| 目的 | 何に繋がるか |
|---|---|
| 市場価値・ブランディング | コロプラエンジニアの技術的な取り組みを社外に伝える |
| 成長 | アウトプットを通じて、個人とチームの学びを深める |
| 採用 | 技術発信を通じて、候補者との接点を増やす |
この 3 つは、一度の記事公開やイベント出展では完結しません。発信を続け、社内外の反応を次の活動に繋げていきます。つまり技術広報は、「発信を増やす仕事」というより、「発信が続く状態を作る仕事」だと考えるようになりました。
歴史：起点は勉強会と社内共有
2022 年ごろから、コロプラの技術発信は COLOPL Tech としてまとまった形を取り始めました。エンジニアで現在は技術基盤本部の部長を務める齋藤が中心となり、テックブログや connpass での勉強会を立ち上げました。最初の記事では、ゲームを支える技術や組織の話を発信すること、社内勉強会や他社交流会を続ける中で「ブログはやっぱり欲しい」という機運が高まったことを書いています。
第 1 回 COLOPL Tech 勉強会では、「高負荷/トラフィックなゲームの運用を支える SRE」をテーマにしました。ブログと勉強会がほぼ同時に立ち上がったことで、記事とイベントを組み合わせて技術発信を進める土台ができました。当時は、ゲーム開発や運用に関するバックエンド、インフラの技術やノウハウを社外に届けることが中心でした。
ただ、その土台には社内向けの勉強会や LT 文化がありました。リモートワークが広がると、他プロジェクトの取り組みや横断組織の知見は意識して共有しないと見えづらくなります。社内 LT や勉強会は、情報共有の場であると同時に、社外発信の種を見つける場でもありました。
社内で見つかった話題は、カンファレンス出展や登壇など社外の接点にも繋がりました。ブース展示やイベント後の振り返りも、技術発信の材料になります。
Slack の技術系チャンネルも、社内の情報共有を支える重要な場所です。コロプラでは、エンジニア向けチャンネルに tech- という prefix を付けています。tech-ai、tech-php、tech-golang、tech-csharp など、AI や各プログラミング言語の話題を共有する場があり、投稿や議論から記事の種が見つかることもあります。
このような社内コミュニケーションの工夫は、以前の記事でも紹介しています。
齋藤が中心となって立ち上げた当時の取り組みを見ると、社内の情報共有や勉強会も発信の起点になっていたことがわかります。そこで共有された技術的な話題を、ブログや勉強会を通じて社外にも届く形にしていきました。
課題：ブログがハブになるほど運用は重くなる
勉強会や登壇の内容は、その場で終わると届く範囲が限られます。そこで、テックブログが技術広報のハブになっていきました。
たとえば、次のような流れです。
- 社内外の勉強会の登壇資料を記事にする
- 社内 LT の内容を外向けに再構成する
- カンファレンス出展の振り返りを記事にする
社内 LT・勉強会、登壇、カンファレンス出展で生まれた話題をテックブログに残し、SNS 告知、採用面談、技術コミュニティとの接点に繋げる。こうして、勉強会、ブログ、カンファレンス、SNS が少しずつ繋がっていきました。
ブログの良いところは、長期的に読まれ続ける接点になることです。イベント当日に会えなかった人にも届き、検索から長く読まれる記事もあります。採用面談やイベントで「この記事を読みました」と言ってもらえることもあります。PV だけでは見えない接点が残るのが、ブログの価値だと感じています。
一方で、ブログがハブになるほど運用は難しくなります。テーマをどう見つけるか、誰に依頼するか、どの段階でレビューするか、公開可否をどう確認するか、公開後の反応をどう共有するか。勢いで回っていたものも、続けるほど仕組みが必要になります。
記事化までの流れは、単純化すると次のように整理できます。
ネタを見つける → 骨子を作る → 下書きを書く → 技術レビュー → 広報・公開可否確認 → 公開 → 反応を共有
この流れの中で、ネタ不足、執筆負荷、レビューの属人化、公開判断の迷いといった詰まりどころが出てきます。
たとえば、ブログ記事や勉強会・登壇を準備するときは、社内向けに次のような流れと目安を共有しています。
| 工程 | 主な対応者 | 内容 | 目安 |
|---|---|---|---|
| ネタ・方向性の決定 | 本人、上長、運営 | 運営メンバーと話し、ある程度の方向性を共有する。工数がかかる場合は、事前に上長の合意のもと進める | - |
| 記事執筆、資料作成 | 本人 | テックブログや勉強会の進め方を参考に準備する | 記事: 1〜2人日、資料: 5〜10人日 |
| 現場レビュー | 本人、現場 | 上長や関係者にレビューを依頼する | - |
| 技術広報レビュー | 本人、技術広報 | 技術広報の運営メンバーにレビューを依頼する。現場レビューと並行も可 | 1〜2営業日 |
| 広報チェック | 技術広報、広報 | 広報・プロダクト広報で確認する。IP などの画像が絡む場合は、先に画像部分だけチェックすることもある | 最低5営業日、内容次第では10営業日 |
| リハ | 本人、現場、技術広報 | 登壇の場合、必要に応じてリハを設定する | - |
| 公開 | 運営 | 記事の場合は技術広報が公開する | - |
課題：発信が止まる理由はネタ不足だけではない
技術広報は、立ち上げの勢いだけでは続きません。よくある理由は「ネタがない」ですが、実際にはネタを記事やイベントにする道筋が見えていないことの方が多いです。
普段の仕事で当たり前になっている工夫も、外から見ると十分に面白い話かもしれません。逆に、技術的には面白くても、公開できる範囲の確認や説明の組み立てに時間がかかることもあります。
社内アンケートや振り返りでは、「何を書けば良いかわからない」「技術的に間違っていないか不安」「本業の時間を圧迫しそう」「どこまで公開して良いかわからない」といった壁も見えてきました。書く人の気合いだけで解決する問題ではありません。
もう一つ大きいのは、発信が個人の頑張りに寄りすぎることです。記事を書く人、レビューする人、イベントを企画する人が固定化し、その人が忙しくなると活動が弱まる。どこの会社でも起こりやすい課題です。
見えてきた課題は、次のように整理できます。
| 課題 | 起きやすいこと |
|---|---|
| ネタ不足 | 技術的に面白い話があっても、記事の形にできない |
| 執筆負荷 | 本業の合間に下書きまで作るのが重い |
| レビューの属人化 | 特定の人に確認が集中する |
| 公開判断 | どこまで外に出して良いか迷う |
コロプラでも、勉強会やブログを続ける中で、発信の熱量と運用負荷のバランスを考える必要が出てきました。活動が弱まった時期を失敗で終わらせず、止まった理由から次に仕組み化することを考えるようになりました。
体制：現場と広報で支える
再始動のタイミングでは、技術広報を「エンジニアが記事を書く活動」だけにしないことを意識しました。
技術の中身を一番よく知っているのはエンジニアです。一方で、読者に届く形にするには、取り組みの背景や、読者に持ち帰ってほしいことまで整理します。
現在は、技術広報の担当者とエンジニアが近い距離でやり取りしています。勉強会やイベント後に「この反応は記事にできそうですね」「この LT は外向けにも話せそうですね」と話し、企画の種を拾います。エンジニア側から相談することもあります。
社外に出す情報である以上、広報との連携も欠かせません。コロプラでは、記事や資料を公開する前に社内の確認ルールに沿って、未公開情報や表現、公開範囲などに問題がないかを確認しています。
この体制を前提に、日々の運用ではネタ出し、下書き管理、公開後の反応共有などを少しずつ整えてきました。ここからは、その中でも効いた取り組みを紹介します。
取り組み1：Slack リアクションでネタの種を拾う
まず効いたのが、Slack のリアクションを使ったネタ出しです。
以前から Reacji Channeler を使い、:hack: 
のリアクションが付いた投稿を特定チャンネルに集めています。プロジェクトやチームのチャンネルに投稿された技術的に面白い話題が集まるため、眺めているだけでも発見があります。こうした社内共有の流れがあると、技術広報側も「外に出すと面白そうな話」を見つけやすくなります。
現在は、Slack 上で :blog-chance: 
も使っています。誰かの投稿を見て「これは記事にできそう」「外向けに話すと面白そう」と思ったら、その絵文字を押すだけで候補として共有されます。
アンケートや自薦だけでは、忙しい中でなかなかネタは集まりません。一方で、他の人の投稿にリアクションするだけならかなりカジュアルです。
実際に、Slack 上の PHP に関する投稿に :blog-chance: が付き、Deep Dive PHP: PHP 8.5 の新機能「Tail call VM」とは？ という記事に繋がりました。自薦に頼りすぎず、他薦で日常の技術の断片を拾えることも、ネタ不足への対策になっています。
取り組み2：GitHub と AI で運用を軽くする
運用面では、記事を GitHub で管理していることも効いています。
現在のテックブログでは、下書きを Markdown ファイルとして管理し、Pull Request 上でレビューしています。エンジニアにとっては普段の開発フローに近く、差分を見ながら指摘できます。誰がどこを直したかも残るため、後から見返しやすくなります。
この運用では、はてなさんが公開している HatenaBlog Workflows Boilerplate を活用しています。GitHub Actions から下書きを作成して Pull Request を立て、push のたびにブログの下書きへ反映できます。
下書き URL やプレビュー URL は Pull Request 上で確認できます。記事から参照する画像もリポジトリに置けば同期されるため、ブログ管理者が管理画面で本文や画像を都度反映する手間を減らせます。
最近は記事のレビューに Devin や Claude Code などの AI も使っています。読みづらい箇所を見つける、レビュー観点の抜けを確認する、初稿のたたき台を作る、といった用途です。AI に任せきりにはせず、人間が読む前提の補助として使っています。なお、下書きの取り扱いについては社内の AI ポリシーに沿って運用しています。
技術広報の記事では、事実確認が特に重要です。AI は文章を整えるのは得意ですが、社内事情や公開可否は判断できません。そのため、AI には文章化やレビューの補助を任せ、最後はエンジニアと技術広報担当が確認します。公開範囲や会社としての見え方に迷うところは、広報に相談します。
この形にして良かったのは、執筆者が下書き段階で最低限の品質を整えやすくなったことです。誤字脱字や言い回しに加え、コロプラのテックブログで守っている表記、構成、公開前確認の観点を事前に確認できます。
人間が一つずつ指摘しなくても基本的なルールに近づけられるため、レビューでは技術的な正確さや公開可否など、人が見るべき部分に集中しやすくなります。
取り組み3：反応を共有して次に繋げる
3 つ目は、公開して終わりにしないことです。記事やイベントへの反応を拾い、書いた人や関係者に返すと、次の発信に繋がりやすくなります。
技術広報の成果は測りづらいです。記事の PV、イベント参加者数、X の反応、connpass のメンバー数、採用ページへの流入など、見られる数字はいくつもあります。ただ、それだけで活動の価値を判断するのは少し危ういと感じています。
一方で、数字を見なくて良いわけでもありません。公開本数、イベント実施数、登壇数、記事の反応、SNS での広がりは、活動が続いているかを見る手がかりです。
ただし、技術広報の効果は時間差で出ることが多いです。記事を読んだ社外の方とイベントで会話できた。カンファレンスで話した内容が社内勉強会に繋がった。社内 LT の話がブログ記事になった。採用面談で「この記事を読みました」と言ってもらえた。こうした反応も、技術広報を続ける理由になります。
具体的には、Slack のオープンチャンネルで記事公開を共有する、イベントや採用面談で記事が話題になったら本人に伝える、外部からの感想を拾って共有する、といったことです。反応が届くと、書いた人も「出して良かった」と感じやすくなります。
KGI や KPI を置くなら、短期の行動指標と長期の関係性を分けて考えるのがよさそうです。すべてを一つの数字に押し込まない方が、活動の実態に合います。
| 見るもの | 指標や反応の例 |
|---|---|
| 短期の行動 | 公開本数、イベント実施数、参加者数 |
| 短期の反応 | PV、SNS 反応、読了、会話 |
| 長期の関係性 | 社外接点、候補者認知、コミュニティとの接続 |
| 社内文化 | 発信者の増加、継続しやすさ |
これから
コロプラの技術広報は、まだまだ完成形ではありません。直近では支援体制を整えることに力を入れてきました。次は、関わる人を増やし、発信のハードルをさらに下げる段階です。
これから作りたいのは、発信者が一部に偏らず、初めて記事を書く人でも相談しやすく、公開後の反応が本人に届く状態です。登壇、勉強会、ブログ、カンファレンス出展を、ばらばらの施策ではなく一つの技術発信の流れとして繋げていきます。
振り返ってみると、技術広報は立ち上げて終わりではありません。勢いがある時期も、運用負荷が見えてくる時期もあります。そのたびに、何を仕組みにするか、誰と進めるかを見直してきました。
これからも、コロプラの技術やものづくりの面白さを、社内外のエンジニアに届く形で発信していきます。
ColoplTechについて
コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpass および X で情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。
また、コロプラではインフラエンジニアを積極採用中です！
興味を持っていただいた方はぜひお気軽にご連絡ください。
