こんにちは。クローバの門屋です。PMアドベントカレンダー１２日目書かせていただきます。
今日はサイボウズ時代にやっていた Tech PM という仕事について紹介したいと思います。退職した会社でやっていたことを書くのもあれですが中の人からぜひといわれたので遠慮なく書かせていただきます。暴露話みたいなのはあまりありません。
Tech PM とは
Tech PM と聞くと、プロダクトにどういうフレームワークを使うかとか、いわゆる技術責任者的なポジションを想像するかもしれませんが、わたしがやっていたのはそうではなくて、デベロッパー向けのAPIやSDK、他サービスとのインテグレーションを担当するPMのことです。日本ではあまり馴染みがありませんが、ググってみると海の向こうではけっこうそういう求人があります。API PMとかインテグレーションPMとかのほうがわかりやすいかもしれませんがここではTech PMと呼ぶことにします。
Tech PM の責任範囲
Tech PM の責任範囲は以下のようなものです。
- API、SDKの開発ロードマップの作成、ライフサイクルの管理
- API、SDK及び周辺ツールの開発、ドキュメントの作成、公開
- インテグレーション先パートナーの拡大
- インテグレーション先パートナー、顧客、及びステークホルダーとの調整
なぜそういう仕事をしていたか
４年ほど前になりますが、サンフランシスコで行われていたSalesforce社主催のDreamforceというイベントに参加したことがありました。そこでデベロッパー向けのキーノートがあり、壇上のおじさん（たぶんエンジニアのえらい人）がSalesforceのデータがコマンドラインから取り出せるぞというデモをやっていました。キーノートでやるわりにはただそれだけのデモでしたが観客は興味津々できいており、周辺の展示ブースでは冷蔵庫とスマホのアプリがつながります。このボタンを押すとドアが開きます！ みたいなよくわからないブースに人が群がっていました。そのときわたしは、ああ自分がやるべきはこれだと確信しました。壇上でコマンドラインツールのデモをやる。観客にめっちゃうける。これだと。さっそく上司にAPIのPMが必要だと直談判しましたがまったく取り合ってもらえず、その頃組織が変わってあまりやる仕事もなかったので勝手に kintone というサービスでTechよりのPMをやることにしました。
はじめはSIコンサルを担当している部署と協力しながら細々とSDKやドキュメント整備するだけだったのですが、当時 kintone はUSでの販売に本腰を入れ始めたところで、USでのプロモーションのためにシリコンバレーのサービス数社とインテグレーションを行うことになり、そこに必要なアイデアを売り込むかたちでなんとか正式なPMとして認めてもらった感じでした。英語も満足にできないのにサンフランシスコのとある企業にひとりで訪問して半ば体よく追い返されたのはよい思い出です。
わたしが退職した今もそのポジションは残っているので、まあ自己満足ではなかったなと思っています。
周囲の理解
普通のPMと違って、Tech PMはデベロッパーに向けた要件を決めることが多いため、あまり要件に関心を持ってもらえないということがあります。これはどういうことかというと、普通の機能要件だったら、営業や経営陣へのレビューなどでこの画面や機能はもっとこうすべきだとかいった指摘がなされるものなのですが、このAPIのインターフェイスはこうであるべきみたいな指摘が営業から出ることはほぼありません。これは余計な要求を受けなくて済むのでやりやすい一方で、社内でのフィードバックがもらいにくいという側面もあります。
あとでも書きますが、APIの開発は一度出してしまうとあとから修正が難しいため、最初はクローズドβで公開するなど、フィードバックをもらいやすいしくみ整えておく必要があります。ユーザーコミュニティを活用するのも有効です。
kintone の場合は開発と並行してユーザーコミュニティを育てていくという活動が行われていて、今では6000人のデベロッパーが参加しています。
cybozu developer network
それから、ステイクホルダーに説明する際には、「誰に向けて」「なんのために」やるのかという目的を明確することで理解が得やすくなります（この開発によって、USのパートナー企業が自社サービスとインテグレーションできるようになる、など）。
ターゲットを誰にするか
これはけっこう重要です。そんなもんはデベロッパーに決まってるだろうと思われるかもしれませんが、同じデベロッパーでも業務よりのSIなのか、スタートアップのエンジニアなのか、ISVなのかで優先するものや内容がずいぶん違います。
業務よりのSIerを相手にするのでしたら、がんばってOAuthによる認可機能を実装しても使ってもらえない可能性があります。もしかしたらRESTよりSOAPのAPIが必要かもしれませんし、ODBCドライバのほうがより求められるかもしれません。コマンドラインツールはわたしがデモをするために必須です。Tech PM はそのへんのさじ加減を決める役割を担っています。
APIは多少冗長なくらいでよい
普通のPMと同じように、Tech PMも当然仕様についてエンジニアとすり合わせを行います。APIについていえば外部仕様と呼ばれるものはAPIのインターフェイス仕様なので、内部仕様とかぶるところがあり難しいのですが、エンジニア任せにしてしまうと内部仕様の都合でインターフェイスが決められてしまうことがあります。わたしもそうですがエンジニアはとにかく正規化こそが正義というところがあるので、例えばユーザーが所属する部署のメンバーを取得したいのにまずユーザー情報APIを呼び、それからユーザー所属部署APIを呼び、部署情報APIを呼び、部署のメンバーAPIを呼び、やっと目的のものが取得できる、みたいなことになりかねません。きちんとユースケースを想定して、適切なインターフェイスを考えましょう。個人的には多少冗長なくらいでよいと思っています。
一度つくると変えられない
APIはそれを使ってサードパーティのベンダーが開発を行うという性質上、一度作ってしまったものをかんたんに変えることはできません。極端なはなし、エラーメッセージを変えただけでお叱りを受けることもあります。抜本的にAPIを変える場合には、一度作ったものはそのままにして、新しいバージョンとして公開するのが常套手段ですが、古いバージョンをいつまで残すか、また古いバージョンのAPIを使っているベンダーやサービスをどこまでフォローするかという問題がつきまといます。C向けのサービスだと思い切ってがっつり変えてしまうところもありますが、Tech PMはそのへんのライフサイクルのマネージメントを行う責務があります。
参考になるもの
API設計の具体的な知見についてはいろいろな資料があると思いますので特に参考になりそうなものを挙げてみます。
zendesk developers
kintone のプラグインストアを開発するうえで、Zendeskのプラグインマーケットの設計思想やドキュメントは非常に参考になりました。API Proxyもここからヒントを得ています。
B2B版のIFTTT的サービス。実際にこのサービス上でインテグレーションしてみることで、連携しやすいAPIがどんなものか理解が深まります。
Best Practices for Designing a Pragmatic RESTful API
API設計のベストプラクティスについて網羅的に書かれた記事です（実は最近知りました）。
こちらに翻訳版があります。
さいごに
Tech PMは普通のPMより技術よりな部分があり、エンジニアとの境目がつきにくいところがあります。実際、わたしもSDKやコマンドラインツールのコードは自分で書いていました。USのWebサービスでは他サービスとのインテグレーションが当たり前に受け入れられており、APIやSDKの開発がサービスの重要な戦略として扱われています。日本もこういう流れになってくるのではないかと思います。
今は起業したのでPMではありませんが、kintone のエヴァンジェリストの活動もやっていて、壇上でコマンドラインツールのデモをやりました！