補助金・給付金の申請システム開発

補助金の申請システムというと、「入力フォームを作って、送信されたデータを一覧にするもの」と思われがちです。確かに、それだけであれば汎用のフォームサービスでも実現できます。けれども、自治体の補助金・協力金・給付金の現場で本当に求められるのは、フォームの先、つまり申請内容の確認、審査、結果の通知、そして次の期の制度へと続く、一連の業務を滞りなく回すことです。私たちは、自治体の補助金・協力金・給付金制度のWeb受付・審査システムを、制度の要綱に合わせて開発しています。

「Webフォームやスプレッドシートで足りるのでは」というご疑問に

事務局運営を受託されたばかりの担当者様から、よくいただくご質問があります。申請の受付だけなら、既存のフォームサービスで十分ではないか。あるいは、申請内容をスプレッドシートに集めて、そこで審査すればよいのではないか、というものです。

小規模で単純な制度であれば、それも一つの選択肢です。ただ、制度の内容によっては、次のような点で無理が生じやすくなります。

• 補助額や給付額の算出に複雑な計算が必要で、申請者が計算を誤りやすい
• 入力内容に矛盾があっても、送信されるまで誰も気づけない
• 審査担当者が複数いるとき、誰がどの申請をどこまで確認したかの管理が煩雑になる
• 複数期にわたる制度で、過去の申請情報を参照する必要がある
• 他の制度との重複申請を確認する必要がある

こうした課題は、申請件数が増えるほど、また受付開始までの時間が短いほど、事務局の負担として大きくなります。私たちは、まさにこの部分でお役に立てるよう、システムを設計・開発しています。

申請者に求めない、という設計

申請システムの設計で私たちが最も意識しているのは、申請者に余計な作業をさせないことです。複雑な計算が必要な制度でも、申請者が計算する必要はありません。入力された内容をもとに、システム側で必要な値を算出します。

入力の途中で矛盾する内容があれば、その場でお知らせします。たとえば、ある項目の入力内容と、別の項目の入力内容が整合しない場合に、提出前に気づいて修正できるようにするものです。こうした入力確認の仕組みによって、不備のある申請が提出される前に防がれ、事務局の確認作業と申請者への差し戻しは大きく減ります。

申請者の負担を下げることは、結果として事務局の負担を下げることに直結します。この順序で設計することが、制度の運営をなめらかにする近道だと考えています。

審査の現場に合わせた管理画面を

申請の受付が始まると、審査側の作業が本格化します。私たちは、審査管理画面についても、標準的な機能だけにとどまらず、案件ごとの運用に合わせて実装を行ってきました。

たとえば、一括でステータスを更新する機能です。複数の申請を選んで一度にステータスを変えられるようにすることで、審査の進行にあわせた更新作業の手間を減らします。複数期にわたる制度では、過去の申請情報を参照表示できるようにし、審査の際に前期までの情報を確認しやすくします。他のシステムとの重複申請のチェックや、重複入力の削減にも対応します。

標準機能ではなかなか実現しにくい、こうした業務効率化ツールを、制度ごとの運用を伺ったうえで一つずつ実装していく。それが、私たちが「カスタム対応」と呼んでいるものの中身です。

制度の種類によって、設計の重心は変わる

一口に補助金・給付金と言っても、制度の性格によって、システムに求められるものは異なります。

補助金では、多くの場合、申請をして交付が決まったあと、事業が実施され、その成果を報告して、最終的な金額が確定するという流れをたどります。そのため、受付の段階だけでなく、事業の完了後に提出される書類を受け付ける仕組みや、申請時の情報と報告内容を突き合わせる作業まで、見据えた設計が必要になります。申請時のデータが、あとの工程でも参照されることを前提に、情報の持たせ方を考えておかなければなりません。

一方、協力金や給付金のように、要件を満たす事業者に一定額を支給するタイプの制度では、迅速に受け付け、迅速に審査して、支給までの期間を短くすることが重視されます。ここでは、入力の確認と審査の効率化が、設計の中心になります。申請件数が短期間に集中することも多く、申請者が迷わず入力でき、事務局がたやすく確認できる画面が、制度全体の円滑な運営に直結します。

私たちが近畿地方の複数自治体で手がけてきたのは、協力金・給付金のWeb受付・審査システムです。制度の性格に応じて、受付と審査のどこに力を入れるべきかを見極める経験を積んできました。補助金の制度についても、要綱の内容を伺い、必要な範囲をご提案します。

入力する人が迷わない画面とは

申請者の多くは、事務手続きに慣れた担当者とは限りません。個人事業主の方や、店舗を営む方が、本業の合間に申請をすることも多いでしょう。そうした方が、画面を前にして迷わないための工夫は、最終的に、事務局の問い合わせ対応と差し戻しの数を減らします。

たとえば、入力項目の並べ方です。申請者が持っている書類の順番に沿って項目が並んでいれば、手元の書類を見ながら迷わず入力できます。逆に、項目が制度側の都合で並んでいると、同じ書類を何度も見直すことになり、入力ミスが増えます。必須項目と任意項目の区別、入力形式の例、ここまで入力すれば申請が完了することの見通し。これらが画面から読み取れることが、申請者にとっての安心につながります。

加えて、入力内容に誤りがあったとき、どこをどう直せばよいのかが明確に伝わることも重要です。単に「エラーです」と表示するだけでは、申請者は途方に暮れてしまいます。矛盾している箇所を示し、修正の方法を案内することで、申請者は自分で不備を解消でき、事務局に問い合わせる必要がなくなります。

私たちは、入力確認の機能を、こうした観点から設計しています。申請者が自分で気づいて直せる仕組みは、事務局にとっても、最も確実な不備の予防策です。

