中小建設会社A社の現場管理アプリ導入ユースケース：紙作業からデジタル化へ

プロジェクト背景とA社の課題

中小建設会社A社は、地域密着型の工務店として50年以上にわたり地元の住宅建築を手がけてきました。これまで現場管理は、現場監督が手書きで毎日の施工進捗や材料消費を記録し、月次で本社に報告するというアナログ運用を続けていました。しかし、近年の人手不足や工期短縮の要請を受け、紙とエクセルベースの管理方法では、情報共有の遅延や転記ミスが原因で追加費用が発生するケースが増えていました。たとえば、ある現場では棚板の材木発注ミスにより、必要な資材が納入されずに作業が1日ストップし、結果として追加で20万円の費用負担が生じた失敗事例がありました。

A社は、自社のシステム構築ノウハウを持たず、開発会社選びから始める必要がありました。プロジェクトを立ち上げるにあたって、最初に明確化した課題は以下の3点です。

1. 進捗報告の遅延と工数増加：現場監督が紙の報告書を毎週本社に持参するため、情報反映が最大で1週間程度遅れる。

2. 材料発注ミスのリスク：現場での在庫把握が十分でないため、発注量の過不足が頻発し、結果として予算超過が起こりやすい。

3. 新規顧客への提案力強化：今後の入札案件でIT化をアピールするため、システム導入による工期短縮や品質向上を数値で示せる必要があった。

これらの課題を整理し、A社では「システム化による情報共有のリアルタイム化」「発注誤りを防止する材料管理機能」「スマホアプリで現場データを即時入力可能にする」といった要件を抽出しました。予算感を把握するため、A社の経営層はまず相場を調査。中小企業向けの現場管理アプリ開発の費用は、一般的に300万～800万円程度といわれており、要件の複雑さや連携先APIの有無によって変動します。A社では初期予算として500万円を確保し、発注先となる開発会社への相見積を開始しました。要件をまとめた資料には「現場管理システム」「開発会社選び」「予算500万円」「費用相場」「発注条件」を明記し、後から開発会社が提示する追加工数や条件も見える化できるよう配慮しました。

A社の代表であるB氏はITには詳しくなかったため、開発会社選びの際には「類似システムの開発実績があるか」「予算内で要件が実現可能か」「アフターサポート体制はどうか」という観点を重視しました。最初に10社程度に問い合わせを行い、そのうち3社から詳細見積を取得。見積内訳には「要件定義」「画面設計」「開発」「テスト」「インフラ構築」「運用保守」の項目ごとに工数と費用が明示されており、A社の社長や経営陣は相場と比較しながら検討しました。

開発会社の比較・選定プロセス

A社が取得した3社の見積結果を比較したところ、次のような違いがありました。

• 開発会社X社：過去に建設業向けシステムを複数手がけており、建築工程管理や原価管理のモジュールまでワンストップで提供可能。見積額は約650万円（要件定義～運用保守1年分込み）。開発スケジュールは要件確定後4か月。

• 開発会社Y社：フリーランスエンジニアを主体とする小規模チームで、コストパフォーマンスを強みにしている。見積額は約450万円（運用保守は別途見積）。開発スケジュールは要件確定後5か月。

• 開発会社Z社：都心のITベンダーで、大企業向けERP連携経験が豊富。見積額は約800万円（ERP連携やカスタムAPI開発込み）。開発スケジュールは3か月と最短だが、費用が予算を大きく超過。

A社では、予算500万円を超えるZ社は選択肢から外れました。X社とY社の違いは「経験とサポートの手厚さ」にあります。X社は建設業特化のノウハウを持ち、API連携や運用保守のサポート実績があるため、予算650万円と相場よりやや高いものの、障害時の対応コストや追加開発の費用を抑えやすいと判断。一方、Y社は予算範囲内であるものの、要件定義の曖昧さから追加費用が生じるリスクや運用保守体制の不透明さが懸念されました。たとえば、Y社は要件定義後に「ERP連携APIが別途必要」と追加提示し、新規で50万円の開発費用が発生するケースがあり、予算内に収まるとは限らない状況に。

最終的にA社は、**「初期費用はやや高いが、要件変更や保守対応を見越したランニングコストの低さ」を評価し、X社に発注を決定しました。X社との契約条件には、「要件定義フェーズで合意した項目以外は別途見積もり」「テスト環境の提供や仕様変更時の見積提示は契約内で対応」**という条項を加え、発注後に思わぬ追加費用が発生しないようリスクヘッジをしました。

