こんにちは。asatoです。
SaaSプロダクトで小さくリリースすることは良いことだ！となんとなく思いながら生きてきてしまっていたように感じます。これでは、大きくリリースしたほうがいい！と感じている人と建設的に話ができません。由々しいので、頭の中を整理します。
小さなリリースの利点ってなんだっけ？
ここでは、機能Aを機能A1〜5に小さく刻んでリリースすることを考えます。A1〜5もそれぞれ独立した価値があり、全部揃ったAは総和より大きな価値があるようなイメージです。
価値を速く提供できる
ユーザーにとって、価値は速く受け取れるほうが嬉しいです。Aの機能のうちA1の価値に強く惹かれているユーザーは、まとまったAのリリースを待つことよりも、A1が最速でリリースされることを望んでいます。
価値を早くから提供できる
プロダクトのLTV（Life Time Value）のようなことを考えると、小さくリリースを積み重ねたほうがユーザーに提供できる価値の積分は大きくなります。リリースしなければ、ユーザーに価値は届きません。どれだけ頑張っていても、リリースしなければユーザーにとって価値はまだ0です。
価値を頻繁に提供できる
小さくリリースすれば、価値を頻繁に提供できます。頻繁に価値を提供できれば、プロダクトがどんどん進化していく期待感を持ってもらえます。使いにくいところや不足した機能があっても、すぐに良くなるだろうという感覚でいてもらえます。すぐに良くなるという感覚があれば、フィードバックも集まりやすくなります。
アップデートが多い = プロダクトが断続的に進化していくという感覚は、新規顧客の獲得にも既存顧客のチャーン抑止にも効きます。すぐに良くなる、どんどん進化するという期待感は武器になります。
価値に対するフィードバックループを頻繁に回せる
小さくリリースすれば、それだけ価値に対するフィードバックループを頻繁に回すことができます。リリースは仮説検証のスタートラインです。リリースなくして実際の価値の検証はできません。
例えば、A1/A2をリリースし、その反応を見たところで、A3/A4/A5という順番で提供するよりもA5がもっとも待ち焦がれられていることがわかるかもしれません。
当初考えていたA3、A4、A5ではなく、少し変えたA3’、A4’、A5’を提供したほうが価値が感じてもらいやすいことがわかるかもしれません。
A3、A4、A5の開発を続けるより、Bの開発を開始したほうがユーザーにとって価値になるという仮説が立つかもしれません。
小さなリリースによって、ユーザーがその価値を価値だと感じるかどうかが確定します。実際にユーザーの課題解決に繋がるのか、ユーザーは使うのか、使いやすいのかが確定します。この不確実性が取り除かれることで、価値提供のアジリティを高めてくれます。さらに、実際にユーザーに価値が届いている、これからの価値に期待しているということがわかれば、チームのモチベーションもアップします。
開発方法に対するフィードバックループを頻繁に回せる
価値以外のところでも小さなリリースのメリットはたくさんあります。まずは開発方法、自分たちの働き方（Way of Working）に対しても頻繁なフィードバックループを回せるようになります。
私たちは、実際に経験してはじめてふりかえり、改善ができるようになります。リリースまでの一連のプロダクト開発の流れを経験することで、それをふりかえり、改善できます。今回の例のように機能Aを5つの小さなリリースに分割した場合、機能Aを完全に提供するまでに4回も一連の流れを改善するチャンスを得られます。例えばこの改善チャンスで一連の流れをより速くできれば、大きくリリースするよりも早く機能Aを提供できます。
もちろん、改善対象はスピードだけではありませんので、一連の流れを改善できるチャンスは多いほうがいいです。
認知負荷が減り、仕事の質を高められる
そもそもワーキングメモリが限られているので、人間は大きなものを扱うのが苦手です。大きなものを多くの要素が絡み合うため、複雑性も指数関数的に増し、認知負荷を高めます。
大きな仕事は小さな仕事に分割し、小さな仕事に集中したほうが仕事の質を高められます。仕事の大きさや先の見えなささに圧倒される心配もなくなります。「困難は分割せよ」ですね。アフリカには、「象を食べるなら一口ずつ（There is only one way to eat an elephant: a bite at a time.）」という諺もあるそうです。
仮に不具合があっても、影響を小さく抑えられ、迅速に対応できる
リリースすることで不具合が顕在化する可能性があります。ユーザーが多ければ多いほど、いろいろな使い方や状態が生まれるため、確率は増します。不具合0を完全に目指すのは時間・コストなどの費用対効果の観点で現実的ではありません。
リリースに伴う不具合をリリース前に取り除くことは大切なことですが、リリース後に迅速に対応できるようにしておくこともそれ以上に大切なことだと僕は思います。
先に述べたように、リリースを小さく分割することで認知負荷が下がり、仕事の質が向上します。小さな範囲での集中が生まれ、不具合の確率を下げられます。
また、リリースが小さければ、大きい場合と比べて影響範囲を小さく抑えられます。さらに、リリースが小さければ、仮に不具合が発生しても原因を探す範囲も最小化できていることになります。
つまり、小さなリリースでは仮に不具合が発生しても、影響範囲は小さくなり、原因特定と修正も素早くできるということです。これはユーザーに安心を提供することにもなりますし、チームがリリースに自信と勇気を持つことにも繋がります。
リリースが日常になり、心理的負荷を減らせる
「リリース」と聞くと大きなイベントに感じる人も少なくないと思います。これは、リリースが日常ではなく特別だからです。小さなリリースはリリースを適度な日常に変え、リリースに対する心理的負荷を低減してくれます。
「 ヤーキーズ・ドットソンの法則 」から始まる「最適覚醒理論」では、人間は生理的・心理的に高負荷の状態ではパフォーマンスが低下するとされています。リリースはただでさえリスクを伴います。小さなリリースで、リリースの経験を積み、少しでも心理的負荷を下げることが安定したリリースの営みを支えます。
頻繁に完了を体感でき、自己効力感が高まる
リリースを小さく刻むと、開発フローの完了を多く迎えることになります。完了は自己効力感を育ててくれます。自己効力感は、ある課題に対して「自分にはそれを遂行する能力がある」と認識している状態を指します。自己効力感があることで、自信を持って仕事ができたりより挑戦できる心持ちになります。自己効力感は、自己の達成経験がもっとも高めるのに役立つとされています。小さなリリースを体験することでチーム全体の自己効力感が高まり、次のリリースはより自信を持って、よりチャレンジできるマインドセットも育ちます。
仮にリリースが失敗になっても、影響は小さく、対応は比較的迅速に行えます。ふりかえり、次の成功に繋げればよいだけです。
でもさぁ、
とはいえ、大きなリリースのほうがこういう観点でいいじゃん、という話もあります。それでも小さなリリースを推進する理由を考えておきます。
大きいリリースのほうがインパクトを残せる
なるほど。たしかに。大きな変化のほうが「すごい！」となりやすいですよね。人間の意思決定において「印象」は重要な要素ですので、できる限りインパクトに残るリリース周知をしたいという考えはとても理解できます。
一方で、それはリリース自体を大きくまとめる必要性まであるのだろうか、とも思っています。例えばリリース自体は小さく行い、ある程度のリリースを積み上げたタイミングで大きくプレスリリースを打つことは効果的ではないのだろうか。これであれば、上記で述べた小さなリリースのメリットを得ながらインパクトを出すこともできるのではないでしょうか。
あるいは、クローズドベータやドッグフーディング（社内リリース）などの限定リリースはどうでしょう。完全ではないものの、上述のメリットは活かしたまま、対外的に大きくリリースしているように見せることができます。
それも違うのであれば、せめてデプロイのみを考えてみるのはどうですか？小さなリリースの価値に関するメリットは享受できませんが、他のメリットに関しては一定得られます。それだけでも開発チームにとっては大きな力になるはずです。
小さなリリースと大きなリリースは0か1かではなく、グラデーションがあります。双方の意見が同時に尊重される点がきっとあるはずです。
頻繁な変更を顧客は望んでいない
特にtoBプロダクトでは、こんなことを言われるケースが多いように思います。業務で利用しているプロダクトが変化することは新たな学習コストを産むため、変更は少ないほうがよいという考えです。さらに、顧客が画面キャプチャありのマニュアルを自社向けに作成しているケースもあり、マニュアル修正の作業コストもかかるケースもあります。
まず、これはSaaSのメリットと真っ向から対立しているように感じます。SaaSプロダクトを利用するメリットの一つとして、プロダクトを提供する会社主導の継続的な改善や機能追加、技術導入があげられます。これはパッケージ製品や自社開発ではシステムやコスト的に難しいポイントです。そのメリットに合わないマインドや業務があるのであれば、それはターゲット顧客ではない可能性があることは念頭においておきたいなと感じます。
もしそうではなく顧客が頻繁な変更に困惑しているのだとすれば、それらの変更に価値がない可能性を考えたほうがいいかもしれません。価値があれば困惑よりも喜びのほうが多いはずですよね。顧客が変更に困惑しているという事実があるのであれば、変更によってユーザーが得るであろう価値と、変更によってユーザーが感じるであろう困惑を比較して意思決定をしたほうなよいかもしれません。
それを置いておいても、学習コストに関しては小さなリリースのほうが有利なのではないかと思っています。なぜなら小さなリリースは、新たに学習することも小さいからです。大きな学習より小さな学習のほうが学習のハードルも低く習得までの時間もかかりません。ユーザーに全てのリリースを完全に把握してもらうことはどちらにせよ難しいです。小さなリリースで、ユーザーの業務に影響がありそうなものだけさっと学習できるように支援できる仕組みを探すほうが、リリースを大きくまとめるよりも本質的のはずです。
これはリリースノートやサポートサイト、チュートリアルなどの工夫になります。この工夫よりもリリースの大きさが論点になるのは、プロダクト開発とこれらの仕組みの間で仕事の受け渡しが発生するからでしょう。リリースの価値を届けきるためにはこれらの仕組みが重要ですが、開発チームがあまり関心をもっていなかったり協働していない場合に、リリースの大きさの議論になりがちなように感じます。
とにかく、頻繁な価値提供を望んでいない顧客はいません。価値のない変更や価値より困惑が勝る変更は望まれていません。変更の価値の見極めスキルを伸ばすことや、変更の価値をまさしく顧客に把握してもらえる仕組みをつくることのほうがリリースを大きくまとめるよりも根本的な解決になります。
全体感がわからなければそれがよいかどうか判断できない
企画フェーズのレビューでよく言われます。たしかに、この小さなリリースが全体感を損なわないか、今後のステップに繋がっていくのか、部分最適になっていないかは大切な観点です。でもだからこそ、小さくリリースしてユーザーのフィードバックを獲得していく戦略が必要なのだと考えています。無計画はダメですが、更新されることを前提としていない計画もダメです。
今後のステップを計画しておくことは前提として、それはこの小さなリリースで変わり得ることも受け入れていきましょう。1年先の可能性は無限です。小さなリリースの積み重ねでリアルなユーザーフィードバックが集まれば、その分だけ分岐を生み出すことができます。リアルなフィードバックによっては、今の良い全体感が良くなかったとわかることもあるのです。
全体感は大事ですが、どれだけ先の全体感を見越していけばよいのでしょうか？先を見越そうとすれば際限はなく、前提を変える外部要因が生まれる可能性は増えていきます。なら、戦略の方向性は捉えつつ、今目の前の課題の解決に集中してフィードバックを早期に集めるのも有効的ではないでしょうか。
一度に大きく点検してリリースしたほうが不具合が出ないのではないか
こういう感覚をチームが持っていたりチーム外から言われた場合は要注意です。品質に対して懐疑的なのだと思います。簡単に言えば、リリースしたら不具合出るんだからリリース減らしたい、減らしてほしい、ということです。
論理的には上述の通り、小さなリリースのほうな不具合が出る確率も、不具合が発生したときの対応スピードも分があります。しかし、今の問題はリリース品質に対して信頼貯金がないことです。なんとか小さくリリースするチャンスを得たり、自社のみなどの限定リリースを小さく実施し、不具合が出ないことや影響範囲の狭さ、不具合への対応スピードを体感してもらうしかありません。チャンスを得られたら、最初のうちはいつも以上にリリース品質に集中して、小さなリリースの有効性を示しましょう。
もう一つは、リグレッションです。最後に大きく点検が、段階的にそこまでの局所的な点検になることで抜け漏れが発生するのではないかと感じられることがあります。A1で開発、テストしたものがA2の開発で変更されテストされないままリリースされるのでは？という不安です。手動で全てをリグレッションテストするのもコストが嵩むので、最後に1回だけのほうがよいという意見もわかります。ここは信頼のおける自動リグレッションテストを用意できるかどうかになります。用意しましょう。小さなリリースにはそれだけの価値があります。
この課題感は大きなリリースでは解決できません。むしろ脅威。小さなリリースを実現しないとリリース品質は効果的にあがりません。なんとか信頼を勝ち得る体験をステークホルダーに提供していきましょう。
これ以上小さくできない
本当に十分小さいならOKです。でも、開発に数ヶ月を要するサイズなら今一度議論してみてもいいと思います。ユーザーは早く価値を手に入れたいんです。この部分だけでも先に手に入れば少しは救われる！というものがないか見てみてもいいはずです。
もちろん、最適なサイズはコンテキストによりますし、小さく分割することを考えること自体は価値を生みません。しかし、ユーザーは価値を求めている前提に立てば、より小さく早く価値提供できないか、を頭のどこかで考え続けていることは間違っていないはずです。
これ以上小さくできない、はユーザー目線ですか？開発都合だけになっていないか考えてみるのは、良いアプローチだと思います。
さいごに
なぜ自分が小さなリリースが良いと思っているのかを殴り書きしてみました。こうやって書き出してみると、小さなリリースには多くの利点があることがあらためてわかりました。これからもリリースを価値を感じてもらえる範囲で小さく刻んでいきたいと思います。
サポートもお待ちしております！
