社内ポータル（社内SNS）開発の発注/外注/依頼/委託方法について

社内ポータル・社内SNSの開発を外注・委託する際には、全社員が利用するシステムであるがゆえの特有の考慮事項があります。利用部門が多く要件が複雑になりやすい点、UI/UXの品質が利用率に直結する点、Active Directoryや既存グループウェアとの認証連携が必要な点など、一般的な業務システムとは異なる発注上の注意点を理解しておくことが重要です。本記事では、社内ポータル開発を外注で成功させるための発注方法を、準備段階から選定・契約・プロジェクト推進・失敗対策まで体系的に解説します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・社内ポータル開発の完全ガイド

社内ポータル開発を外注する前の準備

社内ポータルの外注を成功させるためには、発注前の準備が極めて重要です。特に、利用部門が多い社内ポータルは要件が発散しやすいため、発注前に要件を適切に絞り込んでおくことが外注成功の鍵となります。

社内ポータルの発注仕様書には、以下の項目を詳細に記載することが重要です。まず「利用部門と想定ユーザー」として、ポータルを利用する部門・拠点・社員数・利用端末（PC/スマートフォン/タブレット）を明記します。次に「機能要件」として、必要な機能を優先順位付き（Must/Should/Could）で一覧化します。お知らせ・ドキュメント管理・社員検索・申請ワークフロー・社内SNSなど、各機能の詳細仕様（投稿権限・承認フロー・通知方式など）を具体的に記述してください。「連携システム要件」として、Active Directory・人事システム・グループウェア・勤怠管理など、連携が必要なシステムを列挙し、連携方式（API/LDAP/ファイル連携）と連携データの種類を明示します。「非機能要件」として、セキュリティ基準（ISMS準拠・暗号化要件）・可用性目標・同時接続ユーザー数・レスポンスタイムの要件を記載します。「コンテンツ移行要件」として、移行が必要な既存コンテンツの種類と量も整理しておきましょう。

社内ポータル開発の予算は、初期開発費用だけでなく、コンテンツ移行費用・社員向け導入研修費用・保守費用まで含めて計画することが重要です。一般的な費用感として、社員100名以下の小規模ポータルで200万〜500万円、100〜1,000名規模で500万〜2,000万円、1,000名以上の大規模ポータルで2,000万円以上が目安です。スケジュールの検討では、本番稼働目標日から逆算して各フェーズに必要な期間を確保します。社内ポータルは要件定義フェーズで複数部門のヒアリングが必要なため、この工程だけで1〜2ヶ月かかることが多く、スケジュールに余裕を持たせることが重要です。また、コンテンツ移行と社員向けの説明会・トレーニングの期間も、本番稼働前に確保する必要があります。大規模なコンテンツ移行が発生する場合は、本番稼働の2〜3ヶ月前から移行作業を並行して進める計画が望ましいです。

開発会社の探し方と選定プロセス

社内ポータル開発会社の選定では、技術力だけでなくUI/UX設計力・プロジェクトマネジメント力・運用定着支援の体制も重視することが、開発後の高い利用率実現につながります。複数の候補を比較し、自社のニーズに最も合ったパートナーを選びましょう。

社内ポータル開発会社を探す主な方法として、まずIT系の開発会社比較サイト（発注ナビ・アイミツ・クラウドワークスエンタープライズなど）の活用があります。「社内ポータル」「イントラネット開発」「社内SNS開発」などのキーワードで検索・絞り込みを行い、実績のある会社をリストアップします。次に、Microsoftの認定パートナーリストの活用も有効で、特にSharePointを活用したポータル構築を検討している場合は、Microsoft認定パートナー（Gold/Silver Partner）を優先して探すことが推奨されます。また、知人・取引先企業からの紹介も信頼性の高い情報源です。類似規模・類似業種で社内ポータルを導入した企業から、実際の開発会社を紹介してもらえると、生の評価が参考になります。展示会・セミナーへの参加も、社内ポータル・イントラネット関連の技術会社と直接接点を持つ機会として有効です。候補会社が集まったら、3〜5社程度に絞り込んでRFPを送付し、提案を比較検討します。

