【前編】６社の事例から学ぶ──ユーザー体験を磨き、サービスを支える技術力とは？

イベント公開日: 2020/04/15

ブックマーク

#機械学習, #データ分析, #Fintech, #人工知能, #ビッグデータ

2019年12月1日、仙台市が推進する「SENDAI X-TECH Innovation Project」の一つとして、FiNC Technologies、SHOWROOM、Liquid、ティー・アール・イー、スマートニュース、Retty Innovation Labの技術事例勉強会が開催された。

今回は、モデレーターに及川卓也氏を迎え、テクノロジーで業界の未来を変えるサービスを作っている各社サービス開発の技術基盤について語り合っていただいた。本レポートでは、当日のイベント前半に行われたFiNC Technologies、SHOWROOM、Liquidの技術事例を紹介する。

FiNCアプリを継続率を支えるMLの取り組み

最初に登壇したのは、FiNC Technologies 代表取締役CTO（現：代表取締役 CEO）の南野充則氏。FiNCは、ヘルスケア×テクノロジーで予防医療の課題を解決することに特化している会社。ビジョンは、一生に一度のかけがえのない人生の成功をサポートすることを掲げている。

▲株式会社FiNC Technologies　代表取締役CTO　南野充則氏

寝たきりになる原因の約80％は、脳卒中や認知症、衰弱、骨折、関節疾患など。その前には身体機能の低下も挙げられる。その根元を探ると、生活習慣の乱れによる栄養・運動・休養などの不足などに課題がある。FiNCはそれらに対し、すべての人にパーソナルAIというイシューを掲げ、解決すべく取り組んでいる。

FiNCは、2012年4月にもともとパーソナルトレーナーだった創業者の溝口氏が創業し、現在の社員数は約250名、東京の有楽町にオフィスをかまえる。創業時はオンラインで管理栄養士が個人の栄養指導する「FiNCダイエット家庭教師」の立ち上げやパーソナルトレーニングジム「FiNC Fit」など個人指導した管理栄養士・トレーナーのノウハウをスマートフォンを使ってアプリで展開できればと考え、現在では850万ダウンロードされている。

FiNCアプリですべての人にパーソナルAIを届けたい

FiNCアプリには、データを収集する機能と、そのデータを通じてアドバイスを送る機能がある。具体的にはライフログ（歩数・体重・食事・睡眠など）、管理機能、ミッション機能（ライフログをもとにトレーニングプログラムを作る）、AIチャット＆ポイント（チャットで会話やアドバイスをしてくれる）、パーソナライズされたアドバイスするという機能を提供しており、iOS・Androidともにヘルスケア（健康）/フィットネスカテゴリーで、ダウンロード数も1位を獲得している。

FiNCでのMachine learning、Deep learningプロジェクト

FiNCではMachine learning、Deep learning（以下、MLDL）を活用し、管理栄養士やトレーナー等がやっていることをFiNCアプリに標準化する取り組みを行っている。例えば、管理栄養士ならお客様が摂取した食事の画像をみる・悩みを聞く、トレーナーなら鍛えたい部位や体形をみたり、悩みを聞く。それに応じて問題点を見つけて、その人に合った適切なアドバイスをするといった具合だ。

また、現在のヘルスケア業界の一番大きい課題として挙げられるのは、継続のできない人が多いこと。健康診断に行って、結果を見て改善しようと頑張ろうとするものの、1～2カ月で挫折してしまう人が多いのだ。

そこにはお金・時間・場所などの制約があったり、管理栄養士やトレーナーの属人化された指導方法が自分に合わないとうまくいかなかったりする。もう一つは自分が決めたことをなかなか継続的に実行できないこと。この3つの問題を解決するために、管理栄養士やトレーナーの知識・ノウハウを汎用化し、お金・時間・場所の制約をなくすためのプロジェクトにMLDLを活用している。

FiNCでは、MLDLのプロジェクトを進めるために、3つの指針を作り自動化している。

