職域・持株会システム開発の発注/外注/依頼/委託方法について

職域・持株会システムの発注は、業務の範囲と委託の方法を先に決め、提案と見積を同じ条件で比べる流れで進みます。

RFPの作成、テスト、移行を順に進めると、月次締めと監査証跡を安定させられます。

▼全体ガイドの記事
・職域・持株会システム開発の完全ガイド

職域・持株会システムの発注・外注で最初に整理する全体像

「職域」は範囲の広い言葉です。発注時には、従業員持株会の制度運営、会員管理、給与・証券会社との連携を中心に範囲を決めます。

従業員向けの残高照会に加え、事務局の締め処理や訂正、帳票も業務システムの対象です。権限と監査ログも、業務システムの対象に含まれます。

発注前に決める対象業務

発注前には、対象とする業務とイベントを次のとおり一覧にしておきます。

  • 制度の前提:法人・制度数、会員数、給与締め日、買付日、奨励金率、拠出上限、休止・退会条件
  • 業務の流れ:入会から訂正までを時系列にし、入力・計算・承認・送信・結果確認の定義
  • 対象イベント:拠出額変更、給与取込、奨励金計算、買付、配当再投資、残高報告、異動・退職、売却・引出し

東京証券取引所の調査では、対象は3,265社、加入者は330.2万人、株式保有金額は8兆2,635億円でした(出典:東京証券取引所、2026年)。加入率は40.12%で、奨励金を支給する会社は96.6%でした。

平均奨励金は、拠出金1,000円につき107.24円です(出典:東京証券取引所、2026年)。調査名は「2024年度従業員持株会状況調査結果の概要について」で、2026年に公表されています。

金額と利用者の規模を踏まえ、持株会システムは計算と証跡を持つ業務システムとして発注します。

自社・証券会社・開発会社の役割分担

発注前に、関係者ごとの責任と、データの正を次のとおり決めておきます。

  • 関係者:会社、事務局、人事・給与、証券会社、信託銀行、開発会社の責任範囲
  • 自社の責任:従業員マスタ、給与控除の承認、異動情報、問い合わせ、データ保存
  • データの正:人事は会員資格、給与は控除額、証券会社は買付・保有残高
  • 連携と締め:データの出所・返却先、締め時点の記録、再送、差分訂正、承認者

証券会社へ委託しても、自社の責任は残ります。

すべてを新システムの正にすると責任が重くなり、各システムを正と呼ぶだけでも不整合が起きます。そのため、開発会社にはデータの出所と処理結果の返却先を図で示してもらいます。

発注形態・契約形態の選び方

発注形態は、委託する範囲と自社で統制する範囲のバランスで選びます。

制度運営を標準化したい場合は、証券会社への事務委託が候補になります。

会員・申請・残高管理を早く整えたいなら専用クラウド、独自の信託・会計処理を統合したいならSIerの個別開発を検討します。

証券会社への事務委託が向いているケース

証券会社の標準サービスに合わせられる企業は、事務委託を候補にできます。比べるときは、次の条件を見ます。

  • 委託範囲:買付・株式事務・会員向けWebをまとめて任せる
  • 社内連携:給与・人事連携、異動・退職処理、問い合わせ、データ出力
  • 制約と終了時:独自承認・締め日、データ返却、履歴保存、移行支援、障害連絡

野村證券、大和証券、三菱UFJモルガン・スタンレー証券などは、制度運営やオンライン申請・残高照会のサービスを公開しています。

委託は開発費を抑えやすい一方で、独自の承認フローやグループ会社ごとの締め日を変えられない場合があります。

委託範囲が広いほど、委託先の管理と社内の業務理解が欠かせません。

専用クラウドとカスタマイズ開発の組み合わせ

専用クラウドと追加開発を組み合わせる場合は、次の範囲に分けて検討します。

  • 標準機能:会員情報、申請、積立金、残高、帳票
  • 追加開発:給与CSV、本人認証、会計連携などの不足機能
  • 提案範囲:標準設定、API連携、追加開発、運用代行をRFPで区分

