tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

リリース間隔が開いてようが、開発はアジャイルにやった方が良いのでは?

はじめに

Xで「toB SaaSはリリース期間を長く取る必要があるので、アジャイルでない開発プロセスでも良いのではないか? (意訳)」という内容の投稿を読み、自分の中では答えが出ている問いだったのでメモがわりの投稿です。

「リリース間隔は短ければ良い」とは限らないプロダクトは確かにある

プロダクトにもよるのでしょうが、「toB向けのプロダクトでは必ずしもリリース間隔が短いことが良いとは限らない」のは事実だと思います。

  • プロダクトの展開前に変更内容の周知や、サポート・セールスの教育・学習が必要
  • プロダクトの更新作業にコストがかかる。オンプレで運用されているとか
  • そもそもユーザーが頻繁なアップデートを望んでいない など

リリース日の決定を開発以外の部門に委ねるメリット

「開発の終了 = リリース」だとすると、リリース日に合わせて成果が最大化できるように開発スケジュールを組もうと考えますが、「開発の終了 != リリース」だとどうでしょう?

「この機能は開発が完了しました。いつリリースしてもらっても大丈夫です。セールス・マーケティング・サポートの都合に合わせて、一番良いリリース日を好きに選んでください」と言えると、いろんな選択肢が考えられます。マーケティングは大きなプロモーションを打とうとするでしょうし、サポートは問い合わせが多い事項の改善を早く出したいと考えるでしょう。リリースタイミングを短くできなくても、いつリリースするかがコントールできると、事業として取れる打ち手は広がります。

過去に聞いて良いと思ったtoBプロダクトのリリース管理のやり方

「オンプレ環境にインストールして利用するタイプのソフトウェア」でしたが、年に3回のリリースが予定されており、「いつリリースされるか」「リリースに何が含まれるか」は公開されていませんでした。問い合わせをするとおおまかなロードマップは共有してもらえ、「いつのリリースに含まれるかは確約できないが、開発チームはこの機能に取り組んでいる。これが搭載されればこんな課題が解決できる」という話は聞くことができました。確約ではないけどおおよその実現時期も知ることはできました。展示会に合わせた大きなプロモーションとともにリリースされることもあれば、しれっと新バージョンが出ているということもありました。内部では希望の期日に開発が間に合うことも間に合わないこともあったと思うのですが、リリース日を調整するなどして対応していたのではないかと思います。

まとめ

リリース間隔が開いていて短くすることが叶わなくても、開発はアジャイルに短いサイクルで確認しながら進めた方が良いし、開発の終了とリリースを同じにしなければならない理由はないはずです。リリースのコントロールステークホルダーに委ねることができると、事業上の選択肢を広く持つことができます。