自治体×kintoneで申請受付・補助事業の実績管理を内製する進め方

住民記録や税、福祉など基幹20業務の標準化・ガバメントクラウド移行が進む一方で、その「外側」に目を向けると、Excelと紙と回覧で回り続けている業務が庁内に数多く残っています。庁内の各種申請、補助事業や交付金の進捗・実績・証憑の管理、各課が独自に抱える台帳——いずれも制度改正や事業の新設のたびに様式が変わり、標準パッケージでは吸収しきれない領域です。こうした周辺・独自業務こそ、ノーコードツールであるkintone（サイボウズ）で職員自身が組み立て、内製で改善していける対象になります。

本記事は、補助事業の実績報告や証憑の「制度・法令上の要件」を解説するものではありません。そこは別記事に譲り、ここではあくまで実務にどう適用し、内製をどの順番で進めるか——業務の選び方、アプリ設計の勘所、運用への定着、そして実績データのBI連携まで——を、自治体の情報政策・企画・各事業課の担当者に向けて整理します。なお、標準化対象の基幹20業務そのものの取り扱いは本記事の射程外で、後述のガイドへ送ります。

標準化の「外側」にこそ内製の余地がある

自治体情報システムの標準化は、児童手当・住民基本台帳・固定資産税・国民健康保険・介護保険など20の基幹業務を対象に、全国の地方公共団体が標準準拠システムへ移行する取り組みです（総務省・デジタル庁）。この20業務は仕様が国の標準に合わせて固定されるため、個々の自治体が手を入れる範囲は意図的に狭められています。

裏を返せば、20業務に含まれない業務——庁内の物品・出張・施設利用の申請、各種補助金や交付金の事業管理、イベントや講座の受付、独自の補助制度の台帳など——は、引き続き各自治体が自ら設計・運用する領域として残ります。ここは制度改正や新規事業のたびに様式や項目が変わるため、外部ベンダーに毎回発注していてはコストもリードタイムもかさみます。職員が自分たちで直せる仕組みを持つ意味が、もっとも大きく出る場所です。

標準化対象20業務やガバメントクラウドの全体像、自治体DXの進め方そのものについては、自治体DXの全体像をまとめたガイドで整理しています。本記事はその「周辺・独自業務をノーコードで内製する」部分に絞って掘り下げます。

なぜ補助事業・申請業務とkintoneは相性が良いのか

kintoneは、表計算ソフトの延長線上にある感覚でデータベース型の業務アプリをノーコードで作れるサービスです（サイボウズ）。補助事業や庁内申請の管理には、次のような特性が噛み合います。

第一に、申請から審査、決定、実績確認、精算までの流れをプロセス管理（ステータス）で表現できる点です。レコードごとに「受付→一次審査→課長決裁→交付決定→実績報告待ち→確定」といった状態を持たせ、いま誰のところで何件止まっているのかを一覧で把握できます。紙の回覧では見えなかった滞留が可視化されることが、進捗管理では効きます。

第二に、添付ファイルと台帳行の一体管理です。補助事業では、各支出に見積書・契約書・納品書・請求書・領収書といった証憑が対応します。kintoneなら台帳の1レコードに関連する証憑ファイルを紐づけ、後から「この補助金のこの費目の証憑」へ即座に辿れる状態を平時から作れます。実績報告や検査対応の際に書類を探し回る負荷は、ここで大きく変わります。実績報告そのものの組み立て方や保存要件といった制度面は、補助金の実績報告・証憑管理を扱った記事を参照してください。

第三に、権限とガバナンスです。kintoneはアプリ単位・フィールド単位でアクセス権を設定でき、課をまたいだ情報連携と、見せてはいけない項目の制御を両立しやすい設計になっています。庁内の複数課が関わる補助事業でも、必要な人に必要な範囲だけを開く運用が組めます。

内製を進める四つのステップ

1. 業務を選ぶ——小さく、痛みが明確なものから

