短いサイクルでリリースし続けるには

はじめに

昨年登壇させていただいたAgile Japanですが、2021年の今年はDay0のプレイベントに、所属しているIPA アジャイルWGの一員として、関わらせていただきました。
今回は、グループワークという形で「アジャイルソフトウェア開発宣言の読みとき方」をベースに議論させていただいたのですが、その時の議論を少し振り返りたいと思います。

テーマは何？

このグループワーク、アジャイルWGメンバー8人が事前に用意したテーマを各グループで話し合うという形式で行ったのですが、私の担当は、以下の2つでした。
1) 成果物を2-3週間で、リリースし続ける
2) よい技術、よい設計、よい品質の追求

簡単にまとめると、1) は短期間でリリースすることで、ビジネス価値が変わる前に使われ始め、顧客から早期にフィードバックを受けることが重要、2) は、よい技術、よい設計、よい品質を追求し続けることが、素早く、品質良く、変化に対応できる
ということです。

このうち、1) について盛り上がったので、少しお話したいと思います。

どうやったら実現できるか

所属している企業やプロジェクトの体制、作成しているプロダクトの特性によって、変わるところはありますが、議論の中で上がったポイントを少し掘り下げたいと思います。

①どこに時間がかかるのか認識を合わせる
スピードが出ないときに、よくあるのですが、時間がかかるといっても、言語化って意外に大事なんですよね。まずは認識を合わせて、改善するポイントを明確にしないと、改善できるはずのものがうまくいかないという現場はよく見かけます。

②プロダクトバックログを小さくする
プロダクトバックログの分解するだけでリリースサイクルが早まることもあります。結果的に同じなら、「それ意味あるの？」と思うかも知れないですが、早くフィードバック受けられるというのが大きいです。結果的に手戻りも減ります。また、何よりも作っている人もステークホルダーも常に前に進んでいる感じがするのがいいですね。
私の場合、日本語、次に英語、その後、残りの言語といったように、段階的にリリースすることもありますし、デザインに悩んだら、まずはリリースして、A・Bテストで最終案を決めるというやり方など、工夫すれば色々とあります。

③品質とのバランスをとる
品証がいるようなプロジェクトだと特に起きがちなのですが、品質とのバランスで苦労していることもよく見かけます。ただ、個人的には品質といっても守るべきものから、問題があれば改善をすればいいものもあるので、短期間でリリースし続けるのであれば、見直しが必要だと思っています。
もちろん、自動試験の導入など、自動化できるものは自動化する前提ではありますが、システムを使う人や不具合が発生したときの問題の重要性などを考えながらやっています。

やり方も変えるし、開発のペースも変えていかないといけないので、最初は苦労するのですが、今までの経験からすると、うまく回りだすと、自然とできるようになってくるので、試してみてください。

それでは