HCII09: シナリオ法の定義

HCII09にて。

HCD-Netでオーガナイズドセッションを担当した「Persona and Scenario-based Design in Asia」にて、かねてから疑問だったらシナリオ法についての疑問が明確になった。

結論から言うと、シナリオ法とは「デザイン過程において、自然言語で記述するようなシナリオを用いること全般」を指す。

ペルソナ法といっしょに語られることが多い、シナリオ(シナリオ法)であるが、現場でシナリオを用いる場合、大きく二通りの用途があるのが気になっていた。

ケース1:シナリオを調査結果モデル化の表現に用いる場合

シナリオを調査結果の表現に用いる場合

シナリオを調査結果の表現に用いる場合

ケース2:シナリオをコンセプト(方針)の表現に用いる場合

シナリオをコンセプト(方針)の表現に用いる場合

シナリオをコンセプト(方針)の表現に用いる場合

わかりにくいが、前者はあくまでファクトベースのシナリオ、後者は問題を解決するためのソリューションととしてのシナリオ、ということができる。

どっちでも大差ないよ、という方も多いと思うが、書籍やら事例やらを見ているとどっちのケースも見受けられ、また、デザインプロジェクトにおいてシナリオ構築をタスクとして明示化する場合、どっちもシナリオは有効であるため、どう区別したらよいものかと思っていた。

ちなみにペルソナ法の総本山、Coope社のKim GoodwinによるDesigning for the Digital Ageでは、前者のシナリオを解説している。

で、セミナーなどで話す場合や、ケイパビリティプレゼンテーションとして説明する場合においては、一般的な意味での「シナリオ法」はこう定義されている、というがキチンと説明できなくて困っていた。

特に、プロジェクトとして提案する場合、どっちのシナリオ?ってのは明示化する必要がある。

コンセントとしては、プロジェクトにおいては基本的に後者のシナリオ、つまりソリューションの提案としてのシナリオを用いている。前者のモデル化では、あえてシナリオの形にまで起こさないことが多い。

ということで、日本でも毎月会っている郷先生にサンディエゴにてこの質問をぶつけてみた。

その結果は、この両者を区別するような言い方はなく、「シナリオ」と言った場合は、「デザイン過程においてシナリオを用いること」全体を指しているとのこと。

つまり、シナリオの持つ、「文脈の表現」という役割がシナリオ法の意義であり、モデル化、ビジョニング(ソリューション導出)という異なった目的の両方にシナリオ法が有効、というのが正解となる。

って、別に正解が知りたいわけではなかったが、「シナリオ法」とだけ言ったのでは、用途が特定できないことはわかった。

ペルソナ法という言い方が用途(モデル化)まで規定しているのに対して、シナリオ法が手法だけであって、用途は複数ある、というのが紛らわしさを招いていた、というのが僕が混乱していた理由であろう。

HCII09: シナリオ法の定義」への2件のフィードバック

  1. ueno

    うちでは「As-is シナリオ」「To-be シナリオ」といって両者を区別しています。現状分析の一環で As-is を作成し、その中の問題箇所を部分的に書き換えることで To-be を作り上げるという手法があったと思います。キャロルさんだったかコンスタンティンさんだったか。

  2. Atsushi 投稿作成者

    uenoさん、

    確かに、as-isとto-beですね。
    一般的にもそういう感じで区別されていそうですね。
    名前があるとすっきりします。

    Goodwinさんの本なんかだと、as-isのほうを、作り方から重点的に扱って、ビジョニング(to-beのほう)では、ストーリーボードという言い方をしたりしてました。
    as-isシナリオは、課題の共有が重要なプロジェクトで必要になってくるんでしょうね。

    > 現状分析の一環で As-is を作成し、その中の問題箇所を部分的に書き換えることで
    > To-be を作り上げるという手法があったと思います。

    これはわかりやすくてよいですね。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください