上位下位関係分析でつまずきがちなポイントと対処法
ユーザー調査の分析・モデリング手法はいろいろありますが、今回は、上位下位関係分析について書いていこうと思います。
1.上位下位関係分析とは
上位下位関係分析とは、グループインタビューデータの分析手法として考案されたもので、主に下記3つのニーズの階層に分かれます。（必ずしも3つでなくても良い。）
Beニーズ：ユーザーの本質的ニーズ。「〜になりたい。」
Doニーズ：ユーザーの行為目標。「（Beニーズを実現するために）〜したい。」
Haveニーズ：ユーザーの事象。「（Doニーズを実現するために）〜が欲しい。」
埋めていく順序としては、ニーズ情報を下から上へ、ラダーアップしていきます。
進め方の大まかな手順は、下記4つです。
①ニーズ情報のカード化
②集約と上下関係の発見
③上位のニーズの抽出
④レベルの調整
①ニーズ情報のカード化
まずは、発話などのデータから特徴的な行動、その理由や背景、要望などを整理し、事象カードを書き出します。
②集約と上下関係の発見
①の事象カード下段に並べていきます。最初はランダムに並べますが、最終的に紐づいた上位ニーズと線で結びますので、線が混線して見にくくならないよう、同じニーズと思われるものを近くに置くよう並べ替えていきます。
この時、あくまでもニーズで近しいものかどうかで判断しますので、「これは会計系」「これは商品選択系」など、事象のカテゴリや行動のフェーズで分類しないよう注意が必要です。このあたりのコツはKJ法と一緒です。
なんとなくまとまってきたら、類似の事象カード同士の小さな単位で上下関係を見ていきます。
事象カードは、データから書き出したものなので、粒度がバラバラです。事象カード同士の小さな単位で上下関係を見た時に、ユーザーの行為目標のものが混ざっている場合、それは、Doニーズのエリアに移動させ、下位にあたる事象カードと線で結びます。このあたりは、KJ法と異なる部分です。
③上位のニーズの抽出
事象カードだけで上下関係を導出できないものが出てきたら、事象カードを元に、上位のニーズを導出します。元の事象カードはそのままHaveニーズエリアに、導出した上位ニーズは、Doニーズエリアに行為目標カードを作成して置き、下位にあたる事象カードと線で結びます。
ひととおりすべての事象カードが上位化できたら、Doニーズエリアの行為目標カードに対して同じように上位化を行い、導出した上位ニーズは、Beニーズエリアに、本質的ニーズカードとして置き、下位にあたる行為目標カードと線で結びます。
Beニーズエリアの本質的ニーズカードのレベル感ですが、「幸せに生きたい」「安心して暮らしたい」などは、抽象度が高すぎて、だいたい何にでも当てはまってしまうため、もう少し抽象度を下げます。この時、抽象度を下げにくい場合は、Beニーズの上にもう１段設け、そこに抽象度が高すぎるカードを置いてから考えると、抽象度が高いカードと行為目標カードの間というのが視覚的に表現されるため、考えやすくなります。
④レベルの調整
導出されたニーズの全体を俯瞰し、Beニーズ・Doニーズ・Haveニーズの各階層でレベルが揃うように、カードに書いた文言の調整や、階層関係を整理します。
慣れないうちは、「Doニーズの階層は〜したいに変換して、Beニーズの階層は〜になりたいに揃える」というように、言葉の力を借りて、上下をかなり行ったり来たりします。
2.私が上位下位関係分析を使いづらいと思う理由
個人的には、この上位下位関係分析は、分析する頭を鍛えるトレーニングとしては、かなり有効だと思っています。UXデザイナーとしてガッツリ稼働するようになる前に、授業という可動工数を気にしないで時間をかけられる場で「身につけるぞ！」というモチベーションの高いメンバーと議論しながら、何度も上と下を行ったり来たりした経験は、今も活きています。（遅くまで居残りしてしまったので、警備員さんにはご迷惑をおかけしてしまいましたが。）
ただ、分析方法としては、個人的には使いづらく、現場での使用は避けがちです。
どのあたりが使いづらいかというと、1つ目は「これは会計系」「これは商品選択系」など、事象のカテゴリや行動のフェーズで分類しないようにすることです。これはKJ法にも言えることなのですが、目に見えているものを分類する方がわかりやすく楽なので、ダメと事前に言われても、ついやってしまいがちになります。もちろん、きちんと上位概念、下位概念で分析していくことができれば、「会計時の上位の価値はこれ」などにたどり着くことはできますが、最初に分類した「これは会計系」「これは商品選択系」などの分類項目から離れづらくなります。
2つ目は、最初のニーズ情報のカード化の部分です。インタビューデータなどは、カード化しやすいよう発話されているとは限りません。そんな情報群の中から「つまりこれは、どういうことだろう？」の導出をする必要が出てきます。KA法の「心の声がうまく書けない」問題同様コツがあり、ここが苦手な方もいらっしゃるため、ワークショップで全員で一斉にやろうとすると、なかなか先に進めないことがあります。ただし、ここは初っ端のパートなので、適当にやってしまうと分析結果に大きく影響が出てしまうため、どうしても時間をかけざるを得ない状況になります。
3つ目は、「この価値の上位概念はこれ」という考え方自体が意外に難しいということ。これは、頭の良し悪しではなく、純粋に、こういった思考の習熟度かなと思っています。全員がUXデザインを学んでいくような現場であれば、チームみんなで少しづつボトムアップをして成長していくという手もありますが、クライアントワークなどで、ここの学習時間をかけられない方が参加者にいる場合、全員が理解・納得した上で次に進むというのが難しいケースがあります。
また、先にも述べたとおり、事象カードは、データから書き出したものなので、粒度がバラバラです。このため、カードに書いてある内容を見た時に概念の上位度が微妙に細かく分かれているケースがあり、1つ上の階層に上げるべきなのか否かの判断が難しいものがあります。
3.私なりの「上位下位関係分析」解釈と対処法
2つ目、3つ目が難しい理由として、プレイヤーが、いきなりそれなりの精度で思考をまとめながらワークをしなくてはいけない点が考えられます。（1つ目は「ほにゃらら系で分類しちゃってるぞポリス」役を誰かが意識的に行い、つど声をかけてもらうくらいしかできない気がしています。）
また、実際問題として、モデリング成果物は、ワークショップに参加していない人や、将来Joinしてくる新しいメンバーにも展開できる必要があるケースが多いです。
そこを踏まえた上で、私なりの「上位下位関係分析」解釈と対処法を書いていきます。
①可視化を極力するため、とりあえずデータから素直に書き出す
上位下位関係分析を行う際に、書籍や記事をあたった時に、最初にぶち当たるのが、事象カードの書き方です。
慣れないうちは、丸めすぎて抽象度が高くなってしまったり、書いた人の解釈がかなり入り込んでしまったり、必要な情報を端折って書いてしまったりします。
また、ワークショップに参加しなかったメンバーにも展開する場合、ある程度のトレーサビリティは担保する必要があるため、Haveニーズ = ユーザーの事象とはせず、Haveニーズの下にデータからの抽出した事象の段を設け、そこに、特徴的な行動を、その行動ごとに、理由や背景、要望などを書いて、文面にあまり手を加えないものを置いていきます。
「あまり手を加えない」というのは、1枚にまとめるには文字量が多すぎる場合（考えながらの発話に多い）や、発話順の関係で間に異なる内容が入り込んでしまった場合にそこを省くなどは必要になるためです。
②抽出した事象を書き出したカードをニーズに変換
少しKA法的なアプローチになりますが、①で作成した事象のカードに対して、「つまりこれは、どういうニーズだろう？」を考え、ニーズのカードを作成します。
①で書き出した時点で、すでにニーズになっていれば、それはそのまま使います。
事象からうまくニーズにできない場合、「〜したい」「〜したくない」に語尾を変えて成立するような書き方をします。
「Have」ニーズなので「〜が欲しい」で揃えたいところではありますが、意外と「〜が欲しい」という言い回しに直しづらい言葉が多いので、ニーズとして言い換えやすい言葉を使います。
ただし、あくまでもHaveニーズなので、「（Doニーズを実現するために）〜したい。」という、抽象度の低い粒度で書きます。どうしても抽象度が高くしか書けないものは、最初からHaveニーズの場合があるので、上の階層に置きます。どちらの階層か迷ったら、一旦HaveニーズとDoニーズの間に置き、他の上位化を進めます。ある程度上位化を進めてから、他の上位化されたものと比較した方が、判断しやすくなります。
事象をニーズに変換する時にしない方が良い表現は「○○な価値」という語尾に「価値」をつける言い回しです。KAカードを書く際によく使う言い回しですが、名詞的表現のため、上位下位関係分析のHaveニーズで使用すると、意図せず不必要なところで抽象度が高くなりすぎ、文脈と違う方向へ引っ張られることがあります。
ニーズへの変換ですが、付箋を使う場合、事象と色の異なる（または濃淡の異なる）付箋を用い、次のグルーピングの際、ニーズの付箋と事象の付箋が上下関係になっていると見やすいです。
また、オフラインの場合、いちいちテープを貼るのが面倒ではありますが、KA法のように専用のカードを作ってしまうというのも一つの手です。
③ニーズ表現に変換したカード同士で集約と上下関係の発見を行う
ここからは、本来の上位下位関係分析と同じです。
②でニーズに変換したことで、ニーズでのグルーピングがしやすくなるので、ここで近しいカード同士を寄せていきます。KA法の後にKJ法を使うのと似た感覚です。
そしてニーズ表現同士を比較して、それが上位概念なのか否か議論の上、概念の粒度で、Haveニーズの層とDoニーズの層にそれぞれ配置し、線で結んでいきます。
④上位のニーズの抽出
Haveニーズエリアのカードがひととおりすべて上位化できたら、Doニーズエリアの行為目標カードに対して同じように上位化を行い、導出した上位ニーズは、Beニーズエリアに、本質的ニーズカードとして置き、下位にあたる行為目標カードと線で結びます。
⑤レベルの調整
導出されたニーズの全体を俯瞰し、Beニーズ・Doニーズ・Haveニーズの各階層でレベルが揃うように、カードに書いた文言の調整や、階層関係を整理します。
4.上位下位関係分析の有効な使い方
上位下位関係分析はニーズをラダーアップしていく手法で、価値層に着目して行う分析・モデリング手法にあたります。
サービスやプロダクトの企画や初期開発の要件出し、価値の再定義などに向いています。
時間はかかりますが、「つまりこれは、どういうことだろう？」や「これの上位概念って何だろう？」の議論を、関わるメンバーと掘り下げて行うことで、自分たちが作ろうとしているサービスやプロダクトを多角的に考えることができます。
最終的に、上位下位関係分析の結果として、紙面に残るのは議論の一部ですが、議論途中の話自体も、以降のフェーズでも、議論した内容や経験は、参加者の血肉として活かされます。
一方で、分析結果の図からは、時間軸が失われるため、ユーザー動線や、ユーザーの行動ごとの戦略立案などには向いていないため、別途、ジャーニーマップなど、行為のモデリングを行って、補完します。
また、具体的に何の機能が必要かなどの実装寄りの話をしたい場合は、DoニーズやHaveニーズなどを元に、アイディエーションを行う必要があります。
分析・モデリング手法は、いろいろな種類がありますが、それぞれ特性があります。
分析が終わった後で「で？この後どうすりゃいいの…？」と途方に暮れないよう、目的やゴールに合わせて、手法の選択や組み合わせを考えておくと良いです。