紙の申込書をWebフォームにする。PDFの商品一覧を画面にする。言葉にすると簡単ですが、実際に着手すると「この選択は誰が確認するのか」「該当しない場合はどこへ戻すのか」「受付後は何へ転記するのか」が次々に出てきます。
私たちの制作でも、紙の注文手順をカテゴリ選択から受付まで組み直した案件や、検索から申込、社内システムへの連携まで整理した案件がありました。画面をきれいに並べただけでは、これまで担当者が会話や手作業で補っていた判断が抜け落ちます。
ここでは、紙やPDFをそのまま画面へ写すのではなく、利用者の行動と受付側の仕事を一つのWeb業務へ変換する方法を整理します。
帳票ではなく、実際の一日を聞く
最初に見るのは用紙の項目ですが、仕様を決める材料は用紙だけでは足りません。担当者が受け取ってから何を確認し、どこへ転記し、不足があれば誰へ連絡するかまで聞きます。
- 利用者は何を見て申込・注文を始めるか
- 選択肢や数量を決めるために、別の資料を参照していないか
- 受付後に人が計算、照合、承認している項目は何か
- 電話やメールで補っている例外は何か
- 完了後に、台帳、基幹システム、配送担当などへ何を渡すか
紙では一枚に見えていても、実務では複数の役割と判断がつながっています。そのつながりを先に出すと、画面に必要な入力と、画面外に残す仕事を分けられます。
項目より先に、状態と次の行動を並べる
Web化で先に作りたくなるのは入力項目の一覧です。しかし、項目だけでは「途中」「確認待ち」「差し戻し」「受付済み」を表せません。利用者と担当者の双方について、状態と次の行動を並べます。
- 利用者が対象や条件を選ぶ
- 必要な情報と注意事項を確認する
- 入力内容を送信する
- 受付側が不足・重複・対象外を確認する
- 受理、差し戻し、追加確認へ分ける
- 後続の担当・システムへ渡す
この順番が見えると、確認画面や自動返信が必要な理由も、管理画面に必要なステータスも説明できます。
正常に進まない場面を、後回しにしない
紙の運用では、欄外のメモや担当者の判断が例外を吸収しています。Webでは、選択肢にない、在庫や条件が変わった、同じ人が二度送った、途中で戻った、といった場面を仕様にしなければ止まります。
- 選択できない条件を、いつ・どの言葉で伝えるか
- 途中保存や再開が必要か
- 重複送信をどう見分けるか
- 自動で確定せず、人が確認する境界はどこか
- 処理に失敗したとき、利用者と担当者へ何を知らせるか
例外を全部自動化する必要はありません。人が判断するなら、その人に必要な情報と戻し方を用意することが仕様になります。
計算・検索・外部連携を、画面の裏側として分ける
条件検索、料金計算、シミュレーター、顧客管理への登録などが入ると、見た目は一つでも処理は複数になります。入力値、計算結果、外部へ送る値、保存する値を分け、どこが正しい状態を持つか決めます。
外部会社がフォームや計算処理を担当する場合は、画面の幅、項目名、エラー表示、受け渡すデータ、最終確認者まで揃えます。「組み込めば完成」ではなく、組み込んだ後の一連の操作が完了条件です。
受付後の仕事まで通して、初めて完成とする
利用者に完了画面が出ても、通知が届かない、台帳に保存されない、担当部署へ振り分けられないなら業務は終わっていません。受付番号、通知、保存データ、担当者の確認画面、外部連携を一続きで試します。
最初から全パターンを作るより、代表的な一つの申込を、開始から担当者の処理完了まで通す方が早く不足を見つけられます。その後、対象外、重複、取消、情報不足などの境界へ広げます。
Web化の前に確認すること
- 用紙やPDFだけでなく、受付後の実務を確認したか
- 利用者と担当者の状態、次の行動を並べたか
- 電話やメモで補っている例外を拾ったか
- 自動処理と人が判断する範囲を分けたか
- 計算結果、保存データ、外部へ送る値の正本を決めたか
- 外部会社との画面・処理・確認の境界を決めたか
- 代表的な一件を、受付後まで通して確認したか
- 紙の運用を残す場合、Webとの二重管理をどう防ぐか決めたか
