はじめに
みなさま、初めましての方もご無沙汰しておりますという方も、株式会社キカガク代表の吉崎（twitter:@yoshizaki_kkgk）です。
ちょうど１年ほど前に失敗して泣きながらこんな記事を書き、多くの方から反響をいただきました。
Qiita: 機械学習案件を納品するのは、そんなに簡単な話じゃないから気をつけて
こちらの記事は2018/10/25現在、1118いいねをいただけるモンスター記事となりました。
いま思うと、契約に関する素人感丸出しの記事ですが、まだまだ黎明期のこの分野にとっては共感していただけるような内容だったのだと嬉しく思います。
この記事が関係あるかないかわかりませんが、これ以降、契約周りの話であったり、機械学習のモデルではなくプロジェクトとしての進め方の書籍や記事を2018年は多く見かけるようになりました。
まさに、技術から事業化への一歩を踏み出した１年であったと感じます。
本記事では、前回からの１年間のアップデートをまとめた１本です。
弊社でもこの１年間、機械学習に関する教育事業をメインに展開しながら、いくつかのコンサルティング依頼もいただき、実案件に触れながら経験を積むことができました。
実案件に入るたび、やっぱり参考書にはまだ書かれていない細かい調整が毎度毎度あるなぁと感じ、ボトムアップ的に経験しながら、いつかこのもやもやとしたゾーンを構造化できないかと考えながら臨んでいます。
機械学習 × 事業化
さて、機械学習の前工程などに関しては、まだまだ構造化できる実力はないのですが、私自身、起業家という背景もありビジネスモデルを考えることが多く、機械学習をどのように事業につなげていけば良いかは全体像が掴めてきたように感じます。
たまに聞くのが、AIで新規事業をしてほしいというトップからの指令で勉強を始めましたという話も聞きます。
おそらくこのAIは機械学習を指しているのだろうというこの一年間で何回入れたのかわからないツッコミはさておき、この指令には２つの難しさがあります。
- 新規事業を立ち上げる難しさ
- 機械学習を事業に導入する難しさ
そもそも機械学習でないと実現しない事業で良いの？
まず、よく考えていただきたいところが、機械学習でしか実現できない事業で良いのか？ということです。
機械学習を使ったビジネスモデルを考えてみる
機械学習を使ったビジネスモデルの場合、以下の２つのようなパターンがあると考えています。
パターンAは以下の特徴があります。
- 機械学習なし（まったく精度が出ない）場合でも売り上げが確保できている（切片が0でない）
- 精度が向上するに連れて、売り上げも伸びていくビジネスモデル
例えば、Amazonのリコメンドなどが考えられます。あなたにおすすめの商品が全くあっていないても、そもそも商品を検索して購入することが主であるため、売り上げは確保できています。さらに、おすすめの商品の予測精度が高くなれば、その商品も併せて購入する確率が上がるため、売り上げ向上につながります。
パターンBは以下の特徴があります。
- 精度がまったく出ないときは売り上げも全くない
- 事業としての売上が確保できるのは、かなりの良い精度が出てから
例えば、自動運転がこの例だと考えられます。もし道路を走るとなると、99%の精度で予測できたとしても、その1%に世間の目がいってしまい、いつまで経っても事業として導入することが阻まれてしまいます。結果、ほぼ100%に近い精度でないと導入が難しく、現実的にこれは困難であるため、自動車側だけでなく法律面や道路の整備など、別の方法で工夫していかないと導入が難しいと想像できます。
パターンBを選んだビジネスの先に待っているもの
AIで新規事業というふわっとしたお題の設定だと、パターンBのビジネスを選んでしまうことがあります。
このモデルでは、最初資金調達を行ってブーストをかけていくのですが、ビジネスとしてマネタイズが成立することが非常に遠いため、シードもしくはシリーズAの壁を突破することが難しいです。
精度が出ればさらに追加の投資が入り、人が集まり、さらに精度が出るという正のループに入れば良いのですが、残念ながらその逆の負のループに入ってしまうこともあります。
初期に少ない資金で集められるデータセットと人材で取り組んだものの精度が思ったように出ず、クライアントを見つけて検証を行うも不発に終わり、追加投資に奔走するもどこかと組んでいる実績がなければVCや事業会社からは投資に値しないと言われて、次のフェーズに行けずに解散を余儀なくされる。
そんな経験をしている人を見たことがないでしょうか。
実は私もこのチーム解散を経験しました。
志も高く、良いチームが集まっている。
けれども、ビジネスモデルの構造上、どうしてもその先に進めない。
こんな辛い経験を経て、ようやく機械学習を事業に活かすためには、どのようにビジネスモデルを設計すればよいのかが見えてきました。
精度が100%出ない問題はどうやって解決するの？
誰もが口にすることですが、機械学習では精度100%を出すことは現実的に困難なケースがほとんどです。
逆に精度100%が出せるようなケースだと機械学習を使うまでもなく、単純なif-elseのプログラミングで実現できると思います。（理解をややこしくするため、訂正しました。）
この点を頭では理解している人が多いのですが、実際にビジネスモデルを考えてもらうとやはり機械学習ありきのビジネスモデルとなっていることがほとんどです。
精度100%が出ないということは、以下のどちらかで対処していかないといけません。
- 間違えても大きな損害がないケース（天気予報などそもそも人が100%でない前提で行動）
- 運用側で間違いをカバーできるケース
実はどちらも人間が間違いに対して冗長化を行って対処しているのですが、ユーザー側が対処するか、運用側が対処するかの違いがあります。
どちらにせよ、間違いを前提とした運用フローを考えないとうまくいかないというわけです。
これを事業化と結びつけようとするとさらに難題です。
クライアント側にサービスを提供したり、納品したりと責任が伴う中で間違いを許容しないといけないわけです。
そう考えると、やはり下記の流れで示すように、まずは手動でも良いので機械学習は使わずに成果物を出せるような流れを確立しておき、その中から高頻度もしくは高速化が必要なパートを切り出して徐々に機械学習によって効率化を図っていくことが正しい流れではないでしょうか。
機械学習（図でAIとなっている部分）の前後では人間が間違いを許容できるように冗長化を図っておき、成果物に対しては影響のないような運用フローとすることが肝です。
そう考えると、AIで新規事業と一言で言っても、ちゃんと順番があることがわかります。
- 新規事業を労働集約型でも良いため確立する
- ルーティーンとなっている作業を見つけて、費用対効果が高ければ、システムの自動化（機械学習を含む）に取り組む
この順番を守れば、パターンAのビジネスモデルで取り組むことができ、効果的に機械学習を取り入れることができるのではないでしょうか。
もちろん、前述したように、機械学習でなく単なるプログラミングによるシステム自動化でも良く、工数が少なくて安定稼働するほうを選ぶべきです。
事業化の際に必要な人材とそのフェーズ
機械学習を使っていくとしても使わないとしても、まずは事業化が最優先に来ることが見えてきました。
その前提で、どのような人材がどのようなフェーズに必要なのでしょうか。
弊社ではいくつか新規事業を行っており、ちゃんと事業化していくにはこの３ステップを意識して切り分けていこうと話しています。
「人力×エクセル」でサービスの「質」を高める
企画が始まれば、まずプロダクトを作るというケースも聞きますが、弊社で取り組む際には、絶対に「人力×エクセル」やツールを使って、人力オペレーションの確立を行います。
ただし、前提としてこれは今後労働集約型で行っていくわけではなく、効率よくスケールさせていくことを念頭に置いており、機械学習を理解している人材がそもそもこのフェーズでのオペレーションを行います。
この機械学習を理解している人材には以下のスキルセットが必要です。
- 機械学習が使えるデータセットの構造（入力と教師データ）を理解している
- 機械学習によって予測できることで、事業にプラスになるアクションが設計できる
- 人間から教師データを貯められる仕組みづくりができる
上記を見てわかるように、機械学習のアルゴリズムの数学やプログラミングを徹底的に理解している人材ではなく、入出力の関係性をモデル化できるためのデータの構造を理解している人材であればOKだと思っています。
このご時世、Azure Machine Learning Studioを使えば、GUIで機械学習のモデルを構築することはできますし、事業化さえうまくいけば機械学習エンジニアを雇用することもできます。
多くの企業を見ていて思うこととして、最終的にデータ駆動で起こしたいアクションを決めずに、とりあえずと蓄積したデータから改善策を提案したり、それに基づいた機械学習による効率化を行うことは難しく、議論が発散して、やっぱり辞めた方が良いのでは...と誰もが内心思い始めます。
この問題に遭遇しないためにも、最初の人力オペレーションの時点ではどのようなデータを蓄積すれば、行動の改善につなげられるかを定義しておくことが最重要です。
ここを怠ると、結局機械学習を使えずじまいになります。
そのため、機械学習の大枠を理解した人が、今後機械学習を使う前提でデータの貯め方と活かし方を考え、そして、アプリケーションを作成する際に必要なデータの構造化を行っていくことが重要です。
多くのケースでは、サービスを作る側ではなく、エンジニアがデータベースの構造を定義してしまうため、それが間違いの始まりです。
サービス開発側が必要なデータを定義し、それをエンジニアに伝えながら進めていけるようにしましょう。
「量」を提供するためにアプリケーションへと落とし込む
人力オペレーションによってサービスの「質」を高めることができれば、次はアプリケーションを作成して「量」へとつなげていきます。
ここはアプリケーション作成で多く語られることであるため、言わずもがなですが、事業開発側がエンジニアに求める３点は以下の通りです。
- ユーザー体験（UX）を意識した設計
- MVP(Minimum Viable Product)を意識した素早い仕様変更に耐えうる設計
- 機械学習を用いる連携を意識した設計
よく作り手の意図を感じる仕様になっているサービスに遭遇します（マイクロサービスアーキテクチャー系だとよく感じます）が、大事なことはユーザー体験をどれだけ高められるかといった点です。
ペルソナを定め、まずは見た目から考えて決定していくことで、これを満たしていけると思います。
くれぐれも、コードから書き始めないように注意しましょう。
そして、新しいサービスは人力オペレーションの時には触れることができなかった多くの声が集まり、仕様変更が頻発します。
もちろんこの仕様変更はエンジニアにとって耐えがたい経験の一つです。
これをなるべく避けるためにも、人力オペレーションの際に、ユーザーの声を多く聞き、素早く変更しながら、仕様変更をなるべくしなくても良いように心がけましょう。
とはいえ、現実問題どうしても生じてしまうため、常に仕様変更がある前提で、「Done is better than perfect.」くらいの気持ちで、作りこみすぎない大枠から作っていきましょう。
また、機械学習を使っていく際はAPI連携が多いため、可能であれば（必須ではない）、機能をAPIで連携できるように作っておき、機械学習の推論サーバーとAPIでやり取りをしても大きな仕様が変更しないように今後のことも見据えて設計しておきましょう。
データ駆動での「改善」は「質」と「量」あってこそ
アプリケーションを作ると多くのデータを蓄積することができ、それを最初に活用する方法まで検討して設計できていると、その方向性に基づいて、データサイエンティストと呼ばれる職業の人が解析し、アクションまで提案します。
また、その先に、データに基づいて予測したいものは機械学習エンジニアがモデルを構築し、アプリケーションへと連携していくことで、ユーザー体験を高めることができます。
その結果、売り上げを向上させることができます。
「質」と「量」のフェーズで正しく設計がされていれば、あとはほしい結論に向かって、その道筋をデータサイエンティストや機械学習エンジニアがクリアしていくだけです。
しかし、多くのケースは「質」と「量」のフェーズで何も設計されていないシステムのデータを渡されて、「ここから何か見つけ出してほしい」と無茶なお願いをされるわけです。
まとめ：「質」と「量」あってこその「改善」
おわりに
前回の記事から約一年。
今回も前回同様に２時間弱の勢いで書き上げた記事となりました。
振り返ってみると、この１年間、辛い思いもしながら、それでもこの技術には大きな未来がある！と地道に取り組み続けてきました。
正しく設計すればとても効果的な技術です。
しかし、それを魔法のように過信しすぎると、期待を裏切ることになります。
いまでも一部ではAIや機械学習を「魔法」のように取り上げた文脈に遭遇しますが、残念ながらそうではありません。
今回の記事で紹介したように、ちゃんと人間が考えて設計して、地道に努力し続けて成果が出る領域です。
理想に対して現実はそうそううまくいかないことも多いですが、設計あってこその改善ですので、意識してもらえると、さらに良くしていけるはずです。
お互い辛抱強く頑張っていきましょう。
もし記事の内容を気に入っていただければ、いいねをいただけると嬉しいです。
ご一読いただき、ありがとうございました。
著者
株式会社キカガク
代表取締役社長 吉崎亮介
Twitterでのフォローをお待ちしています。
@yoshizaki_kkgk