Webとモバイルアプリを1つのバックエンドで運用するための実践プラン

なぜ二つのアプリは乖離するのか

同じ目的で始まっても、二つのアプリが別々のシステムのように動き出すことがあります。オフィスチームには明確な管理用Webアプリが必要で、現場チームには高速なモバイルアプリが必要です。どちらも同じ作業、顧客、フォーム、ステータス更新を扱いますが、日々の運用の違いがそれぞれのアプリを形作ります。

ここから分裂が始まります。オフィスのスタッフは作業指示を作成して予定を組む一方で、現場のスタッフは現場でそれを更新します。同じレコードに両者が触れても、各アプリが異なる扱いをすると問題はすぐに現れます。Webで「割り当て済み」とマークされた仕事が、モバイルでは「作業可能」と扱われることがあるかもしれません。一方のアプリで必須のメモが、もう一方では任意になっていることもあります。するとそのレコードは一つの明確な履歴を伝えなくなります。

主な原因はロジックの重複です。ビジネスルールが両方のアプリに組み込まれると、小さな差異が実際の矛盾に発展します。ある画面では技術者が写真なしでタスクを完了できるかもしれませんが、別の画面では写真がないと請求を止めることがあります。結果としてステータスは完了を示しているのに、データが不完全という事態になります。

名称もずれていきます。あるチームは「訪問完了」と言い、別のチームは「作業完了」と言い、管理者は「クローズ」と言うかもしれません。会話では十分に似ているように聞こえても、ソフトウェア上では別のステップ、フィルター、レポートになってしまいます。新しいメンバーが目の前の画面からプロセスを学ぶと、この混乱は時間とともに増します。

小さな変更でもギャップは広がります。承認ステップの追加、署名の必須化、顧客項目の追加は些細に思えても、二か所で作り直す必要があると、一方が先に更新されてもう一方が追いつくまで遅れが生じます。その遅れが手戻りやサポート問題、不整合なデータを生みます。

だからこそ共有バックエンドが重要です。管理用Webアプリと現場用モバイルアプリがレコードは共有してもルールを共有していないと、システムは徐々に二つに分かれていきます。

まずは一つの共有ワークフローから始める

画面を考える前に、最初から最後まで実際のプロセスを書き出してください。依頼が作られる瞬間から、仕事がクローズ、承認、請求される瞬間までを記述します。これが両方のアプリの骨格になります。

よくある間違いは、管理用Webアプリと現場用モバイルアプリを別々のプロダクトとして設計することです。そうすると同じプロセスの二つのバージョン、同じステータスの二つの意味、後で必要となる手動修正が生まれがちです。ワークフローを最初に決めることが重要です。

平易な言葉を使いましょう。例えば：依頼作成、割り当て、受諾、作業中、一時停止、完了、レビュー済み。次に各ステップを見て誰が関わるかを確認します。いくつかのステップは両方の役割に属します。オフィスの担当者が作業を割り当て、現場の作業者がモバイルで受諾することもあります。どちらも別々のワークフローではなく、同じワークフローの一部です。

まず共有ステップに印をつける

計画する最も簡単な方法は、共有アクションとデバイス固有のアクションを分けることです。

共有アクションは、依頼の作成、作業者の割り当て、ステータス更新、メモ追加、ジョブのクローズなどです。Web寄りのアクションはキューのレビュー、再割り当て、完了の承認、レポートの実行などが多いでしょう。モバイル寄りのアクションはタスクの受諾、写真アップロード、署名取得、到着のマークなどが代表的です。

これによりアプリがどこで異なるべきか、どこで同じであるべきかが見えてきます。Webアプリはより多くのフィルターや管理コントロールを表示できます。モバイルは大きなボタンと選択肢を減らしたUIが向いています。しかしステータスロジック、検証、ビジネスルールは一つにまとめるべきです。

ステータス変更の単一の信頼できる情報源を早い段階で決めてください。たとえば、タスクが「完了」に移るには写真と顧客の署名が必要なら、そのルールはバックエンドに置くべきです。モバイル画面や管理パネルだけに存在してはいけません。

簡単なテストがあります：同じアクションがどちらのアプリからも起きるなら、結果は同一であるべきですか？答えが「はい」なら、あなたのワークフローは共有されています。そうでないなら、ビジネスルールがインターフェース内に隠れている可能性があります。

コアデータモデルを定義する

