Specifically, you can take the time to develop and bring to the table an outside-in, market-centric perspective that is so compelling and so well informed that it can counterbalance the inside-out company-centric orientation of last year’s operating plan.

—Geoffrey Moore, Escape Velocity

継続的な探索

継続的な探索(CE)は、継続的デリバリーパイプラインの側面のひとつであり、市場と顧客のニーズを継続的に探索し、ソリューションのビジョン、ロードマップ、一連のフィーチャーを定義することによってイノベーションを推進し、何を構築すべきかの認識を一致させるのを促進します。

継続的な探索(CE)は、継続的デリバリーパイプライン(CDP)を構成する4つの側面（継続的な統合(CI)、継続的なデプロイメント(CD)、リリースオンデマンド(RoD)も含まれる）の1つ目です（図1）。

図1 CDPのコンテキスト中の「継続的な探索」

CEの間中、新しいアイデアを生み出し、精緻化し、そのアイデアをARTバックログの中に優先順位付け済みのフィーチャーの一覧として準備します。CIプロセスが始まると、アジャイルチームは、PIプランニング中にプロダクトマネジメントによって優先順位付けされたフィーチャーを実装します。その後、CDサイクルではそれらのフィーチャーが本番環境に引き込まれ、検証され、リリースする準備が整えられます。

詳細

アジャイルプロダクトデリバリーは、SAFeの7つのコアコンピテンシーのひとつです。このコンピテンシーによって、企業は、最適な頻度で、ますます価値が高まるソリューションをエンドユーザーにデリバリーできるようになります。CEは、アジャイルプロダクトデリバリーのプロセスに不可欠です。そして新しい開発の機会を理解し、ベクトルを揃えるために顧客中心の考え方とデザイン思考の適用に焦点を当てます。ところが一方、そのようなアイデアはすべて、検証が必要な「仮説」であることを認識しています。

CEは、従来のウォーターフォール型の前もって行う厳格な要件定義を、ARTバックログの中で実装の準備が整ったフィーチャーを一貫したフローで生み出すプロセスに置き換えます。フィーチャーをストーリーの小さなバッチに分解することにより、CDPの残りの側面を通じて、仕事を迅速に顧客へと進めることができます。迅速なフィードバックの取得がプロセスに組み込まれているため、チームは市場のニーズに合わせて調整することができます。途切れることなくバリューをフローさせることについての詳細は、ARTフローの記事を参照してください（原則#6 - 途切れることのないバリューを実現する）。

このプロセスには、顧客、サプライヤー、パートナー、ビジネスオーナー、アジャイルチーム、プロダクトオーナー、リーンポートフォリオマネジメントなどの内外のステークホルダーが関与します。これらの関与は、市場ニーズに関するセカンダリーリサーチなどを通じて間接的に行われる場合があります。あるいはアジャイルチームがイノベーション＆プランニングイテレーションに参加するときのように直接的な場合もあります。CEのアクティビティにより、組織は共有されたビジョン、実装のために定義されたバックログ中の一連のフィーチャー、予測されたロードマップにベクトルを揃えることができます。

継続的な探索の4つのアクティビティ

図2は、以下のセクションで記述されている継続的な探索の4つのステップを示しています。

図2 継続的な探索の4つのアクティビティ

仮説作成

仮説作成では、アイデアを生み出すためのプラクティスと、そのアイデアを顧客と一緒に検証するために必要な測定について記述します。その主な目的はチームがCDPを通じて検証するソリューション仮説を定義することです。

プロダクトマネジメントは、市場、戦略テーマ、ポートフォリオビジョン、ロードマップに関する理解に基づいた顧客ニーズについての考えを持っています。ただし、これらの考えを事実とみなすべきではありません。代わりにチームはそれらの考えをテストして証明する必要がある「仮説」とみなすべきです。したがって、仮説駆動開発に関連するプラクティスには以下のものが含まれています。

リーンスタートアップ思考 - 市場に出せる最小限のフィーチャー(MMF)と実用最小限のプロダクト(MVP) [1] を定義すると、最小限の投資で仮説を迅速に評価するのに役立ちます。MMFとMVPは、将来のプロダクト開発にフィードバックを提供できる初期の顧客にとって使用可能な最小限の機能を表します。
イノベーション会計 - 新しいプロダクトや新しいフィーチャーの仮説を評価するには、既存のソリューションを測定するのとは異なるアプローチが必要です。それには2つの質問を検討する必要があります。「成果につながる仮説に向かって前進しているのか」、「どうやって知るのか」の2つです。イノベーション会計では、早期の結果を判断するために実用的な指標（先行指標）を使用し、将来のビジネス成果を予測するのに適しています。先行指標は、これらの2つの質問に答え、MMF や MVPの初期のソリューション開発と評価中に経済的な意思決定を改善します。

コラボレーションとリサーチ

魅力的で差別化されたビジョンを作成するには、図3に示すように、プロダクトマネジメントはさまざまなステークホルダーの意見を求めながら、継続的かつ協調的なプロセスを促進する必要があります。

