名刺データ化コストを改善する

はじめまして、DSOC Development Group で開発をしている石畑です。

現在は名寄せチームで、データ統合の機能開発をしています。関連のある名刺データを統合することで、顧客情報を一元管理できるようにしたり、世の中の様々なビジネスデータを収集し、名刺に紐づけることで、名刺の価値を高めることがぼくらの目的です。Ruby(Rails) で開発しています。

RubyKaigi 2019 に参加して、Sansan ブースにも立っているので、ぜひ開発のあれこれについて話しましょう。

DSOC Development Group の取り組み

DSOC は Sansan の「データ」を司る部署です。そのため、「データ」を使ってユーザー価値につながることなら何でもやる所存ですが、現在できていることは大きく次の 3 つです。

1. 名刺データ化システム（GEES）の開発
2. データの名寄せ
3. 人・組織のニュース配信

これらのサービスは、それぞれ 3 - 6 人ほどの小さなチームで開発しています。少人数ながら、Sansan, Eight 全ユーザーに影響を与えられるとても刺激的なサービス開発です。これだけ多くの価値に関われるのが「データ」を扱う DSOC 開発の面白さだと思います。

今回は一例として、以前携わっていた名刺データ化システム（以下、GEES と呼ぶ）で、データ化のコスト削減を行った話したいと思います。

GEES の概要

GEES は名刺を高いセキュリティで、素早く、ミスなく、低コストにデータ化するためのシステムです。今は 10 ヶ国語に対応しています。

スピード・コストを重視すればガンガン自動化していけばいいんですが、そうもいかないのがデータ化精度です。Sansan はデータ化精度 99.9% をサービスとして約束しており、それがサービス価値の土台になっています。 また、本ブログでビジネスネットワークの活用などが紹介されていますが、活用するにはデータが正しくなければ意味がありません。そこで「人」によって高精度なデータ化を実現しています。自動と手動、そこのバランスがとても難しく、GEES 開発の面白いところでもあります。

少しでも自動化の恩恵を受け、手動の効率を上げるために、GEES の内部は自動車の組み立てラインの様に約 20 もの工程（サービス）に分かれています。

多くの工程を AI と人を組み合わせてデータ化している

これらは全て Rails で開発されており、そのマイクロサービスを連携させるのが AWS の Amazon Simple Workflow Service (SWF) です。 データの状態を見て、簡単にサービスを組み替えられるのが SWF のいいところです。 また、それ以外にも Aurora や ElastiCache, SQS, DynamoDB, Elasticsearch Service などなど、少人数チームで大量のデータを扱うために様々な AWS サービスをフル活用しています。

コスト削減プロジェクトの発足

ぼくらは GEES を評価する指標として Quality / Cost / Delivery / Security (データ化精度・データ化コスト・納品時間・セキュリティ) を数値化し、日々改善を続けています。どれも大事な指標ですが、最も大事なのは Security と Quality です。

一時期、 Security と Quality を達成するためにコストが大きく跳ね上がった時期がありました。そこで発足されたのがコスト削減プロジェクトです。その時は運用メンバー 2 人、開発者ぼくの計 3 人のチームでした。人の管理や勤怠周りでコストを削減するのが運用メンバー、システム周りでコストを削減するのが開発者であるぼくのやることです。

振り返ると以下のようなことをやりました。

1. 目標を立てる
2. 現状を数値化する
3. 数値をビジュアライズする
4. 具体的にデータを見て、改善案を考える
5. 効果とコストを見積もる
6. 開発する
7. 2 に戻る

1. 目標を立てる

まず最初に目標を立てます。これができたところで何一つ状況が前進することはないんですが、ぼくは最も大切な工程だと考えています。

大きく目標と現在がかけ離れているならウルトラ C な案を出すべきですし、目標があともう少しならコツコツ積み上げて行けば達成できます。目標によってこの後に取るべき行動が全く変わってしまいます。また、目標はチームのモチベーションにも大きく影響します。あまりに現実離れした目標を立ててしまうと、あとで「目標が悪かった」と言い訳をする隙を自分達に与えてしまいますし、あまりに簡単に達成できてしまうと「なんか大したことしてないな」という気持ちになってしまいます。そのため、目標決めは大事な工程だと考えています。ビジネス的に意味があり、無理のない、それでも背伸びしている、そんな目標が立てられると幸せな数ヶ月を過ごすことができます。僕らは OKR で目標を管理しているので、3 ヶ月の目標を立てます。

