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

ポータルサイトシステムの発注は、目的と利用者を整理し、要件と見積の条件をそろえ、契約と委託先を選ぶ順に進めます。この順で進めると、費用が膨らみすぎたり、使われないシステムになったりすることを避けやすくなります。

全体像を先に知りたい場合は、ポータルサイトシステム開発の完全ガイドもご覧ください。

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

Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

ポータルサイトシステムの発注方式の選び方

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

目的と対象ユーザーの整理

ポータルは利用者によって必要な設計が変わるため、利用者別に主な価値を整理しておきます。

• 対象利用者：社内、顧客・会員、代理店・取引先、自治体や学校。
• 社内ポータル：規程・マニュアルを検索し、勤怠・経費・人事申請へ移動できます。
• 取引先ポータル：契約先ごとの価格・在庫・注文履歴・問い合わせ状況を安全に表示し、手続きを完了できます。

発注前には、「誰の、どの作業を、何分短縮するのか」を一文にまとめておきます。たとえば、営業300名の共有フォルダ検索を減らし、申請状況を自分で確認できるようにする場合は、検索・権限・申請・通知が優先機能になります。

稼働後に測る指標も、問い合わせ件数、検索時間、申請処理日数、月間ログイン率などで仮に置いておきます。指標があると、開発会社から過剰な機能を提案された際に、その必要性を照らし合わせやすくなります。

SaaS・基盤製品・スクラッチの使い分け

選択肢は4つあり、利用者と業務の独自性に照らして、必要な権限や連携を標準機能で満たせるかを確認します。

• グループウェア・SaaS：短期間で始めやすく、サーバー保守を抑えやすい方式です。
• ポータル基盤製品：組織・会員・取引先の権限や複数サイトを整えやすく、拡張できます。
• ローコードとAPI：業務アプリや申請を小さく作りやすい方法です。
• スクラッチ開発：独自業務を自由に設計できますが、保守と脆弱性対応が長期負担になります。

Microsoft 365を契約済みなら、SharePoint、Entra ID、Teamsの組み合わせが候補になります。申請や掲示板を短期間で統合する場合は、Garoonやdesknet’s NEOも候補です。

従業員向けのセルフサービスや部門をまたぐワークフローならServiceNow、顧客・パートナー向けの複数ポータルやBtoB取引ならLiferayのような基盤も候補になります。

製品名だけで決めず、必要な権限・API・移行・運用を標準機能でどこまで満たせるかを確かめてから発注します。

発注前のRFPと要件の整理

RFPは、開発会社に「何を、どの条件で提案してほしいか」を伝える依頼書です。RFPには、背景、対象者、現行課題、優先順位を機能一覧と合わせて記載します。

連携先、データ移行、セキュリティ、納期、保守範囲も同じ資料にまとめます。記載の粒度がそろうと見積条件も近づくため、前提が抜けていて安く見える提案を選んでしまうリスクを減らせます。

現状の情報源とKPIの整理

管理部門、営業、現場、顧客の利用者ごとに、どこに情報があるかを洗い出します。対象は、共有フォルダ、Excel、メール、Teamsやチャット、既存CMSです。勤怠・経費などの業務システムやERP、CRMも含めます。

各情報について、更新担当者、公開範囲、保存期限、正本の場所、検索語句を確かめます。古い資料や重複した規程をそのまま移すと検索結果が増えるため、廃棄・統合・保管のルールもRFPに含めます。

KPIは、導入すること自体ではなく、業務がどう変わるかで置きます。次のような目標を定めます。

• 問い合わせ：件数を月何件減らすかを目標にします。
• 文書検索：平均時間を何分から何分にするかを目標にします。
• 申請：差し戻し率を何％下げるかを目標にします。
• 利用行動：検索後の閲覧、申請完了、問い合わせの自己解決を測ります。

利用率だけでは、ログインしただけの利用者を成功と誤って数えてしまいます。

ユーザー・権限・連携の具体的な表

権限要件は、閲覧・登録・承認できる範囲を権限マトリクスにまとめます。管理者と一般ユーザーに加えて、次の属性も整理します。

• 利用者属性：部門、役職、雇用区分、契約先、会員ランク、担当案件。
• 変更時の管理：異動・退職・契約終了・委託先担当者変更時のマスタ更新とアクセス停止時間。
• 認証・記録：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円。300人で月18万〜30万円。
• SharePoint：Microsoft 365契約に含まれる機能と追加契約が必要な範囲を確認します。

金額は2026年時点の案内です（出典：サイボウズ Garoon公式価格表、ネオジャパン desknet’s NEO公式価格表、2026年確認）。

月額だけで比べると、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のサービスポータルは、従業員がさまざまなデバイスからアプリやセルフサービスへアクセスする基盤として案内されています。

