2018/07/03 API × PM #01 発表資料

1. 古豪グループウェア
の新API公開までのあれこれ
サイボウズ株式会社
Kitagawa Kyohei
2018/07/03

2. About me
北川 恭平 (Kyohei Kitagawa)
 2017年～ Cybozu Garoon PM
 主な担当はAPI (他にもいろいろやってます)
 筋トレ
 Twitter
@northriver7

3. 今日のゴール
私が古豪グループウェアのAPI開発で経験した、
苦労とか苦労とかやってきたことをみなさんと共有したい。
また、API戦略としてどのような戦略(KPI等)をたてているのか教えて欲し
い意見交換して考えたい。
※どちらかというと開発系メインです。

4. サイボウズとGaroonについて

5. サイボウズの製品ラインナップ
 クラウドベースのグループウェアや業務改善サービスが軸

6. Garoon
 大規模向けグループウェア
 4600社/200万ユーザー 以上の導入実績
 2002年9月発売開始(プレスリリースより)
 オンプレ/クラウド 両バージョンをサポート
 主なアプリケーション
 スケジュール
 ワークフロー
 スペース
 掲示版
 メーラー etc…

7. Garoon の開発体制
 ベトナム＆日本の複数チーム（約8チーム）で開発
 2017年よりスクラム開発を導入
開発
PM
開発
PM
開発
PM
QAリーダーPGリーダー
PGPG PGQA QA QA SM
PGPG PGQA QA QA SM
PGPG PGQA QA QA SM
+ デザイナー
+ テクニカルライター

8. 新Garoon APIを開発するに至った経緯
 オンプレからクラウドの波にのって、付加価値を生み出したい
 クラウドサービス間連携の強化
 kintoneとの連携強化
 クラウドビジネスの創出
 APIエコノミーの醸成
 既存のAPIがイマイチ（というフィードバックが多いので見直したい）
 設計
 認証 etc…

9. 妄想する世界
API プラグイン
受動的に使われるサービス
ほーん。
便利やな。
能動的に使うサービス
こんなことも
できるのか！
もっと連携し
たい！
Garoon連携
作るぞ！
User
User
Developer

10. リリースの状況
 2017/05 WorkFlow JavaScript API 公開
 2017/08 Scheduler JavaScript API 公開
 2017/11 Scheduler JavaScript API 機能強化
 2018/02 Scheduler JavaScript API 機能強化
 2018/05 Scheduler REST API 公開！

11. APIの企画～開発にやった/やっ
ている〇つのこと

12. やったこと1：
API特化チームと担当PMを決める
 最少は少数精鋭で少人数で基本仕様を設計
→徐々に他チーム展開
 API担当PMはなるべくAPIのことだけ考える
(実際は掛け持ちも少々ありますが…)
チーム1
(API)
チーム2
(基本機能)
チーム3
(基本機能)

13. やったこと2：
Web API: The Good Partsをひたすら読む
 チームメンバーで回し読みして共通認識を醸成
 回し読む時間がもったいないので複数冊購入
 日本語しかない？のが難点…

14. やったこと3：
サービスの利用状況から攻めどころを考察
 本当は一気に全領域のAPIを公開したいが、そうもいかないので優
先度を決める
 ログ分析、ヒアリング、既に公開しているAPIの利用状況など様々な
観点からどこか攻めるかを考える
 Garoonの場合は、スケジュール、ワークフローを優先度高めに設定
→考察できたらおおまかなロードマップを引く

15. やったこと4：
他サービスのAPIをひたすら調査
 某スケジュールサービス(複数)のAPIをひたすら叩く
 某スケジュールサービス(複数)のリファレンスをひたすら読む
 ジャンル問わずAPIを叩く
 別サービスのAPIを試しながらOAuthの仕組みも学ぶ
→デファクトスタンダードな仕様がなんとなく分かってくる
→設計者の意図もなんとなく分かってくる

16. やったこと5：
POSTMANを使い倒す
 最強ツールPOSTMAN
 APIをテストするための便利なクライアントツール
 環境変数が使える
 OAuthクライアント機能も搭載