標準機能と不足機能を組み合わせると、費用と柔軟性のバランスを取りやすくなります。ただし、個別対応が広がると、更新のたびに検証費用が発生します。

持株会向けのクラウドには、情報システムサービス株式会社の「持株EXPRESS」などがあります。

Share Managerは株主管理を起点に持株会機能を提供し、2026年にも積立額変更管理などの機能更新を案内しています。

料金は、スモールが月額1,100円、スタンダードが月額5,500円で、エンタープライズは見積制です(出典: Share Manager公式サイト、2026年)。

公開料金は適用範囲によって異なるため、証券会社連携や複数法人対応を含む価格と混同しないよう注意します。

準委任と請負の工程ごとの使い分け

制度がまだ分からない段階の現状分析や要件定義は、準委任と相性がよいです。

  • 準委任:対話が必要な要件定義・現状分析、運用改善
  • 請負:仕様と検収条件を定められる画面・API・帳票開発、データ移行
  • 工程の分け方:要件定義は準委任、設計・開発は請負、運用改善は準委任

すべてを請負にすると、要件変更が追加費用や遅延につながりやすくなります。一方、すべてを準委任にすると、成果物や完了条件が曖昧になりがちです。

契約書には、検収基準、瑕疵対応、仕様変更を明記します。また、再委託と秘密保持、個人情報の扱いを定めます。障害時の責任分界と、ソースコードとデータの帰属も決めておきます。

ポイント

委託範囲と自社で統制する範囲で発注形態を選び、工程ごとに準委任と請負を分けます。契約書に検収、仕様変更、責任分界が書かれているかが判断の目安です。

RFP・要件整理で発注仕様に書く内容

月次締め要件を通常処理、計算・出力、例外処理、訂正管理の4項目に分けた図。
例外処理と訂正管理も、通常処理と並ぶ仕様項目です。

RFPは、機能一覧と価格を求めるだけの資料にとどまらず、会社ごとの提案を同じ条件で比べるための発注基準です。制度と現行業務に加え、連携とセキュリティの条件も明記します。移行と運用についても、同じ形式で書きます。

まずRFIで、サービスや業務委託の選択肢を広く確認します。そのうえでRFPにより必須要件と提案要件を絞ると、過剰なスクラッチ開発を避けやすくなります。

月次締めの業務イベントに基づく要件

月次締めの要件は、正常処理と例外処理を分けて整理しておきます。

  • 通常処理:給与・賞与の拠出額に奨励金を加え、買付データと突合
  • 計算・出力:会員別の株数・口数・端数・取得単価・手数料、残高報告、会計データ
  • 例外処理:買付失敗、給与重複、締め後退職、株価未着、証券会社の再送
  • 訂正管理:元データを残し、訂正理由・承認者・前後値・日時を差分履歴に記録

同じ給与ファイルの二重取込を防ぐ、冪等性が必要です。条件をRFPに書いていないと、単純な上書き更新が提案されるおそれがあります。上書き更新だと、運用開始後に監査や問い合わせの負担が膨らむ可能性があります。

給与・人事・証券・会計連携の入出力

連携要件は、システム名だけでなく形式や運用条件まで決めておきます。対象ごとの項目は、次のとおり整理します。

  • 共通条件:項目、形式、頻度、締め時刻、再送、照合キー、担当者
  • 給与:社員番号、法人、拠出額、控除月、休職・退職区分
  • 証券会社:買付日、銘柄、数量、約定情報、会員別持分、振替・売却結果
  • 会計:奨励金、手数料、返金、未払・預りの仕訳項目
  • ファイル・コード:障害時のCSV、暗号化、命名、受領、保管・削除、旧新コード履歴

APIが使える場合でも、障害時にCSVで処理を続けられる手段を用意しておきます。