図3 プロダクトマネジメントは複数のステークホルダーと一緒に協力して要求を精緻化する

システムアーキテクト - システムアーキテクトは、ソリューションに関する技術的な深いナレッジを持っています。システムアーキテクトらは、システムレベルのソリューション、ユースケース、非機能要件(NFR)を理解する責任があります。これらの役割を技術的かつ社内的ものと考えるのは自然なことですが、アーキテクトはまた、満たされていないニーズを解決するための新たな方法を特定できるように、重要かつ継続的な顧客との関わりを持つべきです。
顧客 - 行動で意思を示すことで、顧客はバリューを判断します。したがって、ソリューションに関するフィードバックや、それがニーズをどの程度満たしているかについての主要な情報源は顧客です。ただし注意が必要です。顧客の動機は現在のソリューションのコンテキストに大きく結びついていることが多く、段階的に改善することしか考えていないことがよくあります。言い換えれば、顧客からのフィードバックだけではプロダクト戦略は成り立ちません。しかし、現在の顧客ニーズや変化する顧客ニーズを満たせなければ、確実に失敗に終わります。
ビジネスオーナーとステークホルダー - ビジネスオーナーには、ミッションとビジョンを設定するために必要なビジネスと市場の知識があります。BOらの期待に応えられないソリューションにはバリューがない可能性があります。
POとチーム - プロダクトオーナーとアジャイルチームは、ソリューションを創り出す仕事を通じてドメインの専門知識を生み出します。多くの場合、それらは技術的な関心事とユーザーの関心事の両方に最も近いものです。POやチームの意見は、ソリューションの継続的な進化に不可欠です。

コラボレーションとリサーチは具体的なプラクティスに根ざしています。

一次市場調査 - プロダクトマネジメントは、顧客理解のためのサーベイ、フォーカスグループ、アンケート、競合分析などの一次市場調査を通じて、さらなる洞察を得ます。
顧客訪問と現場視察 - 現場視察[2]や顧客訪問は、プロダクトチームがステークホルダーのオペレーショナルバリューストリームの中で行う特定の活動を観察し、たゆまぬ改善の機会を特定するプロセスです。仕事をしている人々の日々の活動を直接観察することに代わるものはありません。構造化されているか非公式であるかに関わらず、プロダクトマネージャーとプロダクトオーナーは、人々が職場環境でシステムをどのように利用しているかを理解する必要があります。自分の机でそれを行うことはできないため、「建物の外に出ること」、顧客を訪問すること、特定のソリューションコンテキストの中でユーザーを観察することに取って代わるものはありません。
二次市場調査 - 自分たちの考え方を広げるために、プロダクトマネジメントは、さまざまな二次市場調査のテクニックを利用して、自分たちがサービスを提供している顧客と市場を包括的に理解します。市場や業界のトレンドを常に把握しておくことは、市場調査の重要な成果です。
リーンUX思考 - リーンUX [3]は、市場に出せる最小限のフィーチャー(MMF)を定義し、それを顧客とともに迅速に検証するために、ステークホルダーと一緒に取り組む協働プロセスです。

コラボレーションとリサーチにより、組織はそのプロセスをさらに精緻化し、問題領域に対する新たな理解を明確に表現するアーティファクトを作成することが可能になります。これには以下のことが含まれます。

デザインに焦点を当てたペルソナ作成 - リサーチに基づくペルソナは組織がターゲットとする顧客を理解するのに役立ちます。
ユーザーに対する共感の構築 - 共感マップは、チームがユーザーのニーズを考慮し、それが継続的なリリースを通じて、どのように進化するかを確実に考慮できるようにします。
顧客体験のデザイン - 顧客ジャーニーマップは、オペレーショナルバリューストリームと顧客のユーザー体験との間をつなぐデザインをもたらします。

これらのアーティファクトは、継続的なリリースにわたって比較的安定している傾向があります。ところが一方、企業は陳腐化した洞察に基づいて戦略を決定することを避けなければなりません。

アーキテクト

問題を明確に理解した上で、CEはソリューション領域に移り、最小限のアーキテクチャを定義します。アーキテクチャはソリューションをサポートし、継続的デリバリーを可能にしてくれます。

アーキテクチャランウェイが必要とされる機能をデリバリーするのに十分であり、継続的デリバリーパイプライン(CDP)を有効にするようデザインされていることを確実にすることによって、アーキテクトはビジネスと顧客に貢献します。システムアーキテクトは、以下の5つのプラクティスを通じてCDPをサポートします。