ただし、事例は製品適合性の参考で、同じ結果が自社で再現されるとは限りません。そのため、構築担当、利用機能、追加開発、保守窓口も確認します（出典：コニカミノルタ、Liferay、ServiceNowの公式事例・製品情報、2026年確認）。

価格・範囲・前提を同じ表でそろえる見積比較

相見積もりでは、同じRFPを2〜4社程度に渡し、回答期限、質問の方法、提案項目をそろえます。比較表には、次の要素を並べます。

• 費用：初期費用、月額・年額、3年総額。
• 作業範囲：要件定義、標準機能、開発、連携を示します。移行、テスト、教育、保守も、同じ表に並べます。
• 前提：納期、発注側の作業。

移行やセキュリティ診断が抜けた提案は、同条件で再見積もりを依頼します。評価配点を先に決めると、価格だけの競争を避けやすくなります。

配点例は、要件理解・提案が25点、既存連携も25点です。移行・運用支援は20点、セキュリティ・権限と見積透明性は各15点です。自社の優先度に合わせ、満点の条件も記載します。

提案書の見栄えよりも、できないこと、追加費用になること、発注側が担うことを明示しているかを重視します。

公開後の運用とセキュリティの窓口

ポータルの価値は、公開後の更新によって決まります。そのため、運用と委託の条件では次の点を確かめます。

• 更新管理：登録者、承認者、公開期限を定めます。古い資料やリンク切れ、権限、検索語、利用ログは、月次または四半期ごとに確認します。
• 委託範囲：更新代行とシステム保守を分けて記載します。修正回数、問い合わせ時間、障害の一次切り分け、定例会、改善提案も契約に入れます。
• 情報保護：個人情報・社外秘を扱うならMFA、最小権限、管理者ログを確かめます。退職・契約終了時の停止、暗号化バックアップ、復元テスト、脆弱性対応期限も見ます。
• 再委託：委託先の範囲・審査方法、データ保管地域、契約終了時の削除証跡を確認します。

社外向けの画面では、JIS X 8341-3:2016やWCAG 2.2を意識し、アクセシビリティ試験の証跡を検収時に残します。

よくある質問

発注では、方式、契約、データ、運用の境界で疑問が生じやすくなります。ここでは、初回相談や相見積もりの前に確認されやすい質問に、判断の軸を示します。

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

最初は2〜4社に同じRFPを渡すと、提案の違いや費用の前提を比べやすくなります。候補には、社内ポータルに強い会社、利用製品の公式パートナー、顧客・取引先ポータルに強い会社などを含めます。

候補が多すぎると、質問への対応と評価に時間がかかります。そのため、実績、連携、運用体制で事前に絞り込みます。

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

情報掲載やリンク集だけなら、グループウェアやクラウドの標準機能で始められる可能性があります。一方で、権限、SSO、申請、会員情報を求めると、費用が発生します。基幹連携、監査ログ、バックアップ、運用教育まで求めると、さらに費用がかかります。

無料かどうかではなく、必要な業務を安全に続けるための総費用と、不足機能の追加開発費用で判断します。

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

相談できます。未確定の事項や選択肢、判断期限をRFPに書き、要件定義やPoCの進め方を提案してもらいます。機能を無理に断定するより安全です。

調査・要件整理は準委任、仕様が確定した後の開発は請負に分けると、要件変更の影響を抑えながら発注できます。

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

発注側は、業務ルールと情報の正本を決めておきます。そのうえで、部門代表と最終決裁者、コンテンツ更新者、権限管理者、データ提供者を定め、会議やレビューに参加させます。

開発会社に任せきりにすると、掲載情報が古いままになったり、承認者がいなかったり、異動後も権限が残ったりといった運用上の問題が起こります。

まとめ

発注では、開発会社や製品を先に決めず、まず目的と対象者、情報範囲を整理します。そのうえで、連携、権限、運用を整理し、方式を選びます。

SaaSや既存グループウェア、ポータル基盤、個別開発の範囲を分けて考えると、投資と保守負担を見通しやすくなります。

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

発注前にそろえる情報は5つで、まず達成したい業務成果とKPI、利用者と権限・認証の範囲を決めます。次に、連携先とデータ項目、移行対象と運用責任者を書き出します。最後に、予算枠を初期・月額・保守に分けて押さえます。

RFPには、確定事項に加えて、未確定の事項と提案してほしい選択肢も書きます。そうすると、各社の提案を同じ条件で比べられます。

RFP作成と候補会社への相談

候補会社には、要件定義から移行・運用まで対応できるか、追加費用の境界を説明できるか、同規模・同用途の実績があるかを確認します。

優先度の高い検索・権限・申請から小さく検証し、広げていく方法もあります。利用ログと現場の声をもとに拡張し、責任分担を契約と運用ルールに落とし込みます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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