はじめに

これは技術記事の体裁を模した愚痴である。しかし愚痴にしては具体性が乏しい。具体性が乏しい理由はあまり深く問い詰めないでほしい。

推薦システムの開発

推薦のアルゴリズムを考えるという課題がある。世の中には情報が溢れていて、情報過多の現代においては溢れている情報のうちその人に関係のありそうなもの、その人が得たいと思っていそうなものをリコメンドすることは意義がある、かもしれない¹。特に業務で選択肢が多すぎて人間が手動でフィルタするのが大変な場合、そのフィルタリングを機械がやるのは業務の効率化につながるだろう²。あるいは、顧客が既に利用している推薦システムに課題を感じていて、よりコンバージョンを向上させたり、より精度の良い推薦ができるようなシステム、アルゴリズムにできないかと考えているかもしれない。

というようなことが契機となって、他社のために推薦システムを作るプロジェクトに関係したことがある。しかし、わたしが関わったプロジェクトはすべて失敗した。何で失敗しているのかもわからないくらいにひどい失敗をしたこともあった。

わたしのせいでプロジェクトが破綻している、そうかもしれない。わたしのエンジニアリング能力が足らないのかもしれない。しかし、そういう一切合財を一旦全部全部棚に上げて、数少ない失敗経験と、全くない成功体験から、なぜ受託開発での推薦システム開発が難しいかをメタ情報から考えてみようと思う、というのがこの記事の主旨である。メタ情報を使うのは具体的な情報は書けないし書きたくないからである。

推薦システム開発の情報の偏り

受託開発の情報の不足#

おそらくこんなタイトルの記事を読もうと思っている時点で何がしかの形で推薦システムの開発に携わったことがあると思う。あるいはこれから携わるので情報収集中かもしれない。そこで少し考えてみてほしいのだが、世の中に公表されている推薦システム開発関係の勉強会発表、資料、記事などで「受託開発において」の過程や成果を見たことがある人がいるだろうか。

わたしは一度もない。理由としていくつか考えられるが、まずそもそも推薦システム関係なく受託開発案件の話は書きにくい(NDAとかもろもろ)という話がある。他にもいろいろと思っていることはあるけど、憶測の域は出ないので書かない。

ちなみに、「じゃあ515hikaruが書けばええやんけ」と思われる人もいるかもしれない。書こうと、あるいは喋ろうと思ったことがないわけではないが、一生思い出したくないことが容易に3つくらい思い出されるのでやはりわたしも書かないし喋らないだろう。たとえ酒の席でもだ。もしかしたら、他のプロジェクトの従事者もそう思っているのかもしれない。

自社サービス開発における推薦システム#

というわけで世の中に推薦システム開発関係の情報は自社サービスでこんなリコメンドシステムを作り、こんな風に効果検証をしたみたいな内容の物が多い。作る方にフォーカスがあたっている場合はどんなデータを使ったか、あるいはどんな技術やサービスを使ったかに焦点があたっていることが多い。この内容については受託だろうが自社サービスだろうが状況はあまり変わらない³ので情報が不足しているわけではない。

効果検証にフォーカスすると、自社サービスの場合は下記の条件を満たしている。

• プロダクトが存在している
• そのプロダクトのユーザーが存在している
• 新リコメンドシステムをプロダクトに組み込むことが自社の判断で可能である
• リコメンドの評価方法を自社が決められる

プロダクトがあってユーザーが居るから、ABテストなど方法は問わないが実際にそのサービスにリコメンドシステムを組み込みやってみることができる。そして、(おそらく)推薦の良し悪しをクリック数などから定量的に評価をし、本導入する/しないというプロセスになる。要するにやってみてだめだったら廃止、よかったら採用というのが自社内の議論だけで完結するわけだ。わたしは自社サービスに推薦システムを組み込んだことはないから正しいことを言えている自信はないけれど、勉強会とかで聞いた話でここから大きくずれている内容はなかったように思う。

受託開発における推薦システム#

