3. 「テクノロジー＋アート」でお客様の役に立つ
多くの人が「検索＝テクノロジー」だと思っていますが、実は良い検索はテクノロジーだけでは成り立ちません。ちょっと専門的になりますが、いくつか例を挙げます。
（1）相関性評価
新しいアルゴリズムを開発した後は、今までの検索結果と比較してどれくらい良くなったのかを評価します。これを「相関性評価」と言いますが、相関性評価をすることによって「数字」で改善の度合いを示すことが出来ます。
相関性評価は、クエリーと検索結果のペアに点数をつけることによって行います。ランダムに選んだ100〜500くらいのクエリーに対して、検索結果を上位から5〜10件見て行き、それぞれの結果に点数をつけるのです。
点数をつける人たちの間で基準がぶれないようにきちんとトレーニングを受けていないと正確な判定が出来ません。
全てのクエリーに対して点数を集計すると、アルゴリズムの前後で点数がどれくらい変化したのかを知ることが出来ます。ユニナレでは大きな改善を行う時には必ず相関性評価を行って、検索結果が良くなっていることを確認しています。
（２）ゼロマッチ対策
次にゼロマッチ対策があります。クエリーログを見ることによって、ヒット件数がゼロ件のクエリーを見つけることが出来ます。これを「ゼロマッチ」と呼びますが、ECサイトではゼロマッチ率が高いことは大きな機会損失です。ゼロマッチとなったクエリーを見て行くと、様々なことが分かります。
（１）同義語の登録
（２）形態素解析辞書の登録
（３）マッチングのアルゴリズムの改善
（４）商品登録方法の改善
（５）カテゴリ構造の改善
（６）取扱商品の拡充
これらを分類し、対策を行うにはやはり人手の管理・運用が必須です。
（３）バケットテスト
ユニナレでは「バケットテスト」と呼んでいる改善のプロセスがあります。「ABテスト」はご存知の方が多いと思いますが、バケットテストではA、Bだけでなく3つ以上のテストを同時に進めることが出来るのです。
例えば、5％のユーザーにアルゴリズムXの検索結果を、別の5％のユーザーにアルゴリズムYの検索結果を、さらに別の5％のユーザーにアルゴリズムZの検索結果を見せて、どのアルゴリズムのパフォーマンスが一番良いのかを計測します。
「5%のユーザー」のようにユーザーをたくさんの小さなバケツに入れて行くイメージから「バケットテスト」と呼ばれています。パフォーマンスの指標には色々とあると思いますが、ECサイトですからやはりコンバージョンや売上を重視します。
バケットテストの結果は統計的に解析を行って、それぞれのバケットが現状のアルゴリズムに対して統計的な有意差があるのかどうかを判定します。
先ほど「相関性評価」の話をしましたが、相関性評価はユニナレ社員による評価結果ですから売上がどうなるかまでは判断出来ません。相関性評価で良いと思ったアルゴリズムでもバケットテストをしてみないと、売上に対してポジティブな改善なのかどうか分かりません。そこで大きなアルゴリズムの改善をする場合には必ずバケットテストを行って、実際のお客様がどのように反応するのかを確かめるのです。
面白いことに、バケットテストではこちらの想定が外れることが多々あります。バケットテストの結果を見て初めてお客様の行動が理解できるケースが多いのです。
実際のお客様がどうように反応するのかを知っておくことは次のアルゴリズムの改善の土台として役に立ちます。このような経験の蓄積がユニナレをユニークな存在にしているのです。
以上挙げたような点は非常に大事な改善・運用のポイントなのですが、ECサイト向けのパッケージソフトウェアに付属しているような検索では、全く考慮されていないため検索結果がいつまで経っても良くなりません。
私は運用を「アート」と呼んでいます。「アート」は簡単に真似出来ません。検索とは「テクノロジー＋アート」があって初めて成り立つサービスであって、ソリューションを導入して終わりという性格のサービスではないのです。
4.開発した人が運用する
大手のウェブサイト運営会社では、おそらくほとんどの会社で「開発」と「運用」の分離の話について議論したことがあるのではないでしょうか？つまり開発する人は開発だけを行い、運用する人は運用だけを行うというものです。セキュリティ的な観点から望ましいというメリットもありますし、24時間安定的にサービスを提供するにはそれなりの運用体制を組まなければいけないということもあると思います。
また大企業では「その人がいなくなってもサービスが提供出来る」ことをメインに考えます。みんな休暇も取りますし退職してしまう人も出て来るので当然のことです。
しかしユニナレでは全く別の考え方をしています。
- 開発した人が運用する
- サービスと人を結びつけて切り離さない
つまり「属人性」を尊重しているのです。
「このサービスは君がいなくなったら提供できないから、何が何でもやってくれ」
と言われた方が、
「このサービスを君がやめても提供出来るように、しっかりとドキュメント化して引継ぎをしておいてくれ」
と言われるよりやる気が出るだろうと思っています。
もしサービスで障害が行ったとしても、中身を良く知っている開発者自身が運用を行っている訳ですから、原因の特定や応急措置もやりやすくなります。自分で開発したサービスの安定性が自分自身の運用時間に跳ね返ってくるので「いやいや引き継いで開発者を呪う」というようなこともありません：）
開発と運用を切り離さないことでドキュメントの更新作業などの間接業務を削減出来るというメリットも大きいです。
もちろん、大企業と同じやり方をするほど豊富に人材がいないという側面があることも事実です。しかし社内で自分しか出来ない業務を持っているという緊張感はかならずやりがいにつながると思っています。
5. リモートワーク
ユニナレでは「リモートワーク」がメインです。現在でも、全社員がオフィスに出社するのは週に1日、木曜日の午後だけです（！）。出社や通勤という制約がなくなると自分の時間を自由に組み立てられるようになります。
私は昔からみんなと同じ時間に出勤し体力や気力を消耗することに疑問を持っていました。会社員時代にも出来るだけ通勤に煩わされないように自転車で通える範囲に住むようにしていました。
「通勤」という行為が、その人の「しあわせ」につながると思ったことはありません。人生のある時点から、「しあわせ」につながることだけにフォーカスしようと思って、会社を作ったら通勤をなくそうと考えていました。
自分のやりたいことと仕事を分けることなく、人生の中に混ぜてしまえば良いと思います。どちらも自分の人生ですからやりたいように出来た方が良いに決まっています。
今年の夏、ユニナレの社員のKは「自転車で日本一周の旅」に出かけました。3ヶ月かかりましたが、その間も彼はリモートから働いていました。彼の担当してるサービスもたくさんありますし、彼しか知らないこともたくさんあります。
でもリモートワークですから自宅にいるのか、旅先にいるのかはあまり関係ありません。定例のミーティングにはウェブ会議を使って参加していました。
3ヶ月間会えないので、確かに週一で会っているよりも伝えるのが難しいこともありましたが、こういうことが出来るのもユニナレの特殊な環境のなせる技ではないかと思います。
（つづく）
---
# Facebok ページで「いいね！」して頂けると、ユニーバーサルナレッジの最新情報を得ることができます。
http://www.facebook.com/universal.knowledge.inc
コメント