1.アドバイスの最適化・レコメンド・アドバイスプロジェクト 2.記録にかかる時間の短縮・食事画像認識プロジェクト・睡眠時間予測プロジェクト 3.専門家のやっていることを代替・食事カロリー推定プロジェクト・姿勢分析プロジェクト

例えば「睡眠時間予測プロジェクト」では、AIによって睡眠時間を推定し、自動入力できるようにすることで、記録にかける時間を短縮する機能をリリース。この機能を導入したことによって、睡眠時間記録率が2.5倍にアップした。

「食事画像認識プロジェクト」では、1日3食の写真を撮れば、その画像からメニューが検知されてアドバイスが表示される機能を開発。姿勢分析プロジェクトでは、姿勢のゆがみを計測し、それを正す支援ツールを提供している。

CTO直下で進めるFiNCのプロジェクト体制

FiNCのプロジェクトは、全てCTO直下で行われている。理由は以下の3つが挙げられた。

１. 決済権限がある
　　└ 予定通りに開発が進むわけではないので、予算が読めない
２. プロジェクトのインパクトがわかる
　　└ 経営目線でどこに投資をすればいいかわかる必要がある
３. 技術もプロダクトもわかる
　　└ どちらかが欠けた状態でのAIプロジェクトの推進は不可能

南野氏は、このプロジェクトをやっている中で得た教訓が3つあるという。それは「評価方法の決定からはじめよ」「オペレーションは自社で構築しよう」「MLとDLは　ソフトウェアエンジニアから輩出するべき」。特に大事なのは、評価指標をしっかり決めることであり、最初にアウトプットを決めるべきだと南野氏は語る。

その理由は以下が挙げられた。

AIを使うと何かできるという過度な期待を持ってしまう
プロジェクトの目的が曖昧になってしまう
学習データと作成モデルだけにフォーカスしてしまう傾向がある

さらに、評価するためのデータは学習データ以上に重要だという。評価データが決まれば、評価の仕方が決まり、ゴールが明確になる。目的が曖昧になる状況を防ぐことができるというわけだ。

オペレーションは自社で構築せよ

ディープラーニングの仕事の8割はデータの成形だったりと、泥臭い仕事が多い。例えば食事の画像を切り取り、何の食事なのかを判別しラベル付けしていく。面倒ではあるが、データセットの質が一番大事で、それがちゃんとしていないと成果が出ない。質を担保するためにも、評価手法を理解して、細かいオペレーションを作る必要がある。

同社でも外注してみたところ、データが使えなかった事例があったという。スケールして仕組みがしっかりしてくれば外注しても大丈夫だが、プロジェクトの最初はしっかり自社で作るべきだと、南野氏は強調する。

また、「ディープラーニングやマシンラーニング（DL/ML）人材はソフトウェアエンジニアから輩出するべきだと思っている」と、南野氏。データを集めるためにはアプリケーションが必要だが、エンジニアでないと、そのアプリケーションが作れないため、当事者意識が欠けることがあり、結局プロジェクトが前に進まないからだと語る。

スタートアップで人員が足りない中で、少ない人数で進めていく必要がある。そこで、FiNCの方針は以下が挙げられた。

DL/機械学習に精通している人材は少人数で確保
主にサーバーサイドエンジニアにDL/MLスキルを付加していく方針
自社のカリキュラムを作成、改善中

FiNCのカリキュラムとしてはシンプルで、OJTを行いながら、地道に「ソフトウェア×ML/DLエンジニア」の育成を行っている。

ML/DL周り全般の知識のキャッチアップ
解きたいタスクの専門知識のキャッチアップ
実験のための環境構築のキャッチアップ
OSSの再現実験
OSSを自前のデータセットに適用
論文のモデルを作成できるようになる

ソーシャルライブ配信サービス「SHOWROOM」を支える技術

続いて登壇したのは、SHOWROOMのCTO佐々木康伸氏。SHOWROOMは「努力がフェアに報われる世界を創る」をミッションに、“エンターテインメント×テクノロジー”で世界中に夢中を届けるをビジョンに掲げている。

