取締役会管理システム開発の発注/外注/依頼/委託方法について

取締役会管理システムの発注は、業務を洗い出し、RFPで条件を整理し、複数社の提案を比べる順に進めると、要件と見積条件をそろえて選べます。

最初に外注する範囲と発注の目的を決めておくと、発注形態、契約形態、費用の見方を順に確かめられます。

▼全体ガイドの記事
・取締役会管理システム開発の完全ガイド

取締役会管理システムの発注前に整理する全体像

発注ではまず、システム化する業務と外部へ任せる範囲を分けて考えます。取締役会管理システムは、資料共有だけでなく、招集通知から実効性評価までをつなぐ業務基盤です。

金融庁と東京証券取引所は、2026年7月にコーポレートガバナンス・コードの2026年改訂版を確定しました。さらに、取締役会の機能強化に関する事例集も公表されています(出典: 金融庁・東京証券取引所、2026年7月21日)。

外注範囲の分け方(電子署名・専用SaaS・独自開発)

外注の範囲は、議事録の電子署名・保管だけに絞るか、専用SaaSを使うか、受託開発で作るかで変わります。

  • 電子署名・保管:紙の押印や郵送を早く減らせます。
  • 専用SaaS:招集通知、資料、議事録、承認、署名、保管を標準機能で連携し、社外取締役を招待する運用も行えます。
  • 受託開発:認証基盤、文書管理、ERP、グループ会社マスタと深く連携する場合に適します。

会議体が少なく、法務や事務局の作業を軽くしたい会社には、電子署名・保管から始める方法が向いています。ただし、署名サービスだけでは、議案の提出期限、資料の差し替え、役員ごとの閲覧状況、会議の年間計画までは管理しきれず、業務が分散します。

受託開発は柔軟性が高い反面、要件定義、セキュリティ設計、テスト、保守を自社と開発会社で長く担うことになります。

外注する理由の言語化

外注の目的は、専門性を活かして取締役会業務の設計を進めることです。社内に開発の人手がないことだけが、理由ではありません。

外注先には、取締役会の運営や機密情報に関して、次のような支援が求められます。

  • 業務設計:会社法や取締役会の運営を踏まえた業務の整理
  • 画面・権限:社外役員向けの画面と機密資料の認証の設計
  • 記録管理:電子署名と長期保管の運用の組み合わせ
  • 業務整理:事務局や法務の運用を支援できる会社の選定

議題や資料の確定者、議事録の承認時点、退任者のアクセス停止時期は、外注先ではなく発注側が決めます。外注だけでガバナンスが良くなるわけではないため、この判断は社内で持つ必要があります。

発注の前に、事務局や法務、情報システムの責任者を決めておきます。監査や経営企画の担当も、あわせて置きます。担当が明確であれば、開発会社との意思決定も速くなります。

発注目的と成功条件の定義

「ペーパーレス化」という目標だけでは、導入後に成功したかどうかを判断しにくくなります。そこで、業務の状態で成功条件を定めます。

  • 資料配信:開催3営業日前までに全役員へ最新版を配信する
  • 閲覧確認:未閲覧者を事務局が確認できる
  • 議事録管理:承認・署名状況を一覧で把握する
  • 退任者管理:退任者のアカウントを当日中に停止する

AI議事録では、作成にかかる時間だけでなく、人が校正して正式記録に確定する手順も成功条件に含めます。

発注形態の選び方

発注形態は、どこまで独自性が必要か、どれだけ早く導入したいかの釣り合いで決めます。短期導入と将来拡張を分けて考える方法もあります。

業務を標準機能に合わせて変えられるなら専用SaaS、既存サービスで足りるならツール連携が候補になります。一方で、独自の権限やグループガバナンスが重要なら、受託開発を検討します。

専用SaaSが向く会社(早く導入し、標準機能で定着させたい会社)

専用SaaSは、会議体、役割、議案、資料、議事録を前提に設計されています。そのため、画面やデータ構造を一から作らずに済みます。

数週間から数か月で本稼働できる場合もあり、初期設定は次の順に進めます。

  1. アカウントを発行し、会社情報と会議体を設定する
  2. 役員を招待し、既存資料を移行する
  3. 操作研修を行う

社外取締役がスマートフォンやタブレットで見られるか、通知が多すぎないかは、無料デモで確かめておきます。特に、実機で試すことが有効です。

独自の議事録様式や細かな承認分岐、閉域網は、標準機能に合わない場合があります。特殊な電子証明書も、同じく確認が必要です。また、海外子会社の運用も事前に確認しておきます。

