What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?

—Eric Ries

リーンUX

リーンユーザーエクスペリエンス（リーンUX）は、理想的なデザインを追求するのではなく、反復的な学習、全体的なユーザーエクスペリエンス、そして顧客の成果に焦点を当てることで、より良いプロダクトを構築するためのチームベースのアプローチです。

リーンUXデザインは、従来のUXの役割を、単にデザイン要素を実行し、ユーザーがシステムとどのように交流するかを予測すること以上へと拡大します。その代わりに、フィーチャーが存在する理由、それを実装するために必要な機能性、そしてそれが提供するベネフィットについて、はるかに包括的な視点を奨励します。システムが基本的なビジネス目標を満たすかどうかを理解するための即時フィードバックを得ることで、リーンUXはバリューを定義し測定するための閉ループ方法を提供します。

詳細

一般的にUXは、使いやすさ、有用性、そしてユーザーインターフェース（UI）の効果性といった、システムに対するユーザーの認識を表しています。 UXデザインは、エンドユーザーの深い理解を示すシステムを構築することに焦点を当て、ユーザーのニーズと要望を検討しながら、ユーザーのコンテキストと制限を考慮に入れます。

アジャイル手法を使用する際の一般的な問題は、UXデザインを迅速なイテレーションサイクルにどのように最適に組み込むかであり、結果として新機能のフルスタック実装が実現されます。チームが、複雑で主観的に見えるユーザーのインタラクションを解決しようとしながら同時にインクリメンタルな成果物を開発しようとすると、多くのデザインを繰り返し作成することが多く、アジャイルに対するフラストレーションを生むことがよくあります。

幸いなことに、リーンUXへの移行により、リーンスタートアップの実装アプローチを用いたアジャイル開発を使用してこの問題を解決します。この考え方は、SAFeのマインドセット、原則、そしてプラクティスに反映されています。このプロセスは、エピックの記事で説明されているSAFeリーンスタートアップサイクルから始まり、ここで説明されているリーンUXプロセスを使用して、フィーチャーとケイパビリティの開発を続けます。

その結果、アジャイルチームとアジャイルリリーストレイン（ART）は、迅速な開発、素早いフィードバック、そしてユーザーを満足させる総合的なユーザーエクスペリエンスを生み出すための共通の戦略を活用することができます。

リーンUXプロセス

ゴーセルフとセイデンによる『Lean UX』[2] では、図1が示すように、SAFeに適応させたモデルを説明しています。

図1 リーンUXプロセス（参考文献[2]からの改変）

ベネフィット仮説

リーンUXのアプローチは、ベネフィット仮説から始まります。アジャイルチームとUXデザイナーは、正しい答えは前もって知ることができないと認識しています。チームはビッグデザインアップフロント（BDUF）を避けるためにアジャイル方法を適用し、フィーチャーの期待されるビジネスの成果についての仮説を作成することに焦点を当てます。そして、その仮説をインクリメンタルに実装し、テストします。

SAFeのフィーチャーとベネフィットマトリクス（FAB）は、仮説がCDPの継続的な探索の側面を通過する際に説明するために使用できます。

フィーチャー - 名前とコンテキストを示す短いフレーズ
ベネフィット仮説 - エンドユーザーまたはビジネスに対する提案された測定可能なベネフィット

注: デザイン思考のプラクティスは、フィーチャーのベネフィット仮説の要素の順序を変更して、まず顧客のベネフィットを特定し、その後どのフィーチャーが顧客のニーズを満たすかを決定することを提案しています。

成果はCDPのリリースオンデマンド側面で測定されます。新しいフィーチャーがそのベネフィットの仮説をどれだけ満たしているかを評価するために、先行指標を使用して測定するのが最善です（[1]のイノベーション会計を参照）。例えば、「私たちは管理者が以前の半分の時間で新しいユーザーを追加できると信じています。」

共同設計

従来、UXデザインは高度な専門領域となってきました。デザインの才能やユーザー操作のセンスがあり、専門のトレーニングを受けた人々が、しばしばデザインプロセスを完全に担当しています。その目標は、「ピクセルパーフェクト」の初期デザインで、実装前に行われました。しかし、この仕事はしばしばサイロ内で専門家によって行われ、システムとそのコンテキストについて最も良く知っているかどうかは不明でした。成功は、実装されたユーザーインターフェースが初期のUXデザインにどれだけ準拠しているかで測定されました。しかし、リーンUXでは、これが劇的に変わります。

「Lean UX has no time for heroes. The entire concept of design as a hypothesis immediately dethrones notions of heroism; as a designer, you must expect that many of your ideas will fail in testing. Heroes don’t admit failure. But Lean UX designers embrace it as part of the process.　（リーンUXはヒーローに時間を割く余裕がありません。デザインの全体的な概念が仮説としてすぐに英雄主義の概念を廃止します。デザイナーとして、あなたの多くのアイデアがテストで不合格になることを予想しなければなりません。ヒーローは失敗を認めない。しかし、リーンUXデザイナーはそれをプロセスの一部として受け入れます。）」 [2]

継続的な探索は、仮説を取り上げ、アーキテクト、顧客、ビジネスオーナー、プロダクトオーナー、そしてアジャイルチームといった多様なステークホルダーからのインプットを求める継続的で協力的なプロセスを促進します。このグループは問題をさらに洗練し、ペルソナ、共感マップ、顧客体験マップを含む、新たな理解を明確に表現するアーティファクトを作成します（デザイン思考を参照）。