画面から始めず、両方のアプリが合意する必要のあるレコードから始めてください。毎日あなたのビジネスが追跡している実際の物を考えます：顧客、場所、作業、スタッフ、在庫、請求書、点検など。管理用Webアプリと現場用モバイルアプリの両方が同じ作業に触れるなら、その作業は一つの共有データモデルの一つのレコードとして存在するべきです。

有用なテストは「この二つのアプリが真実について意見が合わないことがあり得るか？」と自問することです。もし答えが「はい」なら、モデルは誤った場所で分かれています。バックエンドが単一の真実の情報源であるべきです。

各コアレコードについて、共有フィールドは一緒に保持します。作業指示なら、ID、ステータス、顧客、場所、割り当てられた作業者、予定日、完了日、メモ、添付ファイル、写真などを含むでしょう。

これらのフィールドは見た目が違っても両方の体験にとって重要です。管理チームはスケジュールを編集しスタッフを割り当てるかもしれません。現場チームはスケジュールを閲覧し写真をアップロードし仕事を完了としてマークするだけかもしれません。それでも同じレコードであり、権限が違うだけです。

役割固有のフィールドは、本当に必要な場合だけ追加してください。例えばディスパッチが内部優先度スコアを必要とするなら同じ作業指示に保存して現場ユーザーからは隠すことができます。モバイル作業者にオフライン同期フラグやデバイスキャプチャのメタデータが必要なら、主な業務上の意味を変えないように慎重に追加します。

アプリを実務で使いやすくするサポートフィールドも忘れないでください。所有者は誰がレコードを作成・所有・割り当てられているかを示します。タイムスタンプはいつ作成・更新・開始・完了したかを示します。ファイルや画像は作業の証拠になります。メモは例外を説明するために使われ、主要データを変えることなく補足できます。

AppMasterを使っている場合、通常は共有エンティティを先にモデリングし、それからWebとモバイルで異なるUIとアクセスルールを適用します。こうすることでロジックは二つのインターフェースに広がるのではなくバックエンドに集中します。

ビジネスルールを画面の中に置かない

管理用Webアプリと現場用モバイルアプリがそれぞれ許可を決めると、ほぼすぐに乖離が始まります。ある画面はある値を受け入れ、別の画面はそれを拒否する、あるいはあるアプリでは仕事を「完了」にできるが別のアプリではまだ「作業中」と見なす、といったことが起きます。

解決はシンプルです：ビジネスルールをバックエンドに置き、両方のアプリが同じロジックを呼び出すようにします。

検証ルールは一か所に置くべきです。作業指示に顧客、場所、少なくとも一つのタスクがないと割り当てできないなら、バックエンドが常にそれを強制します。Webアプリは親切なメッセージを表示し、モバイルも同様にしますが、どちらもルールを所有してはいけません。

ステータス変更も同様です。両方のアプリで共有されるステータスフロー（例：「下書き」「割り当て」「作業中」「完了」「クローズ」）を使ってください。そのフローがバックエンドにあると、両方のアプリは同じ経路に従います。管理チームはWebで作業を割り当て、現場チームはモバイルで進捗を更新しますが、バックエンドが許可しなければどちらのアプリもステップを飛ばせません。

計算やチェックも一か所で行うべきです。合計費用が時間、材料、税、承認制限に依存するならバックエンドで計算します。技術者が写真や署名がないと作業を閉じられないなら、そこでもチェックします。

実務でのイメージ

サービス会社を想像してください。オフィスチームはWebアプリで仕事を作り、技術者は現場でモバイルアプリを使います。両方のアプリは仕事の作成、担当割り当て、ステータス変更、合計計算に同じバックエンドロジックを呼び出すべきです。

この分離により画面は簡潔になります。各アプリはユーザーが見て行うべきことに集中し、バックエンドが一貫して守るべきルールを保持します。

計画の進め方（ステップ・バイ・ステップ）

まず画面ではなく人から始めます。誰がシステムを使い、何をし、どの選択を許可されているかを書き出してください。

管理用Webアプリと現場用モバイルアプリであれば、通常はオフィススタッフ、マネージャー、現場作業者が関わります。オフィスチームは仕事を作成し、担当を割り当て、変更を承認し、作業をクローズすることが多いです。現場チームは割り当てられた仕事を閲覧し、進捗を更新し、メモを追加し、証拠をアップロードします。

それが明確になったら、1ページに共有データモデルをスケッチします。最初はシンプルに：作業、顧客、スタッフ、場所、写真、ステータス履歴。各レコードに本当に必要なフィールドだけを追加します。

ページではなくレコードと状態変化を中心に設計します。両方のアプリが同じ作業に触れるなら、同じステータス値、同じ割り当てルール、同じ承認ロジックを使うべきです。