そして自社サービス開発における状況で満たされている前提条件が受託開発で満たされていることはまずない。そもそもプロダクトが存在しないケースは、これから作る業務システムのこれから作る推薦システムの話をしているケースだ。これはそもそもものがないので、一旦「これでとりあえずやってみようぜ！」と決め打ちでやってみる必要がある。しかし、「根拠はないけどやってみようぜ！」と言ってやらせてくれる会社は普通はない。

既存のサービスがあったとしてもそのサービスを社外の我々が組み込むことは難しい。効果があるとわかってから組み込むと言われ、効果があるとわかるためには組み込むしかないじゃない、という禅問答をひたすら繰り返した記憶があったりなかったりする。

そしてリコメンドの良し悪しを評価しようにも評価方法がそもそもなかったりする。今までやった方法は、

• リコメンドされたもののクリック率(数字)で評価
• アルゴリズムの詳細を説明して “納得” してもらう

の2つある。

前者についてはECサイトでとった方法だ。しかし、はっきり言ってECサイトの推薦システムの精度の “数字” って絶対値で言うとそんないいものではない。Amazonのリコメンドを思い起こしてほしいが、みなさんはAmazonのリコメンドをどれくらいクリックしているだろうか。Amazonのトップページにいって、普通は買いたいものがあるから検索をし、目当ての商品をクリックする。この間にリコメンドでめぼしい商品を見つけてリコメンドボタンをクリックする割合は何%だろうか。

1%とかそれどころでなく、0.001%とか 0% と言われてもわたしは別に驚かない。ふつうネットショッピングサイトは目的があるときに開くものだし、目的がある状態でリコメンドにばかり目が行く人も稀だろう⁴。つまり数字で評価をしようとすると開発者は「この推薦システム、精度0.001%でしたけど、導入しましょう!」という提案をしにいくことになる。さすがにどれだけ数字オンチな依頼者でも「だったら要らない」となってしまうだろう。依頼者側がなんらかのベンチマークを持っている場合はまだいいが、ベンチマークがない場合は開発者も依頼者もどう検証すればいいかわからず途方に暮れることになる。

後者はベンチマークがないし既存のデータもないのでそうせざるを得なかったというプロジェクトだ。納得するかしないかは顧客次第なのでこれについては汎用性のあることは書けないし、具体性のあることは(別の意味で)書けない。

推薦の精度評価

だらだらと書いてしまったので論旨がわかりにくくなってしまった。

要するに自社開発においても受託開発においても推薦システム開発において最も重要で最も難しいのは「いかにして精度を評価するか」である。

推薦システムは動いているだけでは意味がない。エラーなく動いた上で、ユーザーの心を動かす(可能性の高い)ものを提示し続ける必要がある。そのためにABテストなどをして既存の推薦や新しい推薦のなるべく正確で定量的な比較を実施する必要がある。あるいは定期的に推薦システムの精度を評価して、ロジックを見直す必要がある。そして自社サービスの場合、社内の説得や調整で一連の工程は実施可能である。

受託開発の場合は顧客を動かす必要がある。上記のような一連の検証サイクルが必要であることを訴え、お互いのために顧客に効果を検証できる環境を作ってもらえるよう顧客と信頼関係を作る必要がある。

顧客を巻き込むことが大事であると『アジャイルサムライ』 にも書いてある。しかし、わたしが知る限りこれはとても難しいことだ。

まとめにならないまとめ

書いているうちにわたしが関わったプロジェクトに問題があっただけな気もしてきたけど、まとめる。

• 推薦システムを作る上で最も重要なのは技術選定でもアルゴリズムでもなく精度・効果検証である
• 見た目の数字の精度では測れない 精度 があるのでリコメンドシステムの検証は過去データのみで検証することは難しい
• 顧客を巻き込んだ意味のある効果検証をきちんと実施できるかどうかが勝負の分かれ目
  • PoC段階で一定のベンチマークさえない場合効果検証のしようがなく詰む
• もう一生推薦システム作りたくない