Nayose Groupが開発する名寄せ技術によるサービス
Sansan Enginerring UnitのNayose Groupではビジネスデータの収集、整理、データベース化を行って、そのデータを用いたビジネス価値の創出を担う機能を各プロダクトへ提供するのが役割となります。
Sansanは、オペレーションとデータとテクノロジーを掛け合わせてプロダクトを作っていくところが強みです。
その中でもデータを担っているのがNayose Groupで、名寄せ技術の開発を行っています。 名寄せとは、同一人物や同一企業の単位でデータを統合することです。例えば、名刺やメール、署名、もしくは顧客管理の情報、公開情報に対して一意のIDを付けていろいろな価値を提供しています。
会社に対してIDが付いた場合は、この会社に所属している人がこうツリー構造で分かるようになります。
名寄せ技術の課題と改善策
名寄せはシステムの成長に伴って扱うデータと評価軸が複雑化してきて、 クオリティーチェックに時間がかかることが課題でした。
先ほどもスライドで説明したように、名刺データだけではなく公開情報や請求書など、入ってくるデータが多岐にわたるようになっています。
そこでSansanの強みとしてクオリティーチェックをしっかりやって担保していましたが、どうしてもここに時間がかかってしまっていました。
以前は複雑な依頼でも対応可能で結果の信頼性が高いことがクオリティーチェックの強みでしたが、すべて人の手で行っていたのでどうしても時間がかかってしまうことが顕在化してきて、リリース回数が減ってしまいました。
そこで、なるべくクオリティーを落とさずに時間を短縮する方法を検討することにしました。開発サイクルは早くしたいですが、 クオリティーの担保をしないとデータベース自体の価値が低下します。結果的にはプロダクトの価値低下につながるので、クオリティーの担保が何よりも重要でした。
ここでMLOpsが出てくるのですが、Machine Learningで作られたアルゴリズムを活用するのではなく、MLOpsそのもの（アルゴリズムを作成するための仕組み）を導入することが今回の計画です。
MLOpsは人が介在して評価データが作られて、この評価データを使ってCI/CDに組み込んで自動で評価される（評価データは評価プロセスで毎回再利用される）という流れです。
この流れを導入すると、Sansanの強みであるクオリティーチェックの良さを残したまま自動化が実現できそうだったんです。
MLOps導入のために検討すべきこと
現在もMLOpsのエッセンスを実際に取り入れて進行中なのですが、評価データの作成が課題となりました。1回評価データを作って終わりとなれば1番簡単ですが、 複雑化していた要件をまずは解きほぐさないといけなかったんです。
何のためにチェックしているのかを整理して、そのために必要なデータを一つひとつ要件に沿って作っていく必要がありました。
まずはデータの作り方やサンプリングの方法を考えなければいけないですね。企業情報や人物といったデータの鮮度も大事で、古いデータをずっと使うわけにはいきません。
あとはデータの量です。クオリティーを担保するデータの量は一体何なのかも要件の段階で一から考える必要があります。
以上のことを考えていくと、オペレーションも問題となってきます。どうしても人が介在して時間がかかるので、評価データの作成においても結局は人の介在をどれだけ小さくできるかというオペレーションの改善が重要になりました。
まさに継ぎ足しで秘伝のタレを作るような工程を、評価データのところで行っています。 今のところ未完成ですが、このような形でMLOpsを使って評価システム全体を再構築しています。
視聴者からの質問に答える質疑応答タイムへ
――ここからは、視聴者の方からの質問に回答していきます。まず1つ目は、「データ構造の負債を解消するために専用のメンバーを配置しているのでしょうか、それとも開発メンバーが機能アップデートと並行して進めているのでしょうか」という質問です。陳さんからご共有いただけますか。
陳：我々は全て同じメンバーがやっています。なぜなら、ここを分けると背景がわからないメンバーも入ってきてしまうからですね。 基本的に解消する際は短期間で皆で一緒にやり切るという形で進めています。
――続いてtocknさん、お願いします。
tockn：弊社も同じで、特に負債解消の専門チームは置いていません。プロダクトを開発するメンバーが解消しています。クォーターの最初の2週間は非機能系の改善に当てるといった改善ウィークも設けたりして、色んな方法でプロダクト開発と共に並行できる施策を練っている感じですね。
――続いて大島さん、お願いします。
大島：Nayose Groupは歴史が長く大きいチームになっていて、その結果システムとしても大きくなってしまいました。そのため、チームを分割してより改善しやすくなる構造にしています。
――続いて森山さん、お願いします。
森山：弊社も機能アップデートと並行してやっていますね。 開発を進めるか、負債を解消するかを天秤にかけていて、場合によっては負債の解消を優先しています。
――最後に弓場さんはお願いします。
弓場：フツパーもチームを分けてはいなくて、開発メンバーが担う体制で今はやっています。
――続けて、「どれぐらいの時間をかけて負債を解消してきましたか」とのことですが、陳さんからお願いできますか？
陳：基本的には2〜3週間でやりきることを徹底しています。 何か行動的に問題が発覚した場合は一旦開発を止めて2〜3週間で全部やりきって、無理にその先に進まないという判断をしてきました。 短期間で細かく、問題があるところだけ集中的にアタックする形ですね。
――続いてtocknさん、お願いします。
tockn：先ほどの回答と被りますが、改善ウィークみたいな形で1週間〜2週間を改善の期間に当てていますね。あとは、クォーター単位でプロダクトや非機能系の開発も含めて何をやるのかを整理する段階で期間を当てはめたりしています。
――続いて大島さん、お願いします。
大島：細かいところは2週間くらいの短期間でやって、 どうしても歴史的経緯で大規模改修が必要なタイミングであれば半年〜1年ぐらいかけて、現在動いているものをリプレイスする形です。
――続いて森山さん、お願いします。
森山：大体メンバーは複数人いるので、一人が負債回収して、もう一人は機能開発という感じでやっていましたね。負債回収をやると大体1ヶ月ぐらいかかります。それぐらいで今回の課題などは対応していました。
――続いて弓場さん、お願いします。
弓場：今回発表したデータベースの移行に関してはいきなり全部を変えるのではなくて、ステップを区切って1ヶ月単位で行いました。
――本日のイベントはこちらで終了とさせていただきます。 登壇者の皆さん、視聴者の皆さんありがとうございました。
