発注企業の視点からナレッジマネジメントシステムのRFP（提案依頼書）や要件定義書を具体化するには、導入目的を起点に、情報の届け方から権限、連携、データ移行までの要件を詰めていきます。その積み重ねが、業務に定着する基盤につながります。
▼全体ガイドの記事
・ナレッジマネジメントシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
導入目的と情報ルーティングの要件定義
発注側は、RFPの冒頭で最も重要な導入目的を言葉にして書きます。「ナレッジを共有したい」といった書き方では目的が曖昧なため、提案を比べにくく、現場に合わないシステムになりかねません。
たとえば、退職者の暗黙知の継承、問い合わせ対応の標準化、検索時間の短縮などのうち、どれを最優先にするかを決めます。目的が定まれば、情報を誰にどう届けるかというルーティング要件も具体化できます。
現状業務とToBe像の要件化
要件定義では、現場へのヒアリングをもとに、現状（AsIs）と目指す姿（ToBe）を順に整理します。
- 誰がどんな知識を持ち、情報がどこにあり、いつ探され、どこで詰まるかを洗い出す
- あるべき姿を描き、現状との差を埋める機能を決める
- RFPには「現状はこうで、こう変えたい」という流れを書き込む
現状を見ないまま要件を書くと、机上の理想論になり、現場で使われないシステムになりかねません。投資額を大きくすれば成功するとも限りません。
こうした背景がRFPに書かれていれば、ベンダーは機能の一覧ではなく、業務改善の文脈で提案できます。riplaがフルスクラッチ受託で重視するのも、現場業務から逆算する設計です。
要件定義では、機能を並べるだけでなく、業務をどう変えるかを定めます。その視点が、定着するシステムへの第一歩になります。
情報ルーティング（誰に・どのチャネルで）の要件
情報ルーティングでは、誰に、どのチャネルで情報を届けるかを定めます。ナレッジの蓄積が進むほど、無関係な通知やメンションが増え、通知疲れが起きることがあります。
- 通知対象：タグやフォロー単位で、通知を届ける範囲を絞る
- 通知チャネル：重要度に応じて届け方を分ける
- 受信設定：ユーザーごとに、受け取る情報を選べるようにする
全員にすべてを通知する設計では、結局誰も通知を見なくなります。貯める機能と同じく、届け方の設計も定着を左右します。
誰に届けるかが曖昧なまま開発を進めると、通知が多すぎて現場が離れ、ナレッジが参照されなくなるおそれがあります。要件定義の段階で届け先を詰めておくことが、形骸化を防ぐ予防になります。
権限・監査ログとセキュリティの要件定義
ナレッジには機密情報も含まれるため、誰が何を見られるかを制御する権限と、操作を記録する監査の要件が欠かせません。求める水準は、中小企業と大企業で異なります。
自社の規模や方針を踏まえて、過不足のない水準を定めます。とくに、権限や監査ログを後から足すと、大きな手戻りになることがあります。
権限設計・アクセス制御の要件
権限要件では、閲覧・編集・公開を誰にどの範囲まで許可するかを定めます。論点は、部署・役職・プロジェクト単位で制御するか、機密情報をどう限定して共有するかです。
人事や経営情報は限られたメンバーに、業務手順は全社に公開するなど、情報ごとに使い分けられる柔軟な設計が必要です。
入社・異動・退職に伴う権限の変更も、要件に含めておきます。異動後も古い部署の権限が残ったり、退職者のアカウントが放置されたりすると、漏洩のリスクになります。
- アカウント管理：人事システムとの連動の可否
- 権限の棚卸し：定期的に見直せる仕組みの有無
- 管理する粒度：部署や役職など、運用できる単位で区切る
権限は一度設定して終わりではなく、組織の変化に合わせて保っていく必要があります。この前提で要件化しておくと、長期的なガバナンスを支えられます。
記事ごとに権限を個別に設定すると、運用が破綻しやすく、現実には維持できません。
権限が緩すぎれば漏洩のリスクがあり、厳しすぎれば共有が進みません。機密区分を整理し、運用できる範囲で要件を定めることが、両立の鍵になります。
監査ログ・二要素認証・暗号化の要件
監査ログは、誰がいつナレッジにアクセスし、編集したかを記録します。漏洩時の追跡や内部統制の証跡として求められるため、RFPには次の項目を要件として書き込みます。
- 監査ログ：記録する操作と期間、参照や出力の方法
- アクセス保護：自社の方針に合わせて、二要素認証やIP制限を指定する
- 暗号化：通信データと保存データの扱い
- クラウドの提供範囲：ベンダーの標準機能と追加費用の境い目
監査ログや暗号化は基盤の設計に関わるため、要件定義の段階で確定させます。セキュリティ関連のオプションは、追加費用になることもあります。
自社のガバナンス基準を満たす最低ラインを決め、過剰でも過少でもない水準に収めることが大切です。
外部連携とAI活用の要件定義
連携とAI活用は、ナレッジを孤立させず業務の流れの中に置くための重要な要件です。何と、どのように連携するか、AIに何を期待するかを具体化しておきます。
Google Workspace・Microsoft 365連携の要件
Google WorkspaceやMicrosoft 365を業務基盤にしている企業は多くあります。そのため、必要な連携を具体的に挙げ、「連携できること」だけの曖昧な指定は避けます。
- 認証：シングルサインオンによるログイン
- 既存資料：既存のドキュメントを取り込めること
- 日常ツール：カレンダーやチャットとの連動
連携の範囲が曖昧だと、ベンダーごとに想定がずれ、提案を比べられません。さらに、SFAやCRMなど既存の業務システムとの連携も検討しておきます。
顧客対応のナレッジを営業システムから参照できれば、商談の質が上がります。RFPには、連携するシステム、連携の方向、データを明記し、必要なAPIや方式を踏まえた提案を求めます。
後から連携すると工数がかさむため、対象システムと優先度は初期の要件定義で確定させます。追加費用と手戻りを防ぐことにつながります。
AI（Gemini・Copilot）活用の要件
AIを使う場合は、用途とデータ保護の要件を明確にします。使い方によって必要な機能が変わるため、RFPには具体的に記載します。
- 用途：自然言語での質問応答、議事録や資料の要約、投稿への自動タグ付け
- 回答の根拠：自社に蓄積したナレッジに基づく回答
- データ保護：機密情報の扱いと、入力データを外部学習に使わないこと
「AI対応」とだけ書くと、自社のナレッジに基づかない汎用AIが提案されるおそれがあります。参照できる良質なナレッジがなければ、AIは実力を発揮できません。
AIを目的にせず、蓄積・検索・定着の基本要件を満たしたうえで上乗せしていきます。過度な期待で要件を膨らませないことも大切です。
提案を比較可能にするRFPの書き方
連携やAIの要件が増えるほど、提案の前提はずれやすくなり、比較も難しくなります。そこで、「できること」を漠然と並べるのではなく、要件と評価軸をRFPで明示します。
- 要件の分類：「必須」と「あれば望ましい」に分け、それぞれに優先度を付ける
- 評価軸：費用、機能適合度、連携範囲、サポート体制、定着支援
- 重み付け：評価軸ごとに、重要度の差を明示する
ベンダーは重視する点を踏まえて提案でき、発注側も同じ条件で比べられます。評価の観点を示すと、提案の質もそろえやすくなります。
RFPは、ベンダーに示すだけでなく、発注側が何を重視するかを整理する過程でもあります。さらに、明確な基準は、提案の比較と社内の合意形成を助け、ベンダー選定の精度を高めます。
既存データ移行と棚卸しルールの要件定義
既存のファイルサーバや旧システム、個人のExcelに、情報が散在しています。何を移行し、移行後にどう鮮度を保つかが、定着を左右します。
データ移行と棚卸しのルールは軽視されがちですが、重要な要件です。移行だけでなく、その後の管理まで定めておきます。
データ移行の範囲・形式・期間の要件
移行要件では、何をどの形式で、いつまでに移すかを定めます。論点は、エクスポート形式と対象データの範囲、期間、ベンダーの支援体制です。
過去資料をすべて移すか、直近で使う資料に絞るかによって、工数と費用は大きく変わります。そこでRFPには、概算のボリュームと優先度を記し、現実的な計画を求めます。
「全部移す」を前提にせず、棚卸しとあわせて今も使われている情報を選びます。古い情報や誤った情報を移すと、新しいシステムが陳腐化した情報で埋まり、検索しても使えなくなります。
今も使われている情報かどうかは、自社で判断します。この作業に必要な工数も要件に織り込み、移行をベンダー任せにしないことが大切です。
- 移行できない場合：旧システムを参照用に残すか、PDFなどで保管する
- 移行後の検証：データが正しく引き継がれたかどうか
移行は、データを移して終わりではありません。移行後に正しく使える状態になるまでを要件に含めておくと、リリース直後の混乱を防げます。
エクスポート形式と移行範囲、検証手順、代替策を文書にして明確にすることが、移行の失敗を避ける要点です。
棚卸し・ライフサイクル管理のルール要件
古い情報や誤った情報ばかりでは、検索結果への信頼が失われます。更新・削除・アーカイブの担当を決めておくことは、競合製品でもカバーされにくい運用の盲点です。
棚卸しの仕組みがないと、システムは数年で陳腐化します。そのため、鮮度を保つルールをRFPに組み込みます。
- 更新確認：一定期間更新のない記事を検出し、担当者に見直しを促す
- 古い情報：アーカイブして、検索結果から外す
- 更新責任：記事ごとの責任者
誰がいつ棚卸しするかは、あらかじめ決めておきます。riplaは、フルスクラッチ開発と業務への伴走の立場から、ナレッジが回り続ける設計を要件定義の中核に置いています。
棚卸しを要件に含めることが、信頼され続けるナレッジ基盤の条件です。
非機能要件（性能・可用性・サポート）の定義
機能要件と並んで、見落とすと後悔しやすいのが非機能要件です。機能要件だけでは、導入後の使い勝手は決まりません。検索の速さや安定性、サポートの体制といった品質面の要件を、次の項目でRFPに具体化しておきます。
- 性能：検索速度と、全社が同時にアクセスしたときの動作
- 可用性：障害からの復旧時間やデータのバックアップ体制
- サポート：問い合わせへの対応時間と、障害時の連絡の流れ
- 定着支援：トレーニングと、導入後の伴走の範囲
性能が低かったり障害が多かったりすると、機能が優れていても使われなくなるおそれがあります。このため、品質面の要件は現場での使いやすさを左右します。
ナレッジマネジメントは、導入後も使われ続けて価値が出ます。運用時の伴走範囲を確認しておくと、立ち上げ期の挫折を防げます。
また、稼働率の目安もRFPに盛り込みます。機能だけで判断しないことが、長く使えるシステムを選ぶことにつながります。
まとめ
RFPでは、導入目的とToBe像を起点に、各要件を自社の業務に即して定めます。対象は、情報ルーティングと権限・監査、外部連携とAIです。さらに、データ移行と棚卸しも要件に含めます。
通知疲れを防ぐ設計と、情報の陳腐化を防ぐ棚卸しは、定着を左右する要件です。機能だけでなく、業務の変化とナレッジの継続的な運用も書き込みます。
RFPは、提案の比較や見積の妥当性の判断、導入後の手戻りの防止に使う設計図です。現場の現状を把握し、目的から要件を整理すれば、机上の理想論を避けられます。
riplaは、フルスクラッチ受託と国内開発の立場から、要件定義の伴走と、現場に定着するナレッジ基盤の設計・構築を一貫して支援しています。
要件全体の前提となる費用相場や選び方は、完全ガイドであらためてご覧ください。
▼全体ガイドの記事
・ナレッジマネジメントシステムの完全ガイド
▼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を創業。