変更できる範囲と、業務を標準に合わせる範囲を分けておきます。あわせて、退会時の返却形式や保存期間、バックアップ、利用停止後の削除時期も契約前に確認します。

既存ツールの組み合わせが向く会社

新規契約や開発を抑えたい場合には、既存ツールの組み合わせも候補になります。

  • 業務基盤:Microsoft 365、Google Workspace、Box
  • 周辺機能:オンライン会議、電子契約サービス

署名と保管から始めるなら、既存の文書管理に署名機能を足す方法もあります。

署名サービスの例として、WAN-Signは取締役会議事録の認印版署名を、人数を問わず1件100円(税抜)と案内しています(出典: WAN-Sign公式、2026年8月確認)。

ツールを組み合わせると、業務の流れが別々のツールに分かれます。資料の版や閲覧状況、承認を、どのツールで管理するかを決めます。署名や10年保管、役員交代時の権限変更も、同じように整理します。事務局の転記時間や誤送信のリスクも、比較に含めておきます。

問い合わせ窓口の分散や、監査時に履歴を集める作業も費用になります。ライセンス料だけでなく、これらを含めた総保有コストで判断します。

スクラッチ開発が向く会社(独自のガバナンス運用を実装したい会社)

受託開発なら、業務ルールを独自に実装できます。標準機能に運用を合わせずに済むのが、この方法の強みです。

  • 会議体:取締役会、監査役会、経営会議、指名・報酬委員会を横断する
  • 会社管理:親会社と子会社で管理者を分ける
  • 機密管理:議案の機密度に応じ閲覧範囲を変える
  • 情報活用:ERP指標の表示や実効性評価の蓄積に対応する

独自開発では、データモデル、認証、権限まで設計します。さらに、監査ログや暗号化、バックアップも設計に含めます。画面だけでは運用が成り立たないため、障害対応や法改正対応も開発の範囲に入ります。

運用責任者、ソースコードと設計書の所有権、開発会社を変更できる条件は、発注時に契約へ記載しておきます。

署名・保管からの段階導入

発注形態を決めきれない場合は、署名・保管から始めて、必要な機能を順に広げる方法があります。段階導入なら、各段階で効果を確認しながら進められます。

  1. 議事録の承認、電子署名、保管を始める
  2. 議案、資料、閲覧確認を専用SaaSへ広げる
  3. 必要な連携だけを追加開発する

最初の契約では、将来の機能をすべて確約しないようにします。データのエクスポート形式とAPIの有無を確認しておくと、次の選択肢を残せます。

ポイント

標準機能に合わせて業務を変えられるなら専用SaaS、独自の権限やグループガバナンスが欠かせないなら受託開発を候補にします。迷う場合は、署名・保管から段階的に始める方法もあります。

RFPと要件整理の進め方

RFPに含める現行業務の例外、機能優先度、法務・保管要件、提案回答欄を並べたチェックリスト図
例外処理から回答欄までを先にそろえると、各社の提案を同じ前提で見比べられます。

RFPは、開発会社やサービス会社に提案を依頼するための文書です。機能一覧に加えて、業務や利用者、機密情報を記します。導入希望時期や予算の考え方も、あわせて書き込みます。

提案書に求める回答形式も、あわせてそろえておきます。発注側の条件をそろえると、各社の見積を同じ前提で比べやすくなります。

開催前・開催中・開催後の現行業務の棚卸し

現行業務は、会議の前後と開催中に分けて洗い出します。さらに、工程ごとに担当者と期限を記録します。資料や承認者、例外処理も、あわせて書き留めておきます。

  • 開催前:年間計画、日程調整、議案受付、資料作成、招集通知、出席確認、資料配信
  • 開催中:アジェンダ、決議、発言メモ、出席者、審議時間
  • 開催後:議事録案の確認、電子署名、保管、検索、実効性評価

たとえば、開催直前に資料を差し替える場合は、旧版を閲覧できるかを決めておきます。あわせて、差し替えの承認者と既読状態をリセットするかも定めます。

こうした例外をRFPに入れておくと、デモでは見えにくい実務上の差を各社で比べられます。

MUST・SHOULD・WANTによる機能要件の優先順位付け

機能要件はMUST・SHOULD・WANTに分けます。追加候補は、課題と効果を見て優先順位を決めます。

