情報共有システムの発注は、現状把握、要件整理、RFP作成、試験運用、段階導入の順に進めると、現場に定着しやすくなります。
発注を検討している企業の担当者に向けて、RFP・要件定義書・提案依頼書の作り方を要件ごとに説明します。全体像は情報共有システムの完全ガイドでも確認できます。
▼全体ガイドの記事
・情報共有システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
導入目的と情報ルーティングの要件定義
要件定義で最初に決めるのは、機能ではなく、何のために情報共有システムを入れるのかという目的です。メールに情報が埋もれる、最新ファイルが分からない、退職者の知見が消えるといった現状の課題も、あわせて書き出します。
目的を決めないまま機能だけを並べると、現場で使われないシステムになりかねません。そこで、RFPの冒頭には導入目的と解決したい課題を明記しておきます。
現状の情報の流れ（AsIs）を可視化する要件
導入目的が決まったら、次は現状の情報の流れ（AsIs）を可視化します。情報の種類ごとに、誰から誰へ、どの手段で届いているかを、発注側の担当者が確かめます。手段には、メールや口頭のほか、紙やExcelもあります。
具体的には、各部署の担当者にヒアリングして、受発注や日報の流れと不満点を洗い出します。稟議や議事録の流れも対象に含めます。現場が非公式ツールを使う理由は、新システムが満たすべき要件につながります。
可視化を省くと、公式システムを入れたあともLINEや独自Excelで情報が流れ続け、二重入力が残ることがあります。
- 情報の送り手と受け手：部署や担当者の間で、誰が情報を渡すか
- 情報の種類と手段：受発注などの情報が、どの経路を通るか
- 現場の不満と非公式ツール：利用されている理由を聞き取る
AsIsの可視化は地道な工程ですが、現場で使われるシステムの要件定義を支える土台になります。
誰に・どのチャネルで届けるかの情報ルーティング要件
情報共有が活発になるほど、無関係な通知やメンションが増え、通知疲れからシステム離れが起こることがあります。そこで、情報を誰に、どのチャネルで届けるかを要件として定めておきます。
- 全社向け：全社員に共有する情報の届け方
- 部署向け：関係する部署に限った情報の届け方
- 個人向け：特定の利用者に届ける情報の扱い
RFPには、チャンネルやキーワード単位で通知を絞り込めることと、役職や部署に応じて表示する情報を分けられることを書きます。
通知の設計が不十分だと、大事な情報まで埋もれてしまいます。そのため、情報ルーティングは機能と運用の両面から、要件定義の段階で意図的に組み込みます。
権限・監査ログのセキュリティ要件
情報共有システムには社内の機密情報が集まるため、セキュリティ要件をRFPで明確にしておく必要があります。必要な水準は、手軽さを優先する中小企業向けと、厳格な統制を求める大企業向けとでは大きく異なります。
権限設定・二要素認証・IP制限の要件
権限設定では、誰が情報を閲覧・編集できるかを制御します。そのうえで、部署や役職ごとの閲覧範囲と、フォルダや記事の限定公開を要件に含めます。
- 二要素認証：不正アクセスを防ぐための対応有無
- IP制限：社外からのアクセスを制限する対応有無
- 暗号化：保存時と通信時それぞれの対応状況
テレワークで社外から利用する場合は、認証や接続元の制限の重要性が一層高まります。また、要件には「必須・優先・将来」の優先度を付けます。
たとえば、二要素認証は必須、IP制限は優先として扱います。曖昧な要件は後のトラブルにつながりやすいため、具体的に書いて対応範囲を明確にします。
監査ログ・ガバナンスの要件
監査ログは、誰がいつ情報にアクセスし、何を変更したかを記録する仕組みです。情報漏えいの追跡や、内部統制の証跡として使います。
一次データとして、5,000名規模の金融機関や350名規模の自治体が情報共有基盤を導入した例があります。厳格なガバナンスが求められる組織では、ログが製品選定の決め手になることもあります。
- 記録対象：どの操作のログを残すか
- 保持期間と出力形式：必要な情報を取り出せるか
- アカウントと権限の管理：退職者の無効化や棚卸しができるか
RFPには、ログの保持期間と出力形式を書きます。記録は、必要なときに使える形でなければ意味が薄れます。そのため、導入後の運用まで見据えて要件を決めることが、実際に守れる仕組みを支えます。
外部連携とデータ移行・棚卸しの要件
情報共有システムは単独で完結せず、メールやカレンダー、ファイルサーバーなどと連携すると、現場の業務になじみます。さらに、既存システムからの移行も、要件定義の段階で詰めておきます。
移行範囲が曖昧なままだと、作業が想定以上に膨らみ、コストとスケジュールを圧迫します。
Google Workspace・Microsoft 365連携の要件
Google WorkspaceやMicrosoft 365を業務の土台にしている企業は多いため、連携の要件をRFPに書きます。
連携がスムーズだと、新しいシステムを別物と感じにくくなり、移行の心理的なハードルも下がります。
- アカウント：シングルサインオンでの一本化
- 予定と連絡先：カレンダーや連絡先の同期
- ファイル：既存ファイルの参照と編集
連携の要件は、範囲、方向、頻度まで具体的に書くと、認識のずれを防げます。なお、SFAやCRMを使っている場合は、それらとの連携も要件に含めます。
情報共有システムを既存の業務システム群に位置づけ、データがどう行き来するかを描くことで、要件定義の質が高まります。
既存データ移行と棚卸しルールの要件
既存のファイルサーバーや旧システムからのデータ移行は、要件定義の段階で必ず詰めておきます。
古い情報をそのまま移すと、検索の信頼性が損なわれます。移行は、データを新しい場所へ移す作業であると同時に、不要な情報を整理する機会でもあります。
- 移行対象：全件か、必要な情報に絞るかの判断
- 移行条件：形式、期間、支援範囲
- 運用後の棚卸し：見直しとアーカイブの担当・時期
最新で正しい情報を検索できる状態を保つことが、継続利用につながります。移行と棚卸しの要件は、導入の成否を長期的に左右します。
RFPの構成と見積りの妥当性を判断する軸
整理した要件をベンダーに示す文書が、RFP（提案依頼書）です。要件、優先度、評価軸を明確に示すと、ベンダーが的確な提案をできるようになります。
要望だけを並べると、各社が異なる前提で見積もるため、比較が難しくなります。
RFPに盛り込むべき項目とAI活用要件
RFPには、導入目的と現状課題を冒頭に置き、要件を機能、非機能、提案条件の面から整理して書きます。スケジュールも含めます。
- 機能要件：必須・優先・将来への分類
- 非機能要件：性能・セキュリティ・可用性の明示
- 提案条件：連携・移行・運用・予算・評価基準の盛り込み
機能要件を必須・優先・将来に分けると、ベンダーは最優先で実現すべき内容を判断しやすくなります。ただし、すべてを必須にすると見積りが膨らむため、本当に必要な要件を見極めておくことが欠かせません。
近年は、AI活用もRFPに含める項目になっています。課題に直結する場合は、議事録の自動文字起こし・要約、GeminiやCopilotとの連携、対話形式の検索を要件にします。
AI機能については、精度や誤変換時の業務への影響も確認します。流行を理由にせず、解決したい課題に応じて要件の要否を判断します。
見積りの妥当性とROIを判断する軸
見積りを判断するには、相場感をつかんでおく必要があります。クラウド型は初期費用0円が主流で、月額の中央値は1ユーザーあたり約600円です。
クラウド型の中心価格帯は、ワンコインから1,000円前後です。一方、パッケージ（オンプレ）型は、初期費用が1ユーザーあたり4,000〜12,000円です。
パッケージ（オンプレ）型の年額ランニング費用は、500〜2,000円程度が目安です。相場から大きく外れる見積りは、その理由を確認します。
- 相場との比較：方式ごとの初期費用と利用料
- ROI：削減できる時間と費用からみた回収可能性
- 総額：初期費用と利用期間中の費用の合計
時給2,000円で換算すると、月額800円のシステムは、1人あたり月24分の無駄を削減すれば回収できる計算になります。
毎日数分の調整や検索時間が短くなれば、全社で投資額を上回る効果が見込めます。総額は、初期費用に月額×人数×利用年数を足して算出します。
稟議では、このROIの考え方を使うと、投資の理由を説明できます。riplaは、フルスクラッチ受託の立場から、要件整理、RFP作成、見積り評価を発注者の視点で伴走します。
非機能要件と隠れた追加費用の確認
非機能要件には、同時アクセス時の性能や可用性があります。ほかに、障害時の復旧時間やスマートフォン対応なども含まれます。機能の華やかさにまぎれて、見落とされがちな項目です。
朝に全社員がアクセスすると重くなる、外出先のスマートフォンで使えないといった問題は、定着を妨げます。そのため、非機能要件も必須・優先・将来に分けてRFPに書きます。
- 容量追加：基本料金以外に必要な費用
- セキュリティとサポート：オプションや上位プランでかかる額
- 初期設定支援：導入時に別途発生する支払い
基本料金が安くても、総額では高くなることがあります。そこで、提案は追加費用を含む総額で比べます。
RFPでは、想定される追加費用をすべて明示するよう求めます。月額だけで比べると、費用が積み上がり、当初のROI試算が崩れることがあります。
さらに、IT導入補助金などを活用できるかも検討します。要件と費用を整理した段階で対象製品や構成を確認すれば、実質的な投資額を抑えられる可能性があります。
要件定義では、性能や可用性の要件を含めて、支払う総コストと得られる効果を見通しておきます。費用や補助金も考慮に入れます。丁寧な整理が、稟議と導入後の判断を支えます。
運用・定着を見据えた要件と進め方
機能やセキュリティに加えて、導入後も使われ続けるための要件も定義します。システムの成否は、導入後も利用が続くかどうかで決まるからです。
運用保守と定着支援の要件
RFPには、導入後の運用保守の要件を明記します。
- サポート：障害時の体制と問い合わせ対応時間
- 更新と教育：定期更新、操作研修、マニュアルの範囲
- 情報管理：古い情報の見直しとアーカイブの運用
情報管理の運用により、検索の信頼性を長期的に保てます。
現場が入力を続ける仕組みも検討します。入力されない原因は、操作の難しさではなく、入力する動機が乏しいことにある場合があります。
入力への貢献を評価にどう反映するか、管理職がどうフィードバックするかも、要件定義の段階から設計しておきます。運用まで考えておくと、導入が形骸化するのを抑えられます。
技術面の要件に加えて、人の行動を変える運用面の要件を扱います。入力と活用が続く仕組みは、定着の可能性を高めます。
無料トライアルと段階導入を前提にした進め方
RFPでベンダーを選んだあとは、全社一斉導入の前に、小規模に使い始める段階を設けます。実際に使うと、要件定義だけでは分からない使い勝手の問題が見つかります。
- 無料トライアルまたは一部署で試験運用する
- 現場の反応を確かめ、要件の過不足を修正する
- 必須機能から動かし、効果を検証する
- 優先・将来の機能を順に追加して本格展開する
段階導入を前提とすれば、要件にも優先順位を付けやすくなります。
試験運用で要件を直してから展開すれば、手戻りのリスクを減らせます。段階導入は、初期投資を抑えながら、現場の納得感を積み上げる進め方です。
要件定義は一度で終わるものではなく、トライアルと段階導入を通じて磨かれていきます。riplaは、フルスクラッチ受託の立場から、要件定義、段階導入、定着まで発注者の視点で伴走します。
まとめ
情報共有システムの要件定義は、導入目的と現状の可視化から始まります。そのうえで、情報ルーティング、権限・監査ログ、外部連携の要件を整理します。さらに、データ移行と棚卸し、AI活用の要件も押さえます。
機能要件は必須・優先・将来に分け、見積りはクラウド型の月額約600円という相場やROIを踏まえて判断します。網羅的なRFPは、提案の質を高め、比較もしやすくします。
要件定義では、機能よりも現場の情報の流れを起点に考えます。何を、誰のために、どう実現するかを言葉にします。曖昧な依頼は高価な失敗につながり、丁寧な要件整理は定着を支えます。
riplaは、フルスクラッチ受託と国内開発の立場から、要件定義、RFP作成、見積り評価を発注者視点で支援します。費用相場や製品の全体像は、あらためて完全ガイドでご確認ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。