社内ポータル開発会社の評価基準として、まず「UI/UX設計力」の確認が重要です。提案書に画面モックアップ・デザインプロセスの説明が含まれているか、ユーザビリティテストの実施経験があるかを確認します。過去の開発実績サイト（デモ環境を見せてもらえると理想的）でUI品質を評価しましょう。次に「認証連携の実績」として、Active Directory・Azure AD・SAML/OIDCによるSSOの実装経験が豊富かを確認します。具体的な連携実績（どのような規模・環境での実装か）を詳しく聞くことが重要です。「セキュリティへの取り組み」として、ISMS認証の取得有無・セキュリティ診断の実施体制・過去のセキュリティインシデント対応事例などを確認します。「プロジェクトマネジメント力」として、多部門が関与するプロジェクトの調整経験・定例報告の仕組み・課題管理の方法を評価します。最後に「運用定着支援体制」として、リリース後のトレーニング・マニュアル作成・利活用促進支援のメニューを確認します。

見積もり依頼から契約までの流れ

見積もり依頼から契約までのプロセスを丁寧に進めることで、開発開始後のトラブルを防止できます。社内ポータルは仕様変更が発生しやすいため、契約内容を明確にしておくことが特に重要です。

社内ポータルの見積もり依頼では、発注仕様書（RFP）を3〜5社に送付し、同条件での比較を行います。見積もり依頼の際には、初期開発費用・要件定義費用・テスト費用・コンテンツ移行費用・教育費用・保守費用（月額・年額）を別々に提示してもらうよう依頼します。見積もり回答後は、各社の提案内容を以下の観点で比較します。「技術提案の適切さ」として、提案された技術スタック・認証連携方式・インフラ設計が要件に合っているかを確認します。「業務理解の深さ」として、ヒアリングや提案書の中で、社内ポータル特有の課題（多部門の要件調整・コンテンツ管理・利用率向上）への理解が示されているかを評価します。「見積もりの透明性」として、工数根拠の明確さ・追加費用が発生するケースの説明・仕様変更時の費用算出方法が明示されているかを確認します。価格だけで判断せず、提案品質・会社の信頼性・担当者との相性も重要な判断材料です。絞り込んだ2〜3社にプレゼンテーション・ヒアリングを実施した上で最終決定します。

社内ポータル開発の契約形態として、「請負契約」と「準委任契約」の特性を理解して選択することが重要です。請負契約は成果物の完成を約束する契約で、仕様が確定した後の開発フェーズに適しています。契約金額が固定されるため予算管理がしやすい反面、仕様変更が発生した場合は変更見積もりが必要になります。準委任契約は業務の遂行を委託する契約で、成果物の完成保証はありませんが仕様変更への柔軟な対応が可能です。要件が流動的な段階（要件定義フェーズ）や、アジャイル型の開発に適しています。社内ポータルのように利用部門が多く要件変更が生じやすいプロジェクトでは、要件定義フェーズを準委任・設計・開発フェーズを請負とするフェーズ分割型の契約が有効です。契約書には、知的財産権（著作権）の帰属・ソースコードの開示・瑕疵担保の期間・保守条件・秘密保持（NDA）・個人情報保護に関する条件も必ず明記します。

発注後のプロジェクト推進

発注後のプロジェクト推進においては、IT部門だけでなく関係する各部門を適切に巻き込みながら進めることが成功の鍵です。社内の関係者が多い分、コミュニケーション管理と意思決定プロセスの明確化が特に重要となります。

社内ポータルは全社が利用するシステムであるため、人事部・総務部・経営企画部・IT部門など複数の部門が要件に関与します。発注後のプロジェクト推進では、各部門の代表者をプロジェクトメンバーとして正式に任命し、定期的な要件確認・意思決定の場を設けることが重要です。部門間で要件が競合する場合（例：「総務部は全社員に表示したい」vs「IT部門はセキュリティ上の理由で制限したい」）は、プロジェクトオーナー（役員クラス）が意思決定権を持つ形で調整します。各部門の要件をすべて取り込もうとすると機能が膨大になりコストと期間が増大するため、優先順位を明確にした上でスコープを管理することが必要です。開発会社との週次定例ミーティングでは、進捗確認・課題確認・次週の作業計画を確認し、課題は「課題管理表」でステータス管理します。社内調整の議事録は必ず文書化し、開発会社と共有することで「言った・言わない」のトラブルを防ぎます。

