DevRelの施策(コード)
はじめに
前回から、数回に分けつつDevRelの基本的な考え方となる「4C」について解説しています。前回はコンテンツを取り上げました。2回目となる今回はコードについて取り上げます。コードとは、つまり「プログラミングコード」に付随する施策です。
DevRelは開発者向けのマーケティング施策となるので、コードはとても大事な要素です。むしろコードについて手を抜いたり、怠ったりしていればDevRelの成功はおぼつかないはずです。
今回は、ひと口に「コード」と言っても、実際にどのような種類があるのか、また、それぞれどのような狙いで施策が行われているのかを紹介します。
SDK・フレームワーク
SDKはSoftware Development Kitの略で、ソフトウェアを開発する際に一緒に使うと工数を削減できたり、簡略化できます。フレームワークも同義です。他にも単にDevKitといったり、Appleのように○○Kitと呼んだりもします。
多くの開発者向けサービスではAPIを公開しています。APIはハードウェアベース、ソフトウェア・OSベース、Webベースなど様々ありますが、ここではまとめてAPIと呼びます。このAPIがあることで、開発者は提供元の許容する形でアプリケーションを開発したり、拡張できます。
このAPIについて、SDKがない場合には開発者は1つ1つのプロトコル(手続き)についてプログラミングをしなければなりません。例えばWeb APIの場合、HTTPクライアントを使って認証部分を実装したり、GraphQLやgRPCを呼び出すといった場合もあるでしょう。こういった手続きは非常に煩雑になりやすく、コードが見づらくなります。SDKがあるならば、積極的に使っていきたいはずです。
例えば、類似のサービスがあり、片方はSDKが提供されていて、もう1つはSDKがなかったとします。このとき、開発者心理としてはSDKが提供されているものを選びたくなるでしょう。そのため、SDKを開発・提供することは選定理由の1つになるのです。
ただし、SDKは各プログラミング言語や各フレームワークに対して作らなければなりません。PHP向けに開発したSDKはNode.jsでは動作しません。さらにプログラミング言語自体や、依存するライブラリがバージョンアップすれば、それにあわせてメンテナンスが必要になります。そのため、どのプログラミング言語にSDKを提供するか、ちゃんと継続的にメンテナンスできるかを考えた上で決めなければなりません。
【SDK・フレームワークの例】
SDKおよびツールキット
デモアプリ
APIや自社技術を使ってどんなことができるのか、それを示したものがデモアプリです。デモアプリは、ユーザーが作りたいであろうユースケースに合わせて開発されるのが基本です。ユーザーはデモを見ることで、目的としているアプリケーションが開発できそうか判断できます。
つまり、デモアプリは選定理由になり得ます。使い始めてみてから「実はできなかった」ということが分かるのでは遅すぎます。選定する時点で自分たちの目的にマッチしていることが分かれば、安心して導入できます。
こうしたデモアプリは、ショーケースとして公式サイトに掲載されることがあります。ユーザーニーズは1つではないので、さまざまなパターンで開発しておくのがおすすめです。ただし、SDKと同じようにプログラミング言語やライブラリのバージョンアップに追従する必要があるので、メンテナンスできる体制は必要です。
このデモアプリは、あまり大型・多機能なものは作らない方が良いでしょう。多機能さを誇るのではなく、あくまでもユーザーのニーズがありそうなアプリが実現できるかを確認するものと割り切るのがお勧めです。
また、デモアプリでは基本的な技術で、分かりやすい作りに気を配る必要があります。ファイルを細分化したり、クラス設計にこだわりすぎると、デモアプリを参考にする人がどこを見れば良いか、すぐには分からないでしょう。
デモアプリが対象とするのは、自社サービスを使ったことのないビギナーの人たちです。ただでさえサービスの使い方を学ぶ必要があるのに、さらに利用しているフレームワークのマニアックな使い方まですれば、ユーザーは頭が混乱してしまいます。デモアプリは自分たちの技術力をアピールする場ではないことを覚えておいてください。
【デモアプリの例】
Flutter samples(https://flutter.github.io/samples/#)
チュートリアル
チュートリアルはドキュメントなどと連動して提供されます。最初は一部のコードだけが書かれており、チュートリアルドキュメントに従ってコードを書き進めることで、最終的な成果物を得られます。
デモアプリが一通り完成したコードを提供するのに比べて、チュートリアルは最初の段階では中途半端な状態です。そのコードをベースに自分で手を加えることによって、サービスやソフトウェアの使い方を学べる仕組みです。
チュートリアルにおいてもデモアプリと同じく、なるべく誰でも理解しやすいコードベースにすることを心がけましょう。そうしないと、自分たちのサービスを使ってもらうまでの前提知識が増え、ストレスを与えてしまいます。また、最初のコードベースの状態でエラーは出ないようにしましょう。一部のコードが書かれていない状態なのでエラーが出ないように関数やダミーの変数を定義するなどの工夫が必要です。
【チュートリアルの例】
サンプル＆チュートリアル一覧
ライブラリ・プラグイン
SDKやフレームワークほど大きくなく、手軽に利用できるのがライブラリです。API全体ではなく一部の機能だけを実装したり、UIフレームワークと密にした実装を行なったりします。
例として、SupabaseのFlutterライブラリがあります。これはDart SDKをベースとして、Flutter向けに認証機能などを提供するものです。SDKはDart向けなのでFlutter以外でも利用できるようにしつつ、Flutter向けにはUIと密にした機能が提供されます。
他にもSendGridではRuby on Rails向けのプラグインがあります。これはRuby on RailsのAction Mailerとして提供されるプラグインです。SendGridにはRuby向けのSDKもありますが、このプラグインはSDKを用いずにRuby on Railsで使いやすくする目的で作られています。なお、これは公式のライブラリではなく、有志により開発されているものです。
さらにIoT向けに機能を限定して少リソースでも動作するようにしたり、FaaS(Function as a Service)向けなどに開発されたりもします。
【ライブラリ・プラグインの例】
Flutter Package(https://pub.dev/packages/supabase_flutter)
ドキュメント内コード
開発者向けのドキュメントではサンプルコードを記載するでしょう。そうしたドキュメントや中のコードについて、ライセンスを明記するようにしましょう。開発時にドキュメント中のコードをコピペして開発に活かすことがあります。その際、ライセンスが明記されていないと安心して再利用できません。
海外の事例では、ドキュメント全体をCreative Commonsで公開していたり、さらにコードの部分だけをMIT LicenseやApache License 2.0で公開しているようです。
【ドキュメント内コード例】
コードをどのように公開するか
多くの場合、コードはオープンソース・ソフトウェアとして公開します。そうしないと、開発者が安心して自分たちの開発するソフトウェアには組み込めないからです。もし特許などが絡んでオープンソース化できないときには、ビルドしたファイルを配布するケースもあります。ドキュメントについては前述の通り、Creative Commonsで公開されているケースが多いです。
公開する場合のライセンスは、単体ソフトウェアならGPLでも良いでしょう。また、静的ライブラリとして組み込めるものはLGPLを採用する場合もあります。とは言え、最近ではMIT LicenseやApache License 2.0を選択することが多いようです。ライセンスはソフトウェアの利用に大きく関わるので、適切に設定してください。
おわりに
コードに関連した施策はDevRelの肝とも言えます。開発者のサポート教育など、さまざまな形で役立てられるでしょう。
開発言語は多種多様で、それぞれの言語ごとに開発者体験は異なります。皆さんのサービスを利用する開発者がどういった人たちか仮定を立てて、最適な言語や手法を選定するようにしてください。
