国民健康保険システム開発の完全ガイド

国民健康保険システムは、資格・賦課・収納・給付・滞納の業務と外部連携を一体で管理する自治体の基幹システムです。標準仕様への適合と移行設計を含めて導入を進めることが、自治体業務を止めずに続けるための前提になります。

各テーマの詳細は、下の関連記事で確認できます。

▼関連記事一覧
・国民健康保険システム開発の進め方
・国民健康保険システム開発でおすすめの開発会社6選と選び方
・国民健康保険システム開発の見積相場・費用
・国民健康保険システム開発の発注・外注・委託方法

国民健康保険システムの全体像

国民健康保険システムを中心に、資格管理、賦課管理、収納・滞納管理、給付管理を結んだ図。
資格の更新から納付や給付までを一つの基盤で支えます。

住民の異動をきっかけに資格を更新し、所得や世帯の情報をもとに賦課します。納付状況を管理して給付を支えるのも、この業務基盤の役割です。窓口、バックオフィス、通知・証明書発行、外部機関への報告は、同じ基盤の上でつながります。

資格・賦課・収納・給付・滞納の一貫管理

制度条件と住民対応を支える主な機能は、次の4つの領域に分かれます。

  • 資格管理:加入・脱退・転入・転出・世帯・住所変更の処理と履歴、資格確認書の扱い。
  • 賦課管理:所得・資産・世帯人数から保険料または保険税を算定し、軽減・減免・更正、通知書発行まで行います。
  • 収納・滞納管理:納付書・口座振替での納付から、督促・還付・分納・収納消込・滞納整理まで。
  • 給付管理:療養費・高額療養費・出産育児一時金・葬祭費の申請・審査・支給。

料率や減免の条件は自治体ごとに異なるため、制度上の条件を正確に反映させる必要があります。

資格異動から通知、納付、給付まで履歴がつながっていれば、職員は根拠を確かめながら問い合わせに答えられます。

外部連携と標準仕様への適合

外部連携と標準仕様への適合は、要件の段階で盛り込んでおく必要があります。

  • 連携先と仕様:住民記録・個人住民税・固定資産・収納・口座、マイナンバー関連機能、国保連合会、オンライン資格確認の仕様の洗い出し。
  • 連携運用:連携項目と更新時期、エラー時の再送方法、修正の責任を負う部署を決めておく。
  • 標準仕様と保守:納品時の版(第1.6版など)に適合し、改版や制度変更に追随できる体制があるか。

連携条件が決まっていないと、資格と賦課の情報がずれたり、同じ内容を二度入力したりすることが起こりやすくなります。

標準仕様書は2026年1月に第1.6版が公開され、資格・賦課・給付・収納・滞納などの領域別資料があります(出典: 厚生労働省「標準仕様書(国民健康保険)」、2026年)。

国民健康保険システム開発の進め方

開発は現行業務とデータの整理から始め、製品の選定や設定はその後に進めます。標準化移行では、自治体独自の運用を残すか、標準業務に合わせるかを早期に判断します。また、工程ごとに成果物と判定基準を決めておくと、納期直前の仕様変更を抑えられます。

現行調査とFIT&GAP分析による要件整理

標準仕様との差を正しくつかむには、現場の運用、既存データ、システム資産を調べることが欠かせません。

  • 業務フロー:資格異動と年度切替、賦課更正・減免・還付、高額療養費、滞納整理の流れ。
  • 処理条件:起点データ・例外・承認者・期限・再実行の方法を、担当者と洗い出します。
  • 現行資産:画面・帳票、住民記録・税務との連携、件数・コード・文字、過去年度データの保存期間。
  • 標準機能:標準仕様にある機能は、原則として標準の仕組みに寄せる方針。
  • 独自運用:残す理由、住民サービスへの影響、外付けの方法、将来の保守費の記録。

FIT&GAP表が曖昧なままだと、提案と現場の期待がずれ、その分だけ追加開発が膨らみます。

データ移行と外部インターフェースの先行設計

