ポータルサイトシステム開発の発注/外注/依頼/委託方法について

ポータルサイトシステムの発注・外注では、製品名や開発会社の知名度だけで決めず、利用者、業務範囲、既存システムとの連携、運用体制を先に整理して比較することが重要です。発注方式を適切に選び、要件と見積の前提をそろえることで、初期費用の膨張や「作ったのに使われない」という失敗を避けやすくなります。

この記事では、ポータルサイトシステムを発注・外注するときの進め方を、SaaSや既存グループウェアの活用、ポータル基盤製品、ローコード、スクラッチ開発の選択から解説します。RFPに入れる項目、請負契約と準委任契約の使い分け、2026年時点での費用レンジ、委託先と見積書を比べるポイントまで、社内ポータル・顧客ポータル・取引先ポータルに共通する実務へ落とし込みます。

▼全体ガイドの記事
・ポータルサイトシステム開発の完全ガイド

ポータルサイトシステムはどの発注方式が適していますか?

ポータルサイトシステムの発注方式を検討する担当者

発注方式は、利用者の範囲と業務の独自性で決めることが基本です。情報共有が中心で既存のMicrosoft 365やグループウェアを使える場合は設定・導入支援から始めやすく、会員管理、受発注、複雑な権限、基幹システム連携が中心の場合は、ポータル基盤や個別開発を含めた外注が適しています。

最初に目的と対象ユーザーを分けて整理します

ポータルサイトシステムは、社内ポータル、顧客・会員ポータル、代理店・取引先ポータル、自治体や学校の利用者ポータルなどで必要な設計が変わります。社内ポータルなら、規程やマニュアルを検索し、勤怠・経費・人事申請へ移動できることが主な価値です。一方、取引先ポータルなら、契約先ごとの価格や在庫、注文履歴、問い合わせ状況を安全に表示し、相手が自分で手続きを完了できることが価値になります。

発注前には「誰の、どの作業を、何分短縮するのか」を一文にします。たとえば「営業300名が複数の共有フォルダを探す時間を減らし、申請状況を自分で確認できるようにする」なら、検索、権限、申請、通知が優先機能になります。問い合わせ件数、検索にかかる時間、申請処理日数、月間ログイン率など、稼働後に測る指標もこの段階で仮置きすると、開発会社から機能を過剰提案されにくくなります。

SaaS・基盤製品・スクラッチを要件で使い分けます

選択肢は大きく4つあります。既存のグループウェアやSaaSを設定して使う方法は、短期間で始めやすく、サーバー保守を抑えやすい方式です。ポータル基盤製品を導入する方法は、組織・会員・取引先ごとの権限や複数サイトを整えやすく、標準機能を使いながら拡張できます。ローコードとAPIを組み合わせる方法は、業務アプリや申請を小さく作りやすく、全面スクラッチは独自業務を自由に設計できる反面、保守と脆弱性対応を長期に負担します。

Microsoft 365をすでに契約している企業ならSharePointとEntra ID、Teamsなどを組み合わせる案を、社内の申請や掲示板を短期間で統合したい企業ならGaroonやdesknet’s NEOなどを候補にします。大規模な従業員セルフサービスや複数部門のワークフローを統合する場合はServiceNow、顧客・パートナー向けの複数ポータルやBtoB取引まで視野に入れる場合はLiferayのような基盤も候補になります。ただし、製品名ではなく、必要な権限・API・移行・運用が標準機能でどこまで満たせるかを確認して発注します。

発注前にRFPと要件を整理する方法

RFPと要件を整理するポータルサイトシステム担当者

RFPは、開発会社へ「何を、どの条件で提案してほしいか」を伝える依頼書です。機能一覧だけを渡すのではなく、背景、対象ユーザー、現行の課題、優先順位、連携先、データ移行、セキュリティ、納期、保守範囲を同じ資料にまとめます。RFPの粒度がそろうほど各社の見積条件が近づき、安い会社ではなく、前提が抜けて安く見える会社を選ぶリスクを減らせます。

現状の情報源とKPIを棚卸しします

