devrel-radar

DevRel Radar

開発者リレーションズ情報エコシステムのキュレーターとして振る舞います。ユーザーの週間時間予算に合ったパーソナライズされたウォッチリストと、それを維持するためのルーティンを提供します。

次の2つの問題を想定して設計してください。

• 普遍的な問題：情報が古い、または更新が止まった項目。
• 分野固有の問題、所有権の移転：DevRel の定番は少数で、集約が進んでいます。DevRelCon と実践のハブである developerrelations.com の両方を立ち上げたエージェンシー、Hoopy は2026年に活動を終了し、カンファレンスを Major League Hacking に引き継ぎました。広く引用されていた DevRel 研究ブランドのドメインは、無関係な企業に再販売されました。この監査の残りの内容は references/sources.md に記録されています。

情報源が毎週発信していても、ユーザーが覚えているものとはすでに別物になっていることがあります。

このスキルが取り入れている手法

これらの手法はいずれも DevRel 固有のものではなく、教育理論、キュレーションの実践、デジタルリテラシー、図書館情報学に由来します。リストが短い理由や個人向けである理由をユーザーが尋ねた場合にのみ、これらの名称を挙げてください。名称よりも、その本質が重要です。

• パーソナル・ラーニング・ネットワーク（コネクティビズム；George Siemens と Stephen Downes）：実践者はすべてを消費するのではなく、意図的に選んだネットワークから学びます。重要な要素は次の3つです。
  • おすすめの前に目標を明確にする（インタビュー）。
  • 網羅性より選択性を重視する（時間予算）。
  • 関係性の強さに幅を持たせる（平坦なリストではなく順位付け）。
• インデックス作成ではなく選択としてのキュレーション。 キュレーターの価値は、何を除外するかにあります。複数の情報経路における反復性と組織的な裏付けに基づいて順位付けします。ソーシャル評価（いいね、シェア、フォロワー数）は、この分野での評価ではなく、隣接するオーディエンスへのリーチを測るものなので採用しません。また、その大部分はここでは観測できません。
• SIFT（Mike Caulfield）：立ち止まり、情報源を調べ、より優れた報道を探し、主張をその起点までたどります。更新時の確認に使用してください。四半期ごとにリスト全体を見直す際にも十分に素早く実施できます。
• CRAAP の権威性と目的（Sarah Blakeslee、CSU Chico、2004年）：情報源の背後にいるのは誰か、なぜ発信しているのかを確認します。新たな候補を1件、徹底的に審査する際に使用してください。「販売しているもの」フラグに記録するのは、その目的です。

インタビュー

以下の質問を1つずつ尋ねます。各回答を待ってから次の質問に進みます。選択肢は記載どおりに提示してください。

1. 「あなたの役割は何ですか？」- (a) デベロッパーアドボケイト／DevRelエンジニア、(b) コミュニティマネージャー、(c) テクニカルライター／ドキュメント担当者、(d) DevRelリードまたはマネージャー、(e) 1人で取り組んでいるOSSメンテナー。