移行と外部連携では、対象データ、変換と照合、連携の運用を、早い段階で具体的に決めておく必要があります。

  • 移行対象:住民・世帯・資格・賦課・収納・給付・滞納のデータと、過去年度のオンライン参照の範囲。
  • 変換と照合:履歴の欠損・重複、旧コードの変換、抽出から取込後の確認までの担当を仕様書に明記。
  • 例外データ:世帯主変更・転出後の再加入・減免中の更正・分納中の還付を、移行リハーサルで確かめる。
  • 外部連携:連携先・方向・ファイルかAPIの形式・時刻、件数照合・エラー通知・再送・手動補正を一覧にする。

資格情報と所得情報は、更新時期がずれると保険料の計算に影響します。

連携が止まったときにも窓口業務を続けられるよう、暫定手順を用意しておきます。

業務テストと並行稼働による本稼働リスクの低減

本稼働の前には、業務テスト、移行照合、職員の準備を通して切替の可否を判断します。画面が開くかの確認だけでは、この判断はできません。

  • 業務テスト:加入・脱退・転入・転出・世帯変更・年度切替、所得・賦課更正・軽減・減免、収納消込・還付・高額療養費・給付・滞納整理。
  • 一連の確認:入力から通知書・帳票・外部連携までの流れ、制度改正時の再計算、誤入力を訂正したあとの履歴と監査ログ。
  • 移行照合:代表データで複数回リハーサルし、件数・金額・世帯数・資格状態・未収金額を旧システムと突き合わせる。
  • 稼働準備:操作研修・手順書・問い合わせ窓口・障害時の連絡網・ロールバック条件を整え、判定会議で合否を決めます。

標準化移行は2025年度末が原則ですが、特定移行支援システムは2026年度以降の移行と公表されています(出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年6月更新)。

期限だけでなく、業務を続けられる品質も判定基準に含めます。

▶ 詳細はこちら:国民健康保険システム開発の進め方

ポイント

現行業務とデータの整理を済ませてから、製品の選定と設定に進みます。工程ごとの成果物と判定基準を先に決めておくと、納期直前の仕様変更を抑えやすくなります。

パッケージ・クラウド・スクラッチの選び分け

方式は、自治体の規模や既存システム、独自運用、移行期限によって変わります。運用人員やセキュリティ方針も、判断の材料になります。

制度改正と標準仕様の改版が続くため、標準機能を使い独自要件を絞る構成は管理しやすいです。

方式を比べるときは、初期費用だけでなく、5年または10年の総保有コストで比較します。

制度対応と導入期間を重視する場合の標準パッケージ

標準パッケージは資格・賦課・収納・給付・滞納などを備えており、設定の変更を中心に導入を進めます。ゼロから作る範囲を抑えられるうえ、複数の自治体の機能をもとに、制度改正への対応手順や運用のノウハウを蓄積できます。

独自帳票、例外的な減免、特殊な承認フローは、すべて再現できるとは限りません。そのため、デモで業務シナリオを確かめ、標準機能、設定、追加開発、運用のどれで補うかを分けておきます。加えて、標準仕様への適合を示す証跡や、改版時の影響調査、テスト、リリース方法も、事前に確かめておく必要があります。

クラウドの共同利用と運用継続性の評価

クラウド方式は、費用や責任の分け方も含めて評価する必要があります。

  • 運用と共同利用:保守、バックアップ、監視、災害対策を自庁で抱える範囲を減らせます。ガバメントクラウドは全国的な運用環境の選択肢です。
  • 期待効果:セキュリティ・運用監視の標準化や構築の迅速化が期待されています(出典: デジタル庁「ガバメントクラウド」、2026年)。
  • 費用と契約:利用料・ネットワーク・バックアップ容量・監視・運用管理補助、端末・プリンター、転送、障害時の責任の分け方を見積もる。
  • 利用量と終了時:月額費用の増減要因、利用量が増えたときの上限、契約終了時のデータ返却の方法。

