MLOps実践者たちのリアルなお悩みの解決にコミュニティーがどう貢献できるか：MLOpsイベントレポート

MLOps（機械学習の実運用化）の活動目的＆方針を「デザイン思考」で議論した座談会の内容をレポート。デザイン思考フレームワーク＆ツール「MURAL」を紹介し、MLOps実践時の悩みと対策案を議論。世の中が抱えているMLOpsの課題を解決するためにコミュニティーの方針を検討する。

[シバタアキラ, 小島繁樹, 田中翔, 松館学，共著]

連載目次

　MLOpsコミュニティーは「全ての機械学習モデルが現場で実運用化される世界」を目指して2020年夏に始まりました。月1回程度の頻度での活動を目指し、勉強会やワークショップ、ディスカッションなどを行うことで、今後のAI技術の発展に非常に重要な、MLOps（機械学習の実運用化）の普及に貢献していきます。

　このレポートでは、2020年9月に行われた第2回のイベント活動である「MLOpsコミュニティ座談会」の様子をお伝えします。今回はコミュニティーの方針を少人数で議論するため参加者を16人に限定し、リモートで実施しました。よく見かけるオンラインの勉強会とは異なるディスカッション形式の勉強会でした。そこで本稿では初めに、どのようなフレームワーク、ツールを使ったのかを紹介し、その後、ディスカッションの大筋を振り返っていきたいと思います。

デザイン思考とビジュアルコミュニケーション

　リモートワークもだいぶ定着してきましたが、大人数で議論するとなるとまだまだ困難に直面する点は多いのではないでしょうか。そこで今回は、デザイン思考のワークショップ形式を取り入れました。

　デザイン思考とは、デザイナーの思考スタイルを応用した課題解決フレームワークです。発散と収束を繰り返しながら、問題発見／解決に取り組みます。「デザイン」という名前から、ビジネスマンには関係ないと思われがちですが、日常のビジネスミーティングでも効果を発揮します。

　デザイン思考をご存じの方は、付箋を使うイメージをお持ちの方もいらっしゃるかもしれません。オンラインで付箋を使うわけにはいきませんので、ビジュアルコミュニケーションツールを活用します。今回はMURALを利用して、参加者がバーチャル空間で、サイレントブレーンストーミングで付箋に記入しながら、ワークショップを進めていきました。

　ビデオ会議でたくさんの人が発言すると収拾がつかなくなることが予想されますので、まずは、参加者が5分間黙って付箋に入力します。その後、付箋に記入した内容を、口頭で説明しながら参加者にシェアします。

　サイレントブレーンストーミングの良い点は、参加者が等しく自分のアイデアをシェアできる点です。日常の会議では、社内の立場の強い人の発言に重きが置かれたり、声高な人の発言が目立ったりしますが、付箋に書き出すことで多様なアイデアを収集するにはよい手段です。

　こうした「発散」のプロセスで出てきたさまざまなアイデアを、今度はフレームワークを使って整理します。今回は似ているアイデアを「クラスタリング」してアイデアをまとめあげます。こうして、「発散」と「収束」を繰り返し、アイデアを洗練させていきます。

　コミュニティーを始める際には、コミュニティーの目的や活動方針を議論したい場合は多いでしょう。その際には、上記のような手順でデザイン思考ワークショップを取り入れてみることで議論がスムーズになるかと思います。

MLOpsの定義

　まず自己紹介をした後、参加者が考えているMLOpsの定義について、それぞれ発表しました。オンラインの勉強会で全員が発言し意見を共有することはなかなか難しいですが、MURALを使うことで全員の意見を可視化することができ非常に便利でした。

　MLOpsという単語は、2018年頃GoogleのエンジニアがDevOps＋MLを組み合わせて作ったという説が有力です。ただし、明確に定義されている言葉でもなく、また言葉が作られてからまだ数年しかたっていないこともあり、成熟した体系、知識にはなっていないと著者は考えています。そのため、使う人によって定義や考え方が定かではないのが事実です。実際のところ、本勉強会でMLOpsの定義をそれぞれ記載し共有したところ似ている意味はあるものの、必ずしも一致しているわけではないことが明らかになりました（図1参照）。本座談会にはエンジニアからコンサルタントまで幅広い肩書の人が参加しており、人それぞれ異なる役割や視点を持っていることなどが要因ではないかと思われます。