まず、情報がどこに存在するかを一覧にします。共有フォルダ、Excel、メール、Teamsやチャット、既存CMS、勤怠・経費・ERP・CRMなどを、管理部門、営業、現場、顧客といった利用者別に整理します。各情報について、更新担当者、公開範囲、保存期限、正本の場所、検索に使う語句を確認します。古いファイルや重複した規程をそのまま移行すると、ポータルを作っても検索結果が増えるだけなので、移行前の廃棄・統合・保管ルールもRFPに含めます。

KPIは「導入すること」ではなく、業務の変化で置きます。たとえば、問い合わせ件数を月何件減らすか、必要な文書へ到達する平均時間を何分から何分にするか、申請の差し戻し率を何%下げるかを定めます。利用率だけを追うと、ログインしただけの利用者を成功と誤認するため、検索後の閲覧、申請完了、問い合わせ自己解決などの行動も測定対象にします。

ユーザー・権限・連携を具体的な表にします

権限要件は「管理者」「一般ユーザー」の2種類だけで終わらせないことが大切です。部門、役職、雇用区分、契約先、会員ランク、担当案件など、誰が何を見られ、何を登録・承認できるかを権限マトリクスにします。異動、退職、契約終了、委託先の担当者変更が起きたときに、どのマスタを更新し、何分以内にアクセスを止めるかも決めます。SSO、SAMLやOIDC、MFA、IP制限、監査ログの保管期間まで書くと、提案の比較が具体的になります。

連携は、連携先の名前だけではなく、方向、データ項目、頻度、失敗時の扱いを記載します。たとえば、基幹システムから顧客名・契約状況を1日数回取り込むのか、ポータルから受注情報を即時送信するのかで設計と費用が変わります。APIがないシステムではCSV連携やRPAを採用する可能性もあるため、追加費用が発生する条件、テスト用データの準備者、障害時の再送方法をRFPで指定します。

移行・安全性・運用の責任分界を決めます

データ移行では、件数だけでなく、ファイル形式、文字コード、作成者、更新日、タグ、公開期限、既存URL、権限を確認します。移行対象を「すべて」と書くと、不要な資料の整理まで開発会社の作業になり、見積が膨らみます。対象リスト、除外条件、クレンジングの担当、受け入れ確認の方法を分けて記載し、サンプルデータで移行テストを行います。

安全性では、入力値検証、XSSやSQLインジェクション対策、セッション管理、バックアップ、脆弱性診断、ログ監視、障害時の復旧目標を要件化します。IPAの「中小企業の情報セキュリティ対策ガイドライン 第4.0版」でも、Webサイトの安全な運用やバックアップ、外部委託先を含む管理が扱われています。社外向けポータルや申請を受け付けるシステムでは、デジタル庁の2025年「ウェブアクセシビリティ導入ガイドブック」も参照し、キーボード操作、読み上げ順、コントラスト、スマートフォン表示を受入条件に含めます。

契約形態は請負と準委任のどちらを選ぶべきですか?

契約形態を比較するポータルサイトシステムの発注担当者

要件が固まり、完成物と検収条件を明確にできる工程は請負契約が向いています。一方、調査、要件定義、PoC、既存データの棚卸しなど、作業内容を進めながら確定する工程は準委任契約で専門家の稼働を確保しやすくなります。ポータルサイトシステムは、利用者の声を聞くと要件が変わりやすいため、全工程を一つの契約に押し込めず、工程ごとに契約と成果物を設計する方法が現実的です。

完成責任を求める工程は請負にします

請負では、合意した仕様のシステムを納期までに完成させ、検収を受けることが契約の中心になります。画面一覧、機能仕様、権限、連携仕様、テスト項目、納品物、検収期限、瑕疵や不具合の対応を契約書と仕様書で結び付けます。ポータルのトップ画面だけでなく、異動・退職、権限変更、連携エラー、バックアップからの復元といった例外ケースを検収項目に入れないと、稼働後に問題が発覚しやすくなります。

