社内ポータルの要件定義・RFP｜記述例と比較チェックリスト
目次
社内ポータルのRFPで「検索、モバイル、分析に対応」と書いても、各社の回答がすべて「対応可」になり、比較できないことがあります。必要なのは、機能名を増やすことより、誰が何を完了できれば要件を満たすのかを明確にすることです。
社内ポータルの要件定義は、利用者・情報・権限・更新運用を整理する工程です。RFP（提案依頼書）は、その要件と制約を候補企業へ伝え、実現方法、費用、責任範囲を提案してもらう文書です。両者をつなぐと、選定時の評価を、そのまま導入後の受入確認に使えます。
この記事では、大手企業のIT、購買、社内広報、人事が使える要件記述例と評価表を紹介します。表の内容は実務上の作成例であり、特定の製品がすべて満たすことを示すものではありません。
RFP作成前に決めるのは、目的・範囲・判断者
「情報共有を活性化する」だけでは、必須要件を選べません。最初に、今どこで業務が止まり、導入後にどう変えるかを書きます。
例えば、「拠点ごとにお知らせを転記している」を「本社の正式な連絡を、対象拠点の社員が勤務中に確認できる」に変換します。この目的なら、対象者の管理、モバイルアクセス、発信と承認、到達状況の確認が評価項目になります。別の目的なら、必要な項目も変わります。
| 最初に合意する事項 | 記載する内容 |
|---|---|
| 導入目的 | 現在の業務上の問題、改善後の状態、評価する指標 |
| 対象利用者 | 社員・出向者・協力会社、PCの有無、国内外の拠点 |
| 今回の対象範囲 | 全社ニュース、規程の入口、検索、既存システム連携など |
| 維持する基盤 | 文書保管、認証、人事情報、申請システムのうち残すもの |
| 意思決定 | 予算、情報保護、運用、公開をそれぞれ承認する担当者 |
Microsoftのイントラネットの役割と作業に関する資料でも、業務・サイト所有者、ITなどの役割を分けています。社内ポータルは公開後の更新が続くため、発信部門と運用部門の参加を調達の初期から組み込みましょう。
「必須・比較・将来」を分けると、提案が読みやすくなる
要件は3種類に分けます。必須は採用の前提、比較は候補間の違いを評価する項目、将来は今回の費用や受入に含めるかを分けて回答してもらう項目です。
- 必須：指定した認証基盤を利用できる、対象外の情報へアクセスできないなど。
- 比較：部門担当者が公開まで行う作業、訂正のしやすさ、分析の使いやすさなど。
- 将来：未確定のシステム連携、海外展開、AI活用の拡大など。
「将来必要かもしれない」機能をすべて必須にすると、導入費用も運用も複雑になります。将来要件は、追加費用の算定方法や構成上の制約を確認し、今回の選定に必要な範囲を明示してください。
提案依頼書の構成例：本文と別紙を分ける
RFP本文に詳細な機能を詰め込みすぎると、候補企業がプロジェクトの目的を読み取りにくくなります。背景と依頼内容は本文、要件ごとの回答は別紙に分けると比較しやすくなります。以下は構成例です。
- 背景と導入目的：現在の課題、対象業務、改善後の状態。
- 対象範囲：利用者、情報、既存基盤、今回変更しないもの。
- 制約：セキュリティ審査、調達手順、公開時期、予算の提示方針。
- 提案してほしい事項：構成、実施工程、支援体制、費用、リスク。
- 評価と選定：必須条件、デモ、PoC、質疑応答の進め方。
- 別紙：要件回答表、既存構成、移行量、共通シナリオ。
回答書の形式も指定します。自由な説明だけでなく、要件番号に対する実現方法、前提条件、追加費用、確認資料を同じ列で提出してもらうと、横並びの評価ができます。
そのまま検討に使える、社内ポータルRFPの要件記述例
各要件には番号を付け、「利用者・操作・完了条件・回答形式」を組み合わせます。曖昧な要望を、次のように書き換えてみましょう。
| 曖昧な要望 | 検証できる要件の例 | 提案側に求める回答 |
|---|---|---|
| 検索しやすい | 一般社員が、指定した業務上の言葉から規程の正本を開ける | 対象保管先、本文検索の範囲、権限の扱い、実演 |
| 更新が簡単 | 部門編集者がテンプレートでニュースを作成し、承認後に対象者へ公開できる | 操作手順、必要な権限、管理者へ依頼する作業 |
| モバイル対応 | 対象の端末・通信環境で、現場社員が初回ログインから重要連絡の確認まで完了できる | 対応条件、認証、利用者区分ごとの契約 |
| 安全に使える | 一般社員、管理者、利用停止者の条件ごとに、閲覧と管理操作が制限される | 設定方法、反映条件、ログ、試験方法 |
| 効果が分かる | 運用担当者が、対象部署に情報が届いた状況を確認し、改善対象を抽出できる | 集計単位、対象者の定義、出力、個人情報の扱い |
時間や反映期限が重要なら、社内で必要な水準を定めて追記します。「すぐ反映」「短時間で公開」ではなく、いつからいつまでを測るかも含めて合意することが大切です。
RFPに含める8領域のチェックリスト
1．利用者・端末・認証
対象人数だけでなく、会社メールがない社員、兼務者、出向者の扱いを記載します。ログイン方式、アカウント発行・再発行、利用停止を一連の運用として回答してもらいます。
2．権限・データ保護
閲覧と編集、管理者操作を分け、組織変更時の更新元を明確にします。画面上の出し分けと、文書そのもののアクセス権を区別してください。監査ログ、データ保管、契約上の保証は、セキュリティ部門の確認票につなげます。
3．検索・AI・既存システム連携
検索、リンク表示、文書表示、編集、申請実行のどれが必要かを示します。AIを含む場合は、回答の根拠、権限、誤回答時の扱いも対象です。連携先の名称だけでは、必要な作業は決まりません。
4．コンテンツの作成・承認・廃止
作成から掲載終了までの責任を決めます。誤公開時の訂正、承認者不在、編集者交代も実演の対象にすると、運用負荷を把握できます。
5．移行・切り替え
ページ、添付文書、履歴、権限、URLを分けて移行対象を示します。不要情報の判定や内容修正は、ベンダーが自動で判断できる作業ではありません。自社で担当する範囲を見積もりから切り離さず、計画へ含めます。
6．運用・支援・障害対応
問い合わせ窓口、受付時間、障害時の連絡、連携エラーの調査担当を確認します。日本語支援の有無だけでなく、設定変更や利用促進が支援契約に含まれるかを明記してもらいましょう。
7．費用・拡張・契約終了
初期費用と継続費用、追加機能、利用者の増加、APIや連携、教育を分けます。終了時のデータ取り出しの形式・範囲・費用も確認すると、後年の移行を含めた比較ができます。
8．受入試験・成果物
公開を認める条件、試験の担当、設定資料と手順書などの成果物を示します。未解決事項がある場合は、誰がいつまでに解決し、どう再確認するかを決めます。
まだ要件を広く集めている段階なら、「業界事例で学ぶ社内ポータルデザイン」も参考になります。画面の好みだけでなく、社員が何に到達するための入口かを考える材料として活用してください。
ベンダーの回答を「5つの実現方法」に分類する
対応可・不可だけの回答欄は避けます。標準機能、設定、追加オプション、個別開発、非対応に分け、必要な費用と保守の担当を併記してもらいましょう。
例えば、個別開発で実現できても、サービス更新時の改修確認が必要なら、その継続費用が比較に影響します。「提供予定」は現在の機能と分け、提供時期と契約上の扱いを確認します。
| 評価する点 | 記録する内容 |
|---|---|
| 実現性 | 現在利用できるか。設定・追加開発・別契約が必要か |
| 運用性 | 誰が、何の手順で、どの頻度で管理するか |
| 費用 | 初期・継続・追加のどこに含まれるか |
| 証拠 | 資料、共通デモ、PoCのどこで確認したか |
部門間の意見が割れたときの決め方
広報は発信のしやすさ、ITは既存基盤との整合、購買は契約と費用、現場は実際のアクセスを重視します。どれか一部門の感想で決めず、領域ごとに判断者を置きます。
| 領域 | 主に判断する担当の例 | 他部門と共有する結果 |
|---|---|---|
| 認証・情報保護 | IT・セキュリティ | 採用に必要な条件と未解決事項 |
| 情報発信 | 社内広報・人事 | 日常業務を完了できる手順と負荷 |
| 現場利用 | 対象部門・現場責任者 | 勤務中の利用機会と支援・代替手段 |
| 契約・総コスト | 購買・経理 | 比較期間、追加条件、継続・終了時の負担 |
例えば、操作性の評価が分かれたら、画面の好みを議論し続けるより、同じ担当者が原稿作成から訂正まで行う様子を確認します。費用が高いという意見には、対象範囲と社内工数をそろえた比較表で答えます。
アクセシビリティや多言語が必要な組織では、それも対象利用者の業務から要件へ落とし込みます。文字の拡大、キーボード操作、翻訳後の確認・承認など、実際に必要な利用条件を示し、抽象的な「誰でも使いやすい」という表現で終わらせないようにします。
デモとPoCは、同じ業務で比べる
候補ごとに得意な画面を見ても比較は困難です。「総務が規程改定を公開する」「新入社員が申請書を見つける」「異動者の権限を変える」という共通シナリオを渡します。発信担当者と一般社員が実際に操作し、完了、支援があれば完了、未完了を記録してください。
必須要件を満たしてから、運用性や費用を比較する順序にします。重要な情報保護の未達を、デザインの点数で相殺する評価は避けます。配点を設ける場合は、結果を見る前に、業務上の優先順位から決めましょう。
調達の失敗を避けるための最終点検
RFPを送る前に、要件表を導入後の運用担当者に読んでもらいます。「これを満たせば、自分たちの仕事が回るか」を確認すると、機能表だけでは見つからない不足が分かります。
- 維持する既存システムと、今回変える部分が矛盾していない。
- 未定の対象人数や移行量は、仮定と変更時の扱いを示している。
- 導入支援と社内作業の分担を回答してもらう形式になっている。
- 将来提供予定の機能を、今回の必須条件の達成として扱わない。
- 公開後の支援と契約終了時のデータ取り出しを確認している。
この点検で未定事項が出ても、隠す必要はありません。決定が必要な時点と、提案で相談したい範囲を書けば、確定条件と混同せずに調達を進められます。
LumAppsの機能を、RFPの質問へ置き換える例
機能紹介を読んだら、名称を転記するだけでなく、自社で確かめる操作へ置き換えます。
これらを共通デモやPoCへつなげれば、説明資料だけでは分からない前提条件を把握できます。提案の評価と、導入後の責任範囲も対応させやすくなります。
LumAppsへの相談では、製品と導入支援の境界を明確にする
LumAppsの公式FAQでは、認定パートナーによる要件整理から設計・移行・公開までの支援を案内しています。相談時は、自社、LumApps、パートナーの分担を、作業と成果物で確認することが重要です。
例えば、「人事情報を誰が整えるか」「旧文書の廃止を誰が決めるか」「公開後のコンテンツ更新を誰が担うか」は、製品を選ぶだけでは決まりません。検討中のRFPに未定欄があっても、その範囲を明示して相談すれば、提案に必要な条件を整理できます。
社内ポータルの要件定義・RFPに関するFAQ
RFPを出す前に製品説明を聞いてもよいですか？
問題ありません。情報収集で得た内容を自社の業務要件へ置き換え、正式な比較では各候補に共通の条件と質問回答の機会を用意します。
要件が多いほど、よいRFPになりますか？
項目数より、必要性と判定方法が明確なことが重要です。今回の対象と将来の拡張を分け、導入目的に関係する要件を優先します。
料金比較で最低限そろえる条件は何ですか？
対象利用者、機能、連携先、移行量、支援範囲、比較期間です。見積もりに含まれない社内作業も、総コストとスケジュールに反映します。
要件一覧を、導入後まで使える判断資料にする
社内ポータルのRFPは、候補を絞るためだけの文書ではありません。要件番号と検証方法、費用、担当をつなぐことで、導入中の変更管理と公開判断にも使えます。
比較の前提を具体化したい方は、要件一覧をもとにLumAppsの実現方法・費用範囲を相談することができます。導入目的、既存環境、必須条件、希望する公開時期を共有すると、標準対応と追加作業を切り分けやすくなります。
