DevRelCon Tokyo 2017 所感

https://tokyo-2017.devrel.net/img/brand/DRC-tokyo.svg

DevRelCon Tokyo 2017は DevRel（開発者向けマーケティング施策）に関する日本初のワンデーカンファレンスです！

全体を通して

デベロッパー向けのポータルサイトは必須（投資）

GithubやAWS、Googleに、デベロッパー向けのポータルサイトが無かったら使っているだろうか?

ドキュメント、サンプル、ブランディング、参考（他社）事例、FAQ、我々との対話のコミュニティ、そしてデベロッパーの監視システム（どこで詰まったか、何を見たかの追跡）は必須

デベロッパーがどこまで何をしたか、久しぶりに戻って来たときにどこから再開すべきか分かると良い

TODOリストになるチェックシートはあると良い。

機能としてでも、印刷物でも。

「まとめとして、ポータルサイトとは？」

「SDKのミッションコントロール（管制室）です。」

「正しく誘導し、良い旅に導くことが必要です。」

見る側が欲しいのはWarning:（赤字）では無く、Note:（ではどうすれば良いか）

社内のサポート人員と、協力会社のデベロッパーが抱えている問題は、どの会社でも実は近しかった、まずは社内のサポートが幸せか調査を。

「問題を抱えた人（デベロッパー・サポーター）はそのままにすれば最悪の敵に、解決してあげれば最高の味方に」

叩くべき点を知っている敵

失敗（と解決方法）を知っている味方

キーノート 開発者へのマーケティング

https://tokyo-2017.devrel.net/img/speakers/john.jpg

John Britton, GitHub

（雑談 : 一番好きな街は下北沢とのこと）

Githubは100人のチームから700人のチームへ

そして2500万の顧客

何故ここまで成長できたか？

まず、そもそも製品を売るには、しっかりした製品・オーディエンス・マーケティングが必要

製品 => 頑張るしかない

オーディエンス・マーケティング => やり方がある

デベロッパーへのマーケティング

=>どこからお金が来るのか？

マネタイズ

・無料

・使用量に基づいた価格

・価値に基づいた価格

購入方法

・買い切り

・多重課金

・月額請求

https://pbs.twimg.com/media/DF3qoGWU0AQ2jX-.jpg

製品を作って行くサイクル：Support Content Outreach Operations Programs の順番

・何をすべきか、調査する　ユーザーに触れ合う

・製品を作成する

・スペシャリスト

・Branding

・成功を測定する

・クオリティ

・ネットプロモータースコア　NPS

・Quantity

・Activity

・・エンゲージメント

この辺りを考える必要がある。

Githubでの例（ディレクター）

・全てのサポートが自分に来るようにした

・サポートのためのツール・リンク集を作成した、熱心なファンと共同作業もした。

・ブランディングページ

・サポートプロセス、オペレーションの変更を行うことを決めた

・サポートの自動化

・サポートすることで収益を得る。

・デベロッパーからどのようにサポートをして欲しいか、シグナルを受け取る

・SDKでエラーを出してしまった、その時、私は何が起きたかを数千のデベッロッパーに送り、陳謝した。

・何が起きたか、説明責任を果たすことが大切

・良いサンプルを用意することが重要です

・「人として話す」のが大事。"自社のブランドの裏に隠れて"相手と喋ってはいけない

やるべきこと

・素晴らしい（QA）リストが有れば、年に数千回有った筈の質問を無くせる

・もし同じ質問が来たら、リストの中で該当するURLを渡せばいい

・何でもかんでも書き留めて、そこからリストを作っていきましょう

・しかし、サポート用のコンテンツを作ることは難しいです、最初から作るのは難しいでしょう

・どうやって良いかわからなくなってしまいますね、基本的な部分のみを書いて、あとは実際のプロセスから作っていきましょう

・最初から完璧なものを作るのは難しい

・上手くいかないことに対する答えだけではなく、"上手くいった例"を乗せてあげるのも良いでしょう

