CADDi AI Labの進化 R&Dから実用プロダクトへの旅路 #pmconf2023

Transcript

1. 2023.11.29 Takeaki Imai CADDi AI Labの進化: R&Dから実用プロダクトへの旅路
2. CADDiが2021年に⽴ち上げたAI LabはR&D組織として、当初は機械学習のPoCを 主眼に置き活動をしていました。 しかし1年を経て環境が変化し、プロダクト組織へと転換する決断をしました。 • ⽴ち上げ当時意識していたこと • R&D組織からプロダクト組織へ転換した背景 • プロダクト組織にしたことでの半年間の振り返り をお話します。 このセッションの話題 2
3. About Me Takeaki Imai 　@imaimai0 NTT研究所: 機械学習‧データ分析 i Smart Technologies: 製造業向けIoTサービスを開発 CADDi: AI Lab⽴ち上げ、DRAWERテクニカルプロダクトマネージャー Career: 「技術で⽂化を創る」をテーマに 製造業×DXに6年ほど携わっています Hobby: サウナ‧家造り‧茶道 デジタルと距離を置いた⽣活をしています 3 CADDi AI Lab⽴ち上げから製造業へのML適⽤までの軌跡
4. What is CADDi
5. Mission モノづくり産業の ポテンシャルを解放する Unleash the potential of manufacturing 5
6. 設計 調達 製造・施工 検査・納品 販売 サービス 2つの事業で製造業のサプライチェーンのDXをモノとデータから支援 CADDi DRAWER CADDi MANUFACTURING 部品調達プラットフォーム 調達‧⽣産機能の⼀括請負による モノからサプライチェーンを変⾰ technology knowledge 図⾯データ活⽤クラウド 図⾯とその周辺データの資産化による データからサプライチェーンを変⾰ 6
7. 製造業「最重要データ」といわれる図面は、資産とほど遠い 部署問わずアクセスしたい過去図面に即座にアクセスできる、検索性が高い、形式 知化されている、将来の設計・調達・製造・保守等に「価値を生む」 という状態からはほど遠く課題が山積 10年以上前の図面が 紙で保管されている 各調達・設計者のローカルフォ ルダに保存。他の人が何を持っ ているかは知らない システムに保管されて いるが、1図面ずつしか 引き出せない https://warekennis.nl/wp-content/uploads/2013/11/bridging-the-information-worker-productivity-gap.pdf 7
8. DXの第一歩としてのCADDi DRAWER 設計 調達 製造・施工 検査・納品 販売 サービス 設計工数 削減 発注先・ 価格最適化 業務効率 最大化 不良品対応 工数削減 メンテ部品の 最適発注 図面とその周辺データの資産化・横軸での活用 8
9. R&D組織からプロダクト組織へ
10. DRAWER サービス開始 Algo図⾯解析‧ 図⾯検索機能リリース CADDi R&Dとプロダクトの歴史  2023.06~ 2023.11  2023.01~ 2023.05  2022.06~ 2022.12 2022.01~ 2022.05 ML 図⾯解析 3D解析 R&D プロダクト LLM AI Labから DRAWER チームへ ML 図⾯解析 リリース OCR 図⾯検索 AI Lab発⾜ Algo 図⾯解析 2021.01~ 2021.12   10
11. プロダクトまでの3つのフェーズ PoC (Proof of Concept) MVP (Minimum Viable Product) プロダクト化 目的 主な成果物 不確実性 達成にかかる工数 大 小 大 小 実現可能性を 判断する ユーザーへの提供 価値を判断する ユーザーに 価値を届ける モデルの性能 価値判断のための 最低限のインター フェース プロダクトに 組み込まれた状態 11
12. R&Dのススメ方: ユーザ提供までの3つのフェーズと不確実性 PoC MVP Production 実現可能性 判断 ユーザー提供価値 判断 ユーザー 価値提供 不確実性 時間 12
13. R&Dにおいて「正しく」検証する必要性 そもそも実現するかわからないからPoCがある PoCの成功はその実現可否がわかること 実際の価値につなげる⽬標はそのあと PoC MVP Production 実現可能性 判断 ユーザー提供価値 判断 ユーザー 価値提供 不確実性 13 時間
14. R&Dにおいて「正しく」検証する必要性 PoC&MVP Production • 性能の判断が曖昧 • できないものを「できるよう にみせて」次に進まざるを得 ない状況に 実現可能性 判断 ユーザー提供価値 判断 ユーザー 価値提供 不確実性 14 時間
15. • そもそもスタートアップに本気のリサーチはほとんどの場合過剰 • ⼀⽅で、ユースケースに引っ張られすぎると実現可能性が検証できず、コア領域への競争⼒ が低下するため、正しく検証する機会は必要 (私見)スタートアップにおけるR&Dのバランス スタートアップにおいては、コアの技術領域に特定したPoCはOK それ以上のリサーチは持たずMVP以降のプロダクトバリューを⾼める開発をすべき 15 CADDiにおけるコアの技術領域とは？
16. 製造業データにおける ドメイン知識を加味した 解析及び検索の技術 CADDiのコアの技術領域 16
17. 重要度と代替可能性から優先度をつけて技術検証を⾏った まずは図⾯及び3Dの検索部分に注⼒。⼀定の成果を短期間で創出 CADDiのコアの技術領域 ⾼: ドメイン特化のも のは存在しない&単 純なパターンマッチ ングが主流 ⾼: 単純なパターン マッチングが主流 低: 代替が効く 検索 図面 3Dデータ 文書 解析 ⾼: ドメイン特化のも のは存在しない 中: CADメーカにない 解析はいくつか有り そう 中: LLMを起点にあら ゆる幅を広げられる 可能性あり 17
18. R&D組織からプロダクト組織へ至った背景 エンジニア視点 プロダクト視点 LLMや基盤モデルの台頭により、モデリン グに隣接する領域が重要視されるように。 下記例 • モデリング前の要件定義 • 基盤を作ることによるモデルのデプ ロイ⾼速化や作ったモデルの運⽤ PoCにより実現可能性がわかり、MVPを経て コア技術の提供価値が認められ始めた。 ユーザー起点の「こんな事できないか」が増 え、更に解像度を⾼めていく必要性が上がっ てきた。 選択と集中 キャリアの多様化 18
19. R&D組織からプロダクト組織へ AI Lab MANU Team MANU DRAWER DRAWER ML/Algo Team DRAWER Team MANU DRAWER MANU Team DRAWER Team 検証から価値提供まで遠い 領域が分散する 縦にチームをつなぐことで 価値提供の質とスピードを⾼める 19
20. 20 キャリアの多様化: モデリングに隣接する領域が一層重要視されるように データ収集 課題定義 アノテーション モデリング 運用 再学習 データ収集 課題定義 アノテーション モデリング 運用 再学習 プロダクトマネジメント的思考 MLOps的思考 MLモデリングのフロー これまで これから
21. プロダクト組織にしたことの振り返り ~必要なのは、プロダクトマネジメントでした。~
22. 提供価値を主体で考えること、事業解像度を⾼く保ち続ける必要性、 相互コミュニケーションが必要であることから、プロダクトマネジメントが必要 必要なのはプロダクトマネジメントでした 2  良い性能≠良いプロダクト 3つの学び 3  相互理解が事業推進の⼟台 1  求められる解像度が⼤きく違う 22
23. R&Dとプロダクトの解像度の違い ⾼: ドメイン特化のも のは存在しない&単 純なパターンマッチ ングが主流 高: 単純なパターン マッチングが主流 低: 代替が効く 検索 図⾯ 3Dデータ 文書 解析 ⾼: ドメイン特化のも のは存在しない 中: CADメーカにない 解析はいくつか有りそ う 中: LLMを起点にあら ゆる幅を広げられる可 能性あり PoC: 精度と必要マシンリソースから、解析が コア技術として成り⽴つか 23
24. R&Dとプロダクトの解像度の違い ⾼: ドメイン特化のも のは存在しない&単 純なパターンマッチ ングが主流 高: 単純なパターン マッチングが主流 低: 代替が効く 検索 図⾯ 3Dデータ 文書 解析 ⾼: ドメイン特化のも のは存在しない 中: CADメーカにない 解析はいくつか有りそ う 中: LLMを起点にあら ゆる幅を広げられる可 能性あり プロダクト: 顧客が価値を継続的に享受できるか • ユースケース: 実際に顧客がどのように使っているのか ◦ 解析の粒度は適切か ◦ めちゃくちゃ解像度の⼤きな図⾯にどのように対応 していくか • 戦略: 新しい業態の顧客に出ていく際に、同等のモデルで⼗ 分耐えうるか、新しく作る必要があるか • 変更マネジメント: モデルをどのタイミングで変更するか、 そのときのコストはどうするか • 信頼性: 解析のレイテンシ及び安定性はSLOを満たすものに なっているか etc… 24
25. 良い性能≠良いプロダクト: 精度 少し頑張れば⼤きな成 果になるが、精度を上 げても価値は代わりに くいかも 性能が上がれば 素直に価値にな る ほとんど100% じゃないと成果 出せない Accuracy/ Difficulty Value ref: Lean AI 開発論: コードを書く前に機械学習プロジェクトを評価する方法 ｜Anno Takahiro｜note Accuracy Value Curve 精度は必ずしも価値と⽐例しない。精度を⾼めるには労⼒がかかるので、 精度と価値の関係性にあたりを付けておき、労⼒に⾒合った優先順位判断が重要 25
26. 良い性能≠良いプロダクト: スピード 図⾯投⼊から画像解析 された結果がサービス に格納されるまで10s 以内 性能のトレードオフが作成したモデルの範疇を超えて存在 性能‧コスト‧顧客体験を踏まえ総合的に判断を⾏う 要求 精度 10s以内に格納できるよう、モデルの軽量 化を⾏う トレードオフの選択肢 コスト 10s以内に格納できるよう、マシンのス ケールアップ / スケールアウトを検討する UX 10s以内に表⽰されるのは「解析中」の表 ⽰だけにして、待ってもらう ML領域内での トレードオフ プロダクト 開発全体での トレードオフ 26
27. 必ずしも簡単なことではない。 PoCの精度と違い、顧客価値のレバーが⾃分たちだけにないことも多 く、越境し職掌を広げていく必要はある。 言うは易しだが... 27
28. 相互理解が事業推進の土台 ⾃チーム 関連 チーム 28 関連チーム / ユーザーの理解とともに、⾃チームの理解活動も必要
29. 相互理解が事業推進の土台: ユーザ理解 設計 調達 製造‧施⼯ 検査‧納品 販売 サービス 過去、同様の加⼯が 「存在したか」を「参 考情報として」知りた い ⾒積のために「同様の 記号カテゴリ」が何個 あるか「参考情報とし て」知りたい 図⾯上に加⼯が「どこ に何個存在したか」を 「正確に」知りたい 例: 「溶接記号認識」におけるユーザーニーズの違い ペルソナ設定とヒアリングを経て、これらに優先順位を決めたり、 抽象化してプロダクト要求を書いたりするところはプロダクトマネージャの腕の⾒せどころ。 ※ 社内で使っている   PRDテンプレート ※溶接記号の例 29
30. 相互理解が事業推進の土台: ステークホルダへの理解活動 機械学習とはなにかの理解 開発プロセスへの理解 対Biz 対Product セールストークの切り返し できないことを「できます」というような認 識齟齬の防⽌ 機械学習モデルが実⽤化されるまでの 時間的な期待値の調整 R&Dは内容の理解が難しい。⾃分たちの活動を理解してもらい、「魔法の箱」とな らないことが事業推進の底上げにつながる。⼿間を惜しんではいけない。 30
31. まとめ