17. やったこと6：
社内外でヒアリング
 社内でAPIフリークなメンバーを集めてヒアリング
 時にはアイディアブレスト的なプチワークショップ(KJ法にハマってます)
 社外のパートナーにヒアリング
 Twitterでエゴサーチ

18. やったこと7：
Swagger Specの導入
 仕様書はConfluenceを使っているが、スクラム開発＆複数チーム開
発していると分散しがち…
→ Swagger Spec で最新の仕様をまとめる
 インデント/改行にばらつきがない統一的な仕様が無意識的に完成
 YAMLの差分で仕様レビューが可能

19. やったこと8：
仕様は仕様の向こう側まで考え抜く
 どうしたら本当に使いやすい設計になるのか？を考え抜く
 もうこれでいいやと思ってからあとひと推し考え抜く
 チームメンバーとひたすらディスカッション
 …でも、究極迷ったらデファクトスタンダードな方を選ぶ

20. やったこと9：
仕様統一化担当を任命する
 API開発チームがスケールしてきたら、API仕様を統一する役割のメ
ンバーがいると仕様統一が捗る
 役割を明確化することで細かい改善案なども出てきやすくなる
→自立的な組織へ
仕様番長

21. やったこと10：
物理的に離れている拠点のチームと作る場合、
最初は現地へ行ってワイワイする
 海外、地方など離れたチームにトランスファーする場合は、"同じ釜
の飯を食う"のが効果的
 一度会って信頼関係構築しておくとその後のやりとりがスムーズ

22. やった(ている)こと11：
APIのKGI,KPIを考える
 どの期間でどれくらいの目標を達成したら成功と言えるのかをひた
すら考える
 例：
公開から一年後のAPIトラフィック数○○
API利用顧客数○○
連携ソリューション〇個
開発者数〇人
…悩みながら日々継続議論中。
 基準とする数値は？
 えいや！で決める or なにがしかの数値を基準にする
仮説
検証 実行

23. やった(ている)こと12：
社内環境で実験する
 社内で日々利用しているGaroonを使って便利ツールの作成
 他部署を巻き込んで企画＆実施
 実際に使うことで必要な機能が見えてくることも

24. やった(ている)こと13：
公開後はフィードバックを集める
 NPS
 ヒアリング
 kintoneアプリで社内から要望を集める
 社内ハッカソン etc…

25. やった(ている)こと14：
公開後はTips/ブログを投稿する
 技術者向けサイトでアピール

26. API開発において苦労した/している
ポイント

27. 既存の仕組みを使おうとするとバグが出てくる
 古豪なだけに古傷をえぐってしまうこともしばしば…
 既存ロジック使うとバグが出てくる…
 そもそもの仕様にバグがある
 バグを直すとデグレ…
→いい機会だと思って治す！（コストを見つつ）

28. 泣く泣くリリースした仕様を変更する場合がある
 基本ポリシーは、一度公開したら出力が変わる仕様変更はしないと
している
 APIを利用しているユーザーのプログラム修正が必要になるため
 しかし、仕様統一のためやむを得ない場合も…（でも基本はNG）

29. 時間を使うポイントがチーム外の人に伝わり
づらい
 仕様検討、パフォーマンス、認証のあれこれなど開発以外の人にそ
のコストが伝わりづらいこともしばしば…
→スプリントレビューなどに参加してもらいできるだけやっていることを
共有

30. 心が折れそうになる
 中々決めきれない仕様、様々な外圧、予定通りにいかないスケ
ジュール、公開しても反応がイマイチ…
→API利用ユーザーが増えたときの楽しい未来を考える＆筋トレする

31. まとめ

32. まとめ
 Cybozu Garoon 2018年5月にREST APIをリリース
 ぜひ叩いてみてください！
 API Good Partsはチーム内で共通認識を作るのに活躍するはず
 APIを作るときは専任チームを作るとよさそう
 APIを作るチーム数が増えてきたら仕様の番人がいると統一化がス
ムーズにできそう
 API公開においてKPIを考えていくことは重要(だがなかなか難しい)
 色々と大変なことも多いが、楽しい未来を考えるとやっていける

33. おわり