クラウドに移行すれば自動的に安くなるとは限らないため、費用の項目をすべて含めて比べます。

スクラッチ開発の独自要件と検証

スクラッチ開発は独自要件に対応できます。ただし、開発範囲と将来の保守体制を確かめたうえで選ぶ必要があります。

  • 開発範囲:全機能を実装すると、資格・賦課・収納・給付・滞納の各領域に加えて、帳票・連携・監査ログ・権限・制度改正・テストデータまで広がる。
  • 方式の検討:標準仕様から外れる理由が明確でなければ、パッケージと外付け機能の組み合わせを先に検討します。
  • 契約と保守:要件定義書・変更管理、ソースと設計書の引き渡し、担当交代後の保守・改修単価・テスト環境の取り決め。

特定の担当者や技術に依存すると、制度改正のたびに見積と納期が不安定になりがちです。将来の運用体制も、判断の材料になります。

ポイント

制度改正と改版が続くため、標準機能を中心に独自要件を絞る構成が管理しやすくなります。方式は、初期費用に加えて5年または10年の総保有コストで比べます。

国民健康保険システムの費用相場とコストの内訳

全国共通の定価はありません。金額は、対象業務や人口・世帯数、データ量、連携先によって変わります。独自帳票や移行年度、運用期間も金額に影響します。

公開されている調達額は、狭い準備業務の100万円前後から、標準化移行全体の数億円、大規模自治体の再構築の数十億円まで広がります。そのため、金額に何が含まれるかを確認することが欠かせません。

公開調達額の対象範囲ごとの読み取り

準備・移行・再構築では対象範囲が異なるため、金額を同じ条件で比べないようにします。

  • 伊達市:移行準備業務の委託
  • 大津市:標準化移行対応業務の委託料上限
  • 神戸市:再構築業務の契約

福島県伊達市の移行準備業務委託は、2025年10月31日公表で税抜96万円でした(出典: 福島県伊達市「令和7年10月31日入札結果」、2025年)。この委託額には、本体システムの構築や本稼働後の運用費は含まれません。

大津市の標準化移行対応業務は、2026年度から2027年度にまたがる契約です。委託料の上限は税込4億3,994万1,000円です(出典: 大津市「国民健康保険システム標準化移行対応業務公募型プロポーザル実施要領」、2026年)。

神戸市の再構築業務は、契約期間が2028年1月3日まででした。契約額は税込34億8,700万円です(出典: 神戸市「神戸市国民健康保険システム再構築業務」、2025年)。自治体の規模や既存システム、移行量、連携範囲が異なるため、金額を単純な単価の比較には使わないようにします。

初期費用・移行費・運用費の内訳

見積では、初期費用、移行費、運用費を分けて、それぞれの作業範囲を確かめます。

  • 初期費用:現行調査・要件定義・設定と開発・画面と帳票・連携・クラウド・権限・テスト・研修・稼働立会い。
  • 移行費:データの抽出・クレンジング・コード変換・取込・照合・再抽出・移行リハーサル。
  • 運用費:アプリ保守・制度改正・クラウド・監視・バックアップ・問い合わせ・障害対応・帳票・教育・定期テスト。

「一式」とだけ書かれた見積は、作業量と成果物に分けてもらいます。5年TCOには、法改正や標準仕様の改版、追加の連携、利用量の増加、再移行を想定します。前提条件には税区分と契約期間を明記し、人口・世帯数・対象業務・連携先・想定データ件数も同じように書いておきます。

見積比較の前提条件と責任範囲

金額だけでなく、提案の前提条件と責任範囲を同じ基準で比べます。

  • 含まれる作業:移行確認・連携テスト・並行稼働・職員研修・制度改正時の追加対応・稼働後の問い合わせ。
  • 回答条件:複数の候補に同じRFPを渡し、機能・非機能・移行・運用・体制・日程・費用を、共通の様式で答えてもらいます。
  • 評価項目:標準仕様への適合・移行実績・連携設計・制度改正、障害時の責任の分け方・終了時のデータ返却。