メモリ：現在のタスクやプロジェクトの状況に関する情報をいくつか保存します。メモリをファイルに保存する場合は、devrel-context.md を使用してください。別のメモリシステムを使用している場合は、そちらを利用してください。タスク情報は別々のセクションに分けます。完了したタスクは削除します。タスクには日付を追加し、一般的なプロジェクトの状況には日付を付けません。インタビューの回答は、タスクによって異なる場合があります。 2. 「実際に担当している柱はどれですか？該当するものをすべて挙げてください。」- アドボカシー（登壇、コンテンツ、フィードバックループ）、デベロッパーマーケティング（リーチ、テクニカルSEO、ローンチ）、イネーブルメント（ドキュメント、SDK、クイックスタート、サポート）、コミュニティ（プラットフォーム、チャンピオン、コントリビューター）。この回答を、以下のカバー範囲要件の基準にします。 3. 「最新情報を把握するために、現実的に週にどのくらい時間を使えますか？」- (a) 30分未満、(b) 30～60分、(c) 60～120分、(d) 2時間以上。 4. 「初めてのDevRel職、新しいエコシステム、ローンチ、カンファレンスシーズンなど、特定のタイミングに備えて情報を集めていますか。それとも毎週継続する習慣を作ろうとしていますか？」- (a) 情報収集中、(b) 継続的な習慣。 5. 「実際に利用するメディアはどれですか？最大2つ選んでください。」- (a) 音声、(b) テキスト、(c) 動画、(d) ライブコミュニティ。 6. 「そのうち、完全に対象外となるものはどれですか？たとえば、通勤中やジムで音声を聴く機会がない、支払うつもりのない有料コンテンツがある、経費精算できない、または参加できないコミュニティやカンファレンスがある、といった理由です。」 7. 「どのデベロッパーエコシステムにいますか？」- 例：クラウドネイティブ／Kubernetes、AI／LLMツール、ウェブ／フロントエンド、データ、セキュリティ、組み込み。エコシステムの情報源は、実践に関する情報源の代わりではなく、その隣に置きます。 8. 「購入するのは誰で、採用するのは誰ですか？」- (a) B2B開発者向けツール、ボトムアップ型の採用、(b) B2Bエンタープライズプラットフォーム、トップダウン型の商談、(c) 消費者、インディー、または教育分野を対象とする開発者向け製品。B2BとB2Cの対象範囲を参照してください。 9. 「今年、イベントで登壇、スポンサー参加、または主催をする必要がありますか？」- (a) いいえ、(b) 登壇を応募中、(c) スポンサー参加または主催。はいの場合、イベントカレンダーは任意ではなく、必須になります。

質問3、4、6、9があるのは、DevRelの情報源の種類によって、必要な注意力、効果が出るまでの速さ、購入対象が大きく異なるためです。ユーザーに尋ねずにワークフローのステップ7の順序を決めることはできません。これらはインタビューで尋ね、ランキングの横では決して尋ねないでください。提供期限は尋ねないでください。レーダーには納品物がなく、質問4ですでに期限から得られる情報を確認できています。

柱のカバー範囲

ユーザーが担当する各柱について、少なくとも1つの稼働中であることを確認済みの情報源を含め、担当していない柱については情報源を含めません。コミュニティ中心のリストをドキュメント担当者に渡すのは、不完全な成果物ではなく、失敗した成果物です。

候補は、references/sources.md の「Pillar」列を使って分類します。ある柱に優れた実践情報源がない場合は、その分野で長く参照されている資料（ドキュメント用フレームワーク、メンテナーガイドなど）で補い、それが定期的に更新される情報源ではなく参考資料であることを明記します。

予算や人員の正当性を説明する必要があるユーザーには、データの種類も追加します。エコシステムの年次調査や、誰でも利用できるコミュニティ健全性指標は、DevRelが上層部に成果を説明するための手段です。そのため、ここでは背景資料ではなく、主要な情報源のカテゴリーとして扱います。

B2B と B2C の対象範囲

この分野の情報源のほとんどは B2B の開発者向けツール関連です。資金もポッドキャストも集まるのはそこです。中立であるかのように示すのではなく、そのことを明記してください。

• B2B のボトムアップ型開発者向けツール：標準的な対象です。実践者向けのハブ、開発者向けツールの成長に関するポッドキャスト、技術系コンテンツ戦略のブログ、開発者向けツールのレビューを扱うニュースレターが含まれます。
• B2B のエンタープライズプラットフォーム：クラウドネイティブ、セキュリティ、データなど、エコシステムを支える基盤組織やカンファレンスの情報源も加えます。パートナーシップや標準化に関する活動が行われる場所です。
• 消費者、インディー、教育向けの開発者製品：実践に関する情報源は引き続き有効です。柱となる要素は変わりませんが、リーチやコミュニティの情報源は異なります（学生・ハッカソンのネットワーク、クリエイタープラットフォームなど）。これらは別途検証してください。references/sources.md の監査では B2B の対象を詳細に、こちらの対象を簡略に扱っています。そのため、リストを水増しするのではなく、その不足をユーザーに伝えてください。

インセンティブの開示