要件定義と予算交渉の実際

X社に発注を決定したものの、要件定義フェーズでさらに詳細を詰める過程で、A社の予算と実際に必要な機能のバランスを取る難しさが浮き彫りになりました。ここでは、要件定義の深堀りと予算交渉の具体例を紹介します。

まず、A社から提示された「現場作業員がスマホで写真を撮ってもらい、クラウド上に画像を保存したい」という要件に対し、X社は「AWS S3連携およびサムネイル生成の仕組みが必要」と回答。これにより、バックエンド開発工数とAWS利用料が増加し、見積額に約100万円の追加が発生しました。A社の経営陣は当初、写真保存機能にはそれほどコストをかけたくない意向でしたが、X社のエンジニアが**「画像保存を別途オンプレミスで構築すると運用コストが高く、将来的にサーバ容量増加時の帯域課金リスクが大きい」と説明。結果として、「AWS利用料：月額約1.5万円」**を含めた上で、一時的に予算を50万円増額し、要件を確定しました。

また、要件定義の段階で発覚したのが、「現場の通信環境は必ずしも安定しない」という現状です。A社では地方の山間部にも施工拠点を持っており、LTE回線では通信が途切れがちであることから、オフライン対応が必要との指摘がありました。X社は、オフライン時にもアプリがデータをローカルにキャッシュし、通信回復時に自動同期する方式を提案。これにより、モバイル側の開発工数が約30工数（90万円相当）増加しましたが、A社は「追加費用を負担することで現場運用がスムーズになり、結果的にコスト削減につながる」と判断。要件に盛り込まれたことで、発注前に明確な**「オフライン同期機能」**が合意され、契約書で「同期失敗時の再試行ポリシー」を仕様として規定することで、後の費用増加を防止しました。

次に、予算交渉のポイントとして、A社は当初「500万円以内で全機能を実装したい」という説明でしたが、要件の複雑さが増すたびに工数が膨らんでいきます。そこでX社は、機能をコア機能と拡張機能に分け、フェーズ1（基本機能実装）とフェーズ2（拡張機能実装）に分割する方式を提案しました。具体的には、フェーズ1では「現場の作業記録」「材料在庫管理」「写真保存」「簡易レポート生成」の基本機能を実装し、開発費用を約550万円に抑制。フェーズ2では「分析ダッシュボード」「ERPへの月次連携」「AI画像自動タグ付け」などの拡張機能を別途検討する形にしました。この提案により、A社は**「フェーズ1内で現場運用を立ち上げ、効果を確認してから追加予算を検討する」**という戦略を取ることで、追加費用リスクを低減しつつプロジェクトを開始しました。

さらに、要件定義フェーズの最後には、**「見積時の費用相場との乖離がないか」「要件変更による追加費用はどう算定するか」を契約書に明記。A社はX社から「工数単価：30,000円/工数」「オフライン同期機能：30工数」「AWS構築費用：50万円」などの内訳を提示され、経営陣は相場と照らし合わせながら納得したうえで発注しました。その結果、「発注金額：フェーズ1合計550万円」「運用保守費用（月額）：5万円」**が決定し、A社は正式にX社へ発注しています。

設計・開発フェーズの詳細と工夫

フェーズ1が正式にスタートしてから、要件定義で固めた「現場作業記録」「材料在庫管理」「写真保存」「簡易レポート生成」を実装するにあたり、A社とX社は以下のような進め方・工夫を行いました。まず画面設計フェーズでは、業務担当者である現場監督が毎日使いやすいように、1画面に表示する情報は絞り込み、入力操作は3タップ以内を目標にワイヤーフレームを作成。現場に行った作業員へのヒアリングを実施し、「入力項目が多すぎると記録に手間がかかり、かえって運用が定着しない」という課題を明確化しました。その結果、本当に必要な項目を「作業日時」「担当者ID」「作業内容テキスト」「写真添付ボタン」の4つに絞り、スムーズに入力できるUIを目指しました。