図1　参加者が考えるMLOpsの定義
※編集部注：画像内のテキストを読む場合は、画像をクリックもしくはタップして拡大してください。

　例として一部を取り上げると「データサイエンティスト＆リサーチャーが開発したモデルをシステムに適切に当てはめる行為」や「システムを本番化する上で、データサイエンティストがやること以外すべて」など、機械学習をシステム化する上でのデータサイエンティストの担当で分けていることや、「機械学習（ML）ライフサイクルを支えるもの一式」などライフサイクル全体を指すものなどが挙がりました。

　確かにMLOpsについて明確な定義はありませんが、参加者の共通点として機械学習システムの「ライフサイクル」「エンジニアリング」は確認できました。繰り返しになりますが、この定義について正解はありません。しかし、この後のディスカッションでも何度も話題に挙がりましたが、本コミュニティーとしてのMLOpsの定義を明確化し、コミュニティー参加者の視点をそろえることは必要であると考えています。そこで本記事の最後では、この会を振り返り、コミュニティーにおけるMLOpsの定義を決めたいと思います。

MLOpsにおける日々の悩み

　このコミュニティーの活動を考える上で、MLOpsにおいて皆さんが悩んでいることをヒントにしていきたいと考え、MURALを使って悩みを共有してもらいました。その結果が図2になります。

図2　各人が考えるMLOps/機械学習プロジェクトの悩み

　機械学習プロジェクトのビジネス企画からチームビルディング、システム構築などさまざまな悩みが出てきた中でカテゴリ分けしていくと、6つの共通パターンが見えてきました：

• 精度 - ビジネス実装の段階になると、よりシビアなモデル精度が求めることは当然としても、「明確な精度基準がない」、また「いくら精度を上げても完璧でなければ受け入れてもらえない」などの点が挙がった。中には、人間でも間違う判断なのに「機械には完璧を求める」など、機械学習への期待値のギャップも指摘された。
• 環境面 - 特にセキュリティ上の懸念から各種ツールの利用に対する制限がかかったり、APIを使ったサービス化により多部門や他サービスにモデル予測を公開できなかったりするケースが挙がった。
• 属人化 - モデル運用における方法論はまだ確立されていない上、実際の運用はモデル構築者とは別の部門に任されることが多い。適切な運用管理／監視はもとよりモデルの定期的な再構築などはほとんどの場合、実施されず、行われたとしても属人的な手段に依存していて、担当者が変わっていつの間にか動かなくなってしまうようなこともある。
• 予算 - 多くの場合、MLOpsは新しい取り組みであり、そこには事前に予算がついているケースが少ない。予算を取るためには費用対効果（ROI：Return On Investment）を示すことが必要だが、モデル構築担当側は運用コストまでを考えずにROIを算出しているケースが多い。
• 理解されない - 「産みの苦しみ」という言葉も出るほど、現状はMLOpsの実施に対して周りの理解が少ないため、成功するために巻き込まないといけない人たちからも理解を得ることができず、なかなかプロジェクトを前に進めることができない。
• システム構築 - 機械学習モデルは主にデータサイエンティストがコードを書いているケースが多いが、データサイエンティストが書いたコードは本番実装を前提としていなかったり、エンジニアリングの「お作法」を踏まえていなかったりするため、システム化には手間がかかる（ことが多い）。また、機械学習システムの設計にはまだ十分な経験を持っていないエンジニアがほとんどだ。

　このように、プロジェクト横断的な問題が多く指摘され、どれも機械学習プロジェクトを企画／運用していく上で避けては通れないものばかりでした。ここからもMLOpsの関連領域の広さが分かります。全体を見ると、MLOpsの「今」について一貫性のあるストーリーが見えてきました。

　どの現場も、MLOpsにはまだ経験値が浅く、技術的にも、組織的な側面からも成熟が求められています。

悩みに対する解決策

　悩みが一通り出そろったところで、いよいよ解決に向けてどのようなアクティビティーが求められているのかを検討していきました。同じくMURALを使って、幅出しとカテゴリ分けを行った結果が図3です。