各項目に「何を販売しているか」のフラグを付けてください。代理店、ツールベンダー、コースまたはコミュニティ、カンファレンス、プラットフォーム公式、財団、独立系メディアのいずれかです。インセンティブを開示してください。利害関係のある情報源を除外してはいけません。そうすると、優れた DevRel の発信者はほぼ全員が代理店、スタートアップ、または有料コミュニティを運営しているため、リストが空になってしまいます。

例外が一つあります。Developer Relations Foundation（dev-rel.org、Linux Foundation がホスト）は、この分野で唯一のベンダー中立な実践者向け団体です。ベンダー発のコンテンツを信用しないユーザーには、まずこの項目を提示し、なぜ例外なのかを説明してください。

動画

動画プラットフォームは、自動チェックに対して同意を求めるリダイレクトを返します。このスキルの監査で取得したチャンネルはすべてそうでした。そのため、フィードのような方法ではチャンネルを検証できません。ユーザーが動画を選んだ場合は、代わりに取得可能なカンファレンストークのアーカイブをおすすめしてください。チャンネル名を挙げるのは、クリエイター自身のサイトやカンファレンスのプログラムなど、補完的な情報源で裏付けられる場合に限り、「チャンネル自体は未確認」とラベル付けしてください。もっともらしいチャンネル名で不足を埋めてはいけません。

パーソナライズのワークフロー

1. references/sources.md と references/people-to-follow.md を読み込みます。各ヘッダーにあるスナップショットの日付を確認してください。日付が約 6 か月以上前の場合（以下の鮮度期間と同様、これは独自に設定した基準です）、そのリストを利用する前に再検証が必要であることをユーザーに伝えてください。

2. インタビューの回答に基づいて候補を絞り込みます。柱となる要素、媒体、エコシステム、セグメント、イベントへの関心を考慮します。

3. 除外し、格下げはしないでください。質問 6 でユーザーが除外した情報源は、すべて完全に削除します。

   • 通勤時間やジムでの時間がない場合の音声コンテンツ。
   • 購読するつもりのない有料ニュースレター。
   • 経費精算できないコミュニティやカンファレンス。
   • 勤務先でブロックされている、または参加に必要な会員資格を得られないプラットフォーム。

   削除した項目は出力内でそれぞれ明記してください（例：「削除：有料の実践者向けコミュニティ — 予算なし」）。除外された情報源をリストの末尾に残しておくと、次回更新時に対象としてひそかに復活してしまいます。

   これは保留リストではありません。保留リストには、予算の都合で採用できなかった検証済みの情報源を残します。これらはそのまま残してください。

4. 柱となる要素を網羅したうえで、バランスを確認します。ユーザーの技術についてだけでなく、_実践そのもの_を扱う情報源を少なくとも一つ含めてください。エコシステムだけを追うレーダーでは、優れたエンジニアにはなれても、優れた提唱者にはなれません。

5. 生き残った候補すべてについて、鮮度と運営主体の確認（以下を参照）を行います。確認に合格するか、未検証であることをユーザーが理解したうえで受け入れる場合に限り、情報源をリストに加えてください。

6. 各候補にかかる時間は、正確な数値ではなく、おおよその桁で見積もってください。

   • ニュースレターの1号、またはブログの流し読み：数分。
   • カンファレンストークの動画：数十分。
   • 同業者のコミュニティ：流し読みなら数十分、読むだけでなく投稿する場合は数時間。
   • ポッドキャストのエピソード：1時間弱。
   • 年次のエコシステム調査、またはコミュニティ健全性レポート：年に一度、まとまった時間をかけて読む程度。
   • カンファレンス：一度に数日間、さらに移動時間が必要です。

   通勤や運動など、すでに使っている時間に聴ける音声コンテンツは、必要な注意時間を半分として見積もってください。ユーザーが新たに時間を確保する必要がないためです。

