この記事は 技術広報 Advent Calendar 2025 4日目の記事です。
12/3 は ShuzoN__ さんの 1年カンファレンスを見張ってプロポーザル登壇10倍にした登壇文化形成 でした。
こんにちは。@plageoj です。気づけばベトナムで働き始めてもう1年になります。
あっという間の1年間でした。
私は技術広報専業のロールをもっているわけではない一介のソフトウェアエンジニアですが、これまで、あの手この手で発信文化を根付かせようと活動をしてきました。
イベントをやってみたり、デブサミに出たり、開発チームのブログを開設したり。
日常の業務をこなしながら、出張費を工面したり、資料を準備したりすることになります。
もちろん他のチームメンバーにもたくさん手助けをもらいました。
この記事は、技術広報チームがないところから、手探りでやってきた赤裸々な記録です。
これから技術広報を始める誰かの背中をそっと押せたらいいな、と思っています。
だから本来、「技術広報」という肩書きの人だけの仕事ではないはずなんですよね。エンジニアも、PdM も、EM も、人事も、広報も、それぞれの立場から担える“概念的な役割”だと感じていて、組織にとっての“筋肉”みたいなものです。
技術広報との出会い
話は2023年に遡ります。
広島のエンジニアコミュニティに育ててもらった私は、新卒就職で上京しました。
引っ越し前にプライベートで予期せぬ出費があり、最初の給料日まで食費にも困るような状況だった私は、昼は副業で作ったジャムの売上で、夜は懇親会のある LT 会で食いつないでいました。
懇親会タダメシおじさんにならないように、せめて登壇しよう……
今思えば、これが「技術広報で(文字通り)メシを食う」初めての経験だったかもしれません。
そこで気になったのが、LT 会に来る若手の所属企業が偏っていたこと。
グループでの参加が多く、私のような一匹狼は少数派でした。
東京にたくさんイベントがあるのは知っていたので、エンジニアなら皆行っているもんだと思っていたのですが、実際のところ同世代に話を聞いてみると、なかなかハードルがあるようでした。
どうして登壇しないの?と聞いてみると、
ネタが思いつかない、発表する価値があるかわからない、他社の人に伝わるかわからない。
そんな不安を教えてくれました。
ひるがえって、自分を育ててくれたコミュニティへの恩返しが発表のモチベーションになっていると気付かされました。
初心者の試行錯誤、ちょっとした Tips、それだけで役に立つということを、コミュニティは教えてくれていたのでした。
巻き込み
会社では IT コミュニティへの露出は積極的でなかったものの、幸いなことに学会での発表やスポンサリングを行っていたので、同じ文脈で業務時間の一部を使って登壇の準備をしたり、定時より早く退勤してイベントに向かったりできました。
参加したイベントの情報や学びを Slack の個人用チャンネルに投稿していたところ、いつしか当時の上司も LT イベントに参加し始め、社外の情報を拾ってくる機会が増えていきました。その上司はのちに初めての LT にも挑戦しています。
その頃私はコードベースの改善に張り付いており、現場の課題を見ながら参加するイベントを選べたのはよかったと思っています。最新の知見を拾ってくる代わりに、レガシーコードをどうやって改善していくかを発表していました。
理想のコードとは何なのか、どうやって安全に移行するのか、丁寧に言語化する訓練になりました。
技術広報は、自分の設計を改めて見直す機会にもなりました。
カンファレンス登壇
発信を続けていくうち、何度か長いセッションに登壇する機会を得ました。事業部メンバーは海外も含めたカンファレンスに登壇することがしばしばあり、それに準じて遠方のカンファレンスにも出張で行くことができたのは幸いでした。
特にフロントエンドカンファレンス北海道2024は印象に残っています。周囲がモダンなフロントエンド技術やブラウザの低レイヤー寄りな話ばかりの中、あくまで堅実に jQuery コードベースを改善する話をしました。
いまさら刺さる人がいるのかが非常に不安でしたが、LINEヤフーさんのブログで取り上げていただき 非常に嬉しかったのを覚えています。
ベトナムで一人、自分のやっていることが正しいのか不安になったとき、過去登壇のハッシュタグを漁って自己肯定感を取り戻したこともありました。
技術広報は、同業の仲間だけでなく未来の自分も助けるのかもしれません。
イベント運営
チーム内で外部登壇・イベント参加者が増えた一方、遠方に住んでいるなど東京のイベントに参加しにくいメンバーにも登壇機会を用意しようということで、自社イベントを開催しました。
トピックの選び方、当日の運営など手探りの状態でスタートしましたが、この点でも少しずつ Web 業界・マーケティング業界に貢献できればとの思いです。
会社のイベントの他に個人のグループも立ち上げて、ボツになったアイデアや実験的なイベントを試してみています。自分でイベントをホストして、業務では触れられない知見が集まるのを楽しんでいます。
ブログへの挑戦
私はもともと長文記事を書くのはそれほど得意ではありません。Qiita のプロフィールを見ていただければわかるように、書きかけのシリーズばかり残っています ![]()
そんな私がブログ最初の記事を書いたのは、LT に限界を感じ始めていたからでした。
もともと自分の市場価値に興味があり、転職意図にかかわらず定期的に履歴書の更新やカジュアル面談をしています。ところが、LT 登壇は何を喋ったかわからないスライドしか残らないため、後で見返したときにポートフォリオに書き起こしにくかったのです。ブログであればゆっくり見返せますし、そのままリンクすることもできます。
もう一つの意図はユーザーの理解です。SEO・コンテンツマーケティングを支援する SaaS を開発している身にとって、実際の Web サイトを使って自分たちが作っている機能をテストすることは、ちょっとした使いづらさを洗い出す貴重なチャンスになりました。
前述したような出張で得たものや学んだことを共有する(そして、次の出張費を出してもらうための)レポートとしての役割も大きいです。
書いたブログは Slack でも共有し、エンジニア以外のメンバーにも読めるようにしています。
ブログが社内で読まれていた
現在の開発ブログはイベントレポートが多く技術記事は少ないため、我々自身も「テックブログ」と銘打つかどうか迷っているくらいのところなのですが、ありがたいことに、だからこそ他部署のメンバーにも読者がいるようです。
以前は「エンジニア組は何をやっているかわからないが、とりあえず大事にしておこう」という距離感を感じていました。セールスレッドな(営業が主導する)組織であることも相まって、プレスリリースが出るような機能開発以外では、なかなか開発チームの存在感を示せる機会が少なかったのが実情です。
セキュリティ、ガバナンス、パフォーマンスを見ている者として、どんな課題意識があって、どうやって課題に立ち向かっているかをなんとなく共有しておくことで、部署間の距離を少しだけ縮められたのかなという気がしています。
なんのための技術広報?
チームで技術広報をやるなら目標設定は必要ですが、ボトムアップで自由にやっているからこそ、セルフブランディングも含めた色々な可能性を見つけられたのだとも思います。
たとえば最初から採用が KPI になっていたら、今のオペレーションにすら到達できていないかもしれません。
表に出ていくいちメンバーとしては、まずはゴールを決めずに気楽にアウトプットすることからでいいのです。考えていること、迷っていることを記録するだけで価値があります。
自分にあったアウトプットの形が見つかれば、それに見合ったゴールがあとからついてきます。
登壇しなければ飢える。
飢えがしのげれば、今度は自分が施す番だとわかるのです。
それが私にとっての技術広報なのでした。
明日は furusin さんの「技術広報はじめの一歩(仮)」です。