現場責任者が地下2階の機械室で点検作業を終え、タブレットに記録した点検データを保存しようとした瞬間、画面が固まった。地下は電波が入らない。「通信エラー」の表示が出た後、アプリを閉じて再度開くと、入力したはずの項目がすべて消えていた。仕方なく地上に戻り、記憶を頼りにもう一度同じ項目を入力し直す。これだけで往復20分、点検自体より移動時間の方が長くなってしまった。
同じような話は配送の現場にもある。山間部の配送先に向かうドライバーが、受け取りサインをタブレットで記録しようとしたところ圏外表示。何度試しても送信できず、結局その場では紙の伝票にサインをもらい、事務所に戻ってから手入力でシステムに転記する二度手間が発生した。せっかく紙をなくすために導入したシステムが、圏外の一瞬のせいで紙に逆戻りしてしまう。こうした場面は建設、倉庫、製造、物流など、電波が不安定な現場を抱える会社であれば一度は経験しているのではないだろうか。
クラウド前提のシステムが現場の圏外で動かなくなる理由
多くの業務システムは、サーバーと常時通信できることを前提に設計されている。入力した内容をその場でサーバーに送信し、サーバー側の処理が終わった応答を受け取って初めて「保存完了」となる仕組みだ。オフィスや店舗のように安定した通信環境であれば何の問題もないが、地下や山間部、鉄筋コンクリートに囲まれた建物内、郊外の配送ルートなどでは通信が途切れることが日常的に起こる。
この設計のままだと、通信が切れた瞬間に何が起きるかが深刻な問題になる。送信中のデータが宙に浮いた状態になり、アプリ側でエラーハンドリングが甘いと入力内容がそのまま消失する。ユーザーからすると「保存したはずのデータが消えた」という体験になり、一度これを経験すると現場の人間はそのシステムを信用しなくなる。信用を失ったシステムがたどる道は決まっていて、現場は「念のため紙にも書いておこう」という二重運用に戻り、やがて紙だけで済ませるようになる。せっかくデジタル化に投資しても、現場の圏外対応を考えていなければ効果は長続きしない。
オフライン対応の設計で現場の入力データを守る仕組み
この問題を解決するのが、オフライン対応(オフラインファースト)という設計思想だ。考え方はシンプルで、サーバーとの通信が前提ではなく、端末側での動作を前提に据える。入力したデータはまず端末内のローカルストレージに保存され、その時点で「保存完了」として扱われる。通信が回復したタイミングでバックグラウンドが自動的にサーバーへ同期を行うため、現場の担当者は通信状況を気にせず入力作業を続けられる。
この設計であれば、地下の点検作業も圏外の配送先での署名も、入力した瞬間に端末内へ確実に記録される。あとはトンネルを抜けた瞬間、事務所に戻った瞬間に自動で同期されるので、担当者が「送信できているか」を確認する手間もない。基本的な入力・閲覧・検索といった機能が圏外でも動き続けることで、現場の作業フローを止めずに済む。
ただし、オフライン対応には避けて通れない技術的な課題がある。それが複数拠点での同時編集によるデータ競合だ。たとえば同じ案件について、現場Aの担当者と現場Bの担当者がそれぞれオフライン状態で同じデータを編集し、両方が同期されるタイミングが重なった場合、どちらの変更を正とするかを決めなければならない。単純に「後から同期した方を優先する」ルールにすると、先に入力した担当者の作業が知らないうちに上書きされてしまう危険がある。実務では、更新日時をもとにした自動マージ、競合が発生した場合に両方の変更内容を残して人間が確認する仕組み、項目単位で編集者を分けて競合自体を起こりにくくする設計など、業務の性質に応じた対策を組み合わせる必要がある。
オフライン対応を導入する際に注意すべきポイント
オフライン対応は魅力的な仕組みだが、システムのすべての機能をオフライン対応させようとすると、開発コストが跳ね上がり現実的ではなくなる。ローカル保存の仕組み、同期処理、競合解決のロジックはそれぞれ独立した開発負荷を伴うため、機能を絞らずに全方位で対応しようとすると、開発期間もコストも当初の想定を大きく超えてしまう。だからこそ、どの機能をオフライン対応させるかという優先順位づけが欠かせない。
あわせて注意したいのが、同期時のデータ競合や重複登録のテストだ。オフライン対応の不具合は、通信が安定した開発環境でのテストだけでは発見しづらい。わざと通信を切断した状態で操作し、複数端末で同時にオフライン編集を行い、同期タイミングを意図的にずらすといった、実際の現場に近い条件でのテストを設計段階から組み込む必要がある。
もう一つ見落とされがちなのが、オフライン中の操作性の見え方だ。今入力しているデータが端末内にとどまっているのか、すでにサーバーに同期済みなのかが画面上で分からないと、現場の担当者は不安を感じたまま作業を続けることになる。同期待ちの件数を表示する、未同期のデータにアイコンを付ける、通信が回復した瞬間に同期完了の通知を出すなど、状態を可視化するUIの設計もオフライン対応の一部として考えておきたい。
現実的な進め方は使用頻度の高い機能からのオフライン対応
限られた予算と期間の中でオフライン対応を実現するには、まず現場で最も使用頻度が高く、圏外で困る場面が多い機能から着手するのが現実的だ。点検記録の入力、配送の受領確認、在庫の数量登録といった、現場作業の中心となる機能を優先し、利用頻度の低い管理系の画面や集計機能は当面オンライン専用のままにしておく、という切り分けが有効だ。
同期の仕組みについても、最初から複雑な競合解決ロジックを組み込む必要はない。まずは単純な更新日時ベースの同期から始め、実際の運用データを見ながら競合が起きやすい箇所を特定し、そこだけ丁寧に設計を作り込んでいく。シンプルな設計から始めて現場の実態に合わせて段階的に育てていく進め方の方が、結果として使われ続けるシステムになりやすい。
圏外でも歩みを止めない現場を支える
地下の機械室で、山間部の配送ルートで、電波の届かない倉庫の奥で、それでも手を止めずに仕事を進めている人たちがいる。彼らは通信環境を選べない場所で、それでも記録を残し、届けるべきものを届け、次の現場へと進んでいく。オフライン対応の設計は、そうした現場の壁を越えて働く人たちの歩みを止めないための技術だ。電波が届くかどうかにシステムが振り回されるのではなく、現場の人たちがどこにいても迷わず動ける状態をつくること。それこそが、本当の意味での現場に寄り添ったシステム開発だと私たちは考えている。