画面の色や機能一覧を決める前に、現場の仕事を言葉にできるかが成否を分けます。ここではMaka houが小規模な専用Webアプリを考える際に、最初に確認する五つを実務向けに整理します。
1. 実際の手順を「担当と物」で書く
マニュアル上の理想ではなく、紙を受け取る、LINEで確認する、Excelへ写す、担当者へ電話する、という現状を書きます。机の上を移動する紙や、アプリ間を移動するデータを矢印でつなぐと、待ちと転記が見つかります。
2. 正しい情報がどこにあるか決める
顧客住所は顧客台帳、予定は共有カレンダー、在庫数は在庫台帳というように正本を一つ決めます。「紙も正しい、Excelも正しい」では不一致時に判断できません。移行期間だけ併用する場合も終了日を置きます。
3. 普通ではないケースを先に集める
返品、取消、代理入力、後日修正、通信切れ、同姓同名、商品名変更など、例外は公開後に必ず現れます。通常手順だけで設計すると、例外を自由記入欄で処理し、検索不能になります。過去1か月の「困った処理」を集めると現実的です。
4. 見る人と変える人を分ける
全員が編集できる必要はありません。在庫を閲覧する人、入出庫を登録する人、商品マスターを変える人を分けます。顧客情報や利用履歴では、端末紛失や退職時の停止方法も決めます。
5. 成功を数値か行動で決める
「使いやすいシステム」では測れません。「送り状作成の転記を0回にする」「予定確認の電話を半分にする」「未対応を朝の一覧で発見できる」など、導入後に確認できる状態にします。
個人情報を消した帳票見本、画面の写真、項目名だけでも十分に手順を確認できます。顧客固有情報や社外秘情報は、安全な共有方法が決まるまで渡さないようにします。
最後に“一番小さい公開範囲”を決める
五つを整理したら、単独で役立つ機能を一つ選びます。検索、当日予定、CSV変換などです。現場で使って初めて分かることを、次の改修へ反映します。
「大きな要望」も、聞いてみると核は一つだったりする
最初のご相談で「こんな感じのことがしたい」と幅広く伝えられると、大がかりな開発が必要に思えて身構えることがあります。ただ、実際に五つの項目に沿ってヒアリングしてみると、本当にやりたいことの核は一つだけだった、というケースは少なくありません。話を分解する前提でヒアリングすると、最初の印象より小さく、現実的な形に着地できます。
五つを飛ばすと、公開後にどうなるか
特に多いのが「3. 例外」を飛ばしたケースです。通常の申込みだけを想定して作った予約システムが、公開直後に代理予約やキャンセル待ちで止まり、結局は電話とExcelの二重管理に逆戻りする、というのはよくある流れです。例外を先に集める工程は、地味に見えて公開後の手戻りを一番減らします。
作る範囲の判断は「専用システムが向く会社」、最初の課題発見は「小さな会社の業務効率化」も参考にしてください。