ポータルサイトシステム開発の進め方/やり方/流れや方法/手法/工程/手順

ポータルサイトシステムの開発は、課題と利用者の整理、方式の選定と設計、段階公開と継続改善の順に進めると、業務改善につながります。

全体の流れは6段階で、ポータルの全体像と各段階の進め方、費用と見積の確認点を順に説明します。全体像は、完全ガイドでも確認できます。

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

ポータルサイトシステムの全体像

ポータルサイトの機能を情報管理、利用者対応、認証・統制の3層で示した図
情報の掲載から認証までを機能領域ごとに見渡せます。

ポータルサイトシステムは、情報・検索・申請・問い合わせ・既存システムへの導線を一つにまとめる業務基盤です。

ログインや権限、ワークフロー、データ連携、操作ログも設計の対象になります。

社内・顧客・取引先ごとに異なる必要な仕組み

社内、顧客・会員、取引先では、ポータルで扱う情報と権限の単位が異なります。

  • 社内:通知、規程、マニュアル、FAQ、勤怠・経費へのリンク、申請・承認を一か所に集めます。
  • 顧客・会員:会員情報、契約、問い合わせ、請求書、予約や申込履歴の本人向け表示。
  • 取引先:受発注、納期、在庫、請求、案件情報を企業単位の権限で扱います。

企画書では、「誰が、何を、どの頻度で、どのシステムと使うか」を書き分けます。用途を混ぜると、外部の個人情報に社内向けの簡易な権限を使うといった過不足が生じます。

主要機能の中心は検索・権限・連携

ポータルを業務の入口として広げるには、検索、利用者対応、認証・統制を組み合わせる必要があります。

  • 情報管理:CMSやニュース、文書管理、検索、タグ・カテゴリ、FAQ、アクセス解析。
  • 利用者対応:フォーム、申請・承認、問い合わせ管理、予約、通知。
  • 認証・統制:SSO(SAMLまたはOIDC)、MFA、属性別認可、アカウント停止、監査ログ、バックアップ。

ポータルは、Microsoft 365、Google Workspace、kintone、ERP、CRMを横断する入口にもなり、勤怠・経費、ストレージ、チャットともつながります。

導入効果は、検索時間、問い合わせ件数、申請処理時間で測れます。重複入力や月間利用率も加えると、優先順位を決めやすくなります。

ポイント

判断の目安は、社内・顧客・取引先のどれに向けたポータルかです。利用者ごとに情報と権限を分けて考えると、検索・権限・連携のどこに力を入れるかを決めやすくなります。

ポータルサイトシステム開発の進め方

要件整理から定着までを6段階で進めます。

各工程で仕上げる内容と意思決定者、次へ進む条件を決めておくと、抜け漏れを抑えられ、納期と費用も安定させやすくなります。

1. 要件整理:目的・対象者・業務の定義

まず、解決する業務課題を現状調査で測り、導入後に比べられる数値で置いておきます。たとえば、規程を探す時間を平均10分から3分にするといった目標です。

問い合わせを月100件から60件に減らす目標や、申請の受付から承認までを3営業日から1営業日にする目標も立てられます。要件整理では、利用と情報、管理と連携、表示条件の3点を文書に含めます。

  • 利用と情報:対象ユーザー、利用シーン、情報源、ページ・文書、機能。
  • 管理と連携:権限マトリクス、外部連携、移行対象、運用体制、KPI。
  • 表示条件:部門・役職のほか、雇用区分、契約、取引先、案件参加状況。

発注側は、誰が使い、何を見せ、誰が更新と承認を担うかを決めます。

発注側は、いつ削除するか、障害時にどう連絡するかも詰めておきます。

まだ決まっていない項目は一覧にし、見積の前提条件として残します。

2. 選定:SaaS・基盤製品・ローコード・スクラッチの比較

候補方式は、既存環境を活用できるか、導入を急ぐか、独自業務を実現する必要があるかで絞り込みます。

  • Microsoft 365利用中:SharePointとEntra IDの組み合わせ。
  • 短期導入:Garoonやdesknet’s NEOなどのグループウェア。
  • 高度な統合:LiferayやServiceNowなどの基盤製品。
  • 独自業務が競争力に直結:既存製品で解けない範囲をスクラッチ開発。

候補会社には、同じ用途・規模の実績を聞きます。SSOと権限、移行の経験に加え、API連携や運用引き継ぎ、公開後の改善の経験も確かめます。

製品会社と構築会社が別の場合は、設計・開発・保守のどこまでを誰が受け持つかと、障害時の一次窓口を契約前に決めます。

そのうえで、候補を2〜3方式に絞り、小規模なPoCで比べます。たとえば、PoCでは規程20件の検索、異なる3部門の権限表示、申請1種類の通知と承認履歴を試せます。