▲SHOWROOM株式会社 CTO　佐々木康伸氏

同社が提供するライブ配信サービス「SHOWROOM」では、誰でも無料でライブ配信と視聴することができ、夢を叶えたい人と、それを応援したい人が集まる新しいエンターテインメントの形を生み出している。「夢を叶えたい」にフォーカスしてサービスを提供しており、芸能人が登竜門的に活用することも多い。

SHOWROOMのサービスには、大きく以下のような3つの特徴がある。サービスの特徴に合わせてアーキテクチャも分かれており、ソーシャルゲームに近いシステム構造になっている。コミュニティ要素に関しては、SNSと近いWebのスタンダートな技術構成だ。

ライブ動画で、リアルタイム重視の作り（アーカイブではなく、生配信にこだわる）
ギフティングと呼ばれるアイテム課金（収益の中心）
濃いコミュニティ形成 SNS要素（配信者とユーザー、ファンのつながりをつくる）

ライブ動画の配信は , Perlがメインで動いており、オンプレミスを使っている。だが最近は、新機能に合わせて最新技術を使ったり、マイクロサービスにしてアーキテクチャを分けたりしているという。

3年前からライブコマースの機能を追加し、ライブ配信中に販売をするECシステムとして活用している。Goを使うという選択肢もあったが、Scalaが得意な人間が社内にいたため、Scalaを採用した。

ELBやAWSの機能も活用して、インフラ構築したところ、かなり手間や作業が減ってよかったと佐々木氏。最近ようやく落ち着いてきたので、Vチューバー向けの事業を開始。「立ち上げメンバーがいなかったので、一人で立ち上げました」と笑う。

コメントやギフティングは、Webに一旦投げて、q4mを使い、非同期処理を行う。閾値を設け1秒間に70～100くらいのコメントが捌いている。、乃木坂46やバーチャルジャニーズなどのトップコンテンツのギフティングも問題なく捌けているのだそうだ。

動画の配信サーバーは一部クラウドを使っており、WOWZAというライブ配信に必要な機能を備えたサーバー、配信系のプロトコルはRTMPを採用している。配信者側はOrigin、視聴者側とは異なってつながるサーバーを使用。オートスケールが必要となるため、「急なトラフィックがあったり、時間帯によって視聴者の数が変わるタイミングなどで、インスタンスの上げ下げができるようにしたい」と佐々木氏は語る。

ライブ配信サービスのコストは、トラフィックだけで9割。水平に広げられるようにShading（シャーリング）している。大規模配信向けにCDNも入れている。超低遅延実現のため、WOWZAから自前のストリーミングサーバーにリプレイスを進めている。

最後に佐々木氏は、新配信サーバーの性能について、HLSで5～6秒の遅延が今は0.5秒くらいになっていると、Before、Afeterでその効果を紹介した。

Liquidの画像認識技術を支える評価基盤とは

前半ラストに登壇したのは、Liquid 取締役 CTOの大岩良行氏。大学時代に高速画像処理を研究し、LiquidではCTOであるものの技術全般を見るというよりは画像処理チームをリードしていると自己紹介した。

Liquidは指紋や顔の生体認証技術を用いて、世の中の様々な認証を安全で簡単に便利にするサービスを開発。これまでテーマパークやホテルにおける決済手段やチェックインの仕組み、ATMの認証など、各種アクセスコントロールのサービスを中心に提供してきた。現在は各種オンライン取引を注力している。

▲株式会社Liquid 取締役 CTO　大岩良行氏

同社が提供するのは生体認証技術サービス「LIQUID eKYC」。eKYCとは、electronic Know Your Customerの略語で、本人確認手続きをオンラインで完結する仕組みだ。金融機関の口座開設などで使われている。

