Product Canvas（プロダクト・キャンバス）−AgileUXを更に加速させる強力なツール

昨今、より優れたユーザーエクスペリエンスを実現すべく「Business Model Canvas（ビジネスモデル・キャンバス）」に代表されるなんちゃらキャンバスが次々と登場しています。一度ブログにまとめましたが、これだけの数がいま世の中に存在しています（呼び名はさておき）。

ビジネスモデル・キャンバス
リーン・キャンバス
カスタマー・エクスペリエンス・マップ／キャンバス
サービス・ブループリント・キャンバス
カンバン・キャンバス

大半は対ビジネスという関係において顧客思考を形式知化するツールがメインですが、一方で対デベロップメントという関係においては「Product Canvas（プロダクト・キャンバス）」が新たに活躍しそうなのでご紹介します。

The Product Canvas brings together the key pieces of information necessary to create a new product: the users and customers with their needs, the product’s functionality and design, and the user interaction. It’s intended to be a collaborative tool that helps you state your ideas and assumptions, test them, and integrate the insights you gain.

実は、この開発者はビジネスモデル・キャンバスを参考に作成されたそうです。ビジネス・モデルとエンドユーザのリレーションやリーチを可視化し、正しい問題解決を促すことはできますが「では、どうやって？」の部分にポッカリ穴が空いてしまっていることに違和感を覚えます。

実際にビジネスモデル・キャンバスは「要件定義」を目的に作られたわけではありませんので当たり前なのですが、「要件定義は」ビジネスサイドの人間とデベロッパー、そしてデザイナーの三者の意見を束ねる必要がある、最も重要な作業です。

そのような背景から、ビジネスモデル・キャンバスと併用することを開発者は推奨しています。項目をご覧になっていただいてお分かりになったかと思いますが、アジャイル開発につなげるための HCD なエッセンスがこのプロダクト・キャンバスには含まれています。

Vision（ビジョン）
ビジョン・ステートメントでは対象の商品やサービスの背景にある意図や動機を述べます。短く、簡単な文章にまとめましょう。
Product Name（商品名またはサービス名）
対象の商品名またはサービス名を記載します。
Personas（ペルソナ）
ターゲットとする顧客セグメントを代表する、問題解決を促すユーザを説明します。このエリアでは「誰が」「なぜ」対象の商品またはサービスを使いたいと思うのかを説明しなければなりません。
Journeys（フローやシナリオ）
ペルソナと商品またはサービスの複合的なインタラクションを記載します。ダイアグラムやストーリーボード、ストーリー・マップなどのイラストを描いても構いません。
Epics（ストーリー）
対象の商品またはサービスの主要な機能をスケッチするためのハイレベルなストーリーのことを指します。ペルソナの名前を物語の一部に含めることで、問題が解決されるか否かを検証します：＜この機能＞を使うことで＜ペルソナの名前＞が抱える＜ニーズや課題＞を解決することができます。すべてのストーリーを記載するのではなく、ペルソナが抱えるニーズを満たせているか否かを検証できる本質的なストーリーのみを記載します。
Design Sketches（ワイヤーフレームやスケッチ）
デザインのアイディアを記載します。Epics（物語）同様、ペルソナにとってクリティカルとなるインターフェースやデザインのみにフォーカスします。ユーザからのフィードバックが得られ次第、アップデートしていくことを推奨します。
Constraints（制約）
パフォーマンスやオペレーション、アーキテクチャなどユーザーエクスペリエンスに影響のある制約が商品やサービスがある場合は記載します。データ通信やトランズアクション数など技術的品質の検証を確保するためでもあります。
Ready Stories（スプリントのためのストーリー）
上の Epics（ストーリー）をより小さくかつ詳細に記載し、番号を割り振ることで次のステージであるアジャイル開発に直結させます。結果としてスクラムを実施した場合のスプリントごとのゴールが達成されます。スプリントのためのストーリーは実現可能性・検証可能性を担保し、かつ LeanUX のコンセプトである Minimum Viable Product（最低限必要な機能）を定義できるレベルにまで落とさなければなりません。