ROI事件ファイル No.451『鉄の記憶を持つ工場』
鉄の記憶を持つ工場
第一章：三十年前の記憶
「自社で作るべきか、買うべきか。それが分からないのです」
TechNova社のIT推進担当、村上亮介氏は、そう言いながら一枚のシステム構成図をテーブルに広げた。紙は黄ばんでいる。右下の作成日付には、1995年の数字が刻まれていた。
「当社の基幹システムは、IBM系のものをベースに自社開発に近い形で構築しています。三十年、動き続けています」
「現役ですか」とClaudeが確認した。
「ええ。止めるわけにいかない。製造ラインがこのシステムに依存していますから。ただ——」村上氏が指先でシステム構成図の一点を叩いた。「このデータ形式が、問題です。独自フォーマットで出力されるため、最新のAIツールがそのまま読み込めない」
「具体的にどんな業務でAIを使いたいですか」と私は尋ねた。
「四つあります」と村上氏が指を折った。「異常検知、需要予測、類似図面の検索、見積書の自動作成。特に見積書は、一件あたり平均三時間かかっています。営業担当が四名いて、多い月は四十件を超える。計算すると——」
「月に百二十時間、見積書だけに消えている」とGeminiが静かに言った。
村上氏が頷いた。「そこにAIを当てたい。ただ、基幹システムから出力したCSVデータ、CADデータ、顧客からもらうPDFの図面——三種類が別々の場所にある。これを連携させるには既製品では無理だと言われました。だから自社開発を検討していますが、費用と時間が掛かりすぎて判断できずにいる」
その言葉の中に、事件の核心があった。「自社か既製品か」という問いは、本当の問いではない。本当の問いは、どこから始めるか、だ。
第二章：HEARTが問う五つの温度
「この案件には、HEARTが必要です」
Claudeがホワイトボードに五つのアルファベットを書いた。H・E・A・R・T。
「HEARTは、Googleが提唱したユーザー体験の評価フレームワークです」と私が説明を始めた。「Happiness（満足度）、Engagement（エンゲージメント）、Adoption（採用率）、Retention（継続利用率）、Task success（タスク成功率）——この五つの指標で、ツールが現場に根付くかを判断します。自社か既製品かを決める前に、現場の温度を測る必要があります」
「まず、ROI Polygraphで現状を整理させてください」とGeminiがノートパソコンを開いた。村上氏から提供されていた業務ログをROI Polygraphに入力する。ツールはしばらくして結果を返した。
「面白い数字が出ました」とGeminiが画面を見ながら言った。「見積書作成の三時間のうち、AIが代替できる定型作業の割合は六十八パーセントです。残りの三十二パーセントは、担当者の経験則に基づく判断が入っている」
「つまり」と私が引き取った。「全体を自社開発AIで置き換えようとすると、三十二パーセントの『判断』の部分まで作り込まなければならない。それが開発コストを押し上げている」
村上氏が眉を動かした。「言われてみれば——見積書で一番時間がかかるのは、仕様の読み込みと、過去の類似案件を記憶から引っ張り出す作業です。数字を入れる作業自体はそれほどでもない」
「そこがHEARTの出発点です」とClaudeが続けた。
[H——Happiness：現場が使いたいと思えるか]
「村上さん、営業担当四名は今の見積書作成業務をどう感じていますか」
「全員が、重荷だと言っています」と村上氏が即答した。「特に月末は、見積書のために残業が発生している」
「現場のHappinessの土台はある。ツールが仕事を減らしてくれると実感できれば、受け入れられます。問題は——」
「実感できるかどうか、ですね」と村上氏が先を読んだ。
[E——Engagement：日常業務に溶け込んでいるか]
「エンゲージメントの問題は使用頻度に表れます」とGeminiが続けた。「見積書作成は月四十件以上。一方、異常検知や需要予測は、担当者が意識的に確認しないと使われない可能性がある。見積書支援は『毎日使う』道具になりやすく、異常検知は『あった方がいい』で止まるリスクがある」
「だとすると」と私が整理した。「最初に導入すべきは、見積書の自動作成支援です。エンゲージメントが最も高くなる場所から始める」
[A——Adoption：技術に不慣れな担当者でも使えるか]
「採用率の観点が、自社か既製品かの判断を左右します」とClaudeが指摘した。「営業担当の年齢層は」
「三十代が二名、五十代が二名です。五十代の二名は、システム全般に不慣れで——」
「そこが分岐点です。採用率を高めるには、最初の体験が鍵です。最初に複雑なツールを渡すと、五十代の二名がついてこれない。既製品の中でも、最もシンプルなUIのものから始めてください」
[R——Retention：三ヶ月後も使い続けているか]
「継続利用率の問題は、データ連携の壁に直結します」とGeminiが続けた。「CSV、CAD、PDFが別々にある状態では、担当者がツールを使うたびにデータを手動で揃えなければならない。その手間が、三ヶ月後の離脱を生みます。AIツールを入れる前に、この三種類を一か所に集めるデータ基盤の整備が先決です」
「それが——自社開発が必要になる部分ですね」と村上氏が気づいた。
「正確には」とClaudeが修正した。「データ連携の部分は自社で作り、その上に乗るAI機能は既製品を使う、という組み合わせです。全部を自社開発する必要はない」
[T——Task success：仕事が実際に終わるか]
「最後のTask successは、最もシンプルな問いです」とGeminiが締めた。「見積書が、以前より短い時間で、同じ品質で完成するか。ROI Polygraphの試算では、データ連携基盤を整備した上で既製品AIを導入した場合、見積書一件あたりの作成時間は三時間から五十分前後に短縮できる見込みです。月四十件で計算すると、月に約八十時間の工数削減です」
第三章：分岐点の地図
「整理すると」と私がホワイトボードの前に立った。「今回の判断は、全部自社開発か全部既製品かではありません。HEARTの五指標によって、作るべき部分と使うべき部分が明確に分かれました」
Claudeが図を描いた。
- 自社で作る部分： 三種類のデータを統合するデータ連携基盤
- 既製品を使う部分： その上で動く見積書支援AI（まず一機能から）
- 後続フェーズ： 異常検知、需要予測、類似図面検索
「ROI Proposal Generatorで投資計画を試算しましょう」と私が提案した。データ連携基盤の構築費用、既製品AI導入費用、工数削減効果——試算が返ってきた。投資回収期間は十一ヶ月。全部自社開発した場合と比較すると、回収期間が半分以下になる。
「なぜこれほど差が出るのですか」と村上氏が聞いた。
「自社開発の場合、完成まで業務改善の恩恵を受けられない空白期間が生じます」とClaudeが答えた。「既製品プラス自社基盤の場合、データ連携が完成した時点で即座に価値が出始める。時間の価値が、数字に表れています」
村上氏が深く頷いた。「分かりました。まずデータ連携基盤を作り、その上で見積書支援AIを一つ試す、から始めます」
「パイロット期間は三ヶ月を設定してください」とGeminiが付け加えた。「HEARTの五指標を週次で記録し、三ヶ月後に数字で判断する。その結果を持って、異常検知と需要予測への展開を決める。その順序が、三十年前の基幹システムと向き合う最も安全な道です」
第四章：鉄の記憶が目を覚ます朝
村上氏が立ち上がり、1995年のシステム構成図を丁寧に折りたたんだ。
「三十年間、このシステムは正確に動き続けてきました。だから誰も触りたくなかった。今回も、AIを乗せる前に基盤を作る——同じ考え方ですね。土台を壊さずに、上に積み上げていく」
「HEARTの本質は」と私が応じた。「ツールの性能ではなく、使う人間の体験を設計することです。どれだけ優れたAIも、担当者が使い続けなければ意味がない。五つの温度計が正常値を示している状態を、最初から設計する。それが、自社開発か既製品かという問いの前に来るべき問いです」
窓の外では、工場地帯の朝の光が金属の屋根に反射していた。
五ヶ月後、村上氏から報告が届いた。
データ連携基盤の構築から三週間後、見積書支援AIのパイロット運用を開始。三ヶ月のパイロット期間で、HEART五指標はいずれも基準値を超えた。最も大きな変化は、五十代の担当者二名が「これなら使える」と自発的に使用頻度を上げたことだった。
見積書一件あたりの作成時間は、三時間から四十七分に短縮。月間工数削減は約八十五時間。投資回収期間の試算は十一ヶ月だったが、実績では九ヶ月に前倒しされる見通しになった。
村上氏は報告書にこう記していた。「最初にデータ基盤を作ると決めた時、社内には反対意見もありました。すぐにAIを使いたいという声でした。しかし、土台がない状態でツールを入れても、誰も使わなかったと思います。HEARTは、その順序を教えてくれたフレームワークでした」
三十年の鉄の記憶を持つ工場が、新しい言葉を覚え始めた日だった。
「自社開発か既製品かという問いは、本当の問いではない。本当の問いは、使う人間の体験が設計されているか、だ。HEARTが問う五つの指標——満足度、エンゲージメント、採用率、継続利用率、タスク成功率——はいずれも、ツールの話ではなく、人の話だ。三十年前のシステムが生き続けてきた理由は、現場がそれを信頼し、使い続けたからだ。新しいAIも、同じ問いから設計するべきだ」
関連ファイル
使用ツール
- ROI Polygraph — 業務ログの分析と代替可能工数の可視化
- ROI Proposal Generator — 自社開発vs既製品の投資回収シミュレーション
