Bubbleで業務アプリを作る際は、画面デザインから始めるより、現在の業務と利用者の役割を整理する方が手戻りを減らせます。小さな版を作るためのチェックポイントをまとめます。
01利用者と目的を明確にする
「顧客管理アプリを作りたい」だけでは必要な画面もデータも決まりません。営業担当、管理者、顧客などの利用者を分け、それぞれが何を入力し、確認し、どこで業務を終えるかを書き出します。現在の表計算やメール運用で困っている点を記録し、最初の版で解決する範囲を絞ります。
02データと権限を一緒に考える
顧客、案件、申請などのデータ型と項目を並べ、誰が検索・閲覧・編集できるか決めます。Bubbleのプライバシールールは、サーバーからブラウザーへ送るデータを制限する重要な設定です。画面上で隠すだけでは権限制御の代わりになりません。権限の異なる利用者で表示を試す計画も含めます。
03例外と運用を先に書く
必須項目が空の場合、二重送信、承認の取り消し、担当者不在などの例外を考えます。さらに、データの修正方法、問い合わせ先、変更を依頼する窓口を用意しておくと公開後の混乱を減らせます。最初は利用者と業務フローを限定し、実際の使われ方を見てから機能を増やすのが現実的です。
04最小構成を一枚にまとめる
業務アプリの初期案は、利用者、画面、データ、承認者、通知先を一枚の表にまとめると会話しやすくなります。「申請者が入力し、上長が承認し、担当者が処理する」という流れなら、各段階で誰が何を見て変更できるかを書き込みます。権限が曖昧なまま画面制作に進むと、後からデータ設計を直すことになりがちです。
公開前には実データに近い試験データを用意し、各役割で最初から最後まで操作します。画面が表示されるだけでなく、承認待ちの滞留や通知の見落としなど、現場で起こる問題も確認しましょう。
05具体例：備品購入申請を最初の版に落とす
「申請者が品名・金額・理由を送る → 上長が承認または差し戻す → 経理が処理済みにする」の一往復だけを初期版とします。画面は申請フォーム、本人の申請一覧、上長の承認一覧、経理の処理一覧の四つから始めます。データは申請、利用者、所属部署を候補にし、申請には申請者、金額、状態、承認者、承認日時を持たせます。状態は「下書き・承認待ち・差し戻し・承認済み・処理済み」のように定義し、誰がどの状態へ移せるかを一覧にします。
この例では、社員Aが送った申請を別部署の社員Cが検索できないこと、上長以外が承認できないこと、差し戻し後に修正して再申請できることを受け入れ条件にします。画面で操作ボタンを隠すだけでなく、データのPrivacy Rulesと処理側の条件を確認します。経理システムとの自動連携は、最初の版で必要と決めた場合を除き、手動処理の結果を記録するところまでに絞れます。
試作を始める前に、実際の申請を匿名化した10件程度を並べ、上限超過・入力不足・同じ申請の二重送信を混ぜてください。「申請から承認まで何分かかるか」「差し戻し理由が申請者へ伝わるか」を現行のメール運用と比較すれば、画面の見栄えではなく業務改善として判断できます。件数は例示であり、実際の評価には自社の頻度と例外を使います。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。