【DB勉強会】10_データビジネスの保守・運用

【製造業データビジネス勉強会】10 データビジネスの保守・運用 2026/07/07 @shimitaka1982 清水 隆史

今日の 勉強どころ

データビジネスの階層構造 プロセス 現時点の 個人的な感触 新規事業創出 プロジェクトマネジメント ビジネスモデル 要求分析・要件定義 プロダクトマネジメント リスクマネジメント プラクティ ス マインドセット 人材育成 ビジネス力 データサイエンス力 データエンジニアリング 力

データビジネスの進め方 ① 事業設計 ⑧ マ ③ データ準備 ー ④ 探索的データ分析 ケ テ ⑤ モデル構築 ィ ン ⑥ 社会実装 グ ⑦ 保守・運用 ② サービス設計 現時点の 個人的な感触 • いずれも単方向ではなく、 行ったり来たりを繰り返す • 全てを行うわけではなく、 途中から始まったり途中で 終わったりすることもある • 初期の段階で後期の要素を 考えておく必要がある

本当にあった 怖い話

怖い話１：システム不具合 あるところに、IPカメラによって継続的に動画が取得 され、その動画を自動的に解析して人物の行動を検出 できるソリューションがありました そのソリューションが商用リリースされ、実際にお客 様の施設にIPカメラが設置され運用が開始されました 運用が開始されて1ヶ月後。あることが分かりました。 「あれ？2週間目からデータが取れてない…」 *私が実際に体験したり見聞きした話を概要レベルで紹介

怖い話１：システム不具合 実はそのIPカメラ（システム）は耐久性の検証がされ ておらず、PoCでは1週間しか稼働させたことが無かっ たため、1ヶ月間の稼働はしたことがありませんでした。 当然動くだろうと思っていたので、 途中でデータが取れなくなるといった ことも想像していませんでした。 そのことをお客様に報告したところ こっぴどく怒られ、契約は破談と なりました。

怖い話２：データ取得不具合 あるところに、外部データをAPI経由で 取得して、そのデータを加工して顧客に 価値を提供するソリューションがありました。 そのソリューションが商用リリースされ、実際にお客 様が利用を始めました。 ある日、お客様から営業担当の元に連絡がありました。 「1週間前からシステムにアクセスしてもデータが表示 されないんだけど…」

怖い話２：データ取得不具合 慌ててエンジニアが調査を行ったところ、なんとその 外部データのデータスキーマがいつの間にか変わって おり、APIエラーがずっと出続けていました。 そのエンジニアは他の新しいサービス開発をしていた ので、ログを見に行くまでまったくそのことには気付 きませんでした。 このことをお客様に報告したところ こっぴどく怒られ、契約は破談と なりました。

怖い話３：モデルの精度低下 あるところに、市場データを分析して とある商品の需要予測を行うサービスが ありました。 そのサービスが商用リリースされ、実際にお客様が利 用を始めました。 ある日、お客様から営業担当の元に連絡がありました。 「なんだか精度が低いような気がするんだけど…」

怖い話３：モデルの精度低下 慌ててデータサイエンティストが調べたところ、需要 予測の為に使っているデータの内容が季節によりだい ぶ変わっており、それによって予測精度が落ちている ことが分かりました。 そのことをお客様にお伝えしたところ、 「そんなことは知ったこっちゃない！」 とこっぴどく怒られ、契約は破談と なりました。（※需要予測が外れて 損失が発生してしまっていた）

どうして こうなった

怖い話１：システム不具合 1ヶ月間の運用テストが出来ていれば良かった （※これは保守・運用というより開発におけるテスト の話になる） 場合によっては運用テストでも不具合が発生しない場 合がある。ただ、運用においてすぐに「データが取れ ていない」ということに気付いていれば、その時に修 復が出来て、被害は最小限に抑えられたはず

怖い話１：システム不具合 つまり テスト不足 および 保守・運用プロセス 構築漏れ

怖い話２：データ取得不具合 データスキーマが変わったということが検知出来れば よかった データスキーマが変わったということは検知できなく ても、APIエラーが出ているということが検知出来れば よかった さらに、そのエラーを検知したらすぐに原因調査が出 来るようなログが仕込めていれば良かった

怖い話２：データ取得不具合 つまり 監視不足 および 開発時の運用想定不足

怖い話３：モデルの精度低下 開発段階でデータが季節変動するということに気付け ていれば良かった 運用においてモデルの精度が基準を満たしているかを 毎回監視し、もし基準を下回ったら気付けていれば良 かった （例えば、AUC=0.6を下回ったら発報する、など）

怖い話３：モデルの精度低下 つまり モデル開発時の検討不足 および モデル精度の監視設計不足

価値を潰してしまっている これまでの怖い話は、「コト売り」における継続的な 価値創出に失敗してしまっている、といえる ここに失敗 【DB勉強会】02_新規事業創出とビジネスモデル https://www.docswell.com/s/shimitaka/KY8D6P-data-business-benkyo-02#p37