・アウトリーチを上手くやる方法として、ワークショップは良いでしょう。

・ブランディングにも繋がり、密なサポートが出来ます。

・提供側が相手に出向いていきましょう。（GO YOUR AUDIENCE）

・また、デベロッパーが集まるスペースを作るのも良いでしょう（BE THE LIVING ROOM）

・良いデベロッパーが、良いデベロッパーを呼び込んでくれますし、イベントを開催してブランディングしやすくなります。

・誰かの真似をして、反動的にやることは上手くいきません。ゴールを考えていなければそれは良い結果に繋がりません。（DONT FOLLOW THE CROWD）

・例えば、他者を真似するだけで、中身のないイベント登壇やスピーチを行うことです。得られるものは少ないです。

・サポートオペレーションはチェックリストで作っていきましょう、進捗を確認できるようにし、チームがサポート出来るようにしましょう（MAKE CHECKLISTS）

・シングルポイントにならないよう、チーム全員がチェックリストを見て、チェックしていけるようにすべきです。

・チェックリストは、自動化することも出来ます。そういうサービスがありますし、何より私たちはデベロッパーです（AUTOMATE）

・重要なのは、チェックリストに頼り切らないことです。必要な時に必要なことをやりましょう。

・サポートでやらないことをしっかりと決めておくことが重要です。（DIVERT DISTRACTIONS）

・プランによってスケールするプログラム（彼らにとって必要なものだけが入ってること）SDK API

・シンプルであることが重要です。

おすすめの書籍

book: Made To Stick

book: Traction

book: Platform Revolution

発表者

JDB.IO　でした、ありがとうございました。

カスタムで、希望に満ちた、Generated SDK の制作

https://tokyo-2017.devrel.net/img/speakers/tristan.jpg

Tristan Sokol / Square

内容：

API をつくる人々にとっては、API を、「製品」として重視することは簡単ですが、実際には、エンドユーザーのエクスペリエンスは、事実、エンドユーザーの好みの言語のパッケージマネージャーから引き出すものに基づいて定義されます。デベロッパーとして、誰かの API を使用するために自分のライブラリを書くことは特に、同じ機能性のある API が他にあり、ライブラリが自分の使っている言語である場合にはあまり望ましくありません。しかし、API プロバイダーは、これらの SDK をAPI が将来的に進歩した場合のメンテナンスの負担に押しつぶされることのないようにスケーラブルに構築するにはどうすればいいのでしょうか？ この講演では、一般的な戦略を、2~3 個とりあげていき、最後のものについては、詳しく話します。* ご自分の SDK を手助けしてもらうためのオープンソースコミュニティの構築、* SDK に応じた割合でのチームのスケーリング、* 仕様書に基づいたクライアントライブラリの生成用ツールの使用私のチームの API については、これらの様々なオプションを評価し、Swagger / OpenAPI 仕様を使って生成することで、必要な機能性、言語サポート、そしてスケーラビリティを実現することができました。SDK を書き、メンテナンスするための追加スタッフを採用する必要なく、API により多くの自社製 SDK を使用する方法を知りたい場合には、SDK 生成もよい選択肢となるでしょう。

SDKはエンドユーザー（デベロッパ）に一番近いものです。

それが無ければ彼らは私たちのサービス使うことが出来ません、私たちと繋がる唯一の点なのです。

希望に満ち溢れたSDKにしましょう

デベロッパーに対してSDKを上手く作れている会社はあまりありません。

60%のSDKは、次のエンドユーザーにはあまり合ってないSDKになっています

SDKは、複数人に使ってもらうものです。

複数に対応して、誰でも印象が同じものになり、チームでの作業がボトルネックにならないように作る必要があります。

OPEN API INITIATIVE

私たちは、OPEN APIというものに沿ってAPI作成をしています。

そのAPIには、どこに行けばサポートを得られるのか、DocのURLが含まれた返り値が返されるような内容になっています

