見出し画像

DevRel/Japan CONFERENCE 2024に行ってきた

中村修三(ShuzoN)

2024/09/14開催、DevRel/Japan CONFERENCE 2024の参加レポートです。

会場

会場はdocomo R&D OPEN LAB ODAIBAです。何度か来たことがある会場なので馴染みの場所。

受付・スポンサー

devrel.tokyo の横断幕がかかった受付。トートバックと名札をもらいました。

見慣れたロゴの横断幕


DevRel/Japan CONFERENCE 2024のトートバック
ノベルティシール
今回のスポンサーさんはこちら

ブース

ブース出展を回ったのでセッションの前にまとめを！(セッション内容を書いたのであまりに長すぎた)

Findy, KEEN, Hexabaseさんがスポンサーブースに出展していました。

Findy

まずはFindyさんに行って驚いたのは「アンケートがデジタルで動いていること」。

デジタルアンケートパネル

EMの方が立っていたので聞いたところ裏側はReactで動いているそうで、DevRelチームからの要望で開発したとのこと。Findyレベルになるとそんなことが起きるんか…w

名物お守り

その奥にはガチャとFindyさん名物お守りがありました。

KEEN

KEENさんはコミュニティの中からスター顧客・スター社員を発掘・育成につなげるデータ分析サービス「KEEN Manager」を提供する会社。

プロダクト説明もさることながら缶バッチを作ってくれる企画が。

作ってもらった缶バッチ

調子づいた私も一つ作ってもらいました。カンファレンス、Xアイコンあると「あ～あの人だ！」となりやすいのでめっちゃありがたかったです。

Hexabase

(写真撮り忘れました、すみません)

Hexabaseさんは App ModelerというChatUIで要件を定義するとアプリケーションコードを生成してくれるサービスを展示していました。最終的にはインフラのデプロイまで勝手にやってサービスイン出来る状態まで自動化しようとしているそうです。ノーコードの意味変わり始めててすごい。

v0.devやGitHub Copilotなどと違い、AIが並走するのではなく、生成したものをそのまま実装・利用可能なレベルまで爆誕させる発想を本気でやろうとしているのは凄いなーと思いました。

ここからは参加したセッションサマリです。

DevRelこそ、プロダクトが愛され発展する源泉

slide: https://www.canva.com/design/DAGQs7I9HPo/EIutD2zr64P3O9eQtS39gA/view

KT
シニアプロダクトマーケティングマネージャー兼エヴァンジェリスト@Snowflake合同会社

DevRelは今の時代最も重要な取り組み
現時点では製品の機能差はほぼなくなっている

Snowflake, Tableauは最初はニッチプレイヤー。リーダーになると模倣されコモディティ化する。

ガートナー マジック・クアドラント

コミュニティが差別化要因になる。隣人がつかっているものがつかっているものは愛されていることが信用になり選ばれる理由になる。

自分が選んだ選択が正しかったと自信を持てる。これがコミュニティの力。信念とヴィジョンを理解したコアコミュニティのユーザの声を聞くことが大事。

Snowflake, Tableauの事例から

有志のイベントで毎度1000人を超えてくるイベントシリーズ。このイベントで確実に認知やつながりを獲得してきた。

イケてる製品だからコミュニティがあるのではない。
コミュニティがあるからイケてる製品なのだ

Tableau DATA Saber プログラム、90日でクリアするプログラム。師匠を見つけなければクリアできない。師匠も被育成者もTableauユーザ。そのようなセルフドライブ(再帰的・有機的)な仕組みになっている。人事制度の中に組み込まれている。

Land & Expand戦略、使いたい人が使うのはいいがそれだけでは全社展開されない。Expandにはチャンピオンが必要。2種いる。チャンピオンAは技術的な実力がある、チャンピオンBはビジョンがあり推進力がある。前者はヘルプデスク的に振る舞ってしまい一人で終わる。後者は技術が分からず進めようとしたときに先が見えずその後に繋がらない。

だからこそどちらも必要。それを補うためにDATA Saberを作った。

3ヶ月で未経験から全社導入までこぎつけ育成レイヤまで成長した。他のアンケート結果には「参加者同士のつながりにかけがえのない価値があった」と書いてあった。とはいえ、大体1年ほどで実績につながる。結果、2年で105人育てた。

KTがどうやって認定しているかわからない