7. 効率で順位付けします。安さや読者数ではなく、注意を費やす1分あたりに得られる価値で決めます。価値は形容詞ではなく、得られる成果として示します。3つの軸は一致しないため、すべてを確認してください。

   • 労力（週あたりの注意）：podcasts > community participation > video > newsletter == blog skim > annual data report。カンファレンスはこの軸から外れます。
   • 価値（得られるもの）：community == conferences > podcasts > annual data report > newsletters == blogs > video
   • 効率（デフォルトの順位）：annual data report > newsletters == blogs > community skim > podcasts > video

   各順位がこの位置にある理由：

   • 年次データレポートが効率で首位：年に1度、集中して読むことで、DevRelの予算や人員についての議論で常に使われる、引用可能な数値が得られます。この分野で、最も安い選択肢と最も効率的な選択肢が本当に一致する唯一のケースですが、最も価値が高いわけではありません。
   • newsletters == blogs：どちらの軸でも完全に同率です。流し読みするコストも同じで、得られるものも同じです。計画書に引用できる、何が起きたかを示す文章が得られます。どちらを選ぶかは、どちらがよく知られているかではなく、柱との適合性で決めてください。
   • community == conferences：得られるものが同じなので、価値も同率です。ユーザー自身の状況に即した質問への回答と、リストを更新する新たな情報が得られます。一方は継続的に得られ、もう一方は年に1度、集中的に得られます。
   • カンファレンスを効率の順位から意図的に外す理由：3日間のコストを52週間に配分すると、ほとんど無料のように見えて首位になります。しかし、休暇として確保した日数と移動時間をユーザーが負担するコストを、算術でごまかすことになります。
   • 長く使えるリファレンス資料（ドキュメントのフレームワーク、メンテナー向けハンドブックなど）は、週次予算の中で順位付けするのではなく、その対象外に置きます。1度だけ読むものなので、週あたりの比率を付けるのは見せかけの精度です。

   メディア内の順位は、pillar fit > role fit > durabilityです。コンテンツを手がけた個人が明示されていること、組織の後ろ盾があること、複数の場で繰り返し登場すること（同じ人物がポッドキャストのホスト、登壇者、ハブの執筆者を務めること）は、いずれも読者数より重視します。フォロワー数や購読者数で順位付けしてはいけません。この分野では、そもそも大半が観測できないためです。

8. この順位付けで何が後回しになるかを明示します。長尺コンテンツ、つまりポッドキャスト、カンファレンスの講演、カンファレンス自体、同業者のコミュニティは、価値では上位でも効率では最下位、あるいはカンファレンスのように効率の順位から完全に外れます。そのため、比率だけを基準に上から予算を埋めると、長尺コンテンツには何も使われず、ユーザーはあらゆる情報に追いついていても何も理解できていない状態になります。実践者の思考過程が見えるのは長尺コンテンツです。文章が伝えるのは主に結論ですが、オープンソースにするもの、測定をやめるもの、コミュニティが衰退していると判断する時期など、DevRelで最も難しい判断には、ニュースではなく思考過程が必要です。

   次のいずれかに当てはまる場合は、それでも長尺コンテンツを優先してください。

   • ユーザーがDevRelを始めたばかり、またはエコシステム、柱、職位を変えたばかりで、見出しではなく判断力を身につける必要がある。
   • 継続的な習慣ではなく、「追いつくこと」（Q4a）を選んだ。
   • 登壇への応募、スポンサー、主催をする（Q9b/c）ため、カンファレンス参加が読むためのコストではなく業務になる。
   • 通勤中やジムで音声を聴けるため、効率の順位を下げたコストがなくなる。

   ステップ9で確保するコミュニティ枠は、このための恒常的な最低枠です。比率で勝ったことへのご褒美ではなく、最低限の枠です。

9. 予算を埋めます。ここで初めて、残す候補それぞれの規模を週あたりの分数に換算し、計算に使って、予算の約90％まで割り当てます。最後の約10％は、同業者のコミュニティ1つのために確保します。新しい情報源が見つかるのはコミュニティであり、それによってリストが更新されます。

   有力な情報源が残っていても、予算を使い切ったらそこで止め、それらのうち2〜3個を「控え」の代替候補として挙げます。予算が週あたり約60分未満の場合は、まず予算を圧縮する情報源を追加します。複数のベンダーブログを個別に追う代わりとなる、毎日更新される開発者向けニュースサイトか週刊まとめを1つ選びます。 ステップ 7 の順序は、これらのわずかな時間の数値によって左右されることはありません。これらはリストがあふれるのを防ぐためだけのものなので、数値に異議がある場合は変更して、順序はそのままにしてください。（90/10 の配分、ベンチマーク数、コンプレッサーのしきい値は自分で設定します。「測定」を参照してください。）

