仕様変更とコミュニケーションの進め方

こんにちは！freeeのニックです。スプラトゥーン3の開発が発表されて、ワクワクが抑えられない今日この頃です。

今回は、2020年12月に実施されたAPIの大幅な仕様変更について、どのように開発者コミュニケーションを進めていったかについてお話しします。

freeeのPublic APIについて

freeeのPublic APIは、仕様や使い方をドキュメントとして公開し、誰でも好きな時にAPIを利用した開発ができるようにしています。

自分はPublic APIの利用促進を進める「ディベロッパーリレーション」というロールを担当していて、APIの情報発信や開発者の皆様とのリレーション構築を中心に業務を行っています。

Breaking Change (破壊的変更) とは

「Breaking Change」という言葉をご存知でしょうか。

APIなど、外部連携サービスのバージョンアップを行う場合、互換性を保ちながら進めるのが通常のやり方です。「後方互換性」と呼ばれています。

一方で、サービスの継続性や品質担保のために、止むを得ず互換性を犠牲にしてでもバージョンアップを行うべき場合があります。後方互換性を担保せずにバージョンアップを行うことを「Breaking Chagne」と呼びます。日本語では「破壊的変更」と呼ばれたりします。

仕様変更をする理由はケースバイケースですが、今回は

開発者からのフィードバック、仕様面のちぐはぐさの解消
開発者が安心に、手戻りなく開発に取り組むための改善

など、開発者の皆様が安心して開発に取り組めるよう、実施することになりました。

Breaking Change の詳細については、まっつーの投稿でより詳しい説明が行われているため、ぜひご覧ください。

APIの大幅な仕様変更とコミュニケーションプランの作成

仕様変更に先立って、関係者の皆様に支障が出ないよう、前もってコミュニケーションプランを作成しました。

コミュニケーションプランは、おおむね以下の手順で進めています。

コミュニケーションプランの作成フロー

最初に、仕様変更の内容確認。どんな理由で、どのように仕様が変わるかを把握します。

変更点が把握できたら、仕様変更のインパクトを見積もります。影響を受けるサードパーティはどの程度存在するか、特に影響が大きい変更はどこか、などを、ログをもとに算出します。

仕様変更の内容によって、規模感は上下します。微小な変更の場合は小規模なプランで済ませますが、今回は影響範囲が大きいと判断し、プランも大掛かりなものとなりました。

次に、大まかなスケジュールを作成します。プロジェクトのマイルストーンをおおよそ設定。いつまでに何を行うのかを設定します。スケジュールをもとに、本格的なコミュニケーションプランの作成を行いました。

コミュニーションプランのタイムライン

今回の仕様変更では、事前に半年間の切り替え期間を設定。開発者の皆様に前もって新バージョンを提供し、余裕を持った改修に取り組んでいただけるよう配慮しました。

社内外への告知プランを作成する

コミュニケーションプランをもとに、社内外のステークホルダーに説明を行い、情報発信する準備を進めました。意識したことは「広く、大きく伝えて巻き込む」こと。APIはインフラの一部なので、皆さんに理解してもらい、協力してもらうことが大事です。

一方で、APIの技術情報は、営業担当者やマーケティング担当者の皆様には理解が難しい側面があります。そういった方々に、できるだけわかりやすく説明を行い、協力してもらいたい内容をまとめて力を貸していただきました。

実際の情報拡散ルートをまとめると、以下のような形になります。

社内外のステークホルダーに対するコミュニケーション設計。社内の各部署から関係各所へ連絡を行なった。

大事なのは、「情報が必要な方に届け切ること」です。リリースノートを公開するだけでは、情報は届きません。社内関係者の皆様にご協力いただき、各方面に連絡をしてもらいました。個別カスタマイズを行っているクライアントへは、社内の営業担当部門から。アドバイザーの先にいらっしゃっるAPI利用ユーザー様へは、アドバイザー担当部門を含め、誰に対して連絡を行うか整理しました。

下記は、仕様変更に影響があるAPIコール数の推移です。皆様に協力いただいたおかげで、プラン通り切り替えが進んで行きました。

コミュニケーションプランの実行に伴うAPIコール数の推移