続いては動画本数世界ナンバーワンのレシピ動画サービス「Kurashiru」を中心に様々な事業を展開するdely株式会社の辻様にご登壇いただきました。

テーマは「20年のエンジニアキャリアから、データサイエンティストになって1年で学んだこと」です。

最初に会社の説明をして頂きました。

こちらに記載されているダウンロード数はさらに100万増え現在1600万だそうです。動画レシピサイトでは国内外でナンバーワンですね。

自己紹介

続いては自己紹介です。辻様はキャリアの出発点は金融系メインフレームでCOBOLエンジニアを新卒から7年携わり、オープンソースとは無縁でJavaも知らず過ごしました。しかし「このままではいけない！」との思いからキャリアチエンジを図ります。SIerとしてJavaやPHPメイン基幹システム構築を4年過ごしました。

その後、toC向けサービスでサーバサイドとアプリ開発を7年行います。そして昨年、dely株式会社に入社しました。CTOと最初に面談した時にフェルマー（フランスの数学者）の話で盛り上がり気に入られ入社したそうです。数学を趣味とする辻様らしいエピソードです。

なぜデータサイエンティストに？

一昨年に入社したということは、上記の経歴からデータサイエンティストとしては未経験ということがわかります。なぜデータサイエンティストになったのでしょう。これについて４点挙げられました。

• サービスの成長にはデータ分析が必須だと身に沁みる

• 民主化の流れ

• エンジニアキャリアを活かす

• 数式の傍らで仕事したい

アプリ開発時にデータ分析をやらざるを得ない状況があり、その中で統計的な勉強もしてサービスの成長にはデータ分析は必要とのこと。民主化の流れについては、機械学習の論文を読まないとできない部分はAWS SageMaker等使うことによって自分でできるようになった点が大きいと話しています。また趣味である数学を活かし数式の傍らで仕事がしたいという点で、ニーズが一致したそうです。

事業会社に必要なデータサイエンス　1  

Data-Driven

事業会社に必要なデータサイエンスを３つ挙げられ、まずはData-Drivenについてお話し頂きました。ちなみにData-Drivenとは集計したデータを総合的に分析し、未来予測・意思決定・企画立案などに役立てることです。

データの活用に対し集計したものを可視化するのが一般的です。しかし辻様は、集計して、増えた減ったことに一喜一憂せず、またダッシュボードを作って達成した気にならないよう指摘しています。大事なことは「未来の価値に繋げる」だそうです。ではその未来の価値とは何でしょう？

下記の図をご覧ください。

シンプルでわかりやすいですね。さらに上記の「現状の把握」部分に関し、補足として辻様の言葉を引用します。

辻様：レシピの情報とユーザーの情報で二面性があると思いますが、まずはレシピがどういう状態にあるのか？　和食や洋食、それがどのような成分なのか？　分布をきっちり把握して課題を局所化して何を解決したいのか明確化します。そこに関わるデータの相関や因子を知ることによって現状をつぶさに理解していきます。これを行うためにEDA Scrum（後述）があります。未来の価値はこれらに基づきます。

「未来の価値」について「ユーザビリティ向上」「プロダクト向上」はユーザーに歩み寄っていく、「コンテンツ向上」に関しては画像と動画の分析をして良かった点に対し再現性を持って提供し、「ビジネスサポート」はビジネスサイドの資料のサポートとして統計的なデータに基づき提供することだそうです。転換に関する詳細は後述します。

続いてData-Drivenに対し「効果を焦りすぎない」ことに言及し、それに対しどのように対処するかお話して頂きました。

定量的な分析結果で課題を共通認識する

・サンプルサイズの算出方法を社内共有+推定値の自動算出

ABテストを行う場合、「サンプルサイズはどのくらいにするか？」となり、これをサンプルサイズの算出方法に基づいて社内で共有したとのこと。推定値を自動算出するアプリは辻様自身で作ったそうです。

・分析基盤の構築+運用（コスト面）+改善

コスト面や速度面の改善とかパイプラインを作ったりしてより使いやすくしていたそうです。

他には統計学、多変量解析の実践方法を社内にレクチャーし、SQL勉強会の不定期開催を行なったそうです。