これにより、このAPIを元にSDKやDocを作る際に、何が答えか、はっきりした状態で作成が出来ます。

これがなぜ必要かというと、私たちの会社ではAPIを作るチームと、SDKを作るチームが別なのです。

APIにメタデータが付与されているおかげで、エンドユーザも、SDK制作チームも、混乱がありません。

（この辺りから、APIからSDKを自動生成する、という話っぽかったが、聞き取れず流れがわからず・・・）

が私たちのspecになります。

そして、これが素晴らしい点は、自動でSDKを作成出来るということです。TravisCIを利用しています。

最後に

SDKs...

hopeful !

bespoke !

generated !

ハッカソンフィールドガイド

https://tokyo-2017.devrel.net/img/speakers/mike.jpg

Mike Elsmore

内容：

ハッカソンは開発者に製品/サービスを紹介する最も効果的な方法の1つです。スポンサーがこれらの開発スピードが速いイベントを最大限に活用するにはどうしたらいいでしょうか。このセッションではハッカソンの準備や実行、フォローアップを行って最大限に価値を引き出す方法を紹介します。

このセッションでは問題点を洗い出し、ハッカソンのベストプラクティスと問題点の解決法を紹介します。これまで50以上のハッカソンに参加し、さらに最近では若いハッカーを集めてメンタリングもしている中で培ったナレッジを紹介します。 最後に必須の資料やイベントサイズに合わせたプレゼンスなど、ハッカーの関与を最大限に引き出すための賞品などについて紹介します。

Code of Conduct

行動規約やガイダンスということです。

まずこれを読んでみましょう

まず、ハッカソンに参加する時には調査が必要です。

・継続的に開催されているか

・どんな企業・コミュニティが主催しているか

・どういう風に運営されてきたか

企業主催で行う場合は、

・API

・バナー

・ドキュメント

がちゃんと用意されている必要があります。"余裕を持って"です。

遅いとそもそもダメなハッカソンとして認識されてしまいます。

参加者として注意するべきは

・RTM - Read The Manual

・Check Support Channels (For the Event)

・Setup Tracking

・❌ Bail early without reason

キックオフ

・ブースを作って・・・

・参加者とネットワークを持って・・・

・ちゃんとオーガナイザーとして準備を遅らせず、遅刻をせず・・・

Easily identifiable

・誰に質問すれば良いのか、参加者が困らない様にしましょう、人と被らないTシャツとか！

プレゼンテーションはしっかりと

・Demoは必ず

・Demoの事前チェックは２回

・Demoは失敗します！失敗した時の準備も必ず。

・Demoには悪魔が・・・・

・DemoをGIFにするとか・・・

cant make assumptions on attendee skills

・参加者には学生やデザイナーも居ます、どんなスキルにも対応できる様にしましょう

時間が少なくなると皆慌てます。

・ちゃんと残り時間を告知して、慌てない様に誘導しましょう

hackersの問題をhackingしましょう

・困っていることはないか、会話から探っていきましょう

スライドのデザイン技術

https://tokyo-2017.devrel.net/img/speakers/melinda.jpg

Melinda Seckington / FutureLearn

内容：

スライド資料は美しいにこしたことはありません。 テクノロジー・エバンジェリストとして、我々のプレゼンテーションは、聴衆に自分が言いたいことを伝えるための中心的な手段であり、我々のスライド資料でいかに効果的になれるかということを学ぶ必要があります。

スライドデザインで何を選択するかが、聴衆に対してどのように影響するのかが左右されます。シンプルなデザイン要素を理解することで、より説得力のあるスライドを制作することができ、その結果、より印象的で効果的なプレゼンテーションを実現することができます。

この講演では、スライドのデザインをよりよいものにするためのシンプルな秘訣とコツでプレゼンテーション改善する方法についてとりあげます。皆さんが伝えたいストーリーをサポートするためのフォント、色、アニメーションやその他の要素の使い方についてとりあげます。

（メモすることがあまり無かった、スライドがよくまとまっていた）

おすすめの書籍

