Aipoはおかげさまで3万人にご利用いただいています。ユーザーが増えても最小最速のリリースを実現できるよう、リリース内容にあわせてリリース方法を選んでいます。
目次
リリース戦略を立てることになったきっかけ
もともとユーザー全員に同じタイミングでリリースする方法をとっていました。一度に全員にリリースするためリリースノートは書きやすいものの、一発勝負というところもあり、リリース後にパフォーマンスのボトルネックが発覚する、アップデートで逆にユーザーの使い勝手が悪くなるなどリスクもあるリリース方法でした。
課題を感じながらも具体的な改善策がないままリリースフローを変えることができていませんでした。
そんな中、戦略的なリリースに取り組むきっかけとなった出来事が起こります。
UIリニューアル
2018年、新たにサイドメニューを配置するUIリニューアルをしました。
当時のリリースノートを見ると大きな変更が3つも同時にリリースされており、ユーザーに負担をかけるリリースだったと反省しています。
UIリニューアルでは画面の構成が変わるため、ある程度のフィードバックがあることは予想していましたが、フィードバックをいただく中で顧客の解像度がまだまだ低かったことを実感しました。
サイドメニューを追加するということは、メインコンテンツの幅がそのぶん狭くなります。50ピクセルのサイドバーが増えたことで「今まで10文字表示されていたところが2文字表示が少なくなってしまった」「1行で表示されていたものが改行されるようになってしまった」といった声を多くいただきました。
この経験を通して、ビジネス向けカレンダーとして1画面の情報量を重要視されているユーザーが多くいらっしゃることを理解することができました。
それと同時に今のリリース方法だと多くのユーザーに影響を与えることになり、細かな調整に柔軟に対応しづらいという問題点があることがわかりました。またリリースの影響を受けるユーザーの数だけ反響があるため、ユーザーサポートが対応しきれなくなる問題も浮かび上がってきました。
これらの反省をもとに3つのリリースフローをつくりました。
１．ユーザーごとリリース
ユーザーをグルーピングして段階的にリリース内容を適用していきます。
このフローをつかうケース
- ほとんどのユーザーに影響するUI変更、仕様変更
- 新しい画面の追加を含む新機能
メニュー位置の変更やボタン配置の変更などほとんどのユーザーが使う機能に対するUIの変更や仕様変更をする場合にはユーザーごとリリースをしています。
このしくみによりユーザーを限定したベータ版リリースをおこないフィードバックを受けながら開発を進めることができるようになりました。新機能開発時には基本的にユーザーごとリリースを選択しています。
具体的なリリースフロー
新機能をリリースする場合のユーザーごとリリースの流れは次のようになっています。
- 社内リリースしてフィードバックをもらう
- 機能の要望をあげてくれたユーザーにリリースしてフィードバックをもらう
- 1%のユーザーにリリースしてフィードバックをもらう
- 10%のユーザーにリリースして反応を見る
- 必要に応じてサービス内で告知する
- 全ユーザーにリリースして反応を見る
1%、10%とリリース範囲を広げていますが、実際にはさらに細かく数段階に分けてリリース範囲を調整しています。リリースノートを出すころにはほとんどのユーザーが使い始めている、なんてこともあります。Aipoには1,700社、30,000人の利用者がいますが、会社単位だけではなく1ユーザー単位でリリースをコントロールできるようになっています。
リリース対象の切り替えはGitHubが採用しているフィーチャーフラグと同じ方法で実現しています。アプリケーションとしては1つですがその中で特定の機能にアクセスできる、できないをフラグをもたせてコントロールしています。
ユーザーごとリリースで大事になるのはスケジュール感です。サービス提供側としてはリリースしたらすぐにフィードバックをくれるもの、と期待してしまいがちですが、ユーザーは業務のためにプロダクトを使っていてフィードバックをするために使っているわけではありません。
今までの経験上、リリースしてすぐ「ネガティブな反応がないから受け入れられた」と判断するのは早く、1週間ほどたたないとフィードバックが出てこないことが多いようです。
そのためリリース範囲を広げるサイクルは1日ずつではなく、1週間ずつのサイクルにして数週間かけて全ユーザーに適用をしています。リリースの最初の段階、つまり機能の要望をあげてくれたユーザーにリリースしたタイミング、1%のユーザーにリリースしたタイミングでこちらから積極的にお声がけすることで多くのフィードバックを得られるようにしています。
特定の機能にアクセスできる、できないのフラグだけでなく実際にその機能を使った、まだ使ってないという情報をチャットサポートツールに連携することでユーザーを限定したベータ版リリースの案内やヒアリングをしやすくしています。
２．フェーズごとリリース
機能をフェーズに分けて段階的にリリースしています。
このフローをつかうケース
- UI変更、仕様変更が少なく部分ごとに適用できる機能
- 新しい画面の追加を含む新機能（ユーザー毎リリースと組み合わせる）
1つの大きな機能もフェーズに分けてリリースすることで、小さく検証していくことができます。1ヶ月以内でMVP（Minimum Viable Product）を作成するようにフェーズを区切ることで、機能として求められていない、さらなるブラッシュアップのために作り直す必要がある、などの判断を素早くできるようにしています。大きな機能も最大1ヶ月という期間ごとにフェーズを分けることでユーザーの反応を確かめながら開発を進めることができるようになりました。
以前はフェーズを分けていなかったため、1年をかけて開発した新機能が全然使われないということもありました。このあたりの詳しい話はこちらにまとめています。
３．一括リリース
すべてのユーザーに一回で機能をまるごとリリースします。
このフローをつかうケース
- ユーザーが気がつかないレベルの小さい変更
- ユーザーが選択しないと利用可能にならない機能
「プラン変更を申し込む」→「契約内容を変更する」などの文言変更やユーザーが設定を切り替えることで試しに使ってみて合わなければもとに戻せる機能については一括リリースをしています。
細かくリリースするメリット
リリース対象となるユーザーや機能の範囲を小さくすることで次のようなメリットがうまれます。
小さくすばやく検証できる
いきなりの大幅な仕様変更はユーザーがついてこられなくなってしまいますが、小さい変更を数多くリリースすることで早く小さく失敗し、ユーザーのフィードバックをもとに素早く軌道修正して目指す姿に近づけていくことができます。
撤退の判断が早くできる
1年かけて作った機能の撤退を判断するには大きな決断が必要ですが、1週間かけて作った機能の撤退を判断する場合は失敗を最小限にとどめることができます。また小さな決断を数多く重ねることで判断の精度を磨いていくことができます。
影響を最小限にできる
3万人にリリースしたら最大で3万人からフィードバックがありますが、1人だけにリリースしたらフィードバックは最大1人です。そのようにして影響範囲を最小限にできます。
リリース内容にあわせたリリース方法を選ぶことで最小最速のリリースを実現しています。
一緒に働く仲間を募集しています。
新卒採用・中途採用を問わず、年間を通して、さまざまな職種を募集しています。「すぐに仕事がしたい」「話を聞いてみたい」「オフィスを訪問してみたい」など、ご応募をお待ちしています。共に未来をカタチにする仲間を待っています。