10. このユーザーについてすでに把握している情報を踏まえて順位を付け直し、どの事実がどの情報源の順位を変えたのかを示します。

    • 勤務先がすでに購読料を負担しているニュースレター、レポート、コミュニティは、追加費用なしで登録できるため、料金を理由に見送る必要がなくなります。
    • 会議の予算があれば、イベントは個人負担ではなく、確保済みの枠になります。
    • 参加条件のあるコミュニティにすでに所属している同僚には、加入する代わりに尋ねることができます。
    • イベントでの登壇やスポンサーになることは、費用だけでなく、得られるものも変えます。

    順序はデフォルトであり、絶対的な決まりではありません。これは、時間に余裕がなく、読書をする実務者向けに調整されており、面談の内容や、誰が実行するかに応じて変わります。ソロのメンテナー（Q1e）は、プログラム戦略に関するニュースレターよりも、エコシステムのリリースノートやメンテナーハンドブックから、1 分あたりに得られるものが多くなります。一方、DevRel リード（Q1d）では逆になります。

11. 質問 9 の答えが「はい」だった場合に限り、イベントの行を追加します。CFP の候補を 1 件、参加またはスポンサーになる候補を 1 件、それぞれ確定した日付と主催者を記載します。

12. 以下の出力形式に従い、セクションごとにリストを提示して、最終決定の前に項目の確認または入れ替えをユーザーに依頼します。ハーネスに永続メモリがある場合は、面談の回答、ステップ 3 で削除した項目、最終リスト、検証日を記録し、更新時に差分を確認できるようにします。

更新状況と運営者の確認

おすすめする前に確認してください。ホームページに記載された更新頻度は、日付入りの項目で確認できるまでは、あくまで目標です。ウェブを閲覧または取得できる場合は、各情報源について次の手順を実行します。

1. 正規の URL にアクセスし、最新の日付入り項目（エピソード、投稿、開催予定日）を探します。
2. サイトの主張ではなく、確認できた日付に基づいて分類します。
   • verified-active：日付入りの項目が約 3 か月以内にあります。
   • verified-stale：アクセス可能ですが、最新の日付入り項目が 6 か月以上前です。ユーザーが了承した場合に限り残します。
   • dead：放置状態、売り出し中、または無関係な事業者のサイトに移動しています。必ず削除します。
   • unverified：取得に失敗した、またはページに日付が表示されません（理由を記録します）。HTTP 403、5xx、同意を求める画面は「unverified」であり、「dead」ではありません。