AIはなんでも解決できる魔法の箱ではない

これに対し、下記を挙げていました。

• AIは答えを出してくれるが理由をちゃんと教えてくれない

• 定性的判断は人間が下した方が精度がいい

• 精度のプライオリティ判断

• 10000件程度のタグ付けなら人海戦術

人海戦術に対し、辻様の言葉を引用します。機械学習に依存しない辻様の姿勢が伺われます。

辻様：弊社のデータはユーザー投稿型のデータではなく管理栄養士さんが計画を立て作成しています。約３万レシピあり、そのレシピの中で新しいレシピの情報を付与したい場合、１万件ぐらいのレシピだったら社内で頑張って人海戦術でそれに対して推論していくような形でアプローチしています。ユーザー投稿型のデータで３００万とか４００万とかのデータだとできないアプローチです。弊社でハンドリングできるデータだからこそ、できるものだと思っています。

今できていること+α

・機能、非機能共に今のサービスレベルを損なわないのが大前提

上記を前提に機械学習を小さく導入しているそうです。

・最終的に実現したいことにみんな巻き込む

以上が「効果を焦りすぎない」為の対処法です。

次にData-Drivenに対するイベントデザイン・ファーストについてお話して頂きました。図をご覧ください。

より理解を深めるために辻様の説明を全文掲載します。文頭に出てくる「リーン」とは英語の「Lean」で「痩せた、無駄のない」と意味です。アジャイルと比べ「小さなこと」を回す意味で使われています。

辻様：弊社はリーンプロダクトと呼ばれる手法で開発を進め、デザインフェーズを重点的に回しています。一般的なアジャイル開発でいうとお客さんに成果物を出して評価を仰ぎますが、社内で使っているユーザーがこの機能を公開して有用なのか？　しっかりと検証することから始まります。検証してプロダクトオーナーが「これを出そう」となったらそこから実際のUI設計に入り、その時に「ユーザーがどういう行動をとったか」というイベントの設計をします。あらかじめ評価指標を決め、実際にリリースした時に評価指標を上回っていたら有用で、下回っていたら有用ではなかったとなります。

それからリリースしてイベントログを取り、その中で大事になってくることが、過去に作った機能のファネル（ユーザー数が絞り込まれていく様子）に対してそれがトラフィックバランスに大きな乱れ、影響がないか、増減がないかチエックします。例えばこの評価指標で良い結果が得られたのでこの機能が良いと判断しますが、一方で過去の機能に対して何かネガティブな影響が出ていれば、トレードオフになります。つまり今がいいから進めるというわけではなく、過去も検証してから次に進むという方法を取っています。

辻様の説明を読んでから、もう一度図を見て頂くとよりわかりやすくなると思います。

事業会社に必要なデータサイエンス　2

ETL Eco System

Data-Drivenに続く事業会社に必要なデータサイエンスとしてETL Eco Systemを説明して頂きました。

ETLとはExtract（抽出）・Transform（変換）・Load（書き出し）の略です。データウェアハウスにおける工程を指します。まずは今までのMLエンジニアとこれからのエンジニアの違いについて説明して頂きました。

今までのMLエンジニアはエンジニアリング、機械学習、統計、ディープランニングであり最先端の技術の詳細なところまで理解していないとできないものだったとのこと。しかし現在、民主化の流れでAutoMLが登場し、昔に比べ楽になったそうです。これからのエンジニアは周辺部分、データエンジニアリングやインフラストラクチャー、サービスアーキテクチャなど総合的に理解して実現していかなければならないそうです。

柔軟性の高い設計とは?

次にETL Eco Systemに対する柔軟性の高い設計についてです。これからのエンジニアに課せられるのは柔軟性が高い設計とのこと。MLのパイプラインの文脈で発生する不確実性があり、クラスタリング結果が非決定的でサイズがバラバラなので、そのあとの処理でインスタンスの最適化を行わなければならないそうです。

柔軟性の高い設計=代替提案が可能

柔軟性の高い設計とは代替可能にします。これに対し、フィードバックループのワークフローという循環を作ってみます。データはイベントに合わせ集め、集めたもの対しアドホックにSQLを叩きまくりデータを取っていくとのこと。

