モバイル対応を検討する企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、現場入力の目的とセキュリティ・権限を決めることを重視して進め方を整理します。
この記事では、基幹システムをスマホやタブレットで使えるようにする前に考えておくべきことを整理します。現場入力のモバイル化を検討している製造・物流・営業部門の担当者と、投資判断を行う経営層に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
モバイル対応の目的は端末ではなく「現場のデータ入力」
スマホやタブレットへの対応は、端末を変えることではなく、データの入力場所を現場へ移すことです。倉庫での入出庫記録、工場の作業実績、営業先からの在庫確認や受注入力。これまでオフィスのPCでまとめて入力していた作業を、発生した場所でリアルタイムに記録できるようにすることが本来の目的です。この目的を先に固めないまま「モバイル対応したい」と始めると、何を・どこで・誰が入力するのかが曖昧なまま開発が進みます。
全画面をモバイルに持っていく必要はない
基幹システムの画面は多くの場合、情報量が多くモバイルの小さな画面には向きません。全画面をモバイルに移すのではなく、現場で必要な入力と照会だけを抜き出して専用の画面を作るのが定石です。在庫照会、入出庫のバーコード読取、作業報告の入力、承認操作といった「現場で完結する短い操作」がモバイル向き。明細の一括入力や帳票確認はPCのほうが圧倒的に効率が良い業務です。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、PC画面をそのまま縮小表示してスマホ対応としてしまい、文字が小さすぎて使い物にならないケースです。モバイル対応は画面のリサイズではなく、操作の再設計です。現場で手袋をしたまま使う、日差しの下で画面を見る、歩きながら片手で操作するといった利用環境を前提とした設計が必要です。
また、セキュリティと権限の設計を後回しにする失敗も目立ちます。スマホは紛失・盗難のリスクがPCより高く、個人端末を使うBYOD方式では業務データとプライベートの境界を明確にする必要があります。端末管理・遠隔ロック・アクセス制御を先に設計し、セキュリティ要件を満たしたうえで使いやすさを追求する順序が正しい進め方です。
通信環境の不安定さも見落としがちです。工場の奥や倉庫ではWi-Fiが届かない場所があり、電波状況で入力データが飛んでしまうと現場の信頼を失います。オフライン時の一時保存とオンライン復帰時の同期は、利用環境に応じて必ず検討すべき要件です。
自社で確認できるチェックポイント
モバイル対応の検討を始める前に、次の点を確認しておくと、対象と方式が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
モバイル対応ならではの棚卸しポイント
基本のチェックリストに加えて、現場でモバイル入力を行いたい業務の具体名と1日の件数、利用場所の通信環境（Wi-Fi・モバイル回線の状況）、端末の方針（会社支給かBYODか）、バーコードやQRコードの読取の有無、そして現在その作業を紙やPCでどう行っているかを確認してください。紙の運用を写真に撮っておくと、モバイル画面の設計時にそのまま参考資料になります。
モバイル対応の方式には、Webブラウザで動く方式とネイティブアプリ方式があります。ブラウザ方式はインストール不要で更新が容易、ネイティブ方式はオフライン対応やカメラ・バーコード連携に強みがあります。利用環境と必要な機能で選択しますが、多くの業務入力はブラウザ方式で十分対応できます。
モバイル対応では、入力件数と作業時間の削減効果を導入前後で比較できるよう、現状の計測を導入前に行っておくことをおすすめします。「導入前は1件あたり3分かかっていた手書き+PC転記が、モバイル入力で1分になった」と言えれば、次の展開への説得力が段違いです。
延命・部分改善で対応できるケース
モバイル対応は全面的に行う必要はありません。次のような場合は小さく始めるのが正解です。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
たとえば、倉庫での入出庫バーコード読取だけ、営業の在庫照会画面だけ、といった一業務一画面の開発なら数百万円・2〜3か月で実現でき、効果を実感してから範囲を広げられます。全業務のモバイル化を一度に計画すると、費用と開発期間が膨らみ、全体のリリースが遅れます。
現場の反応を見ながら改善サイクルを回せるのが、モバイル開発の小さく始めやすい特性です。最初のリリースは「最小限の機能で、すぐ使える」を目指し、追加機能は運用を始めてからの要望で決めるのが実践的です。
費用の目安は、一業務・一画面のモバイル対応で数百万円・2〜3か月、複数業務を含むモバイル基盤の構築で1,000万円前後、オフライン同期や端末管理まで含める場合はさらに上積みになります。端末の購入・通信費・管理費もランニングコストとして含めて試算してください。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
次のような状況であれば、モバイル対応単独ではなく再構築の中で設計すべきです。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
クラウド型パッケージにはモバイル対応機能が標準搭載されていることが多く、パッケージ移行がモバイル化への最短ルートになる場合があります。ただし標準のモバイル画面が自社の現場に合うかは実機で確認してください。
周辺開発で補うケース
基幹本体はそのまま残し、モバイル画面だけを周辺開発で追加する構成は最も一般的な進め方です。基幹のデータベースに対してAPI経由で読み書きする形を取れば、本体への影響を最小にできます。
スクラッチ再構築が向くケース
基幹を全面再構築する場合は、最初からレスポンシブ対応のWeb画面として設計できるため、モバイル対応を後付けにする必要がありません。将来のモバイル利用を見据えた設計を、要件定義の段階で織り込みます。
マクティズムの見解
マクティズムの見解として、基幹システムをスマホ・タブレット対応する前に考えることでは「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、現場入力の目的とセキュリティ・権限を決めることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
モバイル対応の相談では、現場に同行させていただくことをお願いしています。オフィスの会議室では見えない利用環境——照明、手袋、ほこり、騒音、通信の不安定さ——は、画面の設計に直結する重要な情報だからです。現場を自分の目で見てから設計するのが、私たちの基本方針です。使う場所を知らずに使いやすい画面は作れない、というのが実案件からの確信です。
相談前に準備しておく情報
モバイル対応の相談では、現場で使いたい業務の具体名、利用場所と通信環境、端末の方針、バーコード読取の有無、現在の紙やPC運用の実態が分かると、初回から方式と費用帯を具体的に話せます。現場の作業を動画で撮っておくと、最も伝わりやすい資料になります。
実務では、現行調査で現場の入力業務を観察し、開発前診断でモバイル化の優先順位と方式を整理したうえで、最小機能でのリリースと改善サイクルを組み込んだ計画をおすすめしています。
モバイル化の効果は、入力の即時化だけでなく、紙の介在を減らすことで転記ミスや記録漏れがなくなるという品質面のメリットも大きい領域です。数字で測りやすいため、投資対効果の説明にも向いています。
現場の手元で完結する入力の仕組みが実現すると、データの鮮度と精度が同時に上がり、管理側のリアルタイムな把握が可能になります。モバイル化は現場だけでなく、経営の判断スピードも変える投資です。
検討は、目的の具体化、対象業務の選定、利用環境の確認、方式の選定、最小機能でのリリース計画、の順で進めてください。最初の一画面の成功が、次の展開を加速させます。
現場に端末を渡す前には、実際の作業環境で一日分の業務を通しで試すパイロット運用を行ってください。会議室でのデモでは見えない課題——バッテリーの持ち、画面の反射、手袋での操作性——はパイロットでしか発見できません。
なお、モバイル端末のOS更新に伴うアプリの動作確認は、運用開始後も継続的に必要です。年に1〜2回のOS大型更新のたびに検証する運用を計画に含めておくと、「ある日突然動かなくなった」という事態を防げます。
モバイル化は小さな画面のためのUI設計が鍵です。情報を詰め込むのではなく、その場で必要な操作だけに絞り込む。「引き算の設計」がモバイル画面の品質を決めます。
現場が「これは便利だ」と自発的に使い始めたとき、モバイル化は成功したと言えます。
その一画面が、現場のデータの質と速度を変えます。小さく始めて、大きく育ててください。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。モバイルの場合、現場で入力したい業務の具体名と利用環境が分かれば十分に出発点になります。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。一業務・一画面から始め、効果を見て広げる進め方が最も堅実です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。標準のモバイル画面が現場に合うかの確認も、パッケージ選定の重要な評価項目として一緒に見ます。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。数百万円・2〜3か月で実現できる最小単位の開発からお受けしています。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。現場の状況をお聞かせください。可能であれば現場見学から始めさせていただきます。
