2009年6月15日月曜日

3つのチェックシナリオ

About Face 3 読書ノートの14。


ノートの11~13でコンテキストシナリオ、キーパスシナリオを紹介しました。

About Face 3 のペルソナ/シナリオ法で使うシナリオには3種類ありまして、最後がチェックシナリオってことになります。

チェックシナリオは、前の2つみたいに凝って書くことはないんですね。
こういう場合はどうするの? こんなときはこうなるよ、みたいに端的な表現で箇条書きにしておく。

システムやアプリケーションには、けっしてメインストリームじゃないんけど、でも、絶対できなくちゃいけないことってのがあって。そういうのも忘れずにちゃんと考慮されたデザインになっているか、ワイヤーフレームを描き、インタラクションの細部を精緻化していくプロセスの中で、適宜、チェックシナリオを参照しながら確認していこうって、まあ、そういうことなんですね。

もし、コンテキストシナリオから機能要件を取り出してまとめるためにユースケース図を書いたとしたら、全部のユースケースをふたつに分けることになるでしょうね。

一方は、システムやアプリケーションの価値を形成する中心的なユースケース群。これらはワイヤーフレームを使って詳細化され、キーパスシナリオとして把握されていく。

他方は、あえてそれ以上は詳細化せずに、いわばチェックシナリオとして使っていく一群。

そう考えると、チェックシナリオっていうのは、書くのも、取り扱うのも、前の2つに比べてずいぶん気軽なような気がしてきますけれども、About Face 3 に挙げられている典型的なチェックシナリオの種類ってのをみると、それが早合点だったってことにすぐに気がつかされます。

いわく、チェックシナリオは、だいたい、次の3種類のどれかになると。


1. キーパスバリアントシナリオ

なんらかの条件の下で、あるいは付随的な要求に応じて、キーパスシナリオにつけ加えられたり、そこから分岐したりする操作に関するシナリオですね。

ブログだったら、書いてすぐ公開じゃなく、日時を指定して公開を予約するとか、かな。

ユースケース図で extend でつないで拡張ユースケースを書いたり、ユースケース記述で、代替シーケンスを明記したり、というのと同じことだと思います。


2. 必須パスシナリオ

システムやアプリケーションにユーザーが期待しているゴールの達成には直接関係ないけど、そのゴールを達成するためには必要となる動作設定とかコンフィグレーションとかですかね。

About Face 3的にいえば、「間接税的な操作」ってやつです。間接なんだけど、それは税。不本意でも必ず支払わなくてはならない。


3. エッジケースシナリオ

これこそ、まさに、"こういう場合どうすんの?"です。想定される異常事態とその対応方法のことですね。

アドレス帳で、新規作成ってことだったのに、既存のレコードと名前も電話番号もメールアドレスも一致してるのが登録された(前に入れたのを忘れちゃったのかな)場合、ほっといていいの?それとも黙って上書きしちゃう?それも乱暴だから、何かアラートでも出しとく?なんて。


で、ですね。

キーパスバリアントは、ユーザーの質的調査 → ペルソナまとめ → コンテキストシナリオ展開、ってな作業の中で見えてきているはずなんですよ。

ペルソナのいくつかあるゴールのうちでも優先順位の低いほうのものとか、脇役ペルソナのゴールとして。

でも、必須パス(間接税的な操作)ってのは、実装側からの要請という面が強いんじゃないかと思います。

インタラクションデザイン的には、できることなら省略したいくらいのものですからね。キーパスバリアントのように、インタラクションデザインのプロセスの中から自然に浮かび上がってくるということは、まずありえないでしょう。

それから、エッジケース。これ、経験上、思いつくのが得意な人と不得意な人がはっきり分れますよね。

いや、個人の資質もあるのかも知れないけど、職業的に訓練された思考パターンにも強く影響を受けそう。はっきり言うと、このへんの気づきは、プログラマーの人のほうが得意。でしょ?

というわけで、キーパスバリアントはともかく、後の2つは、プログラマーの人と一緒に考えたほうがいいと、ぼくは強く思います。

