ソフトウェア品質を作り込むのが苦手な理由

「品質を作り込みましょう」というのは、誰が聞いても「間違いない」意見に思います。ただ、これがとても難しい。最近、「なんでこんなに難しいんだろうなぁ」と考えて、ふと仮説が浮かんだのでメモっておきます。

品質を作り込まない理由

大きな原因の一つが、従来型開発のバイアスではないかと考えました。

従来型はプロジェクト型が多く、期限があり、一括納品なので、品質を作り込むより、納品までがんばろうという意識が働くからです。つまり、問題が多くても、最後にバグを潰せば、チェックさえしっかりやってパスすればOKということ。

その結果、プロセスの後半で網羅性の高いテストを実施する。ここでいうテストは「チェック」です。この方法だと、機能が増えるたびにどんどんチェックも増えます。

品質を作り込む理由

従来型でも品質を作り込んだほうがいいと思いますが、なかなかできない現状もありそうです。

では、なぜ品質を作り込む必要があるのか？

それはずばり、サービスを開発し運営するケースだと、リリース（納品）で仕事が終わらないからです。むしろ、リリースからがサービスを成長させる本番と言えます。

この場合、品質を作り込むと、それが投資になり、今後の開発スピードやサービスの質にもつながっていきます。かけたコストがしっかり返ってくるのです。

短い期間でリリースを繰り返すので、この質を維持するためには、テストを自動化せざるを得ません。しかも、短い期間が固定なのでずっと増やし続けることもできません。効率の良い一定量のテストが求められます。

従来型スプリントゴールの罠

アジャイル開発を導入した場合、イテレーションやスプリントといった短い期間を採用することになるので、品質を作り込まないバイアスはかからないはずです。

ただ、従来型スプリントゴールを立ててしまうと、同じ問題に遭遇する可能性が高まります。

そもそも、スプリントゴールは、従来型の開発の考え方とは違うものです。従来型はプロジェクトを完了させれば成功になるはずなので、「きちんと終わらせる」のが重要です。

しかし、スプリントゴールのようなアジャイル開発の考え方は、「完了させ、リリースし、期待する効果を得られる可能性を高める」ものです。できるだけ成功確率を上げたいということ。

このゴールが従来型にひっぱられ「リリースすること」であったり「タスクを消化すること」、「進捗30％になること」になってしまうと、従来型のように品質を作り込まないリスクが高まります。

もし、「スプリント回すので必死でトラブルが多い」状況が多いなら、従来型スプリントゴールになっていないか？疑ってみるといいかもしれません。