これまでに挙げてきた施策は次の通りです。

• ドキュメント整備
• ブログ
• ソーシャルメディア
• イベント
• メールマガジン
• オンラインコミュニティ

APIを開発したものの、利用者数が伸びずに苦戦しているといった話は度々聞かれますが、実際のところAPIを開発しただけにとどまっているなんてケースが殆どです。利用者の立場として、面白いかも分からないものを、あえて苦労してまで使いたいと思うでしょうか。

もしSDKが提供されていて、かつそれが各プログラミング言語のパッケージ管理で導入できるとすればどうでしょう。さらにサンプルも多数登録されていて、それらを見れば自分が作りたいものができそうな雰囲気がしてくれば、ようやく重い腰を上げてみようと思うかも知れません。そのための必要なライブラリ、ソフトウェアを作るのもDevRelにおいて大事なのは仕事です。

SDKで大事なのはAPIがモダンな作りになっているかどうかです。メソッド名のつけ方、引数の取り方だけでも開発者の技術力は分かります。開発者として、技術力が低いライブラリは使いたいと思わないですし、元サービスの技術力まで判断されてしまうでしょう。そのためSDKはなるべくキレイなコードで、テストコードも十分書かれていなければなりません。

さらにSDKはオープンソース・ソフトウェアになっているべきで、ライセンスはMIT LicenseやApache License 2.0などの利用制限のゆるいものを選択しましょう。間違ってもやってはいけないのは以下のようなことです。

• ライセンスを明記していないのにオープンソースと発表
• オープンソース・ライセンスに独自の事項を追加
• SDKでGPLなどの汚染度の高いライセンスを採用（LGPLであれば場合によってはOKです）

デモのソフトウェアについてもライセンスはなるべく緩いものを採用し、GitHubなどからダウンロードできるようになっているべきでしょう。Zipファイルでダウンロードなどはあまり格好良くありませんのでやめたほうがいいでしょう（GitHubのZipファイルダウンロードのリンクであれば可）。

なお、デモはあまり作り込まないのが大事です。基本的にデモを見るのは熟練者ではなく初心者です。真似して作れるレベルに抑えておけばいいでしょう。物凄いことが実現するとしても、それをやるためのコード量が長ければ誰も試してみたいと思わないはずです。何よりUIやデザイン面の工数が増えますので、本当に知ってほしいSDK部分のコード割合は少なくなってしまうはずです。

そこでオススメなのはデモのチュートリアル化です。チュートリアルはユーザが実際に手を動かしながら作品を作っていきます。つまり手を動かせるレベルに止めなければなりません。あまり時間がかかるものは嫌がられますし、あまり単純すぎても作っていて面白くないでしょう。バランスが大事です。その結果がデモのソフトウェアであれば、初級者がちょうど自分の手の届く範囲で作れるものになるはずです。

他にもブログのTipsで使うためにプログラムを書くというのも良くあります。そうしたコードもGitHubなどにアップするようにすれば自然とオンライン上に参考になるコードが増えることにつながるでしょう。