前のエントリーで見たとおり、コンテキストシナリオができたら、次にシナリオからデータ要件と機能要件を抽出します。
About Face 3 がそういっているわけではないけど、それはつまり、概念モデルとユースケースを書くってこと。まあ、そういうことにしておこう。
そしたら、アジャイルな開発プロセスをはじめられる。これも、About Face 3 がそういっているわけではないけどね。
毎回のイテレーションの冒頭では、今回のターゲットとなる開発範囲に含まれるユースケースについて詳細化を行うことになるでしょう。
ユースケースの詳細化っていうと、細かくユースケース記述を書くってのもあるけど、たいがいは、ワイヤーフレームを作成してみることになりますね。少なくともぼくがいる現場ではそうすることが多いです。
ここのところを、About Face 3 的に言い換えれば、つまり、フォームファクタ、ポスチュア、入力メソッドなんかをどんどん決めて、実際のインタラクションを描いていく、すなわち、キーパスシナリオを書く、ということになるみたいです。
About Face 3では、キーパスシナリオのことを次のように説明しています。
キーパスシナリオは、インタラクションフレームワークの語彙を使って、ペルソナが製品とどのようにインタラクションするかを記述する。このシナリオは、ペルソナがもっともひんぱんに通過する（毎日という場合も多い）インターフェースの主要経路を説明する。
（中略）
コンテキストシナリオはゴールオリエントだが、これと比べ、キーパスシナリオは作業寄りであり、コンテキストシナリオでは広くヒント程度に描かれていた作業のディテールに重点を置く。
（中略）
キーパスシナリオは、主要なインタラクションの正確な振る舞いを詳しく記述し、主要な操作経路を最初から最後までたどってみなければならない。
なるほど。でも、そうすると、コンテキストシナリオとユースケースは明らかに違うもんだっていうのはわかったんだけど、キーパスシナリオっていうのはなんだか、それこそユースケース記述みたいだな、なんて思っちゃったり。
でも、よく考えてみると、やっぱり違うもんだと捉えたほうがよさそうです。
ある目的にそった「行為」とは、目的を達成するために組み立てられたな複数の「作業」からなっていて、各「作業」はまた、一連の「操作」によって構成されている、としますね。
たとえば、
| 行為 | 作業 | 操作 |
|---|---|---|
| 自動販売機で缶ジュースを買う | ||
| 自動販売機にお金を入れる | 硬貨投入口に10、50、100、500円を一枚ずつ差し込む | |
| 缶ジュースを選ぶ | ディスプレイされた缶ジュースの中から、飲みたいものを選び、当該の缶ジュースに対応するボタンを押す | |
| 缶ジュースを受け取る | ジュースの取り出し口に放出された缶ジュースを取り出す | |
| おつりを受け取る | おつり返却レバーを回転させ、おつり返却口に放出された硬貨を取り出す |
こんなかんじ。
これでいうと、作業レベルの記述がユースケース。で、操作レベルの記述がキーパスシナリオってことになるんですよね。キーパスシナリオの内容は、インターフェースの実装に依存した書き方になる。
ユースケースとは機能要件の網羅であって、そのひとつひとつを実現できたかどうかが、開発の進捗を測る上での中心的な指標になるんですよね。
だから、プロジェクトの最後まで、常に最新の設計が反映された状態を維持しておきたいんです。
ユースケース記述で操作の詳細にまで書く踏み込んで書くと、その後のデザイン/実装での変更を逐一反映させていかなければならないハメになっちゃう。でも、そんなこと実際にはやってられないわけで。
だから、ユースケースは作業レベルの記述に止めておくのが吉。
でも、これだけじゃ、具体的にどんなインタラクションを作っていいのかわからない。
ユースケースに機能要件の網羅という役割を期待するんなら、インタラクショデザインの道しるべとしての役割のほうは期待できない。
ってわけで、そっちは、キーパスシナリオに任せる。
キーパスシナリオはインタラクションデザインの試行錯誤の中で何度も書き直されるし、作業プロセスの過程で十分にデザインと実装が進めば、途中で捨てちゃっても構わない。いってみればいつも書き捨てるつもりで軽く書く。
このへんの話、思い切ってまとめると、こんなかんじでしょうか。
→ コンテキストシナリオは、ユーザーのニーズとゴールを見失わないために常に参照されるドキュメント。
→ ユースケースは、システムの全体像と整合性を見失わないために常に参照されるドキュメント。
→ キーパスシナリオは、具体的なシステムの姿を描き出すためのツール。
じゃあ、そのキーパスシナリオ、具体的にはどう書くの？って話になるんですが、About Face 3 によれば、コンテキストシナリオは（データと機能の要件を抜き出すためのヒントが書き込まれやすい）テキストで書くべし、とはっきり書かれていて、前に紹介したようにサンプルまでついて、手取り足取りってかんじなんですが、キーパスシナリオの書き方についてはそこまで詳しく書いてなくて。
ただ、映画におけるストーリーボードテクニックが参考になる、なんてことは書いてあります。
ストーリーボードって、インタラクションデザインの場合でいえば、つまりインタラクションを説明する一連のワイヤーフレームってことになりますね。
引き出し線をひっぱって操作を説明するテキストを添えて、それを順番に読んでもらえれば、それこそ、キーパスシナリオそのものってわけで。
というわけで、思わせぶりなタイトルをつけちゃいましたが、まあ、言いたいことは、キーパスシナリオ = とりあえずワイヤーフレームでOK？ってことです。
ただ、肝心なのは、形式はどうあれ、当の作業を次のようなプロセスの中にちゃんと位置づけて、これは "キーパスシナリオ" なんだと意識して行うってことですよね。
ユーザーの質的調査
↓
ペルソナ + コンテキストシナリオ
↓
ユースケース + 概念モデル
↓
キーパスシナリオ / ワイヤーフレーム
↓
(チェックシナリオ等、その他のシナリオ)
↓
インタラクションデザイン + システム実装
こういうプロセス観の下で作業しないと、何の当てもないのにいきなりワイヤーフレームから書き始めるとか、まるでエスパーの仕事になってしまう。
あるいは、本来の役割を弁えていないもんだから、妙に表層的なビジュアルデザインに踏み込んじゃったり、コンテキストに関する説明のために膨大なコメントを書き込んじゃったりして、それ自体を分析することが一仕事になっちゃったりして。
そう、だから、何を隠そう「ワイヤーフレームの正体」こそ、実はキーパスシナリオだったのです。
あ、タイトル逆だったかな。
0 件のコメント:
コメントを投稿