リリース可能性を考慮したアーキテクチャ - ソリューションのさまざまなパーツは、異なるリリース戦略を必要とします。そのため、さまざまなインクリメンタルなリリース戦略を可能にし、ビジネスの需要に基づいて時間をかけて進化させるソリューションをデザインします。
テスト可能性を考慮したアーキテクチャ - モジュール方式で設計・構築されたシステムにより、継続的なテストを可能にします。
デプロイメントとリリースの分離 - 継続的にデプロイするケイパビリティには、機能を本番環境に移行しても、顧客からは隠せるようにするアーキテクチャイネーブラーが必要です。
運用を考慮したアーキテクチャ - 運用サポートのニーズを満たすために、すべてのアプリケーションとソリューションに遠隔測定とロギング機能を組み込みます。高負荷時やインシデント発生時にサービスをダウングレードしたり、停止したりできるようにします。迅速なリカバリーとフィックスフォワードのための機能を構築します。
脅威モデリング - 提案されているアーキテクチャ、インフラストラクチャ、アプリケーションに対する脅威を特定しながら、情報セキュリティの検討は早い段階から始めるべきです。重要なセキュリティ要件を非機能要件として把握し、バックログに影響を与えます。

合成

合成では、得られた知識を蒸留してソリューションの新しい将来の状態にします。ビジョン、ロードマップ、優先順位付け済みのフィーチャーのバックログは、ARTの各チームのベクトルを共通の方向に揃えてくれます。これらの資産がPIプランニングの準備を行う際、合成に焦点を当てます。これを達成するには、以下のプラクティスが必要です。

ソリューションビジョンの作成 - ビジョンは、新しいフィーチャーを開発する理由や目的を提供します。
ソリューションロードマップの維持 - ARTロードマップは、プロダクトマネジメントが仕事の優先順位を決めるのに役立ち、システムアーキテクトがアーキテクチャの優先順位を付けられるようにし、ビジネスオーナーに可視性を提供しながら、近い将来への展望をもたらします。
明確に記述された項目を伴ったバックログの定義 - PIに適合するフィーチャーを定義することは、ARTが必要とされていることにベクトルを合わせ、チームが計画を立てるために重要です。バックログには、重要なセキュリティ要件も反映されます。
ビヘイビア駆動開発(BDD) - プロダクトマネジメント、プロダクトオーナー、アジャイルチーム間のコラボレーションを促進し、受け入れ基準を追加することで要件を明確にします。
経済的な優先順位付け - 優先順位付けされたフィーチャーは効果的な開発を可能にします。優先順位付けには、キャパシティ配分、投資ホライゾン、継続的なビジネスオーナーのエンゲージメントからなる予算ガードレールが重要です。
PIプランニング - ARTによって行われる探索の仕事は、次のPIプランニングイベントへの不可欠なインプットであり、ベクトルを揃えるのに役立ちます。

構築すべきもののベクトルが揃っている場合、フィーチャーはスムーズにCDPのCIセグメントへと流れていきます。しかし、探索が終わったことを意味するわけではありません。デプロイされ、リリースされたフィーチャーからのフィードバックが絶えず戻ってきます。このフィードバックは、ARTが次に何に取り組むべきかについての決定に影響を与え、CEプロセスにとって欠かせないものです。

DevOpsで継続的な探索を可能にする

継続的な探索のアクティビティは、CDP全体のペースを決めます。大規模なバッチ、厳密な仕様、固定された計画へのコミットメントを伴う場合、実行には時間がかかります。それ故、ARTが継続的デリバリーを達成するためには、「上流」のアクティビティは、スピード重視と検証済みの学習によって推進されるべきです。バリューストリームの早い段階で、DevOpsのマインドセット、プラクティス、ツールを適用することにより、すべてのSAFe原則を強化し、ART全体のベクトルをDevOpsのマインドセットに揃え、CDPを準備します。

多くのDevOps関連のコンセプトがこのレベルに適用されます。図4は、DevOps （中央）に向けた SAFeのCALMRアプローチと、CEをサポートするプラクティスのドメイン（内側のリング）を示しています。4つの各アクティビティ（緑色）は、デリバリーの速さと品質を最大化するために、複数の分野のDevOpsの専門知識を活用した協調的な取り組みです。

図4 DevOpsは継続的な探索を可能にする

例えば、継続的デリバリーのためのアーキテクチャ構築は一面的なアクティビティではありません。図4が示すように、いくつかの分野にまたがっています。アジャイルアーキテクチャは、望ましい品質とセキュリティレベルを考慮すること、バリューストリームのパフォーマンス目標にベクトルを揃えること、バージョン管理の下で実体のあるコンフィグレーションを作成すること、そしてバックログ項目とアジャイルプランニングと創発的なデザインをサポートする非機能要件を生み出すことが必要です。さらに、CALMRのマインドセットは、デリバリーの速さとソリューションの価値を最大化するために、すべてのアーキテクチャ上の決定と行動の指針とする必要があります。

4つのCEアクティビティはすべて、技術的なプラクティスとツールの組み合わせは異なるものの、DevOpsによって可能になります。

詳しく学ぶ

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc, 2011.

[2] Womack, Jim. Gemba Walks Expanded 2nd Edition. Lean Enterprise Institute, Inc, 2019.

[3] Gothelf, Jeff, and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media, 2016.

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series). Pearson Education, 2011.

最終更新： 2023年1月6日