eKYCが解決する課題として挙げられたのは、口座開設など本人確認に関するプロセスの不便さを削減すること。従来、銀行の口座を開設するためには窓口に行くか、本人限定受け取り郵便による住所確認が必要だった。そのため、平日に手続きに行けない会社員には不便極まりなかった。

本人確認をオンラインで完結してもよいという法改正もあり、顔と顔写真があるIDカード（免許証など）を撮影し、偽の画像ではないことを確認する事で銀行講座などが開けるサービスを提供。写真が偽物じゃないことを証明するために、撮影時にアクションを入れてもらうことを促すツールやその画面、Webブラウザでカメラが起動する仕組み、審査する管理画面も開発している。

ユーザーの利便性を上げるだけではなく、銀行や証券会社といった審査する側もローコストかつ、リアルタイムに認証が行える。撮影した画像を利用して、顔認証によるログインやパスワードを忘れた際に、もう一回スマホを通じて認証することによって、なりすましを防止した再登録を行うことができる。

「災害時に身元を示すカードがなくなってしまったときでも、登録されているデータが紐づいて、避難所で自分を証明することができる未来を実現したい」と大岩氏は目を輝かせる。そのためには、セキュリティを保ったまま、簡単・便利に使ってもらえるような画像処理アルゴリズムを開発する必要がある。

そのような画像処理アルゴリズムを評価する際に、一番大きな課題になってくるのが様々な種類の画像データの認証だ。画像なので毎回インプットが違うし、性別・人種・年齢・化粧や髪型による変化、照明環境や顔の向きなどの撮影状況やスマホの機種、ソフトウェアの種類などによっても変わってくる。

実際にデータセットによってどれだけ違うのか。とある顔認証モデルを2つの顔画像データセットで評価してみると、Accuracy（正確さ）が99.6％と92.6％となった。50％ものリサーチャーが自分自身の実験の再現に失敗しているという。

Liquidでは、2つのツール「mlflow tracking」と「dvc」を使って再現可能な実験ログを取り、評価情報を集約している。「mlflowとdvcの導入により、複数のデータセットでの結果一覧が見えやすくなり、追加実験がしやすくなった」と、大岩氏は語る。

一方で、メモ（Run Name）を書かずに実験を繰り返すと、途中でわからなくなるという問題もある。評価軸をどう設定するか、データセットをどう集めるかはエンジニア・リサーチャーに求められていると、セッションを締めくくった。

【パネルディスカッション】サービスを支える技術力と人材とは

続いてのパネルディスカッションでは、及川卓也氏をモデレータに迎え、「ユーザー体験を磨き続けるサービスを支える技術力」をテーマにFiNC南野氏、SHOWROOM佐々木氏、Liquid大岩氏が語り合った。

及川：南野さんには、「MLDLはソフトウェア人材を活用している」「オペレーションはまず自社でちゃんとやった方がいい」というポイントで伺いたいと思います。まずはFiNCの中の人、開発をしてる人たちはどんな方々なんですか？

南野：開発人材はプロジェクトをベースに、横串しで職能ベースに人材を分けています。弊社はアプリケーションを作っているので、iOSやAndroidのクライアントのエンジニアチームとサーバーチーム、機械学習チーム、それの上にインフラチームがあります。主に5チームが横串しであります。そこにプロジェクトがあり、各プロジェクトにチームメンバーがそれぞれ配置される形になります。

ディープラーニングやマシンラーニングをやっている人は、主に結構ソフトウェア作ってきた人が多いですね。大学時代にマシンラーニングやディープラーニングを研究していた人や、物理学をやってきた人で、現在はアプリケーションの開発をしている。次のキャリアでディープラーニングやマシンラーニングをやってみたいという人がチームの中心となっています。

及川：何か一つの専門性を深掘りするより、いろんなことをやりたい方が多いのですか？

南野：そうですね。幅広くやっていきたいという人が多いですね。でも、ディープラーニングとかやりませんという人もいるので、プロジェクトベースで先生に教えてもらいながら進めています。

