行政・地域団体の業務システムで、画面より先に決める7項目

年度で担当者が替わり、複数の権限・申請・集計を扱う行政部署や地域団体向けの記事です。

行政、団体、地域事業で使うシステムにも、見やすいデザインは必要です。

ただし、画面の色や配置より先に決めなければならないことがあります。

誰が、どの権限で、何を記録し、担当者が変わっても運用できるか。ここが曖昧なまま作ると、見た目は整っていても現場では使えません。

行政向けの納品経験を通じて、特に重要だと感じる視点を整理します。

■ 1．利用者と権限

同じシステムでも、担当者、管理者、承認者、外部事業者、閲覧だけの人では、できることが違います。

・誰が新規登録できるか

・誰が修正できるか

・誰が削除できるか

・個人情報を見られる人は誰か

・退職や異動時にどう停止するか

役割ごとに整理します。

全員を管理者にすると楽に見えますが、誤操作と情報漏えいのリスクが上がります。

■ 2．記録を残す範囲

データの現在値だけでなく、誰がいつ変更したかが必要な場合があります。

申請、承認、差戻し、取消、再提出など、判断の履歴を残します。

ただし、何でも記録すると画面と保管が複雑になります。監査、問い合わせ、引継ぎで本当に必要な履歴を決めます。

■ 3．例外処理

制度や地域業務では、通常ルールに当てはまらないケースが必ず出ます。

・期限後の受付

・添付不足

・代理申請

・重複登録

・担当区域外

・承認後の訂正

例外をすべて自由入力で処理すると集計できません。反対に、例外を禁止すると現場が紙へ戻ります。

よくある例外は選択肢にし、特殊なケースは理由と承認を残す設計にします。

■ 4．引継ぎと属人化

行政や団体では、年度や異動で担当者が変わります。

開発者や前任者に聞かないと設定を変えられない状態は避けなければなりません。

・日常操作のマニュアル

・管理者向け設定資料

・データ項目の意味

・障害時の連絡先

・バックアップと復旧方法

を残します。

マニュアルは分厚くするより、実際の業務単位で短く分けるほうが使われます。

■ 5．個人情報と保存期間

便利だから保存するのではなく、業務上必要だから保存するという考え方が重要です。

取得目的、閲覧権限、保存期間、削除方法、出力データの扱いを決めます。

テスト環境へ実データを入れない、画面共有時に個人情報を見せないなど、開発・保守の運用も対象です。

■ 6．集計の定義

同じ「件数」でも、申請件数、承認件数、利用者数、対象世帯数では意味が違います。

月次報告や議会・理事会資料へ使う場合は、集計条件を先に決めます。

画面上の数字とExcel出力の数字が一致しないと、システムへの信頼が失われます。

■ 7．停止したときの業務

ネットワーク障害やメンテナンスで使えない時間が発生する可能性があります。

そのとき受付を止めるのか、紙で仮受付するのか、復旧後に誰が入力するのかを決めます。

システムだけでなく、業務継続まで設計します。

■ デザインは、ルールを分かりやすくするために使う

ここまで決めた後で、画面設計が生きます。

重要な項目を目立たせる、権限外の操作を見せない、エラー時に次の行動を伝える、スマートフォンやタブレットでも押し間違えない。

デザインは飾りではなく、決めた業務ルールを利用者へ正しく伝えるものです。

■ 最初の会議で画面案を見せない理由

システム開発の打ち合わせで画面案を出すと、話は進んだように見えます。

「このボタンは青がいい」「一覧を広くしたい」「検索欄を上に置きたい」と、参加者が意見を出しやすいからです。

しかし、行政・地域団体の業務で本当に時間がかかるのは、画面の配置ではありません。

・誰の判断を正式な承認とするか

・紙とシステムが食い違った場合はどちらを正とするか

・制度変更時に過去データをどう扱うか

・例外を誰が認め、どの記録を残すか

・年度をまたいだ案件を誰が引き継ぐか

ここを決めないまま画面を作ると、後からボタン一つの変更では済まなくなります。データ構造、権限、帳票、通知まで連鎖して作り直すことになります。

最初に作るべきものは完成画面ではなく、業務の地図です。

■ 業務の地図は「通常」と「例外」を分けて描く

まず、一件の申請や案件が、受付から完了までどう進むかを時系列で並べます。

たとえば、受付、内容確認、不備連絡、再提出、審査、承認、支払い、完了報告、保管です。

