検索における2種の条件と3つの機能についての考察
これはなにか
サービスにおける検索行動と検索機能についての考察である。
検索行動とはなにか
サービスにおける検索行動とは、ユーザーが思い描いた条件に合致する商品を見つけるために行う行為である。
たとえば、「男性向けのコンバースの26cmの白色のスニーカーが欲しい」といったケースを想像する。その場合、これらの「条件」をキーワードに含めて検索するか、検索条件に含めて商品を探し、購入するという行動を行うだろう。
この一連の行為の中で、「購入対象となる商品を見つける」という行為が検索行動である。
この検索行動においては、ユーザー自身が自分が求める商品の条件を、明文化された条件という形で明確に頭に思い描けていないというケースもある。（e.g. ◯◯っぽい感じのスカート、◯◯っぽい雰囲気のカフェなど）
そういったケースにはまた別の対処方法があるが、本稿では比較的明文化された条件に対しての検索行動を取り上げるため、割愛する。
商品に求める条件の種別
これらの検索行動に重要な役割を果たす「条件」であるが、この条件には2つの種類がある。 「Must条件」と「Want条件」である。
Must条件とWant条件
Must条件
Must条件とは、この条件が合わないと最終的な行動がそもそもできないという、絶対的な条件である。
例えば、靴を買う際の「サイズ」、賃貸を借りる際の「エリア」などである。この場合の「最終的な行動」は靴であれば「購入」、賃貸であれば「申込み」であり、これらが合致しないとそもそも最終行動ができない、「最終行動の可否を分ける条件」である。
Want条件
一方、Want条件とは、希望の条件に合っていた方が望ましいが、完全に合致していなくても最終的な行動が出来るという、相対的な条件である。
例えば、靴を買う際の「価格」、賃貸を借りる際の「駅からの距離」が該当する。これらは希望の条件に合致しなくとも折り合いがつく、「比較によって意思決定をする条件」である
Must条件とWant条件はグラデーション
ここまで検索条件を2つに大別してきたが、Must条件とWant条件は明確な線引があるものではない。
より厳密に言うと、Want条件はユーザーの意向次第でMust条件になりうる。また、その強さもグラデーションとなっており、これ以上強くなるとMust条件である、といったような明確な段階差はない。
例えば、靴の購入であれば、「一定価格以下でないと予算をオーバーするため買わない」であったり、賃貸を借りる場合であれば、「駅徒歩5分以内でないと絶対に住まない」といった、ユーザーのマイルールとしてWant条件をMust条件化しているケースが存在する。
条件の種別による検索機能UIへの影響
Must条件が「最終行動の可否を分ける絶対的な条件」だと考えると、Must条件は検索階層の上部に所属しているほうがよい。（表示位置ではなく画面階層の話。また、Want条件が同じ階層に同居することは問題ない）
例えば、賃貸を探すときに、次のような手順で絞り込む検索フローだった場合、条件にマッチするものが出ず、1からやり直すことになる。
- 部屋の金額、駅徒歩(Want条件)を先に決めて絞り込み
- その次にエリア(Must条件)入力して表示
逆の順番であれば、手戻りは1ステップで済むだろう。
加えて、金額や駅徒歩は、「他の物件との対比の中で最も良い」という状況で選択ができるため、徐々に条件を緩和して、候補物件を増やして妥協点を探るといった使い方もできるだろう。
また、一度Must条件のみで、検索を実行させ、その後検索結果の絞り込みとしてWant条件でフィルタリングをかけるという検索フローを組むこともできる。
検索機能の種別
検索条件には2つの種別があったが、検索機能は3つの種別に大きく分けられる。
- ディレクトリ型
- 条件並列絞り込み型
- キーワード型
である。
※画像検索、バーコード検索、ID検索といったピンポイント型の検索もあるが、検索の型としてはそんなに広がらないので本稿では扱わない
1. ディレクトリ型
ディレクトリ型は、カテゴリーをドリルダウンして掘っていき、該当するジャンルの商品一覧を出す方法である。
ディレクトリ型の特徴
ディレクトリ型では最終的に求める商品一つにたどり着くのは難しく、検索行動フローの終盤で、ユーザーのマニュアル操作での詳細確認・比較検討にかなりの比重で頼ることになる。
また、商品数が少なく、カテゴリー内の商品が適切なボリュームに保たれている場合は、ゼロマッチを起こさずに商品を見せることが出来るという利点がある。
一方で、サービスが成長し、商品が増えれば増えるほど、カテゴリーを広く深く拡張するか、カテゴリーごとの商品数を増やす必要があるため、探しにくくなるという欠点がある。
ディレクトリ型の活用方法
ディレクトリ型だけで検索行動を完結させることは難しいため、前述のとおりサービスの初期での利用および、Must条件に適応し、その後の絞り込みについては次の「条件並列絞り込み型」に任せるといった使い方をするとよい。
2. 条件並列絞り込み型
条件並列絞り込み型は、全商品群から単一もしくは複数の条件を並列で並べて絞り込んでいき、理想とする商品にたどり着く方法である。
条件並列絞り込み型の特徴
条件並列絞り込み型は、複数のピンポイントな条件で絞り込むことができるため、絞り込み強度が高く、精度高くユーザーの理想の商品にたどり着くことができるという利点があり、Want条件の適応に向いている。
しかし、その体験が実現できるのは、強度の高い絞り込みに耐えられるほど、商品群が豊富にあるときに限られる。
よって、商品群が多く存在しない段階で、良かれと思い、細かく多くの絞り込み条件を提供すると、ユーザーは理想を求めたキツい絞り込みをかけた結果、ゼロマッチ(※)になってしまい、かえって体験が悪化するという欠点もある。
さらに条件並列絞り込み型が苦手な状況として、商品のジャンルがバラバラなものを対象とする場合が上げられる。
例えば、釣具とコスメを探す場合の検索条件は大幅に異なるため、すべての商品を対象にして一括で絞り込みをかけようとするとどうしても無理が出てしまう。
仮にコスメだとしても、液状、パウダー状、固形など形状が異なるし、効能も異なるため、ジャンルごとに個別のUIが必要になってくる。
※ゼロマッチ= 合致する商品がなく、検索結果に商品がなにも出ないこと
条件並列絞り込み型の活用方法
まず、絞り込みの強さについての対策として、サービス内の商品の拡充度合いに応じて、下記のような対応をしてゼロマッチ時の体験をコントロールする必要がある。
- 粒度の粗い絞り込みにとどめる
- ひとつの条件内で複数の選択肢をOR条件で持たせられるオプションを用意する
(e.g. 選択できる都道府県を複数選択出来るようにする)
- ゼロマッチしても何かを必ず返すようにする
(e.g. 勝手に検索条件を緩和した結果を返す、おすすめの商品一覧を返す)
次に、ジャンルごとの条件が異なるという状況に対しては、ディレクトリ型の検索を前工程にはさみ、ジャンル別に検索条件が分かれるようなUIを提供することで解決ができる。
3. キーワード型
キーワード型は、おなじみGoogleを筆頭に一番良く使われているであろう検索型である。
（キーワード型は今回の考察の対象外だったので、初稿時点では割愛します。キーワード型はキーワード型で結構いろいろある気がするので、後日気が向いたら加筆します。）
まとめ
Must型、Want型という2つの検索条件に加えて、ディレクトリ型、条件並列絞り込み型、キーワード型といった検索機能があり、検索条件に合わせて機能を振り分けて、組み合わせることで、サービスのフェーズに合わせた最適な検索体験が提供できるため、サービスの状況を加味して適切に設計していくとよいだろう。