及川：面白いキャリアの人はいます？そもそも南野さん自身が情報系じゃないですよね？

南野：僕はシステム創成学科で、理系の人がどう技術経営していくといいのかを技術とともに学ぶ学部でした。FiNCで面白い経歴なのは、お寿司屋さんで配達をしていたという人がいました。お店で料理の写真を撮って、その画像をアップしたときに、このアプリってすごい！アプリを作りたいと思ったそうです。いきなりプロダクトを作っている会社には行けなかったらしく、最初はSIに行って勉強して、それからFiNCに来てくれた方がいます。

及川：佐々木さんのお話でSHOWROOMの裏側というか、衝撃だったのは開発言語がPerl だったという点ですね。例えばPerlから始まり、マイクロサービスアーキテクチャになっていくところで、技術や言語が変わっていく。すごく変化が激しいですよね。

Web系の技術を使えるところと、リアルタイム系の技術は違うところ、変化も激しいし、多様な領域や技術が必要とされると思いますが、どんな人たちが開発しているんですか？

佐々木：技術が好きなんだけど、こだわりというか、この技術だけをやりたいという人はいないですね。それよりはサービスや事業に関心が高い人を採用するようにしています。特定の言語にこだわりすぎる人はミスマッチになってしまう。事業をやっていく中では、どうしても優先度が落ちてしまうし、そこが最優先でないところが特徴ですね。

及川：SHOWROOMのように巨大で、日本でも最先端サービスを支えるのは、技術面でもかなりのレベルが求められると思うのですが、その経営視点や事業への関心の2つを持っている人材って、どういう人たちなんですか？

佐々木：うちの社員はオタクが多いんですよ。乃木坂46、AKB48などのアイドルオタクやYouTuber、Vチューバー好きとか。Twitterのアイコンもみんな美少女になってるんじゃないかな。社内のSlackのアイコンも美少女化しています(笑)。やっぱり、好きっていうことは大事ですね。それがやりやすい事業体でもあるので、サービスやアイドルが好きという理由で来てくれてる人はいます。

及川：たしかに人材を集めるときに、事業に対する共感は非常に大事だと感じます。ものによってはそれが難しい領域もありますが。SHOWROOMを支えている方たちは、みんなSHOWROOMの世界観が好きだということですね。

佐々木：そうですね。SHOWROOMのコンテンツが好きというか、ひとことで表すと、明るいオタクです(笑)。

及川：Liquidは他の2社と違い、どちらかというと要素技術、専門性を高め、深堀していく会社だという印象を持ちました。その方たちは、どんな人なのかを知りたいです。

大岩：eKYCには、わかりにくい面が多々あります。一方で指紋だけで支払いができたり、わかりやすい面はビジネスとしてスケールしていない状況。その中でビジネスとして両立する道を探しながら、人が均等なインターネットにつながるような世界を目指しているところです。どんな人かは、ひとことで言うと攻殻機動隊が好きな人(笑)。

LiquidでeKYCの評価基盤を作っている人たちは、もともと大学での研究でここに繋げたいという思いがある人が多いですね。面白い経歴では、SIerを経て、スパコンの会社に入り、専任海外協力隊で2年間ボランティアをした後に、うちに入ってくれた人がいます。

及川：eKYCはtoB的なところも多く、かつ、保守的な金融機関がメインクライアントで、その先には実際にユーザーがいるという点では、難しさはありませんか？

大岩：eKYCの話をいきなりして、共感してもらうのは正直難しいですね。そこで、登録したパスワードを忘れても大丈夫な世界や、海外でパスポートがなくなっても安心な世界を目指しているという、ちょっと抽象的な話をするんですね。その未来像に共感してくれるエンジニアは、それなりにいると思ってます。

及川：FiNCのマシンラーニングforヘルスの取り組みでは、特にその再編成が重要であったり、属人的なものを排除しなければということでした。とはいえ、どうしてもその人にしかできない、例えば画像認識など、属人的な要素技術だと思います。その属人的な要素とは、どこまで外すことを求めるべきだと考えているのか聞かせてください。