book: Universal Principles of Design

book: slide:ology

オススメのサイト

site: flickr free

site: pexels

site: design bundels

site: the noun project

デベロッパーコミュニティーのマネタイズ

https://tokyo-2017.devrel.net/img/speakers/nicholas.jpg

Nicholas Chen / Shopify

内容：

バランスを見つけましょう​ ​

取り込む以上の価値を創造することが、デベロッパーコミュニティの成長には不可欠です。しかし、このコミュニティーを立ち上げ、成長させ、その後、スケーリングすることは、非常に難しい作業です。それでは、顧客と、御社のデベロッパーのどのようにとればいいのでしょう？Shopify は、商店とデベロッパーの双方を扱う秘訣は、これら双方のエンゲージメント度が同等なユニークな文化を作り上げることだと気づきました。

自分の業務を熟知しましょう

これは、最終的には製品に関する意思決定ですが、デベロッパーと顧客の各コミュニティの双方に影響を及ぼします。顧客が御社製品から求めることをすべて行い、デベロッパーコミュニティーにギャップを埋めさせます。プロダクトロードマップに (ある程度) 透明性のあることを確認しましょう。Shopify では、既定値を受け入れ、我々の求めているものをサードパーティーデベロッパーに共有しています。これにより、価値を創造し、財務上の寄与率を捉えることができます。

この価値を外に向けて永続させます

デベロッパーアドボケイトとしての我々の業務の一環として、我々のエコシステムが顧客にもたらす価値を見せる必要があります。セミナー、カンファレンスや対面ミーティングなどは、金銭的価値と、我々のエコシステムが顧客のビジネスにもたらす影響を見せるための重要な仕組みです。同様に、デベロッパーは、その最終結果にエコシステムがいかに影響するのかを見ることができれば、プロダクトの作成や、インテグレーションのみに注力します。インテグレーションを追求するようデベロッパーを説得することは、彼らが増やしたい価値によって異なります。

スケールと抽出

デベロッパーコミュニティの真のマネタイゼーションはここから始まります。最小必要人数のパートナーがプラットフォーム上に現れるに従い、収益のみならず、これらのインテグレーションのデータも抽出する必要があります。小規模な会社が苦しむのは、人々に何かをつくるよう説得することですが、この苦しみをスケーリングすると、全当事者が賛同する、公平なエコシステムの構築につながります。

顧客は、ソリューションを見つけられる場所を知っています。デベロッパーは、構築すべきものと、その構築方法を知っています。そして、皆さんは、新しいパートナーを誘致するためにエコシステムの価値を示すことができるのです。この、サイクルの重要な部分を管理することで、ユーザーベースと、デベロッパーコミュニティを拡大させることができます。

繰り返しましょう

このサイクルには終わりがありません。エコシステム内の要素の4つすべての管理には微妙なバランスが関わっています。また、今どのサイクルにいるのかということ、そして、ご自分の会社、顧客とデベロッパーが協調して前進するための最善の方法を認識している必要があります。

学んでいただけること。

顧客が、そのユーザーエクスペリエンスを改善するためのサードパーティーのエコシステムを求めている、文化を創造する方法

目に見える変化をもたらし続ける魅力的なデベロッパーコミュニティーの構築方法

御社のプラットフォームを成長させるために、双方の当事者から価値を抽出する方法

現状の確認

・今の自分たちの強み

・何を売り出していきたいか

・デベロッパーコミュニティに何をして欲しいか

(追記 : 微妙だったのでメモを取り忘れていました…)

→何かの受け売りをそのまま喋ってる感が凄かった…自分の中に落とし入れて喋ってる感じがなく、実体験感が無く、共感できなかった。

近代的DevRelの歴史

https://tokyo-2017.devrel.net/img/speakers/brandon.jpg

Brandon West / Kickbox.io

内容：