MUSTには、取締役会の基本業務を支える機能を次のように置きます。

  • MUST:必ず必要な機能として指定する
  • SHOULD:できれば必要な機能として指定する
  • WANT:将来検討する機能として分ける
  • MUST例:会議体、役割、議案、資料版、閲覧、コメント、通知、議事録、承認、署名、検索、ログ
  • 追加候補:AI文字起こし、会議分析、グループ会社横断管理は課題と効果で優先度を決める

認証まわりでは、SSOやMFA、IP制限を整理します。さらに、端末制御と暗号化も条件に含めます。

復旧に関しては、バックアップと復旧目標を整理します。稼働時間とサポート時間、保管地域、ログ保存期間も、条件として書き出します。その条件は、数値や具体的な内容で示します。

IPAは2026年3月、中小企業向け情報セキュリティ対策ガイドライン第4.0版を公開しました。「バックアップを取ろう」を含む情報セキュリティ6か条へ改訂しています(出典: IPA、2026年3月27日)。そのため、RFPにもバックアップと復旧確認を記載します。

会社法上の記録と社内の証跡は、分けて確認します。この記事は一般的な整理であり、個別の法的判断に代わるものではありません。取締役会の決議や議事録に関わる条文は、会社法の369条から371条です。

  • 会社法369条:取締役会の決議と議事録
  • 会社法370条:決議の省略
  • 会社法371条:議事録などの備置

e-Gov法令検索では、取締役会設置会社は取締役会の日から10年間、議事録を本店に備え置くと示されています(出典: e-Gov法令検索「会社法」第369条・第370条・第371条、2026年8月確認)。

電子記録での署名・記名押印に代わる措置や、書面決議の同意記録を確認します。また、オンライン登記で使えるかも、サービスの宣伝文だけで判断せず確かめます。

自社の機関設計と定款は、法務担当者や専門家に確認します。議事録の様式と署名方式も、あわせて確かめます。確認結果は、RFPの要件と受入テストに反映します。

RFPの提案・見積・体制・運用の回答欄

提案と見積の回答欄では、各社の前提と費用の範囲をそろえておきます。RFPでは、次の内容を共通の条件として回答してもらいます。

  • 提案範囲:会社概要、実績、標準機能と追加開発の境界、導入期間、発注側の作業
  • 費用:初期、月額・保守、移行、研修、署名・AIの従量費
  • 見積条件:ユーザー、会議体、会社、資料容量、移行年数

提案書には、要件を満たさない項目と代替案も書いてもらいます。たとえば、自動要約はできても正式記録へ自動で確定しないことや、子会社管理は追加オプションになることといった差が、追加費用を左右します。

回答期限と質疑の方法は、先に共有しておきます。デモの評価者と最終的な選定基準も共有しておくと、営業説明の印象だけでは決めにくくなります。

ポイント

業務の例外処理までRFPに入れておくと、デモでは見えにくい実務上の差を各社で比べられます。例外の洗い出しが足りないまま提案を依頼すると、差が見えないまま選ぶことになりかねません。

契約形態(請負・準委任・SaaS利用)の使い分け

請負契約、準委任契約、SaaS利用契約について、それぞれの確認事項を3枚のパネルで示した図
完成範囲、変化する要件、サービス運用のどこを担うかで確認項目が分かれます。

契約形態は、成果物を定義できるか、要件が変わりそうか、運用を誰が担うかで選びます。契約書の名前だけでは判断できないため、中身を確かめることが大切です。

契約書では、成果物、担当範囲、検収、変更手続きを確認します。さらに、知的財産や機密保持、個人情報の扱いも確かめます。障害対応と終了時のデータ返却も、契約前に押さえておきます。

請負契約の完成範囲と検収条件

請負契約は、成果物を完成させて発注側が検収する開発に向いています。まず、完成範囲を明確にします。

成果物と検収では、次の範囲と業務シナリオを確認します。

  • 成果物:画面、API、帳票、権限、ログ、テスト仕様書、操作マニュアル
  • 検収シナリオ:閲覧権限、署名者変更、議事録差し戻し、会議延期

要件が固まる前に全工程を請負にすると、追加の要件が変更契約になりやすくなります。そのため、前提条件、対象外、追加費用の条件をRFPで確認します。

検収日と不具合修正の扱いを決めておきます。また、法務や役員の確認期限も計画に入れ、発注側の遅れが開発会社だけの責任にならないようにします。

要件整理や継続改善に向く準委任契約

準委任契約は、専門家が一定期間、合意した業務を行う形態です。成果物の完成を一括で保証する契約とは、性質が異なります。

