
キャディの機械学習プロダクトマネジメント〜要件定義から学習・評価まで〜
CADDi プロダクトチーム Advent Calendar 2024 14日目の記事です。
はじめまして、キャディ株式会社の井上と申します!
CADDi Drawerという製造業向けSaaSの、
機械学習まわりのプロダクトマネジメントを担当しています。
先日、プロダクトチームの打ち合わせでこんな声があがりました。
プロダクトマネジメントに関するナレッジ発信が足りてないのではないか?他社のナレッジは世の中的にかなり興味を引くポイントだし、その発信がきっかけでキャディに関心を持ってもらえることも多いはずだよね
ふむ、ふりかえってみると確かに、あまりやってこなかったな…….
ということで今回は、
機械学習プロダクトマネジメントをテーマに筆を執ってみました。
機械学習プロダクトマネジメント
AI、機械学習はかつてに比べてかなり敷居が下がりました。
クラウド環境が充実して誰でも気軽に開発ができるようになり、さらに最近では生成AI系のサービスによってもはや開発せずともAIを搭載できるようになりました。AI、機械学習の大民主化時代です。
機械学習をプロダクトに取りいれるハードルはどんどん下がってきています。しかし機械学習を利用した開発の進め方は、よくある開発プロジェクトとは大きく異なります。AI、機械学習が簡単に扱えるようになっても、それをプロダクトに載せて運用し続けることは、まだ簡単ではありません。
まぁ…….いずれはそこも簡単になるんだろうなぁ…..
そこで機械学習が絡むプロダクト開発にあたって、
特段落とし穴となりやすい部分について深堀っていきます。
キャディの機械学習モデル開発プロセス
ここから先の文章では、機械学習のことをMLと略します。漢字がゴツゴツしてて厳ついのでね
キャディのMLプロダクト開発では、プロダクトマネージャー・MLエンジニア・MLOpsエンジニアが密に関わって活動しています。開発チーム内でのそれぞれの役割はざっくりと以下のとおりです。
プロダクトマネージャー
顧客価値の探索、要求・要件定義、やること/やらないこと判断MLエンジニア
機械学習モデルの設計、開発、トレーニング、評価MLOpsエンジニア
機械学習モデルの継続運用にかかわるシステムの設計、開発
三者が協力しながら、顧客価値の定義、MLモデルの開発からプロダクトへのデリバリー、運用・監視までを一貫して担っています。また高品質な学習データを用意するために、ドメイン知識を有する専門のアノテーションチームを設けています。
(※ アノテーション≒ML用の教師データ作成)

さて、このような図で表すとスムーズに開発サイクルが回りそうに見えますね。でも実際はそれぞれのステップの中に、泥臭い作業や技術的不確実性に由来する手戻りがしばしば発生します。
中でもとくに要件定義〜デプロイの手前あたりは、プロダクトマネジメント観点での落とし穴が多いです。今回はこの落とし穴ゾーンについて深ぼっていきます。

顧客ニーズ理解は、今回スキップします。
ここは一般的なプロダクト開発とMLを使ったプロダクト開発とで特段の差があるわけではないですし、またニーズ理解の一環であるインタビューについて、今年の弊社アドベントカレンダーでも触れられていますので。
ここからの解説の前提として、
顧客業務の実情と課題がわかった状態をスタートラインとします。
要件定義
MLプロダクトの要件定義は、通常のソフトウェア開発よりも技術的不確実性が格段に高いです。なぜならMLには避けようのない以下の制約があるためです。
100%に近いモデルは大抵実現できない・予測のミスはつきもの
顧客体験はモデルの精度によって左右される
モデルの精度は学習してみるまでわからない
モデルの精度はデータの量と質に左右される
良質なデータが豊富に手に入ることはほぼない
精度重視で複雑なシステムを構成すると速度や負荷耐性が犠牲になる
よって要件定義でよく語られる顧客ニーズの特定や、ビジネスとして採算が合うか合わないかに加えて、この技術的不確実性をいかに潰し込めるかを早いうちに検証しておく必要があります。
この点を加味して、以下のような流れで要件定義を進めていきます。
王道の開発なら先にモックアップまで持ち回ってから本腰入れて実装を進めると思うのですが、その手前で技術検証が入るのが特徴です。