「若いエンジニアを一人連れて行って酔わせて情報を得よう」これがDevRelのアドバイスに見えるでしょうか。しかしこれはある世界最大級のソフトウェア企業の資料に書かれていた言葉なのです！DevRelの形式は80年代にはできあがっていましたが、今なお多数のブログやガイドでは新しいものであるとして扱われています。DevRelのルーツを正しく学ばなければ巨大企業とうまく付き合う機会も逃してしまうでしょう。DevRelの歴史に沿って、私たちの仕事にどう活かせるのか考えてみましょう。

これはとても面白い話になるはずです。

苦情をいうデベロッパーを大切にしましょう

・デベロッパーは、ユーザーと違い、評価を残して立ち去ってくれることはほぼ有りません。

・静かに立ち去るのみです。

・苦情は千載一遇のチャンスです、必ず汲み取りましょう

The_Plamondon_Files

マイクロソフトは当時、アップルと比べてDevrelを短期的に見ていた。

「若いエンジニアを一人連れて行って酔わせて情報を得よう」等。

つまりDirty Tricks

(追記 : 自社宣伝臭が凄くてメモを取り忘れていました…)

→今のマイクロソフトはデベロッパーの方を向いているので、良いという話もあった

→しかし何かの本の内容を読んでいるだけっぽい感じで前半が終わった

→後半は自社の宣伝っぽかった

キーノート: 時は来た - 開発者が世界を変える

https://tokyo-2017.devrel.net/img/speakers/katsura.jpg

伊藤かつら氏, Microsoft

(追記 : 自社宣伝臭が凄くてメモを取り忘れていました…)

→スポンサー枠でアズールの宣伝に来たな・・・！という感じだった

→偉い人らしい、喋りが上手かった。エバンジェリスト界隈に関わってるらしいので、この人ありきのマイクロソフトMVCなんだなと思った。

→アズールのリアルタイム翻訳を使って発表をテキスト翻訳してたが、（自分で始めてた表示だが）あまりに精度が悪くて、本人が「邪魔なので！」と言って表示消してたのは笑った（そういう定番ネタなのかも）

開発者向けサイトの致命的な7つの罪

https://tokyo-2017.devrel.net/img/speakers/cristiano.jpg

Cristiano Betta / Work Betta

内容：

新しいAPIや開発者ツールを触ろうとした時、そのドキュメントの酷さにがっくりした経験はありますか。もしそうならこのセッションを通じて改善策が紹介できるはずです。

このセッションでは自身も開発者であるクリスティアーノ・ベッタが開発者サイトにおける7つの致命的な問題を紹介します。TwilioやStripeといった大企業でさえ時に犯す間違いについて紹介します。この中では開発者やUXデザイナーに対するよくある誤解や逆パターンを紹介します。最終的にはユーザ中心のデザインがすべてのユーザ、さらに開発者にも適用できることが学べるでしょう。

デベロッパーにとって、使い方のわからないSDKは、突然目の前に現れた見えないガラスの扉の様なもの

気をつけていないと、ぶつかってしまいます。彼らが急いでいればいるほど・・・

今日はデベロッパーエクスペリエンスについて話します。デベロッパーのUXと御考えください。

・outreach

・1st site visit

・successful integration

・advocacy

APIs + SDKs => Tool

Document => Information

・下記の3つを考える必要があります

Too Much

Too Soon

Too Little

では過去に出会った、酷い例についてお話致します。

（実例と何が悪いかの説明をしていた、実例をメモし忘れて対策の部分だけメモしてました…）

例：ドアノブを使ってドアを開ける

・物理的な負荷（ドアノブは硬くないか）

・認知的な負荷（ドア・ドアノブだと認識できるか）

引くドアか、押すドアか？

注意文言がドア中に貼ってないか？

ユーザーの処理能力を超えるほどの情報を渡していないか？

=>情報を小さなセクションに分けられないか？

80/20のルール

80%の時間で、20%しか触らない

=>ならば他の80は、最初は出さないほうがいい

例：火災報知器

・認知はしやすい

・物理的には難しい（ガラスを割ってボタンを押す必要がある）

