ユーザーに素早く価値を届ける!アトラス流の社内リリースノートとは?

みなさまこんにちは、さいとう(白)です。Confitを含めたいくつかのアトラスサービスで、PdM/PjMを担当しています。

今回は、アトラスサービスの社内リリースノートについてご紹介します。一般的なリリースノートは、プロダクトの更新内容をユーザーに伝えるために作成・公開するものだと思います。アトラスサービスでは、直接的な顧客が学協会や大会運営組織であるのと、サービスで提供している機能が多く利用シーンも多岐に渡るため、必要な情報を必要なタイミングで的確にお伝えできるよう、対外的な情報共有はセールス担当やサポート担当から直接顧客へ伝えることが多くなっています。そのため、アトラスサービスの開発チームでは社内リリースノートを作成して、セールス・サポートチームに共有しています。

社内リリースノートを書く理由

社内リリースノートが必要な理由は、プロダクトの更新頻度が多いことにあります。アトラスで展開しているサービスは、より利便性を高める機能追加・拡張や、細かな改善・不具合の解消などホットフィックスリリースのため、常に高頻度で更新を続けています。ConfitとSMOOSYを例に挙げると、2020年のリリース回数は下記の通りです(本記事公開時の11月30日現在)。

サービス 機能追加・拡張
リリース回数
ホットフィックス
リリース回数
合計
Confit 20 46 66
SMOOSY 19 17 36

Confitだけでも月あたり5〜6回のリリースをしている計算になりますが、各リリースには大小さまざまな変更がいくつも含まれています。これは何らかの形で記録を残していかないと、何がいつ更新されたのか(または更新される予定なのか)わからなくなることが容易に想像できると思います。

アトラスサービスのセールス、サポートは、顧客である学協会や大会運営組織に対して、必ず担当者が付いています。特定のリリースにおいて、各担当者が「何が変更されたのか(何が変更される予定なのか)」、「どのタイミングでどの範囲のユーザーに影響があるのか」そういった内容を正確に把握し、必要に応じて顧客へアナウンスする必要があります。また、顧客から要望のあった機能を実現できるようになったり、困っていた不具合が解消されたり、そういった更新があれば、いち早く顧客へ伝えることができます。これらは、アトラスサービスをより活用いただくために重要なことです。

少し大袈裟にまとめると、社内リリースノートはサービスの進化をより速く正確に共有し、より効果的に利用してもらうための一役を担っています。

アトラス流の社内リリースノートの書き方

では、実際にアトラスではどのようなリリースノートを書いているかをご紹介します。リリースノートはDocBaseで作成し、公開時にSlackで関係者へ周知しています。記載内容については、機能拡張・追加リリース時とホットフィックスリリース時でフォーマットを分けています。

機能拡張・追加リリース

このリリースにはサービスの利便性向上や運用改善など様々な開発目的がありますが、そういったそもそもの目的に加えて、拡張・追加した機能の概要や、既存部分への影響、運用プロセスの追加・変更点などの注意事項があれば記載しています。基本的な記載事項は下記の通りです。

項目 記載内容
開発目的 現状の課題を、課題の背景とあわせて明確に記載します。課題を解決した結果どうなるのか、ユーザーが享受するメリット、アトラスのビジネスメリットなどのゴール設定も記載します。
前提条件 すべてのユーザーではなく特定のユーザーのみ利用可能であったり、新機能の提供にともなって廃止する機能があるなど、前提条件があれば記載します。
機能概要 変更対象となる機能の概要を記載します。必要に応じて、スクリーションショットや図表も交えて変更点を明確にします。
注意事項 運用・導入手順の変更点や、予期されるリスクなど、注意すべきことがあれば記載します。

ホットフィックスリリース

細かな調整やバグフィックスが目的のリリースです。リリース日、変更対象の機能と変更点をシンプルに記載します。加えて、バグフィックスであればその事象内容や発生条件、変更による影響もあわせて記載します。

こちらのリリースノートはマイナーバージョン毎にDocBase記事を作成し、対象のバージョンでどのような変更が反映されたかを、ざっと確認できるようにしています。

社内リリースノートの成果と大事なポイント

セールス・サポートチームでは、社内リリースノートをもとに週次の進捗会議でどの顧客に何を伝えるべきか、チームメンバー全員で確認・共有しています。冒頭に挙げたような、対外的なアナウンスをする際の情報源としてリリースノートを活用しています。

開発チームの目線では、セールス・サポートチームからのリリース内容に関する問い合わせが減ったと感じています。以前のCTO大神の記事でご紹介したように、仕様検討のプロセスにはセールス・サポートチームも参加しており、リリースノートに記載するような内容は常に共有しています。ただ、リリースのタイミングで「どんな変更になるんだっけ…」と思い出したり、「そもそもどういう経緯で開発したんだっけ…」と後から調べたいときに、50ページもある仕様書から必要な情報を見つけ出すのってけっこう大変なんですよね。そういった仕様検討以降のプロセスで参照することが多い情報を、リリースノートとして切り出すイメージです。そのうえで大事なポイントは下記3点だと考えています。

  • タイムリーかつ容易にアクセスできること
  • 後から見返したときに、時系列に沿って各リリースの内容を把握できること
  • セールス・運用のフェーズで必要な情報が、要点を押さえて記載されていること

DocBaseは記事のグループ分けやタグ付けができるので、サービス・バージョン毎の管理も楽にできると思います。

おわりに

今回は、アトラスサービスの社内リリースノートについてご紹介しました。セールスやサポートとの連携がうまくいかず、何かいい情報共有方法はないかとお悩みのエンジニアの方にとって、参考になれば嬉しいです。こんな感じで、アトラスはエンジニアとセールス・サポートが一丸となって継続的にサービスを改善し、その価値をみなさまにお届けしていきますので、今後ともよろしくお願いします。

この記事を書いた人