請負契約で注意したいのは、要件変更が追加費用になりやすい点です。「使いやすくする」「必要に応じて連携する」のような曖昧な表現を残さず、対象範囲外の作業、変更依頼の受付方法、影響見積、承認者、納期変更の扱いを決めます。開発会社に一方的な完成責任を求めるのではなく、発注側が確認用データや業務ルールをいつ提供するかも責任分界表にします。

不確実性が高い工程は準委任で段階的に進めます

準委任では、一定の業務を専門家が遂行することが中心で、作業時間や体制に応じて精算する契約が一般的です。現場ヒアリング、業務フロー整理、技術検証、標準機能とカスタマイズの切り分け、PoCなどに適しています。たとえば、最初の1〜2か月を準委任で調査し、その成果物として要件定義書、権限マトリクス、連携一覧、概算見積、優先順位を作り、その後の開発を請負または別の準委任で契約する方法があります。

準委任を選ぶ場合は、成果物が曖昧にならないようにします。月次の稼働報告、会議体、課題一覧、意思決定の期限、レビューの回数、時間単価や月額、超過時の扱い、担当者の交代条件を明記します。請負と準委任のどちらが安いかだけでなく、要件変更を吸収する柔軟性と、完成状態を検証する方法を比べることが、発注後のトラブルを抑えるポイントです。

ポータルサイトシステムの費用相場と見積の見方

ポータルサイトシステムの費用見積を確認する担当者

費用は、ライセンスやクラウド利用料と、要件定義・設計・開発・移行・教育・保守の費用を分けて考えます。公開料金がある製品でも、ポータルとして使える状態にする導入支援や既存システム連携は別見積になる場合があります。以下の金額はポータル固有の全国統計ではなく、公開料金と業務システムの人月相場、要件別のプロジェクト規模を組み合わせた概算レンジです。実際の予算はRFPと提案内容で確認します。

ライセンス費用は利用者数と追加機能で試算します

2026年時点で公式料金を確認できる例では、Garoonクラウド版は1ユーザー月額900円、初期費用0円と案内されています。300ユーザーならライセンスだけで月27万円、年324万円が目安です。desknet’s NEOクラウド版はライト600円、スタンダード800円、プレミアム1,000円を1ユーザー月額の税抜料金として案内しており、300ユーザーでは月18万〜30万円の範囲になります(出典: サイボウズ Garoon公式価格表、ネオジャパン desknet’s NEO公式価格表、2026年確認)。

SharePointもプランごとに機能と料金が異なり、既存のMicrosoft 365契約に含まれる範囲と追加契約が必要な範囲を分けて確認します。ライセンスの月額だけで比較すると、SSO設定、サイト設計、権限設計、データ移行、API連携、教育、運用支援が抜けます。見積書では、ユーザー課金、ゲスト課金、ストレージ、追加アプリ、認証、バックアップ、サポートの単位と増額条件を確認します。

要件別の初期費用は幅を持って見積もります

小規模な社内ポータルで、利用者50〜100名、既存クラウド、テンプレート中心、連携が少数なら、初期費用は50万〜300万円、期間は1〜3か月程度が一つの概算レンジです。標準的な社内ポータルで、利用者100〜500名、SSO、部門別ページ、検索、申請・問い合わせ、既存データ移行まで含める場合は、初期300万〜1,000万円、期間3〜6か月程度を見込みます。これらは要件別の推定であり、製品価格だけを示すものではありません。

顧客・会員・取引先ポータルで、外部公開、個人情報、会員管理、決済・受発注・CRM連携を含める場合は、初期800万〜2,000万円、期間4〜9か月程度が概算の目安です。複数組織、複数システム、監査、冗長化、大量移行、複雑なワークフローを含む大企業・自治体向けでは、1,000万〜3,000万円以上、6〜12か月以上になる可能性があります。独自業務を全面的にスクラッチ開発する場合は、1,500万〜4,000万円以上になるケースも考えられますが、これは個別の工数と非機能要件を確認したうえで判断します(出典: NotebookLM業務システム費用・期間Q&A、公開製品料金をもとにした要件別推定、2026年)。

