効果的で真にアジャイルな製品開発チームを思い浮かべるとき、Amazonのように毎日あるいは1日に何度もソフトウェアを本番リリースさせるようなチームを思い浮かべることが多いでしょう。
製品開発チームは頻繁なリリースによって、開発中のソリューションに関する仮説を技術的な観点とビジネス的な観点の両方から早期かつ頻繁に検証をすることができます。
技術的な観点には、製品が完全に統合され、本番環境で展開されたときに何が起こるかを検証することが含まれます。言い換えれば、「その製品を正しく構築できたか」ということです。
ビジネスの観点には、製品が提供するフィーチャー、能力、体験に対して顧客がどのように反応するかを検証することが含まれます。言い換えれば 「我々は正しい製品を構築できたか？」です。
結果として、こうしたチームは、手戻りのリスクや無駄を減らし、市場で成功する可能性を高めることができます。
このような状態を達成できているとすれば素晴らしいことであり、もしこのブログをお読みの皆さんが既にこの状態にあるのだとすれば、それは良いことです。また、もし皆さんがこのような状態を達成しうる製品の開発に取り組んでいるのであれば、あまり心配することはないでしょう。なぜならば、このような状態を達成するためには、他の人の経験やケーススターディ、グッドプラクティス（成功例）などの様々な形のヒントが世の中にはありますので、それらのヒントを生かすことができるからです。
しかしながら、必ずしもすべての業界、ビジネスモデル、技術がこれを可能にするわけではありません。私が言っているのは、非生産的な社内ガバナンスや旧態依然とした開発・エンジニアリング慣行など、自ら課した制約や障害に苦しんでいる企業やチームのことではありません。早期かつ頻繁な本番リリースが不可能か、少なくとも法外なコストがかかる状況について話しているのです。全ユーザーによる製品の頻繁なテストができない状況は、ビジネス上、規制上またはコスト上のいずれかの要因により起こります。例えば、グーグル・ピクセルスマートフォンの次の開発、すべての患者が新薬にアクセスできるようにすること、あるいはロケットを宇宙に送ることなどが良い例だと思います。
しかし、もしあなたがそのような状況にあるとしても、「アジャイルである」ことは可能であり、前述した早期の仮説テストやリスク削減の恩恵をたくさん受けることができるので安心してください。ここからは、そのための2つの戦略と一部の戦術を紹介します。
戦略#1: できるだけ早い段階でプロダクトを「リリース可能な状態」にし、実際にリリースしない場合でもその状態を維持すること
製品をリリースするビジネス上の必要性がない場合、ストレステスト、UAT（ユーザー受け入れテスト）、コンプライアンスサインオフ、文書化などを遅らせたくなります。結局これらはリリースするときにだけ必要なのですから、なぜ今やる必要があるのか？というところです。
しかし、この考え方の問題点は、時間の経過とともにリスクが蓄積していくことです。プロジェクトが終盤に差し掛かり、リリース日が近づくにつれ、あなたはリスクを最小にしたいと思うでしょう。しかし、最終的なストレステスト、UAT、コンプライアンス・サインオフを実施すると、最終的にさまざまな新しい問題が発見されます。ストレステストでアーキテクチャの大きな流れが明らかになり、多くの手戻りが発生するかもしれません。UATによって、製品フィーチャーの3分の1がほとんど誰にも使われていないことが判明し、開発チームはその代わりに別のものを作ることに時間を費やすべきだったことが明らかになるかもしれません。誰もが単なる形式的なものだと思っていたコンプライアンス・サインオフで、製品のリリースを遅らせるような悪い知らせがさまざま明らかになるかもしれません。
いわゆる「潜在的にリリース可能な」状態に製品を常に置くことで、そのようなリスクを排除することができます。スクラムでは、基本的に次のような方法でこの戦略を実行します。
1. "完成の定義 "を公式化し、完成の定義に "潜在的にリリース可能な状態"を含めること。
2. 各スプリントで、この「完成の定義」を満たす製品のインクリメントを少なくとも一つ作成するようにします。
スプリントごとにストレステスト、ユーザー受け入れテスト、コンプライアンス検証を実施することは、コストがかかる戦略のように思えるかもしれません。しかし、それを試したほとんどのチームは、コスト以上のメリットがあることに気づきます。また、これらのコストは正しいアプローチを採用することで削減することができます。例えば、適切なチーム構造（クロスファンクショナル、権限委譲されたチーム）の設定や、適切なエンジニアリング技術やツール（テスト自動化、CI/CD、シミュレーターなど）への投資などです。
この1つ目の戦略は、以下の2つ目の戦略を実現するものでもあります。
戦略#2：市場への直接的かつ徹底的なアクセスを待たずに、プロダクトに関するフィードバックを積極的に収集すること
先に見たように、製品に関する仮説をテストする理想的な方法は、製品として広く市場に出荷することです。しかし、それができない場合でも、最終的に製品を発売またはリリースできるまで、仮説を過度に蓄積させるべきではありません。そのため、さまざまな情報源から洞察を得られるよう努力してください。これらの洞察は網羅的ではないかもしれませんし、収集するのは簡単ではないかもしれませんが、あなたの製品が目標を達成する可能性を最大化する上で非常に価値があります。
これらのインサイトを収集する3つの方法を紹介します：
1. ドッグフーディングと社内ユーザーグループ
自分のドッグフードを食べること、あるいは "ドッグフーディング "とは、自分の製品やサービスを利用することです。
私が以前スクラムマスターとしてサポートしたあるチームでは、メンバーのほとんどが作った製品に純粋に情熱を持っており、勤務時間外にも積極的に製品を利用していました。そのため、チームはより創造的で、顧客のニーズや潜在的な解決策を見つけ出すことに、より自律的に取り組むことができました。Facebookをはじめ、多くの企業がこの手法を使っています。
場合によっては、ドッグフーディングは完全に有機的に起こるわけではありません。この場合、チームは、社内ユーザーのコミュニティを構築し、彼らからフィードバックを収集することに、より意図的に取り組む必要があります。
2. ユーザー代表と代理人
ユーザー代表とは、組織内またはエコシステム内で、顧客やユーザーのニーズについて話すことができる立場にある人のことです。社内では、営業やカスタマーサポートの担当者がこれにあたります。社外的には、オピニオンリーダーやコミュニティリーダー、ユーザーアドボカシーグループのメンバーなどが考えられます。これらの人々が個々に、あなたが扱っている市場全体を代表しているわけではありません。しかし、適切な人数を揃え、彼らとの効果的なやり取りを学べば、製品を本番出荷することで得られるものにかなり近いフィードバックを集めることができます。
スクラムの文脈では、少なくともスプリントレビューの間にこれらの代表者と関わりたい、あるいはプロダクトバックログのリファインメント活動で協力したいと思うかもしれません。
3. 早期アクセス（アーリーアクセス）と早期導入者（アーリーアダプター）プログラム
これは、特定の条件下で少数のユーザーに製品へのアクセスを提供するものです。例えばゲーム業界では一般的な慣行で、ビデオゲームの制作者が、ゲームの正式リリース前に貴重なフィードバックと重要な収益源を得るためにこのような方法を活用しています。
しかし、この方法は、B2Bも含めてより広範囲な場面で実施することができます。とある私のクライアントは、鉱山事業会社をターゲットにした非常に野心的なソフトウェア製品を開発していました。そこで、私とクライアントは、早い段階で対象の顧客である鉱山事業会社と2つの強力なパートナーシップを築きました。開発チーム全員が実際の鉱山に飛び、潜在的な将来のユーザーとなりうる鉱山事業会社の社員と同席し、彼らとともに重要な仮説を検証しました。
前述の通りこれは決して安い方法ではありません。しかし、間違った製品を開発してしまい、手遅れになってから理解するよりはずっと安上がりです。
まとめ
つまり、yes you can ！たとえ年に1回しかリリースしなくても、アジャイル開発を取り入れて、たくさんのベネフィットを得ることは可能なのです。重要なのは、知らないことが多くあり、失敗する可能性があることを認識する勇気と謙虚さを持つことです。そこから正しい戦略とテクニックを導入して知らないことを見つけに行き、検査と適応を繰り返し、プロダクトが成功する可能性を高めていきます。
----------------
著者について
グレゴリー・フォンテーヌは、Scrum.orgの約350名のプロフェッショナルスクラムトレーナー™（PST）の一人であり、合同会社AgoraxのCEOです。
ソフトウェア開発だけでなく、様々な分野でスクラムを適用してきた長年の経験を持っています。彼は唯一の日本語を話すPSTであり、長年にわたって日本のクライアントや学生をサポートしてきました。もっと詳しく知りたい方は、グレゴリーのクラススケジュールやアゴラックスのウェブサイトをご覧ください。