=>簡単には実施して欲しくないものなどで使える、良い例

例：フォーム

・あとで内容を変更できるんだろうか？

・何で今聞くんだろうか？

・ダミーの情報を入れるとまずいだろうか？

・空で次に進むとまずいだろうか？

Mental Model

ものがどの様に動くか、ユーザーが考えた通りに動くか？

=>「ユーザーが初めて見たときに、最初に想像していた挙動」と同じ挙動をする様に実装する。

例：ユーザーの心

Where am I?

Where can I go?

Where did I come from?

=>ユーザーに道筋を示しているか？

=>久々に戻ってきた時、どこまで行ったかわかる様になっているか？

ドキュメントのどこからどこを見ているか把握しよう

（ドキュメントページをオンラインで用意し、ヒートマップツールを導入すると良い）

ドキュメントの量について

・壊れたほど少なすぎず

・疲れるほど多すぎず

・ちょうど良い大きさに！

段階的な開示を心がける

例：Warning: と Note: の差を気をつける。

何でも赤文字で書けばいいってもんじゃない！

お客にとって重要なこと

・メールアドレスを入力する必要があるか

・電話番号を入力する必要があるか

・お金がかかるか

・名前を伝える必要があるか

=> これらは実は違います。

=> お客が成功するかどうか　です。　まず、入り口は求めるだけではなく、見返りを提示しましょう

どのSDKを使えば良いのか、はっきりと示す。

・用途によってSDKを分けるのは重要

・しかし、同じ用途でSDKを複数用意するのは最悪です。認知の過負荷となります。

・・これはドキュメントでも同じ

book: Universal Principles of Design

book: the design of things

book: Envisioning Information

book: the mom test

デベロッパーエンゲージメント：ストラテジー対ベストプラクティス

https://tokyo-2017.devrel.net/img/speakers/kristof.jpg

Kristof Van Tomme / Pronovix

内容：

競争に勝つためには、ベストプラクティスを導入するだけでは十分ではありません： それは、顧客が最低限期待していることに過ぎないのです。競争に勝つためには、組織は、戦略的に投資し、一部の顧客を完全に受け入れられるよう、意図的にその他の顧客を遠ざける必要があります。

これが、一見不合理な選択をするという　他社が決して真似することのできない戦略の性質です。行った選択により、一部の選ばれた一群の顧客の考えうる最良のパートナーになることができます。

この、ビジネス戦略からの基本亭原則はまた、デベロッパーポータルにも該当します。

この講義では、この原理、ベストプラクティスと考えられるデベロッパーポータルの機能、そして差別化に役立つ機能の一例を示し、これらの機能が DX と、特定の顧客のデベロッパーエンゲージメントについて説明します。

API チームが競合他社との差別化に使用している原形的な戦略を多数紹介し、これらの戦略の導入方法について説明し、皆さんの業界で同様の戦略を実施するために役立つデベロッパーポータルの機能についてお話しします。

デベロッパー向けポータルサイトについてお話しします。

Distill & Share

デベロッパーポータルとは？

・ドキュメンテーション

・どうやって自社製品に組み込むかの方法

・何が出来るかの提示

・私たちとのコミュニケーション

ポータルの役割は？

・SDKのミッションコントロール（管制室）です。

・正しく誘導し、良い旅に導くことが必要です。

用意すると何が嬉しいか？

・私たちが長いサポートをしない様に

・新規参入者を増やすために

よくある間違い

・APIリファレンスだけを用意したサイトは、ポータルでも何でも有りません。

・デベロッパーポータルは負債ではなく、投資です。　私たちが使いたいと思うAPI・SDKで、デベロッパーポータルが無いサービスが有ったでしょうか。

API docs MVP

・1. Discover / Research

・2. Evaluate

・3. Get Started

・4. Develop & Troubleshoot

・5. Celebrate

・6. Maintain

これらが満たされていると良い

良いポータル

・APIやSDKにどんな機能があるか、見つけられる様に

