ユースケース紹介：建設現場向け資材管理モバイルアプリで工期短縮とコスト削減を実現

プロジェクト発端と課題感

地方の中堅建設会社「山田建設」は、複数の施工現場で資材管理に多大な手間をかけていました。これまでは現場の担当者が手書きの資材発注リストを基に事務所へFAXで発注し、事務所担当が一覧表をExcelで集計してから開発会社へERPシステム経由で発注していました。その結果、発注ミスが多発し、過剰在庫や不足が頻発。工期の遅れや人件費増加によるコストアップが深刻化していたのです。
現場にはWi-Fi環境が整っておらず、スマートフォンをほとんど活用していなかったため、経営層も「モバイルアプリで何とかなるはずがない」と半信半疑でした。しかしある日、新規特命プロジェクト責任者となったCさん（36歳、元建築技術者）は、IoTカメラやモバイルアプリで在庫の写真を撮り、リアルタイム在庫連携を行えるシステムを提案。社内SEの協力を得つつ、Cさんは開発会社への発注検討を始めました。
Cさんはまず、自社の現場課題を整理するワークショップを開催し、次の要件をまとめました。

• 手書き・FAX発注を廃止し、現場でスマホから資材発注できるモバイルUI

• 発注と同時に倉庫在庫を自動更新し、二重発注や不足を防止

• 同一資材を複数現場で発注した場合、リアルタイムで優先順位を自動調整

• 資材費用や運搬費を含めた見積もり機能をアプリ内に実装し、現場で概算予算を即座に把握

• 導入予算は250万円以下、月額ランニングコストは5万円前後に抑える

これらの課題を踏まえ、Cさんは開発会社の選定に着手しました。

開発会社選びと見積もり比較のポイント

Cさんはまず、3社の開発会社にRFPを送付しました。RFPには上記要件に加え、「システムはスマホとERP連携を前提に構築」「予算・費用感を明示的に提示」「保守運用サポートを含めた相場を提示」と記載。A社・B社・C社（以下便宜上C社と呼ぶ）から返却された見積もりを比較するポイントは次の通りです。

• スマホUI開発工数：ネイティブ（iOS/Android）か、ハイブリッド（React Native, Flutter）かによって費用相場が変動（Flutter採用で約120工数＝240万円，React Nativeで約130工数＝260万円）

• バックエンドインフラ構築費用：Azure App ServiceかAWS　Lambda＋DynamoDBか、予算感を確認（Azureで初期50万～80万円，AWSで初期60万～90万円）

• ERPシステム連携方式：既存のオンプレミスERPがSkype for Businessとしか連携できないため、どのミドルウェアを使うかが開発会社によって提案が異なる（EDIミドルウェア利用で追加50万円，APIゲートウェイ経由30万円など）

• 運用保守費用相場：月額5万円前後を目標に、A社は8万円、B社は6万円、C社は5万円のプランを提示

最終的に、Cさんは「モバイルUI設計力」「ERP連携実績」「コスト感」のバランスを考慮し、C社をパートナーに選定。Flutter＋Azure構成で初期開発費用250万円、月額保守運用費5万円以内という条件で合意し、PoCフェーズとして小規模機能を約50工数（100万円）で発注して検証を開始しました。

PoCフェーズ：現場UX検証と初期導入結果

PoCでは、まず「現場でスマホから資材のバーコードを読み取り、即座に在庫状況を確認して発注できる簡易画面」を構築。倉庫側にはIoTバーコードスキャナーを導入し、Azure Functionsで在庫更新APIを実装。これにより、リアルタイム在庫管理が可能になりました。
作成したPoCアプリを3か所の現場で試験的に導入すると、以下の成果が得られました。

• 在庫照会時間の短縮：従来は倉庫担当者への電話連絡とExcel検索で平均5分かかっていたところ、PoCではバーコードスキャン＋即時表示で30秒以内に完了

• 発注ミス率の低減：手書き・FAX発注時の誤発注が月10件発生していたが、PoCでのQRコード照合で月1～2件に

• 現場満足度の向上：現場担当者から「スマホで簡単に在庫確認と発注できるため作業効率が飛躍的に上がった」との声

• コストシミュレーション：PoCで発注データを3現場分収集し、発注単価や運搬費を算出。PoC期間中の総試算金額を計測し、本番予算（240万円＋保守5万円/月）が適切と判断