というFBから認定基準(クライテリア)を作った。その後、5年で2,285名認定した。結果として、外部メディア、SNS、海外認定プログラムに選ばれ、新規プロダクト開発をやっている卒業生が起業したり執筆している。

それを生み出していくためには以下が必要

  • スキル、ビジョン、コネクションが大切

  • 仕組みと情熱を高いレベルで継承している

仕組みと情熱はきれいに独立させる。仕組みは標準化していき属人性を廃する。しかし、情熱は属人性があるその熱量は人に依存する。

Snowflakeでセルフドライブコミュニティを再現してみよう

社長にはまだ早い、と言われていたがコミュニティを作り始めた。

SnowVillageというコミュニティを作った。「みんなの心のコミュニティに」をテーマに。すでにフルセルフドライブなコミュニティになった。

天然チャンピオンがチャンピオンA/Bを育成していった。そういったメンバーが良いコンテンツを生んで巻き込んでいくことでデータドライブな世界観や動きがコミュニティからにじみ出てきた。

早く仕組みを渡すことはできるが、素っ気なさが理由に熱量を冷ましてしまう。だから、やり方を伝えて

  1. 最初はSnowVillageの入り方を決めてまとめた。

  2. 空っぽのチャンネルがないように自発性を保てる状態で仕組み化していく

完全セルフドライブへの奇跡

  1. 私が企画して、人を集める

  2. 私が企画して、スピーカーを集める

  3. トピックを決めて、企画を集める

  4. やりたいなと行っている人がいたらやりなよ、という

  5. 場や仕組みを用意してあとは自由にやってもらう

学び

  • いつか帰ってこれるところになる。楽しい場所に人は帰って来る

  • どれだけ沢山の人の人生を変えることができたか

発信を応援する、そうするとプレゼンスが上がる、それを元に人が集まる、それがサイクルを成していく。それが個々人のキャリアを作っていく。

なぜビジョンが必要なのか

  • ビジョンが共有されていないと、製品が使えないときに人が離れていく

  • 技術を極めた人たちをまとめるものがビジョン

コミュニティーマネージャー…(聞き取れなかった)。エヴァンジェリストは未来に対する創造性を描ける人。コミュニティのリードメンバ。ビジョンに共鳴しそれを体現する発信。アトモスフィアを創るのが役割。経営者、マネジメントはコミュニティのサポート。売上に直接的に繋がらないものを切り捨てる姿勢はコミュニティを壊す

今の仕事を人に渡すことを前提にしていく。

QA

Q. 仕組みと情熱、どちらを重視して人を選ぶ？
A. 足りない側面を育てる、が私の回答 

Q. 経営者がコミュニティに理解がない。どう向き合うかを示唆するには？
A. 相手のベネフィットになる行動をする。相手の仕事がやりやすくなるように振る舞いを変えていく。コミュニティの発信を属する組織のベネフィットに沿うような発信にガイドしていく。そうすると合目的な発信や成果といった実績がコミュニティの信用・信頼につながっていく。

どの種は何の花を咲かす？DevRelのターゲットオーディエンスを知ることの意味

萩野 たいじ
Senior Develoepr Advocate@Datadog

DevRelとは、企業や技術コミュニティと開発者の関係を強化し、技術や製品を効果的に利用できるよう支援するための取り組み。

DevRelは種まき。短時間で目が出ることを期待されても困る。

正しい場所に種を蒔く(潜在的なターゲットへのリーチ)、然るべきステップを育て上げて(イベントなど)、芽が出る(コアユーザを生む)

技術広報のアクティビティはさほど変わらない。ターゲットユーザが違う。

種を蒔く人とその畑

  • 人: 企業での立ち位置は何なのか

    • ビジネスゴール、KPI，OKRとは

    • 短期的なKPIを作り、その達成率を元にFBサイクルをかけていく

  • 畑: 自分の仕事の市場はどこなのか

    • 業種・業界、ポジション・役割

どういった花の種を蒔く？

ターゲットオーディエンスは誰なのか = 開発者