最初の対象は「全庁で使う大規模システム」ではなく、一つの課で完結し、現状の痛みがはっきりしている業務を選びます。たとえば、Excel台帳をメール添付で回している補助金、申請書を紙で受け取り手集計している講座受付など、件数と関係者が限られ、効果を実感しやすいものが適しています。

選定の目安は、(1)様式や項目が今後も変わりやすい、(2)複数人が同じ台帳を更新して競合が起きている、(3)進捗の問い合わせ対応に手間がかかっている、のいずれかに当てはまるかどうか。逆に、制度上の要件が固く外部接続が前提のものは初手に向きません。

2. アプリを設計する——項目とプロセスを先に決める

いきなり画面を作り込むのではなく、まず「何を1レコードとするか」を決めます。補助事業なら1申請=1レコードを基本に、申請者情報、事業名、申請額、決定額、実績額、ステータス、担当者、証憑添付といった項目を洗い出します。次に、前述のプロセス管理で承認の流れを定義し、各ステータスで誰が何を入力・確認するかを紙の決裁ルートと突き合わせます。

このとき、入力ミスを減らすために選択肢はドロップダウン化し、必須項目を絞り、計算が必要な金額は自動計算に寄せます。完璧を狙わず、運用しながら項目を足し引きできるのがノーコードの利点なので、初版は最小構成で立ち上げるのが定石です。

3. 運用に定着させる——「作って終わり」を避ける

内製でつまずく典型は、作った職員の異動とともにアプリが塩漬けになることです。これを避けるには、(1)アプリの目的・項目の意味・更新手順を簡単な手順書として残す、(2)入力ルールを課内で合意する、(3)管理者を複数名にしておく、の三点を最初から仕込みます。

サイボウズは、成功したアプリや運用ノウハウを自治体間で共有する「シェアDX」の考え方を打ち出しており、行政職員向けの導入事例・活用情報サイトを公開しています。ゼロから設計せず、近い業務の作り方を参照することで、定着までの時間を縮められます。

4. 実績データをBIにつなぐ——管理から可視化へ

申請・実績データがkintoneに蓄積されてくると、次の関心は「事業横断での見える化」に移ります。kintoneはAPIトークンをアプリ単位・権限単位で発行でき、最小限の権限で外部ツールへデータを渡せる設計です。標準のグラフ機能で課内の集計を行いつつ、複数事業の予算・執行・実績を束ねて見たい場合は、BIツールへ連携して予実ダッシュボードに集約する構成が取れます。

補助金・交付金の使途と予実を全庁横断で可視化する考え方は、ふるさと納税の寄付金の使途・予実管理をまとめた記事で詳しく扱っています。kintoneで現場の入力を内製しつつ、その先のダッシュボードで経営・財政の視点から束ねる——この役割分担が、申請管理の内製を単なる業務効率化で終わらせないための要になります。

内製とベンダー活用の線引き

すべてを内製する必要はありません。現場が頻繁に直す部分——項目の追加、様式変更、簡単な集計——は職員が担い、初期の設計方針づくり、複数システムをまたぐデータ連携、APIを使った自動化やBI基盤の構築といった専門性の高い部分は外部の知見を借りる、という線引きが現実的です。最初に設計の型を一緒に作り、その後の運用は庁内で回せるようにしておくと、ベンダーロックインを避けつつ改善の速度を保てます。

オンライン申請の受付そのものをデジタル化する観点は、自治体のオンライン申請・受付のDXを扱った記事も参考になります。受付の入口をデジタル化し、その裏側の進捗・実績・証憑をkintoneで内製管理し、さらに予実管理ダッシュボードで束ねる——入口から可視化までを一本の流れとして設計することが、周辺業務の内製を成果につなげる近道です。

まず一つ、選んで作る

標準化が基幹20業務の足場を固める間に、その周辺で職員の時間を奪い続けている業務は確実に存在します。そのうちの一つを選び、最小構成のkintoneアプリとして立ち上げ、プロセスと証憑を一体で管理し、データが溜まったらBIへつなぐ。この小さな一巡を経験することが、内製文化を庁内に根づかせる出発点になります。完璧な全体設計を待つより、痛みの明確な一業務から動かしてみることをおすすめします。