とはいえ、最初に話したように目標を決めたところで状況は全く改善しません。そのため、どんなに大事でも時間をかけすぎないように注意しています。感覚的には 1 週間、どんなに長くても 2 週間以内には決めたいところです。この期間はできる限り他の事はやらずに、目標決めのために集中して、調査をします。

2. 現状を数値化する

目標を決めたところでようやくスタート地点に立てます。スタート地点に立ったらすぐに走り出したいところですが、闇雲に走ってもゴールには偶然にしかたどり着くことはできません。まずやることは状況を正確に把握することです。そこで数値出しをします。

GEES では様々なところにイベントログを仕込み、Redshift や Athena で集計するための仕組みを持っています。ログは Fluentd で S3 に飛ばされ、それを Glue で Redshift にため込んでいます。

イベントログを Redshift に蓄積

サービスと切り離されているので、気軽に追加・削除できますし、Redash にクエリを登録しておけば非エンジニアの人たちも分析に使えるのが便利です。取りたい数値に合わせてログを埋め込みます。

3. 数値をビジュアライズする

現状を計測できるようになったら、地味に大事なのがビジュアライズです。素早く状況を知ることができますし、そのままレポートとして利用することもできます。DSOC はシステムに必要なものを開発者が提案し、そのまま開発することができますが、説明責任はあります。最初にビジュアライズしておくと、あとはバッチで定期的に Redshift のデータを飛ばすだけなので、資料作りが楽になります。といってもぼくはあまり凝ったことはできないので、スプレッドシートで簡単なグラフを作るくらいです。とにかく状況がパッと見たいだけなので、あまり時間をかけるものでもないです。

4. 具体的にデータを見て、改善案を考える

ここまでくれば大体コストを引き上げている箇所が見えるようになっているので、原因を特定するために関連する具体的なデータを見ていきます。いいコスト削減案が思いつくまで、時間の許す限り、とにかく大量のデータを見ます。

例えば、GEES では Quality を担保するために複数人によるデータマッチングを行っているんですが、中々マッチせずにコストを引き上げている事があります。そこがボトルネックだと分かれば、オペレーターの入力結果をひたすら見ていきます。 一人で見れる量には限りがあるので、運用メンバーと協力して複数人で見ていくんですが、最後には必ず自分がチェックします。自らデータを見なければ本当に作るべき機能を自分が確信を持てないからです。

ぼくらは営業の方のようにお客さんとビジネスで対面する場はほとんどないので、名刺交換をする機会は少ないです。それでも GEES のエンジニアは全員めちゃくちゃ名刺に詳しい自信があります。開発するたびに毎回大量のデータを見ているためです。（そんな日々を過ごしているせいか、名刺を見ると「データ化しやすそうかどうか」を真っ先に考えてしまします）

5. 効果とコストを見積もる

複数の改善案が出たらタスクの優先順位を決めるために、改修後どれだけコストが下がるかの期待値とその改修にかかる開発期間のざっくりの見積もりを出します。ここで期待値が目標に届いてなければ、さらなる案出しを考えます。また、各タスクの見積もりがあまりに大きければプロジェクトの進退を考えます。

ここでの見積もりは往々にして当たりません。名刺の流入にはその時々で偏りがありますし、見れるデータセットに限りがあるためです。また、開発の見積もりも詳細設計をしたわけではないので超感覚値です。それでも必ず数値は出します。開発が始まれば実装は例え一人でも、レビューなどで他の開発メンバーの時間を使いますし、機能は開発された瞬間に負債になります。そのため、提案者にはそれだけのコストをかけて開発する理由を周りに説明する責任があります。そのためには数値が最も説得力があります。

6. 開発する

長いステップを経てようやくみんな大好きな開発工程です！ プロジェクトによってはここまで来るのに 1 ヶ月以上かかることもあります。ものづくりって大変ですね。

一言で開発するといってもやることはたくさんあります。アーキテクチャ設計、詳細設計、実装にテストと進めて、ようやくリリースです。ただ、ここまでで多くのデータを見て、自ら要件定義をしているので、スムーズに行くことが多いです。ぼくはデータを見るのが大嫌いですが、そのおかげで自分の開発に自信が持てて、開発がより楽しくなるなと感じます。サウナ後のビールみたいな。やっぱり作るなら価値あるものを作りたいですよね。

7. 2 に戻る

あとは 2 - 6 をぐるぐる回して目標を達成します！

まとめ

ここに書いたのは一例で、1, 2 週間で終わる改善もあれば、半年以上かかるものもあります。それでもエッセンスは変わりません。DSOC サービスの多くは、GEES の QCDS のように数字で評価することができます。そのため、開発時から「数値」と「データ」にこだわって、日々エンジニアリングをしています。