審査のあとに続く工程を見据えて

審査が終わったら、結果を通知し、必要に応じて支払いの手続きに進みます。申請システムは、この段階で必要になる情報を、あとから取り出しやすい形で保持しておくことが求められます。

たとえば、決定通知のための宛名や内容の一覧、支払いに必要な情報の取りまとめ、制度全体の件数や金額の集計などです。これらをシステムから出力できれば、事務局は、手作業での転記や集計から解放されます。どのような出力が必要になるかは、事務局の運用によって異なります。私たちは、運用の流れを伺い、必要な出力の形を、ご相談のうえで決めていきます。

また、複数の期にわたる制度では、期ごとに申請情報を管理しつつ、過去の情報を参照できることが求められます。同じ事業者が複数の期にまたがって申請する場合、前期の情報を引き継げれば、申請者の入力の手間も、事務局の確認の手間も減ります。他の制度やシステムとの重複申請の確認も、制度の公平性を保つうえで重要な役割を果たします。

構築の進め方

構築は、次の流れで進めます。

要綱確定・ヒアリング

制度の要綱案、想定される申請件数、受付開始までのスケジュールをお伺いし、構築範囲を確定します。要綱が完全に固まる前の段階でも、わかっている範囲でご相談いただけます。

受付システムの構築

要綱確定から短期間で、申請の受付システムを構築します。緊急性が高い案件であるほど、早い段階でご相談いただくことで、無理のない計画を立てやすくなります。

審査管理画面の構築

受付の開始と並行して、審査側の管理画面（ステータス管理、一括更新など）を構築します。

受付開始後の対応

Web申請の受付が始まった後も、運用の中で見えてきた課題への機能追加に対応します。要綱の改定にともなう変更も、ご相談ください。

料金の目安

料金は、制度の複雑さ、想定される申請件数、カスタマイズの範囲によって変わりますが、目安は次のとおりです。正式なお見積りは、要件をお伺いしたうえで個別にご提示します。

見積りだけのご依頼も歓迎します。要綱案や想定申請件数など、わかる範囲の情報をお聞かせいただければ、概算をお出しします。

概算のあとは、要件を詳しく伺ったうえで、構築の範囲と、受付開始までのスケジュールを確認し、正式なお見積りをご提示します。金額が大きく変わる要因（計算の複雑さ、審査管理画面に必要な機能、他システムとの連携の有無など）は、そのつど、根拠をご説明します。受付開始後の対応を含めるかどうかも、この段階で一緒に決めます。

個人情報を預かるシステムとして、考えていること

補助金・給付金の申請システムは、申請者のお名前、住所、事業の内容、場合によっては口座の情報まで、多くの個人情報・事業者情報を預かります。これらの情報が外部に漏れたり、改ざんされたりすれば、制度そのものへの信頼が損なわれます。私たちは、この点を、構築の最初から最後まで、最も重い前提として扱います。

個人情報を扱うシステムでは、一般に、次のような観点が欠かせません。通信が暗号化されていること。管理画面に入れる人が限られ、誰が何をしたかが後から確認できること。万一のときに備えて、データが適切に保存されていること。そして、受付期間が終わったあとのデータの取り扱いが、あらかじめ決められていること。どの水準の対応が必要かは、制度の性格や発注元の方針によって変わります。

そのため、私たちは、運用環境や求められるセキュリティの水準を、構築の前にお伺いすることにしています。LGWAN環境での運用が必要なのか、発注元が定めるセキュリティの基準があるのか。これらを後から知ることは、スケジュールの観点から最も避けたい事態です。要綱案の段階でも結構ですので、わかっている条件は、早めにお知らせください。

単年度の制度、調達方式、運用環境について

自治体の予算は単年度で組まれるのが基本であり、単年度の制度ではスケジュールがとくに厳しくなりがちです。そのため、要綱案の段階からご相談いただけると、構築計画をご提案しやすくなります。事務局運営を受託したばかりで要綱がまだ固まっていない段階でも、問題ありません。むしろその時点でお声がけいただくほうが、スケジュールに無理のない進め方を一緒に検討できます。

ご発注元の調達方式（随意契約を含みます）に応じた対応も行います。必要な書類や実績資料は、お問い合わせの際にご案内します。

運用環境については、LGWAN環境での運用の要否や、既存システムとの連携の必要性など、案件ごとに条件が異なります。運用環境に制約がある場合は、できるだけ早い段階でお知らせください。個人情報・事業者情報の保護を前提とした設計を行います。

近畿地方の複数自治体で積み重ねた経験

私たちは、近畿地方の複数自治体（都道府県・政令指定都市・市を含む）において、協力金・給付金のWeb受付・審査システムを、大手事業者の事務局運営体制の一員として25件以上構築してきました。守秘義務の都合上、自治体名・発注元企業名は公表していませんが、事務局運営の元請け企業様のチームの一員として開発を担当するという関わり方が、私たちの基本的なスタイルです。実績の詳細は、開発実績のページでご紹介しています。

「決まってから」ではなく、「決まる前」にお声がけください

補助金・給付金の事務局は、始まってからできることが限られる仕事です。要綱確定前の段階でも構いません。想定される申請件数、受付開始までのスケジュール、既存システムとの連携の有無など、わかっていることだけで結構ですので、お聞かせください。構築範囲、進め方、概算のお見積りをお返しします。

事務局運営を受託された企業・コンソーシアム様、そして自治体のご担当者様からのご相談をお待ちしています。お問い合わせは、お問い合わせフォームからお願いします。事務局向けのシステム開発の全体像は、補助金事務局向けのシステム開発パートナーのページもあわせてご覧ください。