除外項目が多い提案は、本契約のあとに変更要求として費用が発生する可能性があります。

▶ 詳細はこちら:国民健康保険システム開発の見積相場・費用

ポイント

費用は初期費用・移行費・運用費に分け、金額に何が含まれるかを確かめてから比べます。税区分や契約期間などの前提も、見積の段階で同じ形に揃えます。

国民健康保険システムの開発会社・サービスの選び方

開発会社の提案を比べる評価項目として、標準仕様への適合、実業務のシナリオ、移行・連携・保守、価格・機能・体制を並べた図。
提案前に評価軸をそろえると、候補ごとの回答を並べて判断できます。

知名度や営業資料だけで決めずに、国保業務と自治体システムの両方を理解している会社を比べます。

実績は、自治体の数だけでなく、担当した業務領域・対応した標準仕様の版・移行・本稼働後の保守範囲で確かめます。

標準仕様への適合の資料とデモによる確認

標準仕様の対象領域・適合の根拠・対応している版・経過措置・改版時のリリース計画を、候補ごとに確かめます。あわせて、要件番号と製品機能の対応表、未対応機能の代替、設定と追加開発の範囲を資料として出してもらいます。

デモでは、加入・脱退・所得変更の流れを中心に、実業務のシナリオを使います。ほかに、次の場面も同じように確かめます。

  • 減免:条件を入れたときの、賦課額の結果。
  • 年度切替:年度をまたいだ保険料と、資格情報の更新。
  • 還付:戻すべき金額と、対象者の処理を確かめる。
  • 給付申請:申請の受付から支給までの流れ。

さらに、エラー表示・履歴の追跡・帳票の再発行・権限の制御・処理の再実行も、デモで確認します。窓口・賦課・収納・給付の担当者もデモに加わると、判断しやすくなります。

移行・連携・保守を一体で担える体制

候補には、移行から保守までの役割と対応の方法、契約条件を示してもらいます。

  • 担当体制:移行責任者・業務有識者・インターフェース担当・テスト責任者・運用責任者それぞれの役割と人数。
  • 対応の責任分担:再抽出や障害対応で、誰がいつまでに何を行うかを決めておく。
  • 保守とサービス条件:改版情報の収集から職員への周知までの周期・SLA・受付時間・重大障害の初動・復旧目標・バックアップ世代・ログ保存・問い合わせ先。
  • 契約終了:将来の契約終了時に、データを返せる状態になっているか。

再抽出や障害対応の分担が曖昧な提案は避け、合意した内容を契約書に反映させます。

価格・機能・体制の点数化による比較

評価項目と配点は、自治体の優先事項を踏まえたうえで、提案を比べる前に決めておきます。

  • 評価項目:標準仕様・制度対応・業務適合・連携・移行・非機能・セキュリティ・体制・教育・費用・将来性。
  • 配点:機能適合や移行を重視する自治体も、共同利用や運用費を重視する自治体もあります。提案を受けたあとに基準を変えないことが公平です。
  • 確認方法:提案書と質問回答、実データに近いデモ、移行計画のレビュー、導入自治体へのヒアリングを組み合わせる。
  • 決定と契約:抽象的な回答を、成果物・受入条件・追加費用に落とし込む。情報政策・保険年金・収納・財政・窓口の視点をそろえる。

▶ 詳細はこちら:国民健康保険システム開発でおすすめの開発会社6選と選び方

ポイント

知名度や営業資料だけで決めず、実績・標準仕様の適合・移行と保守の体制を同じ基準で確かめます。デモは実業務のシナリオで行い、候補ごとの回答を点数にして比べます。

国民健康保険システムの発注・外注・委託の方法

発注では、まずRFIで市場の対応範囲と概算を把握し、その結果をRFPに反映させます。詳細な仕様を、最初から一社に合わせて固めないようにします。

RFIによる情報収集とRFPによる条件提示