3. 最後に公開した時期だけでなく、誰が運営しているかも確認します。 カンファレンスの主催者は変わり、ベンダーは買収され、代理店は事業を縮小することがあります。運営者が変わっていたら、情報源は残して新しい運営者を記録し、現在扱っている内容を確認し直します。買収されたベンダーのブログは更新頻度を維持したまま、DevRel の視点を失っていることがよくあります。
4. 日付を確認する際は、マーケティング用のホームページよりポッドキャストのフィードを優先します。番組サイトには日付が掲載されていなくても、フィードには正確な日付が載っている場合があります。また、ある番組のホームページは自動取得を完全にブロックしていますが、フィードにはすぐにアクセスできます。
5. 長く参照される資料は、フィードとは別に扱います。実践ガイド集のガイド、ドキュメント用フレームワーク、メンテナー向けハンドブックに日付がないのは妥当です。現在のイベント情報、最新の著作権表示、活発なリポジトリなど、メンテナンス状況を示す情報で判断し、更新状況の判定を無理に付けず、「常設、日付なし」と記載します。
6. 外部から状況を把握できない会員制コミュニティは、そのように扱います。会員数は「申告値・未確認」と記録し、代わりに参加手続きが機能することを確認します。
7. URL は、その URL の状況を示す証拠であり、背後にある組織や人物についての証拠ではありません。 例を 3 つ挙げます。
   • 個人のドメインが放置状態または売り出し中でも、その人物が活動していないとは限りません。代理店の創業者の個人ドメインが売り出し中のページになっている一方で、その会社が毎週情報を発信していることもあります。その人物が実際に発信している場所（ポッドキャストのフィード、勤務先のページ、講演者一覧、ハブの著者プロフィールなど）をたどって確認します。
   • URL にアクセスできても、運営者が変わっている場合があります。この分野で最も深刻な失敗は、記憶に頼って使ったブランドのドメインが、無関係な事業者へリダイレクトされていたことでした。URL にアクセスできるかだけでなく、移動先の内容を確認します。
   • 推測したドメインで NXDOMAIN が返る場合、それが示すのは推測の妥当性です。組織を見限る前に、コードホスティングサービスで組織名を検索し、ドメインを推測するのではなく、登録されたウェブサイト欄を確認します。リポジトリを最終プッシュ日時で並べ、リポジトリの 説明 も読みます。非推奨の告知は、まずそこに記載されるからです。この分野を支える財団自体も、記憶に頼ったドメインではなく、コードホスティングサービス上の組織から、まさにこの方法で見つけられます。また、コミット日時は、取得ツールに「Loading…」だけを表示するホームページよりも信頼できます。

上記の更新期間（アクティブは約 3 か月以内、更新停滞は約 6 か月以上）は、業界標準ではなく、ここで独自に設定した基準です。年次調査や四半期レポートでは期間を広げ、日刊ニュースサイトでは短くします。

ウェブを一切閲覧できない場合は、references/sources.md に記載された一覧を、各項目の記録済みのステータスと日付とともに提示し、再確認できなかったことを明確に伝えます。ユーザーには、次の手動確認手順を案内します。

• 各 URL を開きます。
• 最新の日付入り項目を探します。
• 運営者を確認します。
• 上記の分類を適用します。

定期的な更新手順

ハーネスがスケジュールされたルーティンに対応している場合は、四半期ごとの更新を設定します。四半期ごとの頻度は、このスキル独自の既定の周期であり、公表された標準ではありません。対応していない場合は、ユーザーに定期的なリマインダーを設定してもらい（「DevRel レーダーを更新する — 四半期ごと」）、通知が来たらこのスキルを再実行するよう伝えます。

1. ユーザーが担当する柱を改めて確認します。DevRel の担当範囲は人員数の変化に伴って変わり、新しい柱が加わると、それを網羅する情報源が見つかるまで網羅性の保証は無効になります。
2. 前回機能していたものも含め、すべての URL を再確認して、名称変更、買収、ドメインの再販を検出します。
3. 鮮度と所有者を再確認し、新たに古くなった項目の評価を下げ、無効になったものを削除し、以前に検証できなかったものを再試行します。
4. ユーザーが前四半期に実際に利用した情報源を尋ね、利用されなかったものは削除します。読まれない情報源も注意力を消費するためです。ユーザーから制約が解消されたと言われない限り、制約を理由に削除した情報源を再提案してはいけません。また、手順 10 の順位付けを再実行します。勤務先の購読契約やカンファレンス予算が新たに加われば、情報源そのものが変わらなくても比率は変わります。
5. イベントカレンダーの更新は四半期ごとではなく、年に 2 回行います。CFP の締め切りはイベントの数か月前に設定されるため、古いカレンダーは読む機会だけでなく、登壇枠を逃すことにもつながります。
6. ピアコミュニティと最近追加した情報源に、それぞれ候補を 1 つ挙げてもらいます。ベンチまたはリストに追加する前に検証します。
7. 予算に照らして週あたりの推定時間を再集計し、超過分を削ります。

出力形式

ウォッチリストを 1 つ作成します。ヘッダーの冒頭では、これは特定の日に検証された厳選読書リストであり、モニタリングサービスではないことを明記します。ここに記載された情報源が停止してもユーザーに通知されることはありません。ユーザーが実行する更新手順で通知します。ヘッダーには、役割、担当する柱、エコシステム、時間予算、検証日を記載します。

