Monthly Archives: January 2024

年に1回しかリリースできなくても、アジャイルを導入できるのか？

​​効果的で真にアジャイルな製品開発チームを思い浮かべるとき、Amazonのように毎日あるいは1日に何度もソフトウェアを本番リリースさせるようなチームを思い浮かべることが多いでしょう。 製品開発チームは頻繁なリリースによって、開発中のソリューションに関する仮説を技術的な観点とビジネス的な観点の両方から早期かつ頻繁に検証をすることができます。 技術的な観点には、製品が完全に統合され、本番環境で展開されたときに何が起こるかを検証することが含まれます。言い換えれば、「その製品を正しく構築できたか」ということです。 ビジネスの観点には、製品が提供するフィーチャー、能力、体験に対して顧客がどのように反応するかを検証することが含まれます。言い換えれば 「我々は正しい製品を構築できたか？」です。 結果として、こうしたチームは、手戻りのリスクや無駄を減らし、市場で成功する可能性を高めることができます。 このような状態を達成できているとすれば素晴らしいことであり、もしこのブログをお読みの皆さんが既にこの状態にあるのだとすれば、それは良いことです。また、もし皆さんがこのような状態を達成しうる製品の開発に取り組んでいるのであれば、あまり心配することはないでしょう。なぜならば、このような状態を達成するためには、他の人の経験やケーススターディ、グッドプラクティス（成功例）などの様々な形のヒントが世の中にはありますので、それらのヒントを生かすことができるからです。 しかしながら、必ずしもすべての業界、ビジネスモデル、技術がこれを可能にするわけではありません。私が言っているのは、非生産的な社内ガバナンスや旧態依然とした開発・エンジニアリング慣行など、自ら課した制約や障害に苦しんでいる企業やチームのことではありません。早期かつ頻繁な本番リリースが不可能か、少なくとも法外なコストがかかる状況について話しているのです。全ユーザーによる製品の頻繁なテストができない状況は、ビジネス上、規制上またはコスト上のいずれかの要因により起こります。例えば、グーグル・ピクセルスマートフォンの次の開発、すべての患者が新薬にアクセスできるようにすること、あるいはロケットを宇宙に送ることなどが良い例だと思います。 しかし、もしあなたがそのような状況にあるとしても、「アジャイルである」ことは可能であり、前述した早期の仮説テストやリスク削減の恩恵をたくさん受けることができるので安心してください。ここからは、そのための2つの戦略と一部の戦術を紹介します。  戦略#1: できるだけ早い段階で製品を「リリース可能な状態」にし、実際にリリースしない場合でもその状態を維持すること  製品をリリースするビジネス上の必要性がない場合、ストレステスト、UAT（ユーザー受け入れテスト）、コンプライアンスサインオフ、文書化などを遅らせたくなります。結局これらはリリースするときにだけ必要なのですから、なぜ今やる必要があるのか？というところです。 しかし、この考え方の問題点は、時間の経過とともにリスクが蓄積していくことです。プロジェクトが終盤に差し掛かり、リリース日が近づくにつれ、あなたはリスクを最小にしたいと思うでしょう。しかし、最終的なストレステスト、UAT、コンプライアンス・サインオフを実施すると、最終的にさまざまな新しい問題が発見されます。ストレステストでアーキテクチャの大きな流れが明らかになり、多くの手戻りが発生するかもしれません。UATによって、製品フィーチャーの3分の1がほとんど誰にも使われていないことが判明し、開発チームはその代わりに別のものを作ることに時間を費やすべきだったことが明らかになるかもしれません。誰もが単なる形式的なものだと思っていたコンプライアンス・サインオフで、製品のリリースを遅らせるような悪い知らせがさまざま明らかになるかもしれません。 いわゆる「潜在的にリリース可能な」状態に製品を常に置くことで、そのようなリスクを排除することができます。スクラムでは、基本的に次のような方法でこの戦略を実行します。 1.        "完成の定義 "を公式化し、完成の定義に "潜在的にリリース可能な状態"を含めること。 2.        各スプリントで、この「完成の定義」を満たす製品のインクリメントを少なくとも一つ作成するようにします。 スプリントごとにストレステスト、ユーザー受け入れテスト、コンプライアンス検証を実施することは、コストがかかる戦略のように思えるかもしれません。しかし、それを試したほとんどのチームは、コスト以上のメリットがあることに気づきます。また、これらのコストは正しいアプローチを採用することで削減することができます。例えば、適切なチーム構造（クロスファンクショナル、権限委譲されたチーム）の設定や、適切なエンジニアリング技術やツール（テスト自動化、CI/CD、シミュレーターなど）への投資などです。 この1つ目の戦略は、以下の2つ目の戦略を実現するものでもあります。  戦略#2：市場への直接的かつ徹底的なアクセスを待たずに、プロダクトに関するフィードバックを積極的に収集すること  先に見たように、製品に関する仮説をテストする理想的な方法は、製品として広く市場に出荷することです。しかし、それができない場合でも、最終的に製品を発売またはリリースできるまで、仮説を過度に蓄積させるべきではありません。そのため、さまざまな情報源から洞察を得られるよう努力してください。これらの洞察は網羅的ではないかもしれませんし、収集するのは簡単ではないかもしれませんが、あなたの製品が目標を達成する可能性を最大化する上で非常に価値があります。 これらのインサイトを収集する3つの方法を紹介します： 1.…

Continue Reading年に1回しかリリースできなくても、アジャイルを導入できるのか？