Morning Girl

Web API, Windows, C#, .NET, Dynamics 365/CRM etc..

主要クラウドサービスのPMが自社のAPIを語る! API x PM #01 参加レポート

f:id:sugimomoto:20180703191135j:plain

参加対象者が「製品やサービスをProduct Manager、Product Owner、製品企画として運営する方で「API」が守備範囲の方」!

サイボウズ・Sansan・CloudSign・freee」現在のクラウドサービス最前線でAPIに関わるPMの方々が自社のAPIの狙い、戦略、苦労を語る、というかなり舵を振り切った勉強会、API x PM #01に参加してきました。

apipm.connpass.com

こんなところでやりました

会場は サイボウズ 東京オフィスでした。こんな感じでおしゃれなカフェみたいなところ!

Twitter

当日のTwitter ハッシュタグは #apipm です。

twitter.com

togetterのまとめもあります!(関さん@fullvirtue ありがとうございます!)

togetter.com

Session1: 「古豪グループウェアREST API公開までのあれこれ」Cybozu Garoon PM 北川さん

最初のセッションは、CybouzuでGaroonのPMを務める北川さん

APIの企画~開発にやった/やっていること(14個!)、API開発において苦労した/しているポイントを語ってくれました!

f:id:sugimomoto:20180703191121j:plain

www.slideshare.net

普段APIのPMを務めている、もしくはこれからAPIを開発しようとしている人は見ておいて損は無いスライドです!

私が特に気になったスライドは「API特化チームと担当PMを決める」「APIのKGI,KPIを考える」です。

f:id:sugimomoto:20180705173920p:plain

f:id:sugimomoto:20180705211650p:plain

API専任でチームを組めるのは、ある程度リソースも必要になってくるかと思いますが、今後このチームの存在がデファクトスタンダードになってくるのではないか? と感じます。

KGI,KPIに関しては、どのように指標を定めるべきか、北川さん自身も模索しながら進めていると言っていたのが印象的でした。

この内容に触れて、私自身も少し調べたのですが、以下のAPIs for KPIsが結構参考になるかもしれません。

www.programmableweb.com

APIのKPIを6つのレンズ、DX(Developer Experience)という考え方、実際のEvernonteが立てているAPIを通じたKPI等参考になる考え方が溢れていました。(2014年公開というのが驚き、、、。)今後の勉強会でこのあたり掘り下げてもみたいですね。

苦労した点で気になったのは、ビジネスサイドの理解、なぜこんなにも時間がかかるのか? と言った声が聞かれる部分でした。

f:id:sugimomoto:20180705173934p:plain

通常の画面・UIベースで提供されるものよりも、わかりづらく、見えづらいからこその声かもしれません。しかしながら、スプリントレビューからビジネスサイドの人たちにも参加してもらうことで意見をもらいつつも現場の状況を理解してもらっているという取り組み方が印象的でした。

全体を通じて、如何にAPIを提供していく環境をより良く、よりビジネスサイドにも理解してもらいながら進めるか? といった部分の工夫や戦略が感じられるセッションでとてもおもしろかったです!

北川さんのチームが開発しているCybouzu Garoon REST API のドキュメントは以下から見ることができます。

Garoon REST API 一覧 – cybozu developer network

Session2: 「API as a Productのトレンド」 CData Software Japan 疋田さん

続いて、CData Software Japanの疋田さんから。(私も所属している会社です)

最近提唱され、徐々に認知が広まってきたキーワード「API as a Product」のトレンドについて。

f:id:sugimomoto:20180703195723j:plain

www.slideshare.net

APIを公開したのはいいけど、どうやったらもっと使われるようになるの? APIエコノミーとは言われてるけど、その目標に対してどう取り組むべきか? といった点を「API as a Product」というキーワードをベースにお話してくれました。

f:id:sugimomoto:20180705174123p:plain

そもそもの目的に立ち返ると、APIのユーザーは「Developer」

対象とするユーザーが違えば、そこに生じる、生じるべきUX(Developer Experienceと言ってもいいでしょう)も違うべきというメッセージが印象的でした。

f:id:sugimomoto:20180705174147p:plain

f:id:sugimomoto:20180705174226p:plain

北川さんのKPIのお話と同じように、まず求めるべきはAPI 戦略。何を狙って、どのように製品のUXを高めるのか。

f:id:sugimomoto:20180705215920p:plain

そのために、会の名称でもあるAPI PMの重要性(APIの仕様はもちろん、マーケティングや営業、サポートに渡るまでの権限を持てる人)、APIそのものの使いやすいさ、APIドキュメントの重要性、プロモーションチャネル・アプローチの違い、トータルでAPI as a Productという考え方を実現するための要素が詰め込まれたセッションでした。

まだ日本ではAPI PMもAPI as a Productという考え方も浸透していないですが、重要なキーワードとなってくることは間違いないように思います。

CData で提供しているAPI用Driverの一覧は以下で確認できます。

https://www.cdata.com/jp/drivers/www.cdata.com

LT1:「クラウドサインはなぜエコシステムに投資するのか」クラウドサイン PM 三科さん

クラウドサインの三科さんからは、先日プレスリリースも出したばかりの内容をベースに、クラウドサインがなぜエコシステムに力を入れているのか? を語ってくれました。