バックエンドでは、X社が選定した技術スタックはNode.js + Express。開発会社X社によると、このスタックは開発スピードが早く、かつAWS LambdaやAWS Fargateとも相性がよいため、初期開発費用を抑えつつ将来的なマイクロサービス化へも対応しやすいというメリットがあるとのことでした。また、データベースはAmazon RDS for PostgreSQLを採用し、在庫管理テーブルや作業記録テーブルを設計。作業記録テーブルは作業ID（UUID）を主キーとし、作業日時（TIMESTAMP）、担当者ID（VARCHAR）、作業内容（TEXT）、**写真URL（VARCHAR）**といった項目を持たせました。材料在庫テーブルは、材料ID（UUID）、現場ID（VARCHAR）、在庫数量（INTEGER）、**最終更新日時（TIMESTAMP）**というシンプルな構成です。これらのテーブル構造は、要件定義時にA社から提示された「将来的に他システム（基幹ERP）と在庫情報を連携する」という要求に対応できるよう、余裕をもった拡張性を考慮した設計となっています。

API設計では、RESTfulなエンドポイントを基本とし、具体的には以下のように定義しました。

• POST /api/works：現場作業記録登録（要求ボディ：担当者ID、作業内容、写真ファイルBase64）

• GET /api/works?siteId={現場ID}&date={日付}：現場ごとの作業記録取得

• GET /api/inventory?siteId={現場ID}：現場ごとの在庫情報取得

• PUT /api/inventory/{materialsId}：在庫数量更新

• POST /api/photos：写真アップロード（S3に保存し、返却されたURLをDBに登録）
  設計段階で重要視したのは、APIレスポンスに含めるエラーメッセージをわかりやすくすることでした。たとえば、在庫更新時に在庫不足で更新できなかった場合は、単にHTTP 400を返すのではなく、**「在庫数量が足りません。現在の在庫は○○です。」**という具体的なメッセージを含めることで、現場の作業員が混乱せずに即座に対応できるようにしました。

開発期間は要件定義通過から約3.5か月。工数ベースでは約250工数（目安：バックエンド開発100工数、フロントエンド開発100工数、テスト・QA50工数）となり、開発費用は約750万円相当でした。フェーズ1の予算550万円を超過する見込みでしたが、X社からは**「開発中に発生した仕様追加や微調整は無償対応」**という太っ腹な申し出があり、結果としてA社が支払った総額は550万円以内に収まりました。これはX社が「長期的な顧客信頼を優先し、要件定義時に想定されていなかった細かな修正対応を契約内でフォローする」という姿勢を示したためであり、A社のB氏は「発注前に開発会社の選び方やサポート体制をきちんと確認しておいてよかった」と後に振り返っています。

テスト・品質保証フェーズの取組み

開発完了が近づくと、A社とX社はテスト・QAプロセスを同時並行で進めました。X社からは「ユニットテスト70％以上、結合テストカバレッジ50％以上」という具体的な基準が提示され、A社のITリーダーC氏はこれを社内要件として承認。ユニットテストはJestを使ってバックエンドの各ビジネスロジックをテストし、React Nativeで開発したフロントエンド部分はReact Testing Libraryを使ってコンポーネント単位のテストを実装しました。

結合テストでは、Docker Composeを利用してローカル環境にAPIとDB（PostgreSQL）、そしてS3互換のMinIOサーバーを立ち上げ、E2EテストツールとしてCypressを導入しました。Cypressのテスト項目は以下のように整理しました。

1. 作業記録登録フロー：スマホアプリから作業内容を入力し、写真を添付して送信 → バックエンドで作業レコードがDBに登録されているかの確認

2. 在庫更新フロー：現場管理画面で在庫数量を変更 → APIを叩いて在庫テーブルが更新されるか確認

3. 写真表示フロー：作業登録後、最新作業一覧画面でアップロードした写真が正しく表示されるかの確認

4. レポート生成フロー：月次レポート画面を起動し、該当月の作業データがExcel形式でダウンロードできるかの確認

ここで苦戦したのがスマホアプリのエミュレータ／実機テスト環境です。Cypressは本来Web向けの自動テストツールであり、React Nativeアプリのビルド直後に生成されるWebViewエミュレータを使ってテストを実行しましたが、実機のカメラアクセスやファイルピッカーとの互換性がCypressではカバーできない問題が発生。これに対し、X社はDetoxというReact Native向けのE2Eテストフレームワークを追加導入し、実際のスマホシミュレータ（iOS Simulator / Android Emulator）を使っての自動テストを実施しました。Detoxを採用することで、スマホ固有の動作（カメラプレビュー、ファイル選択画面など）を含めたレイアウト検証やボタンタップ操作まで自動化できるようになり、実機テスト工数を当初見積より約30％削減できました。

