OFFICIAL SNS
DevRelの施策を考える際、デベロッパージャーニーを意識すると分かりやすくなります。この時、基礎になる考えとして紹介したいのがAIRDOメソッドです。
AIRDOメソッドは、あなたのサービスを知らない状態から、自分たちのプロダクトをリリース・運用までの開発者体験を状態ごとに区切ったものです。
図にすると以下の通りです。
未知の状態から、あなたのサービスを見つけるまでのフェーズです。この時に見つけるきっかけは以下のようなものが想定されます。
あなたのサービスに興味を持ち、調べ始めた段階です。類似サービスとの比較も行う状態です。この時役立つのは、以下のような情報です。
この時期にまず必要なのは、公式情報としてのドキュメントや事例です。特に大きな日本企業においては事例が重要です。自社と同じカテゴリーの企業が利用しているかどうかは、必ずチェックされます。
そして、同時に必要なのが第三者視点での評価です。Qiitaなどで利用記事が書かれていたり、コミュニティ（オンライン・オフライン）で情報が活発にやり取りされているかどうかは、導入可否に影響を与えるでしょう。
ユーザー登録するフェーズです。このフェーズはすでに調査し終わっているので、大きな障壁はないはずです。ただし、トライアルの有無によってユーザー登録の障壁の高さが変わります。
他にもソーシャルログインができるかどうか、SSO対応かどうかで、いざ利用しようと思ったら躓いて…というケースもあるので油断はできません。この段階では、とにかくストレスなく登録完了するのが大事です。
あなたのサービスを開発フローに組み込む段階です。この段階で必要な情報は、たとえば以下になります。
この段階で必要なのは、あなたのサービスを使うのが目的ではないという考えです。あなたのサービスは単なる部品であり、開発者のやりたいことを阻害してはいけません。あなたのサービスが彼らの開発のボトルネックになってはいけないのです。
そのため、極力エラーが出ずに使える必要があります。エラーは実行時エラーは話になりませんが、エラーハンドリングのしやすさや、そもそも「こうやれば動くだろう」という予想通りの開発を実現できるべきです。開発者はこれまでの経験に基づいて、コードを書きますので、独自のやり方や制約を組み込むべきではありません。
そして万一エラーが出たとしても、まずセルフサポートできる仕組みが必要です。SDKで分かりやすいエラーメッセージを出す、API側で分かりやすいエラーを出す、さらにドキュメントでフォローできるなど多段階で開発者をサポートしなければなりません。それができないとコミュニティで聞くことになり、さらにそこでも回答が期待できないとサポートに問い合わせが必要です。これは数時間〜1日開発が止まってしまい、開発体験が悪いものになるでしょう。
最後は運用です。APIなどの場合、開発フェーズで組み込んでしまうと、ほぼそのままです。前述の通り、開発者はあなたのサービスを利用するのが目的ではないので、安定して動いている限りは触らずに済ませたいのです。そして、あなたのサービスはそれを叶えられるよう、常に安定して問題なく動作し続ける必要があります。
SDKは常に後方互換性が維持されている必要がありますし、かといって関連ライブラリのバージョンアップには追従し続ける必要があります。コードは常にテストされた状態で、バージョンアップしたらエラーが出るといった事態は避けなければなりません。
そのため、SDK設計はとても重要です。将来的な拡張も考えながら、柔軟性を持たせた設計が求められます。APIのバージョンが変わった場合でも安定して提供できる必要があるでしょう。
今回はAIRDOメソッドについて紹介しました。開発者体験をベースに考えることで、自分たちが行おうと考えている施策がどのステージにいる開発者に刺さるのかを考えるきっかけになるでしょう。
また、開発者がどこでドロップしているのかを測定することで、どの施策を強化すべきかも考えられます。他社との差別化を考える上で、その比較にも利用できます。ぜひ活用してください。
メールにてDevRelに関するニュース、アップデートをお送りします。
Contact is below.