情報を集める段階と条件を示す段階は、RFIとRFPで分けて考えます。RFIで市場の情報を集め、その結果をRFPに反映させてから、候補に共通の条件を示します。

  1. RFI:市場の選択肢とリスクの把握。
  2. RFP:候補に共通の条件を示し、提案を受け取る。
  3. 価格条件:初期・移行・連携・研修・稼働支援・保守・クラウド・制度改正に分けた見積と、5年分のTCO。

RFIには、現行システムと対象人口・世帯数、業務範囲に加えて、移行時期や連携先も記載します。独自運用とクラウド方針も、あわせて書き添えます。

候補には、対応方式・概算費用・期間・前提条件・制約を回答してもらいます。

RFIの段階で契約条件を確定することはありません。

RFPでは、機能・標準仕様・データを、それぞれ分けて記載します。ほかに、次の内容も書き込みます。

  • 連携:連携先と仕様、連携項目と更新時期、エラー時の再送方法。
  • 非機能:求める水準を、要件として書き込む。
  • 移行:成果物とリハーサルの回数、受入の条件。
  • 教育:職員の研修の範囲と内容。
  • 運用保守と契約終了時の返却:保守の範囲と、契約終了時のデータ返却の方法。

対象範囲をはっきりさせておくと、提案の比較と契約後の変更管理が進めやすくなります。

RFPには、標準仕様の版と適合の確認、移行の成果物とリハーサルの回数、受入テストを記載します。加えて、障害時の責任の分け方と、ログ・バックアップ・SLAの扱いを明記します。さらに、法改正対応、ソースやデータの権利、契約終了時の返却も、取り決めの対象にします。

契約と変更管理による追加費用の発生条件

契約後に追加費用が膨らむのを防ぐには、条件を先に決めておく必要があります。

  1. 要件定義・設計・開発・移行・テスト・教育・本稼働支援・保守、それぞれの成果物と検収条件。
  2. 標準仕様の改版、制度や法令の変更、自治体都合の追加、外部システムの変更について、保守費と追加契約の境界を決めておく。
  3. 変更要求は、業務・セキュリティへの影響・費用・納期・テスト範囲・承認者を記録してから着手します。口頭での依頼は、納期と責任をあいまいにします。
  4. 月次会議では、未決事項・リスク・次回の判定日を確認し、重大な変更は自治体の意思決定者が承認します。

受入テストと研修の発注範囲

発注の範囲には、受入テストと、役割に応じた研修、引き継ぎ資料を含めておきます。

  • 受入テスト:資格異動・賦課計算・納付・還付・給付・滞納・帳票・外部連携・権限・監査ログを、業務担当者が確かめる。
  • 判定基準:不具合の重大度、再テストの条件、移行件数や金額が合わない場合の再調査の基準。
  • 研修:役割別の操作演習・年度切替・例外処理・障害時の対応・問い合わせの記録。
  • 引き継ぎ資料:窓口の手順書・管理者の権限変更手順・運用担当のバックアップと復旧の手順を整え、異動後も引き継げる形で納品する。

▶ 詳細はこちら:国民健康保険システム開発の発注・外注・委託方法

ポイント

発注では、RFIで把握した市場の対応範囲をRFPに反映させます。RFPには連携・移行・教育・運用保守まで書き込み、対象範囲をはっきりさせておきます。

セキュリティと本稼働後の運用

個人情報を中央に置き、権限設定、承認と記録、監視と定期確認、委託先のアクセス管理で囲んだ図。
アクセスの制御と記録を重ね、不正利用を抑えます。

国民健康保険システムは、個人情報や所得、世帯、医療給付、収納の状況を扱います。そのため、セキュリティも機能要件と同じ粒度で設計する必要があります。

アクセス権限と操作ログ、通信の暗号化は、要件として盛り込みます。ほかに、次の項目も要件に入れます。

  • 異動や退職時の停止:離任した職員の利用を、速やかに止める。
  • 帳票の出力制御:印刷や書き出しの対象と、操作できる職員を絞る。
  • バックアップ:障害に備えた保存と復旧の取り決め。
  • 脆弱性への対応:製品の弱点を把握し、修正の手順を決めておく。
  • 委託先のアクセス管理:委託先の作業者にも、自庁と同じ基準で権限を与える。

