「開発者にわかりやすく」がポリシーなのでセキュリティの専門家である必要はありません(まさに自分がそう)。
その上で、文章をはじめとしたコンテンツの企画と最終品質に執念を持てる方をDevRelとして大募集しています、という感じです！
どういう意味？日本語で解説して。
※これは cb2ai の douiu プロンプト を使っているだけであり、他意はありません。英語の文章に対して行うことも多いので「日本語で解説して」もついています。
この一連の投稿は、ある企業で技術ブログの編集長業務を引き継いでくれる人を募集しているという内容です。投稿者である@toyojuniさんは、以下の点を強調しています。
まとめると、このポジションは、セキュリティの専門知識よりも、開発者目線で技術情報をわかりやすく伝えられる能力と、コンテンツの質を高めるための管理能力を求めているということです。
目的がわからない。 セキュリティエンジニア向けの高度なナレッジを提供する、ではダメなん？
目的は「セキュリティ“業界内”の人に刺さる情報発信」ではなく、“ふつうの開発者”に届いて、プロダクト利用や信頼につながる発信を継続的に作ることだと思われます。だから編集長（ディレクション役）に、あえてセキュリティ専門家でない視点を求めています。
投稿の文脈だと、技術ブログは会社の発信の中核で、狙いはだいたい次のどれか（複合）です。
これらは、読者が「セキュリティ研究者」よりも「一般の開発者」であるほど効きます。
ダメというより、目的が別になりやすいです。高度Exploit・研究寄りコンテンツは価値がありますが、企業ブログの“マーケ/DevRel”目的とはズレやすい。
具体的には：
だから投稿者は「セキュリティ屋によるセキュリティ屋のための凄Exploitブログになりかねない（→開発者マーケとしてNG）」と言っています。
要は「専門家が書くと尖りすぎる/難しすぎる」方向に行かないように、
をやる人が欲しい、という意味です。専門知識より「読者代表としての目」と「コンテンツ品質への執念」を重視してる。
「高度なナレッジ提供」が完全にNGではなく、やるなら例えば：
みたいに編集方針を作れば、専門性と開発者向け価値を両立できます。
必要なら、その企業ブログが想定してそうな「良いテーマ例/悪いテーマ例」も具体例で整理します。
GMO Flatt Security株式会社 採用情報 募集職種 ビジョン メンバー ワークスタイル カジュアル面談 選考に応募 DevRel 仕事概要 GMO Flatt Securityは「エンジニアの背中を預かる」をミッションに、エンジニアを主な顧客としたセキュリティサービスを提供しています。こうした事業特性から、エンジニアとの信頼関係そのものが事業の基盤になっており、DevRelを組織として重要な役割と位置づけています。 2025年は、イベント開催やスポンサー協賛、エンジニア向けのコンテンツ制作・発信を通じて、「Dev × AI × SecならFlatt」というメッセージを積極的に発信してきました。この流れをさらに加速させるため、エンジニアと組織の架け橋となる専任のDevRel担当を募集します。 特に技術ブログは弊社のDevRel活動の中核を担ってきました。一企業のブログでありながら年間約13万UU（2025年）規模を誇り、「サイバーセキュリティ」という開発者にとっても決して取っ付きやすくはない世界をわかりやすく伝え、ノウハウを開示することに努めています。しかし、こうした技術コンテンツの企画・ディレクションに専任者はおらず、有志や兼務の努力で成立している状態です。 今回募集するDevRel専任に期待する人物像は「コンテンツづくりへの執念を持つ方」です。 コンテンツは弊社が世界の安全に資する上で不可欠な架け橋です。この質を継続的に改善し、その規模の拡大に向けて専任メンバーとして牽引してくださる方をお待ちしています。
お任せしたい仕事内容
「ファン作り」を軸に、エンジニアコミュニティにおける弊社のプレゼンス向上と、プロダクト・サービスの認知拡大をリードしていただきます。 既存のDevRelメンバーは主にイベント・コミュニティ運営を担っており、本ポジションは技術コンテンツ領域の専任として、裁量と挑戦余地の大きい役割です。
技術発信の企画・ディレクション：
ブログをはじめとする技術コンテンツの企画・編集
エンジニアによるアウトプットの最大化支援
グローバル向け技術発信：
海外向けリサーチブログの発信支援
海外エンジニアコミュニティへのアプローチ
イベント・コミュニティ運営：
自社コミュニティの企画・運営
最新トレンドを捉えたスピード感のあるイベントのプロデュース
RubyKaigi、Go Conference等の外部カンファレンスへの協賛・ブース出展企画
【体制】 配属予定のチームは、Developer Marketing teamです。 DevRel、広報、デザイナー、マーケターが在籍しており、それぞれの専門性を活かしながら、エンジニア向けの情報発信やコミュニティづくりに取り組んでいます。
Developer Marketing team：DevRel1名、マーケター3名、広報1名（兼務）、デザイナー1名（兼務）、セールス1名（兼務）
本ポジションの魅力
組織のスピード感に合わせ、市場の熱量を逃さないダイナミックな施策が打てます。
例:
Claude 3.7 Sonnetの登場から1ヶ月で日本初AIエージェント「Takumi byGMO」をリリース
AWS Security Agentリリースの3日後に顧客企業CTOを巻き込んでオンライン配信を実施
経営陣がDevRelの重要性を深く理解し、自らコミットする文化があるため、意思決定が非常にスムーズです。
※冒頭に掲載しているnoteは、事業部長を務める執行役員・豊田によるものです。
GitHub・Ubuntu・Claude Codeなど、世界的に著名なプロダクトへの脆弱性報告実績をもつ世界レベルのエンジニアとともに、技術的な背景を理解した上で発信や企画に取り組めます。
応募条件
必須スキル（Must）
ITエンジニアとしての実務経験１年以上、またはエンジニアリングに対する深い理解
技術ブログ、登壇、コミュニティ運営など、何らかの技術発信活動に携わった経験
最新のAIトレンド（LLM、AI Agent等）に対する強い関心とキャッチアップ能力
歓迎スキル（Want）
セキュリティ領域に関する知見
大規模な技術カンファレンスの運営経験、またはスポンサー対応経験
SNS（X、LinkedIn等）での発信力や、技術者コミュニティへのネットワーク
雇用条件
想定給与
年収：600万円 ~ 1,300 万円
提示年収金額の1/12を月々支給
固定残業代として月45時間分を含みます。45時間/月超過の場合は別途残業代をお支払いします。
年2回の評価に基づく給与改定あり
採用時の給与金額は、スキルやご経験、現職のご収入などを考慮し決定します。
給与例）年収600万円 ~ 1,300 万円
月給：500,000円 ~ 1,083,400円
基本給：369,900円 ~ 801,600円
固定残業代：130,100円 ~ 281,800円
従事すべき業務の変更の範囲
会社の定める業務
雇用形態
正社員 （３ヶ月の試用期間あり）
就業場所
東京都渋谷区桜丘町26-1 セルリアンタワー6階 ※リモートワーク制度あり
就業場所の変更の範囲
会社の定める場所 応募はこちらから 個人情報の取り扱いについて
面談や選考などで知り得た個人情報は、当社プライバシーポリシーに基づき適切に取り扱います。
面談や選考に応募をいただくことで、上記への同意とみなさせていただきます。
GMO Flatt Security 採用情報/募集職種/DevRel
上記を踏まえて、COO toyojuni さんの意図を考察して。
toyojuniさんの投稿意図は、採用ページの記述（「ファン作り」「プレゼンス向上」「認知拡大」「技術ブログが中核」「開発者にわかりやすく」）と合わせて読むと、だいたい次のように整理できます。
GMO Flatt Securityは「エンジニアが主な顧客」で、採用文にも「エンジニアとの信頼関係そのものが事業の基盤」とあります。
この前提だと技術ブログは、単なる広報ではなく
という“プロダクト/サービスの周辺インフラ”です。
だから「媒体拡大の余地はあるが真髄は技術ブログ」と言っている。
採用文に「専任者はおらず、有志や兼務の努力で成立」とあります。
COO目線ではこれは明確なボトルネックで、
という課題になりやすい。
なので「編集長業務を自分から奪ってくれる方」＝“権限と責任を持って回す専任”を欲している。
ここが投稿の肝です。
Flattには世界レベルのセキュリティ/リサーチ人材がいる（採用文にも脆弱性報告実績などが書かれている）。その組織で放っておくと、発信が自然に
に寄りやすい。
しかし、彼らの主要顧客は「セキュリティ専門家」ではなく「セキュリティに詳しくない開発者/開発組織」側であることが多い。すると開発者マーケ（DevRel）としての失点が起きる：
だからtoyojuniさんは、編集長にはセキュリティの深さよりも「開発者にわかりやすいか」「開発者が次に何をすればいいか」にコミットできる人＝読者代表の目を求めている、という意図です。
投稿で言う「コントロール」は、検閲というより編集方針のガバナンスです。具体的には：
ここまで含めて「編集長業務」と呼んでいる。
COOの関心は「発信の美しさ」よりも、再現性ある成長装置になっているかです。
技術ブログが年間13万UU規模まで来ているなら、ここは経営的に「伸ばすべきチャネル」になっている可能性が高い。一方で、セキュリティ会社の発信は放置すると“専門家内輪化”しやすい。
なのでCOOとしては
変換器＝DevRel編集長を置きたい、という意思決定に見えます。
まとめると、toyojuniさんの意図は「高度なセキュリティ知識を発表すること」自体を否定しているのではなく、それを“開発者に届く形”に翻訳し、事業（信頼・認知・利用・採用）に効くアウトカムへ繋げる編集責任者が欲しいということです。
もし「高度記事もやりたい」なら、Flattの文脈では“高度さを保ちつつ開発者向けに着地させる編集”が理想、という発想になります。
私はこのポジションに応募しようとしています。
私は受かるでしょうか。受けるべきでしょうか。
受かる可能性は十分ありますし、「受けるべきか？」にはかなり前向きに答えられます。ただし、この職種は“文章が上手い人”というより 社内の強い技術（Sec/AI/Dev）を、継続的に、狙った読者に届く形で量産する編集長/プロデューサーなので、そこに刺さる材料を応募書類と面接で出せるかが勝負です。
募集文・toyojuniさんの発言から求めている中核は「コンテンツづくりへの執念」「開発者にわかりやすく」「企画・編集・ディレクション」「社内アウトプット最大化」ですよね。そこに対してあなたの強みは適合度が高いです。
少なくとも「応募してもズレてる」タイプではなく、かなり“狙いに合ってる側”です。
ここが弱いと落ちやすい、というポイントを挙げます。
企業DevRelは、個人ブログよりも 目的（認知→信頼→相談/導入→成功） がはっきりしています。
面接では「100万PVです」だけだと、運用者としての強さが伝わりきらないことがあります。
を語れると強いです。
あなたが言う通りディレクションが肝ですが、ここは机上の空論だと見抜かれます。例えば：
この辺の具体が出せると勝ちやすいです。
「下書きを競わせる」はアイデアとしては分かる一方、研究/エンジニア文化だと -競争が逆に筆を止める -心理的安全性を下げる -忙しい人が脱落する も起きがちです。
むしろ刺さりやすいのは、
あなたはかなり適性がありそうなので、受けた方がいいです。
一方で、合否は「実績」より “この会社の目的に沿って運用設計できるか” の提示にかかりやすいので、応募前に次を用意すると勝率が上がります。
1) 自分のベスト記事3本（初心者向けで、構成が上手いもの）
各記事について「狙い」「工夫」「結果」「学び」を箇条書きで添える
2) この会社のブログの改善提案（A4 1枚）
例：
3) 社内アウトプットを増やす運用案（具体的に）
最後に逆質問です。ここが満たせるほど、さらに“受かる確率”は上がります。
この2点を教えてくれれば、あなたの経歴の出し方（職務経歴書・面接の勝ち筋）を、より応募先に合わせて具体的に組み立てます。
実務経験はあります。今もエンジニアです。
英語発信/グローバル対応（翻訳ディレクションでも可）にどれくらい関われそうですか？
こっちが弱いです。英語はできないので「生成AI使って翻訳すれば理解できます」という程度です。
英語が弱いのは「致命傷」ではないですが、そのまま言うと弱点として刺さりやすいので、応募戦略としては次の整理が良いです。
採用票の書き方だと、あなたが“英語でバリバリ執筆”まで必須というより、
みたいな「ディレクション寄り」の役割を含んでいる可能性が高いです。DevRel専任で“技術コンテンツ領域の牽引”が主で、英語はその一部、という構図。
面接での言い方は、弱点の告白ではなく「リスク認識＋運用設計」で返すのがコツです。
ポイントは「自分が英語で書ける」よりも、会社として英語発信を継続できる仕組みに落とすこと。
あなたの強み（編集・わかりやすさ・仕組み化）に寄せて、英語をこう処理できると示すと強いです。
これを「入社後90日プラン」的に語れると、弱点が「課題認識できている＋回し方わかってる」に変わります。
応募書類/面接用に、英語については次の一文を用意しておくのが効きます。
必要なら、あなたのQiita/Zennの「強い記事3本」を前提に、職務経歴書の“DevRelっぽい書き方”と、面接での想定QA（英語質問の切り返し含む）を一緒に作れます。英語をどの程度読めるか（読む/書く/話すを5段階くらい）も教えてください。
観点を変えて、なぜ DevRel と表示しているかを考察してほしい。 内容から見ると「編集長」や「ディレクター」として表示するのが普通ではないですか？
「編集長/ディレクターの仕事に見えるのに、なぜ職種名がDevRelなのか？」は、たぶん 社内外に対する“役割の定義”が DevRel の方が正確だからです。募集文とtoyojuniさんの投稿を前提にすると、理由は主に次のあたりに整理できます。
編集長・ディレクターは“手段（コンテンツを作る役割）”の名前です。
一方この求人が達成したいのは、採用文にある通り
で、これはまさに Developer Relations の領域です。
つまり会社としては「ブログ編集担当を採りたい」のではなく、開発者との関係を作る責任者を採りたい。その主要手段がブログ（中核）なだけ、という構図です。
募集要項に、ブログ以外も明示されていますよね。
今は「技術コンテンツ領域の専任」寄りでも、事業の状況で ブログ→登壇→イベント→コミュニティ→海外みたいに活動が広がる可能性が高い。
この時に「編集長」で採ってしまうと、本人も周囲も「記事だけやる人」と誤解しやすく、スコープが閉じます。
職種名をDevRelにしておくと、最初から「対外的な開発者向け活動を横断して持つ」前提を置けます。
「編集長/ディレクター」で出すと、応募者が
に寄りやすいです。でもこの求人はMustに
を置いていて、“技術が分かる側の人” を強く求めています。
DevRelというラベルの方が、「開発者向けに技術で信頼を作る仕事」という意味が伝わり、人材プールが合いやすい。
toyojuniさんが言う「編集長」は、原稿を直す人というより、
を担う“ハブ”です。これはメディア編集というより、DevRelがよくやる advocacy program（社内の発信者支援）に近い。
なので職種としては「編集長」より「DevRel」の方が社内的にも正しい呼び方になりやすいです。
配属先が Developer Marketing team で、メンバー構成にマーケ/広報/デザイナー等がいる。
この中であなたが担うのは、編集の職能というより「開発者市場に向けた関係構築の担当者」＝DevRel、という整理の方が座りが良いです（評価指標もPVだけでなく、認知・コミュニティ反応・指名・登壇等になりやすい）。
この求人は仕事内容だけ切り取ると「技術ブログ編集長/コンテンツディレクター」に見えるけど、会社があなたに背負ってほしいミッションは “開発者との関係（信頼・ファン・コミュニティ）を作るDevRel” なので、DevRel表記にしている可能性が高いです。
必要なら、面接で「DevRelとしての成功指標（KPI）をどう置くか」をどう答えると強いか、ブログ編集長の話と矛盾しない形で一緒に組み立てます。
ってことは、コミュニティ運用にも理解と好意がある方がいいんですかね。 僕はコミュニティは好きじゃないし、参加や運用をしたいとも思ってないんだけどなー。むしろブログを始めとしたナレッジの展開に力を入れたいんだ。
必須ではない可能性は高いです。ただし「コミュニティが嫌い」をそのまま出すのは、この求人だとリスクがあります。理由はシンプルで、募集要項のミッションが「ファン作り」「プレゼンス向上」「エンジニアとの信頼関係」で、手段として ブログ が中核だけど、イベント/コミュニティ も職務に明記されているからです。
採用票を見る限り、既存DevRelは主にイベント・コミュニティ運営を担っていて、あなたが応募する枠は「技術コンテンツ領域の専任」ですよね。つまり
なので、あなたが「ブログ/ナレッジ展開に張りたい」は、方向性としては合っています。
DevRelは極端に言うと「開発者と良い関係を作る仕事」で、関係構築の代表例がイベントやコミュニティだからです。
ただここで大事なのは、コミュニティへの関わり方は二択（好きで前に出る/嫌いでゼロ）じゃない、という点です。例えばコンテンツ専任DevRelでも十分成立する関わり方があります。
これはDevRelとして自然です。
あなたの本音が「コミュニティ嫌い」でも、面接ではこう言い換えるのが安全です。
要するに「嫌い」ではなく「得意領域と貢献の形」を語る。
カジュアル面談や面接の逆質問で、これを聞くと良いです。
ここで「イベントもガッツリ回してほしい」が返ってくるなら、あなたの志向とズレる可能性が高い。逆に「基本はコンテンツ専任、イベントは連携程度」ならかなり相性が良いです。
よければ、あなたが「絶対にやりたくないライン」（例：月◯回の現地運営は無理、登壇は無理、Slack運営は無理等）を教えてください。そこから、面接での現実的な落とし所の作り方を一緒に組みます。
とすると、まずはカジュアル面談で僕の仮説がマッチするかを会話すればいいですかね。
僕の仮説:
どうだろう。そもそもカジュアル面談に応じてもらえるかな？
カジュアル面談で「仮説が合っているか」を確かめに行くのは、今回かなり筋が良いです。というか、この求人はミッション（DevRel）と実務（技術ブログ編集長機能）が混ざっているので、面談でスコープ調整しないと入社後に齟齬が出やすいタイプです。
結論、かなりマッチ寄りです。特に強いのはここ：
一方で、言い方だけ調整した方が良いポイントもあります。
あなたの意図は正しい（中核がブログ）けど、言い方としては
にすると角が立ちません。
これは思想としては良いけど、会社は外部（市場・顧客）にも当然コミットしてるので、
正論でも、面談の場で“要求”に聞こえるとマイナスになりやすいです。代わりに、
あなたの仮説を検証するための質問はこれが効きます。
この4つが噛み合えば、あなたはかなり戦えるはずです。
応じてもらえる可能性は高いと思います。理由は：
ただし、面談依頼時の文章は短くした方が通りやすいです（長文の思想は面談で言えばいい）。
この形で送るのが一番通ります。
必要なら、あなたの仮説を「面談で刺さる1分ピッチ」に圧縮した版も作ります。