そうすると、これまでのエントリーでも触れてまいりましたとおり、インタラクションデザインと、プログラミングをウォーターフロー的につなげるのではなくてですね、やはり両方を含めて、小さく反復的に作業を進めていくべきなんじゃないかと、ここでも思います。

実装設計から、必須パスやエッジケースに関するフィードバックがかかって、インタラクションデザインも再考されていく、みたいなプロセス感。それによって、キーパスシナリオすら書き換えたほうがよくなるかも知れなくて。

ま、実際、現場ではそういうことをやっているような気もしますよ。

ただ、せっかくかかった実装側からのフィードバックに対して、その場でごにょごにょやって、解決した気になって盛り上がって、あっさり忘れちゃうのではなくて、それらをちゃんと「チェックシナリオ」として全体のプロセスや設計の中に位置づけて定着させていこうとすること、それが重要ですよね。

それはれっきとしたデザイン作業場の(中間)成果物なんであって。

それ以降に発生するインタラクションに関する仕様変更が、視野狭窄に陥って思ってもみないところで矛盾を生み出していたり、インタラクション全体のバランスを崩すことになっていたりしないか、とか、そういう危機を早期に発見するためのツールとしてもっと大事にしていく。

キーパスシナリオのところでも、その位置づけをちゃんと考えるっていうことで、なんか同じようなことを書きましたが、About Face 3 を読んで感銘を覚えることのひとつは、このへんですね。これまでなんとなく、ぼーっとやってきてしまっていた実践に、はっきりとした輪郭が与えられていくかんじ。

そんなわけで「チェックシナリオ」っていう言葉と考え方、これから積極的に使っていこうかなと、そう思った次第です。

2009年6月1日月曜日

キーパスシナリオの正体

About Face 3 読書ノートの13。

前のエントリーで見たとおり、コンテキストシナリオができたら、次にシナリオからデータ要件と機能要件を抽出します。

About Face 3 がそういっているわけではないけど、それはつまり、概念モデルとユースケースを書くってこと。まあ、そういうことにしておこう。

そしたら、アジャイルな開発プロセスをはじめられる。これも、About Face 3 がそういっているわけではないけどね。

毎回のイテレーションの冒頭では、今回のターゲットとなる開発範囲に含まれるユースケースについて詳細化を行うことになるでしょう。

ユースケースの詳細化っていうと、細かくユースケース記述を書くってのもあるけど、たいがいは、ワイヤーフレームを作成してみることになりますね。少なくともぼくがいる現場ではそうすることが多いです。

ここのところを、About Face 3 的に言い換えれば、つまり、フォームファクタ、ポスチュア、入力メソッドなんかをどんどん決めて、実際のインタラクションを描いていく、すなわち、キーパスシナリオを書く、ということになるみたいです。

About Face 3では、キーパスシナリオのことを次のように説明しています。

キーパスシナリオは、インタラクションフレームワークの語彙を使って、ペルソナが製品とどのようにインタラクションするかを記述する。このシナリオは、ペルソナがもっともひんぱんに通過する(毎日という場合も多い)インターフェースの主要経路を説明する。

(中略)

コンテキストシナリオはゴールオリエントだが、これと比べ、キーパスシナリオは作業寄りであり、コンテキストシナリオでは広くヒント程度に描かれていた作業のディテールに重点を置く。

(中略)

キーパスシナリオは、主要なインタラクションの正確な振る舞いを詳しく記述し、主要な操作経路を最初から最後までたどってみなければならない。


なるほど。でも、そうすると、コンテキストシナリオとユースケースは明らかに違うもんだっていうのはわかったんだけど、キーパスシナリオっていうのはなんだか、それこそユースケース記述みたいだな、なんて思っちゃったり。

でも、よく考えてみると、やっぱり違うもんだと捉えたほうがよさそうです。

ある目的にそった「行為」とは、目的を達成するために組み立てられたな複数の「作業」からなっていて、各「作業」はまた、一連の「操作」によって構成されている、としますね。

たとえば、

