ペルソナビルドのインタビュー

次回のアウラセミナーではペルソナを取り上げようと考えています。
ペルソナという手法は、我々が普段関わることが多い消費財相手のリサーチにはあまり向いていない方法かもしれません。
自分の知識ではアプリケーションソフトの開発現場がペルソナの活躍の場のようです。

例えば50人規模の会社の会計ソフト(大げさにいえばERPソフト)の開発を考えると、
?業務分析を行う
?経理担当から社長までの「要求項目」を分析する(ここで、定量的な調査やインタビュー調査が実施される)
?プロトタイプ(コンセプト)を作成する
?ユーザビリティ評価を行う
?再検討して開発に入る
というプロセスをとるようです。
ここでデッドロックに乗り上げるのが、各担当から出てくる要求項目が互いに矛盾したり衝突する場合です。
例えば、
経費の入力画面の入力欄の数をいくつ表示すればよいかという要求項目に、社長は「2から3行あれば十分で、入力欄を大きく表示しろ」と要求したとします。
一方、経理担当者は「1画面に20行はないとスクロールが多くなって効率と精度が低下する」としたとします。
ここで開発者が「じゃ、社長と経理担当の間をとって5から6行にしましょう」としてしまうと両者にとって使い勝手が中途半端なソフトが出来上がります。

こういった弊害を防ぐためにペルソナを導入するわけです。
ペルソナは、今回のソフトを最も「よく使う人」として想定します。
いうまでもなく、この「よく使う」の意味は頻度が高かったり使用時間が長いということではありません。
この「よく使う」の視点で分析していったら経理課のベテラン社員が浮かんできたします。
そしたら、この社員をペルソナとし、この社員が使いやすいようにソフトを作ればよいとなります。
実在の社員その人でなく、「よく使う」という視点で分析(作り上げた)したペルソナ(架空の人)とします。
さらにこのペルソナをあたかも実在して実際に仕事をする使う人として作り上げます。

こうしてペルソナを作っておくと
・開発途中でのコンフリクトが解決しやすい → ペルソナだったら何と言うだろうか
・開発コンセプトがブレない → 予算がないといってもこの機能を組み込まないとペルソナの残業が増える
・開発チームの「よりどころ」になる → リーダーや権威者の指示ではなくユーザーの声に従えばよい
などのメリットがあります。

さらにメンテナンスに入ってもこのペルソナが有効に働きます。
(実際はペルソナも成長=作り替え、していきます)

以上みたようにアプリや耐久財(家電やクルマ、電子機器)には使えそうですが、飲食品などには使いずらそうです。
困難はありそうですが我々にとって身近な商品、ブランドでチャレンジしたいと思います。
・ペルソナビルドのためのインタビューの方法論
が主テーマですが
・評価グリッド
・シナリオ法
・エスノグラフィー
なども組み合わせられたらと考えています。

早くテーマを決めないと。