はじめに
2021年11月24日に、Autify CEOの近澤を話者に「AgilityとQualityを両立し競争力を高めるプロダクト開発手法」ウェブセミナーを開催いたしました。この記事では、登壇時に用いたスライドも交えながら、ビジネスやプロダクトがいかにAgilityとQualityを両立しながら競争力を高めていくかをセミナーレポート形式でお伝えします。
当日ご参加いただけなかった方も、ぜひご覧ください！
なぜAgilityが重要なのか?
現在のソフトウェア市場では、企業間の競争が激化しています。そこで、競合他社よりも素早く、かつ継続的に顧客のニーズへ応える必要性が出てきました。
大手テック企業のAgilityについて、デプロイ頻度を指標に調べてみました。
NETFLIXは1日1,000回以上。Amazonに関しては11.7秒ごとにデプロイと、すごい数字になっています。
弊社が行なった調査でも、45.1％の企業が週1回以上のリリースをしているという結果が出ています。
リリース頻度を上げると「開発に想定以上の時間がかかったり」「リリースのたびにバグが出たり」「ユーザーの指摘でバグに気付いたり」といったケースが増えてきます。こういった場合は、AgilityとQualityがトレードオフになっています。
AgilityとQualityのトレードオフを図解する
それでは、AgilityとQualityがトレードオフとなっている状態とは一体どんな状態でしょうか？
4象限に分けて分類してみました。縦軸をAgility、横軸をQualityとしています。
プロダクトの初期段階では、Qualityよりもまずはプロダクトを作り上げることが大事なので、Agilityを優先して開発する傾向が強いように思います。このパターンは、左上の「Low quality trade-off」に当てはまります。一方、プロダクトが成熟していくと品質基準が上がり、Agilityを犠牲にしてしまう場合が多くなってきます。このパターンは、右下の「Low agility trade-off」に当てはまります。
そういったトレードオフから脱却し、右上の「Elite」を目指すためには、具体的にどうすればいいのでしょうか？
なぜAgilityとQualityのトレードオフが発生するのか？
まずは、なぜトレードオフが発生するのか考えてみましょう。トレードオフが発生する原因には「技術負債が溜まる」「品質基準が上がる」「テスト量が増える」の3つがあると考えています。
そもそも技術負債とは、変更のコストが負債のように積み上がっていくことを指しています。コードの一部に過去の仕様が残ったり、システムが複雑化したりするうち、次第に技術負債が溜まっていきます
技術負債の改善を開発フローに組み込もう
技術負債が溜まると、開発に想定以上の時間がかかってしまいます。変更が広範囲になったり、予期せぬバグが発生したり、仕様理解に時間がかかったり。そういったパターンがよくあります。
とはいえ、技術負債の蓄積は避けられませんし、決して悪いことではないと思います。変更を繰り返すからこそ、最初から完璧な設計はできないということを念頭に置く必要があります。ですから、お金を借りて事業を回すのと同じように、計画的に負債を返却していくことが重要です。
そこで普段の開発の流れの中に「技術負債の返却」を組み入れると、定期的に負債を返却しAgilityを高めることができるようになります。実際にAutifyではスプリントの30%を、技術負債の返却に充てています。
品質の基準を定義しよう
続いて、AgilityとQualityのトレードオフが発生する2つ目の原因「品質基準が上がる」についてご説明します。ソフトウェアのユーザーが増えていくと、バグによる売上減や、信頼毀損のインパクトも大きくなっていきます。そういった背景があると、品質の基準は自然と上がっていきます。
これを解決するためには、品質基準を定義することが重要になってきます。バグをゼロにすることは不可能なので、代わりに何を守らなければならないか、きちんと定義していく必要があるということです。
加えて、バグが出たとしても迅速にそれを検知し巻き戻せる仕組みを構築できれば、もしもの際も最悪の事態は防げます。アジャイル開発ではテストに長時間を充てることができないので、開発を進めながら品質の基準を定義していく必要があります。
テストを自動化するしかない
そして、AgilityとQualityのトレードオフが発生する3つ目の原因「テスト量が増える」についてです。
ソフトウェアの機能を増やしていくと、スライドのグラフのように、リリースのたびにテスト量も増え続けていきます。つまり、QAに必要な時間は増え続ける一方です。これについては、自動化するしかないと思っています。
テストのピラミッドとアイスクリームコーン
では、どうやって自動化しましょう？自動化には色々な方法があって、QAの文脈では4つのテスト手法から成り立つ、ピラミッドの図がよく知られています。
しかし実際には、綺麗にピラミッドを作れているケースは少ないと思っています。なぜなら、事業のフェーズに合わせて「Agility優先」から「Quality優先」の開発体制に移行していくと、ユニット / インテグレーションテストをほとんど書けていない状況が発生してしまうからです。
ピラミッドとボリュームが逆になった「アイスクリームコーン」は、この分野のアンチパターンとよく呼ばれます。ただ、事業を進めていく上では悪いことではないと思います。だからこそ、アイスクリームコーンを解消する方法が重要になってきます。
アイスクリームコーンの解消は、簡単な話ではありません。そもそもテストを書きづらいからこそ、そういった状態に陥っているケースもあるからです。
アイスクリームコーンの解消に向けた現実的な戦略は、ユニット / インテグレーションテストを少しずつ増やしていくのと同時に、E2Eテストの自動化も進めることだと思います。1つのピラミッドに、上と下の両方からアプローチしていく形です。
我々のお客様であるLayerXさまは実際に、この方法でアイスクリームコーンを解消されています。AgilityとQualityを両立させた、非常によい事例となっています。
参考：LayerXのQAへの取り組み〜アイスクリームの誘惑に負けるな
テストフェーズの負担を減らすには？
加えてお話ししたいのが、テストには「Shift Left」（より早くテストする）と「Shift Right」（本番でテストする）、2つの考え方があることです。テストフェーズだけでテストをすると、テストフェーズだけのボリュームが増えていきます。本当にAgilityを高めるためには、テストフェーズの負荷を減らしていく必要があります。
「Shift Right」については、本番での監視とロールバックの仕組みを整備することで、テストフェーズの負荷を減らすことができます。
「Shift Left」については、頻繁にテストを回して、なるべく早い段階でバグを発見できると理想的です。バグに気付く段階が早ければ早いほど、バグの修正コストは低くなります。
「AgilityとQualityを両立できているか？」確かめる方法
それでは、AgilityとQualityの両立をどうやって測っていくのか。我々はスライドの4つの指標を参考にしています。
Autifyでは現在「1. Deployment Frequency（リリース頻度）」を追っています。しかし、リリースのたびにバグが発生していては意味がありませんから、「3. Change Failure Rate（変更に対する失敗率）」も追うようにしています。
参考：Google Cloud で実行されている DevOps 組織の有効性を評価する
まとめ
ここまでお話しした内容を実現することで、AgilityとQualityのトレードオフから脱却することができるのではないかと考えています。
具体的にどうすればいいかのまとめなのですが、「技術負債は定期的に返却すること」「品質基準を定義すること」「テストを自動化し、早く頻繁に回すこと」が大切になってきます。
Autifyを活用すれば、テストを自動化し、早く頻繁に回すことができますし、そこから品質基準を定義し、技術負債の返却にも繋げていく事が可能です。
Autifyに興味があるという方は、ぜひ14日間のフリートライアルをお試しください。
Autifyではこの他にも品質保証やテスト、アジャイル開発に役立つ資料を無料で公開していますので、ぜひこちらからご覧ください。