DevRel界隈で起こるトラブル
はじめに
これまで、DevRelを積極的に行って成功している事例や、DevRelによってさまざまな課題を解決できる点について紹介してきました。
しかし、DevRelはすべての問題を解決できるわけではありません。ネガティブなポイントも多数あります。それらを理解せずに、単にDevRelを行ったところで、予定外のトラブルに巻き込まれてしまうでしょう。
今回は、これまでに筆者が体験してきた、いくつかのDevRel失敗例を紹介します。企業名が出せないケースも多いので、その点はご了承ください。
マーケティングを二転、三転させるTwitter
Twitterは、執筆時点(2023年7月)で大荒れです。イーロンマスク氏による買収以降、API周りでの締め付けが相当厳しくなっています。有料化はもちろんのこと、その閾値が使いたいと思わせるような内容ではなくなっています。
そんなTwitterですが、実は買収前から開発者向けのメッセージがコロコロ変わることで知られています。元々TwitterのAPIは緩い条件のもとに利用でき、それにより数多くの関連サービスや専用クライアントが開発されてきました。
しかし、2012年にTwitterアプリの利用者数を最大10万人に制限したり、Instagramなどのサービスを埋め込み表示できないようにするなどの施策により、開発者の信頼を損なっています。その結果として、TwitterのCEOとして戻ってきたジャック・ドーシー氏は開発者に謝罪しています。
これにより関係が改善されるかと思ったのですが、TwitterのUser Streams APIが廃止されたり、Fabricを売却したりと数多く開発者を失望させてきました。そして、最近の有料化により学生などが「少し遊んでみようかな」と思うのも難しくなってしまいました(ホビーユーザー向けのBasicプランで月額100ドル)。
APIでは広告データが流せないため、ビジネスという観点においてはTwitterの取り組みが分からないでもありません。しかし、多くのサードパーティーアプリ開発者によって成長してきたTwitterにして、開発者を失望させるような取り組みが続いているのは残念でしかありません。
プラットフォーマーとしての存在
プラットフォームのDevRelでは、開発者にプロダクトを作ってもらうのが最終目的となっています。Twitterであれば、APIを使ったサービスやボット、クライアントアプリなどになるでしょう。
そこで問題になるのが外部企業の買収です。Twitterは2010年にTweetieというクライアントアプリを買収し、公式アプリとしています。これが他のクライアントアプリのAPI締め出しにつながっているのは間違いありません。Twitterは2011年にTweetDeckも買収しており、こうしたクライアントアプリの買収は他のアプリ開発者に対するデメリットとなっています。
このようなプラットフォーマーからのアプリ提供は、プラットフォームのエコシステムを壊しかねない行為です。結局のところ、サードパーティーアプリはマーケティングやマネタイズなどの面で公式アプリには敵わない存在であり、類似アプリを公式提供された際の影響はとても大きいものです。その結果として、開発者は開発意欲がそがれてしまうでしょう。
同様の行為はAppleでもよく見られます。決済、地図、写真管理など公式アプリの登場でサービスが終了してしまったアプリも数多く存在します。最近ではJournalという日記アプリが、他の日記カテゴリーを壊滅的にしてしまうのではないかと危惧されています。こうしたAppleの行為はsherlockingとして知られています。
サービス終了が与える影響
ゲーム等でサービスが終了することは「サ終」と言われていますが、これはDevRel周りでもよく起こります。サービスが終了するには、いくつかのパターンがあります。
- ビジネス的な問題
- 買収
ビジネス的な問題により発生するサービス終了は、そもそもそのサービス自体が流行っていない場合もありますが、大企業によるサービスの統廃合で起きる場合もあります。そもそも流行っていない場合は、それほど大きな影響はありません。もちろん、アーリーアダプターとして使い始めてくれていたユーザーや開発者を裏切ってしまっているのですが、それでも影響範囲は少ないでしょう。
大企業の統廃合でよく知られるのはGoogleではないでしょうか。有名なところではGoogle Wave、Google Code、Googleリーダー、iGoogle、Google+、Google Daydream、Google Stadiaなどがあります。最近ではGoogle DomainsがSquarespace社に売却されています。
こうしたGoogleによるサービス終了はあまりに多く、Google Graveyard - Killed by Googleにまとめられています。同様のサイトにMicrosoft Graveyard - Killed by Microsoftがあり、こちらはMicrosoftによるサービス終了リストとなっています(こちらはあまり開発者向けではないようです)。
サービス終了による、そのサービスを使っているシステムへの影響は小さくありません。特にAPIによりすでに稼働していた場合、代替サービスへの載せ替えが発生します。同じ機能が提供されていれば良いですが、もしない場合には既存サービスへ影響が出てしまいます。
こうしたサービス終了は、DevRelにもマイナスの影響があります。いつサービス終了するか分からないような状態では、とても使っていこうとは思えません。DevRelでは開発者との信頼を築かなければなりませんが、サービス終了はその信頼構築を妨げる行為になります。
1つの答えとしてのオープンソース化
サービス終了するのはビジネス上、致し方ない場面もあるでしょう。そうした際の選択肢として、オープンソース化が答えになるかも知れません。
例として、Facebook(現Meta社)によるParse買収があります。Parseは2013年に買収され、2017年にサービス終了しました。このとき、同時にオープンソース化が発表されています。オープンソース版のParse Serverは現在も活発に開発されており、GraphQLなどさまざまな機能が追加されています。
同様の事例として、GoogleによるLaunchKit買収、AdobeによるPhoneGap買収(現Apache Cordova)、LGによるwebOS公開(旧Palm OS)などがあります。
ハードウェアビジネスが与える影響
すでに一般的になりつつあるIoTですが、IoT向けのサービスが終了すると相当大きな影響があります。IoTではデバイスが日本(または世界)各地に配置されており、クラウドサービスなどを通じて連携しています。
そのため、データを集めたり、逆にデバイスに命令を出すクラウドサービスが終了すると、デバイスが使えなくなってしまいます。Google Cloud IoT Coreが2023年8月に終了したり、スマートロックのQ-SL1が終了して、スマートキーとして使えなくなります。FitbitによるPebble買収は、スマートウォッチが使えなくなる事態につながっています。
筆者が覚えているのは、某メーカーによるデバイス終了がワンデーのハンズオン当日に発表されたことです。そのデバイスはすでにビジネスでの実績もあり、ビジネス提携も実施されていました。筆者はそのハンズオンでのチューターを担当する予定だったのですが、当日会場でサービス終了を聞きました。
サービス終了はすでに決定事項であったため、ハンズオンも中止になりました。とはいえ、会場には足を運んでいる人たちが大勢おり、その人たちへの説明が必要です。日本側の担当者の責任ではないため同情的な雰囲気もあったのですが、それでも無駄足になってしまったことや、今後の信頼性を疑う声も多数上がっていました。
Webサービスの場合は代替手段がないこともありませんが、クラウドサービスと密接に関係しているIoTサービスでは載せ替えもできない場合があります。開発者の信頼を損なわないための設計(システム面、サービス面)をあらかじめ考えてほしいです。
サポーターがヘイトになる
DevRelでは開発者コミュニティの形成が1つの大きな目標になっています。コミュニティに参加することは、信頼性の表れとも言えます。それだけにコミュニティ参加者を裏切るような行為は禁物です。
筆者が知っている事例としては、某外資系企業でのコミュニティ形成の例があります。その企業では今後、開発者にフォーカスするということでコミュニティ作成を開始しました。当然ながらコミュニティは一朝一夕にできるものではなく、土壌をきちんと作る必要があります。
イベントの前段階からコアメンバーになりえる方たちと話をし、いざイベントを実施しました。その数週間後、マーケティングチームの目標がDevRelからビジネスへフォーカスを変更されたと発表されました。その間、わずかに3ヶ月です。
外資系企業では四半期単位で目標が変わるというのはよくあります。ただ、DevRelでは外部の開発者を対象としています。彼らの信頼を損なう行為は決してすべきではありません。この外資系のコミュニティ形成の場合では、一部の開発者から「もうサービスを使わない」と言った意見がTwitter上に流れる結果につながっています。
コミュニティに参加してくれる開発者はいわばファンであり、その信頼を損なう行為は彼らの気持ちが反転する可能性を秘めています。
課金周りのトラブル
クラウドサービスではFree Tierという枠がよく使われます。これにより、使ってもらうまでの敷居を低くします。DevRelに関わるエバンジェリストやアドボケイトはFree Tierの範囲でハンズオンを行ったりします。
こうしたハンズオンのときには決済情報を不要とするのがベストですが、多くのパブリッククラウドではクレジットカード番号の登録は必須としています。その結果、IBM Cloudでは突然の無料枠削除と、予期せぬ請求発生という問題が発生しました。
課金周りはサービス終了以上に大きな問題につながりやすいので、注意が必要です。課金額の変更を含めて慎重に進めるようにしましょう。
ジェンダートラブル
ジェンダーに関する問題は定期的に持ち上がります。コミュニティであったり、カンファレンスのセッション内容に関するものだったり、トラブルの火種はさまざまです。筆者の運用するコミュニティではアンチハラスメントポリシーを設定し、毎回イベント前に紹介しています。はじめて参加する人もいますし、知っていてもつい忘れてしまう人もいるからです。
最近では、女性だけを対象としたカンファレンスやコミュニティも増えています。本来ならそうした性差なく誰でも参加できるのが一番なのですが、その方が参加する心理的障壁が低いのであれば、参加者メリットがあると言えるでしょう。
また、コロナ禍でオンラインイベントが増えたことにより、コミュニティに参加しやすくなったという声も聞かれます。日本ではコミュニティ活動が平日夜に行われることが多いため、家庭の事情で参加できない人たちも多いです。そうした方々にとって、オンラインイベントであれば参加しやすいと感じてもらえるのはメリットと言えます。
また、ジェンダーは男女に限らずLGBTQを含めた枠組みになります。最近では男性がスカートを履くなど好きな格好ができる雰囲気になってきています。実際、私の知り合いの中にもそうした方は大勢います。誰でも自由に楽しくコミュニティに参加できる、そんな雰囲気を作ることが運営側に求められているでしょう。
最近では海外のDevRel界隈で「DevRel vs Developer」と題したツイートでトラブルが発生しています。ツイートした本人は「DevRelに関わる人は大げさに喜び、開発者はそうではない」という意味で選んだそうです。しかし、それでも「女性は大げさに喜ぶ」と間違ったメッセージを送ってるように見えてしまうので、良い写真ではなかったのは確かです。
「DevRel vs Developer」
DevRelに関わる人たちは、登壇をはじめとして顔を表に出す機会が多いです。そのため、こういったトラブルに巻き込まれると、後々まで尾を引く可能性があります。ジェンダートラブルに限りませんが、炎上につながるような行為は慎むべきでしょう(これはDevRel関係ありませんが…)。
おわりに
今回はいくつかのパターンに分けて、DevRel界隈での失敗談や炎上案件を紹介しました。人と人が関わる以上、どうしても問題が起きる可能性はあります。しかし、逆に人と人だからこそ理解し合える場合もあるでしょう。
無用なトラブルにならないためには、信頼の構築とコミュニケーションが重要です。揺るぎない信頼性の構築こそ、DevRel成功の鍵となるでしょう。
