Summary
この文書の要点
- 最初から紙をなくすことを目的にしない。
- 台帳、進捗、確認結果、添付ファイルを分けて管理する。
- 紙、PDF、入力データ、承認状態を同じものとして扱わず、それぞれの証跡を持たせる。
- 段階移行では、スキャン済み、確認待ち、差し戻し、確定を状態として管理する。
どこが設計の難所か
申請や確認業務では、紙、PDF、Excel、メールが混在しやすく、どれが最新か分からなくなります。完全なオンライン申請を作る前に、既存の提出方法を変えられない制約があることも多いです。
関係者が多い業務では、いきなり入力方法を変えると問い合わせが増えます。法的な保管、押印、原本確認などが残る場合もあります。デジタル化は現場の制約に合わせて段階を分ける必要があります。
紙やPDFが残る業務では、データ入力だけをWeb化しても、原本確認、差し戻し、承認、保管の流れが残ります。ここを無視すると、画面上は完了しているのに紙の確認が終わっていないという二重管理が起きます。
境界をどう切るか
第一段階では、紙やPDFを受け取った後の台帳化、進捗、確認結果、差戻し理由をWebアプリで管理します。提出方法は残しつつ、内部処理の見える化を先に行います。第二段階で入力フォームや外部受付を検討します。
設計では、原本、電子ファイル、抽出データ、業務レコードを分けます。PDFから読み取った値は確定値ではなく候補値として扱い、人の確認によって確定する流れを作ります。
実装で効く細部
データモデルは、案件、提出物、確認ステータス、添付ファイル、コメント、履歴を分けます。画面では、未確認、差戻し、承認済み、期限超過を一覧で見られるようにし、確認結果の理由を構造化して残します。
PostgreSQLには、documents、attachments、extracted_fields、review_tasksのように分けて保存します。React画面ではPDFプレビューと入力フォームを横断させ、どの値が自動抽出で、どの値が人の修正かを見えるようにします。
- PDFファイルのハッシュを保存し、後から差し替わった原本を検出できるようにする。
- 抽出値にはconfidenceやsource_pageを持たせ、確認優先度を決める材料にする。
- 確定後の修正は上書きではなく、修正履歴と理由を残す。
壊れ方を観測する
検証では、紙原本とデジタル台帳の突合、添付ファイルの閲覧権限、ステータス変更履歴、差戻し後の再確認フローを確認します。Excel出力が必要な場合は、出力項目と並び順も業務手順として検証します。
検証では、きれいなPDFだけでなく、傾き、薄い印字、複数ページ、手書き混在、再スキャンを含むサンプルを用意します。処理精度だけでなく、確認者が迷わず修正できるかを画面で確認することが重要です。
捨てた選択肢とトレードオフ
段階導入は一時的に紙とWebの二重管理になります。短期的には手間が増える面もありますが、進捗と証跡が見えることで、次にどこを電子化すべきか判断しやすくなります。
OCRや自動抽出を入れると入力負荷は下がりますが、誤抽出の確認コストが出ます。最初から全項目を自動化するより、頻度が高く判定しやすい項目だけを候補化し、残りは人が確認する構成が安定します。
現場に残す判断軸
紙業務のデジタル化は、紙をすぐになくすことではありません。まず台帳と進捗を整え、現場が混乱しない範囲で入力経路を移すことが、失敗しにくい進め方です。
紙とPDFのデジタル化では、紙をなくすことだけを目標にしない方がうまくいきます。原本、候補値、確定値、承認状態を分けると、段階的に安全な移行ができます。