転籍や企業再編の際も、残高、拠出、申請が別人のものに見えないようにします。

セキュリティ・監査・個人情報の要件の明文化

扱う情報は、氏名や住所、所属に加え、給与控除額、証券口座、保有残高に及びます。そのため、管理策を具体的に定めます。

  • 保護策:最小権限、管理者の多要素認証、通信・保存時の暗号化、アクセスログ
  • 運用策:管理者操作の承認、脆弱性診断、バックアップ、復旧訓練
  • 権限設計:職務を分けて、事務局、人事、経理、証券会社、開発会社の閲覧範囲を区切る
  • 委託先管理:再委託先の把握・監査、事故連絡、ログ保存年数、データ返却、復旧目標

金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」は、2025年7月にも一部改正されました。このガイドラインは、委託先やサードパーティを含むリスク管理を検討する際の基準になります(出典: 金融庁、2025年)。

日本証券業協会の「持株制度に関するガイドライン」は、2025年6月12日に改正されています(出典: 日本証券業協会、2025年)。

ポイント

RFPは月次締めの業務イベントと例外処理を中心に書き、連携は形式と締め時刻まで決めます。セキュリティと委託先管理も、必須要件に入っているかが判断の目安になります。

職域・持株会システムの発注から導入までの進め方

企画、RFI・RFP、要件定義、月次締めの検証、本番移行の5つの節目を並べた時系列図。
要件を決めた後に検証と移行へ進みます。

発注は、提案を比べて会社を選んだ後も続きます。

工程は、企画、RFI・RFP、要件定義の順に進みます。

その後、設計・開発とテストを経て移行に進みます。移行のあとは並行稼働を行い、運用開始に至ります。各段階で成果物を確認します。

初回リリースでは全制度を一度に対象にせず、月次締めの最小業務を安定させる方法もあります。そのうえで、スマホ申請やAPI連携を広げていきます。

企画とRFP作成での社内の判断者の調整

企画では社内の判断者を集め、担当部門ごとの要求をそろえます。

  • 参加者:事務局、人事、給与、経理、情報システム、法務・コンプライアンス、必要に応じ証券会社
  • 担当領域:事務局は訂正・締め、人事は資格・異動、給与は控除、経理は仕訳・残高
  • 専門領域:情報システムは認証・連携・運用、法務は個人情報・委託管理
  • RFP項目:背景・目的、範囲、課題、規模、業務、画面・帳票、連携、非機能要件
  • 提案条件:移行、教育、保守、様式、日程、標準・設定・追加開発・対応不可の区分

部署ごとの要求は分けて整理しておきます。

提案範囲を区分しておくと、会社ごとの見積条件をそろえやすくなります。

提案比較後の要件定義による不確実性の低減

提案比較と要件定義では、次の実演と成果物を確かめておきます。

  • 月次締めの実演:給与取込、奨励金計算、買付照合、異動・退職処理、訂正履歴、帳票
  • 操作確認:例外処理、誤操作の警告、再実行の可否
  • 要件定義の成果物:業務一覧、データ項目、連携仕様、権限表、帳票、テスト・移行方針、運用手順
  • 変更管理:見積前提と成果物を結び付け、変更要求、完了条件、未決事項、決定期限を記録

実演では、画面の見た目より例外対応を見ます。

要件や見積の条件を明確にしておくと、開発中の手戻りを抑えられます。

月次締めを中心にしたテストと並行稼働による移行

月次締めの検証から本番移行までは、次の順で進めます。

  1. 例外を含めてテスト:入会・拠出・買付、給与重複・金額不一致、買付失敗、端数、配当再投資、休職、締め日前後の退職、転籍、制度変更、通信断、証券会社の再送を試す
  2. 数値を照合:匿名化した実データに近い件数を使い、入力、計算結果、会員残高、会計データ、帳票を繰り返し確認
  3. 移行データを整備:旧Excel・Accessや証券会社帳票から会員、拠出、買付、残高、履歴を抽出し、重複・欠損・コードを整理
  4. 並行稼働して切替:新旧を数回動かして残高・締め結果を照合し、本番初月の連絡網と手作業の代替手順を用意