準委任では、次の業務と管理項目を契約で定めます。

  • 活用場面:要件整理、設計、開発支援、プロジェクト管理、SaaS比較、自社運用整理
  • 開発対象:要件が変化しやすいMVP
  • 契約項目:作業範囲、担当者、稼働時間、報告、成果確認
  • 進行管理:優先順位が決まらないと作業が増えるため、週次会議、課題表、意思決定ログ、未確定事項の期限を設け、MUST機能を先に完成させる
  • 発注側の役割:優先順位を決める責任者と事務局責任者を置く

SaaS利用契約のサービス水準とデータの扱い

専用SaaSでは、利用規約とサービス仕様を確認します。さらに、サービスレベル、サポート条件、個人情報の扱いも押さえます。これらは、開発請負の見積とは別に確かめる必要があります。

料金、サービス水準、データ管理では、次の条件を確認します。

  • 利用料金:ユーザー、会議体、容量、署名数、AI利用量、管理者数と追加料金単位
  • サービス水準:障害連絡、復旧目標、保守通知、脆弱性対応の責任分担
  • データ管理:保管場所、委託先、バックアップ、暗号化、ログ、退会後の消去、出力形式
  • AI利用:学習利用、第三者基盤への送信、誤変換の校正者、正式記録の責任

機密性の高い取締役会資料を扱うなら、サービス水準の確認は欠かせません。

契約書に入れる追加開発・知財・終了時の条件

契約条件は、仕様変更と契約終了の両方を想定して整理します。契約書には、次の項目を具体的に記載します。

  • 追加開発:単価、見積承認の手順、仕様変更の影響
  • 知的財産:著作権、ソースコード、設計書、テスト・議事録データの帰属と利用許諾
  • 共通部品:発注側の利用範囲と契約終了後の継続利用
  • 終了時:データ返却・形式、移行支援、消去証明、アカウント停止、未払費用

これらは、価格だけでは見えにくい比較項目です。特に、取締役会の記録を長く扱う発注では、確認が欠かせません。

ポイント

成果物を定義できるか、要件が変わりそうかで請負か準委任かを分け、運用を誰が担うかも合わせて判断します。SaaSを使う場合は、サービス水準とデータの扱いを契約で押さえる必要があります。

取締役会管理システムの費用相場とコストの内訳

電子署名・保管からフル開発まで、導入形態ごとの初期費用概算を5本の横棒で比較した図
導入範囲が広がるほど、初期費用の想定レンジも大きく変わります。

専用SaaSは公開価格が限られており、ユーザー数、会議体、会社数によって見積が変わります。加えて、セキュリティや導入支援、署名・AIの利用量でも金額が動きます。

次の金額は、リサーチノートの公開価格と、ERP・基幹システムの類似案件から整理した概算です。市場全体の公表価格ではなく、予算の初期仮説として使います。

正式な発注額は、RFP後の提案見積で確定します。概算を確定価格として扱わないよう注意します。

電子署名・保管だけの費用目安(初期0〜30万円程度)

電子署名・保管だけを切り出す場合は、対象業務と費用の目安を照らし合わせて考えます。

  • 対象業務:議事録のアップロード、承認、電子署名、保管
  • 概算:初期0〜30万円程度、月額0〜5万円程度に署名従量費を加算
  • 公開価格:WAN-Signの認印版署名は1件100円(税抜)(出典: WAN-Sign公式、2026年8月確認)

この金額は、取締役会全体をまとめて管理する場合ではなく、小さく電子化する場合の推定です。

初期設定や利用者登録、電子証明書、実印版が加わる場合があります。保管容量、サポート、資料移行も、追加になることがあります。公開単価に含まれる範囲も、あわせて確認しておきます。

見積では、対象に含まれない機能や追加費用も確かめます。

小規模クラウドの費用目安(初期0〜200万円、月額5〜30万円程度)

規模別の費用を比べると、自社の導入範囲に近い予算の見当をつけられます。

  • 10〜50ユーザー:初期0〜200万円程度、月額5〜30万円程度。資料共有、議案、承認、議事録、署名を利用
  • 中堅企業向け:初期100〜500万円程度、月額20〜100万円程度。SSO・MFA、複数会議体、資料移行、役員研修を含むケース
  • 価格の位置づけ:統一された市場価格ではなく、機能と導入支援から整理した概算

問い合わせ制のサービスでは、ユーザー課金か会議体課金かを確認します。あわせて、閲覧専用の社外役員や子会社を追加する場合の料金も質問します。

