自社のことを理解し、自社製品について知り、コミュニティとつながる。
この記事は、Alex Trost さんがブログで公開している 「Starting Strong in Developer Relations」の日本語訳です。
今回 Alex Trost さんに許可をいただきましたので、Qiita に投稿します。
はじめに
DevRel としての良いキャリアを築くには、自社のこと、自社製品について、そして(その製品を使う開発者の)コミュニティについて理解するところから始めましょう。これから始めようとしている活動の全ては、この基礎知識の上に築いていくものなのです。
アイデアを出しっぱなしにするのはやめましょう。何をすれば一番インパクトがあるのか、情報をもとに判断しましょう。最初にやらなければいけないのは、質問をすること、聞くこと、そして理解することです。
そこから得られるものは、
- より大きなインパクトを、より早く
- 実際にコミュニティの役に立ち
- あなた自身のキャリアがより早く成長し
- 高い品質のコンテンツを生み出し
- あなた自身の仕事をもっと楽しむ
といったことに他なりません。
この記事がカバーする内容
この記事では、次に挙げる３つの領域に関して取り上げます。
- 会社 - あなたに給料を払い、製品をつくる人たち
- 製品 - 会社がつくるものであり、コミュニティが使うもの
- コミュニティ - あなたの担当する製品を使う人たち
この記事が想定する読者
- 最近着任した DevRel は、着任した会社で仕事を始める際、揺るがない理解を持って、力強くスタートする際の助けとなるでしょう
- 現役の DevRel は、知識の中の抜け漏れを埋めることで、チームの中で気づきを共有したり、新任のDevRelのオンボーディングを早く進められるでしょう
- DevRel になりたい人は、面接の際にここで挙げられている質問をぶつけてみることで、このDevRelというロールについて、より深く理解することができるでしょう
このガイドを、旅行時の荷物のチェックリストのように使ってください。そうすれば、忘れ物はないか、不安に感じることなく、DevRel という旅の準備が効率的にできるのです。
自分が DevRel を始めた際にこんなガイドがあったら、そんな思いを込めたガイドです。正直なところ、私自身は苦労してやっと気づいたり、数々の間違いを繰り返してきましたが、このガイドがあれば、そんな苦労をせずに済むのです。
自社のことを理解する
まずは自社に関わるあらゆることについて、知っておくようにしましょう。会社の目指すゴールや、提供価値、業界におけるポジションや自社の信念といったことが挙げられます。こういったことから、提供する製品やコミュニティに関する重要なコンテクストが得られるのです。
自社のミッションとビジョンは何か
ミッションとは、会社にとっての「どうして」です。コードを提供する理由は何で、世界をどのように見てインパクトを与えようとしており、コミュニティに何を提供しようとしているのでしょうか？
いくつかの会社のミッションを見ていきましょう。
- Patagonia: 私たちは、故郷である地球を救うためにビジネスを営む。
- Honest Tea: おいしくて、健康的なオーガニック飲料を作り、世に広げる。
- Prezi: 人々が知識を共有し、ストーリーを語り、見ている人に行動を促す方法を改革する。
- Microsoft: 世界中のそれぞれの国において、ローカルでのチャンス、成長、そしてインパクトを生み出すことを追求する。
あなたの会社にミッションがないのであれば、自社のビジョンは何だと思うか、同僚に聞いてみると良いでしょう。
DevRel 活動において、あなたは会社や製品の顔として活動するのですから、その活動で体現しようとしている自社のミッションを知っておくことは助けになります。
自社にとってのゴールは何か
ゴールとは、会社にとっての「何を」です。今年やろうとしていることの達成度を、何をもって計測するのでしょうか？
- DevRel チームがインパクトを与えること期待されてるのは、どのゴールか？
- それらのゴールをいつまでに達成すれば良いのか？
- 達成度はどのように計測されるのか？
これらを理解しておくことで、ゴールから逆算して活動内容を計画することができるのです。会社のゴールを決めたのは DevRel ではありませんが、DevRel も同じ方向を向いて活動していくのです。
自社の競合はどこか
自社の競合はどこなのか、競合と自社との違いは何なのか、知っておきましょう。
- 自社にも競合にもある機能は何か？
- どちらかにしかない機能は何か？
- 客観的に見て、自社であれ競合であれ、その製品を薦めるのはどのような状況においてなのか？
- 競合との比較において、自社をどのように位置付けているのか？
- 両社のコミュニティ(ユーザー層)はどのように異なるのか？
重要なことは、それぞれ競合しているのは「会社」であって、あなた個人ではないということです。競合のDeveloper Advocateに対しても、あなたは友好的でいるべきです。「あなた」のライバルではなく、あなたと同様に友好的な開発者であって、違う会社で働いているだけなのです。
DevRel の成功をどう測るか
DevRel 活動が長期において与えるインパクトを計測する方法は、企業ごとに異なります。
ある会社ではサインアップした開発者の数を見ているでしょうし、他の会社では開発者イベントの参加者数を見ているでしょう。あるいは、オープンソースへのコントリビューションで測るといったケースもあるかもしれません。
あなたが DevRel として聞くべき質問は２つあります。
- 成功であると評価する上で、どのようなメトリックスをトラッキングするのですか？
- そのメトリックスをトラッキングする際に使っているツールは何ですか？
会社のゴールと同様に、あなたの活動も見える化する必要があるのです。
ステルスジェットであれば、レーダーに捉えられないことは素晴らしいことですが、メトリックスで捉えられないようなステルスな活動は素晴らしくもなんともないのです。
チームについて理解する
あなたが一緒に仕事をする人や、タッグを組む人たちはだれでしょう？ 同じチームに所属してはいても、別のロールなのかも知れません。そうだとしても、チームの誰もが Developer Experience (開発者体験)をより良いものにするために働いているのです。
チームについて理解する上で、いくつかの重要なことを挙げておきます。
- あなたはなぜこのチームにいるのか？
- あなたがすることを期待されているのは何なのか？
- チームの大きさはどのくらいか？ (小さなチームであれば、一人でいくつかの役割を担う必要がしばしば生じます)
- チームのゴールは何なのか？
- ゴールを設定するのは誰で、ゴールの達成度チェックや見直しはどのくらいのペースで行われるのか？
- 今四半期はどのような活動に取り組んでいるのか？
- チームや会社全体はコミュニティとどうつながっているのか？
- どのような定期イベントを計画しているのか？
- コミュニティのゴールは何なのか？
DevRel ロールとは
あなたの上司やチームは、DevRel ロールであなたが何をすると考えているのでしょう？ DevRel や Developer Experience に期待されている役割には、次のようなものが挙げられます。
- ドキュメントを書くこと
- ポッドキャストやライブストリームを配信すること
- チュートリアルを書くこと
- コミュニティを管理したり、成長させていくこと
- 人やコミュニティをつなげること
- イベントを計画すること
- デモやサンプルを作成すること
- カンファレンスに登壇すること
- ソーシャルメディアで発言すること
これらの中から、いくつかのタスクに注力することになるでしょう。
- Developer Experience Engineer であれば、エンジニアと情報発信の両輪
- テクニカルライター であれば、主業務はドキュメント作成
- コミュニティマネージャー であれば、イベントの計画やコミュニティとのやりとりに注力
- Developer Advocate であれば、一般的にはコンテンツの作成と、コミュニティへの発信
こういったロールの区分や担当業務は、ソフトウェア業界においても標準的な定義があるわけではありませんが、チームや上司と意思疎通をしっかり取ることで、この先、フラストレーションを感じることを防ぐことができます。
DevRel が属する組織は
あなたのチームは、会社の組織図の中でどこに属しているでしょう？
DevRel は一般的に
- 製品部門
- エンジニアリング部門
- マーケティング部門
- 独立部門
に属しています。したがって、これら所属部門のゴールが DevRel 部門のゴールを決定する上でも、影響を与えるのが一般的です。所属部門という重要なコンテクスト抜きに考えていると、何かを決める際に、混乱を招くこともありうるでしょう。
他のチームについて理解する
チームの成功であっても、DevRel チーム単体で収めることはできません。数多くの社員が Developer Experience に何らかの形で貢献してくれているのです。したがって、社内組織を横断する形で関係を築くというのは、素晴らしいアイデアです。
会社の中のさまざまな人やチームと定期的にミーティングを持つようにしましょう。参加者は多すぎない方が良いでしょう。１回のミーティングは１つのチームから３人までに留めるのが良いかと思います。
ミーティングでは相手に質問をしたり、話を聞くようにします。
- あなたに知っておいてもらいたいと思っていることは何か？
- あなたと一緒にどのように動きたいと思っているのか？
- どんなユーザーと会話したいと思っているのか、そこから何を知りたいのか？
- 相手が抱えている問題は何か？
- あなたやあなたのロールについてどんなことを知りたいのか？
このようにして、今、関係を築いておくことで、この先、プロジェクトで一緒に働く際に、よりスムーズに進めることができるのです。加えて、自社の製品について、さらに知りたい際に、ここで築いておいた関係をもとに、誰にコンタクトを取るのが良いのかがわかってくるのです。
自社製品について知る
あなたが DevRel ロールで関わっている製品について、経験を積むことでより深い理解ができるようになってきます。それにより、次に挙げる活動を進めることができるでしょう。
- トレーニング用のコンテンツを作成して、実際に使い方を教える
- そういったコンテンツをコミュニティに紹介する
- ユーザーが感じている問題や対処法を吸い上げる
- 自社のプロダクトチームに対してフィードバックする
ここで挙げた一連の活動は、会社によっても進め方が異なるでしょうし、同じ会社の中であっても、製品ごとに異なるかも知れません。
Shopifyのような企業向けの複雑なソフトウェアの場合、数十の複雑な機能の枠があり、それらの枠ごとに開発者が利用できる機能が数百の単位である、という場合もあります。コアプロダクトについて学ぶだけでも数週間かかるといったケースもあるでしょう。
製品について学ぶ際には、できるだけ早く理解したいと思うのは当然ですが、急ぎ足で進める必要はありません。初心者の目線から製品を見ることができる期間にも価値があるのです。
新人の気持ちでいよう
自分が関わる製品に関して初心者であるとしても、それは「素晴らしい」ことなのです。そこには貴重なチャンスがあるからです。
私はその貴重なチャンスを、無知からの贈り物と呼んでいます。
全くの新規ユーザーの気持ちを「心から」理解できるのは、この時をおいて他にはないのです。
製品についての理解が進むにつれ、知識の呪い があなたを襲うことになるのです。つまり、何かを説明しようとする際に、経験者は初心者だった時のことをすっかり忘れてしまうのです。git を勉強し始めた頃、「rebaseして、pushをforceすればいいんだよ」といったアドバイスをされたことはありませんか？
あなたの手元にまだ「無知からの贈り物」が残っているのであれば、それを大事にしてください。
自分が関わる製品に関して、以前にも使ったことがあるというのであれば、その製品を新しい目で見るように心がけてみてください。Developer Experience の向上において、これは重要なスキルです。私は常日頃からこういったことを問いかけています。
- 自社のプロダクトは初めて使う人にはどのように見えているのか？
- どのような知識を持っていることを前提にしているのか？
- 初めて使う人がつまづきやすいポイントはどこなのか？
自分が初心者であれば、その自分の経験を記録として残しておくべきです。
- 理解しづらかった考え方は何か？
- ドキュメントを呼んでいて、わからなくなってしまったのはどこか？
- 実際に動かしてみる前には、どういった動作をすると想定していたのか？
つまづいたり、わからなくなってしまっても、自分を責める必要がありません。むしろ、ちゃんと記録を取っておくことで、後になってあなたと同じ問題で困っている人を手助けできるからです。
実際に使ってみる
あなたがどのような製品を担当するにせよ、その製品の使い方をしっかりと理解しておきましょう。
オンボーディングの機会に、その製品を使っていくつかのプロジェクトを開発してみましょう。プロジェクトでは、その製品が一般的に使われるユースケースのトップ３をカバーするようにしましょう。例えば、コンテンツ管理システムであれば、ブログ、アプリケーション、マーケティングページの３つになるでしょう。
次に、「理解しやすいチュートリアル」から離れて、実業務に近い状況を想定して開発をしてみましょう。
プロジェクトを作成して、開発を進めようとしても、１週間の中でなかなか前に進まず、何度も後戻りすることがあるでしょう。チュートリアルではない、実際のサイトやアプリケーションを開発する中で、毎日の作業内容を記録していきます。プロダクトによって、実際の作業内容は異なるでしょう。
このようなレベルの知識こそが、会社にとっても、コミュニティにとっても価値のある知識なのです。ここでの気づきをプロダクトチームに共有することもでき、また、ユーザーがさらに難しいポイントで苦労したとしても、助けてあげることができるでしょう。
強みと弱み
自分の担当する製品を使って、実際に開発をしてみたら、その製品についての意見を同僚にも聞いてみましょう。
- 製品の強みは何か？
- 製品の弱みは何か？
- 製品の中で好きなところは？
- 製品の目玉機能は何か？
- もう一つ機能を追加するとしたら、どんな機能か？
- この製品で完璧に解決できるようなユースケースは？
- この製品があまり得意としないようなユースケースは？
こういった質問は、あくまでも自分で製品を使ってみて、また自分の意見を出した上で聞くようにしましょう。また、出てきた意見が意外なものだったとしたら、実際に製品を使って、自分でも確かめてみるようにしましょう。
ドキュメントを読む
自分の担当する製品のドキュメントを読みましょう。ドキュメント全体を、先頭ページから末尾のページまでです。
製品を理解することで初めて得られることもあれば、見過ごしていた機能を発見することもあるでしょう。常にドキュメントを参照することで、どんなことであっても、何がどこに書いてあるのか、わかるに越したことはないからです。
ユーザーが製品を正しく使う上でも、ドキュメントは重要であり、またドキュメントは製品の中心であるとも言えます。ですから、ユーザーがこの先ドキュメントから得られるであろうことに関して、あらかじめ知っておくべきです。
メモを取る
「どんなことであっても」、メモを取っておきましょう。とりわけその製品の DevRel 職に就いてからの最初の何か月はそうしましょう。
メモにはどんなことを書けば良いのでしょうか。
- 製品に関して分かりにくかった点
- 製品を使ってみて嬉しかったのはどんな時か
- 最初はわからなかったけれども、後になって理解できたこと
- 使ってみてびっくりしたこと
- 開発時に手が止まってしまうポイント
- 今後適用してみたい分野
- 製品の重要なコンセプトを自分の言葉で説明するとしたら
また、ある程度の時間が経ったら、こういったメモも役に立つでしょう。
- 今後入社する DevRel 職のオンボーディングで、変えた方が良い点
- 自分が分かりにくかった点やその際に感じたこと
- ブログなど、簡単に作成可能なコンテンツ
- 同僚と会話する中で、自分が気づいた勘違い
完璧な製品など存在しない
製品について、いろいろなことがわかってくる中で、たくさんのバグを見つけたり、未解決の問題に出くわしたり、直した方が良い点も見えてくるでしょう。これは特定の製品に限った話ではありません。あなたが、Apple や Google、Microsoftで働いていたとしても、未解決の問題は山ほどあるし、不満を持っている顧客だっているのです。
完璧ではない製品であっても、プライドを持ってその製品を担当しましょう。その製品を開発するために全力を尽くしている、とはいえ完璧ではない人間に対しても、寛容さを持って接しましょう。
コミュニティとつながる
コミュニティは DevRel のさまざまな側面の中でも、最も重要なものです。DevRel の中の「Dev」は、「開発者」コミュニティを指しているのです。
コミュニティに携わるとは、このような活動を続けることに他なりません。
- みんなが参加しやすいイベントを企画し
- 役に立つブログをタイミングよく公開し
- 参考にしやすい、ニーズに合ったデモを作成する
コミュニティを理解していないということは、あなたが何かやろうとするときに、サイコロを振って決めるようなものです。つまり、ユーザーがやってほしいこと、必要を思っていることを理解しようとしていないことなのです。
ユーザーは誰
すべてのソフトウェア開発者をターゲットにするというのは、そもそも無理があります。したがって、誰をターゲットとするのかを考えておきましょう。
- どんなプログラミング言語を使っているのか
- 新人〜中級レベルの開発者なのか、CTOのような意思決定者なのか
- どこで仕事をしているのか
- どこで情報収集をしたり、学んでいるのか
- あなたが担当する製品をどのように利用しているのか
- あなたが担当する製品を使って、どのような問題を解決しているのか
- あなたが担当する製品のどの機能を使うことで、仕事が進めやすくなっているのか
- あなたが担当する製品や会社のファン度はどれくらいか
ユーザーはどこにいる
ユーザーはオンラインで何に時間を使っているのでしょう。
- GitHub
- Stack Overflow
- Hacker News
- Discord
- Slack
- フォーラム
あなたが担当する製品が、専用のコミュニティをSlack上やDiscord上、あるいはフォーラム上に持っているのであれば、そこからつながり始めるのが良いでしょう。。
ツイートやブログ、あるいはその他のオンラインメディアであなたの会社や担当する製品に言及しているのをウォッチするには、mention のようなツールが役に立つでしょう。
チャンピオンを探し出す
コミュニティの中で、最も活躍しているメンバーはだれでしょう？
Orbitモデルによって、誰が重要なメンバーなのか、その理由が説明できます。
チャンピオンは、他のメンバーを引きつける中心的な役割を担っており、コミュニティがゴールを達成する上での方向性を示してくれるのです。チャンピオンがいないと、ゴールに向かおうとしても行き詰まってしまうのです。
チームのメンバーに誰がチャンピオンに相当するのか、聞いてみてください。チームの支持が得られるのは誰でしょうか？
候補となる人がいれば、その人にコンタクトして、打ち合わせの機会を持てないか、聞いてみましょう。打ち合わせはリラックスした雰囲気で、お互いを理解できるようにします。あくまでも、相手の話を聞き、理解するための機会なのです。
あなたの会社や製品、コミュニティに関する深い洞察を持っていることがわかるでしょう。この外からの目線に大きな価値があるのです。その人が話してくれたことは、残さずメモを取るようにしましょう。
コンテンツを書いてくれる人とつながる
あなたが担当する製品に関するコンテンツをこれまでに作成してくれた人は誰でしょうか？ チュートリアルやビデオなどを作成してくれた人とコンタクトを取ってみましょう。それらのコンテンツに関して、あなたがいいと思った点を伝えて、コンテンツを書いてくれた人のことを知るようにしましょう。何のためにコンテンツを作ってくれているのか、どんな点で苦労しているのか、今後コンテンツを作成してくれる際に、あなたはどんなサポートができるのか。
コンテンツを書いてくれる人と DelRelチームとは共存関係を築くことができるのです。彼らがコンテンツを作成することで、あなたが担当する製品について他の人が学ぶ助けとなっているのです。会社のソーシャルメディアのアカウントでコンテンツを紹介して、みんなに知ってもらうようにしましょう。
コンテンツの公開前に、あなたにレビューさせてもらえるよう、将来的にはお願いしてみても良いでしょう。製品の使い方を一番良い方法で伝えるにはという目線でレビューすることで、コンテンツを書いてくれる人はエキスパートからの有益なフィードバックを得られるのです。
自分を大きく見せない
コミュニティをサポートする上で、あなたはエキスパートである必要はありません。 コミュニティには初心者もいれば、エキスパートもいて、あなたは常に両者の間にいる存在なのです。
あなたの担当する製品であっても、ユースケースごとに、あなたよりも良く知っている人が常にいるのです。
そんなとき、あなたは製品の一番のエキスパートでなければならないと感じるかもしれませんが、コミュニティがあなたに期待しているポイントはそこではありません。コミュニティが必要としているのは、正しい方向性を示してくれたり、役に立つコンテンツを提供してくれたり、問題や質問に耳を傾けてくれ、自分の意見が取り入れられていると実感できる人なのです。
自分が製品に関して、どの程度理解しているか、必要以上に自分を大きく見せることなく、あなたが知らないことを教えてくれることに感謝しましょう。
ユーザーをどうサポートするか
技術的な問題で困っているユーザーをどのタイミングで、どのようにサポートチームにつなげば良いのか、上司に確認してみましょう。あなたが直接サポートしたいと思っていても、結果としてサポートチームの業務をあなたが引き受けることになりかねません。
組織間の連携方法は会社ごとに異なっているので、あなたの会社でのやり方を確認しておきましょう。
ユーザーがあなたに直接コンタクトを取ってくることがあるかも知れません。Twitterで困りごとをつぶやいているのを目にすることもあるでしょう。あなたがすでに答えを知っていたり、すぐに見つけられるのであれば、直接答えても良いでしょう。そうでなければ、サポートへのコンタクト方法を紹介するようにしましょう。
そうであるとしても、あなたがコミュニティにとっての最初のコンタクトポイントであることには変わりありません。サポートチームの方がもっと良い方法で、もっと早く対応できるのであれば、あなたは自分の範囲外のことをしないようにしましょう。
おわりに
３つの領域に分けて見てきましたが、着任して最初の数ヶ月の間に意識しておくべきことを挙げておきます。
うまくいくことを取り入れる
あなたの会社や製品、そしてコミュニティが他とは違うように、あなたの DevRel へのアプローチも他と違って良いのです。つまり、DevRel する唯一無二の方法というのはないのです。
このガイドは DevRel についての概要を、実行可能なステップとあわせて紹介するために書いたものです。確かにその通りと思うこと、意味があると思うことは取り入れた上で、これは違うと思うことは取り入れなくても良いのです。
じっくり構える
DevRel はそもそもクリエイティブな活動です。あなたの声が伝わる方法が見つかるまで、時間がかかるかもしれません。さまざまなタイプのコンテンツを作成してみて、効果的な方法を探してみてください。
結果として、あなたや上司が期待していたのとは違ったやり方をすることになるかもしれませんが、それで良いのです。じっくり構えて、コミュニティを作り上げるには時間がかかるものだということを理解しましょう。
先輩 DevRel をまねる
もしあなたが先輩 DevRel の仕事のやり方を観察する機会があるのなら、そうしてみましょう。先輩 DevRel の仕事のやり方を学び、どのような考え方をしているのかをたどることで、新たな気づきが得られるでしょう。
先輩 DevRel がどのようにしてコンテンツを作成し、コミュニティと向き合い、製品を使っているのかを観察しましょう。そうすることで、あなたが自分のやり方や DevRel へのアプローチを確立する上で役に立つでしょう。
学ぶ立場でいるときには、観察すること、質問をすることが重要です。提案や批評、違ったやり方の指示は、頼まれない限り控えるようにしましょう。
著者に問い合わせる
私はあなたのことを知っているわけではありませんが、それでも DevRel 分野であなたが成功を収めるのをサポートしたいと心から思っています。私にコンタクトいただければ、何か良いアドバイスをしたり、正しい方向性を指し示すためにベストを尽くすつもりです。
このブログ記事に関して提案があれば、私に知らせてください。このガイドがより役立つガイドになるようにと願っています。
このガイドにフィードバックを寄せてくれたLucie Haberer, Grace Liller, Prince Wilson, Vadim Smirnovに感謝します。