機械学習エンジニアが研究開発とサービス開発の違いを考えてみた

この記事は [フォトクリエイト Advent Calendar 2019](https://qiita.com/advent-calendar/2019/photocreate)  の 8日目の記事になります。

はじめまして！
Qiita初投稿の @ryosuke_3110 です。

## 内容
タイトルそのままなのですが、**アルゴリズムで殴り合う研究開発案件**に2年半ほど従事した私が、今年の8月にフォトクリエイト社に転職し、**機械学習をサービスに活用する立場**に変わった事で得た感覚を、実際に担当しているプロダクトの事例を含めてざっくりと書いていこうと思います。（何番煎じだよとというツッコミは重々理解しております...）
私自身まだまだ未熟な部分が多い為、的外れな内容になっていない事を祈ります。

私と同様、機械学習を研究よりもサービスとして活用していきたいと考えている方。
または機械学習をサービスとして活用しているけど、本格的に研究していきたいと考えている方の参考になれば幸いです。

<font color="OrangeRed">*あくまで私自身が感覚として得た内容であり、研究開発とサービス開発の違いを明記するものではありません。</font>

## 視野と視座
そもそも研究開発とサービス開発では目的が大きく違う為、案件に取り組むにあたり意識する箇所も違います。
研究開発では、専門的な領域に対しての課題解決や、新しいアルゴリズム（マイナーチェンジ含む）の考案と、その有用性を示す為の検証といった案件をよく見かけます。
それはある意味そのアルゴリズムが**使えるか使えないかの結果のみで判断する非情な戦い**である事を意味しています。
ですので当然、データクレンジングやモデルの構造検討、さらには推論結果の検証に多くの時間を費やします。
視野を専門的な領域にフォーカスして、より高いスキルが要求される場合も多い印象です。
また、システム開発をする訳ではないので、メンバー間で開発環境や使用している言語のバージョンが違ったりしました。(GitHub上のイケてるモデルは割とPython2系で書かれてたりする)

一方で、サービス開発の目的は要件によって様々ですが、共通しているのは**利益や価値を生むプロダクトにする事**だと思います。
それを実現する為に、チーム内で今後の運用を見据えた設計に力を注いだり、ユーザ体験に重きを置いてツールを選定します。
それは時としてモデルの精度を一番に考えない設計に落ち着く事もあります。
さらにモデルには手を加えずに、UI等を工夫して体感的な精度を上げるアプローチも多く存在する為、単純な機械学習の知見だけではなく、ユーザ指向でサービス全体を考慮できる視座の高さが要求されると考えています。

やっている事は同じ機械学習という領域でも、視野と視座は両者で異なり**仕事としてやりがいを感じる部分**も違ってくるという感覚です。

## スピード感
当然ですが、サービス開発とは単純に動くものを作れば良い訳ではありません。
仮に企画担当部署が画期的なAIを活用したサービスを思いついたとして、それをリリースするにあたり、開発する私達の人件費やサービスの運用費諸々を差し引いて利益を生み出さなければなりません。
加えてお客様や業界のニーズは日々刻々と変化していくので、いかに早くリリースするかという観点も重要になります。
そういった背景の中、いくら精度の高いモデルを作れようと、その開発に1年を要するのでは期待される成果は出しづらく、UI周りをコーディングするメンバーと足並みも揃わないので、モデルのチューニングに多くの時間をかけずに**トレーニング済みモデルや、提供されているAPIでまずは作ってみる**という選択肢も候補に上がります。
とにかくサービスとしてリリースする事が大事で、その後のチューニングは運用しつつ行うみたいな感じです。

対して研究開発は、まだ研究領域の課題に対する技術選定や、2年計画くらいの長いプロジェクトをよく見かけました。
私自身、自動運転に採用候補のアルゴリズムに対してPoC検証を行う案件に従事していた時、スケジュールが全く引かれていないという訳ではありませんが、状況に応じて柔軟に変更しやすい風潮はありました。
また、チームメンバーが考案したアルゴリズムの精度検証をして、社外へのプレゼン資料の作成や論文を世に出すお手伝いをさせていただいた時も、時間感覚はだいぶ緩かったです。（これはのんびりすぎて逆に困惑した笑）


## モデルの検証
スピード感の項目と若干被るところも多いですが、こっちは既に物自体はできていて、**推論モデルや入力データに何かしらの変更を加えた際**の検証に対する考え方のお話です。
研究案件の場合、ある意味トレーニングしたモデルの検証が最も重要なタスクといっても過言ではありませんので、クロスバリデーション（交差検証）を行なったり、学習曲線を描いてオーバーフィッティング（過学習）していないか確認するなど、とにかく様々な観点から検証を実施します。

それに対して弊社では（今私が担当しているプロダクトにおいては）、F値の算出や推論されたデータの目視確認はある程度しますが、その精度を深く追う事はせずに一旦リリースします。（正常にサービスが稼働するかのテストは行います）
それは机上で検証するよりも、実際の利用データを基に検証を行った方が質の高い検証が行える点と、トライアンドエラーの回数を少しでも増やす事が、結果的に良い物が作れるという理念で動いているからです。
これについては賛否両論あるかとは思いますが、サービスとして、**何かあった時にすぐに戻せる**基盤がしっかりと作れているかどうかで分かれそうな気もしています。

## かお検索
これまでお話しした理念に基づいて、実際に私がフォトクリエイト社で担当しているプロダクトをご紹介します！（企業アドベントカレンダーなのでご愛嬌）
弊社で運営しているサービスの1つに、子供のイベント写真を販売する[スナップスナップ](https://snapsnap.jp)というサイトがあり、その中に**「かお検索」**という機能が存在します。
<img width="516" alt="かお検索.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545914/64b2269e-851b-df3f-e105-8022e52555f6.png">
私の担当はこのかお検索で、**数千枚ある写真の中から、自分の子供が写っている写真を検索する機能**を開発しています。

活用している技術はよくあるFaceDetectionとDeepMetricLearningを駆使した類似度検索ですが、プラスでクラスタリングを用いた独自の工夫も施しています。

安定稼働はしているものの、機械学習エンジニアとしてさらなる精度や推論速度の向上に努めたいと思う反面、**サービスを運営し、そこから利益を生み出すエンジニア**としての立場から冷静に今優先すべきタスクを考え、日々奔走しています。

また余談ですが、弊社ではお客様からの問い合わせに対応するカスタマーサポートの部門が同フロアにあり、背中越しにサービスに関するお客様からの生の声を聞く事ができます。
かお検索への問い合わせが来た時は、怖くもありますが、とても使いやすかったという嬉しい問い合わせが来る事もあり、モチベーションを高めるきっかけにもなっています。
これもサービス開発でなければ得られない体験かなと感じています。

## まとめ
**どっちもめちゃくちゃ楽しいので、自分が仕事のどういった部分にやりがいを覚えるか次第！（丸投げ）**

## 最後に
フォトクリエイト社では共に働けるエンジニアを募集しております。
Webエンジニア方面は先輩方が宣伝してくださると思うので、私は機械学習エンジニアに対しての魅力を語ろうと思います。
フォトクリエイト社は日本でも有数の**大量の画像データ**を保持している企業なので、上記のかお検索含め、機械学習を活用する可能性は無限大だと転職した私自身が感じています。
環境をAWSに移行した事でマシンリソースの心配もなく、最近ではデータレイク基盤の構築も進んでおり、分析系の業務経験も積めます。

興味を持っていただけた方は[twitter: @tetsunosuke](https://twitter.com/tetsunosuke)までご連絡ください！