シンプルな計画順

1. 各ユーザーロールの主要なアクションを列挙する。
2. 各アクションが読む／変更するデータを記す。
3. ステータスルールを明確に定義する。
4. 各画面を必要なデータにマッピングする。
5. 実際のタスクでモデルをテストする。

最後のステップが最も重要です。例えばオフィスで修理依頼を作成し、技術者に割り当てられ、現場で更新され、マネージャーがレビューする、といった現実的なケースを取り上げます。モデルがスクリーン固有の隠れたルールなしでその流れを処理できれば、正しい道を歩んでいます。

各アプリで何が違うべきか

バックエンドは共有しておくべきですが、体験は同じである必要はありません。管理用Webアプリと現場用モバイルアプリは役割が違うので、同じレコードを別の見せ方で提示するべきです。

Web側では広い視点が求められます。多くのレコードを比較し、列でソートし、履歴を走査し、フィルターを実行し、まとめて更新をかけることが多いです。ディスパッチャーや運用マネージャーは複数の作業指示を一度に更新し、スタッフを割り当て、テーブルでステータス変化を確認したいでしょう。

モバイルでは概観よりも速度が重要です。現場作業者は通常「次に何をするか」を一目で知りたいだけです。ホーム画面は次のタスク、住所、連絡先、期限、ステータス更新ボタンを前面に出すべきです。

同じデータ、違う見せ方

重要な考え方は単純です：レコードは同じまま、レイアウトを変える。両方のアプリが同じ作業、顧客、ステータス、メモオブジェクトを使えば、ビジネスルールは一か所に保てます。

変わるのはインターフェースです。Webは密なテーブル、保存済みフィルター、バルク編集ツールを表示できます。モバイルは現在のタスクと次のアクションを強調します。モバイルはカメラ写真、署名、バーコードスキャン、位置情報などを収集できます。Webは詳細なレビュー、報告、例外処理を支援します。

オフライン利用も実際の違いです。フィールドアプリは地下や移動中、顧客先で電波が届かないことがあります。これは同期設計、競合処理、デバイスにキャッシュすべきデータに影響します。管理用Webアプリは安定した接続を前提にすることが多く、ライブ更新に頼れます。

検査プロセスの単純な例を考えると、オフィスチームはWebで訪問を割り当て、結果を確認し、不備を一括で修正します。検査員はモバイルで次の訪問を開き、写真を撮り、到着を確認して報告を提出します。画面は違っても検査レコードは同じです。

単純な例のシナリオ

機器修理を扱うサービス会社を想像してください。オフィスの担当者はラップトップで作業し、技術者は一日の多くを移動して過ごします。

ディスパッチャーは管理用Webアプリで新しい作業指示を作成します。顧客名、住所、問題の詳細、優先度、予定時間、割当技術者を入力します。それはWeb版の別レコードではなく、1つの共有レコードを作ります。

後で技術者が現場のモバイルアプリを開くと、同じ作業指示が見えます。画面は異なりますが基になるデータは同じです。技術者は住所を見て顧客に電話をかけ、作業内容を確認し、再入力することなく進捗を更新できます。

現場で技術者は壊れた部品の写真を追加し、簡単なメモを書き、顧客の署名を取得します。それらはすべて同じ作業レコードに保存されます。モバイルが写真やメモのための別システムを作るのではなく、共有データモデルに情報を追加しているだけです。

オフィスに戻ると、マネージャーは管理用Webアプリで更新された作業を確認できます。現場で追加された項目を見て作業を承認し、請求やフォローアップに回せます。誰も二つの真実を比較する必要はありません。

ステータス履歴がこれを有用にします。ディスパッチャーが作業を「予定済み」に設定し、技術者が「作業中」にマークし、マネージャーが「完了」としてクローズすれば、誰もが同じタイムラインを見ることができます。これにより「誰がいつステータスを変えたか」「訪問の前後に何が起きたか」を簡単に答えられます。

避けるべき一般的な間違い

最大の間違いは同じルールを二か所に置くことです。管理用Webアプリが「予定済み」から「作業中」に移れると言い、モバイルアプリも同じチェックをするなら、そのルールは必ず乖離します。ステータス変更、権限、必須チェックはバックエンドにまとめて、両方のアプリが同じロジックに従うようにしてください。

別レコードを作ってしまうのもよくある問題です。オフィス側の見え方を変えたいがために、管理アプリには「アポイントメント」、モバイルには「訪問」といった別のレコードを作ると、それらを同期させ続ける必要が生じます。結果はメモの不一致、重複更新、どのレコードが正しいかの混乱です。

