みなさん、こんにちは。エンジニアリングマネージャーの Kobaan です。
最近チェアのせいか腰が痛いため、オフィスチェアを研究しているのですが、お値段が天井で選ぶのに困り果てています。何かおすすめがあったらおしえてください。
前回アドベントカレンダーで書き残したことの続きです。 リリーストレインを使ってデリバリーマネジメントを行うことで非常に楽になってきたので、せっかくなので記事にしようかなと思って筆を取りました。
リリーストレインを行うきっかけ
これはわかりやすくて、以前は１チームの開発物しかリリースプロセスに乗らなかったので、割とうまくいっていたのですが、会社が拡大するうちに
- 複数の機能開発アウトプットをリリースプロセスに載せる必要があった
- Biz チームからリリースタイミングの未来日付が求められるようになった
などがあり、お客様にプロダクトを届けるまでをしっかりマネジメントするという意味のデリバリーマネジメントが必要になりました。
アウトプットを高品質かつ低遅延でリリースする
弊社プロダクトはエンタープライズなシステムでの利用も多いため、品質によってはお客様への多大なご迷惑をおかけするリスクも多分に含んでいます。
そのため、一斉テストという最終的なデグレテストおよび総合テストを兼ねたテストフェーズを設けています。
今まではこの機能開発が一斉テストに一部食い込んだり、そのため一斉テストの実施回数を増やさざるを得ず、結果リリース日が後ろ倒しになってしまう、と言うことが度々発生していました。
その遅延をできるだけ解消するためにリリーストレインを導入することにしました。
リリーストレインとは
リリーストレインとは、一言でいうと締切を作った上で締切に間に合うものしかリリース対象にしない、と言うものです。
なんとなく見掛け上は「なんだ難しくなさそうじゃん？」って思うのですが割と落とし穴も存在しています。
- 落とし穴１：「あとちょっとだから間に合わせたい」が発生する。
- 落とし穴２：完了時の品質がまばらでQA時に不具合が多発し、結果リリース遅延のリスクとなる。
落とし穴１：「あとちょっとだから間に合わせたい」が発生する。
プロダクトを作る立場として、当たり前ですが、できるだけ早く世に出したいという気持ちが強いです。それはテックタッチメンバーも変わりがなく（むしろより強く感じます）、だからこそ「あと少し待って」が発生するのですが、できる限りお断りしています。
結局のところ、アウトカムを最大化することが必須なプロダクト開発において、
- QAプロセスの延伸による納期の遅延
- 計画外のQA項目の追加は品質担保力の低下につながる
といったリアクションがリリース後のアウトカム減少リスクにつながるからです。
すなわち、日々のスクラムでのファシリが重要となります。（私はスクラムマスターも兼任しているので結果として自分に返ってくるかんじになります。いやはや・・・）
落とし穴２：完了時の品質がまばらでQA時に不具合が多発し、結果リリース遅延のリスクとなる。
同じ人が開発していなかったり、技術レベルやスタックが異なる機能開発も多くそうなった場合、品質レベルはまばらになってしまいます。 そのためDoD（Definition of Done：完了の定義）を整理しきることが重要となります。
私の運営しているスクラムチームでは、DoDをスプリントプランニングの際に
- 完了条件としてサブタスクをしっかり上げきる
- 受け入れ条件をチーム内で考え切る
ということを重要視してプランニングを行なっています。
そうすることで、チーム内での認識齟齬や品質の是正を行なっています。
副作用として、締切ができるためリリース日付もある程度先が読めるようになり、お客様へも不具合や要望に対する機能をデリバリーできるタイミングを伝えられるようになったことは 小さいですがプロダクト進化の一つかなと思っています。
終わりに
これらはまだ、基盤を整えたに過ぎません。今後は、自動化や機能間の影響を最小化し、品質を高めてリリーストレインを簡略化することでデリバリーにかかるコストを低減し、より頻度の多いデリバリーを目指して行けたらなと考えています。
そんな私たちに協力してくれる仲間を募集中です！！