本番初月は、開発会社と事務局の間で連絡できるようにします。給与、人事、証券会社との間でも連絡できる体制にします。さらに、障害時にも給与控除や買付の締切を守れるようにします。

ポイント

各段階の成果物を見てから次へ進むことが、判断の目安です。初回リリースを月次締めの最小業務に絞るかどうかも、判断材料になります。

職域・持株会システム開発の費用相場と見積内訳

複数法人のパッケージ、クラウド基盤の個別開発、スクラッチ開発、大規模統合の初期費用推定レンジを示す横棒図。
統合規模の方式ほど、推定レンジの上限が高くなります。

職域・持株会システム単体の公開見積統計は多くありません。そのため、2025〜2026年の一般的な業務システム価格に、給与・証券会社連携と金融系の監査・セキュリティ要件を加味した推定を示します。

RFP作成前の予算取りに使う目安で、実際の契約額ではありません。

提案を受ける際は、同じ前提で個別見積を依頼します。

方式別の初期費用と開発期間の目安

方式別の予算と期間は、発注範囲を比べる基準になります。想定する内容に応じて、次の推定レンジを参考にしてください。

  • クラウド:汎用は0〜300万円・1〜3か月程度、持株会用は300〜800万円・2〜5か月程度が目安
  • 複数法人のパッケージ:800〜1,500万円・4〜9か月程度が目安
  • クラウド基盤の個別開発:1,200〜3,000万円・6〜12か月程度を見込みます
  • スクラッチ開発:2,000〜5,000万円以上・10〜18か月程度
  • 大規模統合:金融基盤や複数グループ会社では5,000万円〜1.5億円程度・12〜24か月程度となる場合があります

汎用クラウド等は、既存のサービスを設定して会員・株主管理を始める想定です。

持株会クラウドでは、会員画面、申請、残高に加えて、帳票と給与CSV連携も含みます。

パッケージでは、複数法人・制度、承認、会計・人事連携を想定します。

個別開発には、スマホ申請、API、独自の奨励金・信託処理が含まれます。

金額は開発範囲から逆算した推定で、公開料金ではありません。

「システム幹事」などの一般相場情報も、証券会社連携や監査要件を含むとは限りません。

見積には、会員数、法人・制度数、連携数を加味します。さらに、ピーク処理と移行量、セキュリティ診断、SLAも見積に反映します。

専用サービスの月額料や初期設定が別建てになる場合もあります。制度設計支援や証券会社費用も、別建てになる場合があります。

要件定義・連携・移行・テストに分けた初期費用の内訳

見積は、工程や機能ごとに分けてもらいます。内訳をそろえると、各社の対象範囲を比べられます。

  • 設計・機能:要件定義、業務設計、画面、管理機能、計算ロジック
  • 連携・帳票:API・CSV、帳票、認証、権限
  • 導入:データ移行、テスト、セキュリティ診断、教育、導入支援
  • 運用準備:運用設計、保守、制度変更への対応

要件定義だけで100〜500万円程度を仮置きします。

連携先が増えるほど、設計、テスト、障害対応の工数も増えます。

既存データの品質が低い場合は、移行前のクレンジングを別項目として扱います。また、安い見積では、月次締めの例外と並行稼働、監査ログ、脆弱性診断も確認します。

問い合わせや制度改定が除外されていないかも見ます。手作業の照合や変更のたびの追加開発があれば、5年間の総費用は高くなります。

初期費用に加えて、制度変更と担当者交代まで含めた総保有コストで比べます。

運用費・保守費と制度変更費の予算化