アジャイルチームは、協調的なUXを設計し、実装する権限を与えられており、ビジネスの成果と市場投入までの期間を大幅に改善します。さらに、別の重要な目標は、さまざまなシステム要素やチャンネル（例えば、モバイル、ウェブ、キオスク）や、同じ会社の異なるプロダクト間で一貫したユーザーエクスペリエンスを提供することです。この一貫性を可能にするためには、分散制御と再利用可能なデザイン資産の集中化（原則＃9 - 意思決定を分散する）のバランスを取る必要があります。例えば、ARTやバリューストリームが役立つと判断したUI要素を含む標準のセットを持つ次のようなデザインシステム[2]を作成することが含まれます。

編集ルール、スタイルガイド、ボイスとトーンのガイドライン、命名規則、標準用語、および略語
ブランディングと企業アイデンティティキット、カラーパレット、著作権、ロゴ、商標、およびその他の帰属に関する使用ガイドライン
アイコンやその他の画像、テンプレート、標準的なレイアウト、グリッドを含んだUIアセットライブラリ
ボタンのデザインや他の類似の要素を含むUIウィジェット

これらの集中化された資産は、分散制御を支えつつ、一部の設計要素が集中化されなければならないことを認識するアーキテクチャランウェイに不可欠です。結局のところ、これらの決定は「まれ」で、「長期的な」影響を及ぼし、ユーザーベースと企業アプリケーションの両方にわたって「大規模な規模の経済」を提供します。これは原則＃9で説明されています。

市場に出せる最小限のフィーチャー（MMF）の構築

仮説とデザインがあれば、チームは機能を市場に出せる最小限のフィーチャー（MMF）として実装することができます。 MMFは、顧客が何らかのバリューを認識し、チームがベネフィット仮説が有効かどうかを学ぶために提供しなければならない最小限の機能であるべきです。

MMFを作成することで、ARTはSAFe原則＃4 - 迅速で統合された学習サイクルでインクリメンタルに構築する、を適用します。チームは、初期のMMFを定義する際に、セットベースデザインを用いて選択肢を保持することができます。

多くの場合、極めて軽量で機能しないデザインでもユーザー要件を検証するのに役立ちます（例えば、紙のプロトタイプ、低忠実度のモックアップ、シミュレーション、APIスタブなど）。他の場合では、MMFの一部だけの垂直スレッド（フルスタック）が、アーキテクチャをテストし、システムデモで迅速なフィードバックを得るために必要となるかもしれません。しかし、一部の場合では、機能はデプロイメントとリリースに進む必要があり、アプリケーションの計装と遠隔測定が本番環境ユーザーからのフィードバックデータを提供します。

評価

MMFは、デプロイやリリース（必要な場合）の一部として評価されます。そのフィーチャーが適切な成果を提供するかどうかを判断するための様々な方法があります。これには以下が含まれます。

観察 - 可能な限り、システムの実際の使用を直接観察します。それは、ユーザーのコンテキストと行動を理解する機会です。
ユーザーサーベイ - シンプルなエンドユーザーのアンケートは、直接の観察が不可能な場合に迅速なフィードバックを得ることができます。
使用分析 - リーンアジャイルチームは、アプリケーションに分析を構築し、初期使用を検証し、継続的デリバリーモデルをサポートするために必要なアプリケーションの遠隔測定を提供します。アプリケーションの遠隔測定は、デプロイされたシステムからの常時の運用とユーザーフィードバックを提供します。
A/Bテスト - これは、ユーザーの好みが事前には知り得ないことを認識した上で、2つのサンプルを比較する統計的な仮説の形態です。これを認識することにより、おそらくシステムを使用することのないデザイナーと開発者の間の終わりのない議論を排除します。チームは、可能な限り長くデザインの選択肢を保持するために、原則＃3 - バラツキを前提とする。複数の選択肢を持ち続けるを遵守します。また、実用的で経済的に可能な限り、重要なユーザーアクティビティに対して複数の代替案を実装するべきです。それから、他の選択肢をモックアップ、プロトタイプ、またはフルスタックの実装でテストすることができます。この後者のケースでは、異なるバージョンがユーザーの複数のサブセットにデプロイされるかもしれません。これは時間をかけて順序を決めて行われ、分析を通じて測定されるかもしれません。

要するに、測定可能な結果は、チームがリファクタリングする、調整する、再設計する、または客観的なデータとユーザーフィードバックに基づいてフィーチャーを完全に放棄するための方針転換をするために必要な知識を提供します。測定は、特定のフィーチャーが仮説を満たすかどうかの証拠によって推進され、成功する結果に向けてイテレーションを行う閉ループのリーンUXプロセスを作り出します。

SAFeでリーンUXを実装する

リーンUXは、ユーザーエクスペリエンスデザインに対する従来の中央集権的なアプローチとは異なります。主な違いは、コードを実装し、適用可能な場所で計装し、ステージングまたは本番環境でユーザーフィードバックを得ることにより、仮説主導の側面がどのように評価されるかです。新しいデザインを実装することは主にアジャイルチームの責任であり、リーンUXの専門家と連携して行います。

もちろん、この変化はリーンアジャイル開発と同様に、チームや機能の組織化の方法に大きな変化をもたらし、継続的なバリューフローを可能にすることができます。リーンUXの調整と実装についての詳細情報、特にPIサイクルにリーンUXを統合する方法については、上級者向けトピックの記事リーンUXとPIライフサイクルをご覧ください。

詳しく学ぶ

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

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

[3] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

最終更新: 2023年2月21日