行為作業操作
自動販売機で缶ジュースを買う
自動販売機にお金を入れる硬貨投入口に10、50、100、500円を一枚ずつ差し込む
缶ジュースを選ぶディスプレイされた缶ジュースの中から、飲みたいものを選び、当該の缶ジュースに対応するボタンを押す
缶ジュースを受け取るジュースの取り出し口に放出された缶ジュースを取り出す
おつりを受け取るおつり返却レバーを回転させ、おつり返却口に放出された硬貨を取り出す

こんなかんじ。

これでいうと、作業レベルの記述がユースケース。で、操作レベルの記述がキーパスシナリオってことになるんですよね。キーパスシナリオの内容は、インターフェースの実装に依存した書き方になる。

ユースケースとは機能要件の網羅であって、そのひとつひとつを実現できたかどうかが、開発の進捗を測る上での中心的な指標になるんですよね。

だから、プロジェクトの最後まで、常に最新の設計が反映された状態を維持しておきたいんです。

ユースケース記述で操作の詳細にまで書く踏み込んで書くと、その後のデザイン/実装での変更を逐一反映させていかなければならないハメになっちゃう。でも、そんなこと実際にはやってられないわけで。

だから、ユースケースは作業レベルの記述に止めておくのが吉。

でも、これだけじゃ、具体的にどんなインタラクションを作っていいのかわからない。
ユースケースに機能要件の網羅という役割を期待するんなら、インタラクショデザインの道しるべとしての役割のほうは期待できない。

ってわけで、そっちは、キーパスシナリオに任せる。

キーパスシナリオはインタラクションデザインの試行錯誤の中で何度も書き直されるし、作業プロセスの過程で十分にデザインと実装が進めば、途中で捨てちゃっても構わない。いってみればいつも書き捨てるつもりで軽く書く。

このへんの話、思い切ってまとめると、こんなかんじでしょうか。


→ コンテキストシナリオは、ユーザーのニーズとゴールを見失わないために常に参照されるドキュメント。

→ ユースケースは、システムの全体像と整合性を見失わないために常に参照されるドキュメント。

→ キーパスシナリオは、具体的なシステムの姿を描き出すためのツール。


じゃあ、そのキーパスシナリオ、具体的にはどう書くの?って話になるんですが、About Face 3 によれば、コンテキストシナリオは(データと機能の要件を抜き出すためのヒントが書き込まれやすい)テキストで書くべし、とはっきり書かれていて、前に紹介したようにサンプルまでついて、手取り足取りってかんじなんですが、キーパスシナリオの書き方についてはそこまで詳しく書いてなくて。

ただ、映画におけるストーリーボードテクニックが参考になる、なんてことは書いてあります。

ストーリーボードって、インタラクションデザインの場合でいえば、つまりインタラクションを説明する一連のワイヤーフレームってことになりますね。
引き出し線をひっぱって操作を説明するテキストを添えて、それを順番に読んでもらえれば、それこそ、キーパスシナリオそのものってわけで。

というわけで、思わせぶりなタイトルをつけちゃいましたが、まあ、言いたいことは、キーパスシナリオ = とりあえずワイヤーフレームでOK?ってことです。

ただ、肝心なのは、形式はどうあれ、当の作業を次のようなプロセスの中にちゃんと位置づけて、これは "キーパスシナリオ" なんだと意識して行うってことですよね。


ユーザーの質的調査

ペルソナ + コンテキストシナリオ

ユースケース + 概念モデル

キーパスシナリオ / ワイヤーフレーム

(チェックシナリオ等、その他のシナリオ)

インタラクションデザイン + システム実装


こういうプロセス観の下で作業しないと、何の当てもないのにいきなりワイヤーフレームから書き始めるとか、まるでエスパーの仕事になってしまう。

あるいは、本来の役割を弁えていないもんだから、妙に表層的なビジュアルデザインに踏み込んじゃったり、コンテキストに関する説明のために膨大なコメントを書き込んじゃったりして、それ自体を分析することが一仕事になっちゃったりして。

そう、だから、何を隠そう「ワイヤーフレームの正体」こそ、実はキーパスシナリオだったのです。

あ、タイトル逆だったかな。