--- title: 【DB勉強会】10_データビジネスの保守・運用 tags: #製造業データビジネス勉強会 author: [shimitaka（清水隆史）](https://docswell.com/user/shimitaka) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/K74W532YE1.jpg?width=480 description: （AIによる要約） 本資料では、データビジネスの階層構造と進め方を示した上で、システム不具合、データ取得エラー、モデル精度低下という3つの失敗事例を紹介しています。各事例から、テスト不足や監視不足、モデル開発時の考慮不足が原因であることを指摘し、保守・運用を設計段階に組み込む重要性を説明しています。また、継続的な価値創出のためにMLOpsの概念と実践が必要であることを提案しています。 published: July 06, 26 canonical: https://docswell.com/s/shimitaka/KR89X4-data-business-benkyo-10 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/K74W532YE1.jpg) 【製造業データビジネス勉強会】10 データビジネスの保守・運用 2026/07/07 @shimitaka1982 清水 隆史 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/LJ1YW1MNEG.jpg) 今日の 勉強どころ # Page. 3 ![Page Image](https://bcdn.docswell.com/page/GJWG68DM72.jpg) データビジネスの階層構造 プロセス 現時点の 個人的な感触 新規事業創出 プロジェクトマネジメント ビジネスモデル 要求分析・要件定義 プロダクトマネジメント リスクマネジメント プラクティ ス マインドセット 人材育成 ビジネス力 データサイエンス力 データエンジニアリング 力 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/4EZLY8GM73.jpg) データビジネスの進め方 ① 事業設計 ⑧ マ ③ データ準備 ー ④ 探索的データ分析 ケ テ ⑤ モデル構築 ィ ン ⑥ 社会実装 グ ⑦ 保守・運用 ② サービス設計 現時点の 個人的な感触 • いずれも単方向ではなく、 行ったり来たりを繰り返す • 全てを行うわけではなく、 途中から始まったり途中で 終わったりすることもある • 初期の段階で後期の要素を 考えておく必要がある # Page. 5 ![Page Image](https://bcdn.docswell.com/page/Y76WDPY57V.jpg) 本当にあった 怖い話 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/G75M3KGG74.jpg) 怖い話１：システム不具合 あるところに、IPカメラによって継続的に動画が取得 され、その動画を自動的に解析して人物の行動を検出 できるソリューションがありました そのソリューションが商用リリースされ、実際にお客 様の施設にIPカメラが設置され運用が開始されました 運用が開始されて1ヶ月後。あることが分かりました。 「あれ？2週間目からデータが取れてない…」 *私が実際に体験したり見聞きした話を概要レベルで紹介 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/9J29ZWYDER.jpg) 怖い話１：システム不具合 実はそのIPカメラ（システム）は耐久性の検証がされ ておらず、PoCでは1週間しか稼働させたことが無かっ たため、1ヶ月間の稼働はしたことがありませんでした。 当然動くだろうと思っていたので、 途中でデータが取れなくなるといった ことも想像していませんでした。 そのことをお客様に報告したところ こっぴどく怒られ、契約は破談と なりました。 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/DEY4RLGMJM.jpg) 怖い話２：データ取得不具合 あるところに、外部データをAPI経由で 取得して、そのデータを加工して顧客に 価値を提供するソリューションがありました。 そのソリューションが商用リリースされ、実際にお客 様が利用を始めました。 ある日、お客様から営業担当の元に連絡がありました。 「1週間前からシステムにアクセスしてもデータが表示 されないんだけど…」 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/VJNYD4G378.jpg) 怖い話２：データ取得不具合 慌ててエンジニアが調査を行ったところ、なんとその 外部データのデータスキーマがいつの間にか変わって おり、APIエラーがずっと出続けていました。 そのエンジニアは他の新しいサービス開発をしていた ので、ログを見に行くまでまったくそのことには気付 きませんでした。 このことをお客様に報告したところ こっぴどく怒られ、契約は破談と なりました。 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/YE9PGQWPJ3.jpg) 怖い話３：モデルの精度低下 あるところに、市場データを分析して とある商品の需要予測を行うサービスが ありました。 そのサービスが商用リリースされ、実際にお客様が利 用を始めました。 ある日、お客様から営業担当の元に連絡がありました。 「なんだか精度が低いような気がするんだけど…」 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/GE8DVGNXED.jpg) 怖い話３：モデルの精度低下 慌ててデータサイエンティストが調べたところ、需要 予測の為に使っているデータの内容が季節によりだい ぶ変わっており、それによって予測精度が落ちている ことが分かりました。 そのことをお客様にお伝えしたところ、 「そんなことは知ったこっちゃない！」 とこっぴどく怒られ、契約は破談と なりました。（※需要予測が外れて 損失が発生してしまっていた） # Page. 12 ![Page Image](https://bcdn.docswell.com/page/LELM5GPN7R.jpg) どうして こうなった # Page. 13 ![Page Image](https://bcdn.docswell.com/page/4JMY3Q4QJW.jpg) 怖い話１：システム不具合 1ヶ月間の運用テストが出来ていれば良かった （※これは保守・運用というより開発におけるテスト の話になる） 場合によっては運用テストでも不具合が発生しない場 合がある。ただ、運用においてすぐに「データが取れ ていない」ということに気付いていれば、その時に修 復が出来て、被害は最小限に抑えられたはず # Page. 14 ![Page Image](https://bcdn.docswell.com/page/PJR9Q8WK79.jpg) 怖い話１：システム不具合 つまり テスト不足 および 保守・運用プロセス 構築漏れ # Page. 15 ![Page Image](https://bcdn.docswell.com/page/PEXQ58P5JX.jpg) 怖い話２：データ取得不具合 データスキーマが変わったということが検知出来れば よかった データスキーマが変わったということは検知できなく ても、APIエラーが出ているということが検知出来れば よかった さらに、そのエラーを検知したらすぐに原因調査が出 来るようなログが仕込めていれば良かった # Page. 16 ![Page Image](https://bcdn.docswell.com/page/3EK96KDRED.jpg) 怖い話２：データ取得不具合 つまり 監視不足 および 開発時の運用想定不足 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/L73W6ZRG75.jpg) 怖い話３：モデルの精度低下 開発段階でデータが季節変動するということに気付け ていれば良かった 運用においてモデルの精度が基準を満たしているかを 毎回監視し、もし基準を下回ったら気付けていれば良 かった （例えば、AUC=0.6を下回ったら発報する、など） # Page. 18 ![Page Image](https://bcdn.docswell.com/page/87DKVRYNJG.jpg) 怖い話３：モデルの精度低下 つまり モデル開発時の検討不足 および モデル精度の監視設計不足 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/VJPKVW6NE8.jpg) 価値を潰してしまっている これまでの怖い話は、「コト売り」における継続的な 価値創出に失敗してしまっている、といえる ここに失敗 【DB勉強会】02_新規事業創出とビジネスモデル https://www.docswell.com/s/shimitaka/KY8D6P-data-business-benkyo-02#p37 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/2EVVZ83YEQ.jpg) お金がもらえず信頼も失墜する 一番最悪なのが、こういったことが発生すると顧客か らお金を頂けなくなる。つまり、ビジネスとして成立 しなくなってしまう＝事業として失敗する これだけ頑張って開発してきてようやくリリースした のに、最後の最後でお客様に価値を届けられず、信頼 も失墜し、お金ももらえない こんなにみじめなことはない # Page. 21 ![Page Image](https://bcdn.docswell.com/page/57GL453WEL.jpg) どうすれば よかったか # Page. 22 ![Page Image](https://bcdn.docswell.com/page/4EQYGZ5QJP.jpg) 保守・運用のことをちゃんと考える 運用・保守のことをちゃんと考える、それに尽きる 保守・運用のことをサービス設計に組み込む 保守・運用を行う体制をつくる 保守・運用をしっかり行うことによって継続的な売上 が生まれる、というマインドセットを醸成する 地味でもカッコ悪くても愚直にやる # Page. 23 ![Page Image](https://bcdn.docswell.com/page/KJ4W539Y71.jpg) 保守・運用のことをちゃんと考える つまり、勝負は最初の方の 事業設計やサービス設計に かかっている ここで後段の保守・運用の ことを考えて体制や設計や マインドセット情勢ができるか が勝負の分かれ目になる # Page. 24 ![Page Image](https://bcdn.docswell.com/page/LE1YW1KN7G.jpg) 保守・運用のことをちゃんと考える 実はこのあたりの話は、昨日・今日出てきたような新 しい概念ではない 古くからソフトウェア工学、システムズエンジニアリ ング、ITサービスマネジメント（ITIL）などで散々言わ れてきた「サービスを安定して顧客に届け続けるため の知恵」である サービスビジネスにおいてはリリースはスタートライ ンであり、保守・運用こそが価値を生み出し続ける源 泉である # Page. 25 ![Page Image](https://bcdn.docswell.com/page/GEWG68PMJ2.jpg) 保守・運用のことをちゃんと考える こういう話をすると、「まだそこまで考えられる余裕 はない」「まずは売れるサービスを創るのが先だ」 「それは私たちの考えることではない」といった言葉 を聞くことがある じゃあ、いつ、誰が、考えるのか？ そこに誰がどのように責任を持つのか？ 私はこれはオーナーシップの問題だと考えている # Page. 26 ![Page Image](https://bcdn.docswell.com/page/47ZLY8KMJ3.jpg) （参考）なぜ保守・運用は後回し？ 研究者は精度の高いモデルを構築する方が 楽しい（※コードのバージョン管理や24/365 止まらないシステムの構築・運用は専門外） 個人的な感触 です エンジニアは動くシステム・アプリを作る方が楽しい 営業・企画はお客様や社内関係者が喜ぶアイデアを考 えるのが仕事（だと思ってる） 管理者・経営者は保守・運用という仕事の本質を正し く評価できていない（または、製造業ではそもそもシ ステムの保守・運用という仕事を知らない） # Page. 27 ![Page Image](https://bcdn.docswell.com/page/YJ6WDPQ5JV.jpg) MLOpsの話 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/GJ5M3KRGJ4.jpg) MLOpsとは Google Geminiさんの見解 MLOps（Machine Learning Operations）とは、機 械学習（ML）モデルを効率的に開発し、本番環境へ導 入・安定運用するための手法、プロセス、および基盤 （システム）の総称です。 ソフトウェア開発における「DevOps」の考え方を機 械学習に応用したもので、「データサイエンティスト （開発）」と「機械学習エンジニア / ITインフラ運用 （運用）」が連携し、ビジネス価値を継続的に生み出 すことを目的にしています。 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/LE3W6ZPPE5.jpg) DevOpsの理念 文化（Culture） 自動化（Automation） メトリクス（Metrics） 共有（Sharing） 4つの頭文字をとってCAMSと 呼ばれる [出典]実践MLOps: 作って理解する機械学習システムの構築と運用 https://amzn.asia/d/04DQ3i0v # Page. 30 ![Page Image](https://bcdn.docswell.com/page/8EDKVRL37G.jpg) DevOps実践時の要素 継続的インテグレーション（CI）と継続的デリバリー （CD）による高頻度なリリース 継続的テスト 品質保証 継続的監視 ロギング フィードバックループ [出典]実践MLOps: 作って理解する機械学習システムの構築と運用 https://amzn.asia/d/04DQ3i0v # Page. 31 ![Page Image](https://bcdn.docswell.com/page/V7PKVW2PJ8.jpg) MLOpsの場合 MLOpsは、DevOpsを機械学習システムに適用した ものなので、ほぼDevOpsの理念と実装時の要素が当 てはまる 先の3つの怖い話は、どれもMLOpsの考え方をあらか じめ理解していれば対応が出来たかもしれない # Page. 32 ![Page Image](https://bcdn.docswell.com/page/2JVVZ8DVJQ.jpg) 怖い話１の場合 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/5EGL45Y1JL.jpg) 怖い話２の場合 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/4JQYGZMN7P.jpg) 怖い話３の場合 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/K74W53V3E1.jpg) MLOpsに関する所感 MLOpsは、まずは本質を知って「そういう考え方が 必要なんだ」と認識するのがスタートだと考える 運用・保守は、究極的には人で対応するか、ツールで 自動化するか、の2択しかない（もちろん、一部を人 で対応して、一部をツールで対応する、といったグラ デーションはあるが） MLOpsの理念としては自動化が含まれているが、 ツールを使うことに囚われずに、まずは「何をすべき か」を理解することが大事 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/LJ1YW13ZEG.jpg) まとめ 保守・運用はサービスビジネスにおける価値創出の要 であるにも関わらず不遇な扱いを受けがち 保守・運用やMLOpsの「本質」をしっかり理解して、 早い段階から設計に組み込もう！ 保守・運用を地味に愚直にしっかりこなすことで、 継続的に価値を届けられるサービスビジネスを創ろう！ # Page. 37 ![Page Image](https://bcdn.docswell.com/page/GJWG68P672.jpg) 製造業データビジネス勉強会 おわり