・サンプルを見つけられる様に

・デベロッパーが、SDKを良いもの、信頼できるものだと評価できる様に

・デベロッパーが、SDKが長くサポートされるものだと思える様に

・デベロッパーが、投資しても良いと思える様に

・すぐにソースコード・ファイルをダウンロード出来る様に

・プロダクトを理解できる、チュートリアルを開始できる様に

・最初は、SDKの選択肢をできる限り少なく。デベロッパーがやりたいことを聞いて、一つだけを提示する様に

・トラブルシューティングに素早くアクセスできる様に

・参考事例（他企業）を用意する様に　これは信頼と、評価、御祝いです。使ってくれたんだから、褒めましょう、もちろん許可を得て！

・サポート窓口を用意しましょう、デベロッパーが怒り、悲しみ、離れたらお終いです

本当に？

・今挙げた内容だけで、良いポータルが出来るでしょうか？

・残念ながら出来ません。なぜなら日々良いポータルは業界として進化して行っているからです。

・環境・戦略に合わせて進化させ続けましょう。競合から学びましょう

developer portal mailing list

サポートを楽しいものに

https://tokyo-2017.devrel.net/img/speakers/scott.png

Scott Massey / Astrocolossal Consulting, Pantheon

内容：

テクニカル製品へのスケーラブルなサポートは、サポートエンジニアを採用し、資料をいろいろと読むだけではありません。カスタマーサクセスに対する、幹部、エンジニアリング、プロダクト、さらにはマーケティングまでを含む会社全体のコミットメントが必要です。　　 このコミットメントは、資料、オンボーディング、カスタマーサクセス、トレーニングとコミュニティーなど、ユーザーが関わるやりとりのすべての意思決定を牽引するサポート戦略の立案に役立ちます。

この講演では、サポートチームとオファリング、プロセスとチャネル、ツールとメトリクスなど、サポートに全面的に関わるユーザーサクセスの枠組みについてとりあげます。

新規のユーザーを増やす努力も大切だが、既存のユーザーを離さないことも重要です。

サポートは、利用者とのコミュニケーションです。

ただの接点では無いのです。

利用者からセラーとの「それ買いたい」

利用者からサポーターとの「これ助けて」

だけでは無いのです。

我々とユーザーの循環環境を作る様な、コミュニケーションをしていきましょう。

・声に出さないユーザーへのサポートを行いましょう。

小さな問題に遭遇した時、連絡してくれるユーザーは10%以下と言われています。

90%のユーザーにリーチするためには何が必要でしょうか？

私たちから、聞きに行くことが必要です。サポートの窓口をわかりやすく示し、対話のきっかけを提供し、

コミュニティを持つことが重要です。

・怒ったユーザーを味方に変えましょう

丁寧なサポートをすることで、評価を下げる筈だったユーザーを、評価を挙げてくれるユーザーに変えることが出来ます。

そのために必要なことは

1. ユーザを理解すること

(どこで問題が起きているか把握すること)

(事前に対策を考えるため、ペルソナを作ること)

(ユーザーの気持ちの上がり下がりを理解すること（どこでユーザーが喜び、どこで失望したのか。ジャーニーマップ等が参考になります）)

2. すぐに連絡すること

手伝えることがあるか、聞くこと

相手の場所に向かうこと

3. 上記が出来る様に事前にサポートチームをトレーニングすること

4. ドキュメント(QA,サポート,FAQ)を見たユーザーが、怒らない文章を用意すること。

既に怒っているユーザーがドキュメントを探して見たときに、余計怒るのは避けなければなりません。

相手が疲弊してるときに見たらどう思うかを考えて作成しないといけません。

・ユーザーが持っているのに、自社には無いナレッジは有りませんか？

困ったユーザーは、失敗を持っていることが多いです。失敗は成功の糧です。

どんな失敗をしたかを知らなければ、次に失敗したユーザーをすぐ助けることも出来なければ、機能の改善も出来ません。

