利用者の立場を考えたペルソナ/シナリオ法による開発とは[@IT勉強会]連動企画

「使いにくい」「分かりづらい」──エンドユーザーからそんな言葉を聞いたことのある開発者、システム担当者は少なくないだろう。近年、使いやすいソフトウェアを作るためのテクノロジやツールはそろってきた。しかし、それだけで使いやすさが実現できるわけではない。「使いやすさ」とは何か、アプレッソ副社長の小野和俊氏に聞いた。

» 2004年09月18日 12時00分 公開
[生井 俊,@IT]
ALT Speaker 株式会社アプレッソ代表取締役副社長 CTO 小野和俊氏【ユーザビリティ研究会】では、ペルソナ/シナリオ法による開発の具体例などを紹介していきます。ペルソナを使ったことで発見された画面デザイン上の問題点や機能重複などをいくつか紹介する予定です。

リッチクライアント技術の登場・進展により、ソフトウェア・ユーザーインターフェイスの表現自由度が非常に高まり、いろいろなものが作れるようになりました。

 ただ、いろいろなものが作成可能な道具が与えられたというのは、その道具を間違って使ってしまうことにも結び付き、それがこれからの課題だといえます。

 HTMLを用いたWebベースのソフトウェアでは、ごく限られたソフトウェア部品しかなく、結果的にシンプルな操作性が実現されていた。そのように表現の方法が限られていたものが、いま自由に表現できる時代になろうとしています。その自由な表現が可能だという状況の中で、どういうふうにデザインをしていくかということがあらためて注目されてきています。

操作デザインを裏側のデザインがかき乱す?

ソフトウェアのデザインは、大きく2つに分けられます。1つはユーザーが直接触る部分のデザインです。僕たちは操作デザインと呼んでいます。それともう1つは、その裏側のアーキテクチャやオブジェクトの設計をどうするか、といったプログラムデザインです。

 本来、ユーザーが直接触る部分のソフトウェアデザインと、裏側のアーキテクチャ──コンポーネントをどのようにするかといったソフトウェアデザインは別のものです。しかし、再利用性や拡張性など、プログラム的な「裏側」の事情が表に出ていることがあります。こうした部分はエンジニアから見ると、「これはすごく拡張しやすい形になっている!」などと結構感動したりするものですが、エンドユーザーから見たときには、必ずしも求められている機能ではありません。それがそのまま表に出てしまっていることで、使いづらさにつながっているケースが多くあります。

 ソフトウェアの表現の自由度が上がってきたことにより、使いやすいソフトと使いにくいソフトの差がより明確になってきています。ですから、ユーザーのレベルに合った使いやすいソフトにしていかなければならないのに、ソフトウェアを作る側の事情が表に出てきてしまうことが陥りやすい危険なポイントだと思っています。それを解消するために、弊社では開発にペルソナ/シナリオ法を採用することで、リスクを最小化しています。

主要ペルソナがハッピーになる開発方法

ALT rコンピュータは、むずかしすぎて使えない!アラン・クーパー著、山形浩生訳 翔泳社 2000年2月 ISBN4-88135-826-X 2200円+税

 ペルソナ/シナリオ法とは、『コンピュータは、むずかしすぎて使えない!』(アラン・クーパー著、山形浩生訳、翔泳社)で紹介されたやり方です。ペルソナとは、いわば架空ユーザーのことです。かなり細かいプロフィール──現在の業務内容や考え方、個人的にやりたいことなどを設定します。

 一口にソフトウェアを使うといっても、ソフトウェア製品上で何らかのスプリクトを書く人、そのソフトウェアを運用・管理する人、アプリケーションのエンドユーザーというように、複数のアクターがいるわけです。アクターごとの仕事を精査すると、共通する部分が出てくるため、抽象化していきます。その抽象化されたものが、開発で利用する“ペルソナ”なのです。

 ペルソナは通常、複数設定されます。例えば、弊社のDataSpiderのようなミドルウェア製品でいうと、スクリプトを設計するペルソナとそのスクリプトを使って実際にシステムを運用するペルソナというような形です。さらに細かく見ると、同じスクリプトを作る人にしても、プログラムを熟知している人やまだプログラムを始めたばかりの人などを用意します。同じ業務をしてもスキルセットや考え方が違ったりすることがあるからです。

 「このソフトウェアを使うのはこういう人が一番多いし、この人のために作るんだ」という人を1人絞り込みます。それを主要ペルソナと呼びます。製品を開発するときに、「この主要ペルソナがハッピーになるためには」と常に考えていくわけです。

 とにかく、エンジニア同士で仕様を決定しようとコミュニケーションすると、自分のスキルセットを前提にして話をしてしまうことが多いのです。例えばJavaのエンジニアは、Javaのエンジニアであれば知っていることを「誰でもみんな知ってるはず」と誤認識することがあります。ユーザーがそんなスキルセットを持っていないかもしれないのに、「だってそんなことを知らない人、世の中にいるわけないでしょう」といって話を済ませてしまう。そういうときに、ペルソナに代弁させるのです。