署名やAIの従量課金、最低利用期間、解約費用も確認します。月額だけでなく、初期設定や移行、研修、保守の費用も含め、3年分の総額で比べます。

スクラッチMVP(500〜1,500万円)とフル開発(1,500〜4,000万円以上)の費用目安

開発範囲によって費用の幅が大きく変わるため、MVPとフル開発を分けて見積もります。

  • MVP:議案、資料、ワークフロー、議事録、署名連携に絞り500〜1,500万円程度
  • フル開発:グループ管理、基幹・認証連携、権限、ログ、AI、分析、長期保管を含み1,500〜4,000万円以上
  • 類似案件:人件費と保守費の参考値

類似案件では、エンジニアの月額が80〜120万円程度、保守費は初期費用の年5〜15%程度が参考値です。

出典は、取締役会管理システムのNotebookLMリサーチノート(2026年8月整理)です。

費用は画面数よりも、工数の積み重ねで決まります。要件定義から開発・テストまでの工数に加えて、セキュリティ審査や移行、研修、運用設計の工数も含まれます。

要件が未確定のまま全部入りの請負契約を結ぶよりも、準委任で要件整理を行う方法があります。MVPを定めてから開発請負へ移れば、予算と責任範囲を一段ずつ確かめられます。

初期費用・運用費・移行費の分け方

見積と総保有コストは、初期、運用、将来の各費用に分けて確認します。見積書でも、導入時の費用と継続利用費、将来発生する費用を分けて書いてもらうと、比べやすくなります。

  • 初期費用:要件定義、設計、開発、テスト、クラウド、診断、移行、研修、初回会議支援
  • 運用費:利用料、基盤、監視、バックアップ、保守、問い合わせ、法改正対応、署名・AI従量費
  • 一式表記:作業内容、回数、時間、対象外を質問する
  • 将来費用:役員、ユーザー、会議体、子会社、容量の変更と退会時返却を想定する
  • 料金条件:初年度と3年・5年総額を比べる。期間やオプションで総額が逆転するため、条件をそろえる

ポイント

費用は導入範囲と見積条件で大きく変わるため、ここでの数字は予算の仮説とし、正式な金額はRFP後の見積で確定させます。

委託先の選定と見積比較での確認項目

委託先は、事務局業務への理解、機密資料のセキュリティ、導入後の定着支援で選びます。知名度や見積総額は、判断材料の一つにとどめます。

専用SaaS、電子署名、受託開発では得意な領域が異なります。そのため、質問票は共通のものを使いつつ、発注形態に合わせて評価軸を設定します。

取締役会・経営会議・機密文書の実績

実績は、取締役会業務の経験と、導入後の効果に分けて確認します。

  • 会議体の経験:取締役会、監査役会、経営会議、委員会、書面決議
  • 運用経験:社外役員を含む権限設計、議事録の承認・署名
  • 匿名事例:会社規模、会議体数、利用者数、期間、移行量、セキュリティ審査
  • 効果測定:公表値と自社検証を分け、通知や閲覧確認の時間、承認期間、ミス、問い合わせを測る
  • 実効性評価:導入後も議題設計や役員教育と組み合わせる

デモとPoCでの社外取締役の操作確認

デモとPoCでは、実際の資料に近いサンプルで、操作と例外時の対応を確認します。評価には、関係者の視点と、次の確認項目を含めます。

  • 評価者:事務局、取締役、監査役、社外取締役、法務、情報システム
  • 基本操作:通知、議案差し替え、役員別閲覧、コメント、会議メモ
  • 記録操作:議事録案、承認、署名、検索、データ出力
  • 利用環境:スマートフォン・タブレットの可読性、通知メール、低頻度利用者の再ログイン
  • 例外・評価:延期、版違い、再通知、署名者交代、退任、誤登録、AI誤変換を試し、管理操作・履歴確認者・MUST達成度を記録

見積比較の前提・範囲・将来費用

見積は、条件と将来費用を同じ基準で比べます。そのため、各社の見積前提をそろえておきます。追加が発生したときの負担まで、同じ条件で比べるのが基本です。

  • 共通条件:ユーザー、会議体、会社、容量、移行対象、導入日、連携対象
  • 見積内訳:「一式」の作業、工数、成果物、対象外と価格差の理由
  • 追加費用:3年・5年総額と追加単価、ユーザー10人、会議体、資料1年分、AI利用量の追加
  • 契約終了:データ出力費用と、終了時に発生する費用を確認する