次に、それぞれの段階で次を確認します。

・担当者は誰か

・入力する情報は何か

・判断に必要な資料は何か

・次へ進める条件は何か

・差し戻す条件は何か

・期限を過ぎたらどうするか

・本人以外が代理で行う場合はどうするか

通常ルートだけをきれいに描くと、実運用で止まります。現場で困っている案件を5〜10件出してもらい、その例外が地図のどこに入るかを確かめるほうが、要件の解像度は上がります。

■ 権限表は役職名ではなく「行為」で作る

「担当者」「管理者」という名前だけでは不十分です。

閲覧、登録、編集、承認、差戻し、取消、削除、CSV出力、設定変更、ユーザー管理を行為ごとに並べ、誰ができるかを表にします。

特に削除と修正は分けます。誤入力を直す権限が必要でも、記録そのものを消せる必要はないことがあります。

また、外部事業者が関わる場合は、自社案件だけ見えるのか、地域全体を見られるのか、添付資料まで見えるのかを分けます。

権限表はセキュリティ資料であると同時に、責任の所在を明確にする業務設計書です。

■ 履歴は「残す」だけでなく「読める」ようにする

変更履歴を大量に保存しても、問い合わせ時に探せなければ役に立ちません。

誰が、いつ、どの項目を、何から何へ変更し、なぜ変更したか。最低限の文脈を一覧で追える必要があります。

承認後の訂正には理由入力を必須にする、重要な変更は元の値を残す、帳票を再発行したら版を区別するなど、業務上の意味に合わせます。

一方で、操作のすべてを永久保存すればよいわけでもありません。保存目的、保存期間、閲覧権限を情報管理の方針と合わせます。

■ データ項目は、入力欄ではなく「将来の証拠」

画面に入力欄を追加するのは簡単です。しかし、その項目が何を意味するかが曖昧だと、数年後の集計に使えません。

たとえば「利用者数」が、申請書に書かれた人数なのか、実際の参加人数なのか、延べ人数なのかで報告値は変わります。

項目ごとに、名称、定義、入力者、入力時点、必須条件、選択肢、集計での使い方を決めます。選択肢を変更した場合、過去データの表示や集計をどう扱うかも決めます。

このデータ辞書があると、担当者交代、制度改正、CSV連携のときに判断がぶれにくくなります。

■ 個人情報は「集めない設計」から考える

入力できるから集める、将来使うかもしれないから残す、は避けます。

業務目的に必要な項目だけに絞り、閲覧できる人を限定し、不要になった後の扱いを決めます。

添付ファイルには、想定していない個人情報が含まれることがあります。ダウンロード権限、端末への保存、メール添付での共有、印刷物の扱いまで運用に含めます。

開発会社が保守のために閲覧する必要があるのか、テストでは匿名化したデータを使えるのかも、公開後ではなく契約・設計段階で確認します。

■ 年度替わりを「一度だけの特殊処理」にしない

行政・地域団体では、年度の切替が毎年起こります。

利用者の所属変更、予算区分、申請番号、選択肢、受付期間、帳票様式、担当者権限などが一斉に変わることがあります。

毎年、開発会社へ直接データを書き換えてもらわないと更新できない仕組みは、運用コストと事故の原因になります。

管理画面で安全に変更できる項目と、影響が大きいため保守担当が変更すべき項目を分けます。年度更新の手順書を作り、事前確認、切替、切替後確認、戻し方まで一連で試します。

■ 紙やExcelをすぐ廃止しない

新システムの公開日に、既存業務を全面停止するのは危険です。

一部の部署や少数案件で試し、入力結果、帳票、集計、権限、問い合わせ対応を確認します。一定期間だけ旧台帳と突き合わせ、差が出た理由を調べます。

ただし、二重入力を無期限に続けると現場負担が増えます。試行期間、比較項目、移行判定、旧方式を止める日を最初から決めます。

小さく始めるとは、機能を適当に減らすことではありません。受付から完了までの一本の業務を、狭い対象で最後まで通すことです。

■ 受入テストは「機能が動く」だけでは足りない

納品前には、仕様書どおり動くかだけでなく、現場の仕事が完了するかを確認します。

・通常申請が最後まで処理できる

・不備、取消、再提出を扱える

・権限外の情報が見えない

・必要な帳票とCSVが正しい

・同じ条件で集計結果が一致する

・スマートフォンや庁内端末で操作できる

・障害時の仮受付と復旧後入力が行える

