boardというSaaSを提供していて、その運用における開発チームとCSチーム間での共有の話です。
社内用リリースノートとは
boardでは、ほぼ週1ペースでデプロイしているのですが、その内容を事前にCSチームに共有するため「社内用リリースノート」を書いています。
基本的なフォーマットは決めていて、以下の内容を記述しています。
## リリースノート
### 機能追加・改善
#### ユーザーさんに見えるもの
#### ユーザーさんに見えないもの
### バグ修正
### 運用や内部的なもの
## CSチームに事前に操作・把握しておいてほしいこと
## このリリースに伴うリスク
デプロイのおよそ1週間前にはリリースノートを書いて社内に共有します。
なお、エンジニア向けにはGitHubのリリースタグで管理していますが、この社内用リリースノートは「CSチーム視点で把握すべきことの共有」を目的としているので、別ものとして作成しています。
boardのステージング環境はいくつかあるのですが、そのうち1つが「次の次にリリースされる内容がデプロイされている環境」で、その環境と社内用リリースノートをセットで準備します。
CSチームは、リリースノートとその確認用環境を使って、サポート業務の合間に変更点などを確認するようにしています。
なお、大きめの機能の場合は、数週間〜1ヶ月ほど前には確認用環境と社内用リリースノートを用意し、時間をかけて事前インプットをできるようにしています。
社内用リリースノートの目的
社内用リリースノートの運用を始める前も、大きめの機能は事前共有して確認できるようにしていました。
ただ、細かいものを見落としがちだったり、サポートが忙しいと流れてしまうこともありました。
仕様やその背景の理解度は回答の精度・わかりやすさに大きく影響します。そのため、単に「その機能の説明ができる」だけでは不十分で、状況に合わせた対応ができるよう、しっかり自分の中で消化できている必要があります。
それを安定的に運用できるようにするために始めたのが「社内用リリースノート」でした。
社内用リリースノートの効果
社内用リリースノートの運用を始めて約1年ほど経つのですが、とても良かったなと感じています。
安定した事前準備
まず、「リリース前に仕様をしっかり把握しておく」という事前準備を、安定的に行えるようになりました。
CS業務の忙しさにはコントロールできない波があるので、どうしてもすぐに確認できないこともあります。そのため、CSチーム内で毎日行っている振り返りの中で、「リリースノートの確認状況」も共有するようにし、遅れている人がいれば、すぐに気づいて対応できるようにしています。
デプロイに伴うリスクの共有とコミュニケーションコストの低減
表面的に見える機能追加・改善だけでなく、「ユーザーさんに見えないもの」「運用や内部的なもの」なども書くことで、サービスの運用としてどういったことが行われているのか、CSチームが把握できます。
これにより、問い合わせの中で、普通はあまりないような問い合わせや挙動があった場合、「先日のリリースノートに書いてあったこれの影響かも」ということにすばやく気づくことができます。
また、「このリリースに伴うリスク」というコーナーを設けることで、開発側としてリスクに感じていることを共有できます。これにより、万が一問題があった場合のコミュニケーションをよりスムーズにできるようにしています。
CSチームからも「目に見えること以外にも、こんなに色々なことが行われているんだ、ということを知ることができて参考になる」という感想をもらっています。
仕様理解度の向上
リリースノートを書く際、なるべく「どういう意図の機能や改善か」ということを書くようにしています。
これにより、CSチームが確認する際に、表面的な機能を捉えるだけでなく、その背景も含めて仕様を把握できるので、仕様理解度が向上しやすくなっているようにも感じます。
CS業務において「仕様の意図の理解」は本当に大事だと考えています。大きめの機能の場合は意識しやすいですが、細かい部分だと、なかなか伝える機会がありません。ただ、社内用リリースノートを運用するようになってから、細かいものも含めて、仕様や改修の意図を共有できるようになって、とても良いなと感じています。
まとめ
普段のCS業務を行っていると、なかなかまとまった時間を確保してインプットするということが難しいので、機能追加・改善の把握に後れを取ると、キャッチアップするのが大変です。
しかも、デプロイしたら、すぐに問い合わせが来る可能性もあります。
そのため、事前にしっかり準備できている状態にすることは、安定したCS業務のためには非常に重要なポイントだと思っています。
もともと「ほぼ週1デプロイ」というペースは5年以上続けていることもあり、デプロイサイクルはとても安定していました。その中に「CSチームの事前確認」を安定的に組み込むことができ、かつ、意図やリスクなどを含めて共有できる「社内用リリースノート」は、とても効果的だったなと思います。