ターゲットは何を求めているかというと最終的に求めているものは「ベンダーが自分たちの状況を個別に理解してくれてかゆい部分にちゃんと手を伸ばしてくれる」こと。それを含めてImproveしていく開発者コミュニティやエコシステムを求めている。

  • ターゲット像

    • 製品開発エンジニア: 製品に関するFBや改善点の提供 新しいニーズや市場トレンドの共有

    • 受託開発エンジニア: NDAに縛られていることへの理解・共感 工数管理配下での効率的な勉強方法。技術的なサポートや知識の共有

    • 研究職エンジニア: 新技術に対する実証実験や検証の支援。対象技術の第一人者とのコネクション。多分野の専門知識や技術リソースの共有

    • CIO/CTO: 最新技術や業界動向に関する情報共有とインサイト。他企業や専門家との連携によるコラボレーション

    • スタートアップ: ビジネスや技術に関するFBやアドバイス。資金調達やパートナシップ

    • 学生: 技術的なスキルの支援やメンター提供。実践的プロジェクトやインターンシップ提供。実践的事例の共有

アプローチや咲かせる畑は違うけれど、咲かせる花は同じ。相手の求める「自分たちの状況を個別に理解してくれてかゆい部分にちゃんと手を伸ばしてくれる」を実現すること。

ゼロから始めたコミュニティの歩みと学び

@HiraokaDaisuke
日本アイ・ビー・エム株式会社

技術営業がIBM Instana Observabilityコミュニティを作り始めた話。とはいえno sell, no jobという攻めた設計。

  • 1no1で各部門との調整。継続的な発信・飲みニケーションで信頼値を稼ぐ

  • カスタマーサクセス部門tの連携は特に相性が良い

  • 外部連携は積極的なユーザやパートナーと1on1 mtgによって協力体制を創る

自分の思いを伝えて友人関係からのスタートが成功の鍵。ユーザコミュニティを一人でやっていたが、優秀な人をIBMチャンピオンに据えて登壇機会を作っていく。

同じ思いの人が2人でもコミュニティとして成立する。お誘いするのも恋人に告白するような感じで進んだ。

2023年6月のイベントから立ち上げていった。

参加者エンゲージメントを高める工夫

  • ハッシュタグやロゴの活用

  • お寿司をデプロイ

  • SNSのリアルタイム投稿

    • 営業を巻き込んでいく理由になる

    • アドベントカレンダーでネタを埋めていく

  • 製品の方向性を本国から聞いてシェアする会

  • 定期イベント開催とコミュニティ運営

  • 国内のユーザさんにメールして登壇をお願いする

    • 声掛けし続けたらイタリア政府が出てきた

製品を良くするために表で喋る。喋ることで仲間が増える。製品のカスタムリクエストが増える。投票が起きる。そのサイクルが製品を良くする。

エンジニアと関係組織をつなぐ社内 DevRel のとりくみ

@Mahito

社内 DevRelをしている理由

  • 社内のエンジニアが抱える課題を解決するための取り組み・役割

  • 社内ののエンジニアを繋いで良い関係性を作っていく

    • EMよりはDevRelより

エンジニアと関係組織の良好な関係が会社を良くする。理由がわからないものが来る、言ったけど変わらなかったなど不信感が募ると良いものが生まれづらくなる。それらを橋渡しすると会社がうまく回っていく。

対話による相互理解と課題の共有、行動に寄る実績の積み重ね

検証機の改定

会社PCはほぼ事務向け。検証機はセキュリティ的に社内ネットワークに繋げないため資料やメールにはタッチできない。そこでMacなど検証機を利用できる用に提案。

話を情報システム部門・セキュリティ部門に伝えたところ、セキュリティ部門が乗ってきて実行することに。Goサインが出る部分までの検証を数名のエンジニアで進め、社内利用者コミュニティを募ってみると徐々にエンジニアがセルフドライブ的に動くように。

エンジニアが1日Macから仕事できる状態に。

ドレスコード改定

OK: 会社の規定では襟付けシャツ、ポロシャツ
NG: Tシャツ、ジーパン

対話会を私用、という話を労組やエンジニア、総務を巻き込んで進めてみるとTPOをわきまえていればOKというルール改定に。

まとめ

お互いのベネフィットをつなぐ。社内のコミュニティを作ることでお互いに助け合うことが出来る。

Zenn 運営が集計してわかったテックブログの"定石" 継続とエンゲージメント獲得に受けて

小山正博
クラスメソッド株式会社

DevRelとは

  • Zenn上で、製品と開発者の関係構築を行っているpublication

  • 企業・組織のブランディングのために運営されているテックブログ

どちらかというと後者を前提に。

Zenn Publication Top20

<画像>

運営されている企業を抽出。著名な会社であればフォロワーが増えていくわけではない、工夫でエンゲージメントを獲得できる。