この結果を踏まえ、ステークホルダーの承認を得て本格開発に移行しました。PoCフェーズの費用は100万円（50工数）でしたが、開発会社C社を選んだことで追加で要件が出ても「工数×単価」で柔軟に対応でき、予算オーバーを防ぐことができました。

本開発フェーズ：要件拡張と調整

PoCで得た知見を基に、本番機能では以下の要素を追加・拡張することにしました。

1. 複数現場横断発注の最適化ロジック

   • 工事現場AとBが同一資材を同時に発注した場合、在庫量に応じてどちらを優先するか自動判定

   • 簡易AI予測モデルを導入し、過去3か月分の発注履歴と在庫推移を学習して予測在庫を算出

   • Azure Machine Learningを使って学習済みモデルを提供、API連携で予測値を返却する設計

2. 予算・費用見積もり機能

   • 資材単価と運搬費、現場までの距離をAPIで呼び出し自動計算

   • 予算上限を設定し、予算超過時は警告をアプリ内で表示。現場主任に承認を依頼するワークフローを実装

3. オフライン対応と同期機能

   • 現場で通信断が発生しても在庫閲覧と発注リクエストをローカルデータベース（SQLite via sqflite）に保存し、オンライン復帰時にAzure Functionsへ同期

   • 同期エラー発生時のリトライロジックと、競合解消ルール（先着順 vs. 優先現場）を設計

4. カスタマイズ可能なレポート出力

   • 月次レポートとして、発注履歴、在庫推移、未消化在庫をPDFでエクスポートし、メール配信

   • レポートテンプレートはPower BI Embeddedで作成し、アプリ内に埋め込むことでダッシュボードを提供

C社は上記要件をもとに、追加で約100工数（200万円）の見積もりを提出しました。合計で本開発は150工数（300万円）となりましたが、PoC段階での予算調整や要件固めが功を奏し、経営層から追加予算承認をスムーズに取得できました。

開発中の苦労と工夫

本番開発フェーズでは、以下の課題に直面しました。

競合データ同期時の競合解決

複数現場が同じ資材をほぼ同時に発注すると、オフライン保存後に復帰した際の同期タイミングで発注データが競合。最初は「先に同期したものを優先」ルールを適用していましたが、現場ごとの優先度を考慮せずトラブルが発生。そこで開発会社C社と協議し、

• 現場ごとの優先ランク（工事進行度や納期迫り度）を見積もりAPIで返却し、発注優先度を動的に決定

• 同期前にユーザーへ「優先権が低いため一部資材がキャンセルになる可能性があります」というポップアップを表示

といったUX改善を実施し、発注トラブルを40％削減しました。競合ロジックの実装工数は20工数（約40万円）でしたが、結果として現場稼働率向上に貢献しました。

AI予測モデルの精度調整

予測在庫を算出するAIモデルは、初期データでの精度が約70％だったため、「現場担当者が予測に不安を抱き、モデルを信用しない」といった課題が発生。そこで、

• 「AI予測値＋過去履歴グラフ」をモバイルUIに表示し、予測結果の根拠を可視化

• フィードバック機能を追加し、現場担当が実在庫との差分を入力することでモデル精度を継続改善

といった施策を取り入れ、精度を約85％まで高めることができました。AI関連の改修工数は15工数（約30万円）でしたが、現場の納得感を高めることでAI活用率を60％→90％に向上させました。

納品後の効果とROI評価

リリースから3か月後、山田建設が得た成果は次の通りです。

• 発注ミス件数の大幅削減：月平均10件以上あった誤発注が、1件程度に激減。これにより無駄な資材コストを月間30万円相当削減。

• 在庫保有コスト低減：過剰在庫が減少し、倉庫スペースを1/3に削減。年間の在庫保管費用を約240万円節約。

• 工期短縮と稼働率向上：資材不足による工期遅延が激減し、現場平均工期を10％短縮。追加で3件のプロジェクト受注が可能になり、年間売上が500万円増加。

• IT化による人件費圧縮：従来Excel集計やFAX対応にかかっていた事務工数を削減し、月間工数換算で約100時間、年間約120万円分の人件費を節約。

これらを合計すると、初年度に創出された付加価値は合計約890万円。開発・導入にかかった費用（PoC100万＋本番300万＋保守15万×12）が約700万円だったため、ROIは約1.3倍となり、投資回収期間は約9か月という結果になりました。
山田建設のCさんは「開発会社の選び方と予算・費用管理を徹底したおかげで、相場感と実際費用のギャップを最小限に抑えられた」「発注時に追加要件を想定し、工数×単価ルールで契約したためトラブル対応もスムーズだった」と振り返っています。