・担当者交代後も資料だけで主要操作ができる

テスト用のきれいなデータだけでなく、文字数が長い住所、未入力、同姓同名、年度をまたぐ案件など、現場に近い条件を使います。

■ ベンダーが変わっても業務を続けられるか

システムは何年も使う可能性がありますが、担当者や保守会社は変わるかもしれません。

データを一般的な形式で出力できるか、添付ファイルを対応付けて取り出せるか、設定値と集計定義が文書化されているか、契約終了時の引き渡し範囲は何かを確認します。

すべてを内製できる必要はありません。ただし、現在の開発者にしか分からない状態は避けます。発注側が自分たちの業務ルールとデータを説明できることが、最も重要な主導権になります。

■ 成功指標は「導入したこと」ではなく業務の変化

公開日を迎えることは成果の始まりです。

受付から処理完了までの日数、不備差戻し率、重複入力時間、月次集計時間、問い合わせ件数、引継ぎにかかる時間など、導入前後で比べる指標を決めます。

数字だけでなく、「どの作業が楽になったか」「新しく増えた負担はないか」「紙へ戻っている工程はないか」も現場へ聞きます。

システムが使われない理由を、職員の慣れや意識の問題だけにしないことが大切です。説明不足、権限不足、画面遷移、処理速度、例外への未対応など、設計側で直せる原因を分けます。

行政・地域団体のシステムは、派手な機能の数で評価するものではありません。制度が変わり、人が替わり、例外が起きても、説明可能な形で業務を続けられること。その土台を作る仕事です。

■ 仕様書を「機能一覧」から始めない

「ログインできる」「検索できる」「CSVを出せる」と機能を並べても、業務の正解は決まりません。

先に必要なのは、受付から完了までの業務地図です。通常処理だけでなく、不備、差戻し、承認後の訂正、担当区域外、期限超過、代理申請、重複登録などを同じ地図に置きます。

それぞれについて、誰が判断するか、何を根拠にするか、どこまで処理を戻すか、履歴へ何を残すかを決めます。この地図ができると、必要な画面と不要な画面が自然に分かれます。

逆に地図がないまま画面を増やすと、例外が起きるたび自由記述欄と管理者機能が増え、数年後には誰も全体を説明できなくなります。

■ 最初の打合せで、完成画面を見せすぎない

きれいな画面案は話を進めやすく見せます。しかし早い段階で完成形を見せると、議論が色、文字サイズ、ボタン位置へ寄り、本来決めるべき業務ルールが後回しになります。

最初に見せるのは、業務フロー、権限表、例外一覧、データ辞書のたたき台です。参加者に「このケースは誰が判断しますか」「紙とシステムが食い違ったら何を正としますか」「年度をまたぐ案件は誰が引き継ぎますか」と問い、判断を言葉にしてもらいます。

画面は、その回答を利用者へ誤解なく伝えるために作ります。デザインは飾りではなく、決めた業務ルールを正しく実行してもらうための翻訳です。

■ 受入条件は、納品直前ではなく発注前に決める

「仕様書どおり動く」だけでは、現場で使える保証になりません。通常申請、不備差戻し、権限外操作、通信中断、二重送信、担当者交代など、実際に起こる場面を受入テストへ入れます。

誰が、どの端末で、どのデータを使い、何が確認できたら合格かを先に決めます。紙やExcelと並行運用する場合は、どちらを正とするか、差が出たとき誰が直すか、並行運用を終える日も受入条件の一部です。

この合格条件が明確なら、発注側も受注側も「作ったつもり」「聞いていない」を減らせます。

■ 図解で整理：画面より先に決める設計物

ここからは、業務地図、権限、履歴、例外、引継ぎ、受入テストを6枚の図解で整理します。

図解1｜通常ルートと例外ルートを一枚の業務地図にする

図解2｜権限を「できる行為」の表で合意する

図解3｜差戻しや訂正の理由まで、後から読める履歴にする

図解4｜例外は自由入力ではなく、判断と承認の流れにする

図解5｜担当者交代に耐える引継ぎ資料を納品物に含める

図解6｜受入テストは実際の例外と障害まで通す

石井DXスタジオでは、行政向け納品の経験と経営者目線を活かし、紙・Excel業務の整理から、権限・例外・引継ぎまで含めたWebアプリ設計に対応しています。

ご相談は、プロフィールの出品サービス「紙・Excel業務のWebアプリ化」からお気軽にどうぞ。