SaaSならではの、リリース後の改善サイクルの取り組み
動くものを安定かつ継続して出すことを開発チームの活動の重要なこととして置いたことで、非エンジニアのプロダクト関係者も実際に「動くもの」を見ることが可能となり、速やかなフィードバックを挙げられるようになりました。それらはプロダクトオーナーのもとにすぐ届くこととなり、プロダクトの進むべき姿や改善へ繋がる体制に至ることができたと考えています。
リリース後程なくして、freee社内のエンジニアやUXデザイナーなどプロダクト制作に関わる人たちに向けてプロジェクト管理freeeの運用が開始されました。そこでも利用者の生の声を多くもらえたのですが、そこでも「こうすればこの課題は解決できそうだが、やってみてはどうか？」とチーム内で話し合ってはスプリントの開発計画に載せて実装し、翌週にはQAを経てリリースするということを繰り返し行っていきました。
こうしたプロダクト改善がより進められるよう、数回の開発スプリントのうちの1回を「改善スプリント」と題した専用のスプリントを設けることも始めています。ここではバックログに存在するユーザーストーリーを軸にした機能開発は行わずに、フィードバック対応を含んだ機能面および実装面の改善を行うことを目的としています。現時点でリリース済みの機能における利用者のUXの向上はもちろんのこと、開発チームが抱えている技術的負債、あるいはエンジニア特有の実装内容に対する不満や不安感を解消するといった内容も含めており、みんなが笑顔になれることを目指す施策としています。
ちなみにこの改善スプリントはチーム内では通称「５５１スプリント」と呼ばれています。関西圏の人ならばその理由を察することができるかもしれませんね。
おわりに
今回は、開発チームが新規プロダクトを作り上げていくためにどのように準備、計画をして、開発を進め、そして継続させていったのかをご紹介させていただきました。不確実な要素がある、リソースに限りがあるなど開発進行にはさまざまな課題があるかと思われますが、そのような状況でもできることをしっかり進めることで、成果を生み出すことができると考えています。これから同じようにプロダクトを作り上げていく全てのプロダクトマネージャー、およびエンジニアの方々の参考になれば幸いです。
次回は、私たち開発チームのアウトプットの下支えをしてくださっているQAチーム編です。この度アジャイルQAの採用により得られているメリットもご紹介しましたが、それを支えるQAチームはどのような仕組みを作り、そしてQAを進められているのでしょうか。どうぞご期待ください。