学びと成功のポイント

本ユースケースから得られる主な学びは以下の通りです。

1. 要件定義とPoCでの仮説検証

   • 発注前にPoCを行い、実際の現場UXやコスト感を把握できたことで、本開発での大きな手戻りを防止。

2. 開発会社選びの工数×単価ルール

   • 見積もり内訳を明確化し、追加要件は「工数×単価」で対応という契約にしたことで、予算超過リスクをコントロール。

3. リアルタイム同期とオフライン対応の両立

   • オンライン・オフラインどちらでも使える設計により、通信が不安定な現場環境でも安心して利用できるアプリを実現。

4. AI予測モデルの利活用

   • AI予測値に信頼性を持たせるため、可視化とフィードバック機能を組み合わせた設計により、現場スタッフの承認率を90％まで向上。

5. 継続的なコストレビューと運用保守体制

   • Azureコストやモバイル通信費を含めた予実管理を徹底し、保守中に発生したコスト増を即座に検知・対策する体制を整備。

これから同様の業務を抱える事業責任者やマネージャーの方には、まずPoCで現場検証し、開発会社選びの際にコストリスクを最小限に留める契約ルールを徹底することを強くおすすめします。

スケーラビリティと将来展望

山田建設では、資材管理アプリの初期導入後、利用現場が3拠点から10拠点へ拡大しました。その過程で発覚したのが、Azure Cosmos DBのスループット設定不足によるレイテンシ問題です。PoCおよび本番初期では「月間10万ドキュメント書き込み」で想定していましたが、拠点増加に伴い「月間30万書き込み」を超え、予算（費用）が割り当てたRU（Request Units）が枯渇し、APIレスポンスが遅延しました。これを解消するために、次の対応を行いました。

• Cosmos DBのスループット調整：手動スループットから「自動スケーリング」へ変更し、ピーク時に自動でリソースを増減できるようにし、運用コストを最適化。これにより、従来の固定設定（月額約5万円）から自動スケールで平均3万RUを維持した場合の相場（月額約4万円）に引き下げつつ、スケール不足によるエラーを回避できました。

• APIキャッシュの強化：Azure Cache for Redisを導入し、在庫照会のキャッシュヒット率を95%以上に向上。これにより、バックエンドへのクエリを大幅に削減し、Cosmos DBの負荷を安定化させることに成功しました。キャッシュ導入費用（インスタンス利用料）は月額約2万円で、システム全体の予算感を踏まえて発注しました。

• バックエンドAzure Functionsのスロット分割：従来は「消費プラン」を利用していましたが、トラフィック急増時にCold Start問題が発生したため、プロビジョンドコンカレンシー付きの「専用プラン」に変更。これに伴い費用相場が上がったものの（月額約6万円→約9万円）、起動レイテンシを改善し、ユーザビリティを維持しました。

これらのスケーラビリティ対策を実施した結果、拠点追加後もレスポンスタイムは100ms以下を維持しつつ、月間運用コストは当初想定よりも15％抑えられました。プロジェクト進行中に発生した課題に対して、開発会社との継続的なコミュニケーションで要件変更と予算管理を行い、結果として発注から運用フェーズまで予算超過を防げたことが大きな学びとなりました。

ERP連携機能のさらなる拡張

導入から半年後、山田建設の経営層は「資材管理アプリのデータを基幹ERPへリアルタイムに反映し、会計業務の自動化を図りたい」という要望を出しました。これに対応するため、次の作業を行いました。

• ERPシステムのAPI化要件定義：既存のオンプレミスERPはAPI連携機能が限定的だったため、I/F仕様を確認し、「帳票出力CSV→バッチアップロード」から「REST API経由で直接データ入力」に移行する計画を立案。これにより、ERP側の開発規模を縮小し、開発会社B社へ相見積もりを依頼した結果、約40工数（80万円）で連携ミドルウェアを提供可能という回答を得ました。

• ミドルウェア選定と実装：C社の提案により、Azure Logic Appsを活用して「資材発注データをJSON形式へマッピング→ERP向けSOAP APIへ変換」するフローを構築。Logic Appsのコネクタ利用により、開発工数を25工数（約50万円）に削減しつつ、運用負担を軽減しました。