南野：実際の評価において、何の値を評価ポイントにするかですが、属人化から抜けれることはあまりないと考えています。

及川：それは正解がない世界において、誰かが「こうやりたい」という思いがなければやっていけないということですか？

南野：僕はそう信じています。ただその上で、ある意味初歩的なところであったり、労力がかかりすぎるところは、属人化から自動化につなげていきたい。それが、我々がやるべきことなのかなと思っています。

及川：SHOWROOMは、属人性という点で何か問題が発生していたり、何か工夫しているところはありますか？

佐々木：動画関連の開発ができる人材はまだあまりいないので、そこは常々属人化しています。ただ自社内だけで解決させないという取り組みはあります。今は副業とかできる時代になっているので、会社を辞めた人とも、なるべく協力関係を続けていたり。

及川：FiNCは創業時のミッションが、トレーナーの属人化を排除しようというもので、それをものづくりにも実践しているんですよね。何か工夫しているところはありますか？

南野：例えばその人が抜けてしまった瞬間、事業が滞ってしまうのは経営としてリスクがあります。機能ごとに属人化はしょうがないと今はあきらめる部分と、ここだけは属人化しないという部分を分けて考えるようにしていますね。

属人化したくないところは、チームにノウハウを投げていく体制にして、一人ではなく、2～3人体制にして、キャッチアップ力が高そうな若手を輩出することによって、その成長にも寄与する開発体制をつくろうという方針でやっています。

及川：スピードを重視するならば、ある程度の属人性は避けられない。正解がない世界において、万人が正解だとするものを求めるのは不可能であり、その人だけに頼らざるを得ないこともある。ただ一方で、最低限その人がいなくなっても事業の継続が可能であることが、人材の配置においては必要なのかなと感じました。

変化に対応し、スピードを支える技術選定はどうしてる？

及川：続いては、技術選定を行う場合について、もう少し伺いたいます。皆さんは、変化についていくスピードを支える技術をどう選ばれているのか。

FiNCの場合は、CTO直下体制で意思決定を早くするところがあったと思います。SHOWROOMは、もしかしたらある程度捨てることをいとわないところにあるのかと。Liquidは事業のニーズに合わせて、作るものや使う技術も変わってきているのではないでしょうか。

そうした変化に対応するためには、どのような技術選定を行い、開発プロセスなどで工夫していますか？

大岩：我々は金融機関と仕事をすることになるので、セキュアルームからのみできる形式を最初に作る必要がありました。eKYCというサービスでアーキテクチャ作りで一番苦労したのは、そのセキュアルームからしかリプレイができない環境にし、本番データの確認や、本番データで用いた学習基盤を執務室からは触れないようにしなければならないことでした。

幸いAWSで動かすことは可能だったので、機械学習においても、本番データを用いて学習していくものはAWSで実行できるようにしました。セキュアルームという制約の中で、どうスピードをつけるかという点では、そのような対応をしていました。

及川：要はスピードダウンしてしまう要素があるにも関わらず、セキュアルームでも、クラウドを活用してスピーディに動けるやり方を実践しているということですね。

SHOWROOMでもセンシティブなデータや画像などがあると思いますが、そこでの技術的な工夫は何かありましたか？

佐々木：あります。ただどちらかというと、個人情報の方がセンシティブです。クラウドで扱えるものと扱えないものを分けていますね。

及川：それは一つのポイントですね。元DeNAさんだったということもあり、オンプレをメインに使いながらも、クラウドもハイブリッドで活用していると。それはセキュアにしたい部分と、スピード重視の部分で使い分けしているんですか？

佐々木：商品サービス系はクラウドですが、個人情報系はオンプレのDBで保存するようにしています。

及川：FiNCはヘルスビジネスなので、センシティブなデータがユーザーから集まってくると思います。そういったものを扱いながら、変化の早さに対してはどう工夫していますか？