フィールド（列）をどんどん追加してしまうのも罠です。あるチームが「あと一つだけ詳細が欲しい」と言うと追加しがちですが、すべてのフィールドには目的があるべきです。そのフィールドがなぜ重要か、誰が使うか、レポートや判断に影響するかを問ってください。明確でないなら、必要になるまで追加しない方がいいです。

弱い接続は現場初日にまで無視されがちです。技術者は地下、地方の道中、電波の悪い倉庫でアプリを開くことがあります。アプリがすべての操作にライブ接続を必要とするなら作業が止まります。どのデータをオフラインで持つべきか、どのアクションを後で同期してよいか、再接続時の競合はどう処理するかを計画してください。

名称のずれも共有システムを壊します。あるチームが「割り当て済み」と言い、別のチームが「派遣済み」と言い、第三者が「作業準備完了」と言うと、人々はそれらを別の状態として扱い始めます。早い段階で共通の語彙に合意し、どこでも同じ用語を使ってください。

簡単な直感チェックはこうです：1つの仕事は1つの真実の情報源を持つべき、1つのルールは1つの場所に置くべき、1つのステータスは1つの明確な名前を持つべき、です。

構築前の簡単な確認

何かを構築する前に、紙の上で計画をテストしてください。モデルが数分で説明できるほどシンプルなら、多くの場合アプリが成長しても安定して保てます。

良いチェック項目はこれです：両チームが同じレコードを指して同じ意味を持てますか？オフィスチームが仕事、タスク、顧客、検査報告を現場チームと異なる見え方で見ているなら、乖離は早く始まります。

短いチェックリストを使いましょう：

• 作業指示のようなコアレコードを1つ選び、両アプリが同じバージョンを読んでいることを確認する。
• 検証ルールは各画面の中ではなくバックエンドに一度だけ書く。
• すべてのステータス変更を一つの経路としてテストする。
• モデルを一つの簡単な図に描く。
• モバイルビューは本当に必要最低限にそぎ落とす。

小さなシナリオが役に立ちます。管理用Webアプリが修理訪問を予定し、モバイルアプリが技術者の当日の仕事を表示するとします。管理チームはフィルター、レポート、顧客の完全な履歴を必要とし、技術者は今日の仕事、連絡先、注意事項、ステータス更新の方法だけを必要とします。画面が違うのは問題ありません。ビジネスルールが違うのは問題です。

もう一つ実用的なテスト：ルールを変更してどれだけ多くの場所に手を入れる必要があるか見てください。例えば「完了前に写真が必須」を変えるのにバックエンドロジックと複数の画面を編集する必要があるなら、設計は既に分裂し始めています。

次のステップ

Webとモバイル両方に1つのバックエンドを作りたいなら、最初にすべての画面やすべてのチーム要求をマッピングしてはいけません。まず日常的に重要な1つのワークフローから始めてください。例えば仕事の作成、割り当て、ステータス更新、クローズです。小さなワークフローはテストしやすく、データモデルがどこで明確でどこにギャップがあるかを素早く示します。

画面を磨く前にバックエンドのルールを作ってください。どのフィールドが必須で誰がステータスを変更できるか、データが欠けているとどうなるか、どのアクションがアラートやフォローアップをトリガーするかを決めてください。それらのルールがバックエンドにあると、管理用Webアプリと現場用モバイルアプリは見た目が違っても同じロジックに従えます。

実践的な順序はシンプルです：主要なレコードと関係を定義し、コアなビジネスルールとステータス変更を書き、サンプルデータでワークフローをテストし、オフィス向けのWebビューと現場向けのモバイルビューを設計し、実ユーザーと最初のバージョンをレビューします。

その順序がよくある間違いを避ける手助けになります：二つの磨かれたアプリを作ってしまい、互いに矛盾しているという事態です。

もしより早く進めたいなら、AppMasterのようなノーコードプラットフォームが役立ちます。データとビジネスロジックを一か所で定義し、同じ基盤の上にWebアプリとネイティブモバイルアプリを構築できます。

最初のリリースは小さく保ってください。マネージャー1人にWebアプリで実際のタスクを使ってもらい、現場作業者1人に実際のシフトでモバイルを使ってもらいましょう。どこで躊躇するか、何をスキップするか、次に何が起こることを期待しているかを観察します。まずそのポイントを直し、次にワークフローを増やします。

通常これが最も安全な道です：共有モデル1つ、ルール1セット、そして実際の仕事に合わせて形を変えた2つの体験です。