何をもってリリース完了なのか？は、明確に定義したほうがいい。

本記事はWeb系の自社開発企業における、自社サービスをチームで運用している方を対象とした記事になっています。

「今日はリリースとは何か？」

について、思うことがあったので書くことにしました。

これを読んでいる皆さんの中にも、Web系の自社開発企業に勤めていらっしゃる方もいるかと思います。そんな皆さんに質問です。

リリースをどう定義しているか？考えたことがあるでしょうか？

僕は、ぼんやりとしかありませんでした。

例えば、リリースとは自分たちが運用しているWebサイトに更新がかかること。というくらいにしか捉えていませんでした。

だから事故りましたw

手戻りが発生したり、やり直したり、追加で開発が必要になったりしました。

これではチームとして開発スピードや、効果検証の速度も落ちて、ひいては事業の競争力も落ちてしまいます。Webのサービスは模倣しやすいので、チームの事業を推進するスピードはライバル企業との競争力の源泉です。

それなのに、本来は1つの施策開発で済んだのに、あれもこれも追加となり余分な開発が必要になった経験は皆さんもあるのではないでしょうか？

これはなぜ起こるのでしょうか？

どうすればリリース後の追加改修を減らせるか

自分が考えた結論としては、リリース後の検証項目の合意をとることです。

施策の依頼者が目指すべきWebサイトの状態があるでしょう。そこから逆算して、今必要とする1つの機能を作るとします。

その機能を抽象化すれば「何かしらアクションを何かしら出力を返す」ものではないでしょうか？

では、アクションのパターンやそこから出力される結果は何試行すればいいでしょうか？全て検証できれば安心ですが、リソースも限られているので、理想は、最も少ない検証項目で全ての出力結果が想定どおりかを確認できる検証項目を洗い出すことです。

これを依頼者とエンジニアで合意を得ることが大切だと思っています。

そして、それが仕様になります。

僕はこれをすることで想定外の追加改修や、リリース前のエラーの発見率の向上にもつながりました。

そして、これはテストコードを書く技術の向上にも繋がりました。

これを読んでいる方の中にはもっと厳密な定義をされている方もいるかもしれませんが、以前の僕のようにリリースをフワッと捉えていて、追加改修に追われて、いつまで経っても終わらないないーーーー。と嘆いている方がいたら、是非実践してほしいなと思いました。

今日は以上です。ありがとうございました。