運用費は利用規模と対応条件で変わるため、費用項目と契約条件を分けて予算化します。

  • 運用費の対象:クラウド、監視・バックアップ、問い合わせ、アカウント管理、証券会社・給与システムの仕様変更、脆弱性、障害復旧、制度改定
  • 予算の目安:初期費用の年15〜25%、または月額10〜80万円程度
  • 見積の区分:通常保守、障害、軽微な変更、制度変更、追加開発、データ修正、監査対応
  • 締め日の対応:受付時間、一次回答、復旧目標、代替手順、報告書期限

費用は、会員数やSLA、対応時間、連携数によって変わります。あわせて、金融庁のITレジリエンスに関する公表資料も確認します(出典: 金融庁、2025年)。

復旧できるかどうかに加えて、重要業務をいつまでに再開できるかを定めます。復旧目標は、発注の品質に直結します。

ポイント

予算は方式別の推定レンジを目安にし、見積は工程と機能に分けてもらいます。運用費は初期費用の年15〜25%、または月額10〜80万円程度を基準に、制度変更まで含めて比べます。

委託先の選定と見積比較で失敗しないポイント

委託先は、持株会業務と月次締めを理解し、安全に運用できるかで選びます。知名度や総額は、その判断材料の一つとして扱います。

証券会社や専用クラウド、金融系SIerと、一般的な業務システム会社とでは、得意領域が異なります。委託したい範囲に合う候補を選びます。

持株会実務と金融系システムの経験の確認

候補会社の経験と評価項目をそろえ、実務を担う人にも確認します。

  • 経験:職域・持株会、証券、信託、給与連携と担当工程
  • 機能・業務:専用機能、各システム連携、複数法人・制度、奨励金・配当、異動・退職・訂正
  • 運用・契約:監査ログ、本人確認、障害対応、移行・返却、SLA、料金の透明性
  • 体制:実務責任者との面談、担当者交代時の引き継ぎ

株式会社エス・エス・シーは、公式の会社案内で「職域・持株会システム」を証券分野の実績として明記しています。また、現状分析・要件定義から設計、導入、移行、エンハンスまでを掲げています(出典: 株式会社エス・エス・シー会社案内、2024年)。

実績と自社要件への適合は別問題です。そのため、月次締めのデモ、導入事例、保守体制を見ます。

機能・工数・前提・除外範囲をそろえた見積比較

見積条件と除外範囲をそろえ、初期費用だけに偏らないよう比べます。

  • 費目:要件定義、設計、開発、連携、移行、テスト、教育、保守
  • 前提:標準・追加機能、会員・法人・制度数、連携先、取引量、移行件数、診断、納品物、検収
  • 除外の確認:接続試験、旧データ整備、制度改定、本人確認、帳票、締め立会い、休日障害、再委託先監査
  • 総合評価:追加費用を一覧化し、5年間の総額と業務負担を比べる

前提が異なる場合は、比べる前に補正します。「一式」の金額では、含まれない作業を質問します。

5年間の総額と業務負担で評価すると、初期費用だけの価格競争を避けやすくなります。

価格と同じ重みで見る契約・再委託・障害対応

外注後の責任分界が曖昧にならないよう、契約と障害対応を具体的に決めます。

  • 契約範囲:サービス、データ管理者・目的・保管場所、アクセス権、再委託、監査・報告
  • 終了・保護:脆弱性対応、事故通知、返却・消去、終了時の移行、安全管理措置
  • 再委託管理:承認・把握・監査方法、複数社の報告先一覧
  • 障害対応:締め停止、誤計算、欠損、不正アクセス、連携停止ごとの連絡・切り分け・復旧
  • 事後対応:原因報告、再発防止の期限、ログ確認者、処理停止の基準

障害の重大度ごとに、一次連絡と切り分けの方法を決めておきます。

そのうえで、暫定と完全の復旧、原因報告、再発防止の期限を定めます。

ログが残っていても、確認者や処理を止める基準がなければ監査につながりません。