最小権限と監査ログによる不正利用の抑止

不正利用を抑えるには、権限、承認、監視の3つの面から考えます。

  • 権限設定:担当課・業務・役割・操作内容・参照範囲で区切ります。資格を参照する職員が賦課額を変えられないよう、参照と更新も切り分けます。
  • 承認と記録:更正や還付で上長の承認が必要な場合は、申請者と承認者を分け、誰がいつ、どの住民・世帯のどの項目を、どの値から変えたかを記録する。
  • 監視と定期確認:大量出力・時間外アクセス・連続失敗・権限変更を検知し、権限の一覧での見直しと、異動・退職時の停止を手順にします。

障害・災害時の窓口と給付の継続

障害の際は、資格確認、保険料の問い合わせ、給付申請、納付相談を、完全には止められない場合があります。このため、継続の手順と復旧の体制を事前に定めておきます。

  • 停止中の業務:紙や一時ファイルでの受付、復旧後の再入力、重複登録の防止、住民への案内。
  • 復旧目標:重要業務ごとの復旧目標時間と、許容するデータ損失。
  • バックアップ:取得の頻度・世代数・保管場所・暗号化・復旧テスト・復旧権限。
  • 復旧の分担と訓練:クラウドでも、アプリ・データ・ネットワーク・端末・帳票印刷の担当を分け、年次訓練と、制度や構成の変更後の再検証を行います。

国民健康保険システム開発で失敗しやすいポイント

失敗の原因は、技術そのものよりも、標準化と現場業務の調整不足、移行データの確認不足、担当範囲の曖昧さにあります。

よくある問題は、事前にチェックリストへ落とし込んでおき、発注前、設計時、テスト時の各段階で確かめます。

独自要件の積み上げと標準化の利点

現行の画面や帳票をそのまま再現すると、標準機能から外れた改修が増えます。

独自要件は、法令・条例、住民サービス、内部統制のどれに必要かで分けて考えます。

まずは、標準機能に合わせて業務を変えることで解決できないかを検討します。残す機能は、改版時の影響や保守費、将来の担当者が理解できるかどうかで評価します。

移行の後回しとデータ品質の問題

本稼働の直前だけで移行を済ませようとせず、早い段階でサンプルを抽出します。氏名・住所の表記の揺れ・旧コード・重複世帯・所得の欠損・金額の丸め・過年度の扱いを確かめます。

クレンジングの基準と承認者を決めておきます。移行できないデータを別の媒体に残す場合は、参照の方法と保存期間も定めます。

期限への偏りと切替判定の数値化

標準化の期限や年度切替に合わせることは大切ですが、未解決の不整合を抱えたまま本稼働すると、業務に影響が出ます。

窓口、賦課、収納、給付への影響を抑えるため、切替の判定では、次の項目を数値で決めておきます。

  • 移行照合:移行件数と金額の一致を、数値で判定する。
  • 業務・障害:重要業務テストの完了、重大障害の未解決件数、障害時手順の確認を判定項目とする。
  • 研修:職員の研修受講率を、数値で判定する。
  • 基準未達時:延期・段階稼働・暫定運用・対象範囲の縮小を、事前に決めておく。
  • 延期が難しい場合:未解決リスクの所有者・期限・暫定策・住民への説明・復旧計画を文書にまとめる。

責任者が判断できるよう、課題は一覧にしておきます。

国民健康保険システムに関するよくある質問

標準仕様、費用、移行、制度改正への対応について、発注前によく寄せられる質問に答えます。

国民健康保険システムの開発費用はいくらですか?

対象範囲によって大きく変わります。準備業務だけなら100万円前後から、標準化移行・連携・テスト・研修を含むと数千万円から数億円です。

大規模自治体の再構築では、数十億円の公開事例があります。