見積書は初期費用・移行費・保守費を分解して読みます

見積書の項目は、要件定義・業務整理、画面と情報設計、環境構築、標準設定、追加開発、API連携、権限設計、テスト、脆弱性診断、データクレンジング、データ移行、マニュアル、教育、リリース支援に分けてもらいます。保守費は、問い合わせ窓口、障害対応、軽微な改修、監視、バックアップ確認、脆弱性対応、定例会のどこまで含むかを確認します。作業一式とだけ書かれた項目は、作業内容と成果物を質問します。

毎月の費用だけでなく、3年間の総保有コストでも比較します。ライセンスの値上げ、ユーザー増加、ストレージ追加、外部認証、バックアップ容量、保守契約、契約終了時のデータ返却、将来の追加連携まで含めると、初期費用が低い提案の別の負担が見えることがあります。請負は準委任より見積が高く見えやすいという指摘もありますが、責任範囲と変更吸収の仕組みが違うため、金額だけで優劣を決めないことが大切です。

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

開発会社の見積と実績を比較する発注担当者

委託先は、会社規模や製品の知名度だけでなく、今回のポータルを最後まで運用できる体制で選びます。社内向けの情報共有に強い会社と、顧客・取引先の認証や受発注に強い会社では得意領域が異なります。提案時の営業担当だけでなく、要件定義、設計、移行、テスト、運用保守を担当するメンバーと、障害時の連絡経路まで確認します。

似た利用者規模と業務の実績を確認します

実績を見るときは「ポータルを作った」という表現だけで判断しません。社内か社外か、利用者は何人か、組織や契約先はいくつか、どのシステムと連携したか、何か月で公開したか、移行件数と運用体制はどうだったかを質問します。たとえば、コニカミノルタジャパンのSharePoint社内ポータル事例では、約300名の企業で部門別情報、経営メッセージ、勤怠・経費リンク、ナレッジ、問い合わせ窓口を約3か月で整備したと紹介されています。自社の規模や目的との近さを確認する材料になります。

Liferayの公式事例には、国際貨物予約、顧客・パートナー向け統合ポータル、複数ポータルの統合などが掲載されています。ServiceNowのサービスポータルは、従業員がさまざまなデバイスからアプリやセルフサービスへアクセスする基盤として案内されています。こうした事例は製品の適合性を考える参考になりますが、同じ結果が自社で再現されるとは限りません。導入企業名の確認だけでなく、実際の構築担当、利用した機能、追加開発、保守窓口を提案会社へ確認します(出典: コニカミノルタ、Liferay、ServiceNowの公式事例・製品情報、2026年確認)。

見積比較は価格・範囲・前提を同じ表で比べます

相見積もりでは、同じRFPを2〜4社程度へ渡し、回答期限、質問の方法、提案に含める項目をそろえます。比較表には、初期費用、月額・年額、3年総額、要件定義、標準機能、個別開発、連携、移行、テスト、教育、保守、納期、発注側の作業を並べます。金額が安い会社の提案に移行やセキュリティ診断が含まれていないなら、同じ条件で再見積もりを依頼します。

評価配点を先に決めると、価格だけの競争になりにくくなります。要件理解と提案の具体性を25点、既存システム連携を25点、移行・運用支援を20点、セキュリティ・権限を15点、見積の透明性を15点とする方法があります。配点は自社の優先順位に合わせて変えますが、各項目で「何ができれば満点か」を記述します。提案書のきれいさより、できないこと、追加費用になること、発注側が担うことを明示しているかを重視します。

公開後の運用とセキュリティの窓口を確認します

ポータルは公開してからのコンテンツ更新で価値が決まります。情報の登録者、承認者、公開期限を設定し、月次または四半期ごとに古い資料、リンク切れ、権限、検索語、利用ログを見直します。開発会社へ運用を委託する場合は、日常の更新代行とシステム保守を分け、軽微な画面修正の回数、問い合わせの受付時間、障害の一次切り分け、定例会、改善提案を契約に書きます。