南野：個人情報の管理が一番のリスクですね。個人情報が不要な設計にするといったことは意識しています。

及川：アプリの新機能を社内で試すときのデータは、リアルなデータを使うことがあるんですか？

南野：本番環境と準本番環境を作っています。本番環境に近くないと試せないことが多いので、匿名化やマスクした環境を作ったりしています。あとはクラウド上であまり直接たたかないようにしたりとか。あまり本番環境に入らなくても試せ、誰でもできるようにしています。万が一の場合、何かが流出したときはあとから追えるようにログをデフラグしていますので、そこはしっかりやっています。

及川：先ほどSHOWROOM佐々木さんから、捨てることをいとわないという話がありましたが、技術者サイドからいうと、自分が書いたコードが消されることに対して、抵抗感とか悲しみを覚える方はとても多いですよね。そうしたエンジニアの葛藤をどう克服されているか教えてください。

南野：うちの会社もスピード重視なので、意思決定することも多々あるんですけど、うちのエンジニアは2つのタイプに分かれます。一つは事業推進派タイプで、もう一つは職人肌タイプ。職人肌タイプはいないと困るので大切にしているんですけど、検査の設計ができてないという場合は僕が介入します。経営的にもここのスピードを早く実証することが、後の投資効率が上がるので、我慢してやってほしいとお願いすることが多いですね。

佐々木：僕らは技術者的視点だけじゃなくて、ビジネス的な視点でジャッジをすることが多い。ロジックが通っていれば、エンジニアも納得することが多いので、きちんと説明するようにしています。

及川：エンジニアが上流工程に関わることもあるんですか？

佐々木：結構あります。最初からビジネス的な話をして決めるというケースが多いですね。

及川：それは大事ですね。自分も意思決定しているので、うまくいかなかったとしても納得できますよね。

Liquidは、最初のモデル評価を客観的に見た結果、使えないということが見えてくる場合もあると思うのですが、評価が明白だとしたら、皆さんのあきらめは早いんですか？

大岩：モデルに関しては全く問題がないです。ただ、POCをやる過程において、相手都合でできなくなるケースもあります。その場合は、こんな世界を描けるというモチベーションで作ってきたけど、企業の戦略でできないと説明しても、葛藤が解決しきれてないこともありますね。

及川：そうしたケースは、エンジニアリングの文化みたいなものも大事だったりしますよね。組織によっては普通に壊される、壊せること前提にしているクラウドのフィロソフィーみたいな。同じように、コードというのは書いたものに価値があるんじゃなくて、使われるものに価値がある。そう割り切れると、書いたものに対するこだわりって、どんどん薄くなっていくんじゃないかと。そういったことも大事だったりしますか？

大岩：我々はよく複数タイプを作って壊すのはやってます。モデルももちろん何度も変えます。それは壊すことが前提なので大丈夫ですが、これでいけると踏んで、しっかり作っていたところに関してはやはり少しあるのかなと。

及川：文化という点で何か工夫されてますか？

南野：僕たちの事業はアプリの継続率に終始注力しているので、自分の書いたコードが継続率にどれだけインパクトがあったのか、全員で考えるようにしています。OKRの評価設定などにも入れたりして、全員が意識できるようにしています。

佐々木：文化として気をつけているのは、プロダクトの意思決定に関してはビジネス側とプロダクト側で決めること。ビジネスと寄り添ってチームを育てるカルチャーというか、そのつながりについては、なるべく意識するようにしています。

及川：機械学習に関して、データセットやダッシュボードで評価を可視化して見える化することは重要です。その事業価値は評価、例えばコードを捨てるということに関しても、意思決定していくことになると思いますが、プロダクト開発において意思決定するときの評価軸はどこに置いているんですか？

佐々木：エンタメに関しては売上です。エンタメだからこそ、売上にこだわっています。エンタメって社会性が薄いし、よく悪くも自己満足になりがち。そこはすごく評価軸としては大切にしていることですね。