人口だけでなく、世帯数・データ量・連携先によっても費用は変わります。ほかに、次の要素も関わります。

  • 帳票:独自の帳票を作るほど、設計と検証の範囲が広がる。
  • 独自運用:自治体独自の運用を残す範囲で、開発と保守の量が変わる。
  • 移行範囲:移行するデータの範囲と年度によって、作業量が変わる。
  • 運用年数:運用する期間が長いほど、保守と運用の費用が積み上がる。

初期費用と5年TCOは、分けて見積もります。

標準仕様に合わせれば自治体独自の業務はすべて廃止されますか?

法令・条例、住民サービス、内部統制で必要な独自の業務は残ります。残す業務は、標準機能との差分を洗い出して決めます。

設定、外付け機能、運用手順のどこで対応するかを決めます。理由が慣行だけであれば、標準業務に寄せることで、改版対応と保守費を抑えやすくなります。

データ移行で最初に確認すべきことは何ですか?

移行対象の業務と年度、項目を確かめます。ほかに、次の点も確かめます。

  • 履歴:資格や賦課の過去の記録が、どこまで残っているか。
  • 件数:住民と世帯の数が、旧システムと一致するか。
  • コード体系:旧コードと新コードの対応を、表で示せるか。
  • 文字:氏名や住所の表記の揺れを、どう扱うか。
  • 欠損や重複の状態:抜けや二重登録の有無を、移行前に洗い出す。

抽出・変換・取込・照合・再抽出の担当者と判定基準を決め、代表データと例外データで早い段階からリハーサルします。

本稼働の直前まで問題を残さないことが必要です。

ガバメントクラウドを使えば運用費は必ず下がりますか?

共同利用や運用監視の標準化により、効率化が期待できます。ただし、クラウド利用料・ネットワーク・バックアップ・監視・運用管理・データ転送などの費用も発生するため、必ず下がるとは限りません。

現行環境と移行後の5年TCOを比べ、利用量を抑える構成や、費用を測る仕組みも設計します。

開発会社やサービスを比較するときの決め手は何ですか?

標準仕様への適合・国保業務の理解・移行と連携の実績・制度改正への保守・セキュリティ・費用・プロジェクト管理を、同じ基準で比べます。

実データに近いデモや移行リハーサルの計画、障害時の責任の分け方、終了時のデータ返却も確かめます。

価格以外のリスクも、点数にして評価します。

まとめ

国民健康保険システムは、資格・賦課・収納・給付・滞納に加えて、住民記録・税務・外部機関・通知・証明書・監査をつなぐ自治体の基幹業務です。

標準仕様第1.6版など最新の基準を確認したうえで、現行調査・FIT&GAP・移行・連携・業務テスト・研修・並行稼働を一つの計画にまとめます。

最初に整理するチェック項目

対象業務と住民サービス、標準仕様との差分、外部連携を整理します。ほかに、次の項目も整理します。

  • 移行データ:移行する対象と、データの品質を確かめる範囲。
  • 非機能要件:要件として書き込む条件を、機能要件とは別に整理する。
  • 費用の前提:金額に含む作業と、含まない作業の境目。
  • 5年TCO:法改正や利用量の増加を含めた、5年間の総額。
  • 制度改正時の保守の範囲:改版対応を、保守費と追加契約のどちらに入れるかの境界。

次に、RFIで候補の対応範囲を確かめ、RFPで共通の条件を示します。機能・移行・体制・セキュリティ・費用は、点数にして比べます。

切替の判定、障害時の業務継続、契約終了時のデータ返却まで合意してから、契約に進みます。

関連記事による個別テーマの深掘り

開発工程、会社の比較、費用の見積、発注・外注は、自治体の条件によって検討点が変わります。各論点の詳細は、関連記事で確認できます。

▼関連記事一覧
・国民健康保険システム開発の進め方
・国民健康保険システム開発でおすすめの開発会社6選と選び方
・国民健康保険システム開発の見積相場・費用
・国民健康保険システム開発の発注・外注・委託方法

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。