• データ整合性バッチの追加：リアルタイム同期後もERPと資材アプリのデータに差異が生じた場合に備え、夜間バッチで全データ照合を行う仕組みを追加。Azure Functionsでバッチ処理を実行し、誤差が発生したレコードを自動でログ記録し、翌朝に担当者へアラートメールを送信する設計です。バッチ処理の工数は15工数（約30万円）でした。

これにより、資材アプリとERP間で手動のデータ移行が不要となり、経理担当者の作業工数を月間50時間削減。会計伝票作成のミスも激減し、ERP側での金額誤入力が0件となりました。経営層からは「開発会社の選び方と予算交渉を適切に行ったことで、ERP連携まで含めた費用を抑制し、投資対効果を最大化できた」と高評価を得ました。

現場トレーニングとユーザーサポート

システム導入後、現場の操作方法や運用ルールに関する不安から現場担当者からの問い合わせが増加しました。そこで、Cさんは次の施策を実施しました。

• 導入時ハンズオントレーニング：各現場に導入する際、開発会社C社のエンジニアとともに2日間のオンサイト研修を実施。スマホでの発注フローやオフライン時の対応手順をハンズオン形式で教育し、現場担当者が自信を持って利用開始できるようにしました。

• オンラインマニュアルの整備：Confluenceで「資材発注手順」「トラブル時の問い合わせ先」「帳票ダウンロード方法」などをまとめたオンラインマニュアルを作成。よくある質問（FAQ）も掲載し、日々の運用保守時に参照できるようにしました。

• サポート体制の構築：C社と保守契約を締結し、サブスクリプション型で月間5万円のサポートプランを導入。サポートチケット制で「翌営業日対応」「緊急時は4時間以内に初動」などのSLAを設定し、開発会社の監視ツールで障害やエラーを検知次第チケットが自動発行されるフローを構築。

• ユーザーフィードバック会議の定例化：月1回、現場リーダーを招集し、現場で発生した改善要望やバグ報告をヒアリング。C社とともに優先度を付けて改善リストを作成し、次月リリース分のスプリント計画に反映しました。

これらの取り組みにより、現場からの一次サポート問い合わせは導入初月の50件から導入後3カ月目には10件まで減少。ユーザー満足度調査では「使い方がわかりやすい」「サポート対応が迅速」と評価され、現場への浸透度が飛躍的に向上しました。

リスク管理と継続的改善

プロジェクト開始時には、資材アプリに関するリスクを以下のように整理し、対策を講じました。

1. スマホ紛失時の情報漏洩リスク

   • アプリ起動時にAzure AD B2C認証を必須化し、端末紛失時でもID停止すればアクセス不能に。さらに、アプリ内のデータはすべて暗号化し、IndexedDBの暗号化モジュールを導入。

2. システム障害時の業務停止リスク

   • Azure FunctionsとCosmos DBをリージョン冗長構成（GEORestore）で構築し、プライマリリージョン障害時にバックアップリージョンで自動フェイルオーバー。また、障害時は自動で24時間以内にAzure Routerがリダイレクトを実施する仕組みを採用。

3. 予算超過リスク

   • 開発会社C社との契約に、「要件追加は見積もり提出後に工数×単価で対応」「月次予算レビューを必須」と明示し、予算管理を厳格化。実際に、フェーズ2のAIモデル拡張で追加20工数の見積もりを提示された際も、すぐに優先度を調整して不要機能をスコープオフし、予算枠を維持できた。

4. 現場定着化の遅れリスク

   • 導入前の現場ヒアリングで、操作マニュアルやオンサイト研修が不足すると定着しづらいと判明。先述のトレーニングやFAQ整備を行い、定着に要する工数を減らした結果、現場からの抵抗感を解消できた。

また、継続的改善のために、以下の仕組みを導入しました。

• データドリブンな改善サイクル：Power BI Embeddedを利用し、発注リードタイムや在庫変動、各種KPIを可視化。月次レポートでCレベルや現場リーダーに報告し、次の改善策を検討。

• バージョン管理とリリースノート：アプリとAPIのバージョンをSemantic Versioningで管理し、機能追加や不具合修正をリリースノートに記載。ユーザー側で新機能を把握しやすくし、アップデート率を90％以上に維持。

• リファクタリングと技術債管理：バックエンドのスクリプトやフロントエンドのコンポーネントが肥大化しつつあったため、四半期ごとにC社とリファクタリングスプリントを実施し、技術的負債を解消。結果として、開発スピードを維持しながら品質を担保できた。