最初は精度を気にせずに、このループをとにかく回すそうです。下記の図をご覧ください。

ワークフローの循環を優先する

リソースコストの低減

次にリソースコストの低減についてです。

ETL Eco Systemを作ると今までMLエンジニアがしなければならなかったMLの部分とサービス、運用部分のマネージングが楽になるとのこと。その圧縮されたコストをEDA分析の拡充に当てることができるそうです。

事業会社に必要なデータサイエンス　3

EDA Scrum

次にETL Eco Systeに続く事業会社に必要なデータサイエンスとしてEDA Scrumを説明して頂きました。

EDAとはExploratory Data Analysis（探索的データ解析）の略です。

成果の見える化

データサイエンスは端から「いったい何をしているのか？」と思われ、成果が見えづらい職務です。そこで、２週間ごとに分析結果を提出してライブラリー化することで見えるか化したとのこと。これにはふたつのメリットがあり他の人が過去に行った同じ分析を再びしなくて済み、多部署から分析依頼を受けた時に過去の調査結果を参照でき、得られた気づきを次のEDAに活かせるそうです。

サーベイチャレンジ

サーベイチャレンジに関しては辻様の言葉を引用します。

辻様：弊社のサーベイチャレンジは、ディープラーニングや機械学習に対するサーベイというよりは、食メディアに関する論文を社内で読み、それに対してgoodタグとbadタグをつけていきます。goodタグがいくつか貯まったらそれに対して社内で議論し、デモコードに落として事象を検証します。機械学習のエンジニアは私のみなので、データサイエンティストチームという形で検索エンジニアと2人で行なっています。分析力の評価や統計的な視点を広げ、手法を学んでます。それをGithubのissueで管理し落合陽一先生のフォーマットでUPしています。Slackから通知が来てgoodが貯まり次第二人（データサイエンティストチーム）で読み合わせます。

ETL x EDAサイクル

こちらも辻様の言葉を引用しました。

辻様：ETLとEDAは、相関的な関係があると思います。レベル１はアドホック分析だけでSQLを何度も叩きます。レベル2はスクリプトでバッチをトランスフォームして可視化します。そして実際にモデルを作りトレーニングのデータセットに落とす段階になりましたらレベル３でパイプラインに乗せてバッチを行い、レポートの報告やデータセットを作っています。

オンラインでは１時間前のデータを使用し、例えばレコメンドの新規性の高いユーザーは、たった今お気に入りしたものは見たくない傾向がありますので、ストリーミングでリアクティブなパイプラインを作りプロダクションに反映しています。これら、ユーザーのフィードバックを得ながら回していきます。下記の図をご覧ください。

以上です。

最後に辻様から告知がありました。

辻様：sagemaker-jugコミュニティslackをKIKONIA WORKSの方と作成しました。ご興味のある方は入ってください。こAWS様も参加しているので何か質問すると回答が得られます。ぜひ入ってください。ご静聴いただきありがとうございました。

最後に質問タイムに移ります。会場の皆様からの質問に対し、時間の許す限り応えて頂きました。

質問タイム

サービスの成長には「データ分析が必須だ」と感じたのですか？

大きくは再現性を持った取り組みを行えるかどうかが大事かと思っています。弊社でも定性的にこの取り組みをする際、必ずエビデンスを取り「効果があったのかどうか」判断し、効果があれば進める、効果がなければ取りやめます。

このテストドリブンのような感じで進めることによって、不確実性に対処でき、どこかで間違えた時に戻れなくなるリスクは避けられます。あとは「データを活用していく」という意味で言うと、例えばユーザー様の行動ログやレシピの情報を双方向から活用することによって、そのユーザー様の嗜好性から「先週何を食べたから今週何を食べたいのか」推定できます。そういう面ではデータの分析は必須なのかなと感じています。

社外データの不足で困った経験がありますか？

データは自前（弊社）で作成していますので不足することは、ほぼありません。知見のある管理栄養士にタグをつけてもらえますので、他の会社に比べるとかなり恵まれていると感じます。

この後トークセッションもございますので、引き続きお楽しみください。