公共くじ販売システムは、販売、抽せん、払戻しを結ぶ基幹システムです。開発では、制度ごとの責任分界を最初に決め、販売・決済・抽せんの機能を整理したうえで、テストと運用の順番を押さえることが、正確な取引と継続運用につながります。
▼関連記事一覧
・公共くじ販売システム開発の進め方
・公共くじ販売システム開発でおすすめの開発会社6選と選び方
・公共くじ販売システム開発の見積相場・費用
・公共くじ販売システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
公共くじ販売システムの概要
公共くじ販売システムは、発売計画や販売制御から、購入記録と決済、抽せんと当せん判定、払戻しを経て、収益配分と会計報告までを結ぶ基幹システムです。
宝くじとスポーツくじの制度の違い
宝くじは当せん金付証票法に基づき、全国都道府県と20の指定都市が発売元となります。発売元は総務大臣の許可を受け、発売などの事務を銀行などに委託します。
宝くじ公式サイトによると、受託銀行などは券を準備して売りさばき、抽せんを行い、当せん番号を発表して、当せん金を支払います（出典: 宝くじ公式サイト「宝くじの仕組み」、2026年確認）。
制度による違いは、発売元や実施主体だけでなく、商品、結果承認、会計処理にも及びます。
- 宝くじ：当せん金付証票法の下で、自治体が発売元となる
- スポーツくじ：スポーツ振興投票等の実施等に関する法律に基づく、宝くじとは別の制度
- 共通基盤：責任範囲と、制度ごとの商品・承認・会計処理を分けて設計する
制度によって、実施主体や投票対象が違います。結果の確定や払戻し、収益の使い道も異なります。さらに、法令や規約、監督・監査、委託契約も、制度ごとに同じとは限りません。
販売主体と運営主体の責任分界
担当範囲を決めるときは、関係者ごとの役割と異常時の扱いを、業務フローに落とし込みます。
- 関係者：発注者、受託金融機関、販売店、端末・決済・クラウド事業者
- 承認・再処理：発売停止、抽せん結果の承認、払戻し失敗の再処理担当
- 異常時の照合：画面、取引、決済、精算データが異なる場合の対応
宝くじでは、自治体と受託銀行の役割に加えて、売り場と運用者の責任範囲も要件定義書に明記します。
発注者が自治体や公的機関であっても、販売業務を受託金融機関が担う構成があります。このため、関係者を発注者だけと考えると、障害時の連絡やデータ照合が破綻します。
購入完了の表示後に決済結果が遅れる場合、端末とWebで同じ商品を買う場合、販売停止の直前に注文が集中する場合は、発注者と開発会社で事前に確かめておきます。食い違いが起きたときの扱いは先に決めておき、担当者の判断だけに任せないことが大切です。
公共くじ販売システムの種類と主要機能
方式を選ぶ前に、取引の正本をどこに置くか、データをいつ確定させるかを決めておきます。基幹データを共通化したうえで、チャネルごとの画面や端末をつなぐと、照合や制度変更への対応を管理しやすくなります。
売り場端末・金融機関・オンラインの統合
チャネルごとに、必要な管理と障害対策を洗い出しておきます。
- 販売先：窓口・端末、金融機関画面、Web、スマートフォン、会員ページ
- 共通ルール：販売期間、対象地域、購入限度、決済状態、注文番号
- 端末・オンライン：通信断時の制御と再送、アクセス集中時の排他制御
- 接続テスト：端末時刻、販売停止の反映、再送取引の重複排除
公式サイトでは、普通くじやロトのほか、ビンゴ5やナンバーズも購入できます。クイックワンなども対象に含まれ、購入記録を電磁的に預かる運用もあります（出典: 宝くじ公式サイト「ネット購入」、2026年確認）。
商品・購入・抽せん・払戻しを一つの台帳でつなぐ仕組み
取引の土台になるのは、商品・発売とチャネルの機能です。会員・本人確認、購入・券、決済の機能も、この土台に含めます。そのうえで、抽せん結果と当せん判定、払戻しを同じ台帳で追えるようにします。
精算、報告、監査ログも、この台帳に残します。商品ごとの条件や変更の扱いは、商品マスタで管理します。
- 販売条件：券種、価格、発売期間、販売地域、購入上限
- 結果・払戻し：結果確定日、払戻し期限
- 変更管理：発売前の承認と発売中の変更を分ける
抽せんでは、対象データを締めたうえで、結果の登録と二者承認、公開、変更履歴の記録まで設計します。乱数生成や鍵管理を採用する場合は、操作担当者、保存するログの年数、監査人の追跡方法も決めておきます。
払戻しでは、当せん判定と本人確認、口座振込を、未払いや時効、再処理とは別の状態として記録します。
決済・精算・監査の別レイヤー管理
決済成功と購入確定は同じ意味とは限りません。そのため、カード認証後の通信断や決済結果の遅れ、購入ボタンの二度押しに備えて、取引状態を分けておきます。
- 受付・認証中：購入確定前の状態を、ほかの状態と区別して扱う
- 購入確定：確定した取引の記録
- 取消・返金：取消待ちと返金済みを分けた状態
購入者に見せるメッセージと、内部での再照合処理も分けておきます。精算では日次で締め、売り場や金融機関ごとの売上と手数料を突き合わせます。さらに、払戻し、取消、未収、収益配分も照合の対象です。
自動照合で差異が残る場合に備えて、差異の理由、確認者、修正前後の値、承認時刻を記録しておきます。こうしておくと、障害や問合せの際に、正しい取引を説明できます。
公共くじ販売システム開発の進め方
開発は、制度の確認と現状調査から始め、業務量の定義、RFI・RFP、要件定義へと進みます。その後、方式検証と設計・開発、テスト・移行を経て、運用設計へ至ります。
画面の制作から急いで始めると、後になって法令や精算条件が見つかり、作り直しが生じます。そこで、先に業務主体と取引状態を固めておくと、品質と費用のぶれを抑えられます。
制度確認と現状調査
調査では、制度と関係者、既存環境、ピーク時の業務量を、この順に明らかにしていきます。
- 制度・主体：くじの制度と発売元、実施・受託・販売・決済・払戻し主体
- 既存環境：ホスト、端末、会計、顧客管理、金融機関接続、Webサイト
- 業務量・復旧：ピーク接続数、注文数、取引件数、保存年限、RTO、RPO
各システムの所有者、データ形式、連携頻度、障害時の窓口を確認すると、開発範囲が見えてきます。業務量は、年間の売上だけでなく、発売日や抽せん日、キャンペーン時のピークで捉えます。
ピーク時の同時接続数と1分間の注文数、日次の取引件数は数値で示します。さらに、商品の追加頻度と保存年限も数値にします。
目標復旧時間（RTO）と許容データ損失（RPO）も、あわせて定めます。数値が分からない項目は、計測の方法と仮置きの前提をRFPに書いておきます。
要件定義から段階的な設計・開発
異常時の業務シナリオを定め、その影響範囲に応じて、開発と検証の方法を選びます。
- 取引異常：決済タイムアウト、二重送信、売上確定後の取消、停止直前の注文
- 結果・障害：抽せんデータ差異、払戻し失敗、通信断、災害切替
- 検証方法：影響の大きい制度・精算・監査はウォーターフォールで管理
- 早期確認：決済、端末、ピーク負荷、照合をPoC等で先行検証する
各シナリオでは、システムの状態と担当者の操作を定め、利用者への表示や再処理の方法、監査ログも決めておきます。一方で、画面や検索、分析など改善しやすい部分は、短いサイクルで検証します。
テスト・移行・運用の一体計画
テストから運用までを一つの計画にまとめ、品質と継続性を、次の項目で確かめます。
- テスト：単体、結合、総合、性能、セキュリティ、障害、業務リハーサル、受入
- 重点確認：購入・決済の不一致、結果承認漏れ、精算差異、復旧・切替
- データ移行：商品、会員、購入履歴、当せん、払戻し、精算残高を前後照合
- 運用契約：監視、一次切り分け、復旧、脆弱性・法改正、再委託、返却・移行
テスト結果は合否だけでなく、再現条件と残った課題も記録しておきます。加えて、データ移行では、移行の前後で件数と金額の両方を照合します。
旧システムへ戻す場合に備えて、戻す期限とデータ差分の扱いを事前に決めておきます。また、運用契約では、監視や復旧にかかる時間と、終了時のデータ返却や移行支援も定めます。
▶ 詳細はこちら：公共くじ販売システム開発の進め方
技術方式とセキュリティ要件の決め方
技術方式は、準パッケージ、クラウド・ハイブリッド、フルスクラッチを中心に比べていきます。流行よりも大事なのは、制度固有の取引や精算、抽せん、監査を、長期にわたって変更できるかどうかです。
オンラインを24時間対応にする場合でも、すべての機能を同じ可用性で動かす必要はありません。そこで、取引確定や決済、精算、抽せん関連を、より厳しく保護する層に分けるのが現実的です。
準パッケージ・クラウド・スクラッチの比較
方式ごとの特性を比べながら、制度への適合性と長期運用の条件を確かめます。
- 準パッケージ：会員、注文、券、決済、精算の既存部品に、制度固有の機能を追加する
- クラウド・ハイブリッド：Web等を伸縮性のある環境に置き、決済・精算を分離管理する
- フルスクラッチ：業務に合わせやすい一方、品質保証、人材の継続確保、保守、ベンダー交代のコストが大きい
準パッケージは導入を短期間で進めやすい反面、ライセンス、追加改修の単価、データの持ち出し、提供終了時の移行条件を確かめておきます。クラウドを使う場合は、データの所在やログ、暗号鍵、バックアップを確かめます。加えて、障害時の責任分界と、サービス終了時のデータ返却も、あわせて確認します。
本人認証・決済情報・個人情報の分離と保護
本人認証や決済情報を扱うときは、利用条件と情報保護の要件を分けて定めておきます。
- 購入条件：本人確認、年齢・居住地、購入限度額、不正利用検知、決済認証
- 保存・開示：決済番号や認証結果の保存範囲、問合せ時の開示情報
- カード保護：PCI DSS v4.0.1の対象範囲、委託先、証跡、診断、事故対応
宝くじ公式サイトは、2022年9月5日から3Dセキュア2.0に対応しました。また、リスクに応じて、ワンタイムパスワードや生体認証が必要になる場合があります（出典: 宝くじ公式サイト「本人認証サービス」、2026年確認）。
PCI SSCは2024年6月にv4.0.1を公開し、v4.0は2024年12月31日に退役しました。以後はv4.0.1がサポート対象です（出典: PCI Security Standards Council、2024年）。
カード情報を保持しない方式も、検討の対象にします。基準への対応を宣言するだけでなく、必要な事項を調達仕様と契約に定めておきます。
可用性・監査・クラウド評価の要件
可用性と監査の要件は、機能の重要度やクラウドの利用条件に合わせて定めます。
- 復旧目標：機能ごとの復旧時間と許容するデータ損失
- 可用性対策：重要度に応じた冗長化、監視、バックアップ、復旧訓練
- クラウド評価：ISMAP登録、利用機能、データ範囲、責任分界、ログ保存場所
ピーク時の性能は、想定の取引量を実測か過去データから定め、安全率の根拠も残しておきます。
ISMAPは、政府のセキュリティ要求を満たすサービスを評価・登録する制度です（出典: 国家サイバー統括室「ISMAP」、2026年確認）。ただし、ISMAPやPCI DSSだけに頼らず、業務上の監査証跡や復旧訓練も組み合わせます。
公共くじ販売システムの費用相場とコスト内訳
公共くじ販売システムに、一律の標準価格はありません。ここに示すのは、公共・金融系の調達規模と、販売から決済、精算、監査、運用までを含む構成をもとに整理した、提案依頼前の概算です。
税別か税込か、契約年数も見積によって異なるため、対象範囲と期間をそろえて比べることが大切です。
段階別の概算レンジ
開発の段階や規模ごとに、概算レンジを見ておきます。
- 企画・要件定義：現状調査やRFP支援を含め、500万〜2,000万円程度
- 小規模導入：準パッケージや小規模ネット販売で3,000万〜1億円程度
- 複数チャネル：端末、オンライン、決済、精算、結果公開を含み8,000万〜3億円程度
- 全国規模の更改：複数拠点の災害対策や厳格な移行・監査を含み1.5億〜5億円超の場合がある
これらは定価ではありません。制度の対象やチャネル数、ピーク性能によって、金額は変わります。さらに、既存資産や外部接続、セキュリティ評価、移行の難しさも、金額を左右します。
たとえば、オンライン購入だけに見えても、会員や決済、当せん、払戻しを既存の基盤につなぐ場合があります。画面数だけで算出した見積は、実態より低くなる可能性があります。
公開調達額と本体開発費の切り分け
公開調達額は、対象業務と契約期間を見たうえで、本体開発費と周辺費用、事業全体の予算に分けて読み取ります。
- 販促ツール：スポーツくじ販売促進のマーケティングツール。利用・運用保守が2億8,278万1,422円
- データ基盤：データマネジメント・プラットフォーム。利用・運用保守が1億2,034万2,200円
- 令和7年度予算：業務経費約481.7億円、スポーツ振興投票業務運営費約285.8億円
日本スポーツ振興センターの落札情報に掲載された2件は、複数年契約です。販売や抽せん、払戻しの中核となる開発費ではありません（出典: 日本スポーツ振興センター令和7年度調達情報、2025〜2026年）。
令和7年度予算は事業全体の数字で、システム開発費ではありません（出典: スポーツ庁「令和7事業年度事業計画、予算及び資金計画」、2025年）。周辺基盤でも複数年契約で億単位になり得るため、運用費は複数年の契約期間で見ておく必要があります。
見積もりでは、開発費と機器費、クラウド費を分けて立てます。移行や教育、保守は、別の項目として扱います。
初期費用と5年TCOの比較
ランニングコストには、保守や監視、クラウドやデータセンター、端末の更新、決済手数料が含まれます。加えて、脆弱性診断やログ保管、バックアップ、災害復旧訓練も対象です。さらに、法改正への対応や商品追加、問合せ対応も対象です。
初期開発費の15〜25％程度を、年間の保守費の目安とする場合もあります。24時間のSLAや複数拠点の運用を含むと金額は変わるため、見積もりの条件を確かめておきます。
比較表では、費用を項目ごとに分けて、5年間の総額を算出します。
- 導入費：初期費用、移行費用
- 運用費：年額固定費、取引量に応じた従量費
- 評価・終了費：第三者評価、データ返却・移行費用
制度変更時の追加開発の単価や、別の会社へ運用を移す条件も確かめておくと、将来のコストを把握できます。
▶ 詳細はこちら：公共くじ販売システム開発の見積相場・費用
開発会社・サービスの選び方
会社を決めるときは、知名度や見積総額に加えて、自社の要件に近い経験を見ていきます。公共くじに完全に一致する公開実績がない場合でも、要件に近い類似経験は評価の対象になります。そのうえで、公開実績と、提案時に確認する実績を分けて聞きます。
実績の対象範囲と担当工程の確認
実績は、案件名や業種のほかに、経験の対象範囲まで見ていきます。
- 業務範囲：販売、抽せん、払戻しのどこを担当したか
- 接続範囲：売り場端末、オンライン、決済、金融機関連携の経験
- 運用体制：本番運用や障害対応を担う事業者と責任範囲
開発だけを担当し、本番運用や障害対応は別の会社が担ったケースもあります。このため、必要な範囲にどこまで責任を持つ体制かを確かめます。
再委託がある場合は、役割や所在、セキュリティ管理、障害時の連絡経路、契約終了時の引き継ぎを見ておきます。担当者の経験に加えて、交代時の引き継ぎ資料やレビュー体制、テスト責任者、運用責任者も評価します。
提案内容の異常系・運用・説明力による評価
提案を評価する際は、異常時の対応と運用の条件を具体的に示させ、見積の前提をそろえておきます。
- 異常系：決済タイムアウト、二重購入、停止、結果差異、誤登録、災害切替
- 運用指標：RTO・RPO、監視・通知時間、復旧手順、訓練頻度
- 見積条件：機能範囲、前提、外部サービス、移行・保守費、追加変更単価
未確定の要件を明示する会社は、追加費用や認識の違いを抑えやすくなります。判断は、最安値よりも、制度への適合性や継続運用、変更のしやすさを含む総コストで行います。
契約とベンダーロックインの条件
契約が終わった後も運用を続けられるように、権利とデータ、移行の条件を、契約と設計の両方に残しておきます。
- 成果物・責任：著作権、利用権、ソース・設計書、監査協力、障害責任
- 契約管理：データ所有権、再委託、秘密保持、個人情報、データ返却
- 移行可能性：データ形式、API、ログ、手順を文書化し移行テストする
特定の製品や担当者に依存する部分は、代わりの手段と移行の手順を、設計の段階から用意しておきます。そのうえで、復旧と移行のテストを定期的に行います。
運用を委託する場合でも、発注者が取引の正本と監査証跡にアクセスできる状態を、契約で確保しておきます。
▶ 詳細はこちら：公共くじ販売システム開発でおすすめの開発会社6選と選び方
発注・外注・委託の進め方
要件と責任を整理しないまま委託すると、見積もりの比較も検収もできません。そこで、RFIで市場の対応範囲や方式を把握し、RFPに業務シナリオや非機能要件、監査、運用、契約条件を明記します。
RFIでの情報収集とRFPでの比較条件の統一
RFIでは、制度や販売チャネル、既存システム、取引量、希望時期を示したうえで、提案者から方式や実績などの情報を集めます。
- 方式・前提：対応可能な方式と提案の前提
- 費用・体制：概算費用、実施体制、標準機能と追加開発の境界
- 類似実績：業務や技術の近い導入実績
RFIは、会社を決めるためというより、発注者が見落としている論点を見つける材料として使います。
RFPには、機能要件に加えて、ピーク負荷やSLA、RTO・RPOを盛り込みます。さらに、法改正や再委託、監査、データ所有権についても記します。あわせて、終了時の移行やセキュリティ評価、受入基準も示します。
提案書の目次や見積内訳、質問期限、デモやPoCの範囲をそろえておくと、価格と品質を比べやすくなります。
一括委託と分離委託の責任の比較
一括委託と分離委託では、窓口や責任、競争性、管理の負担が異なります。
- 一括委託：窓口と全体責任をまとめやすいが、一社への依存や競争性の低下があり得る
- 分離委託：専門事業者を組み合わせられるが、責任分界と障害時の指揮を発注者が管理する
決済やセキュリティを分ける場合は、取引番号や状態、ログ、個人情報、インシデント情報の受け渡しを定めておきます。再委託先を含む体制図や連絡網、変更の承認、リリース判定、障害訓練の責任者は、契約書と運用設計書に書き込みます。
分けたからといって、必ず安全になるとは限りません。境界を管理するコストも、見積もりに含めておきます。
調達資格・品質管理・終了条件の確認
調達資格と検収、終了時の処理は、一連の条件として確かめます。
- 調達体制：参加資格、履行実績、情報・個人情報管理、再委託、事業継続
- 評価基準：ISMAP等の適用範囲と、PCI DSSの別個の評価
- 検収・終了：業務完了、データ一致、監査追跡、返却・移行・消去
検収では、業務シナリオが完了しているか、取引と決済、精算のデータが一致しているか、監査ログをたどれるかを確認します。
クラウドでは、ISMAP等の要件と、対象サービスや利用範囲が合っているかを見ます。PCI DSSはカードデータを守るための基準で、公共調達の資格とは別に評価します。
契約終了時には、アカウントの停止やバックアップの消去、秘密情報の返却・廃棄も確かめます。開始前に終了の条件を決めておくことが、長期運用の安全性につながります。
▶ 詳細はこちら：公共くじ販売システム開発の発注・外注・委託方法
運用で起きやすい失敗と対策
発売日や抽せん日にはアクセスが増えるほか、制度改正や商品追加も起きます。障害の発生を前提に、異常を早く発見し、正しい状態を確定し、関係者へ説明して、再発を防ぐ運用を設計します。
同時接続数だけに頼らないピーク対策
同時接続数だけでなく、処理ごとの負荷と障害時の取引の整合性を試験します。
- 負荷箇所：検索、ログイン、予約、決済、購入確定、結果公開
- 整合性：注文保留時に決済だけ進む、購入が重複する事象
- 負荷試験：通常、発売直後、停止直前、結果公開直後、復旧後
- 業務訓練：待機画面、端末再送、決済遅延、監視アラートの優先度
サーバーを増やすことに加えて、処理ごとのボトルネックを測ります。業務リハーサルでは、復旧後の再接続も確かめます。
法改正・商品追加・ベンダー交代への備え
制度変更や担当の交代があっても運用を続けられるよう、設定と引き継ぎ資料を整えておきます。
- 設定管理：商品、販売ルール、購入上限、結果公開日、払戻し期限
- 変更履歴：承認、適用日時、旧設定との差分を残す
- 継続・交代：運用資料を更新し、資料レビューや移行リハーサルを行う
制度変更のたびにプログラムを直接修正し続けると、テストの範囲も費用も膨らみます。そこで、制度ごとの差を設定と業務ルールに分けておくと、長く運用しやすくなります。
構成図やデータ辞書、障害と復旧の手順、定期作業、連絡網を更新し、特定の担当者しか知らない作業を減らします。
よくある質問
企画や発注の初期段階で多く寄せられる質問を、まとめて取り上げます。回答は制度や契約条件によって変わるため、対象の法令、規約、調達仕様、委託契約を確かめてください。
公共くじ販売システムの開発費はいくらですか？
企画・要件定義は500万〜2,000万円程度、準パッケージ導入や小規模なネット販売は3,000万〜1億円程度が目安です。
複数チャネルの販売基盤は8,000万〜3億円程度です。全国規模の基幹更改や厳格な災害対策を含む場合は、1.5億〜5億円超になることがあります。
対象の制度やチャネル、外部接続を決めたうえで、性能や移行、運用の条件を固めなければ、正確な見積は出せません。
公共くじ販売システムはクラウドで構築できますか？
構築はできますが、すべての機能を同じ環境に置く必要はありません。Webや会員、分析、監視をクラウドで伸縮させる構成もあります。
決済や精算、抽せん関連を分けるハイブリッド構成も、選択肢の一つです。政府機関などの調達では、ISMAPの適用やデータの所在、ログ、鍵管理、障害時の責任分界を確かめます。クラウドの利用範囲は、業務要件と合わせて判断します。
抽せんの公平性と監査証跡はどう設計しますか？
抽せんでは、対象データの締めと、結果の生成または登録を分けて設計します。そのうえで、二者承認や公開、変更履歴、操作ログも、それぞれ組み立てます。
乱数生成、鍵管理、権限、バックアップ、第三者確認を採用する場合は、確認者と保存する証跡を定めておきます。大事なのは、第三者が手順と結果を追跡できることです。
開発期間はどのくらいかかりますか？
企画・要件定義は1〜3か月、準パッケージや小規模ネット販売は6〜12か月が目安です。複数チャネルの販売基盤は12〜24か月、基幹更改や災害対策を含む大規模案件は18〜36か月が一つの目安です。
期間は、法令の確認や外部接続、端末、移行の進め方によって変わります。受入や並行稼働の有無も、期間に響きます。計画には、開発だけでなく、テストと業務リハーサルも含めます。
発注前に最低限まとめるべき情報は何ですか？
対象の制度と発注者、運営主体を整理したうえで、販売チャネルや既存システム、ピーク時の取引量もまとめます。必要な機能と外部接続も、あわせて書き出します。
RTO・RPO、セキュリティ条件、希望時期、保守の範囲もまとめておきます。未確定の数値は、仮説と確認方法、提案者に求める算定方法を示します。こうしておくと、提案の前提のずれや追加費用のリスクを大きく減らせます。
まとめ
公共くじ販売システムは、制度に沿って販売から払戻しまでを支える、公共性の高い基盤です。精算や監査、運用まで含めて、長く続けられることが大切です。
宝くじとスポーツくじを分けて考え、発売元や実施主体、受託銀行の責任を整理します。そのうえで、販売店や決済事業者、運用者の責任範囲も書き出します。
制度適合性と5年の運用継続性による判断
公共くじシステムを選ぶときは、費用と実績、調達条件を一緒に比べ、運用を続けられる構成かどうかで判断します。
- 費用：企画、開発、接続、端末、セキュリティ、移行、保守を5年TCOで比較
- 事業者：制度、金融・決済、精算・照合、公共調達、24時間運用の実績を評価
- 発注条件：RFIで前提を整理し、RFPに異常系、SLA、監査、再委託、移行を明記
- 最終判断：取引の正しさを確認でき、制度変更後も継続運用できる構成を選ぶ
最初に作るべき資料：責任分界表と異常系一覧
まずは、業務主体やシステム、データ、承認者を一覧にした責任分界表を作ります。あわせて、決済遅延や二重送信、販売停止、結果差異、災害切替を洗い出した異常系一覧も用意します。
この二つを、RFIやRFPの土台にすると、開発範囲や見積条件、テスト項目、運用契約の抜け漏れを早い段階で見つけられます。
▼関連記事一覧
・公共くじ販売システム開発の進め方
・公共くじ販売システム開発でおすすめの開発会社6選と選び方
・公共くじ販売システム開発の見積相場・費用
・公共くじ販売システム開発の発注・外注・委託方法
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。