[レポート] 「アジリティ」と「品質」は本当にトレードオフなのか？競争力を高めるプロダクト開発の方法論 #pmconf2021

2021年10月26日(火)、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨するイベント『プロダクトマネージャーカンファレンス2021』がオンライン形式で開催されました。

当エントリでは、ブレイクアウトセッション『「アジリティ」と「品質」は本当にトレードオフなのか？競争力を高めるプロダクト開発の方法論』の参加(視聴)レポートをお届けします。

目次

• セッション概要
• セッションレポート
  • はじめに
  • Agilityがなぜ重要か
  • AgilityとQualityをどうやって共存・両立させるか
  • テスト自動化戦略
  • Measurnig the success(どうやって成功を測るか)
  • 総括
• まとめ

セッション概要

セッション概要は以下の通りです。

• 「アジリティ」と「品質」は本当にトレードオフなのか？競争力を高めるプロダクト開発の方法論

セッションレポート

はじめに

• 自己紹介
  • エンジニア歴10年以上、3ヶ国で開発に従事
  • ブログやPodcastをやっています

• 昨年のpmconf 2020で登壇したセッションは満足度1位を獲得

• 企業紹介
  • Autify(オーティファイ), AIを用いたソフトウェアテスト自動化プラットフォーム
• Autifyのソリューション：AIを用いたWeb/MobileアプリのE2Eテスト自動化サービス
  • No Codeで誰でも簡単
  • AIがメンテナンス
  • Autify for Web / Autify for Mobile

Agilityがなぜ重要か

• 競争環境が激化している中で、継続的に価値を届ける必要が出てきている(使う側が「継続的な価値」を求めてきている)
• 素早く変化し続けなければ生き残っていけない
• 大手テック企業の例
  • Netflixでは1日1000回以上デプロイしている
  • Amazonでは11.7秒毎にデプロイしている
• Autifyで行った「リリース頻度の調査」：45.1%が週1回以上リリースしている
  • 顧客ニーズの素早い変化に対応するには、高速なリリースサイクルが必要不可欠
• ただ、Agilityが重要といいつつも、こんな事ありませんか？これらどれかに当てはまる場合、AgilityとQualityがトレードオフになってしまっている可能性が高い
  • 機能開発に想定以上の時間が掛かっている
  • リリースする度にバグが出る
  • QA期間が長くてなかなかリリース出来ない
  • ユーザーの指摘でバグに初めて気づく
• AgilityとQualityはトレードオフにならざるを得ないのか？：時期に依って優先するものが変わる
  • プロダクトローンチ前〜直後：Agility優先、まずはユーザーに受け入れられないと意味がない。少し壊れていても早く出して改善を重ねる
  • プロダクトローンチ1〜2年後：徐々にユーザーが増え、品質基準も向上／プロダクトが複雑化し、Qualityを優先してQAに時間を掛ける
• トレードオフからの脱却：AgilityもQualityも重視・優先する方法はある

AgilityとQualityをどうやって共存・両立させるか

• そもそもなぜ「トレードオフ」が発生するのか
  • 1.技術負債が溜まる
  • 2.品質基準が上がる
  • 3.テスト量が増える

1.技術負債が溜まる

• 変更のコストが負債の様に積み上がっていくこと＝「技術負債」
• 原因は様々：過去仕様の負債化、システムの複雑化、テストしにくいコード等など...
• 技術負債が溜まると、結果的に開発に想像以上の時間が掛かるようになっていってしまう
• 技術負債は"避けられない"もの
  • 仕様は変わり続けるし、完璧な設計もコードも無い
  • 借りすぎない「返済プラン」があるのならば、負債は悪いことではない
• 技術負債をどのように返却するか
  • 進み続ける限り負債は溜まるし、一度に返却も出来ない→定常的に返却しよう
  • Autifyでは「スプリントの30%」を改善に当てている

2.品質基準が上がる

• プロダクトの進化に合わせて、以下の要素も「増える」。
  • ユーザー・顧客の数
  • バグによる売上インパクトの影響
  • 信頼既存によるインパクトの影響
• 自分たちにとって何が品質基準になるのか「定義」をすべき
  • 絶対に守るべきもの
  • バグが出ても迅速に対応する仕組み
  • 必ずしも「バグをゼロにする」というものではない(アジャイルで進めていく以上、これ(バグゼロ)はほぼ不可能と考える)

3.テスト量が増える

• 品質基準の上昇に伴い、カバー範囲や機能も増える
• 理想的なテスト量は線形で増加
• 自動化で対応しない限り、ここ(QAに掛かる時間)は比例して長くなり続けてしまう
• テスト自動化で対応、何をすべきか？
  • まずはUnit/Integrationテストを書き、カバーしきれない部分をE2E自動テスト/手動E2Eテストで補う
  • Ice Cream Cone：Agilityを優先すると陥りがちなケースでもある
    • Unit/Integrationテストが殆ど無い
    • 大部分を手動E2Eテストに依存、自動E2Eテストが殆ど無い場合も
    • アンチバターンとは言われてはいるが、状況としては悪いことではない。現実的に事業を前に進めた結果でもあるので

テスト自動化戦略

• テスト自動化戦略
  • Ice cream coneの解消は容易ではない
  • Unit/Integrationを増やしつつ、E2Eテストを自動化して負荷を下げるのが現実解として機能するのでは
    • LayerX様の事例：
      • LayerXのQAへの取り組み〜アイスクリームの誘惑に負けるな〜 - LayerX エンジニアブログ
• Shift LeftとShift Right
  • シフトレフト・ライトのテストアプローチで何ができる？ | SHIFT ASIA -ソフトウェア品質保証のプロフェッショナル-
  • Shift Left：より早くテストする/Shift Right：本番でテスト
• 修正コストは後になるほど高くなる
  • NASAのリサーチより。リリース後の修正コストは開発中の最大100倍にもなる。なので早くバグに気付けることが出来れば修正コストもその分低く抑えられる
  • より早く頻繁にテストを回そう

Measurnig the success(どうやって成功を測るか)

• Googleが出している「DORA Metrics」というのがある。いわゆる「Elite」になれているかを測る指標

• 指標：Autifyでは現在1と3と対象として追っている
  • デプロイ頻度(Deployment Frequency)
    • 週のデプロイ回数をトラックし、四半期でデプロイの目標数値を設定
  • 変更までのリードタイム(Lead Time for Changes)
  • デプロイ毎の問題発生率(Change Failure Rate)
    • 15%以下に抑えると良い
  • サービスリストアに掛かる時間(Time to Restore Service)

総括

• 「トレードオフ」から脱却する方法はある
• Eliteを目指そう。そのためには
  • 技術負債は定期的に返済
  • 品質基準を定義
  • テストを自動化＆より早く頻繁に回す

まとめ

という訳で、プロダクトマネージャーカンファレンス2021のセッション『「アジリティ」と「品質」は本当にトレードオフなのか？競争力を高めるプロダクト開発の方法論』の視聴レポートでした。

• プロダクトマネージャーカンファレンス 2021 の記事一覧 | DevelopersIO