テストフェーズ全体で追加発生した工数は約70工数（ユニットテスト30工数、Cypressテスト20工数、Detox導入20工数）でしたが、テスト不具合による手戻りを最小限に抑えられたことで、結局本番リリース後の修正コストが圧倒的に少なく済み、後日発生した運用保守費用（月額5万円）にも反映されました。このように、テスト投資を惜しまないことで、後工程での追加費用を抑制し、最終的にトータルコストを削減できたことが大きな学びです。

本番環境移行と導入効果

2024年6月末に、A社のフェーズ1の機能が全て完成し、ステージング環境での最終総合テストを経て、7月上旬に本番環境へ移行しました。本番環境の構成は以下のとおりです。

• AWS EC2（t3.medium）×2台：バックエンドAPIサーバー（Express＋Node.js）およびReact Native WebViewアプリ用静的ファイルをホスト

• Amazon RDS for PostgreSQL（db.t3.medium）：在庫・作業記録データベース

• Amazon S3：写真ファイルの保管および署名付きURLでのアクセス管理

• Elastic Load Balancer（ALB）：HTTPS終端とサーバー負荷分散

• Amazon CloudFront：静的ファイルのCDN配信

• Form API Gateway + Lambda：レポート生成時のバッチジョブ実行およびメール配信

• Amazon Route 53：ドメイン管理

本番リリース当日、A社の現場監督は全員スマホアプリをインストールし、過去1か月分の作業記録をCSVインポートで一括登録する機能が用意されていたため、スムーズに初期データを投入できました。リリース後1週間の利用状況を集計したところ、現場監督は日々の作業記録をスマホ操作で約5分以内に完了できるようになり、紙やエクセルでの手入力に要していた平均15分から約66％の時間短縮となりました。また、材料発注ミスはリリース前の月間平均2件からリリース後の初月は0件となり、ミスによる追加費用が概算30万円→0円に改善されました。これらの導入効果は、A社の経営陣にとって数値で示せる定量成果として評価され、その後に続くフェーズ2・フェーズ3においてもシステム拡張への投資判断を後押ししました。

本番稼働と並行して、A社は現場社員向けの操作マニュアル作成とオンサイト研修を実施。要員コストとして研修講師1名×3日間（約15万円相当）やマニュアル制作費用（5万円相当）が発生しましたが、現場定着率は95％を超え、運用開始1か月後には全現場でスマホアプリによる記録が定着しました。これにより、情報の「属人化リスク」が大幅に低減し、将来的に人手が変わってもノウハウの継承が容易になるという副次的なメリットも得られました。

運用保守フェーズの取り組みと定着化

システム導入後、A社では開発会社X社と**運用保守契約（月額5万円）**を結びました。契約内容には「システム障害対応」「簡易機能追加」「サーバー運用監視」「定期バックアップ設定」が含まれており、以下の取り組みで安定運用を実現しました。

1. 定期バックアップとDR（Disaster Recovery）対策

   • RDSの自動バックアップ機能を有効化し、8日間のバックアップ保持を設定。

   • 写真ファイルはS3のバージョニング機能を有効化し、誤消去や上書き時にも復元できるように設定。

   • さらに、月1回、RDSスナップショットを別リージョンにコピーするDR手順を作成し、災害時でもデータを迅速に復旧できる環境を構築しました。

2. サーバー監視とアラート設計

   • CloudWatchアラームで、CPU使用率＞70% かつメモリ使用率＞80% が30分継続した場合に、Slackへ通知を送信。

   • S3のバケットサイズ監視とオブジェクト数監視を設定し、写真ファイルの急増時にはX社のDevOps担当者がアラートを受け取り、不要ファイル削除の提案やライフサイクルルールの更新を行う仕組みを整えました。

   • また、RDSの接続数監視も設定し、ピーク時の接続数が80%を超えると自動でメール通知が届くようにし、DBパフォーマンス劣化を未然に防止しました。

これらの監視設定は、要件定義フェーズでA社が「運用コストを抑えつつも、現場のトラブルを早期に検知したい」という要望を提示したことがきっかけでした。X社は追加工数（約10工数、30万円相当）で監視ルールを整備し、運用コストを月額5万円の契約内で完結させることに成功しました。