契約後の費用と、どこまでを誰が受け持つかを明確にしておくと、発注時のリスクを下げられます。

セキュリティ・サポート・事業継続の確認項目

機密資料を安全に扱い、利用を続けられる体制かどうかは、次の観点で確認します。

  • 情報保護:未公表業績、M&A、人事、訴訟、資本政策に対するMFA、SSO、IP制限、端末制御、暗号化
  • 継続性:脆弱性診断、アクセス・管理者ログ、バックアップ、復旧訓練、再委託先、証明書・報告書
  • サポート:受付時間、役員対応、初回会議の立ち会い、マニュアル更新、変更通知、障害連絡
  • 引き継ぎ:納品後に保守しない場合は、別会社へ渡せる設計書と運用手順を受け取る

ポイント

委託先は、取締役会業務の経験や機密資料の守り方を、知名度や見積総額より先に見て決めます。質問票は共通にし、評価軸だけを発注形態に合わせて変えます。

取締役会管理システムの発注・外注でよくある質問

発注前によく聞かれる質問を取り上げます。機能や価格だけでなく、法務や事務局、情報システムの確認事項も見ておきます。役員の利用体験や社内の責任分担も、あわせて確かめておくと、発注後の手戻りを減らせます。

取締役会管理システムの発注でRFPは必要ですか?

複数社の提案や見積を比べるなら、簡易なRFPでも用意します。そこには、対象業務、利用者、会議体、必須機能を書き込みます。加えて、セキュリティや導入時期、見積内訳、対象外もそろえておきます。

RFPがあれば、会社ごとの前提がそろい、提案を同じ条件で並べて見られます。小規模な署名・保管でも、範囲を1枚にまとめておけば、追加費用を抑えやすくなります。

専用SaaSとスクラッチ開発はどちらが安いですか?

標準機能で足りる場合、専用SaaSは初期費用と導入期間を抑えやすい傾向にあります。一方、独自開発は初期費用と保守の負担が大きくなりやすいです。

既存の認証基盤や文書管理を使える場合や、開発範囲をMVPに絞る場合は、この差が変わります。比べるときは、3年または5年の総額と、業務を標準に合わせる負担を見ます。

電子署名を導入しても、会社法や定款、社内規程の確認がすべて済むわけではありません。議事録の記載や保管方法も、別に確かめる必要があります。

会社法369条から371条と関係する法務省令を確認し、自社の機関設計と電子記録の方式に合うかを、法務担当者や専門家に確かめます。

システムは、承認や署名の記録を残す仕組みとして活用します。残す内容は、日時、版、操作履歴などです。

AI議事録を発注要件に入れるとき何を確認しますか?

AI議事録では、音声の保管場所や、AIへの送信先、学習利用の有無を確認します。機密情報の扱いと削除方法も、あわせて確かめます。さらに、誤変換の校正者と正式記録の確定者も決めておきます。

要約や文字起こしは、下書きの補助として扱います。そのうえで、人が音声や発言メモと照合して議事録を承認する運用を、RFPと受入テストに含めます。

誤りが残った場合の責任と訂正手順も決めておきます。便利さだけでなく、正式記録としての扱いも確認します。

まとめ

発注では、署名・保管だけに絞るか、議案・資料・承認・実効性評価まで扱うか、独自開発で既存システムと連携するかを決めます。

次に、業務を洗い出して、MUST・SHOULD・WANTに分けます。RFPでは、利用者や会議体、セキュリティから見積条件までをそろえます。

発注での要件・契約・見積の前提のそろえ方

要件定義や継続改善には準委任、完成物を求める場合には請負、標準機能を継続して使う場合にはSaaS契約を使い分けます。

電子署名・保管は初期0〜30万円程度、専用クラウドは初期0〜500万円程度が目安です。さらに、スクラッチはMVPで500〜1,500万円程度、フル開発で1,500〜4,000万円以上です。

これらは公開価格と類似案件から整理した概算で、正式な金額ではありません。RFP後に各社の条件をそろえて見積を取ります。

最初の一歩は現行業務の棚卸しとRFPの作成

まず直近の取締役会を選び、資料配信から議事録保管までの作業を洗い出します。

  1. 担当者、所要時間、困りごとも記録してRFPにまとめる
  2. 実績、社外役員の操作性、セキュリティ、導入支援、障害対応、データ返却を確認する
  3. 複数社のデモとPoCで要件を確かめ、発注後の手戻りを減らす

▼全体ガイドの記事
・取締役会管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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