運用設計と契約は、同時に固めます。

ポイント

委託先は持株会業務と月次締めの理解で選び、見積は前提と除外範囲をそろえて5年間の総額で比べます。実績がある会社でも、月次締めのデモで自社の例外処理に対応できるかを見極めます。

よくある質問(FAQ)

発注では、費用のほかに制度運営とデータ連携、監査と障害対応も含めて判断します。よくある質問への回答を、次に示します。

職域・持株会システムはいつ外注すべきですか?

入退会や給与控除、買付、残高照合に時間がかかり、締め日に手作業で突合している場合は、外注を検討します。

上場準備やグループ再編、会員増加、制度の複雑化により、担当者の経験に依存する場合も対象です。

外注前に業務と責任分界を整理しておくと、事務委託かシステム開発かを選びやすくなります。

開発費用は何万円から考えればよいですか?

開発費用は、選ぶ方式によって幅が大きく違います。標準的なクラウド設定からスクラッチ開発まで、方式ごとの目安を並べます。

  • 標準クラウド設定:0〜300万円程度
  • 給与CSVや申請を含むクラウド:300〜800万円程度
  • 複数法人・複数連携の個別開発:1,200〜3,000万円程度
  • スクラッチ開発:2,000万円以上となることが多い

費用は会員数に加えて、法人・制度・連携・監査・移行・SLAによって変わります。

推定レンジは目安なので、同じRFP条件で個別見積を取ります。

クラウドとスクラッチ開発はどちらがよいですか?

制度を標準機能に合わせ、短期間で安定して運用したい場合は、クラウドが向いています。

複数法人や独自の奨励金・信託処理があれば、クラウド基盤の個別開発やスクラッチを検討します。基幹連携や高度な監査要件がある場合も、検討の対象に入ります。

独自開発では、制度変更やセキュリティ更新に加えて、担当交代や長期保守も自社の負担になります。10年程度の運用体制を含めて判断します。

RFPに最低限入れるべき項目は何ですか?

対象の法人・制度・会員数と、入退会の業務フローを記載します。加えて、給与・人事・証券・会計連携と締め処理も書きます。

再計算と訂正、権限とログ、本人確認に加えて、移行とテスト、保守、SLAも盛り込みます。委託先に関する再委託とデータ返却も、あわせてRFPに記載します。

必須要件と提案要件を分けて、各社に区分を明示させます。区分には、標準機能と設定、追加開発、対応不可が含まれます。こうして区分をそろえると、例外処理の漏れや将来費用も比べられます。

まとめ

発注前に制度の範囲と業務イベントを整理し、給与・人事・証券・会計の正となるデータを決めておきます。

証券会社への委託、専用クラウド、クラウドと個別開発、スクラッチを、柔軟性、費用、運用負担の観点で比べます。返却や監査の面も、あわせて見ます。

発注を成功させる要点

RFPは画面より月次締めを中心に作ります。テストでは、異動・退職・再送・訂正を確かめます。そのうえで見積には、移行とセキュリティ、運用、制度変更まで含めます。

金融庁や日本証券業協会の最新指針を確認します。そのうえで、再委託やログ、障害連絡を契約に定め、復旧目標とデータ返却も盛り込みます。

発注後も、自社には業務判断と委託先管理の責任が残ります。

まず作成する資料と次のアクション

外注計画は、資料作成から見積比較まで次の順に具体化します。

  1. 現状を一枚に整理:法人・制度・会員数、月次締め、現行ファイル、連携先、例外処理、希望時期
  2. 候補を比較:RFIで候補を確認し、2〜3社以上へ同じRFPを提示して月次締めを実演してもらう
  3. 費用と契約を決める:発注方式・契約を工程ごとに選び、初期費用と5年間の運用費を比較

▼全体ガイドの記事
・職域・持株会システム開発の完全ガイド

会社紹介

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

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

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

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

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

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