3. ユーザーフィードバックループ
   運用開始から3か月目に、A社社長から「現場報告の使い勝手をもっと向上させたい」という要望が挙がりました。具体的には、「写真をアップロードしたあとに、すぐにプレビューが見られるようにしたい」「作業内容を音声入力で登録できれば便利」といった声が現場監督から上がっていました。X社は運用保守契約内で、ユーザーフィードバックを週次ミーティングで共有し、小規模なUI改善や機能追加を4工数（12万円）以内で対応可能とする仕組みを提案。A社はこれを承認し、結果として、システムリリース後も現場ニーズに合わせた柔軟な改善が継続されました。これにより、システム利用率は導入1か月後の80％から、導入3か月後には95％にまで上昇し、ユーザー満足度の向上につながりました。

さらに、A社内部でのITリテラシー向上施策として、「毎月第1水曜に社内JT（ジョブトレーニング）を開催し、X社のエンジニアが現場向けに操作方法やトラブルシューティングを解説」という取り組みを実施。これにより、現場監督自らがアプリの問い合わせをトラブルシュートできるようになり、X社への問い合わせ件数が50％減少しました。この削減分の運用保守コストは月間約2万円相当となり、実質的な運用コストを3万円/月に抑えることができました。

拡張フェーズ2への移行とROI検証

フェーズ1が安定稼働した段階で、A社では早くもフェーズ2の拡張要件を検討し始めました。フェーズ2の主な要件は以下のとおりです。

1. ERP連携による月次仕訳データ自動化：これまで月次で現場管理アプリからエクセルデータをエクスポートし、手動でERPにインポートしていた作業を自動化する。

2. 予算実績差異分析ダッシュボード：月次の予算（建設工事の設計時に見積もった金額）と実績を比較し、どの工事でどれだけ誤差が発生しているかを可視化する。

3. 現場安全管理モジュール：毎日の安全点検項目をチェックリスト化し、現場監督がスマホで点検結果を入力 → ダッシュボードで安全スコアをリアルタイムで表示する機能を追加。

これらの要件を実現するためには、相応の追加開発工数と予算が必要です。X社からの提案ではフェーズ2開発工数は約200工数（約600万円）、運用保守費用は月額＋3万円と見積もられました。A社としては、**追加で約600万円を投資する価値があるかどうか（ROI：投資対効果）**を事前に検証する必要がありました。

ERP連携によるコスト削減効果

ERP連携を行うことで、従来月次作業に約2人日／月（約2万円相当）かかっていたエクセル運用コストをゼロにすることができます。年間で約24万円のコスト削減が見込まれます。フェーズ2のERP連携部分の開発費用は約300万円と見積もられていたため、ERP連携単独で見ると回収期間は約12年といえます。これだけではROIが低いため、A社では「ERP連携だけでなく、予算実績差異分析や安全管理機能も含めた総合的な投資対効果」を検討しました。

予算実績差異分析のビジネス効果

予算実績差異分析ダッシュボードを導入することで、各現場でのコストオーバーラン要因を早期に発見し、翌月の発注量や作業スケジュールを最適化できるというメリットがあります。実際に業務部長であるD氏は「過去半年の予算実績差異を分析したところ、部材ロスによるコスト超過が年間約200万円発生していることが判明し、その改善策（在庫最適化や購買先見直し）を立案することで、来年度以降は年間150万円以上のコスト削減が見込める」と試算しました。この場合、予算実績差異分析機能の開発費用は約150万円と見積もられたため、その開発投資は1年以内に回収可能という判断になりました。

安全管理モジュールの効果測定

安全管理モジュールの導入により、従来は現場での事故が起きても事後報告が多く、原因究明が進まないケースがありましたが、点検データをリアルタイムで収集してダッシュボード化することで、ヒヤリハット事例を早期に把握できるようになりました。A社ではこれをプロアクティブ安全管理と位置づけ、導入前後で事故発生件数が年間3件から0件に減少し、労災コストが年間約100万円削減できたと報告しています。安全管理機能の開発費用は約150万円だったため、この投資も1年以内に回収可能となりました。

以上を踏まえ、A社経営陣は「ERP連携は単体ではROIが低いが、予算実績差異分析と安全管理機能を含めた統合投資であれば、導入1年目で約450万円の費用削減効果が見込め、残り150万円は将来的な生産性向上や顧客満足度向上に寄与するため、価値がある」と判断。最終的に、合計600万円の追加予算を確保し、X社へフェーズ2の発注を進めることが決定しました。

フェーズ2開発の進行と課題解決

フェーズ2は2024年9月にキックオフし、前述の3つの要件を並行して開発するスケジュールでした。以下に各要件の進行状況と課題解決の具体例を示します。

