企画会議で「来月の技術広報のネタを10本」と言われ、新機能や流行語を並べる。だが大型案件は毎月なく、似た社員紹介ばかりになる。ネタは特別なニュースを待つものではない。設計で比較した案、繰り返す顧客質問、失敗後に変えた手順など、日々の仕事に残る判断から探す。
素材は、誰のどの判断を助けるか、根拠があるか、安全に公開できるか、次の対話へ広がるかで選ぶ。成立しなかった条件や未解決の限界も企画になる。事故や顧客情報をそのまま出さず、公開境界を先に確かめる。
技術広報のネタは、会議より日々の仕事の記録にある
最初の素材庫は開発記録である。設計レビューで比較した二案、負荷試験で崩れた条件、移行時に捨てた選択肢、運用を一行変えた理由。完成した機能だけを見ると結論しか残らないが、読者が知りたいのは自分の状況で何を選ぶかだ。比較軸と制約が残る記録は、その判断を助ける。
二つ目は顧客や利用者の質問である。サポート、営業、イベント、GitHub Issue、コミュニティで同じ質問が三度出るなら、個別回答では届かない読者がいる可能性が高い。GitLabのDeveloper Relationsは、フォーラムやIssue、イベント、ソーシャルで質問や懸念、フィードバックを聞き、社内へ戻す活動を役割に含める。[S1]
三つ目は失敗と変更である。障害だけでなく、採用しなかった技術、計測できなかった仮説、説明しても伝わらなかった用語も含む。GoogleのSRE資料は、非難ではなく学習を目的に事後検証を行い、影響、対応、根本要因、再発防止を記録する文化を説明する。[S4] 公開できる範囲へ一般化すれば、成功自慢より条件が明確な教材になる。
技術広報の始め方で示したように、先に主読者と読後の判断を決める。記録が面白いから出すのではない。採用候補者が仕事の難しさを比べる、利用者が実装を選ぶ、導入担当者が制約を確認するなど、判断場面へ接続できる素材を選ぶ。
開発記録・顧客質問・失敗を、同じ形式で集める
素材を集めるために、新しい長文報告をエンジニアへ課す必要はない。週一回、既存のIssue、設計文書、サポート記録、振り返りから「何を決めたか」「なぜ迷ったか」「誰が困ったか」「何が未解決か」を一行ずつ拾う。元URL、担当者、公開可能性も付ける。編集会議はゼロから発想する場ではなく、この一覧を読む場に変える。
GitLabのコンテンツ依頼手順は、依頼時に事業目的、対象読者、希望する形式、配布経路、期限を確認し、既存コンテンツの再利用も検討する。[S2] 題名から入らず、なぜ必要かを記録する点が重要だ。同社のブログ方針も、チュートリアル、見解、機能、コミュニティ、顧客事例などの型を持ちながら、読者へ価値を提供することを前提にする。[S3]
質問は個人名ではなく、判断の型へ変換する。「A社がこの設定を誤った」ではなく、「複数リージョンで設定を選ぶとき何を確認するか」にする。失敗も、誰が間違えたかではなく、どの前提が成立せず、どんな検知と変更を加えたかへ置き換える。匿名化だけで再識別を防げない場合は、顧客の許諾や公開自体の中止が必要である。
素材には鮮度を付ける。製品仕様、料金、法令、脆弱性、組織体制は変わる。確認日と更新責任者を持てない素材は、公開後に誤情報になりやすい。一方、設計の比較軸や失敗から得た原則は長く使えることがある。速報向けか、継続更新する解説か、時間に依存しない判断記録かを分ける。
素材カードには、仮の見出しより先に証拠の所在を書く。設計文書の版、検証した環境、質問の件数と期間、変更前後の差、取材すべき担当者である。数字がまだないなら「未計測」、原因を特定していないなら「仮説」と書く。企画段階の空欄を隠さないことで、編集者は追加取材が必要か、現時点では公開できないかを判断できる。
企画は四つの問いで選び、公開リスクを先に落とす
第一の問いは、誰のどの判断を助けるか。第二は、自社の一次情報で説明できるか。第三は、顧客情報、個人情報、契約、知的財産、セキュリティ上の危険を除けるか。第四は、公開後の質問が次の文書や製品改善へ戻るかである。四つに答えられなければ、題材を捨てるのではなく、対象を狭めるか追加取材へ戻す。
優先順位は、派手さより頻度と損失で決める。繰り返し聞かれる、誤解すると実装が止まる、社内でも説明が割れる、自社にしかない証拠がある素材を上げる。季節性や製品公開日は期限として扱うが、締切だけで根拠の薄い企画を前へ出さない。GitLabのDeveloper Advocacyも、依頼の目的や影響を見て作業を選別するワークフローを公開している。[S5]
点数を付けるなら、精密な合計より会話の補助にする。たとえば「月に三回以上聞かれる」「誤ると一日以上止まる」「検証データがある」「担当者がレビューできる」を各一段階で確認する。高得点でも公開リスクが解けなければ止め、低得点でも重要な安全情報なら別の公式文書を優先する。スコアは責任判断を代替しない。
公開しない判断も成果である。未修正の脆弱性、顧客を推定できる障害、契約で守るべきデータ、社員個人へ責任が集中する記録は止める。安全に一般化できないなら、社内文書の改善に使う。技術広報は透明性の競争ではなく、読者へ役立つ事実を、関係者を傷つけない形で共有する仕事だ。
一つの素材を、記事以外の形式にも展開する
企画になった素材を、すぐ長文記事に固定しない。手順なら製品文書、短い変更ならリリースノート、問いが分岐するならイベント、再利用する比較なら図解、背景と判断を残すなら記事が向く。一つの元記録から、文書を更新し、その理由を記事で説明し、イベントで質問を集めることもできる。
公開後はPVだけでなく、新しく出た質問、誤解が減った場面、引用された比較軸、修正した文書を素材庫へ戻す。技術広報のKPIで整理した五層のうち、ネタ探しに効くのは最上段の「組織の学習」だ。読者の反応が次の開発記録と質問を増やし、企画が循環する。
反応が集まった題材は、無条件に連載化しない。最初の記事で答えられなかった別の判断があるか、新しい一次情報を出せるかを確かめる。同じ結論を言い換えるだけなら既存記事を更新し、質問が別の読者や条件へ分かれるなら新しい企画にする。この区別が検索意図の重複と、読者が迷う似たページの増加を防ぐ。
最初の一週間は、開発記録を五件、繰り返す質問を五件、失敗後の変更を五件だけ集める。四つの問いで一件を選び、関係者へ30分取材し、公開境界を確認する。15件すべてを出す必要はない。一人の一つの判断を助ける根拠がそろった一件を出し、反応を次の素材へ戻す。
技術広報のネタ切れは、会社に出来事がないことより、仕事の痕跡と読者の問いが離れているときに起きる。設計判断、繰り返す質問、成立しなかった条件を同じ素材庫で見れば、日常業務そのものが一次情報になる。そこから安全性と読者価値を満たす一件を選ぶことが、量を埋める企画会議より強い出発点になる。
Sources / 参考資料