• https://www.docswell.com/s/shimitaka/KY8D6P-data-business-benkyo-02#p37

お金がもらえず信頼も失墜する 一番最悪なのが、こういったことが発生すると顧客か らお金を頂けなくなる。つまり、ビジネスとして成立 しなくなってしまう＝事業として失敗する これだけ頑張って開発してきてようやくリリースした のに、最後の最後でお客様に価値を届けられず、信頼 も失墜し、お金ももらえない こんなにみじめなことはない

どうすれば よかったか

保守・運用のことをちゃんと考える 運用・保守のことをちゃんと考える、それに尽きる 保守・運用のことをサービス設計に組み込む 保守・運用を行う体制をつくる 保守・運用をしっかり行うことによって継続的な売上 が生まれる、というマインドセットを醸成する 地味でもカッコ悪くても愚直にやる

保守・運用のことをちゃんと考える つまり、勝負は最初の方の 事業設計やサービス設計に かかっている ここで後段の保守・運用の ことを考えて体制や設計や マインドセット情勢ができるか が勝負の分かれ目になる

保守・運用のことをちゃんと考える 実はこのあたりの話は、昨日・今日出てきたような新 しい概念ではない 古くからソフトウェア工学、システムズエンジニアリ ング、ITサービスマネジメント（ITIL）などで散々言わ れてきた「サービスを安定して顧客に届け続けるため の知恵」である サービスビジネスにおいてはリリースはスタートライ ンであり、保守・運用こそが価値を生み出し続ける源 泉である

保守・運用のことをちゃんと考える こういう話をすると、「まだそこまで考えられる余裕 はない」「まずは売れるサービスを創るのが先だ」 「それは私たちの考えることではない」といった言葉 を聞くことがある じゃあ、いつ、誰が、考えるのか？ そこに誰がどのように責任を持つのか？ 私はこれはオーナーシップの問題だと考えている

（参考）なぜ保守・運用は後回し？ 研究者は精度の高いモデルを構築する方が 楽しい（※コードのバージョン管理や24/365 止まらないシステムの構築・運用は専門外） 個人的な感触 です エンジニアは動くシステム・アプリを作る方が楽しい 営業・企画はお客様や社内関係者が喜ぶアイデアを考 えるのが仕事（だと思ってる） 管理者・経営者は保守・運用という仕事の本質を正し く評価できていない（または、製造業ではそもそもシ ステムの保守・運用という仕事を知らない）

MLOpsの話

MLOpsとは Google Geminiさんの見解 MLOps（Machine Learning Operations）とは、機 械学習（ML）モデルを効率的に開発し、本番環境へ導 入・安定運用するための手法、プロセス、および基盤 （システム）の総称です。 ソフトウェア開発における「DevOps」の考え方を機 械学習に応用したもので、「データサイエンティスト （開発）」と「機械学習エンジニア / ITインフラ運用 （運用）」が連携し、ビジネス価値を継続的に生み出 すことを目的にしています。

DevOpsの理念 文化（Culture） 自動化（Automation） メトリクス（Metrics） 共有（Sharing） 4つの頭文字をとってCAMSと 呼ばれる [出典]実践MLOps: 作って理解する機械学習システムの構築と運用 https://amzn.asia/d/04DQ3i0v

• https://amzn.asia/d/04DQ3i0v

DevOps実践時の要素 継続的インテグレーション（CI）と継続的デリバリー （CD）による高頻度なリリース 継続的テスト 品質保証 継続的監視 ロギング フィードバックループ [出典]実践MLOps: 作って理解する機械学習システムの構築と運用 https://amzn.asia/d/04DQ3i0v

• https://amzn.asia/d/04DQ3i0v

MLOpsの場合 MLOpsは、DevOpsを機械学習システムに適用した ものなので、ほぼDevOpsの理念と実装時の要素が当 てはまる 先の3つの怖い話は、どれもMLOpsの考え方をあらか じめ理解していれば対応が出来たかもしれない

怖い話１の場合

怖い話２の場合

怖い話３の場合

MLOpsに関する所感 MLOpsは、まずは本質を知って「そういう考え方が 必要なんだ」と認識するのがスタートだと考える 運用・保守は、究極的には人で対応するか、ツールで 自動化するか、の2択しかない（もちろん、一部を人 で対応して、一部をツールで対応する、といったグラ デーションはあるが） MLOpsの理念としては自動化が含まれているが、 ツールを使うことに囚われずに、まずは「何をすべき か」を理解することが大事

まとめ 保守・運用はサービスビジネスにおける価値創出の要 であるにも関わらず不遇な扱いを受けがち 保守・運用やMLOpsの「本質」をしっかり理解して、 早い段階から設計に組み込もう！ 保守・運用を地味に愚直にしっかりこなすことで、 継続的に価値を届けられるサービスビジネスを創ろう！

製造業データビジネス勉強会 おわり