q
devrelの方向性を c- で揃えたい。
他に何がある？
a
「C」で揃えるなら、DevRelの方向性としては例えばこんなのが定番です（粒度いろいろ）：
- Communication（発信・対話：SNS、イベント登壇、ユーザー/開発者との継続的な会話）
- Connection（関係構築：1on1、キーパーソン連携、パートナー/アンバサダー）
- Collaboration（共創：共同開発、OSSコントリビュート、共同検証、Co-creation）
- Contribution（貢献：OSS/コミュニティへの貢献、バグ報告、ドキュメント改善の促進）
- Customer（顧客理解・顧客価値：フィードバックループ、課題発見、導入支援）
- Care（サポート/体験：オンボーディング、DX改善、開発者体験のケア）
- Credibility（信頼：技術的信頼の獲得、透明性、事例/第三者評価）
- Consistency（一貫性：メッセージ/ブランド/トーンの統一、継続的運用）
- Conversion（導入・活用につなげる：リードではなく“開発者の成功”に寄せた獲得・定着）
- Craft（品質：サンプル、SDK、ツール、ドキュメントの作り込み）
- Catalyst（促進役：コミュニティや社内意思決定を前に進める、摩擦を減らす）
いまの Community / Contents に並べるなら、個人的にはセットとして収まりがいいのは
Communication / Collaboration / Contribution あたりです。
目的（認知・獲得・定着・プロダクト改善・OSSなど）に合わせて「Cの3〜5本」に絞ると綺麗に整理できます。どのゴールに寄せたい？
q
コンテンツをつくり、それを届ける手段として community がある、という構図にしたい。
この前提で、どう整理できる？
a
前提（Contents を作り、届ける“チャネル/場”として Community がある）に合わせるなら、DevRelを「制作→配信→循環」の流れで C で整理すると綺麗です。
1) まずは中核：Contents（作る）
- ドキュメント、チュートリアル、サンプル、ブログ、動画、登壇資料、ユースケース、FAQ など
- 目的は「理解させる」「成功体験を作る」「再現可能にする」
- 勉強会、Discord/Slack、フォーラム、ミートアップ、アンバサダー、ユーザー会
- ここは“コンテンツ流通”だけでなく「反応を集める装置」でもある
この2つを軸にすると、他のCは 役割が被らない補助輪として置けます。
A. Contents（制作）
何を作るか、どの深さで、誰向けに作るかを定義
コンテンツを届ける導線（イベント、SNS、コミュニティ運営、アンバサダー等）
C. Communication（編集・伝達設計）
「作ったコンテンツを、コミュニティで“届く形”にする」機能
- メッセージング、ストーリーテリング、投稿設計、登壇、告知運用
- Contents と Community の“接着剤”にするイメージ
D. Cycle（循環：学び→改善）
Communityから得た声を Contents に戻して改善し続ける
- フィードバック収集、インサイト化、プロダクト/ドキュメントへの反映
- 「作りっぱなし・やりっぱなし」を防ぐ
この形だと、Community が「手段（流通/回収装置）」として明確に位置付けられます。
もう少し“DevRelっぽい”拡張：5C（Cycleを2分割）
上の4Cの「Cycle」を分けて、より運用しやすくします。
- Contents：制作
- Community：流通の場
- Communication：届け方の設計（編集・発信・登壇）
- Capture：声を集める（質問、課題、要望、成功例）
- Continuous improvement：反映する（コンテンツ/プロダクト/オンボーデ改善）
どれを採用すると楽か（判断基準）
- まずシンプルに回したい → 4C（Contents / Community / Communication / Cycle）
- 「収集」と「改善」を担当やKPIで分けたい → 5C
必要なら、あなたの組織のゴール（認知/プロダクト改善/導入支援/OSSなど）に合わせて、この枠にKPI例まで落として整理案作れます。どのゴール寄り？
q
Contents -> Community, Contribution
この整理はどう？つまりコミュニティをつくる方向性と、githubにドキュメント公開して使ってもらうなど貢献の方向性がある。
私は devrel は community に寄りすぎてると思ってて、後者 contribution の方にも力入れたいんですよ
a
良い整理です。「Contents を作る」→「外に届く回路が2系統ある」として
- Community（人・場に届く）
- Contribution（エコシステム／成果物に届く）
に分けるのは、DevRelが“コミュニティ運営に寄りすぎる”問題を是正しやすいです。特に Contribution を独立した柱にするのは筋がいいです。
3Cとしての位置づけ（おすすめの定義）
1) Contents（中核：資産を作る）
- ドキュメント、チュートリアル、サンプル、SDK、動画、設計ガイド、ユースケース
- 成功体験を「再現可能な形」に落とす
- 勉強会、Discord/Slack、フォーラム、アンバサダー、ユーザー会
- 役割は「流通」と「関係性」。熱量・事例・学びが生まれやすい
3) Contribution（定着：外部に“残る形”で貢献し、採用を進める）
ここを「GitHubに置く」より広く捉えると柱になります。
- OSS/Docsの公開・改善（自社/他社OSSどちらも）
- issue/PR を受け付ける運用設計（CONTRIBUTING、テンプレ、CI、レビューSLA）
- 他プロジェクトへの互換性対応、examples提供、バグ報告、仕様議論への参加
- 「使われる」「混ざる」「残る」状態を作る
Community が“場”、Contribution が“公共財（コード/ドキュメント/標準/互換性）”という違いにすると、被りが減ります。
- Community：参加者体験・場の運営が主目的（イベント、モデレーション、会話）
- Contribution：リポジトリ/標準/他OSSなど“外部成果物の前進”が主目的（PR、issue、リリース、互換）
同じ活動でも、アウトカムがどっちかで分類できます。
例：勉強会で得た要望を「議事録で終える」→Community寄り／「issue化してPRまで出す」→Contribution寄り。
3Cを回すループ（運用の骨格）
- Contents を作る
- Community で届けて、質問・事例・反応を得る
- 反応を Contribution に変換して（issue/PR/改善提案/サンプル追加）、成果物を強化
- 強化された成果物がまた Contents になって配られる
この「Community → Contribution への変換」を明示すると、あなたがやりたい“後者に力を入れる”が組織に伝わりやすいです。
もし補助のCを1つ足すなら（任意）
3Cが綺麗なので必須ではないですが、運用上は Capture（収集）を足すと強いです。
- Capture：Community/SNS/サポートから得た声を、issue・改善計画・コンテンツ要件に落とす機能
（「集める」を独立させると、Contributionが回りやすい）
この3Cでいくなら、次は「Contributionの守備範囲」をもう一段具体化すると設計が固まります。例えば “自社OSSを育てたい”のか、“他OSS/標準への貢献で採用障壁を下げたい”のか、どっち寄りですか？