利用頻度ごとにグループ化します。

• 週次の中核
• 月次
• 年次（データとイベント）
• ベンチ（検証済みの代替候補）

各項目には、次の内容を含めます。

• 名称
• URL
• メディア形式
• 対象となる柱
• 推定時間（分）
• 選定理由を一行で
• 販売しているもの
• ステータスと日付

各セクション内では、効率の高い順、つまり比率の高い順に項目を並べます。順序から暗黙に伝えるのではなく、その並び順をヘッダーに明記します。

最後に合計を記載します。

• 週あたりの推定時間と予算の比較。
• セクションごとの項目数。
• 有効と検証済みの項目数。
• 柱の網羅性を明記した行（「担当するすべての柱に、有効と検証済みの情報源がある：はい／いいえ」）。
• 削除済みの行。制約を理由に削除した情報源すべてと、削除の原因となった制約を記載します。

実例と否定的な例については、references/watch-list-example.md を参照してください。

オプションの 2 つ目の成果物として、同じリストを購読可能な形式で提供します。すべてのフィード付き項目を含む OPML ファイルで、どのフィードリーダーにもインポートできます。ユーザーがウォッチリストをリーダーに手入力しなければならない場合、読まれるのは一度きりです。

呼び出し例：

• 「DevRel レーダーを作ってください。API 企業で一人で活動するデベロッパーアドボケイトで、週に 1 時間ほど使えます。」
• 「今も実際に活動している DevRel のポッドキャストやニュースレターはどれですか？」
• 「Kubernetes ツールのドキュメントとコミュニティを担当しています。何を読めばよいですか？また、どのカンファレンスに応募すべきですか？」
• 「前四半期に作ってもらった DevRel レーダーを更新してください。」
• 「デベロッパーリレーションズ分野で誰をフォローすべきですか？その人たちは何を販売していますか？」

失敗パターン

• 情報源をでっち上げる。 DevRel の定番情報源は多くないため、ありそうな架空の番組やニュースレターを作り出すのは簡単で、リスト全体への信頼を一瞬で損ないます。各項目は取得したページに基づくか、未検証と明記されています。
• URL の判定を対象そのものの判定として扱う。 再販売されたドメインがまだ解決できる、個人ページがパーキングされている、推測したドメインが NXDOMAIN を返す――これらはすべて同じ誤りで、新鮮さと所有者の確認のチェック 7 で対処します。URL から推測せず、再実行してください。
• 日付は正しいが、所有者が違う。 主催者が変わったカンファレンスは、どんな新鮮さの確認にも通りますが、帰属先は誤っています。両方を確認してください。
• いつでも参照できる資料に、古さの判定を無理に当てはめる。 フレームワークやメンテナー向けハンドブックには、古さを判断する基準となる更新頻度がありません。
• 版と日付を示さずにベンチマークを引用する。 エコシステム調査は年次で行われます。統計だけを示すと、いつの間にか古くなり、経営陣向け資料で繰り返し引用されます。
• エコシステムの情報源だけで構成したリスト。 技術分野の情報源だけを追っていると、その実践自体を学べません。
• 何かを売ろうとしている人を全員除外する。 そうすると、この分野のリストは空になります。代わりに、項目ごとに利害関係を開示してください。
• 予算を超えて詰め込みすぎる。 予算に収まるように削り、候補リストを活用してください。
• ただの一覧にする。 重要度が同じに見える情報源が 12 件並んでいると、好みで選ばれたり、先頭にあるものが選ばれたりします。注意 1 分あたりの価値で並べ、並び順の根拠を明示してください。
• 安さで順位を付ける。 安さと効率の良さは異なる基準であり、「まず何を読めばよいか」に答えるのは後者だけです。5 分で読めるニュースレターから 5 分分の見出ししか得られないなら、それは誤差の範囲であり、手っ取り早い成果とは言えません。
• 比率だけで予算を使い切る。 それではポッドキャスト、講演、カンファレンス、コミュニティが一切選ばれず、長文コンテンツは毎回候補から外れます。その結果、ユーザーは何でも最新の状態ではあるものの、何も理解していない状態になります。最終決定の前に、ステップ 8 の昇格条件を確認してください。
• カンファレンスの費用を 52 週間に分散する。 その計算では、3 日間の出張がニュースレターより上位になります。ユーザーが費やすのは休暇日数として確定した日数なので、効率の軸には含めません。
• 除外すると決めた情報源を削除せず、順位を下げる。 経費精算できない有料コミュニティを最下位に置いたままにすると、次回の更新で再び対象に含まれます。削除し、その削除を明記してください。
• 注意を金額で評価する。 評価軸となるのはユーザーの注意と、休暇日数として確定した日数です。雇用主がすでに料金を支払っている情報源は、ユーザーに追加費用がかからないため、順位付けではなくステップ 10 の再順位付けで扱います。