32. まとめ プロダクト組織化の振り返り R&D組織からプロダクト組織へ ⽅針 事業のコアとなる技術に限定しPoCを実施 それ以上の過度なリサーチは避ける 組織変更 決断の 経緯 プロダクト視点: 選択と集中 PoCでの実現可能性が認められ、提供価値 を求められるようになった エンジニア視点: キャリアの多様化 LLMなどの台頭によりモデリングの隣接領 域も重要視されるようになった 様々な課題に直⾯しつつも、プロダクト組織化は事業にとって、 チームにとって今のところ良い効果を⽣んでいます。 2  良い性能≠良いプロダクト 3  相互理解が事業推進の⼟台 1  求められる解像度が⼤きく違う 32
33. We are hiring!! 最後に 33
34. 34 これからのML組織にTechnical PdMが必要 データ収集 課題定義 アノテーション モデリング 運用 再学習 プロダクトマネジメント的思考 プラットフォーム的思考 MLモデリングのフロー MLのリスク評価をしつつユーザー 要望を吸い上げられるPdM 開発者の体験がイメージでき、 Platform as a Productとしてプロ ダクト開発ができるPdM
35. © CADDi Inc. CADDi Engineer Tech Blog CADDi 採⽤情報 35 @CaddiTech エンジニア 募集職種 エンジニア採⽤ポータル CADDi Engineering カジュアル⾯談 ちょっと興味ある⽅ がっつり聞いてみたい⽅ どなたでもWelcome！ 積極採⽤中！ • Product Manager • Technical Product Manager • Machine Learning Engineer • UI/UX Designer
36. おわり