Developer Advocacy ハンドブック
(developer-advocacy.com)クリスチャン・ハイルマンが15年前に公開した「開発者エバンジェリスト・ハンドブック」の最新版
- Developer Advocacy / Evangelism とは何か？
→ 定義する
→ 正しい考え方：開発者に変化をもたらす人
→ 役割と強みを発揮する
- 自社と協力する
→ 偏見に備える：複数の役割にまたがるユニークな役割。落胆しないこと
→ 会社の変化に対処する：法的手続きを守ること。「Off-the-record」はない。感情的に行動したり、決めつけたりしないこと
→ 社内開発者のそばにいる：耳を傾けること
→ PRおよびマーケティングと協業する：競合相手ではない。継続的にコミュニケーションすること
→ 外部チャネルとして認識される：メンバーに自分がつながっているチャネルを知らせる
→ 他の Advocate と開発者を教育する：社内教育や講演を行い、外部からのフィードバックを共有する
→ 有用な技術を共有する：知った技術について社内とコミュニケーションする
→ 個人チャネルと公式チャネルのバランスを取る
→ ブランドを取り除く：会社のブランドから自分を切り離すこと。開発者が製品で遊べるようにすることだけに集中する
- 競合他社と協力する
→ 競合他社と一緒に働くとき：
✓ どの会社の製品かに関係なく、面白いものに関心を持つ独立した人になること
✓ 常に新しいものに慣れること
→ 競合を尊重する：優れた DA でありながら、同時に好戦的であることはできない。
→ 競合製品の方が優れているときは認める：良い技術を高く評価する人になり、競争を恐れず歓迎する人になり、社内チームにフィードバックも与えられる
→ 競合について知る：比較して話すには、まず知らなければならない
→ 競合製品を使って例を作り、使ってみる：比較でき、違いを把握できる
- Outreach の準備
→ 正確な事実を把握する：製品チームに正確な仕様や機能、何ができて何ができないのかを詳しく聞くこと
→ 聴衆とその要件を知る
→ バックアップしてくれる専門家を準備する：
✓ 答えられない質問は書き留めておき、後でフォローする
✓ 製品チームが提供できるか確信できないことは約束しないこと
→ 適切な媒体を選ぶ：発表資料、ビデオ、オーディオ、ライブコーディング、オンラインのステップ別サンプルなど
→ 失敗に備える：
✓ 発表資料のローカル版とオンライン版を用意する。
✓ USBメモリに別途保存する。
✓ スライドが使えない場合でも Q&A で進行できるよう準備する
✓ オンライン接続は常に使えるとは限らないので、ローカル環境またはホットスポットを準備する
- 話す機会を探す
→ ポッドキャストに参加する
→ パネルに参加する：特定テーマの専門家になるか、グループのメンバーになること
→ BarCamp / Meetup に参加する：短い発表
→ オンラインマガジンなどに記事を書く
→ ブラウンバッグセッションを運営する：昼休みのセミナー
→ カンファレンスで質問する
→ 招きたくなる登壇者になる：自分の発表テーマ(Term)を公開して掲載する
✓ 個人情報、最新の略歴、最近の発表スライド / 動画
✓ 自分が扱いたいテーマ、使っている技術
✓ カンファレンスオーガナイザーに求めること など
- 出張とカンファレンス参加
→ 出張のヒント：1日分のバッファを設ける、安く旅する
→ 費用を払うのは誰か？
→ 会場でさまざまなイベントに参加し、他の登壇者たちと交流する
→ イベント参加時にソーシャルメディアを活用する：
✓ 発表資料にソーシャルメディアの連絡先を残す
✓ カンファレンス参加内容をハッシュタグなどで知らせる
✓ 面白い内容や良い発表を共有する
✓ カンファレンスオーガナイザーのニュースを再共有する
✓ 発表資料をオンラインに掲載し、人々に知らせる
→ イベントを通じてネットワークを構築する
→ イベント参加を追跡するカレンダーを作って記録する
→ カンファレンスの Buzz を活用する
→ 登壇するカンファレンスの一部になる
→ 発表および関連資料は即座にリリースする
→ カンファレンスについて文章を残す
- 発表とワークショップを進行する
→ 自分らしくあること：最高の資産は自分への信頼。
→ コミュニケーションに招き入れる
→ 参加者が持ち帰れる資料(takeaways)を準備すること
→ QA セッションを準備し、完全にコントロールすること
→ 正直に、真実だけを話す：答えが分からないときに推測しないこと
→ 発表後にフォローアップのコミュニケーションをする
- プレゼンテーションのヒント：時間管理など
→ これらすべてをどうやって X 分以内に収めるか
→ Less is More：重要なこと（インサイト、研究結果、X の現状、製品 X の新機能）1つから始める。人々にこの発表で何を覚えてもらいたいのか？
→ あなたの発表は、あなたにだけ非常に重要である
✓ あなたの発表は数多くあるものの1つにすぎない
✓ あなたの発表は録画され、あちこちに広まるだろう
✓ 人々は発表内容のすべてを覚えてはいない
✓ 人々は情報のためにあなたを必要としているわけではない。その情報はオンラインで簡単に見つけられる
→ 追加情報を整理する
→ ライブコーディング？ 注意すべきこと
→ 質問を避ける
→ 削るべきもの：目次スライド、会社情報、自己紹介、ジョークや Meme など
→ 発表中の埋め草として入れられるもの：資料の場所、連絡方法、自分以外の連絡先となる同僚や専門家など
→ 発表要約を準備する
- ステージ上で言ってはいけないことと、その代替表現
→ 「これは簡単です」：「これを行うには、いくつかのステップを踏むだけです」「これらのツールは文書化がしっかりしているので、あなたも…」
→ 「ご存じない方のために簡単に繰り返すと」：「もう一度言うと、X は…」「ご存じのとおり、X は…」
→ 「誰でもできます」：「こうすると残りの作業がもっと楽しくなります」「とても効果的なので、試してみて他の人にも知らせてください」
→ 「X がこの問題を解決してくれるので心配しないでください」：「X が Y に関する問題を解決してくれるので、Z を作れます」
「X は Y をより簡単にするために作られ、実際に使われています。結果も心強いです」
→ 「皆さんご存じのように」：「これは最近よく話題になっていて、X(リンク) でうまく説明されています」など
→ 「学校で習ったように」：「これはコンピュータサイエンス教育課程の一部であり、それには理由があります」
→ 「Y（私たちの製品）は（競合）X よりはるかに優れています」：「X を使ってこれを行う方法はこうです。私たちは別の方法を取り、その理由は次のとおりです」
「これにはさまざまな解決策があります。X には、より効率的になり得るいくつかの機能がないことを踏まえ…」
→ 「数行のコードだけでできます」：「ご覧のとおり、数行のコードで始められます。ここでお見せするために簡略化しており、ソースコードは X にあります」
→ 「プロフェッショナルになりたいなら、X をやってください」：「X の利点は Y にあるため、使う上でプロ向けのツールになります。
→ そのほか、自分の講演 / 動画を見たあとで「自分がこれを知らなかったら、この言葉を聞いてどう感じるか」を考え、内容を削るか言い換えてください
- 優れた文章や記事を書く
→ Simple is not stupid：分かりやすくシンプルに書くのはとても難しい。簡単な単語、多くの読者が理解しやすい用語、簡潔な文
→ 本質を語ること。Sugar-coat しない
→ 文章の長さは重要。オンライン向けの技術記事は短く、要点だけを伝えるべき。長すぎるなら複数の記事に分ける
→ さまざまな関連メディアを追加する。ビデオ、オーディオ、スライド、画像など
→ 階層的な見出しなどでコンテンツを構造化する。
→ コンテンツにも有効期限は必要。
→ 証明のために他の資料を引用する
→ 先回りする(Pre-emptive)ライティング - あなたの製品が開発者の関心を引けるようにする。「販売」は営業チームが行う
- 優れたコードサンプルを書く
→ サンプルを通じて問題を解決する
→ 動くサンプルを見せる
→ 必要な環境を説明する
→ Copy & Paste できるコードを書く
→ サンプルのダウンロードを提供する
→ きれいで賢いサンプルを書く
→ コードとデモをホスティングする
✓ バージョン管理はあなたの味方
✓ 自動ホスティングする
✓ コードサンドボックスを使う
✓ ライブコーディング環境
- 優れた発表資料を準備する
→ 自分が知っていることが何かを明確に知る
→ スライドではなくコンテンツそのものから始める
→ ポータブルなテキスト形式で書き始める
→ 素早く発表資料を作るコツ：箇条書きを分解する
→ 発表に適したツールを選び、準備する
✓ 16:9、4:3 に関係なく変更できること
✓ 画像のトリミングやリサイズがしやすいこと
✓ 画面上でオブジェクトを自由に移動できること
✓ リモート操作が可能であること
✓ 他の発表資料への移動がスムーズであること
✓ フルスクリーン対応
✓ 1つずつ表示できること
- 発表用の優れたスライドを作る
→ 話し言葉を書き起こさず、短い文 / 図 / スクリーンショット / グラフで説明する
→ 良い画像を探して使う
→ コードサンプルを見やすくする
→ サウンドとビデオ活用のヒント
→ アニメーションは必要な場所にだけ使う（派手すぎないように）
→ 簡潔に - 可能なら1つのトピックだけをカバーする
→ 聴衆を考慮する
→ 会社やカンファレンスのテンプレートがある場合
→ すべての資料は個人化（内在化）して使うこと：他人からもらった資料をそのまま再利用しない
→ 共有して楽しむ
→ 追加の発表ヒント
✓ 自己紹介：なぜ自分がこれを発表するのに適した人で、なぜ / 何を話したいのか
✓ ユーモアを使う：他人を攻撃しないよう注意する
✓ 現実とのつながりを作る
✓ 速すぎないようペースを調整する：少し間を取ることは聴衆にとって良い
✓ 「Hello World」は避ける
✓ 可能なら新しい発表資料を使う。最新に更新する
- より理解しやすく、アクセスしやすく、行動可能な発表のためのチェックリスト
→ 発表資料
✓ HTML / PPTX / PDF か？
✓ コードはオンラインにあるか？
✓ 埋め込み動画 / 音声は OS に関係なく再生でき、オフラインでも使えるか？
→ フォーマット
✓ 埋め込みメディアはアクセシビリティをサポートしているか？（キャプション、代替文字列、トランスクリプトなど）
✓ フォントは十分に大きいか？
✓ カンファレンスに合ったサイズか？ 16x9、4x3
✓ プロジェクターに不具合があっても見えるだけの十分なコントラストがあるか？
✓ プロジェクターで切れても問題ない安全マージンがあるか？
✓ 自分のコンピュータ以外で発表するとき、代替フォントが必要か？
→ コンテンツ
✓ 攻撃的な内容やトリガーになり得る内容が含まれていないか？
✓ 特定の背景知識がなくても理解可能か？
✓ 通訳 / 翻訳者が事前に知っておくべき用語はあるか？
✓ スライドの一部 / 1枚だけが共有されても誤解を招くものはないか？
✓ すべてのメディアと資料に出典明記および著作権確認がされているか？
→ トラッキング
✓ 発表資料をダウンロードした人について把握できるか？
✓ スライドの最後に Call-to-Action があり、ダウンロード可能なリンクがあるか
→ 保険
✓ すべての資料はコンピュータに依存せずオフラインでアクセス可能か？（発表資料 / サンプル / メディアをすべて含めて USBメモリに）
✓ ビデオ / オーディオが正しく動作しないときのための説明資料が含まれているか
- すべての作業を記録しておく
→ すべての発表は音声で記録しておく
→ 可能であればビデオでも記録しておく
→ 発表で使ったすべてのリンクを1か所に集めて記録しておく
→ 自分が行った / 参加するすべてのカンファレンスの一覧を記録しておく：スライド / ブログ / リンク / 動画リンクを含む
- (Social) Web を知り、活用する
→ 良い Web コンテンツを見つける
→ Web コンテンツを再配布する：ブログを書く、ソーシャルブックマークサイトに記録する、発表資料に使う、メーリングリストまたはフォーラムで引用する、Twitter に投稿する
✓ 元の作者を必ず Attribution する
→ Web 上で自分を知らせる
→ 強力なソーシャルサイトや製品を使う：Flickr, YouTube, Vimeo, Archive.org, GitHub, LinkedIn, Facebook, Meetup, Twitter
→ Web を保存庫であり、配布チャネルであり、クロスプロモーションツールとして使う
→ 製品に関するヒントを出し、ティーズ(Tease)し、プレビューを公開する
→ 効果を追跡する：文書 / ブログに Telemetry を追加し、コメントフィードを購読し、追跡可能な URL 短縮サービスを使う
→ ネットワークを構築する
→ ニュースレターを作る、または参加する
→ ポッドキャストを作る、または参加する
- 自分のコンピュータで作業する
→ 機材：外部マイク、モニター、カメラ、照明
→ スクリーンキャストとスクリーンショットを残す
→ ストリーミング
→ リアルタイムのオンラインチャットに参加する
→ リアルタイムのオンラインイベントに参加するときの注意点とヒント
- 自分のオンライン発表を録画するヒント
4件のコメント
以前の版のタイトルは Developer Evangelist Handbook でしたが、最近は Evangelist/Evangelism よりも Advocacy という言葉が使われるため、それを反映しました。
私が2010年にデベロッパーエバンジェリストとして仕事をしていたとき、バイブルのように参考にしていた本でもあります。
著者は20年間開発者として働き、この10年あまり Yahoo、Mozilla、Microsoft でこの仕事をしてきたベテランです。
Developer Advocate/Evangelist/Relations とさまざまに表現されますが、関連業務をされている方はもちろん、外部発表の多い開発者の方にも参考になると思います。
発表資料作りにおける「個別化せずに再利用しないこと - Don't reuse without personalising」は、私自身が非常に重視していることでもあります。
どこかから持ってきた画像や図表を使うと合わない部分も多く、肝心の本人がその図表を十分に理解していない場合も多いです。
できる限り、自分なりに解釈した形で、自分の発表資料のコンセプトに合わせて描き直して使うことをおすすめします。
よく整理されていて助かります。「個人化しないで、再利用しないこと - Don't reuse without personalising」はかなり直訳的な表現なので、ご指摘の文脈では「自分のものとして内在化して再利用する」といった言い方のほうが、より理解しやすいかもしれませんね。
書いてみたらそうですね ^^; 少し反映しておきました。ありがとうございます
@_@)b