現場の操作時間と管理者の負荷も比べておくと、導入後の差を見通せます。

3. 設計・開発:画面だけでなくデータと権限の設計

情報と連携の設計では、基幹システムとの二重入力を防ぐために、データの正本を明確にします。設計項目は、情報・連携・画面の3つに分けて整理します。

  • 情報設計:情報構造、検索対象、分類、ユーザー属性、権限を決めます。
  • 連携設計:通知条件、データの正本、項目、更新頻度、連携方式、エラー時の扱いを記録します。
  • 画面設計:主な仕事を3つ程度に絞り、検索や申請への導線を短くします。

スマートフォンで使う場合は、ボタンや入力項目、通知の見え方を確認します。

設計では、通信が不安定なときの再送や、PDFや表の見やすさも押さえておきます。

公共性の高いポータルでは、発注側が、デジタル庁「ウェブアクセシビリティ導入ガイドブック」(2025年10月16日公開)の考え方を調達条件に含めます。

まずは代表部門、主要コンテンツ、申請1種類の最小構成から始め、利用者の反応を見て広げます。

認証、権限、データモデル、監査ログは、初期に設計します。

標準機能と個別開発の範囲は、機能一覧に明記します。

カスタマイズがアップデートや保守費用に与える影響も確かめておきます。

4. テスト:権限・移行・障害の検証

受入テストでは、利用者の役割ごとに、権限、移行データ、検索、セキュリティを照合します。確認内容は、5つの項目に分けて検証します。

  • 権限・画面:一般社員、管理職、管理者、退職予定者、社外利用者で表示・申請・通知を確認します。
  • 移行データ:ファイル名と本文、作成者と更新日、公開期限、タグ、旧URL、権限。
  • 検索・移行整理:古い文書を整理し、実際の検索語で結果とゼロ件時の案内を検証します。
  • 認証・アカウント:SSO・MFA、セッション期限、パスワード再設定、退職・異動時の停止。
  • 脆弱性・復旧:入力検証、XSS、SQLインジェクション、ファイル投稿、ログ監視、バックアップ復元。

移行対象は、現場の責任者が残すか、統合するか、廃棄するかを判断します。

IPA「中小企業の情報セキュリティ対策ガイドライン」も、安全運用、バックアップ、委託先・サプライチェーンの確認を扱っています。

外部公開では、診断範囲と再診断の条件を契約に入れます。

5. 稼働:段階公開と問い合わせ窓口の準備

稼働時は小さく公開し、利用状況と案内体制を整えながら対象範囲を広げます。実施することは、3つに分けて整理します。

  • 段階公開:1部門か1種類の手続きから始め、権限や情報の問題を早期に見つけます。
  • 状況確認:検索ログ、閲覧数、申請完了率、問い合わせ、権限エラーを見て範囲を広げます。
  • 利用・管理案内:検索や申請取消、公開・承認・削除・権限変更などの手順を用意します。

公開日には、切替時間、旧サイト、データ凍結、障害時の戻し方を関係者で共有します。利用者には、連絡先も案内します。

運用を始めた直後は問い合わせが増えるため、一次窓口と開発会社の二次窓口を分け、回答期限も決めておきます。

6. 定着:コンテンツと利用データによる継続的な改善

公開後は、情報の管理者を決め、利用データをもとに継続して改善します。運用で確かめる事項は、3つに分けて整理します。

  • コンテンツ管理:各ページにオーナー、更新頻度、承認者、期限を設け、月次か四半期で見直します。
  • 利用状況:検索成功、検索後のクリック、申請、問い合わせ削減、期限内更新で測ります。
  • 改善活動:未利用ページや検索語、FAQ・フォームを見直し、現場ユーザーも改善会議に加えます。

古い規程や担当者不明のFAQ、重複文書があると、検索への信頼が下がります。

現場の参加で見つかりやすい課題もあります。

運用責任者や異動時の権限更新、バックアップ復元、保守範囲も決めておく必要があります。

自社で判断する部分と委託作業を分けておけば、費用とリスクを管理できます。

ポイント

判断の目安は、各工程で仕上げる内容、意思決定者、次へ進む条件がそろっているかです。そろわないまま進むと、抜け漏れが後の工程に持ち越されやすくなります。

ポータルサイトシステムの費用相場とコストの内訳

小規模な社内、標準的な社内、顧客・会員・取引先の初期費用レンジを横棒で比較した図
外部利用や連携を含む要件ほど、費用レンジが上がっています。

費用は、用途や認証・権限、連携によって変わります。さらに、移行、画面数、運用支援によっても変わります。

ここで示すのは、公開料金と一般的な開発工数による要件別の概算で、ポータル固有の全国統計ではありません。

