しかし既存の DevRel では少し足りないと思ったので、自分なりに捉え直すことにした。
この記事は、読者が DevRel を捉え直すための刺激を与えるつもりで書いている。あるいはこれで食べていきたい私が誘いをいただく or 今後提示するためのアピールとして書いている。
記事の内容:
対象読者:
便宜上、記事の主語は「開発者」と書く。主語がでかいが、あらゆる開発者に当てはまるわけではない。どちらかと言えば、オープンな方や自社プロダクトを持つ方を指すと思う。Zenn の記事を読み書きしたり、GitHub で語ったりする層と言ってもいいかもしれない。
DevRel とは Developer-Relations の略であり、開発者ユーザーとの良好な関係性をつくりましょうというものである。いわゆる B2D(Business to Developer) に含まれる活動だ。
結局は自社の製品と名前をもっと売るための活動であり、従来のマーケティングや広報と同じに思える。なぜ DevRel などと別名をつけて区別しているかというと、開発者という生き物が特殊 だからだろう。
いくつか例を挙げる:
開発者であれば上記はどれも常識だろう。一方で、開発者でない者にはちんぷんかんぷんだし、勉強して理解することも難しい。たとえば Markdown や GitHub を使えるようになるのは困難だろう。また開発者であっても、プライベートでわざわざ使っている人は少ない。その程度には高度で疲れる営みだと思う。
雑に言えば 開発者に特化したソフトスキル が多数あり、開発者という生き物はそれを身に付けた「強化された人間」である。開発は、おそらくこの世で最も思考と手数の多い仕事の一つだ。脳内で処理して人に伝えるものではなく、コンピュータに伝わるよう厳密に書かねばならない世界だからだ。それゆえ手段には徹底的にこだわらねばならず、効率や集中にもうるさくなるし、信念も強化される。
一般人とは生態が違うのである。B2D では、このような生物を相手にしなきゃいけないが、無論素人に務まるものではない。たとえば従来のマーケティングや広報が得意な者であっても歯が立たないし、キャッチアップもおそらくできまい。
※唯一の例外は巨大な企業や製品であり、巨大でユーザー数も多いゆえに非開発者ユーザーの比重が重いため、普通のマーケティングや広報 +αで済む。特殊な生物を相手にする必要は、実はあまりない。ただしその前段では、開発者を相手にしていて上手く行っていたりもする。むしろそこで成功したからこそ巨大になれている
DevRel が持つニュアンスは「自社の外の開発者ユーザー」だと思う。これを私は 外部の DevRel と呼んでいる。
あえてそう呼んだのは、もちろん 内部の DevRel もあると思うから。つまり「自社の開発者」だ。たとえば、ある程度組織が大きくなってくると、自社の開発者向けのサービスを提供する役割が出てくるだろう。まさに Platform Engineering というジャンルもあるし、IT ベンチャーの話でも「従業員を顧客とみなして丁寧に接する」的な金言を抱く人は多い印象がある。
私は、このあたりを概念化するべきだと考えた。開発者という特殊な生き物は自社の外にいるだけではない。 自社の内部にもいる。というより、製品をつくっているのもまさに開発者であり、特殊な生き物なのだ。ならば外部の DevRel と同様、特殊な活動として位置づけた方が良いはずだ。
DevRel が持つもう一つのニュアンスは「コミュニティ活動」だと思う。私はそうは思ってなくて、以下の 3C で整理している:
図示すると以下:
Contents --+--> Community
|
+--> Contribution
コンテンツという源泉があって、これを届ける方法が二つある。
一つ目、コミュニティはすでに読者が想像したもので大差ない。Discord サーバーとして提供されているようなオンライン型もあれば、イベントに申し込んで参加するオフライン型もある。同じコミュニティでもオープンなものもあれば、クローズドなものもある。一見するとオープンだが、事実上参加者を選んでいる形態もありうる（特に to B）。また人気があると抽選の概念も出てくる。
コミュニティ論は割愛するが、コミュニティは居場所または権威を示すための舞台としての機能があり、運用の仕方はどの業種であっても大差はない。開発者向けであってもだ。扱う内容と訪れる客の傾向が違うだけで、単純化すれば人間の原始的な欲求を満たせればいい。エンタメと言い換えることもできる。したがって、コミュニティを用いた DevRel であれば、開発を知らない者であっても務まる。
※エバンジェリストなど製品の顔となる場合は、深い製品知識と周辺知識も要るため開発経験者でないと厳しいと思う。
本記事でフォーカスしたいのは二つ目、コントリビューションの方だ。直訳すると「貢献」だが、ここでは有用なコンテンツをオープンに提供して、実際に使ってもらえることと定義したい。たとえばオープンソースでソフトウェアやドキュメントを提供したり、気合を入れてつくったレポートを無償で公開したりといったことが該当する。
オープンと書いているように、誰でもいつでもアクセス可能でなければならない。もちろん無償で、だ。ペイウォールや会員登録などもってのほかである。インターネット文化を知る者ならごく当たり前の思想だろう。広く公開して、広く使ってもらった方が世の中全体で見たときに貢献を最大化できる。ソフトウェア自体がそうやって発展してきた。
さて、このコントリビューション活動を専任で行う DevRel ポジションを想像できるだろうか。少なくとも現時点では存在しないと思う。しかし私が DevRel として強調したいのはここなのだ。
DevRel にはコミュニティだけではなくコントリビューションという軸がある はずだ。無論、そのためにはコンテンツが必要であり、したがって コンテンツを持続的につくる仕組みや文化の整備 も重要なはず。
DevRel をこのように拡張することで、コミュニティしか知らない前時代の DevRel を超えた価値を出せると信じている。
開発者が特に重要視するのが 開発者体験（Developer Experience） だろう。
この言葉は現状「プロジェクト」くらいに定義が揺れる多義語だが、私は 開発者が抱く気持ち良さ くらいに捉えている。気持ち良いことよりも、気持ち悪いことを避けるために使う。ストレスと言い換えてもいい。
開発者体験の悪い例をいくつか挙げてみよう:
冗談抜きで開発者は一般人の何倍、何十倍、下手すると何百倍という手数をこなしている。大量に読むし、書きもする。コンピュータまたはコンピュータを扱う人間が相手なので、ただの人間相手に非言語や曖昧な情報では済まない。生成 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 のビジネス戦略も同じだ。鍵屋さんなのか、盗聴や盗撮を検出するのか、あるいは地域ごとの治安をデータとして持っていて「治安が良い地域」を費用とのバランスを踏まえて提案するのか、それともお金持ち向けに堅牢で住宅を高値で提供するのか。顧客層も持ち家の個人、アパートやマンションの管理人、オフィスビルの管理者など幅広い。どこに対して、何で勝負するかは色々考えられる。
まとめよう:
私の向き不向きの話だが、3C でいうとコンテンツとコントリビューションに注力したい。コミュニティはやらないか、やるにしても別の専任者を立ててもらう。
なぜコンテンツとコントリビューションに専念したいか:
3 は難しくない。いや、難しいが、事例も手法も確立されていて、どうとでもなる。
問題は 1 と 2 である。
状況でも述べたとおり、セキュリティ x B2D なので「開発者」に「セキュリティ」を売るわけだが、ここがそもそも難しい。セキュリティはニッチな分野であり小難しいし、ジャンルも備えでしかなくて開発者の食指は動かない。そもそも専門家にお願いしたいくらいなのだ。セキュリティは、開発者にとっては難しい上に興味もないもの、でもやらないといけないから仕方なくやってもらいたいものでしかない。
こんな開発者に対して、一体どうやってセキュリティを売り込んでいけばいいのだろうか。「開発者」の解像度を上げ、それに刺さるコンテンツをつくり続けないといけない。無論、開発者の目線は持たねばならないため、開発者を理解できない素人には歯が立たない。その辺のディレクターではスタートラインにも立てないだろう。
ここで私が目をつけているのがコントリビューションである。
コントリビューションの例を少し挙げよう:
これらはコンテンツをコントリビューションとして提供している好例だ。
開発を知らない者からすると、無償で惜しみなくばらまいているようにしか見えない。しかし、文化的に、このやり方なら比較的「使ってもらいやすい」し、公開されてるので言及や拡散もしやすい。
開発者は手を動かす生き物でもあり「使えるかどうか」は重要だ。エンタメや評論だけでは足りないし、むしろノイズすらあって相手にされないことも多い。実際に使えるコンテンツをつくらねばならない。もちろん、先で述べた開発者体験も踏まえた方がいい。わかりやすいところで言えば、レポートを公開したい場合は PDF よりも Markdown がいいし、Markdown だけでなく静的ウェブサイトもあった方がいい。
――と、開発者であれば「何を当たり前のことを」思われるかもしれない。しかし、DevRel として、これを戦略的に専任して行うという視座は現時点でまだないと思う。もちろん、こんなマニアックな世界観は非開発者には理解できないし、理解できても行動できないと思う。
だからこそ私なのだ。私は開発者であり、コンテンツとコントリビューションも知っている。開発者は技術とタスクが好きで、コンテンツとコントリビューションという「技術的な取り組みには関係のない活動」や「自然言語など言語化を伴う国語的な営み」は好まないが、私はこれらを好む変わり者なのである。そんな私だからこそ推進していけるはずだ。
コンテンツは開発者向けセキュリティに関するものとなるが、これをつくれるのは当社のエンジニアたち自身だ。
私もセキュリティに関しては素人に近いので、今さら勉強したところで皆さんに追いつくはずもない。そもそも私ひとりの発信では量も視点も限度がある。皆さん自身にコンテンツをつくってもらわねばならない。
もちろん、皆さんも日頃の業務が忙しいはずだ。特にセキュリティは診断やコンサルなど時間売りなので、物理的に時間がない。そんなみなさんでも持続的にコンテンツをつくってもらわねばならず、そのための仕組みや文化をつくっていかねばならない。内部の DevRel と書いたが、私にとっては皆さんも開発者（とは限らず「技術者」と呼ぶのが正確か）であり、顧客なのである。みなさんにコンテンツを書いていただくには？を考えていかねばならない。
大まかな方向性は決まっていて、以下のいずれかだ:
単純な例として、コンテンツとしてブログがあるとする。当社のセキュリティエンジニアたちが、セキュリティネタを、開発者向けに書いていくのである。
一番わかりやすいのは 3 の報酬だろう。ブログの記事数や PV を KPI にしたり、ランキングやボーダーを設定して給料や昇進に紐づければいい。
外部からの観察だが、たぶん AWS で有名なクラスメソッドはこれじゃなかろうか。だが、同じ戦略を取れるとは限らない。クラメソが AWS ネタの記事を素早く大量に出せるのは、AWS というプラットフォームがあるからだ。AWS は支配的な存在であり、開発者はその決定や仕様に従うしかない。となれば、いち早く動向と詳細を知れることに価値があり、だからこそ、いち早くキャッチアップして、それを日本向けにわかりやすく提供することが価値になる。一方、セキュリティというジャンルでは、同じ構図が生じている部分はないだろう。
次にわかりやすいのが 2 の成長だろうか。開発者（というよりもう少し広い技術者全般に当てはまるかも）の性質して、成長に対して貪欲な点があげられる。プライベートでも平気で勉強したり、飲み会でも開発の話で盛り上がるようなオタクな生物である。自覚がないことも多いようだが、知識や経験といった成長は常に意識しているし、それが感じられないだけで転職の動機になる。
したがって、コンテンツづくりが成長になることがわかれば、積極的に取り組んでもらえるはずである。私なら生成 AI に絡めるだろう。生成 AI のスキルは言語化スキルであり、一応自然言語ではあるものの、人間向けの内容でもなければプログラミングその他言語とも違った書き方になる。プロンプトエンジニアリングなる体系もすでにできて久しい。コンテンツづくりは、これを鍛えるのに役に立つ。役に立つということを示せれば、その気になってもらえると思う。示すためのコンテンツを私自身がつくって、会話や発表も含む多様な方法で届けて、フィードバックも受け付けるようにして気兼ねなく意見を出してもらったりするかな。そうして皆さんのやる気を焚き付けてみせよう。
最後に、もっともわかりにくいが 1 の楽しさだろうか。
コンテンツづくりは楽しい。開発者はドキュメントを書くのが嫌いな人が多いイメージだが、その主因は開発者体験が悪いからだと思っている。私が解消してみせる。
たとえば:
無論、それでも向き不向きはやっぱりあるが、それでもある程度の支持は得られると信じている。別に白黒ではない。書くのは好きじゃないが、たまに（まれに）なら書いてもいいという人もいるし、対面の場でなら喋れるという人がいるなら喋ってもらってその文字起こしを書いて残せばいい。このあたりの多様性は吸収していける。
コンテンツ寄りの DevRel というと、真っ先にテックブログを思い浮かべると思う。またすでに実践されている組織も多い。王道ということは、それだけ確かな効果があるということだが、私はあまり重視したいとは思わない。インプレッションを増やす一手段として、淡々とやる程度にしたい。
理由は単純で、セキュリティ x B2D との相性が悪いからだ。テックブログもまたブログであり、ブログは本質的にカジュアルなエンタメコンテンツである。そしてすでに述べたとおり、セキュリティは開発者にとっては「難しい上に興味を持てないもの」である。AWS のような支配的構図と圧倒的利用者数もない。つまり ブログでスケールできる段階ではない。だからこそ、まずは段階を引き上げるための他の活動、もっというとコントリビューションを重視したいのである。
とはいえ、王道である程度のインプレッションが得られるのは事実なので、やらないとも言わない。あまり時間をかけず、コンスタントに提供できればそれでいい。戦略と仕組みとディレクションをすればいい。
戦略には正解は無いので適切に決めればいい。たとえば:
仕組みについては、記事を実際に書くことになる当社のセキュリティエンジニア向けの開発者体験をよくするという話である。たとえば:
最後にディレクションについては、一言で言えば執筆者のお尻を叩くということである。
戦略に則り、仕組みをクリアできる程度のクオリティの記事を書くまでお尻を叩く。機械的なリマインドで済む人もいれば、会議を設定して拘束しないとやらない人もいるかもしれない。編集者がマンガを世話するシーンは思い浮かべやすいと思うが、まさに同じだ。人によって何をすればいいかが違うので、人の数だけ対応しなければならない。この点は私の苦手分野なので、カバーしてほしいところではある。
セキュリティ x B2D の国内ボリュームはおそらく小さいため、海外を狙っていきたい。
特に（後述するが）GitHub 上でコンテンツを展開する場合、英語圏も含めるかどうかで利用者数は 10 倍や 100 倍も変わってくる。国内の界隈で流行っても 500 star もつかないところを、英語圏を含めれば 10000 star に至る、くらいに違いがあると思う。
社内で評価されないとき、社外で評価してもらった実績を持ち込んで「ほらね、私は優秀でしょう？」と認めさせる手法があるが、これと同じで、国内であまり相手にされてなくとも、海外で評価されれば国内に持ち込んで拡大できる。そういうチャンスも狙っていきたいと思う。
迷っているのはアプローチで、もっというと生成 AI による翻訳で済ませるかどうかだ。一般的な感覚だと品質や礼儀の観点でダメだと思いがちだろう。私はそうとも思えない。というのも、開発者はもっとドライであり、有用なコンテンツであれば翻訳が多少不自然なくらいは許容できる可能性が高いからだ。読者の実体験でも、多少翻訳が怪しい日本語でも有用なら使った経験があるかと思う。あるいは翻訳または自力による拙い英文でも通じた経験があると思う。そもそも現時点で生成 AI の力でシームレスに翻訳できる段階にあり、ブラウザ拡張機能としてその場で翻訳するツールや拡張機能はあるし、つくることもできる。言語の壁は薄くなっているのだ。
そういうわけで、個人的には翻訳でも行ける感覚があるのだが、じゃあやってみようと言えるほどの確証はまだない。特に思わぬ落とし穴に警戒している。少なくとも英語圏の開発者に詳しい者も交えた議論は必須だろう。それができない場合は、そういう人材を取ってこないといけないかもしれない。
Cosense を使うと情報収集や議論の様子を濃密に公開できる。
既存の例:
ウィキのコンテンツ力は、Wikipedia やゲーム攻略ウィキなどですでにご存知かと思う。そして Cosense は開発者目線でも開発者体験の良い現代的なウィキである。ブログよりも圧倒的に書きやすいし、SEO にもひっかかって検索流入も期待できる。
これ単体で広報を担えるものではないし、むしろニッチなコンテンツになるが、それでも知る人ぞ知るコンテンツとして濃いファンを獲得できる余地がある。一方で、マニアックなコンテンツばかりあっても読まれないのは目に見えているため、コンテンツの方向性を（開発者が読んでわかるものに）寄せる必要はある。私もまだ全然見えてないので膨らませていきたい。
セキュリティに関する何らかの体系をつくり、GitHub と静的サイトで共有したい。そうすると多くの開発者にとってリファレンスとなるはずだし、界隈が薄々取り組んできた諸々を上手く捉えられたら、共通言語として一気に定着する可能性もある。
当社のセキュリティエンジニアとここまでの実績次第だが、もし界隈で知られるほど実力が高いのであれば、体系化できるだけのネタは持っているはずである。あとは、それを言語化して構造化して公開するだけだ。そのノウハウは私が持っている。
以前私は SBOM に関する本を書き、その中で DevPst という概念を提唱した。DevOps のノリで、Dev と PSIRT を持ってきたものだ。私はこのようにゼロイチをつくれる。目次などさらに詳細化してもいい。これを皆さんが叩けばいいのである。
私はクリエイティブシンキングと呼んでいるが、発散と収束の繰り返しによってコンテンツをつくりあげていく営みをする。ブレストや KJ 法がわかりやすい。これをみんなでやる。DevPst というのは例にすぎず、他にも色んな体系をつくれる余地があるはずだ。
Google が提唱した SRE は、今やポジションとして定着しているが、これと同じものをつくれたとしたらどうだろう？製品開発チームの一ポジションという文脈だから、そうだな、プロダクト・セキュリティ・エンジニアリングなる体系を整理した上で、その専任者をプロダクト・セキュリティ・エンジニアを定義する。Product Security Engineer、略称は PSE だ。つまり PSE の体系を、教科書をつくってみせるわけである。試しにこのワードで検索したところ、言葉自体はあちこちで使われているようだが、体系レベルの情報はまだなさそうだ。先手を取って、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 の調査啓蒙の仕事をしていて思ったのは、データベースが重要だということだ。たとえば脆弱性を調べるには以下が必要である:
この前提で、構成物の中に製品 P が含まれているかどうかを調べるのである。その際、照合の仕方が問題になる。「2 の一覧で使われている名前」と「3 の名前」が表記上一致するとは限らない。「Vue.js 3.5」と「vuejs-core(3.5)」かもしれないのである。人間の目視なら同じだとわかるが、プログラムでは判別できない。生成 AI に頼ってもいいが、生成 AI は統計処理であり本質的に正確でない。
今のところ、この表記ゆれ問題を確実にカバーできる唯一の方法は、表記が揺れない統一的な情報をデータベースとして管理して、それを使って照合することだと思う。つまりデータベースを自社で持って、メンテナンスしていくことだ。
脆弱性に限らず、セキュリティは本質的にはこのような「対象」に「問題点」がないかをチェックする構図になりがちである。ということは、「対象」や「問題点」をデータとして持っておくことが価値になる。そうでなくとも、近年の生成 AI ブームには抗えず、生成 AI ベースのセキュリティ製品または機能をつくるケースは多いと思うが、ここでもほぼ確実に何らかのナレッジを保持するデータベースをつくるはず。
少し前に AWS とクラメソの話をしたが、セキュリティではまだ AWS のようなプラットフォームがないと思う。この座を取れれば覇権を取れると思う。データベースは、その初手として重要になる気がするのだ。
……と、素人 +αの自分ではこの程度しか提示できないし、DevRel からも離れているが、こういう議論も皆さんとしていきたい。これもまた「コンテンツづくりの楽しさ」の一環になると思う。仮にデータベースを抱えることに価値があるとわかったのなら、データベースもまたコンテンツとして公開することで DevRel に持ち込める。
CTF などセキュリティを題材とした競技はすでにある。以下は生成 AI に尋ねてみたもの。競技というより演習が色々あるみたい:
セキュリティという「難しい上に興味を持ちづらい題材」を開発者に売り込むために、私はエンタメ化を推し進めたいと思っている。以下にヒントを示す:
何らかの競技を確立し、開発者なら楽しめる程度に理解できるようにし、競技者の顔が見えるようにして、実況もつけることでエンタメ化する。ここまでできたら、国内だけでも同時視聴者数 5000 人くらいのボリュームは出せるんじゃないかと思う。
問題はその「競技」がまだ見えてないところだが、ここは皆さんと議論や試行をして詰めていきたい。DevRel として私がアイデアをリードして、それを皆さんに揉んでもらうのが良いだろう。あるいは私よりエンタメに詳しいエンジニアがいたら、その人にリードしてもらった方がいいかも。たぶんエンタメやゲーム、その他対戦的な営みに詳しい人が何人かいる気がするので、巻き込んでいきたいし、創意工夫を引き出したい。
肩肘張らず、どうしたら楽しくなるかを純粋に探究したい。つくった競技は自分たち自らで遊んでみるのが良いのかも。自分たちで遊んでて楽しいものを外に出していくアプローチ（ドッグフーディング）だ。
ここで具体的なアイデアを出せたらいいのだが、私にまだ知見がなくて出せない。まずはキャッチアップしていきたい。私は CTF すら経験したことがないのだ。しかし、CTF 程度ではエンタメ化は遠いとも思っている。内容が専門的すぎて難しいからだ。XSS を知らないか、勉強したことはあるけどもう忘れてる程度の開発者でも楽しめるくらいに、わかりやすく、しかし競技としても成立するほど奥深いものをつくらねばならないと思っている。
ターゲットについても、今は開発者を想定しているが、非開発者もアリかもしれない。ソフトウェア開発、セキュリティ、コンピュータといったテクノロジーまわりは、一般人には「ハッカーがなんかカタカタしてるやつ」だ。認知はされているし、競技化されたら注目を引けると思う。見せ方次第で楽しめる余地もある気がする。
IT エンジニアリングを題材とした作品は、ありそうで意外とない。私が知っているのは「なれる!SE」や「ブラッディ・マンデイ」くらいか。なおドラマと映画は趣味外なのでさっぱりわからない。
DevRel の切り口として「エンタメ」があり、前項でも競技の話をしたが、もう一つ、私はフィクション作品も追求したい。マンガまたはラノベと書いたのは意図的で、開発者の興味との親和性を考えてのことだ。別の言い方をすると、ドラマや映画ほど一般受けを狙うつもりは今はない。一般受けはマンガやラノベで上手くいってからでも遅くないと思う。
別に商業作品として展開する必然性はない。むしろ GitHub でオープンに公開するなど、開発者向けの DevRel として開発者体験を大事にしたいと思う。
一方で、エンタメ作品は、開発者といえど仕事モードで見るとは限らないし、むしろ私生活モードで見るから、コントリビューションは置いといて、単に従来の戦略（SNS でのチラ見せや小説投稿サイトやマンガアプリなどでの配信）が良いかもしれない。だとすると、投稿サイトやアプリ配信元などの企業と提携するのが良いのだろうか。最初に思いつくのは開発者にはお馴染みはてなが擁するカクヨムで、セキュリティエンジニア向けのラノベをカクヨムで連載しようといったことをすればいいのだろうか。
最も重要なのは作品をつくれる作家の確保とディレクションだろう。当社としては作家にセキュリティに関する情報をインプットし、作品はもちろん作家に書いてもらう。必要ならわかりやすさに寄せる必要もある。いずれにせよ濃い議論は避けられないと思う。私がすぐに思いつくのは、SF プロトタイピングの知見を使って議論や作品コンセプトづくりに協力することだ。
本記事では DevRel に対する私の思い――特に開発者に寄り添うために、コミュニティではなくコンテンツとコントリビューションに力を入れる考え方を述べた。その後、セキュリティ x B2D を例にして何をやれそうかを考えてみた。参考や刺激になれば幸い。