架空の設備修理会社で、訪問後に新しい報告画面を使ってほしいのに、担当者が紙へ戻っています。現場で端末が使えないのか、選択肢に「部品待ち」がないのか、事務所で同じ内容を打ち直すのかでは、直す場所が違います。「入力していない人」の一覧だけでは原因を判別できません。

一件の訪問について、現場で何を控え、帰社後に誰が何を写したかを見せてもらいます。忙しい本人の説明と実際の画面を照らし、止まった箇所を記録します。IPAのDX推進指標も関係者が現状を共有して話し合う用途を示していますが、特定の入力項目を推奨しているわけではありません。

確認するときの問いは、「なぜ入力しないのか」より、「この訪問ではどこで何を書いたか」です。前者だけだと本人の努力の話になり、端末や項目の不足が見えません。紙に書いた内容と新しい画面を並べて、同じことを何回書いたか、書かなかった情報が誰に必要かを確かめます。責任者が集計を見たい項目と、現場が次の訪問を進めるために必要な項目が違うこともあります。両方の目的を一つの欄へ押し込まないでください。

この章の根拠：出典1

修理の例なら、次の訪問を手配するために「案件番号」「今回の状態」「次の作業」が必要です。責任者が見ない長文の感想欄まで必須にすると、急いだ人は同じ文を繰り返して埋めます。欄を消せばよいのではなく、消しても次の人が仕事を進められるかを確認します。

完成見本は「案件R-12／状態：部品待ち／次の作業：部品到着後に再訪」の三つです。「完了」と「部品待ち」は別にし、短い選択肢へ意味を付けます。安全上必要な記録や契約・法令で必要な項目は、見ていないという理由だけで削りません。W3Cは入力情報や書き方を利用者へ説明する設計を扱っています。

状態の選択肢を作る例では、「作業完了」「部品待ち」「顧客確認待ち」「再訪が必要」を並べます。ただし、部品待ちでも再訪が必要な案件はあります。状態と次の作業を別の欄にすると、どちらか一つを選んで事実を欠くことを避けられます。選択肢の数を減らすことだけを目標にせず、記録の意味を失わないかを現場の数件で確認します。その他欄が頻繁に使われるなら、選択肢を増やすか、分類の問いを作り直します。

この章の根拠：出典2

現場担当者が部品待ちを入力しても、部品の発注や再訪予定が見えなければ、結局は電話で聞きます。画面の完成見本は「R-12：部品待ち／発注確認：事務所が確認中／再訪：未定」です。事務所が予定を入れたら、同じ案件に次の訪問日を返します。未定を勝手に予定へ変える必要はありません。

見せる結果は役割によって変えます。現場は自分の未完了案件、事務所は手配待ち、責任者は長く止まった案件を見る、という設計例です。見てはいけない顧客情報まで全員へ開くことは、結果を返すことと別です。利用者と閲覧範囲は社内の情報管理に合わせて決めます。

返却画面では、「入力済み」の印だけを出すより、本人が次にすることを表示します。たとえば「部品到着は未確認。事務所が仕入先へ確認中。現場は再訪日をまだ約束しない」と読める見本なら、担当者は顧客へ未確定の日付を伝えずに済みます。更新が遅れたときは、情報の更新時点と確認先が分かる表示にします。画面に値があることと、その値が今も正しいことは違うためです。自動通知を増やす前に、この画面が必要な人に届くかを試します。

この章の根拠：出典3

訪問終了時に車内で記録できるなら、案件番号を再入力せず、その訪問から報告欄を開ける形を検討します。手袋をしたまま、小さな文字を多く打つ仕組みは向きません。通信がない場所では一時的に紙へ控えるなど、自社で扱える代わりを設け、後で誰がいつ登録するかを決めます。

代わりの記録にも同じ案件番号と状態を使えば、通常の表へ戻せます。ただし紙を撮れば自動で正式な記録になるとは限りません。読み取れない部分の確認と、二重登録の照合を残します。保存とバックアップを含む情報管理も必要です。便利さのために個人端末へ顧客資料を無制限に残しません。

案件番号だけで二重を判定すると、同じ案件への別日の再訪まで消してしまいます。この例では案件R-12と訪問日を組にして同じ訪問を照合します。複数回の訪問が同日にある会社は、訪問を識別する番号も必要です。代わりの紙から登録する前に、通常入力がすでに戻っていないかを確認し、未登録は作業完了と別に残します。

この章の根拠：出典2出典3

試行の架空結果は「現場の状態入力は続いた。事務所の請求用転記が残った。部品待ちの選択肢がなく自由文になった。再訪予定が返ると電話確認は減った」です。これは方法を説明する想定結果で、導入実績ではありません。続いた理由と戻った理由を別々に記録すれば、項目・画面・連携のどこを直すかを選べます。

使った日数だけを評価すると、意味のない入力を埋めることが目的になりがちです。案件の漏れ、状態の間違い、確認の電話、再転記に使う時間を同じ範囲で確認します。手間が減ってもそのまま現金利益へ換算せず、担当者が何の仕事へ時間を使えたかを確かめます。

費用は、利用人数、項目の変更、既存表への連携、説明、保守で変わります。項目の見直しだけで解決するなら大きな開発は不要かもしれません。複数の人が同時に更新し、進行状態を共有する必要があるなら、表の工夫と専用の仕組みを比較します。試す前に必要な完成範囲を見積へ伝えます。

方法の比較は、いまの表を直す、フォームで入力する、専用の案件管理を使う、の三案で考えられます。表は変更しやすい反面、同時更新や案件ごとの権限を確認します。フォームは入力をそろえやすい反面、入力後の訂正と結果返却が別に必要です。専用の仕組みは状態や予定を共有しやすい場合がありますが、既存の請求表との二重入力や設定・保守の費用が残ることもあります。機能名ではなく、一件を最後まで通した完成見本で比べてください。

この章の根拠：出典1

システムへ戻るよう注意するだけでは、入力しづらい理由は消えません。最近の一件をたどり、必要な項目と選択肢を見直し、入力した本人が使える結果を返してください。紙を併用する必要がある仕事は、その記録が戻る道を先に作ります。

記入表は案件R-12の架空例です。対象、入力者、使う結果、代わりの記録、比較する手間を、自社の仕事へ置き換えられます。フォームの制作依頼には入力欄の一覧だけでなく、現場へ返す画面の見本も添えると、同じ完成像を共有できます。

この章の根拠：出典1出典2出典3