社内ポータルの本番稼働前には、実際の利用者（各部門の代表社員）によるUAT（ユーザー受け入れテスト）を必ず実施することが重要です。開発会社によるシステムテストでは技術的な動作確認が中心ですが、UATでは実際の業務シナリオに基づいた操作性・使い勝手・要件との整合性を検証します。UATで確認すべきポイントとして、想定ユースケース（お知らせを投稿する・ドキュメントを検索する・申請書を提出するなど）が問題なく実行できるか、権限管理が正しく設定されているか（自部門外の機密情報にアクセスできないか）、モバイル端末からのアクセスが問題なく機能するか、認証（AD・SSO）が正常に動作するかなどがあります。UATには各部門の代表者5〜10名程度を参加させ、2〜3週間のテスト期間を確保することが理想的です。UATで発見された問題は「改修が必要なもの」と「次フェーズで対応するもの」に分類し、本番稼働前に対応する改修の優先順位を発注者と開発会社で合意した上で対処します。

外注でよくある失敗と対策

社内ポータル開発の外注では、特有の失敗パターンがあります。事前に代表的な失敗事例を把握することで、リスクを大幅に低減できます。特に、利用部門の巻き込み不足とコンテンツ移行計画の不備は、多くのプロジェクトで繰り返される失敗です。

社内ポータル開発で最も多い失敗の一つが、利用部門への要件ヒアリングが不十分なまま開発を進めてしまうケースです。IT部門が独自に要件を設定した結果、「使いにくい」「必要な機能がない」「現場の業務フローと合っていない」といった問題が本番稼働後に発覚し、大規模な改修を余儀なくされるケースが後を絶ちません。この失敗を防ぐためには、要件定義フェーズで人事・総務・営業・製造などの主要部門の代表者を必ずヒアリングに巻き込むことが必要です。ヒアリングでは「現在困っていること」「よく使う業務ツール」「ポータルに求めること」を具体的に引き出します。さらに、要件定義後のワイヤーフレーム・プロトタイプのレビューにも各部門代表者を参加させ、「作る前に使えるかを確認する」プロセスを設けることが重要です。IT部門主導で開発を進めず、「社内ポータルは全員のもの」という意識を持って関係者を適切に巻き込むことが、高い利用率の社内ポータルを実現するための根本的な取り組みです。

社内ポータルの開発において、コンテンツ移行計画の不備も頻発する失敗パターンです。システム開発には十分な時間と予算をかけたにもかかわらず、コンテンツ移行（規程類・マニュアル・既存の掲示板投稿の移行）が間に合わず、新ポータルが空のまま本番稼働してしまうケースがあります。コンテンツが不足したポータルは社員に「使えない」と判断され、旧システムへの逆戻りを招くリスクがあります。この失敗を防ぐためには、コンテンツ移行計画を開発計画と並行して早期に策定することが重要です。具体的には、移行するコンテンツの棚卸し（種類・量・担当部門の確認）、コンテンツのフォーマット変換が必要かの確認、移行作業の担当者アサイン、移行作業スケジュールの策定を本番稼働の3〜4ヶ月前に着手します。また、すべての既存コンテンツを移行しようとするのではなく、「最終更新から2年以上経過したコンテンツは廃棄・更新してから移行する」などのルールを設けてコンテンツを整理することで、移行量を適切にコントロールし、質の高いコンテンツが揃ったポータルを開始することができます。

まとめ

本記事では、社内ポータル開発の発注・外注方法について、事前準備・開発会社の探し方と選定・見積もりと契約・プロジェクト推進・よくある失敗と対策の観点から詳しく解説しました。

社内ポータルの発注を成功させるためのポイントを整理すると、まず利用部門を巻き込んで要件を収集し、RFPとして文書化することが最重要です。開発会社の選定ではUI/UXデザイン力・利活用支援実績・既存システムとの連携経験を重視してください。契約時にはソースコードの所有権・保守体制を明確にし、コンテンツ移行計画は開発計画と並行して早期に策定することが失敗防止のカギです。UATでは実際の利用者を巻き込み、本番稼働前に使い勝手を検証しましょう。

社内ポータルは社員が毎日使う業務インフラです。本記事を参考に計画的に発注を進め、社員に真に使われるポータルを実現してください。

▼全体ガイドの記事
・社内ポータル開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。