DevRel として最近考えていたこと GitHubで開く 2026/03/05に公開 開発者体験 DevRel 情報共有 devex idea はじめに 背景
言語化や情報発信が得意な自分の売り方を考えたい、これで食べていきたい
新しい概念つくっても通じなかった → 既存への接続は必須っぽい
何に接続する？ → DevRel や DevEx あたりが良さそう
しかし既存の DevRel では少し足りないと思ったので、自分なりに捉え直すことにした。 この記事について
この記事は、読者が DevRel を捉え直すための刺激を与えるつもりで書いている。あるいはこれで食べていきたい私が誘いをいただく or 今後提示するためのアピールとして書いている。
記事の内容:
❌今現在 DevRel で食べている者が、DevRel について最近考えていることを書く
⭕DevRel という切り口で食べていきたい人が、DevRel とはこういうことじゃね？を整理する
対象読者:
開発者または同等の素養を持つ者。たとえば LT や開発者体験や Markdown といった用語は当たり前に知っているものとする。
上記には当てはまらない、DevRel 従事者。おそらく勉強しながら読むことになる。生成 AI を使っても翻訳・要約しても良いだろう
便宜上、記事の主語は「開発者」と書く。主語がでかいが、あらゆる開発者に当てはまるわけではない。どちらかと言えば、オープンな方や自社プロダクトを持つ方を指すと思う。Zenn の記事を読み書きしたり、GitHub で語ったりする層と言ってもいいかもしれない。 DevRel とは そもそも DevRel とは？
DevRel とは Developer-Relations の略であり、開発者ユーザーとの良好な関係性をつくりましょうというものである。いわゆる B2D(Business to Developer) に含まれる活動だ。
結局は自社の製品と名前をもっと売るための活動であり、従来のマーケティングや広報と同じに思える。なぜ DevRel などと別名をつけて区別しているかというと、開発者という生き物が特殊 だからだろう。 開発者という特殊な生物
いくつか例を挙げる:
コミュニティ活動が旺盛であり、赤の他人でもいきなり発表しにいけるし門戸も開かれていることが多い
LT が盛んで、発表にも慣れていて、人にもよるが飲み会の場で LT するくらい造作もない人も珍しくない。また「もくもく会」という一緒にいながらも黙って作業する過ごし方もよく知られている
開発者は「開発者体験」を大事にしており、「PDF じゃなくて Markdown で共有してくれよ」のような目線は当たり前に持っている
SNS として GitHub が欠かせないことがある
開発者であれば上記はどれも常識だろう。一方で、開発者でない者にはちんぷんかんぷんだし、勉強して理解することも難しい。たとえば Markdown や GitHub を使えるようになるのは困難だろう。また開発者であっても、プライベートでわざわざ使っている人は少ない。その程度には高度で疲れる営みだと思う。
雑に言えば 開発者に特化したソフトスキル が多数あり、開発者という生き物はそれを身に付けた「強化された人間」である。開発は、おそらくこの世で最も思考と手数の多い仕事の一つだ。脳内で処理して人に伝えるものではなく、コンピュータに伝わるよう厳密に書かねばならない世界だからだ。それゆえ手段には徹底的にこだわらねばならず、効率や集中にもうるさくなるし、信念も強化される。
一般人とは生態が違うのである。B2D では、このような生物を相手にしなきゃいけないが、無論素人に務まるものではない。たとえば従来のマーケティングや広報が得意な者であっても歯が立たないし、キャッチアップもおそらくできまい。
※唯一の例外は巨大な企業や製品であり、巨大でユーザー数も多いゆえに非開発者ユーザーの比重が重いため、普通のマーケティングや広報 +αで済む。特殊な生物を相手にする必要は、実はあまりない。ただしその前段では、開発者を相手にしていて上手く行っていたりもする。むしろそこで成功したからこそ巨大になれている 外部の DevRel、内部の DevRel
DevRel が持つニュアンスは「自社の外の開発者ユーザー」だと思う。これを私は 外部の DevRel と呼んでいる。
あえてそう呼んだのは、もちろん 内部の DevRel もあると思うから。つまり「自社の開発者」だ。たとえば、ある程度組織が大きくなってくると、自社の開発者向けのサービスを提供する役割が出てくるだろう。まさに Platform Engineering というジャンルもあるし、IT ベンチャーの話でも「従業員を顧客とみなして丁寧に接する」的な金言を抱く人は多い印象がある。
私は、このあたりを概念化するべきだと考えた。開発者という特殊な生き物は自社の外にいるだけではない。 自社の内部にもいる。というより、製品をつくっているのもまさに開発者であり、特殊な生き物なのだ。ならば外部の DevRel と同様、特殊な活動として位置づけた方が良いはずだ。 DevRel の 3C
DevRel が持つもう一つのニュアンスは「コミュニティ活動」だと思う。私はそうは思ってなくて、以下の 3C で整理している:
コンテンツ
コミュニティ
コントリビューション（Contribution）
図示すると以下:
Contents –+–> Community | +–> Contribution
コンテンツという源泉があって、これを届ける方法が二つある。
一つ目、コミュニティはすでに読者が想像したもので大差ない。Discord サーバーとして提供されているようなオンライン型もあれば、イベントに申し込んで参加するオフライン型もある。同じコミュニティでもオープンなものもあれば、クローズドなものもある。一見するとオープンだが、事実上参加者を選んでいる形態もありうる（特に to B）。また人気があると抽選の概念も出てくる。
コミュニティ論は割愛するが、コミュニティは居場所または権威を示すための舞台としての機能があり、運用の仕方はどの業種であっても大差はない。開発者向けであってもだ。扱う内容と訪れる客の傾向が違うだけで、単純化すれば人間の原始的な欲求を満たせればいい。エンタメと言い換えることもできる。したがって、コミュニティを用いた DevRel であれば、開発を知らない者であっても務まる。
※エバンジェリストなど製品の顔となる場合は、深い製品知識と周辺知識も要るため開発経験者でないと厳しいと思う。
本記事でフォーカスしたいのは二つ目、コントリビューションの方だ。直訳すると「貢献」だが、ここでは有用なコンテンツをオープンに提供して、実際に使ってもらえることと定義したい。たとえばオープンソースでソフトウェアやドキュメントを提供したり、気合を入れてつくったレポートを無償で公開したりといったことが該当する。
オープンと書いているように、誰でもいつでもアクセス可能でなければならない。もちろん無償で、だ。ペイウォールや会員登録などもってのほかである。インターネット文化を知る者ならごく当たり前の思想だろう。広く公開して、広く使ってもらった方が世の中全体で見たときに貢献を最大化できる。ソフトウェア自体がそうやって発展してきた。
さて、このコントリビューション活動を専任で行う DevRel ポジションを想像できるだろうか。少なくとも現時点では存在しないと思う。しかし私が DevRel として強調したいのはここなのだ。
DevRel にはコミュニティだけではなくコントリビューションという軸がある はずだ。無論、そのためにはコンテンツが必要であり、したがって コンテンツを持続的につくる仕組みや文化の整備 も重要なはず。
DevRel をこのように拡張することで、コミュニティしか知らない前時代の DevRel を超えた価値を出せると信じている。 開発者体験の重要性
開発者が特に重要視するのが 開発者体験（Developer Experience） だろう。
この言葉は現状「プロジェクト」くらいに定義が揺れる多義語だが、私は 開発者が抱く気持ち良さ くらいに捉えている。気持ち良いことよりも、気持ち悪いことを避けるために使う。ストレスと言い換えてもいい。
開発者体験の悪い例をいくつか挙げてみよう:
コミュニケーションツールがチャットしかなくてやりづらい、特に後から情報を探せない
個別チャットで内密にやろうとする。皆が見えるところで書かない。書かないから後で辿れない
PC のスペックがしょぼくて重い
オフィスのデスクが狭い、椅子の座り心地が悪い
オフィスが賑やかすぎて集中しづらいし、ヘッドホンの使用も認められてない
リーダーやマネージャーや経営陣がランダムに話しかけてくる
リモートでいいのになぜか出社させてくる
ドキュメントをリッチテキストでつくらされる、また社内ドキュメントもリッチテキストばかりで読みづらい
新しいツールを使うのにいちいち申請が要るし、定期更新やエクセルへの記入もうざい
冗談抜きで開発者は一般人の何倍、何十倍、下手すると何百倍という手数をこなしている。大量に読むし、書きもする。コンピュータまたはコンピュータを扱う人間が相手なので、ただの人間相手に非言語や曖昧な情報では済まない。生成 AI を使ってる人はよくわかってると思うが、論理的にしっかり読み書きしないといけないのが当たり前の世界なのだ。
こんな世界では、1秒や1回の手間さえも塵積（ちりつも）になって、多大なストレスになる。また開発者はそれぞれ自分なりの最適な仕事の仕方も開拓している。これを削がれても強いストレスになる。仕事にも支障が生じるし、衝突や退職の理由くらいにはなる。こんな世界で日々改善と共有が行われているし、デジタルなので試行錯誤のペースも早い（建築や人間みたいに物理的な制約がないため）。結果として 仕事の仕方の水準も上がりまくっている。
例としてチャットを挙げよう。コミュニケーションツールにしても、Slack や Teams といったチャットしか使えてないのが多数派だと思うが、こんなものはごく一つにすぎない。私は QWINCS（Q&A, ウィキ, Issues, Notes, チャット, Miroなどのボード）と整理しているが、他にも主要ツールが 5 つあるし、開発者なら全部使いこなせる or 使いこなせるようになれる。「チャットを使わず仕事を成立させること」もイメージできるだろう。チャットにすら苦戦する一般人とは練度が違うのである。
水準が上がっているということは、それだけ気にするポイントも多いことを意味する。このあたりのストレスの少なさ、快適性の度合いを述べたのが開発者体験だと私は思っている。こういった開発者の機微を理解し、少しでもストレスを取り除いていくことで開発者体験は上がる。お金で解決し、技術と仕組みで解決し、価値観が対立する場合はどちらかに寄せて Disagree and Commit をさせる必要もあるかもしれない。
と、これでようやく結論を言えるようになった。
開発者体験を意識した提供ができないと、開発者には相手にされづらい 可能性が高い。DevRel も例外ではないと思う。 取り組み例
ここからは私が DevRel として、どのように取り組んでいきたいかを述べる。まず状況を述べた後、どんなことをやっていくかを雑多に述べていく。 状況
架空の状況を設定したい。
「セキュリティ」で食べている B2D 企業があって、私が DevRel の専任者になったとしよう。セキュリティを選んだ深い理由はなく、単に近年触れることが多かったからだ（以前 SBOM の本を書いたりもした）。
B2D なので顧客は開発者である。開発者の定義は広く、どう定義するかも DevRel の責務になるが、仮に開発者であれば GitHub は常用しているはずだとすると「GitHub を常用する者」すべてが顧客だと言える。
開発者である以上、セキュリティは避けては通れない。すでにセキュアな実装を早期から実施するプロセス（シフトレフト）を組み込んだり、脆弱性をチェックしたり、セキュリティのプロに診断を依頼したり、あるいは自分たちで外部レポートを読んで勉強しているかもしれない。
セキュリティは直接価値を生み出すわけではない。むしろ価値を損ねる脅威から守るために投資しておくものだ。単純化すれば、泥棒にどれだけ備えるかにも等しい。何もしなければお金もかからないが、被害に遭いやすい。堅牢にすれば被害には遭いづらいだろうが、お金もかかるし普段の出入りも面倒になる。加えて、この分野も専門的であるため、素人の自分達で何とかできるとは限らない。そこで専門家にお願いしよう、相談しようとなる。
セキュリティ x B2D のビジネス戦略も同じだ。鍵屋さんなのか、盗聴や盗撮を検出するのか、あるいは地域ごとの治安をデータとして持っていて「治安が良い地域」を費用とのバランスを踏まえて提案するのか、それともお金持ち向けに堅牢で住宅を高値で提供するのか。顧客層も持ち家の個人、アパートやマンションの管理人、オフィスビルの管理者など幅広い。どこに対して、何で勝負するかは色々考えられる。
まとめよう:
セキュリティで食べている B2D 企業
私は DevRel として参加し、戦略含めてリードする専任者である
B2D なので開発者が顧客だが、その「開発者」も幅広い
セキュリティ:
直接価値を生み出すわけではなく、脅威から守るために備えるもの
またどこで何をするかも幅広い
顧客目線では、素人の自分達でやるには限度があるか面倒なので、専門家にお願いしたい
方針: コンテンツとコントリビューションに専念する
私の向き不向きの話だが、3C でいうとコンテンツとコントリビューションに注力したい。コミュニティはやらないか、やるにしても別の専任者を立ててもらう。
なぜコンテンツとコントリビューションに専念したいか:
1: DevRel としてお届けするものは「コンテンツ」であり、これを良質に、かつ持続的につくれないと始まらないから。あるいは始まっても続かないから
2: インターネットやオープンソースなど、開発の界隈にはすでにコントリビューションの文化が根付いており、ここに刺さない理由がないから
3: この二つができたら、残るコミュニティその他マーケティングや広報はどうとでもなるから
3 は難しくない。いや、難しいが、事例も手法も確立されていて、どうとでもなる。
問題は 1 と 2 である。
状況でも述べたとおり、セキュリティ x B2D なので「開発者」に「セキュリティ」を売るわけだが、ここがそもそも難しい。セキュリティはニッチな分野であり小難しいし、ジャンルも備えでしかなくて開発者の食指は動かない。そもそも専門家にお願いしたいくらいなのだ。セキュリティは、開発者にとっては難しい上に興味もないもの、でもやらないといけないから仕方なくやってもらいたいものでしかない。
こんな開発者に対して、一体どうやってセキュリティを売り込んでいけばいいのだろうか。「開発者」の解像度を上げ、それに刺さるコンテンツをつくり続けないといけない。無論、開発者の目線は持たねばならないため、開発者を理解できない素人には歯が立たない。その辺のディレクターではスタートラインにも立てないだろう。
ここで私が目をつけているのがコントリビューションである。
コントリビューションの例を少し挙げよう:
開発者であれば、リファレンス的なドキュメントを何度も読んでいると思う。ウェブサイトとして提供されたり、GitHub リポジトリで Markdown として置かれていたり、そこから静的ウェブサイトをつくっているケースも多い。Star が 1 万以上ついたドキュメントリポジトリもある
生成 AI でいうと「プロンプトエンジニアリング」や「12 Factor Agents」といった概念がある。開発者らが探究してきたナレッジを上手く整理して、お届けすることで、界隈全体が共通言語を手に入れることができる
もちろんオープンソースなソフトウェアを公開することもできる。いつでも誰でも使えるし、内部構造を見れるし、自分で改造することもできる。その代わりに責任は負わない。そこで、責任を負いたくない開発者や、もっと気軽に使いたい開発者のために、プロフェッショナルサービスを別途用意して、こっちで稼ぐというのは鉄板の戦略である
これらはコンテンツをコントリビューションとして提供している好例だ。
開発を知らない者からすると、無償で惜しみなくばらまいているようにしか見えない。しかし、文化的に、このやり方なら比較的「使ってもらいやすい」し、公開されてるので言及や拡散もしやすい。
開発者は手を動かす生き物でもあり「使えるかどうか」は重要だ。エンタメや評論だけでは足りないし、むしろノイズすらあって相手にされないことも多い。実際に使えるコンテンツをつくらねばならない。もちろん、先で述べた開発者体験も踏まえた方がいい。わかりやすいところで言えば、レポートを公開したい場合は PDF よりも Markdown がいいし、Markdown だけでなく静的ウェブサイトもあった方がいい。
――と、開発者であれば「何を当たり前のことを」思われるかもしれない。しかし、DevRel として、これを戦略的に専任して行うという視座は現時点でまだないと思う。もちろん、こんなマニアックな世界観は非開発者には理解できないし、理解できても行動できないと思う。
だからこそ私なのだ。私は開発者であり、コンテンツとコントリビューションも知っている。開発者は技術とタスクが好きで、コンテンツとコントリビューションという「技術的な取り組みには関係のない活動」や「自然言語など言語化を伴う国語的な営み」は好まないが、私はこれらを好む変わり者なのである。そんな私だからこそ推進していけるはずだ。 方針: コンテンツを持続的につくる仕組みと文化をつくる
コンテンツは開発者向けセキュリティに関するものとなるが、これをつくれるのは当社のエンジニアたち自身だ。
私もセキュリティに関しては素人に近いので、今さら勉強したところで皆さんに追いつくはずもない。そもそも私ひとりの発信では量も視点も限度がある。皆さん自身にコンテンツをつくってもらわねばならない。
もちろん、皆さんも日頃の業務が忙しいはずだ。特にセキュリティは診断やコンサルなど時間売りなので、物理的に時間がない。そんなみなさんでも持続的にコンテンツをつくってもらわねばならず、そのための仕組みや文化をつくっていかねばならない。内部の DevRel と書いたが、私にとっては皆さんも開発者（とは限らず「技術者」と呼ぶのが正確か）であり、顧客なのである。みなさんにコンテンツを書いていただくには？を考えていかねばならない。
大まかな方向性は決まっていて、以下のいずれかだ:
1: 楽しさ。コンテンツづくりが楽しいからやる
2: 成長。コンテンツづくりによって強くなれるからやる
3: 報酬。給与やキャリアにつながるからやる
単純な例として、コンテンツとしてブログがあるとする。当社のセキュリティエンジニアたちが、セキュリティネタを、開発者向けに書いていくのである。
一番わかりやすいのは 3 の報酬だろう。ブログの記事数や PV を KPI にしたり、ランキングやボーダーを設定して給料や昇進に紐づければいい。
外部からの観察だが、たぶん AWS で有名なクラスメソッドはこれじゃなかろうか。だが、同じ戦略を取れるとは限らない。クラメソが AWS ネタの記事を素早く大量に出せるのは、AWS というプラットフォームがあるからだ。AWS は支配的な存在であり、開発者はその決定や仕様に従うしかない。となれば、いち早く動向と詳細を知れることに価値があり、だからこそ、いち早くキャッチアップして、それを日本向けにわかりやすく提供することが価値になる。一方、セキュリティというジャンルでは、同じ構図が生じている部分はないだろう。
次にわかりやすいのが 2 の成長だろうか。開発者（というよりもう少し広い技術者全般に当てはまるかも）の性質して、成長に対して貪欲な点があげられる。プライベートでも平気で勉強したり、飲み会でも開発の話で盛り上がるようなオタクな生物である。自覚がないことも多いようだが、知識や経験といった成長は常に意識しているし、それが感じられないだけで転職の動機になる。
したがって、コンテンツづくりが成長になることがわかれば、積極的に取り組んでもらえるはずである。私なら生成 AI に絡めるだろう。生成 AI のスキルは言語化スキルであり、一応自然言語ではあるものの、人間向けの内容でもなければプログラミングその他言語とも違った書き方になる。プロンプトエンジニアリングなる体系もすでにできて久しい。コンテンツづくりは、これを鍛えるのに役に立つ。役に立つということを示せれば、その気になってもらえると思う。示すためのコンテンツを私自身がつくって、会話や発表も含む多様な方法で届けて、フィードバックも受け付けるようにして気兼ねなく意見を出してもらったりするかな。そうして皆さんのやる気を焚き付けてみせよう。
最後に、もっともわかりにくいが 1 の楽しさだろうか。
コンテンツづくりは楽しい。開発者はドキュメントを書くのが嫌いな人が多いイメージだが、その主因は開発者体験が悪いからだと思っている。私が解消してみせる。
たとえば:
チャットしか知らない人と、ウィキやノートや Issues も知っている人とでは、コンテンツづくりとしてできることの幅が違う
ブロガーや作家は、テキストを書くための投資と修練を相当しており、そのおかげで快適で楽しい体験を入手できるわけだが、開発者はこれを知らない事が多い。私は知っているので示せるし、教えられる
議論というと、打ち合わせの形で口頭でやるものと思いがちだが、それだけじゃない。読み書きで、非同期でも行えるし、それでも楽しい。たとえば Cosense を使えば可能だし、私は 書籍を書けるほど 詳しいためリードもできる
作家は創作論、開発者も開発論なるものを持っているはずだ。通常それらは飲み会の場で発散されるが、それを仕事の一環で、とことんできるとしたら？私ならその環境を用意できる。必要ならフォーマットやプロセスもつくってみせるし、ファーストペンギンとしてネタを散らかして「ほらほら、色々言いたくなってきただろう？」と刺激することもできる
無論、それでも向き不向きはやっぱりあるが、それでもある程度の支持は得られると信じている。別に白黒ではない。書くのは好きじゃないが、たまに（まれに）なら書いてもいいという人もいるし、対面の場でなら喋れるという人がいるなら喋ってもらってその文字起こしを書いて残せばいい。このあたりの多様性は吸収していける。 方針: テックブログは重視しない
コンテンツ寄りの DevRel というと、真っ先にテックブログを思い浮かべると思う。またすでに実践されている組織も多い。王道ということは、それだけ確かな効果があるということだが、私はあまり重視したいとは思わない。インプレッションを増やす一手段として、淡々とやる程度にしたい。
理由は単純で、セキュリティ x B2D との相性が悪いからだ。テックブログもまたブログであり、ブログは本質的にカジュアルなエンタメコンテンツである。そしてすでに述べたとおり、セキュリティは開発者にとっては「難しい上に興味を持てないもの」である。AWS のような支配的構図と圧倒的利用者数もない。つまり ブログでスケールできる段階ではない。だからこそ、まずは段階を引き上げるための他の活動、もっというとコントリビューションを重視したいのである。
とはいえ、王道である程度のインプレッションが得られるのは事実なので、やらないとも言わない。あまり時間をかけず、コンスタントに提供できればそれでいい。戦略と仕組みとディレクションをすればいい。
戦略には正解は無いので適切に決めればいい。たとえば:
他の DevRel やテックブログ事例を調べたり、当社の顧客ボリュームも踏まえたりして、仮に年 10 万 PV （月 8000 PV）あれば優秀っぽいとわかったとして、とりあえずこれを KPI に置くとか
目的を「LP への誘導」と割り切り、テックブログ活動の前後で訪問者のアクションがどう変化したかを計測するとか
記事品質を「会社として統一させるのか」、それとも「執筆者の個性をある程度許容するか」のどちらに倒すのかを決めるとか
あるいは両方やってもいい。何もテックブログが一つでなければならない理由はない
仕組みについては、記事を実際に書くことになる当社のセキュリティエンジニア向けの開発者体験をよくするという話である。たとえば:
社内の Notion や Confluence といった書きづらい手段で下書きを書いてもらうのではなく、Markdown で書いて GitHub にアップしてもらう運用にする
記事レビューのために会議するのはうっとうしいので、非同期でコメントを出し合って済むようにする。迷わないようやり方や手段は整備し、必要なら教育もする
生成 AI を用いたレビューの仕組みをつくって、各自気軽に使えるようにする。あるいは自動でレビューできるようにする
ただし AI の結果を読み直して振り返る自律性が要るので、相性次第で合わないかもしれない。そうでなくともおそらく本業で忙しいので、あまり自分から使う・結果を読むという行動はおそらくしない。様子見やテコ入れは十中八九要ると思う
文体で迷うなら架空のキャラクターをつくって、それになりきる形で書いてもらう（どちらかと言えば戦略の話だが、キャラクターが決まれば変換など仕組み化もできる）
締切がないと書けない人が多いなら、週に1本、のようなノルマを決めた上で担当者も決めて頑張ってもらう運用にする
このとき担当者の業務は一部免除するべきである。コンテンツづくりや発信を片手間でやらせるパターンは多いが、 重要な活動なのだかられっきとした業務として扱うべきである。つまり投資しろというわけだ。意思決定層にこの点に理解してもらうのは、DevRel としての仕事の一つになる
レビューについては、方針で「執筆者の個性を出す」とした場合の話だが、ティール組織の助言プロセスが使えるかもしれない
これは「助言を請うこと自体は必須」だが「助言に従う義務はない」というものである
意思決定者は執筆者本人であり、本人が好きにすればいい
ただし暴走を防ぐために助言自体は請うことにする
助言を取り入れるか、どこまで取り入れるかは本人の自由
こうすればレビュアーがボトルネックになりにくい
絶対に修正するべきクリティカルな指摘（機密情報や差別的な表現がありますよ等）を数の力でカバーするために、誰でもいつでも下書きを見れるようにする
指摘に対するインセンティブ（報酬や称賛）もあるといい
あるいは会社のブランドを守るために皆で貢献しよう、といった思想を啓蒙してもいい
最後にディレクションについては、一言で言えば執筆者のお尻を叩くということである。
戦略に則り、仕組みをクリアできる程度のクオリティの記事を書くまでお尻を叩く。機械的なリマインドで済む人もいれば、会議を設定して拘束しないとやらない人もいるかもしれない。編集者がマンガを世話するシーンは思い浮かべやすいと思うが、まさに同じだ。人によって何をすればいいかが違うので、人の数だけ対応しなければならない。この点は私の苦手分野なので、カバーしてほしいところではある。 方針: 英語コンテンツも書く
セキュリティ x B2D の国内ボリュームはおそらく小さいため、海外を狙っていきたい。
特に（後述するが）GitHub 上でコンテンツを展開する場合、英語圏も含めるかどうかで利用者数は 10 倍や 100 倍も変わってくる。国内の界隈で流行っても 500 star もつかないところを、英語圏を含めれば 10000 star に至る、くらいに違いがあると思う。
社内で評価されないとき、社外で評価してもらった実績を持ち込んで「ほらね、私は優秀でしょう？」と認めさせる手法があるが、これと同じで、国内であまり相手にされてなくとも、海外で評価されれば国内に持ち込んで拡大できる。そういうチャンスも狙っていきたいと思う。
迷っているのはアプローチで、もっというと生成 AI による翻訳で済ませるかどうかだ。一般的な感覚だと品質や礼儀の観点でダメだと思いがちだろう。私はそうとも思えない。というのも、開発者はもっとドライであり、有用なコンテンツであれば翻訳が多少不自然なくらいは許容できる可能性が高いからだ。読者の実体験でも、多少翻訳が怪しい日本語でも有用なら使った経験があるかと思う。あるいは翻訳または自力による拙い英文でも通じた経験があると思う。そもそも現時点で生成 AI の力でシームレスに翻訳できる段階にあり、ブラウザ拡張機能としてその場で翻訳するツールや拡張機能はあるし、つくることもできる。言語の壁は薄くなっているのだ。
そういうわけで、個人的には翻訳でも行ける感覚があるのだが、じゃあやってみようと言えるほどの確証はまだない。特に思わぬ落とし穴に警戒している。少なくとも英語圏の開発者に詳しい者も交えた議論は必須だろう。それができない場合は、そういう人材を取ってこないといけないかもしれない。 ネタ: ウィキを公開する
Cosense を使うと情報収集や議論の様子を濃密に公開できる。
既存の例:
LayerX Research
Chatwork WebFrontend のチラ裏
ウィキのコンテンツ力は、Wikipedia やゲーム攻略ウィキなどですでにご存知かと思う。そして Cosense は開発者目線でも開発者体験の良い現代的なウィキである。ブログよりも圧倒的に書きやすいし、SEO にもひっかかって検索流入も期待できる。
これ単体で広報を担えるものではないし、むしろニッチなコンテンツになるが、それでも知る人ぞ知るコンテンツとして濃いファンを獲得できる余地がある。一方で、マニアックなコンテンツばかりあっても読まれないのは目に見えているため、コンテンツの方向性を（開発者が読んでわかるものに）寄せる必要はある。私もまだ全然見えてないので膨らませていきたい。 ネタ: 教科書をつくる
セキュリティに関する何らかの体系をつくり、GitHub と静的サイトで共有したい。そうすると多くの開発者にとってリファレンスとなるはずだし、界隈が薄々取り組んできた諸々を上手く捉えられたら、共通言語として一気に定着する可能性もある。
当社のセキュリティエンジニアとここまでの実績次第だが、もし界隈で知られるほど実力が高いのであれば、体系化できるだけのネタは持っているはずである。あとは、それを言語化して構造化して公開するだけだ。そのノウハウは私が持っている。
以前私は SBOM に関する本を書き、その中で DevPst という概念を提唱した。DevOps のノリで、Dev と PSIRT を持ってきたものだ。私はこのようにゼロイチをつくれる。目次などさらに詳細化してもいい。これを皆さんが叩けばいいのである。
私はクリエイティブシンキングと呼んでいるが、発散と収束の繰り返しによってコンテンツをつくりあげていく営みをする。ブレストや KJ 法がわかりやすい。これをみんなでやる。DevPst というのは例にすぎず、他にも色んな体系をつくれる余地があるはずだ。
Google が提唱した SRE は、今やポジションとして定着しているが、これと同じものをつくれたとしたらどうだろう？製品開発チームの一ポジションという文脈だから、そうだな、プロダクト・セキュリティ・エンジニアリングなる体系を整理した上で、その専任者をプロダクト・セキュリティ・エンジニアを定義する。Product Security Engineer、略称は PSE だ。つまり PSE の体系を、教科書をつくってみせるわけである。試しにこのワードで検索したところ、言葉自体はあちこちで使われているようだが、体系レベルの情報はまだなさそうだ。先手を取って、GitHub で広めてしまえば界隈の「顔」になれると思う。 ネタ: その他 GitHub で公開できる有益なコンテンツをつくる
たとえば awesome security list のような awesome list をつくって公開して、オープンに世界中のみんなでメンテしていくといったこともできる。
調べてみたら、もうあるみたい: sbilly/awesome-security: A collection of awesome software, libraries, documents, books, resources and cools stuffs about security.
もう少し踏み込む必要があるだろう。上述した SBOM やプロダクトセキュリティエンジニアリングなど。私も正直全然見えていないので、情報集めと議論を進めていきたい。
他にも、ama（Ask Me Anything）をもじって aua（Ask Us Anything）リポジトリをつくり、開発者の皆さん、誰でも何でも聞きたいことを聞いて下さい、としても面白いかもしれない。この手の「何でも相談」は対面イベントとしてクローズドに設計されがちだが、開発者はオープンが好きだ。ただでさえクローズドになりがちなセキュリティのジャンルで、オープンな aua を行えば、それだけで注目の的になる。無論、集まった回答にちゃんと応えていかなければならず、その体制や仕組みは私が先導してつくっていかねばならない。 ネタ: データベースを抱える
SBOM の調査啓蒙の仕事をしていて思ったのは、データベースが重要だということだ。たとえば脆弱性を調べるには以下が必要である:
1: 調べたい製品
2: 1の構成物（何のライブラリを使っているか等）
3: 脆弱性情報（製品 P が弱点 V を持っている）
この前提で、構成物の中に製品 P が含まれているかどうかを調べるのである。その際、照合の仕方が問題になる。「2 の一覧で使われている名前」と「3 の名前」が表記上一致するとは限らない。「Vue.js 3.5」と「vuejs-core(3.5)」かもしれないのである。人間の目視なら同じだとわかるが、プログラムでは判別できない。生成 AI に頼ってもいいが、生成 AI は統計処理であり本質的に正確でない。
今のところ、この表記ゆれ問題を確実にカバーできる唯一の方法は、表記が揺れない統一的な情報をデータベースとして管理して、それを使って照合することだと思う。つまりデータベースを自社で持って、メンテナンスしていくことだ。
脆弱性に限らず、セキュリティは本質的にはこのような「対象」に「問題点」がないかをチェックする構図になりがちである。ということは、「対象」や「問題点」をデータとして持っておくことが価値になる。そうでなくとも、近年の生成 AI ブームには抗えず、生成 AI ベースのセキュリティ製品または機能をつくるケースは多いと思うが、ここでもほぼ確実に何らかのナレッジを保持するデータベースをつくるはず。
少し前に AWS とクラメソの話をしたが、セキュリティではまだ AWS のようなプラットフォームがないと思う。この座を取れれば覇権を取れると思う。データベースは、その初手として重要になる気がするのだ。
……と、素人 +αの自分ではこの程度しか提示できないし、DevRel からも離れているが、こういう議論も皆さんとしていきたい。これもまた「コンテンツづくりの楽しさ」の一環になると思う。仮にデータベースを抱えることに価値があるとわかったのなら、データベースもまたコンテンツとして公開することで DevRel に持ち込める。 ネタ: セキュリティ競技のエンタメ化
CTF などセキュリティを題材とした競技はすでにある。以下は生成 AI に尋ねてみたもの。競技というより演習が色々あるみたい:
CTF：用意された問題を解き、攻撃・解析の手順や発想を競う競技。突破や攻略のスキルを集中的に鍛えやすい。
ハードニング：脆弱なシステムを受け取り、止めずに守れるよう堅牢化と運用で耐える競技／演習。防御設定・監視・対応まで含めた現場力が問われる。
情報危機管理コンテスト（ICC）：インシデント発生時に、状況整理と意思決定（連絡・公表・復旧など）を競う。技術だけでなく組織対応の力が中心。
バグバウンティ：実在サービスの脆弱性を見つけて報告し、評価に応じ報奨を得る仕組み。再現手順や影響説明など報告品質が重要。
レッドチーム演習／パープルチーム：攻撃側の手法で組織の検知・対応能力を検証する演習。目的は勝敗より改善で、攻防の協調（パープル）も重視。
BCP/DR・テーブルトップ等の演習：障害や侵害を想定し、事業継続（BCP）や復旧（DR）の判断手順を訓練する。技術面に加え体制・連絡・優先順位が中心。
セキュリティという「難しい上に興味を持ちづらい題材」を開発者に売り込むために、私はエンタメ化を推し進めたいと思っている。以下にヒントを示す:
将棋
AI により戦局を数値化できるようになり、実力者でなくとも状況がわかりやすい
また棋士の顔が常に映っているので面白い
将棋のマンガやラノベも普及に一役買っている
BEMANI PRO LEAGUE - YouTube
KONAMI の音ゲー競技（DDR、ボルテ、弐寺）で、リーグ戦をライブ配信している
プレイヤーでなくても音ゲー経験者であれば楽しめると思うし、私もこの 3 つは未経験だが楽しめている
何らかの競技を確立し、開発者なら楽しめる程度に理解できるようにし、競技者の顔が見えるようにして、実況もつけることでエンタメ化する。ここまでできたら、国内だけでも同時視聴者数 5000 人くらいのボリュームは出せるんじゃないかと思う。
問題はその「競技」がまだ見えてないところだが、ここは皆さんと議論や試行をして詰めていきたい。DevRel として私がアイデアをリードして、それを皆さんに揉んでもらうのが良いだろう。あるいは私よりエンタメに詳しいエンジニアがいたら、その人にリードしてもらった方がいいかも。たぶんエンタメやゲーム、その他対戦的な営みに詳しい人が何人かいる気がするので、巻き込んでいきたいし、創意工夫を引き出したい。
肩肘張らず、どうしたら楽しくなるかを純粋に探究したい。つくった競技は自分たち自らで遊んでみるのが良いのかも。自分たちで遊んでて楽しいものを外に出していくアプローチ（ドッグフーディング）だ。
ここで具体的なアイデアを出せたらいいのだが、私にまだ知見がなくて出せない。まずはキャッチアップしていきたい。私は CTF すら経験したことがないのだ。しかし、CTF 程度ではエンタメ化は遠いとも思っている。内容が専門的すぎて難しいからだ。XSS を知らないか、勉強したことはあるけどもう忘れてる程度の開発者でも楽しめるくらいに、わかりやすく、しかし競技としても成立するほど奥深いものをつくらねばならないと思っている。
ターゲットについても、今は開発者を想定しているが、非開発者もアリかもしれない。ソフトウェア開発、セキュリティ、コンピュータといったテクノロジーまわりは、一般人には「ハッカーがなんかカタカタしてるやつ」だ。認知はされているし、競技化されたら注目を引けると思う。見せ方次第で楽しめる余地もある気がする。 ネタ: セキュリティエンジニアを題材としたマンガまたはラノベ
IT エンジニアリングを題材とした作品は、ありそうで意外とない。私が知っているのは「なれる!SE」や「ブラッディ・マンデイ」くらいか。なおドラマと映画は趣味外なのでさっぱりわからない。
DevRel の切り口として「エンタメ」があり、前項でも競技の話をしたが、もう一つ、私はフィクション作品も追求したい。マンガまたはラノベと書いたのは意図的で、開発者の興味との親和性を考えてのことだ。別の言い方をすると、ドラマや映画ほど一般受けを狙うつもりは今はない。一般受けはマンガやラノベで上手くいってからでも遅くないと思う。
別に商業作品として展開する必然性はない。むしろ GitHub でオープンに公開するなど、開発者向けの DevRel として開発者体験を大事にしたいと思う。
一方で、エンタメ作品は、開発者といえど仕事モードで見るとは限らないし、むしろ私生活モードで見るから、コントリビューションは置いといて、単に従来の戦略（SNS でのチラ見せや小説投稿サイトやマンガアプリなどでの配信）が良いかもしれない。だとすると、投稿サイトやアプリ配信元などの企業と提携するのが良いのだろうか。最初に思いつくのは開発者にはお馴染みはてなが擁するカクヨムで、セキュリティエンジニア向けのラノベをカクヨムで連載しようといったことをすればいいのだろうか。
最も重要なのは作品をつくれる作家の確保とディレクションだろう。当社としては作家にセキュリティに関する情報をインプットし、作品はもちろん作家に書いてもらう。必要ならわかりやすさに寄せる必要もある。いずれにせよ濃い議論は避けられないと思う。私がすぐに思いつくのは、SF プロトタイピングの知見を使って議論や作品コンセプトづくりに協力することだ。 おわりに
本記事では DevRel に対する私の思い――特に開発者に寄り添うために、コミュニティではなくコンテンツとコントリビューションに力を入れる考え方を述べた。その後、セキュリティ x B2D を例にして何をやれそうかを考えてみた。参考や刺激になれば幸い。
この DevRel の考え方や取り組みを、以下の立場に説明する形で論じなさい。
あなたが普段やっている DevRel（イベント、登壇、コミュニティ運営、SNS、導入支援、案件化導線づくり）は、DevRel の主要な勝ち筋であり続けます。その前提を崩さずに、この文章が提示しているのは「DevRel を コミュニティ中心 と見なす解釈の偏り」への異議申し立てです。
この整理は、コミュニティ活動を否定するのではなく、「コミュニティをやれば DevRel」という単純化から DevRel を解放します。結果として、あなたが担っている DevRel の一部は「Community 側」、別の一部は「Contribution 側」に分解され、チーム設計・採用設計・評価設計がやりやすくなります。
この文章の強い主張は「開発者は社外だけでなく社内にもいる。社内開発者も特殊で、彼らに対する DevRel が必要」という点です。
既存 DevRel の現場感だと、次の壁にぶつかりがちです。
ここを「内部 DevRel」として役割化し、社内のコンテンツ生産能力を上げる仕組み（プロセス/ツール/評価/文化）を DevRel の範囲に含めると、外部アウトカムが再現可能になります。
コミュニティの場当たり感・属人感を減らし、DevRel を“生産システム”に寄せる方向性です。
「開発者に相手にされるか」は、メッセージ以前に体験で決まることが多い。これは DevRel の現場でも身に覚えがあるはずです。
こうした “体験の悪さ” は、コミュニティの熱量や登壇の上手さで覆せないことがあります。
したがって、この文章が言う 「コンテンツを Contribution の形で、DevEx を意識して提供する」は、DevRel をマーケに寄せすぎたときに失われがちな「開発者への礼儀」を、戦略として再導入する提案です。
結論から言うと、この文章は「コンテンツ特化 DevRel」を “記事を書く人”ではなく、“コンテンツ供給網を設計する人”として定義し直しています。ベンチャーが欲しいのはたぶん後者です。
ベンチャーにとって一番重要なのは、施策がスケールすること・採用できること・再現できることです。ここでの提案は、単に記事を増やすのではなく、
という順序になっています。これは、特にベンチャーの「人的リソース不足」に対して合理的です。
コミュニティ運営は人手が溶けやすい一方、良いコントリビューションは 検索・参照・二次利用・被リンク・Star といった形で複利が効きやすい。
この文章は「自分が全部書く」よりも、「社内の技術者に継続的に書いてもらう仕組み」を重視します。ベンチャー目線ではここが採用要件に落としやすい。
要するに、DevRel を「広報」ではなく 編集工学＋開発者体験設計＋プロダクト的運用として扱っています。これは IT ベンチャーが欲しがる「実務で回る仕組み」の話です。
ベンチャーが陥りがちなのは「とにかくブログPV」の一本槍です。しかし題材が
なら、ブログ中心は負け筋になり得ます。そこで、教科書・ウィキ・OSS・データベース・公開AMA（AUA）など、開発者が“仕事で参照する”導線に寄せる、という提案が出てきます。
幹部向けに翻訳すると、この文章は DevRel を「広報施策」ではなく “技術知のサプライチェーン整備”として捉えています。AI時代の競争力は、モデルだけでなく「知識の整備・再利用・学習ループ」に依存するため、この視点はむしろ大企業向きです。
大企業のAI活用が止まる典型は次です。
この文章が言う 「教科書を作る」「体系を作る」「ウィキで議論過程も含めて残す」「GitHubで再利用可能にする」は、まさにこの詰まりを“コンテンツ化”で突破する発想です。
対外向けに見えますが、本質は 社内の生産性と学習速度に効きます（内部 DevRel）。
記事後半の「表記ゆれを潰すには統一DBが要る」「対象×問題点の照合」という話は、幹部が押さえるべきポイントです。
ここで DevRel が関係するのは、そのDBや知識体系を「内外の開発者が使える形」に落とし、フィードバックループを回す役を担えるからです。大企業がこれをやると、単なる発信ではなく 標準の策定者に近づきます。
大企業では「オープンはリスク」という反射が起きがちですが、この記事の Contribution は、無闇な公開ではなく
という設計論です。幹部の役割は、ここを現場に丸投げせず 方針とガードレール（何を公開し、何を公開しないか）を決め、投資として時間を確保することです。
この記事が「片手間でやらせるな、投資しろ」と言っているのは、まさに幹部への要求です。
必要なら、上の3者それぞれに向けた「提案書の骨子（KPI案・体制案・最初の90日プラン）」まで落として書けます。