税、導入支援、追加オプション、保守の有無で金額は動くため、相場は幅で捉える必要があります。

クラウド型のライセンスと導入作業の切り分け

クラウド型は、製品のライセンス料と導入作業を分けて比べます。料金と、追加で確認する事項もあわせて整理します。

  • 300ユーザー試算:ライセンスだけで月額約18万円から30万円、年額約216万円から360万円です。
  • SharePoint試算:プラン1なら月額約22万4,700円、年額約269万6,400円です。
  • 別途確認する作業:要件・画面・権限設計、SSO、移行、API、教育、運用設計と初年度保守は別見積の場合があります。

1ユーザーあたりでは、SharePointプラン1が月額749円、Garoonクラウド版が月額900円からです。desknet’s NEOクラウド版は、1ユーザーあたり月額600円、800円、1,000円です。料金は、Microsoft 365、サイボウズ、ネオジャパンの公式ページを参照しました(2026年8月確認)。

製品利用料と導入総額は、分けて考えます。既存契約への追加ライセンスや、未契約の場合のユーザー管理費も確認します。

要件の複雑さによる導入費用と期間の違い

小規模な社内向けと外部・統合向けでは、連携や管理の複雑さによって、費用と期間が異なります。

  • 小規模な社内: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万円以上、半年〜1年以上になる可能性があります。

上の金額は、人件費、工数、クラウド利用料、製品ライセンスを組み合わせた推定レンジです。

実際の金額は、ログイン人数そのものより、権限の組み合わせや連携先の数とAPI仕様で左右されます。さらに、移行対象の品質、画面の独自性、テスト・監査の要求水準も金額に影響します。

見積では、同じ要件を各方式に渡して、初期費用と運用費を分けて比べます。

保守・運用・改善にかかる費用の初期確保

運用費と保守契約では、費用の項目と契約条件を確かめておきます。

  • 運用費:ライセンスとクラウド、バックアップと監視、保守と脆弱性対応、問い合わせ窓口とコンテンツ更新支援、追加開発。
  • 見積の分け方:月次の運用作業と、年次のセキュリティ・権限の見直しを分けます。
  • 保守契約:障害対応の受付時間、復旧目標、追加開発の対象外、製品アップデート、バックアップ保持期間、脆弱性修正範囲を確認します。
  • 契約形態:請負契約は仕様が固まった部分、準委任契約は要件変更や改善を続けるフェーズに向きます。納品物と変更手続きの線引きを明確にします。

初期開発費だけで予算を決めると、公開後に更新担当者を置けなくなり、利用データを見た改善費用も確保できなくなります。

ポイント

判断の目安は、初期費用に加えて、ライセンス、保守、運用、改善の費用を合わせて見ているかです。公開後に必要な費用まで含めると、予算の見誤りを防ぎやすくなります。

ポータルサイトシステムの見積を取る際のポイント

見積依頼書に記載する利用規模、機能範囲、権限・連携、移行範囲のチェック項目を並べた図
4項目を同じ前提にそろえると、各社の見積を比べやすくなります。

見積の精度は、発注側が渡す情報の具体性で決まります。そのため、対象と利用場面、機能、権限と連携を、同じ資料にまとめます。また、移行、セキュリティ・運用、納期と予算も、同じ資料に入れます。

発注側は、まだ決まっていない事項も明示し、候補会社に前提条件と追加費用の可能性を示してもらいます。

見積依頼書の対象範囲と前提条件

候補会社が同じ前提で見積もれるように、依頼書の内容を5つの観点で整理します。

  • 利用規模:登録者数と同時接続数を分け、社内外の利用者、組織・拠点数、言語、端末を記載します。
  • 機能範囲:情報、検索、FAQ、フォーム、申請・通知、ファイル・ダッシュボードと、標準・変更・新規の区分。
  • 権限・連携:権限単位と接続先、方向と頻度、項目、API、再送、データの正本。
  • 権限の例:「AさんがB文書を見られるか」「退職したCさんがログインできないか」を示します。
  • 移行範囲:ファイル数・容量に加え、重複、期限切れ、個人情報、旧URL、メタデータ。

複数社の同じ条件での比較

費目と運用品質も含めて比べるため、同じRFPと評価の観点を使います。確認する項目は、4つの観点に分けて整理します。

  • 費目:3社程度に同じRFPを渡し、初期費用とライセンス、連携と移行、テスト、教育、保守、追加開発を分けます。
  • 提案評価:要件適合、連携、移行・運用、セキュリティ、見積透明性の5項目で比べます。
  • 会社・契約:同用途の実績件数、構築担当、標準と個別開発の境界、API制限、追加ライセンス、品質確認の担当と保守窓口を聞きます。
  • 実務確認:管理画面、検索ログ、権限変更、障害時の復旧手順をデモで見ます。