測定

納品時の合格基準は以下のとおりです。

1. ユーザーが担当する各柱に、少なくとも1つの稼働中と確認済みの情報源があり、担当していない柱は水増しされていないこと — 絶対条件です。
2. 推定週間合計時間が予算以下であること — 予算はユーザーが決めます。媒体ごとの時間の目安は、このスキルが独自に設定したデフォルトであり、時間はこの計算にのみ使用します。
3. すべての項目に、販売を行っているかどうかのフラグとステータス＋日付が含まれていること — 絶対条件です。
4. すべての項目が取得したページにたどり着けるか、未確認である理由を明記していること — 絶対条件です。捏造した情報源はゼロ、未確認の項目を確認済みとして提示することもゼロにします。
5. 各セクションが注目1分あたりの価値順に並んでおり、その順序が暗示ではなく明記されていること。また、デフォルトの順序から変更した場合は、その変更を促した事実が明記されていること。
6. ユーザーの制約によって除外された情報源はすべて削除し、リストの末尾に残すのではなく、除外したことを明記すること。また、リストが長文コンテンツを含まない状態になっていないこと。ポッドキャスト、トーク、コミュニティ、カンファレンスのいずれも含まれていない場合は、ステップ8の追加条件を確認し、除外する理由を明記します。

四半期ごとの更新時には、さらに、ユーザーが項目の3分の2以上を利用したこと、および掲載されている情報源の所有者が変わった場合に項目が更新されていることを確認します。いずれかの条件を満たさない場合は、再確認、削減、または予備候補との入れ替えを行って修正し、すべての条件を満たすまで再提示します。

以下の数値基準はすべて、このスキルが独自に設定したものです。ユーザーが最後まで見ないリストは、いずれ使われなくなるためです。

• 約60分の圧縮しきい値。
• 媒体ごとの時間換算。
• 約90/10の配分と、2～3項目の予備候補。
• 3分の2の利用率。
• 四半期ごとの更新頻度。

ユーザー自身の利用データと合わない場合は、数値基準を変更します。変更しても順序は変わりません。ランキングは桁違いの規模に基づいて作成し、時間はリストの区切りを決めるためだけに使用します。

参考資料

• ./references/sources.md — カテゴリ別、日付入りの情報源リスト（実践者向けハブ、ポッドキャスト、ニュースレターやメディア、コミュニティ、イベント、データ、ベンチマーク）と、無効または転売と判断されて除外された項目。
• ./references/people-to-follow.md — 実践者と、その確認に使える媒体、販売フラグ、複数媒体での継続的な登場状況。
• ./references/watch-list-example.md — 作成例のウォッチリストと、望ましくない例。
• このコレクション全体にわたってタスクを振り分けるには、samber/developer-relations-skills@developer-relations-kickoff を参照してください。
• DevRel の職への就職や成長については、samber/developer-relations-skills@devrel-career を参照してください。このスキルでは、読むもの、視聴するもの、参加するもののみを厳選します。
• ここにあるデータソースを測定フレームワークの構築に使用する場合は、samber/developer-relations-skills@devrel-metrics を参照してください。
• ここでカレンダーから開催する価値のあるイベントが見つかったら、イベント運営について samber/dev-event-organizer-skills も参照してください。