個人情報や社外秘情報を扱う場合は、MFA、最小権限、管理者操作のログ、退職・契約終了時のアカウント停止、バックアップの暗号化、復元テスト、脆弱性情報への対応期限を確認します。外注先が再委託する場合は、再委託先の範囲と審査方法、データを保管する地域、契約終了時の削除証跡も質問します。社外向けの画面では、JIS X 8341-3:2016やWCAG 2.2を意識したアクセシビリティの試験方法を、検収時の証跡として残します。

よくある質問

ポータルサイトシステムの発注に関するよくある質問

ポータルサイトシステムの発注では、費用だけでなく、方式、契約、データ、運用の境界で疑問が生まれます。ここでは、初回相談や相見積もりの前に確認されやすい質問へ、判断の軸を直接回答します。

ポータルサイトシステムの発注は何社に相談すればよいですか?

最初は2〜4社程度へ同じRFPを渡すと、提案の違いと費用の前提を比較しやすくなります。社内ポータルに強い会社、利用中の製品に強い公式パートナー、顧客・取引先ポータルに強い会社など、得意領域の異なる候補を混ぜると、自社に合う方式を見つけやすくなります。候補数を増やしすぎると質問対応と評価に時間がかかるため、実績・連携・運用体制で事前に絞ります。

ポータルサイトシステムは無料のツールだけで作れますか?

情報の掲載やリンク集だけなら、既存のグループウェアやクラウドの標準機能で始められる可能性があります。ただし、利用者別の権限、SSO、申請、会員情報、基幹システム連携、監査ログ、バックアップ、運用教育まで求めると、設定・開発・保守の費用が発生します。無料かどうかではなく、必要な業務を安全に継続できる総費用と、使えない機能を追加開発する費用で判断します。

発注前に決めきれない要件があっても相談できますか?

相談できます。決めきれない点を隠して機能を断定するより、未確定事項、選択肢、判断期限をRFPに書き、要件定義やPoCの進め方を提案してもらう方が安全です。調査・要件整理は準委任、仕様確定後の開発は請負というように段階を分けると、要件変更の影響を抑えながら発注できます。

外注後に自社で準備すべきことは何ですか?

発注側には、業務ルールと情報の正本を決める役割があります。各部門の代表ユーザー、最終決裁者、コンテンツ更新者、権限管理者、データ提供者を定め、会議やレビューに参加させます。開発会社へ任せきりにすると、技術的には完成しても、掲載内容が古い、誰も承認できない、異動後も権限が残るといった運用上の問題が起こります。

まとめ

ポータルサイトシステムの発注準備を終えた担当者

ポータルサイトシステムの発注・外注は、最初から開発会社や製品を決めるのではなく、目的、対象ユーザー、情報の範囲、連携、権限、運用を整理してから方式を選ぶことが成功の近道です。SaaSや既存グループウェアで足りる範囲、ポータル基盤が必要な範囲、個別開発にする範囲を分けると、必要な投資と将来の保守負担を見通しやすくなります。

発注前にそろえるべき5つの情報

発注前には、(1)達成したい業務成果とKPI、(2)利用者・権限・認証の一覧、(3)連携先とデータ項目、(4)移行対象と運用責任者、(5)初期費用・月額費用・保守費用の予算枠をそろえます。RFPでは、できることだけでなく、未確定事項と提案してほしい選択肢も明示します。これにより、各社の提案を同じ土俵で比較できます。

次に行うことはRFP作成と候補会社への相談です

候補会社へ相談するときは、費用の安さだけでなく、要件定義から移行・運用まで伴走できるか、追加費用の境界を説明できるか、同規模・同用途の実績があるかを確認します。最初から全機能を作り込まず、優先度の高い検索・権限・申請などを小さく検証し、利用ログと現場の声をもとに拡張する進め方も有効です。ポータルサイトシステムを業務の入口として定着させるために、開発会社と自社の責任を契約と運用ルールへ落とし込んでください。

▼全体ガイドの記事
・ポータルサイトシステム開発の完全ガイド

会社紹介

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

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

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

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

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

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