極端に安い見積には、要件定義、権限テスト、移行前の整備、公開後の支援が含まれない場合があります。

追加費用と失敗リスクの境界の確認

見積の段階で検証担当と契約範囲を明確にし、失敗や追加費用に備えます。確認点は、5項目に分けて洗い出します。

  • 失敗予防:検索できない、権限再設計、古い資料、更新停止、外部連携障害を想定し、検証工程と判断者を決めます。
  • 追加費用:データ整形、API有料オプション、SSO・MFA設定、権限パターンの増加、スマートフォン対応。
  • 試験と改修:アクセシビリティ試験、脆弱性診断、移行のやり直し、公開後の追加画面。
  • 見積明細:「一式」の数量、作業内容、完了条件、対象外作業を確認します。
  • 契約と移行:著作権、コード・設定の引渡し、クラウド契約者、データ持出し、変更時の支援。

短期の費用に加えて、3年程度のライセンス、保守、改修、運用工数を合算した総保有コストで比べると、社内説明に役立ちます。

ポイント

判断の目安は、各社に同じ要件を渡し、前提条件と追加費用の可能性をそろえて出してもらえているかです。価格の安さだけで選ぶと、要件定義や権限テストが含まれていない場合があります。

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

費用や期間は要件によって変わります。社内稟議やベンダーとの相談で判断の起点になりやすい質問を、4件まとめます。

ポータルサイトシステムはSaaSとスクラッチのどちらが良いですか?

情報共有、検索、申請、通知が中心ならSaaSや既存グループウェアが適します。独自の権限や外部との取引、複雑な業務が競争力に直結し、標準機能では足りない場合は、基盤拡張やスクラッチを検討します。

判断の基本は、まず標準機能の範囲を確かめ、差別化に関係しない部分まで作り込まないことです。

ポータルサイトシステムの開発期間はどのくらいですか?

期間の概算は、小規模社内で1〜3か月、標準社内で3〜6か月、外部会員・取引先で4〜9か月、大規模統合で6〜12か月以上です。

要件の決定、データの洗い出し、承認、セキュリティ試験、受入テストにも時間がかかります。そのため、開発作業だけで日程を組まないことが大切です。

既存の共有フォルダやグループウェアのデータは移行できますか?

移行できる場合もありますが、全件をそのまま移す方法は勧められません。まず、所有者、公開期限、機密区分、重複、リンク切れ、検索対象を洗い出します。

残す、統合、廃棄のどれにするかを決めます。そのうえで、サンプルで本文検索、権限、更新日、旧URL、添付ファイルの引継ぎを確かめてから、本番移行に進みます。

個人情報や社外秘情報を扱う場合は何を確認しますか?

個人情報や社外秘情報を扱うなら、SSO・MFAと最小権限、職務・組織別の認可を要件に入れます。加えて、異動・退職時の停止、通信・保存時の暗号化、監査ログも要件に含めます。さらに、バックアップ、脆弱性診断、委託先管理も要件に入れます。

外部利用者には、本人確認、招待期限、企業別の分離、再設定、問い合わせ時の確認も設けます。公開範囲が広い場合は、アクセシビリティとスマートフォン操作も受入条件にします。

ポイント

判断の起点は、標準機能で足りるかどうかです。期間、移行、セキュリティも要件の段階で一緒に見ておくと、判断がぶれにくくなります。

まとめ:段階的に進めるポータルサイトシステム開発

進め方は6段階です。要件整理、方式・ベンダー選定、設計開発の次に、テスト、稼働、定着と進みます。用途と利用者を分けたうえで、検索、権限、連携、移行、運用を要件に入れます。

発注前に決めることの整理

発注前には、対象ユーザー、課題、KPI、機能、権限、連携を資料にまとめます。加えて、SSO・MFA、移行、バックアップも書き加えます。監査、アクセシビリティ、保守SLAと、追加費用の境界も、資料に入れます。

まだ決まっていない事項も明示すると、候補会社から前提の異なる見積が出るのを防げます。

小さく始めて利用データで広げる進め方

まずは小さく検証し、利用データと長期費用を見ながら広げます。継続運用では、3つの観点から追います。

  • 段階導入:代表部門や申請1種類でPoCと段階公開を行います。
  • 利用指標:検索成功率、問い合わせ削減、申請完了率、更新期限の遵守率を見ます。
  • 長期費用:3年程度のライセンス、保守、追加開発、運用工数、移行負担を含めます。

成果は、公開日よりも、情報の鮮度や利用者の行動を継続して改善できる体制で左右されます。

自社の業務と利用者に合う仕組みを段階的に整えると、情報を探す時間や手作業を減らし、使われ続ける業務基盤に育てられます。

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

会社紹介

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

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

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

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

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

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