【投資対効果ざっくり試算】
まず対象とする課題の解決に投入するリソースと、期待される効果をざっくりと試算します。これにより、初期段階でのROI(投資対効果)を見積もり、課題の大枠の価値を評価します。具体的に試算に使う情報は、例えば以下の通り。
投資リソース
開発にかかる期間 × 人員分の費用
開発にかかるシステムの費用(GPUや外部APIの利用料など)
導入費用(マイグレーションや初期状態の構築など)
システム運用費
期待リターン
受注機会の損失額:
営業へのヒアリングや失注理由から推定するチャーンリスク金額:
チャーン理由や未活用ユーザーへのアンケートから推定するアップセル機会の損失額:
カスタマーサクセスへのヒアリングやVoCから推定する期待機会の推定金額:
今リーチできていない市場に対してフェルミ推定をおこなう
この時点では精緻な見積までは求めず、あくまでざっくりです。自身が今解こうとしている課題が本当にインパクトを持つものかどうかを知るために試算をします。
ざっくり試算した時点で投資に対するリターンを得られないのならば、それは解くべき課題ではないと言えます。この時点で十二分に取り組む価値があるとなって初めて、課題解決にむけて着手します。
【イシュー分解・ニーズの特定】
ここでは自身が解くべき問いを見極めることを目指します。
普通に顧客の声をそのまま反映させたとしても、対症療法でしかありません。そうではなく、課題の根本的な解消を目指します。
ここではイシュー/サブイシューのツリー構造を作成したり、フレームワークを使って考えたりすることをおすすめします。
イシュー
=ゴールに到達するために、答えを出すべき問い
より簡単に言いなおすと「これがわかると次に進めるよねポイント」自分が思いつきやすいこと、知っていることをイシューと誤解しがちなので注意する。
↑私もしょっちゅうやりがちです
サブイシュー
= イシューの構成要素、答えを導き出すのに必要な論点いきなりHowから考えがちなので注意する
↑私もしょっちゅうやりがちですWhy, Who, Whatにこだわることがポイント
いわゆる課題解決の王道的なHow toをなぞる感じです。
といっても、細部までめちゃめちゃ完璧なイシュー分解をしようとする必要はありません。あくまで「これがわかると次に進めるよね」を明確にして、次のアクションに進めることが大事です。
イシューの穴埋めが目的じゃないことに注意しましょう。(私もしょっty…
【ソリューション仮説立て】
ここでは先程のイシュー分解に基づいて、「ではどうやって解くの?」を明確化します。具体的な解き方・手段の部分はエンジニア中心に考えていただきつつ、プロダクトマネージャーは以下のポイントを問いかけるとよいです。
本当に、自社で作る必要はあるのか
自社じゃなくても市販ツールや既存のパッケージで行けるのでは?
LLM系のサービスでできちゃったりしないか?作らなくても、人による作業で解決できるのではないか?
何をもって成功だと言えそうか
計測可能な成功指標は何か?
どのタイミングで成功/失敗を判定するか?
どこまで解決できたらMVP(最小実行可能プロダクト)か
作りすぎでなく、されど顧客の課題を解けるミニマムラインはどこ?
ディープラーニングは優秀なので、手なりで学習させると何らかのMLモデルはぬるっとできてしまいます。しかしその良し悪しを判断できず結論が曖昧になってしまいがちです。前もってモデルを作る意味や、合格基準を持っておくことで、真にMLで解くべき課題かどうかを見極めることを目指しましょう。
またこれから作り始めるソリューションは、それが本当に顧客に受け入れられるのかどうかの不確実性をはらんでいます。作りすぎず、素早く市場に送り出して仮説検証できることが重要です。
【ラフなML技術検証】
さて、ようやく機械学習のスタートです。先のステップで立てたソリューション仮説が実現可能かどうかを簡易に検証します。
さて、昨今はOpen AIのGPTやGoogleのGeminiをはじめとしたLLMによって、汎用的なタスクに対しては学習させずとも機能を作ることができるようになりました。
何をするにもまず、初手LLMで試してみるのは良い手だと思います。これで精度が出せるとなると、素早く技術的不確実性を見極められます。ただしLLM系のサービスにはまだ以下の課題もあります。
苦手な種類のタスクがある
ドメインの深いモデルに対しては精度に課題がある
コストが高い
速度が低い
(※ ここは多量のデータを素早く処理するケースでの課題感で、
機能によっては速度が十分な場合もあります)
もちろん生成AIの威力は素晴らしいです。長期的には上記の課題も改善されていくでしょう。弊社もこうした流行りを取り入れるのですが、それがベストな選択なのかどうかは常に考えるようにしています。

LLMで解けない/LLMより特化型モデルのほうが向いているとなった場合は、少数のデータを使って自社でMLモデルを作って評価を行います。
まずはプロダクトマネージャーとMLエンジニアでデータを眺めながら、どうやって学習をするか、どのような教師データに仕立てるか、モデルの性能をどうやって評価するかを考えます。この時点で、後段で話すアノテーションの定義も作っておきます。
そして策定した通りに教師データを作り、学習と評価までやってみます。少ないデータ量なのでこの時点ではもちろん良い精度にたどり着かないことが多いです。しかしここで大事なのは本番レベルの精度を出すことではなく、「できそうか」の肌感を掴む(=技術的不確実性を下げる)ことです。
ざっくり技術検証してみて、「これは無理ゲーやな」ってなったら、再度ソリューション仮説立てに戻るか、その課題には取り組まないかの選択をします。できそうな肌感が掴めたのならば、次に進みます。
なお、この時点からPRDを書き始めることをおすすめします。早いうちにチームにレビューいただくことで後々の手戻りが少なかったり、後で時間に追われずに済んだりするので。
【モックアップヒアリング】
ソリューション仮説のステップで定めたMVPに基づいて、モックアップを作って顧客に持ち回ります。可能であれば、ラフな技術検証でできた機械学習モデルを組み込んだデモか何かを用意できればよいです。
StreamlitなどのPython系のフレームワークを使えば、サクッとデモに十分なMLアプリケーションを構築できるのでおすすめです。またUIの操作が顧客体験にクリティカルでないのであれば、擬似的に機械学習の精度を模した紙芝居を見せるのでも良いと思います。
とにかく何かしらの形で、顧客価値の不確実性を下げることを目指します。
このモックアップのヒアリングで、ソリューション仮説が本当に課題を解決しているのか、顧客に受け入れられるのかを確かめてゆきましょう。
【開発のGo/NoGo判断】
まぁ〜長々と語ってきましたが、全部まとめると↓こんな感じです。
これらの問いが全部YES/合格であれば、本腰を入れて開発していきます。

他者の受け売りですが、開発のGo/NoGoの基準は『INSPIRED』に記されるところの価値・ユーザビリティ・実現可能性・事業実現性の4つのリスクを評価したうえで行うとよいでしょう。先程までの各ステップも、これらの観点に基づいて評価をしてきたと思います。
データ収集
要件定義の末に開発Go・本腰を入れて開発すべきとなったら、まずやるべきはデータ収集です。内製のモデルを使う場合はもちろんですが、LLMを使うとしても精度評価のために一定量のデータ収集は必要です。
モデルを作るにしても評価をするにしても、プロダクトに搭載するにあたっては汎用性がとても重要です。極々一部にだけ強いモデルを作ると、いたずらにモデルの数が増えて、開発工数も運用負荷も増大してしまいます。
(※ あえて特化させるパターンもあるとは存じますが、
スタンスとして言い切らせていただきます🙏)
精度と汎用性を両方とも獲得するために重要なのは、以下の観点です。
学習・評価に十分なデータ量があるか?
データの量が少なすぎると、どれだけ強いエンジニアであっても良い精度は出せません。基本的にはデータが多ければ多いほど良いです。
ちなみに私は↓の考え方で最低限必要な量の目安を勘定します。
タスクの種類 × 特徴のわかりやすさ≒クラスタ間距離 × ラベル種類数
データのバラエティは十分か?
バラエティが少ないと、本番リリース後に学習してないデータが流入するため想定した精度がでません。
学習・評価に含めるパターンと、例外とするパターンの見極めが大事
データはきれいか?
学習を阻害するノイズデータは往々にして紛れがちです
ノイズがある場合はクレンジングする必要があります
アノテーション
収集したデータはそのままでは学習や評価に使えないため、MLで使えるようにするための加工/編集をおこなう必要があります。データにラベルを付けてその意味を明確にする作業のことをアノテーションといいます。画像・動画認識の分野においてはとくに欠かせないタスクです。
アノテーションについてキャディがどのように運用しているのか。
以前このテーマを記事にしたため、ぜひ以下のリンクをご覧ください!
学習⇔評価
アノテーションされたデータが集まったらようやく学習です。
まず、学習プロセスは以下のステップで進めます。
データ前処理
データのクレンジングや正規化、特徴量の選定などを行います。これにより、モデルが効率よく学習できる状態にデータを整えます。とくに我々キャディがターゲットとする製造業のデータはノイズが多いため、データの前処理が欠かせません。
この前処理ですが、データ観点とドメイン観点の両面で見ていくことがとても重要です。データだけで見るとドメインに重要な部分を見落とし、ドメインにこだわりすぎるとML的に扱いにくいデータになります。
モデル選定・学習
問題の種類に応じて最適なモデルを選定し、学習を行います。ここはエンジニアメンバーに、専門性を存分に発揮して進めていただきましょう。
評価
学習が完了したモデルの性能を確認します。
先のステップで定めた評価指標に基づいてみていきましょう。
評価指標のうちどこを重視するかは、その時々の解きたい課題によって異なります。誤検出が致命的な問題になる場合もあれば、多少誤検出しても良いから見逃しを防ぎたい場合など様々です。評価結果と顧客体験への影響は密接に関わるため、プロダクトマネージャーも評価指標についてはよく理解をしておきましょう。
この学習と評価のサイクルは何度も繰り返され、適切なモデルが見つかるまで続けます。ここで重要なのは、以下の点です。
フィードバックループ
学習と評価の結果を元に、モデルの改善点を見つけて再度学習を行います。このプロセスを何度も繰り返すことで、精度の高いモデルを構築することができます。
データのバラエティの確認
評価の段階で、モデルがどのようなデータに対して強いのか、弱いのかを確認し、必要に応じてデータのバラエティを増やしましょう。
モデルが間違ったデータを必ずいれるべきかと言うと、そうではありません。ドメインと照らし合わせて、「必要だけど間違っている」ものを選定しましょう。また間違ったデータの中にノイズがあれば除きましょう。
ドメイン知識を活用した特徴量設計
時に特徴量を追加すると、飛躍的に精度が良くなることがあります。何が精度に寄与するかはデータから探すよりもドメインから見出すほうが手っ取り早かったりします。顧客インタビューやカスタマーサクセスの声をもとにして良い特徴量を探してみましょう。
このように、機械学習を用いたプロダクト開発は、通常のアプリケーションとは異なるプロセスが挟まるものです。しかもそのプロセス、データ収集や学習・評価は結構な手間がかかります。しかしここでの努力が最終的な製品の品質と顧客満足度に直結するため、こだわりを持ってやり抜きましょう。
さて……いかがでしたでしょうか?
AIが扱いやすくなっても、それをどう使えば価値になるか、良し悪しをどう評価するか、品質をどう安定させるかは不確実性の大きい領域です。AIが扱いやすくなったからこそ、その価値定義や品質設計の深さが競争力のエンジンになると個人的には考えています。
もちろん、MLやAIを取り巻く環境は変化が激しいので、これからどんどん開発の進め方は変わっていくと思います。今回はお話できなかったデプロイ・運用の落とし穴や開発プロセスの進化についても、また今後書いて行ければと思います。
記事を出した際にはぜひ、ご笑覧ください。
さいごに
キャディのプロダクト開発について、
少しでも気になっていただけましたでしょうか?
ちょいとでも興味を持っていただけたらぜひ、
以下のページを見てみてください!m(_ _)m
好奇心が旺盛な方や、大胆な動き方が好きな方、何かにハマってみたい方にとって、キャディは面白い環境だと思いますよ!