ペルソナとシナリオを用いたソフトウェア開発──実践編（前編）：ユーザビリティ研究会より（2）（1/2 ページ）

2004年11月19日（金）、＠ITセミナールームで行われた第2回 ユーザビリティ研究会は、ぐずついた雨模様の中、30名以上の参加があり熱い議論が続いた。内容はペルソナ／シナリオ法の実践編で、本レポートはその模様を前後編でお届けする。今回はレクチャー部分をまとめたもので、質疑応答については後編で紹介する予定だ

[生井，＠IT]

操作要件を補うペルソナ／シナリオ法

Speaker

株式会社アプレッソ 代表取締役副社長 CTO

小野和俊氏

慶應義塾大学湘南藤沢キャンパス（SFC）環境情報学部卒業後、サン・マイクロシステムズ株式会社にてJava、XML関連の技術を担当。2000年にはSun Microsystems,Inc（米国本社）にてサイジング自動化ツール「Tahoe」を開発。現在、株式会社アプレッソ代表取締役副社長CTOとしてデータ連携プラットフォーム「DataSpider」を開発。

　今回は、弊社製品DataSpiderの開発でペルソナ／シナリオ法がどのように使われたかを題材に解説していきます。DataSpiderは、いろいろな形式のデータをやり取りできるミドルウェアで、GUI操作を実現しています（※1）。

　まず、おさらいを兼ねて問題提起します。ソフトウェア開発の要件定義フェイズで機能要件を定義していく中で、抜け落ちてしまいがちなものがあります。それは操作要件です。ペルソナ／シナリオ法は、それを補うものといえるでしょう。ペルソナ／シナリオ法は、作ろうとしているものの使用者を考えていくやり方です。どのようなスキルを持った人が、どういう流れで使用し、どれくらいで修得できるのかといった、作り手にとって抜け落ちてしまいがちな情報を補完する役割があります。

　ペルソナ／シナリオ法は、詳細設計や実装を行うエンジニアのためだけのものとイメージする人もいますが、実際にやってみると、それだけでなくソフトウェアを設計するあらゆるフェイズの人にかかわってくるように思います。具体的にいうと、営業担当が「このペルソナ合ってるの」とか「このシナリオどおりに30分では操作完了できないよ」といったことを指摘することもあるでしょう。

　ペルソナ／シナリオ法を用いた開発手順ですが、フェイズとして「ペルソナ設定」「デザインガイドライン設定」「シナリオ作成」「画面設計」があり、この後は詳細設計・実装フェイズがあります。ペルソナ設定の後は、「デザインガイドライン設定」と「シナリオ作成」を並行してやって、一貫性を持たせています。

ペルソナ／シナリオ法を用いた開発手順

デザインガイドラインとシナリオの作成法

　ペルソナの作成について、前回（「ユーザビリティの時代──ペルソナ／シナリオ法 理論編」）お話ししていますので、今回はデザインガイドラインの設定から説明していきます。

　デザインガイドラインの設定では、ソフトウェアを設計するうえでの原則となるポイントを明記していきます。もう少しかみ砕くと、「こういうペルソナが使うので、このルールを今回設けなければいけない」ということを書きます。

　次にシナリオの作成です。DataSpiderをインストールするところから、さまざまな操作を習得していく過程までを、日付や曜日なども細かく入れた日記形式で記述していきます。

　まず全体の流れですが、シナリオはそれぞれが独立しているものではなく、「このシナリオの次に、このシナリオが来る」というフローになっています。ですから、全体の流れを一覧できる目次が必要です。

　DataSpiderを開発する際のペルソナには、こんなシナリオを書きました。

・4月26日（月）	「イベント：チーム誕生」
・翌27日（火）	「イベント：セットアップ。初のアプリケーション開発に着手する」
・3日目（水）	「イベント：複雑なアプリケーションの開発をやってみる」
シナリオ例　DataSpiderが使用されるストーリーを具体的に記述する

　DataSpiderを使って作成したアプリケーションを確認するとか、テストケースを作るとか、そういったことも盛り込みながら、流れをまとめていきます。

　さらに、アプリケーション開発が遅れ気味のため、分担開発でもう1人投入したときに、どういうふうにこのツールでチーム開発がサポートされるのかということも定義します。あるいは、開発の遅れを取り戻すために出張中にも新幹線内で作業を進めなければいけない状況があったとします。新幹線内という特殊な状況になるかどうかは別として、実際に複数プロジェクトを抱えていたり、前任のプロジェクトに問題が起こって出張に行かなければいかない状況はよくあることです。そうした状況にどう応えるかを書いたりします。

　ほかに、アプリケーション開発のフェイズを終えて開発環境から本番環境に移行準備をするとか、ログのバックアップを取るとか、バグがあって障害が発生した場合にはどういう流れで処理することになるのか……。使い始めて1カ月経過したところで、どうもパフォーマンスが悪化してきた──そんなときに、原因を突き止めていけるのかも、日記形式で定義されています。さらに、パフォーマンス維持のために修正バージョンを導入したのだけれども、問題があったので前のバージョンに戻す、という内容も当然あり得る話です。こういったストーリーを定義します。

　これらを機能要件ベースに仕様に落とそうとすると結構大変ではないでしょうか。シナリオにせずに機能要件でも、バージョンの差し戻し機能とか、パッチのバックアウト機能という形で仕様化することはできます。しかし、「このような流れで使っていて問題が起こった」というような、人間の生活感や感情にかかわる情報、文脈に依存する情報が欠落してしまいます。それに対して、シナリオのように「イベント：チーム誕生」から始まる、すべての流れを見ていくことで、実際のユーザーに対する感情移入がしやすくなります。

---

▼※1：DataSpiderカタログ［PDF］

---