運営継続・エンゲージメントの獲得

  1. 人数を増やす

  2. いかに人数を増やすか

  3. 編集長を決める

  4. 言葉遣いが良い

人数を増やす

最後の記事から1ヶ月立つと熱量が冷える。感覚が短くなると繋げられていくとブログの熱量が維持できる。

publicationで平均33名、投稿者数は24名。投稿頻度は7.3日に1本(中央値)。

いかに人数を増やすか

オンボーディングにブログアカウントの追加を乗せる。

  • 執筆のメリットを伝える

    • ブログを書くことで学びを定着できる

    • 個人のポートフォリオになる

  • 会社への貢献にもなる

    • 商談や問い合わせ時にブログへの言及があった

  • 多様なメンバーを巻き込む

    • 初心者〜上級者向けにまばらに巻き込む

    • 社歴長い人はたまにでいいから

編集長の業務

  • 日々の業務を元にブログのネタ出し支援

  • モチベーション維持

  • 公開したときの社内外へのシェア

シリーズコンテンツを創る

週刊で連載。週ごとの勉強会をブログにして1粒で2度美味しい。

  • 領域ごとにトピックを決めシリーズにしていく

上層部の理解

運営目的と長期的なビジョンを経営層と共有。小さな成果はまめに上層部に伝えていく。持つべき指標は本数を目標に。コントロールできるものをKPIにする。

長期間かかる & KPIはアウトプットのみ = "横槍"が入りやすい = トップダウンが望ましい。

エンゲージメントの獲得

エンゲージメントするものによって出すものを変える。

  • 組織: 取り組みの紹介

    • 背景から課題の解き方を詳細に書く

  • 商品: 機能の紹介

    • 説明書ではなくユースケース単位で書く。コードブロックをつかったり丁寧に

  • 理解しやすい記事を書く

    • コードブロック、画像を多く使い伝わりやすいものに。

  • 言葉遣いが良い

    • レビューは原則ないのが良い。真面目に発信してね、を言い続ける。

トピックは良い記事に吹く"追い風"

あくまで中身の質が大切で、流行りのトピックは追い風。

イマこそ、”Dev””Rel”なのでは？？ ～VUCA時代を乗りこなすDevRelの価値と本質～


おだしょー(小田祥平)
mabl Quality Advocate

意思決定に影響を与える要因

LLMは面倒なことをやってくれるが結局は意思決定まではやってくれない。そこは人間の仕事として残っている

DevRelの仕事

DevRel、特にアドボケイトの仕事は意思決定レイヤの人たちに向かって、現場の意見を拾い上げながら公平性や透明性を持った意見を伝え、納得感を持って導入をすすめてもらう必要がある。

VUCA時代を乗りこなすDevRel戦略

アドボケイトはその人がいいといったものは間違いないと思わせないといけない。技術的な透明性や公平性があるから説得力やプロダクト価値を訴求できる。そのために技術的なキャッチアップを欠かさず常にニュートラルなポジションに立つ必要がある。

それを支えてくれるのがコミュニティ活動。この営みの中でニュートラルさを保ちながらVUCAな変化に追従していく。KTさんの言ってた通り、返ってくる場所を作っていくことが長くやっていくなかでは大切。

この辺で集中力が切れてしまい、リアルタイムメモが取れなかったため後日の印象で書いています。

DevRel 環境の変化に伴う体制の立て直しと新たなデベロッパーアドボカシーの確立について

@shosuz
プリンシパルエンタープライズアーキテクト @VMWare

20年のDevRel人生を振り返り、潮流が変わる中で「変わることがなかった行動指針」を教えていただきました。

行動指針

組織や環境の変化に対応するため個人としての柔軟性を保ちつつ、冷静に実行できることをやる。組織自体のニーズも変遷していくからこそ、個人としてのブランディングも確立していく。手詰まりにならないように後進を育てる。

時代が変わっても変わらないものを見極める審美眼という点では、t-wadaさんの審美眼スライドに近く、DevRelにおける不変さを学べた発表でした。

終わったあとは顔見知りやその日知り合ったDevRelの方と飲み！楽しかった！

DevRel初めて2年弱。CfPも出しましたが落ちたためちょっと悔しかったのが本音でした。帰り道で感じたのは「他社に比べてCARTAは全然"量"で負けている」こと。もっとやらねば…！と決意しながら帰りました。

めちゃくちゃいい刺激を受けたカンファレンスでした！以上まとめでした！

いいなと思ったら応援しよう！