ERP連携機能の実装と課題

ERP連携機能は、A社がすでに導入していた**クラウドERP「CloudSuite A」とREST APIで連携する方式を採用しました。CloudSuite AのAPI仕様は公開されていたものの、在庫引当ロジックと請求書フォーマットの連携部分に独自仕様があったため、X社はまずPoC（Proof of Concept）**としてテスト環境で小規模にAPI連携を試行。テスト結果から、以下の課題が浮上しました。

1. 在庫引当APIのレスポンスタイムが1回あたり約500msかかり、本番想定以上のトラフィックではタイムアウトのリスクがある

2. 請求書APIには1分間に10リクエストしか許容されないレートリミットがある

改善策として、X社は以下を実施しました。

• バッチ連携とキャッシュ併用：在庫引当APIはバッチ処理で1日1回全在庫を取得し、Redisキャッシュに保存する構成に変更。請求発行時にはキャッシュから在庫情報を参照し、APIコールを極力抑制するアーキテクチャとしました。これにより、**リアルタイム性は若干落ちるものの、実務上影響がない範囲でのSTEP（数分単位の遅延）**にとどめつつ、APIレスポンスタイムやレートリミット問題を回避できました。

• レートリミット緩和対応：CloudSuite A側に連絡し、ERP管理者同士のビジネスコミュニケーションの結果、A社の発行アカウントにのみレートリミット上限を緩和してもらいました。これにより、1分間あたり20リクエストまで処理可能となり、実際の運用でも問題が発生しなくなりました。

このERP連携施策により、**バッチ実行時のAPIコール数は従来の1,440リクエスト/日（1分1リクエスト×24時間×60分）→120リクエスト/日（1日1回のフル在庫取得）**となり、CloudSuite A側への負荷を90％削減できました。この構成変更に伴う追加開発工数は約20工数（60万円）でしたが、ERP連携機能の本番導入は円滑に進み、A社はERP月次作業でかかっていた2人日分の工数を削減し、年間コスト約24万円を確保しました。

予算実績差異分析ダッシュボードの実装と工夫

予算実績差異分析は、各現場の予算データ（見積金額）をCloudSuite Aから取得し、実績データは作業記録DBから集計する必要があります。要件定義時にA社は「BIツールとしてTableauを既に利用しているため、そのまま活用したい」と希望しました。しかし、X社が調査したところ、Tableauライセンスの追加購入コストが年間で約100万円と高額だったため、X社からは**「オープンソースBIツールのMetabaseを検討しませんか？」という提案がありました。A社の経営陣は「ライセンス費用がネックだが、Tableauの操作性に慣れている現場担当者も多い」との判断から、Tableauを継続利用する方針に一度決定。しかし、テスト環境でTableauと自社DBを接続した際にデータパフォーマンスが著しく低下し、数万人分のレコード集計に1分以上かかる**という致命的な問題が発覚しました。

最終的に、以下のような対応でバランスを取りました。

• Tableauはフロントエンド用途に限定し、ダッシュボード上でのフィルタリングやグラフ表示を行えるようにする。

• 集計用ビューをPostgreSQL側で事前定義し、CloudSuite Aの予算データと作業記録データをマテリアライズドビュー（Materialized View）として1日1回更新する仕組みを採用。これにより、Tableauからのクエリはマテリアライズドビューに対して行い、レスポンスタイムを約5秒以内に収めることに成功。

• Tableauライセンスは現場マネージャーなどのキーユーザー向けに最低限の3ライセンスを購入し、ほかの一般社員はMetabaseの無償ライセンスで閲覧／簡易操作ができるようにしました。これにより、ライセンスコストを年間約60万円に抑制しつつ、Tableauの強力な可視化機能も利用可能な環境を実現しました。

この対応にかかる追加工数は、**マテリアライズドビュー作成工数15工数（45万円）＋Metabase導入工数10工数（30万円）**でしたが、Tableauの追加ライセンス費用を回避できたため、結果的に総TCO（Total Cost of Ownership）を期初想定より約30％削減できました。

フェーズ2運用とユーザー定着化の取り組み

フェーズ2の機能が完成し、2025年1月にリリースされて以降、A社では以下の施策で運用定着化を図りました。