詳細なシナリオが適切な機能に結び付く

 われわれの事例でいうと、現在開発しているDataSpiderの次期バージョンでは、「神尾みか」さんという主要ペルソナを設定しました。ソフトウェアの仕様を決定していく際には、開発者は自分の主観ではなく、「いや、そんなのみかさんは分からないよ」というふうに、みかさんというペルソナが分かるかどうかで判断しています。

ALT アプレッソにおける“ペルソナ”の設定

 この主要ペルソナが、どういうステップで操作を行い、それを学習していくかを記述したものがシナリオです。最初に、ソフトウェアを使い始めた初日のシナリオを書きます。「まずパッケージを開け、インストールCDを見て、CDドライブのトレイに入れる」ところから始めて、「最初にインストーラのダイアログが出てきて、インストールのステップが表示されているのを見る。それで、[次へ]を押す」と、具体的に書いていきます。シナリオを細かく書き、それを1つずつ検証していくと「ここで[次へ]が押せなくなっていて、なぜ押せなくなったのかを神尾みかさんが気付かないのではないか」と洗い出していけるのです。

 ペルソナ/シナリオ法のメリットは、プログラムデザインによって操作デザインが左右されず、想定されるユーザーが必要とする機能だけが無駄なく付加されることです。また、ペルソナという代弁者がいることで、開発者同士のコミュニケーションにおいても、自然とユーザーの視点に立った発言の割合が増えてくることもメリットの1つです。

ソフトウェアの肥大化を防ぐ

 ソフトウェアの設計は、設計してから作る場合と、作りながら設計していく場合と2つに分かれます。

XP(エクストリーム・プログラミング)でテストファーストというのがありますが、これと同じような言い方をすると、ペルソナ/シナリオ法による開発は「シナリオファースト」と呼ぶことができます。最初にペルソナとシナリオを使って仕様をかなり細かいところまで固めて、それを基にしてソフトウェアの仕様を作っていくのです。仕様についてはイテレーションを行うことよりも最初に多くの部分を固めてしまうことを重視するため、ある意味では

ウォーターフォールに近い形になります。

 弊社の事例はミドルウェア開発ですが、業務アプリケーションを作る場合はペルソナ/シナリオ法の前に、上流工程が入るのではないでしょうか。上流工程を経て、ソフトウェアの画面デザインを行うフェイズでペルソナとシナリオを利用するわけですね。

 パッケージソフトのように1つのソフトウェアを中長期に渡ってメンテナンスしていく場合でも、必ずペルソナは誰なのかを意識し、新機能を追加する場合には、そのペルソナが使いやすいようにシナリオをきちんと組んで、そのうえで機能を取り入れるかどうか判断していきます。あるいは機能を新しく追加するのではなくて、機能を改良する場合もそうです。このときシナリオを通してやっていかないと、ユーザーにいわれた機能をどんどん付けて、どんどん意味の分からないシステムになってしまう恐れがあるのです。

 ここで述べた内容は抽象的でしたが、研究会ではペルソナ/シナリオ法による開発の具体例などを紹介していきます。実際に使っている主要ペルソナと各ペルソナ、そのシナリオをご覧に入れます。見ることで初めて分かる部分もあるでしょうし、取り入れるメリットとウイークポイントなどもイメージできると思います。

 リッチクライアント時代になり、その中で、たくさんの道具を使いこなすべくデザインの方向を模索しているような意識の人がたくさんいる場になると、きっと有意義な議論ができるのかなと思っています。(談)

profile

生井 俊(いくい しゅん)

1975年生まれ、東京都出身。同志社大学留学、早稲田大学第一文学部卒業。株式会社リコーを経て、現在、ライター兼高校教師として活動中。著書に『インターネット・マーケティング・ハンドブック』(同友館、共著)『万有縁力』(プレジデント社、共著)。


Copyright © ITmedia, Inc. All Rights Reserved.