ROI事件ファイル No.507『他社の設備が、データを出さなかった工場』
他社の設備が、データを出さなかった工場
第一章：見える設備、見えない設備
「同じ工場の中で、見える設備と見えない設備がある」
TechGear社のDX推進部長、堀井航太氏は、そう言いながら工場のレイアウト図を開いた。関西拠点。約四十台の設備が、五つの異なるメーカーの製品で構成されている。「各メーカーが自社設備用の可視化システムを提供しているが、自社設備分しか見えない。隣り合った設備の稼働状況が、別の画面でしか確認できない」
「DX推進部としては、どこまで進めたいですか」とClaudeが尋ねた。
「最終的にはグループ全拠点で統合管理ですが、まず関西拠点で動くものを作りたい」と堀井氏が答えた。「ただ、設備メーカーが自社データの公開に消極的。API公開を依頼しても、検討中のまま回答が来ない。データ形式もメーカーごとにバラバラで、統合の前に標準化が必要」
「現場の運用は」と私が尋ねた。
「現場監督が、五つの可視化画面を順に確認しています」と堀井氏が答えた。「画面ごとにログインが必要で、見るのに時間がかかる。結果として、確認頻度が下がる。停止に気づくのが遅れる。原因分析も、メーカー別のレポートを手で集約しないと全体が見えない」
「完璧な統合システムを最初から作ろうとしていますか」とGeminiが尋ねた。
「そうです」と堀井氏が答えた。「全メーカーのデータを統合し、リアルタイムで全設備を一元管理する。これが本来の姿だが、ベンダー協議が進まないので、プロジェクトが止まっています」
「最初から完璧を狙う設計が、止まる原因かもしれません」と私が応じた。「MVPで動くものを先に作りましょう」
第二章：MVPが問う、最小実用構成で始める
「この案件には、MVPが必要です」
Claudeがホワイトボードに三つの文字を書いた。M・V・P。
「MVPとは、Minimum Viable Product——最小実用構成の略で、必要最低限の機能で価値を検証する開発手法です」と私が説明した。「リーンスタートアップで使われる考え方ですが、企業内DXでも有効です。全機能を備えた完成版を最初から作ろうとすると、メーカー協議や標準化に時間を取られてプロジェクトが止まる。動く最小構成を先に作り、現場で使いながら拡張していく方が、結果として早く完成に近づきます」
「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。堀井氏から提供されたデータを入力する。
「月間の管理コストが出ました」とGeminiが読み上げた。「現場監督三名が五つの画面を巡回確認する工数が月平均百八十時間、時給三千八百円で月六十八万四千円。停止検知遅れによる生産損失が月平均二百二十万円——複数画面の確認頻度低下が原因。原因分析のためのメーカー別レポート集約工数が月平均八十時間、月三十万四千円。データが統合されていないことによる改善判断遅延の機会損失が月平均六十万円。DXプロジェクトの停滞による経営層の信頼低下が月平均二十万円——次の投資判断が遅れるコスト。合計で月三百九十八万八千円。年間換算で約四千七百九十万円」
堀井氏が数字を見つめた。「画面巡回の工数が、想定より大きい」
「では、MVPで設計します」と私が続けた。
[M——Minimum：最小機能の特定]
「最初に、最小機能を決めます」とClaudeが言った。「全メーカーのデータ統合は理想ですが、最初から狙いません。今すぐ可能なのは、各メーカーの画面をスクリーン取得し、稼働状態だけを抽出して一画面に集約する『ダッシュボード統合』です。データの中身まで踏み込まず、稼働ステータスだけ。これなら一ヶ月で作れます」
「画面スクレイピングですか」と堀井氏が確認した。
「APIが出てこない以上、画面情報を取得します」と私が応じた。「メーカー側の協議は並行して継続しますが、待たない。スクリーン取得で稼働状況だけ見えれば、現場の確認工数は大きく減ります」
[V——Viable：実用性の確保]
「次に、実用性です」とGeminiが続けた。「最小機能でも、現場が使い続ける価値がなければ意味がない。最低限必要なのは、五メーカー全設備の稼働ステータスがリアルタイムで一画面に表示されること。アラート機能、過去履歴、原因分析機能は、最小版に含めません。後の段階で追加します」
[P——Product：プロダクトとして使える形に]
「現場で使えるプロダクトとして仕上げます」と私が続けた。「タブレットで現場のどこからでも見られる、ログイン一回で全画面に届く、ステータス変化が一目で分かる色分け——これだけは整える。最小機能でも、プロダクトとしての完成度がないと、現場が使わない」
[拡張ロードマップ]
「MVPは固定された最終形ではありません」とClaudeが続けた。「拡張ロードマップを並行して作ります。第二段階——メーカー協議が進んだメーカーから順次API連携、データの中身も取得。第三段階——アラート機能と原因分析機能を追加。第四段階——関西拠点での運用実績を持って、他拠点展開。段階ごとに必要な投資判断を独立して行います」
[投資回収を試算する]
「ROI Proposal Generatorで試算しましょう」とGeminiが提案した。
「MVPフェーズの試算です」
- 初期費用：MVP開発（スクリーン取得・ダッシュボード統合・タブレット端末・現場研修）合計三百二十万円
- 月次費用：MVP運用基盤利用料月八万円
- 月次削減効果：画面巡回工数削減＝月四十八万円（七割削減想定）、停止検知遅れ削減＝月百三十二万円（六割削減想定）、レポート集約工数削減＝月二十一万円、合計月二百一万円
- 月次純削減：二百一万円－八万円＝月百九十三万円
- MVP投資回収期間：三百二十万円÷百九十三万円＝約一・七ヶ月
「二ヶ月以内です」とGeminiが整理した。「MVPの投資回収が早いことで、第二段階以降の投資判断がしやすくなります。完璧な統合システムを五千万円で作るか、MVPを三百万円で作って効果を確認してから拡張するか——後者の方が経営判断としても合理的です」
堀井氏が数字を確認しながら言った。「ベンダー協議が進まないことを、プロジェクト停滞の理由にしていました。先に動かせる範囲で動かす、という発想がなかった」
「動くものを先に作れば、協議も進みます」と私が応じた。
第三章：動くものから始める計画
「進め方を整理します」と私がホワイトボードの前に立った。
「第一週——五メーカー画面のスクリーン取得方式の技術検証。第二・三週——ダッシュボード設計、稼働ステータス抽出ロジック実装。第四週——タブレット端末配備、現場での試用。第五・六週——現場フィードバックを反映した調整、本稼働。第七・八週——関西拠点の運用実績の蓄積。第九週以降——メーカー協議の継続、API連携可能なメーカーから第二段階へ」
「ベンダー協議は止めますか」と堀井氏が確認した。
「並行で続けます」とClaudeが応じた。「ただ、協議の結果を待たない。MVPで実績が出ていれば、メーカー側も自社設備が他社設備と並んでステータス表示されている状況を見て、API公開の動機を持つようになります。動いている事実が、協議を加速させます」
堀井氏がメモを取りながら言った。「最初から完璧を狙ったから止まっていた、と整理できました」
第四章：五画面が、一画面になった日
八ヶ月後、堀井氏から報告が届いた。
MVP稼働三ヶ月後、現場監督の画面巡回工数は従来比で七十二パーセント削減。一画面のダッシュボードで五メーカー全設備の稼働ステータスが確認可能になった。「巡回ではなく、一目見れば全体が分かる。確認頻度が大幅に上がった」と堀井氏は記していた。
停止検知も大幅に高速化。ステータス変化がリアルタイムで色分け表示されるため、稼働灯が赤になった瞬間に気づくようになった。「平均検知時間が、十二分から二分に短縮した」と報告書にあった。
最も意外な変化は、メーカー側の対応に表れた。MVP稼働後、二社のメーカーから自発的にAPI連携の提案があった。「自社の設備だけ取得情報が少ない状況が見えてしまうことが、メーカー側の動機になった」と堀井氏は記していた。第二段階の拡張が、想定より早く始まった。
第二段階では、API連携した二社のデータが詳細レベルまで取得可能に。稼働率、停止理由、保全履歴の統合が進んだ。残り三社も、現在API公開の検討が進んでいる。「動いているものに合流したい、という心理が働いた」と報告書にあった。
他拠点展開も加速した。関西拠点でのMVP実績を見て、東日本拠点と中部拠点が同様の構成を希望。第三段階として、三拠点同時展開が進行中。「関西拠点で価値が証明されたことで、他拠点の経営層が判断しやすくなった」と堀井氏は記していた。
副次効果として、現場と本社の関係が変わった。これまで「本社のDX推進は現場を見ていない」という不満があったが、MVPが現場で使われている実績を経て、本社主導のDX施策が受け入れられやすくなった。「動くものを現場に置いた効果は、技術以外の部分でも大きい」と報告書にあった。
堀井氏の報告書の最後にはこう書かれていた。「完璧を狙って止まっていたプロジェクトが、最小実用構成で動いた瞬間に加速した。動いているという事実が、止まっていた協議を進めた。MVPは妥協ではなく、戦略だった」
五画面の巡回が一画面の確認に変わった日、止まっていたのはシステムではなく、判断だった、と記されていた。
「DXプロジェクトが止まる理由の多くは、技術ではなく、完璧主義にある。全機能を備えた完成版を最初から作ろうとすると、調整事項が増え、関係者協議が長期化し、プロジェクトは凍結する。MVPが問うのは、動かす範囲の最小化だ。最小機能でも、実用に耐え、プロダクトとして使える形であれば、現場で価値を出す。動いている事実が、止まっていた協議を動かす。五画面が一画面になった日、変わったのは画面の数ではなく、判断の速度だった」
関連ファイル
使用ツール
- ROI Polygraph — 画面巡回工数・停止検知遅れ・プロジェクト停滞コストの可視化
- ROI Proposal Generator — MVP段階導入の投資回収シミュレーション