1. ERP連携の定期リトライと監視
   ERP連携バッチジョブをAWS Lambdaで実行し、CloudSuite AのAPIと在庫キャッシュを同期。バッチ成功/失敗をCloudWatchで監視し、失敗したジョブは3回リトライしても成功しない場合にのみSlack通知で管理者にアラートを飛ばす仕組みを導入。これにより、バッチ処理失敗による手動介入は月1～2件程度に抑制され、A社側の運用担当者は大幅に工数を削減できました。

2. ダッシュボード利用促進キャンペーン
   予算実績差異分析ダッシュボードを事業部長や工務チームに周知するため、**「今月の最優秀現場コスト管理賞」**というインセンティブ制度を導入。月次でダッシュボードからコスト削減率が高い現場を表彰し、ポイント制度で報奨金を付与する取り組みを行った結果、現場スタッフのダッシュボードログイン率が導入前の20％→80％に跳ね上がり、本格的に運用が定着しました。

3. 安全点検モジュールの活用と効果
   安全管理モジュールの導入後、A社では毎日の点検結果をモバイルアプリで記録し、そのデータをSlackやTeamsで週次レポートとしてまとめ、全社員に共有しました。これにより、「社員が自発的に安全点検を実施する文化」が醸成され、点検異常件数の報告率が従来の30％→95％に向上。また、点検結果をもとに改善策を講じた現場では、事故件数がさらに0件から年間0件を維持できるようになりました。これらの成果を受け、A社は「安全管理モジュールを地域の同業者向けにライセンス販売したい」と話が出るほどの導入効果を得ています。

A社のB氏は「開発会社選びで『アフターサポート』や『追加要件への柔軟性』を重視しておいて本当によかった」と語ります。X社が作業ログのリトライやダッシュボードの運用サポート、ユーザー問い合わせ対応を迅速に行ったことで、A社の社内IT担当者は日々のトラブル対応に要する時間を従来の1日4時間→1日1時間に削減でき、その浮いた時間を次期フェーズの業務改善策検討に充てることができました。

プロジェクト総括と学び

A社の開発ユースケースを通じて得られた主な学びと教訓を以下にまとめます。

1. 開発会社選びの重要性

   • 「同業他社への導入実績」「要件定義精度」「運用保守サポート体制」を重視し、相見積もりにより費用相場を把握したうえで発注した結果、トラブル時の追加費用が削減できた。

   • 予算内にこだわりすぎず、長期的にかかる運用コストも見据えた発注判断が必要。X社は初期予算を若干超過したものの、将来的なコストを抑える設計・提案を行い、トータルではA社のコスト負担を軽減できるアプローチを採用した。

2. 要件定義段階でのリスク洗い出し

   • 通信環境が不安定な現場を想定し、オフライン同期機能を要件に盛り込むことで、リリース後のトラブルを未然に防止できた。

   • ERP連携やBIツールの選定においても、費用対効果を事前に検証し、小規模PoCでパフォーマンスリスクを解消したことで、追加費用の見積外コストを回避できた。

3. テスト自動化への投資

   • ユニットテスト、結合テスト、E2Eテストを適切に組み合わせることで、本番リリース後の障害を激減。

   • 特にReact NativeアプリのE2EテストでDetoxを活用し、スマホ固有のUI問題を早期に検知できたことが大きかった。テスト投資は工数増となったが、トラブル対応コストを大幅に削減できた。

4. 運用定着化の取り組み

   • ダッシュボード利用促進キャンペーンや社内勉強会の実施により、業務担当者のITリテラシー向上を図り、システム活用率を高めた。

   • 運用保守契約内での監視・バックアップ・ユーザサポートを明確に定義し、月額5万円の契約内で安定運用を実現できたことは、中小企業にとって大きな成功ポイントとなった。

5. 拡張フェーズへの投資判断

   • フェーズ2のERP連携機能、予算実績差異分析、安全管理モジュールのうち、ERP連携単体ではROIが低いことを認識し、統合的な投資効果を試算したことで、追加予算600万円を正当化できた。

   • このように、投資対効果を可視化し、見積もり時にコスト構造を明確にすることで、経営層への説得力を強化し、スムーズに予算承認を得られた。

A社のB氏は「今回のプロジェクトを通じて、システム導入はゴールではなく、継続的改善のスタート地点だと実感した」と語ります。現場運用を維持しながら、次期フェーズでのさらなる機能追加や、今後のコスト最適化に取り組むことで、中小企業でもDX推進とコスト削減を両立できるというモデルケースを社内外へ発信できるようになりました。