社内ポータル（社内SNS）を開発・導入するうえで、プロジェクトの成否をもっとも大きく左右するのが要件定義です。社内ポータルは「掲示板とタイムラインを置けば情報が回る」と思われがちですが、実際には、誰に・どの情報を・どのチャネルで届けるか、既存システムとどう連携させるか、蓄積した情報の鮮度をどう保つかといった運用設計を要件として整理できていないと、導入後に「誰も見ない」「書き込まれない」という事態に陥ります。実際、情報共有システムは、機能を盛り込んだのに現場が使い方も意義も理解できず、結局LINEや個人のExcelに情報が逃げていく形骸化が頻発しています。これをいかに正確に要件として整理し、RFP（提案依頼書）や要件定義書に落とし込めるかが、現場に使われるポータルになるか、宝の持ち腐れになるかの分かれ目になります。
本記事は、社内ポータル（社内SNS）のRFP・要件定義書・提案依頼書を、導入企業の視点から具体的に解説する「要件定義特化」の記事です。導入目的の明確化と現場ヒアリング、情報ルーティング（誰に・どのチャネルで）の要件化、権限・監査ログといった非機能要件、Google Workspace／Microsoft 365連携や既存データ移行・棚卸しルールの要件、AI活用の要件まで、社内ポータルの実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まず社内ポータル（社内SNS）の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・社内ポータル（社内SNS）の完全ガイド
導入目的の明確化と現場ヒアリングから始める
社内ポータル（社内SNS）の要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。出発点は、「自社のどの情報共有の課題を、何のために解決したいのか」という導入目的の明確化です。メールに情報が埋もれる、最新ファイルがどこにあるか分からない、ベテランのノウハウが属人化している、日程調整に時間がかかる——課題は会社ごとに異なります。目的が曖昧なまま機能を集めると、多機能だが何のためのシステムか誰も分からない、使われないポータルができあがります。
解決すべき課題に優先順位をつける要件化
導入目的を明確にするには、まず現場が今どのように情報をやり取りしているかを徹底的にヒアリングし、可視化することが必要です。受発注や日報、申請、ナレッジ共有といった情報の流れを、「どこに・どの形式で・誰がやり取りしているか」まで聞き取ります。ここで重要なのは、マニュアル上の建前ではなく、現場が実際に使っているLINEや個人のExcel、手書きメモといった非公式な運用まで拾うことです。これらシャドーITの存在こそ、公式システムが現場の本当のニーズを満たせていないサインだからです。
課題を洗い出したら、すべてを一度に解決しようとせず、優先順位をつけます。最も困っている課題から着手し、効果を実感してもらいながら段階的に広げる方が、定着率は高くなります。要件定義書には、「この課題を、この機能で、このように解決する」という目的と手段の対応関係を明記してください。目的が言語化されていれば、ベンダーからの提案も評価でき、導入後に効果を測る基準にもなります。漠然と「情報共有を良くしたい」では、何をもって成功とするかが決まらず、プロジェクトは迷走します。
定着を支える組織側の要件も明記する
社内ポータルの要件定義で見落とされがちなのが、システム機能だけでなく「運用・組織側の要件」です。情報が入力されない根本原因は、操作の難しさよりも「入力しても人事評価に反映されない＝入力するだけ損」「ノウハウを共有すると自分の社内優位性が失われる」といった、貢献が報われない構造にあります。要件定義の段階で、入力や共有への貢献をどう評価し、どう動機づけるかという運用設計まで視野に入れることが、定着の前提になります。
あわせて要件化したいのが、情報を受け取る中間管理職の行動です。現場が投稿しても上司が既読をつけるだけで反応しないと、現場は「書いても意味がない」と学習し、入力をやめます。運用ルールとして「管理職は投稿にリアクションやコメントを返す」「良い共有を評価の場で取り上げる」ことを定め、要件定義書の運用要件として記載しておく。システムの機能要件と、それを使い続けさせる組織要件は両輪です。riplaは業務伴走の立場から、機能だけでなく「情報が回り続ける運用設計」を要件定義の段階から一緒に描くことを重視しています。
情報ルーティングと外部連携の要件定義
社内ポータルの要件で技術的に重要なのが、情報ルーティングと外部連携です。情報ルーティングとは「どの情報を・誰に・どのチャネルで届けるか」の設計であり、これを誤ると通知疲れによる離脱を招きます。外部連携は、既存のGoogle WorkspaceやMicrosoft 365とどうつなぐかであり、二重入力を防ぎ、ポータルを業務の起点にするための鍵です。どちらも、要件定義の段階で具体的に詰めておかないと、後から手戻りが発生します。
誰に・どのチャネルで届けるか の通知要件
情報ルーティングの要件化では、情報の種類ごとに「届けるべき相手の範囲」と「使うチャネル」を定義します。全社必読の重要連絡はメールとアプリ通知で確実に、部署内の業務連絡はポータル内通知で、雑談に近い共有は通知なしでタイムラインに、といった具合です。この設計を要件として明文化しておかないと、開発者は「とにかく全部通知する」実装をしがちで、結果として社員は通知疲れに陥り、本当に重要な連絡まで見落とすようになります。
あわせて、社員が自分で通知を制御できる範囲も要件に含めます。通知の種類ごとのオン・オフ、購読するグループの選択、まとめて受け取るダイジェスト機能など、社員が情報の受け取り方を調整できる仕組みです。通知ルーティングは、機能一覧に載りにくい地味な要件ですが、活発なコミュニケーションを持続させるか、通知に埋もれて誰も見なくなるかを分ける、極めて重要な非機能寄りの要件です。RFPには「どの情報を・誰に・どのチャネルで届けるか」の方針を必ず盛り込んでください。
外部連携・AI活用・データ移行の要件
外部連携の要件では、自社がすでに使っているGoogle WorkspaceやMicrosoft 365、SFA・CRMといったシステムと、何をどう連携させるかを具体化します。シングルサインオンで認証を統一するのか、カレンダーやファイルをポータルに表示するのか、SFAの案件情報を社内SNSに連動させるのか。連携の範囲と方式（API連携か画面埋め込みかなど）を要件に落とし込むことで、ベンダーは正確に工数を見積もれます。AI活用についても、議事録の自動文字起こし・要約や、ナレッジへの自然言語検索など、どこまでをAIに任せるかを要件として明示しておくと、提案の比較がしやすくなります。
意外と工数とリスクが大きいのが、既存データの移行と棚卸しの要件です。これまで各部署のファイルサーバーや個人のExcelに散らばっていた情報を、ポータルにどう移すか。すべてを機械的に移すと、古い・間違った情報まで持ち込んでしまい、移行直後から「検索しても使えない情報ばかり」という信頼失墜を招きます。要件定義の段階で、移行対象の選別基準（何を残し、何を捨てるか）と、移行後に誰がいつ情報を見直すかという棚卸しルールまで定めることが、鮮度を保つ運用の出発点になります。エクスポート形式や移行期間、ベンダーの支援範囲も、忘れずRFPに含めてください。
鮮度を保つ棚卸しルールを要件に組み込む
データ移行と並んで、運用後の鮮度を保つ仕組みも要件として明文化すべきです。社内ポータルが使われなくなる最大の原因は、検索しても古い情報ばかりでシステムへの信頼が失われることです。これを防ぐには、誰が・いつ・どの情報を見直すかという棚卸しのルールを、導入時から運用に組み込む必要があります。要件定義書には、たとえば「各部署の担当者が四半期ごとに自部署のナレッジを点検する」「記事に最終更新日と次回見直し日を表示する」「一定期間更新がない情報には自動でアラートを出す」といった、情報のライフサイクル管理を支える機能と運用ルールを盛り込みます。
こうした棚卸しの仕組みは、システムの機能だけでは完結せず、運用体制の整備とセットで初めて機能します。要件定義の段階で「ポータルの管理責任者を誰にするか」「各部署の編集担当を誰にするか」という運用体制も併せて設計しておくと、導入後に「誰も管理しないまま放置される」事態を避けられます。鮮度管理は、多くの要件定義で抜け落ちる盲点ですが、ここを設計できるかどうかが、ポータルが資産であり続けるか、ただのゴミ捨て場になるかを分けます。蓄積の仕組みと棚卸しの仕組みは両輪として要件化してください。
非機能要件とRFPに盛り込むべき項目
機能要件と並んで重要なのが、性能・セキュリティ・可用性といった非機能要件です。社内ポータルは全社員が毎日使うため、表示が遅い、検索が重い、よく落ちる、では使われません。また、人事情報や経営情報も載るため、セキュリティ要件も妥協できません。これらをRFPに具体的に書き込むことで、ベンダーの提案を同じ土俵で比較でき、後の「聞いていなかった」というトラブルを防げます。
権限・監査ログ・スマホ対応の非機能要件
セキュリティの非機能要件では、部署・役職・個人単位での権限設定、二要素認証、IPアドレス制限、通信の暗号化、そして誰がいつどの情報にアクセスしたかを記録する監査ログを定義します。とくに大企業や規制業種では、ガバナンスの観点から監査ログの保持期間まで指定が必要になることがあります。中小企業では手軽さとのバランスも考慮し、自社のガバナンス要件に見合った水準を要件として示すことが、過剰投資を避ける鍵です。
忘れてはならないのが、スマホ対応の要件です。現場や外出先の社員が使うには、スマートフォンから快適に閲覧・投稿できることが定着の前提になります。現場がLINEを使い続ける理由の多くは「スマホでサッと使える手軽さ」にあり、公式ポータルがこれに匹敵する使い勝手を持てなければ、シャドーITは解消されません。スマホ対応を「あれば良い」ではなく必須要件として明記し、レスポンス速度や操作性まで具体的に求めることが重要です。
見積りの妥当性とROIで稟議を通す要件
RFPを出してベンダーから見積りを受け取ったら、その妥当性を判断する軸が必要です。クラウド型なら初期費用0円が主流で、月額相場は1ユーザーあたり中央値で約600円、ボリュームゾーンはワンコインから1,000円前後です。パッケージ（オンプレ）型なら初期費用が1ユーザーあたり4,000〜12,000円、ランニングが年額500〜2,000円程度が目安です。これらの相場を知っておくと、提示された見積りが妥当か、過剰なカスタマイズで膨らんでいないかを判断できます。
稟議を通すには、総額（初期費用＋月額×人数×年数）を算出したうえで、投資回収のロジックを示すことが有効です。たとえば時給2,000円換算なら、月額800円のポータルは「社員1人あたり月24分（0.4時間）の無駄を削減できれば回収できる」計算になります。毎日5〜10分の情報を探す時間や日程調整の時間が短縮されれば、全社では投資額を上回る効果が見込めます。要件定義書には、こうしたROIの試算根拠と、IT導入補助金の活用可否まで添えておくと、稟議の説得力が増します。riplaは、機能要件・非機能要件の整理から、稟議を通すための費用対効果の言語化までを一貫して支援します。機能要件をどう整理するかは、関連する型の記事もあわせてご覧ください。
あわせて要件定義書に盛り込みたいのが、隠れた追加費用への目配りです。クラウド型では、基本料金には含まれないストレージ容量の追加、高度なセキュリティオプション、ユーザー数の上限超過、外部連携の追加料金などが、後から発生することがあります。RFPの段階で「想定する利用容量」「必要なセキュリティ水準」「連携先システムの数」を明示し、それらを含めた総額で見積りを求めることで、導入後の予算超過を防げます。月額単価の安さだけで選ぶと、運用フェーズで追加費用が積み上がり、結果的に割高になることもあるため注意が必要です。
まとめ
社内ポータル（社内SNS）の要件定義は、機能のリストアップではなく、導入目的の明確化と現場ヒアリングから始めるのが鉄則です。解決すべき課題に優先順位をつけ、情報ルーティング（誰に・どのチャネルで）、Google Workspace／Microsoft 365連携、既存データの移行と棚卸しルール、AI活用、そして権限・監査ログ・スマホ対応といった非機能要件までをRFPに具体的に落とし込むことが、現場に使われるポータルの土台になります。さらに、入力への動機づけや管理職の行動変容といった組織側の運用要件まで視野に入れることが、形骸化を防ぐ決め手です。
見積りの妥当性は、クラウド月額約600円・パッケージ初期4,000〜12,000円といった相場と、「月24分の無駄削減で回収」というROIロジックで判断できます。要件定義書とRFPに目的・機能・非機能・運用・費用対効果を一貫して書き込むことで、ベンダー提案の比較も、社内の稟議も通しやすくなります。riplaはフルスクラッチ受託と国内開発を組み合わせ、業務から逆算した要件整理と、情報が回り続ける運用設計までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。