f:id:sugimomoto:20180703201214j:plain

speakerdeck.com

個人的にもそのアーキテクチャや機能が大好きなクラウドサインのAPIですが、以下のプレスリリースにもある通りAPI エコシステムに対する取り組みを強めている会社の一つです。

お知らせ — 「リーガルテック API エコシステム」の構築を開始

なぜそこまでクラウドサインはAPIエコシステムに投資するのか? という点については以下プレスリリースでも書かれている通り、幅広い契約業務というプロセスにおいて、様々なリーガルテックや他社サービスと連携し合うことが、さらなる進化に必要であると考えているからだそうです。

契約に付随する業務としては、その他にも契約締結のための稟議申請や、外国との契約の場合は翻訳業務なども発生する中、全てを当社で網羅するのではなく、それぞれの課題に 特化したリーガルテックサービスと連携することで、さらなる進化を目指すべきであると考えております。

f:id:sugimomoto:20180705185855p:plain

これはマイクロサービス的考え方、例えばAPI中心のサービスであるSendgridやTwilioに近い、様々なサービスと共存しあいながら、ユーザーの利便性・ビジネスの成長を目指す、とても共感できる考え方だなと思います。

実際にパートナーや連携サービスの増加も凄まじい。

f:id:sugimomoto:20180705174912p:plain

あと、苦労話も少しお話していたのですが、「今あるAPIで対応できない相談が多い」というのが印象的でした。

f:id:sugimomoto:20180705190009p:plain

これはAPI側だけの話に限ったものではなく、クラウドサイン本体としての機能や法制度上の課題等もあるそうで。

ただ、APIで達成できることがUIと遜色の無いクラウドサインだからこそ、UIで提供する機能と共に高いレベルを求められつつあるのではないかな? と感じました。

クラウドサインのAPIドキュメントは以下からどうぞ。

app.swaggerhub.com

LT2:「SansanオープンAPI ドキュメント制作の裏側」Sansan PM 尾部さん

Sansan PM 尾部さんからは最近刷新されたSansan オープンAPIの ドキュメントについて。

そのリアルな制作の裏側を語ってくれました。

f:id:sugimomoto:20180703202721j:plain

www.slideshare.net

Sansan API は私も実際に触っていた経験があるのですが、つい最近までAPIのドキュメントをPDF! で提供していました。さらに検証環境が無いので、尾部さんには申し訳ないのですが、試すだけでもなかなか敷居が高いAPIでした。

しかしそれら、APIに関わる環境を一新。ドキュメントはWebベースで公開し

f:id:sugimomoto:20180705174922p:plain

APIを使用するまでの手続きを簡略化! トライアルアカウントも提供!

f:id:sugimomoto:20180705174927p:plain

私も日々APIが公開されたというプレスリリースを見ては、API使わせてくれ!と、問い合わせ・這いずり回っている人間なのですが、とても悲しいことに、未だにトライアルアカウントも無く、仕様書はExcelやPDF、挙句の果てにまずNDA・・・。

しかし、こういった取り組みにより、営業系メンバーからも好評を得ているようで認知のされやすさがまず格段に変わったとのことでした。

f:id:sugimomoto:20180705223314p:plain

疋田さんのセッションでも述べられていましたが、デベロッパーに対するUX(DX)が良くなければ、使ってもらう機会するら逸してしまうのがAPIの怖いところだと思います。今後さらなるSansan APIの進化に期待です。

SansanのAPIドキュメントは以下から見ることができます。

docs.ap.sansan.com

LT3:「freeeオープンプラットフォーム構想とその運営よもやま」freee PM/執行役員 坂本さん

最後はfreee PM/執行役員 坂本さんから。スライドは裏話がたくさん載っているため非公開とのこと。

f:id:sugimomoto:20180703203439j:plain

freeeといえば、最近打ち出したAPIエコノミー形成に向けた「オープンプラットフォーム戦略」が様々なニュースサイトでも取り上げられ、話題になったことが記憶に新しいです。

jp.techcrunch.com

freee自身はAPIを会計freeeをリリースした同年、なんとプロダクトリリースから7ヶ月後(2013年)に公開。

また最近はプレスリリースにもある通り、API連携の専任チームによるサポート体制の強化、APIドキュメントだけでなく、開発者向けポータルサイト「freee Developers Community」を公開と、どんどんオープンプラットフォーム戦略を進めています。

f:id:sugimomoto:20180705225518p:plain

セッションでは「freeeがなぜオープンプラットフォーム戦略を打ち出しているのか?」から、この戦略を強く推し進めるための内部的な体制のとり方や、freeeが周辺のプロダクトとどのような関係性を描いていきたいかといった内容に触れていました。

特にCTO直轄で現在このオープンプラットフォーム戦略を進めているというお話は、現在のAPI環境を物語る上で一番強烈なメッセージだったと思います。

freeeのAPI ドキュメント・開発者コミュニティも提供されているデベロッパーポータルは以下からどうぞ。

freee Developers Community | freee Developers Community

終わりに

個人的にAPIにはすごく思い入れがあったのもありますが、とても刺激的な勉強会でした!

第2回も構想が進んでいるようですので、今回参加できなかった方は是非参加してみてください!