ユーザーの方がサービスを使い慣れている状況も同じ様にマズイです。

ユーザーの声を多く聴くこと、そして自分たちでもサービスを理解することが重要です。

・サポートチームが満足する状況を作りましょう

ユーザーとサポートチームが対話をしている状況で、サポートチームが満足しているならばそれは良い状態です。

サポートチームが満足していないことがあれば、しっかりをヒアリングをしましょう。

それは恐らく、ユーザーが抱えている問題と関係している可能性が高いからです。

良い開発者体験につながるクリエイティブなコンテンツ

https://tokyo-2017.devrel.net/img/speakers/tomomi.jpg

Tomomi Imura / Slack

内容：

例えば新しいプロジェクトのためにフレームワークやAPIを探しているとします。素晴らしいWebサイトにも関わらずドキュメントが貧弱だったしましょう。それを試したり、または別なものを探すでしょうか。他の例として、READMEがないGitHubプロジェクトについてどう思いますか。スピーカーはこの開発者の経験が技術や製品の選定に大きく関わる要素の一つだと考えています。

UXはユーザのニーズと価値を理解し、製品やサービスを提供することに重点を置いています。この枠組みは開発者に対しても同じです。開発者の体験、DXは開発者とサービスプロバイダの間にベストな関係を築く上で大事なことです。

そこでエヴァンジェリストとして、私たちは開発者のためにDX改善を通じて何ができるでしょうか。

このセッションではスピーカーの経験や開発者を中心としたコンテンツやドキュメントでコミュニティを動かし、新しい開発者やユーザを獲得する方法について紹介します。

オープンなSDKに関する話題（デベロッパースペースにサンプルを置く等）が多かったため、所感省略

→あまり自社では活用できなさそう

→全体的に宣伝臭がすごかった

素晴らしい開発者向け製品を生み出すための包括的アプローチ

https://tokyo-2017.devrel.net/img/speakers/miyota.jpg

Ryohei Miyota / LINE Corporation

→本人も言っていたが、LINEにはDevRelの部隊が無くて、かつ話す内容もデベロッパーとしての観点ですという入り方だった。

→実際、LINEの技術的な話しかなかった。

→一部の開発者（提携会社）にAPIを公開しているが、前提としてAPI,SDKの一般公開はしていない（一部を除いて）

→話し合いしながら進めてるとか・・・

→システムの話が多くて全体的にちゃんと聴けてなかった

Keynote: Mark a new chapter of developer like a Samurai

Yusuke Morizumi, IBM BlueHub

日本の歴史とデベロッパーを無理やり繋げてみましたみたいな感じの発表

→坂本龍馬は現代のデベロッパーと似ている、会社の外でも繋がれるスキルを持って、複数の会社を繋げて改革を起こした。

→デベロッパーは一つの会社に縛られるべきでは無い論

あんまりこのイベントの趣旨と合っていなかった。何でこうなったのか？規模の小さいイベントだから事前にスライド確認して無かったのかもしれない。

ありがとう & 閉幕！

https://tokyo-2017.devrel.net/img/organisers/nakatsugawa.jpg

Atsushi Nakatsugawa, MOONGIFT

ヒカリエ17Fでよく司会をしているアツシさんが司会だった、手際は良かったが登壇者に全体的に冷たいのはいつもと一緒だった。（悪い人ではない）

所感

全体的に面白いイベントだった。サポートやデベロッパー協力よりも一般ユーザーの顧客側を向いてしまうが、

デベロッパーの問題もしっかりと見つめるべき、という点はどの企業も課題として抱えてるのだなと思った。

サイボウズのオフィス（日本橋タワー）、日本橋の一等地、東京駅からも10分くらいで凄まじかった。

エレベーターホール格好良すぎた。。すごい。。

日本橋2丁目の再開発が凄かった（高島屋の横に巨大な複合商業ビルを2棟建てて、既存の高島屋と屋上付近を接続させて回遊層を作るらしい）、日本橋タワーはその横にあるので、羨望。