設備保全管理システム（CMMS）のRFP/要件定義書/提案依頼書について

設備保全管理システム（CMMS）の導入を成功させられるかどうかは、製品選びそのものよりも、その前段にある要件定義とRFP（提案依頼書）の質で決まると言っても過言ではありません。保全業務は工場ごとに設備構成も保全ルールも大きく異なり、現場の慣行が積み重なってできています。この実態を要件として言語化しないままベンダーに開発や提案を依頼すると、出来上がったシステムが現場と噛み合わず、カスタマイズ費が膨張し、最悪の場合は使われずに放置されます。逆に、要件定義とRFPを丁寧に作り込めば、ベンダーからの提案を正しく比較でき、導入後の手戻りも防げます。

本記事は、設備保全管理システム（CMMS）の要件定義書とRFP（提案依頼書）の作り方を、項目立てと記述のポイントに沿って具体的に解説する「要件定義特化」の記事です。保全方式や設備対象範囲をどう要件化するか、機能要件・非機能要件をどう書き分けるか、Excel・既存システムとのデータ移行や連携をどう要件に盛り込むか、RFPにどんな評価基準とPoC条件を載せるかまで、実務で使える粒度で掘り下げます。読み終えるころには、自社のRFPに何を書けばベンダーから精度の高い提案が引き出せるかが見えるはずです。なお、CMMSの全体像をまだ把握していない方は、まず設備保全管理システム（CMMS）の完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・設備保全管理システム（CMMS）の完全ガイド

現状分析と導入目的の要件化

要件定義の出発点は、機能の羅列ではなく、現状の保全業務の分析と導入目的の明確化です。「なぜCMMSを入れるのか」「どんな状態になれば成功なのか」が曖昧なまま要件を書き始めると、機能の足し算だけが進み、本来の課題を解決できないシステムになります。まずは現状（AsIs）の保全業務を可視化し、あるべき姿（ToBe）を描くことから始めます。

現状分析では、現在の保全業務がどう回っているかを具体的に書き出します。点検は誰がどんな頻度で行い、記録は紙かExcelか、故障時はどう対応し、部品はどう管理しているか。こうしたAsIsを可視化すると、「故障履歴が個人のファイルに散在している」「点検漏れが起きている」といった課題が浮き彫りになります。そのうえで、CMMS導入後にどう変えたいか（ToBe）を描きます。

あわせて整理すべきが、目指す保全方式です。事後保全（BM）中心の現状から、時間基準保全（TBM）へ移行するのか、さらにセンサーを使った状態基準保全（CBM）まで視野に入れるのか。目指す保全方式によって必要な機能が変わるため、要件定義書には「現状はBM中心、まずTBMを定着させ、将来的に重要設備でCBMを導入する」といった段階的な方針を明記します。この方針が、後続の機能要件の優先順位を決める軸になります。

導入目的を定めたら、対象範囲（スコープ）を要件化します。どの工場・どのラインの設備を対象にするか、設備台数や部品点数はどの程度か、利用者は保全員だけか、生産部門や経営層も使うのかを明記します。最初から全工場・全設備を対象にすると、設備マスターの整備だけで膨大な工数がかかり、導入が頓挫しがちです。要件定義の段階で「初期フェーズは停止影響の大きい重要設備に限定し、効果を確認してから拡大する」というスモールスタートの方針を示すことが、現実的かつ重要です。

利用者範囲を明確にすることは、後の権限設計やライセンス費の見積もりにも直結します。現場の保全員は点検記録の入力、保全管理者は計画立案と分析、経営層はKPIの閲覧、といった役割ごとの利用シーンを書き出しておくと、ベンダーは必要な機能とユーザー数を正確に把握でき、見積もりの精度が上がります。スコープを曖昧にしたままRFPを出すと、ベンダーごとに前提が異なる見積もりが返ってきて、比較が成り立たなくなります。範囲の明確化は、提案を公平に比較するための前提条件です。

機能要件・非機能要件の書き分け

要件定義書の中核が、機能要件と非機能要件です。機能要件は「システムが何をできるか」、非機能要件は「どれくらいの品質・性能・運用条件で動くか」を定義します。CMMSの要件定義では、この両者を明確に書き分けることが、提案の比較しやすさと導入後の満足度を大きく左右します。

機能要件は、設備台帳・保全計画・ワークオーダー・点検記録・故障履歴・部品在庫・コスト管理といった機能ごとに、自社に必要な要件を書き出します。このとき重要なのが、すべてを横並びにせず、「必須（MUST）」「推奨（WANT）」「任意（NICE）」のように優先度を仕分けることです。たとえば「設備に貼ったQRコードを読み取って点検画面を開けること」を必須、「故障の傾向をグラフで分析できること」を推奨、といった具合に分けます。

この優先度仕分けが、カスタマイズ費の膨張を防ぐ歯止めになります。すべてを必須にすると、標準機能で対応できない部分が増え、カスタマイズが積み上がります。生産・保全系システムではカスタマイズ費が全体の3〜4割を占めることもあり、ここをいかに抑えるかが予算管理の肝です。「必須でない要件は標準機能の範囲で妥協する」という線引きをRFPで示せば、ベンダーも標準機能を活かした現実的な提案をしやすくなります。要件は多ければよいのではなく、優先度をつけて絞ることに価値があります。

非機能要件は見落とされがちですが、CMMSの使い勝手を大きく左右します。性能面では「設備台数◯台・部品点数◯点のデータ量でも、点検画面の表示が数秒以内に開くこと」といった具体的な水準を示します。現場でストレスなく使えるかは、この性能要件で決まります。モバイル対応も非機能要件として重要で、「現場でオフラインでも入力でき、通信が回復したら同期できること」といった工場特有の条件を明記します。

セキュリティと運用条件も忘れてはいけません。クラウド型かオンプレミス型か、データの保管場所、バックアップの頻度、障害時の復旧目標時間（RTO）、保守サポートの体制と対応時間といった要件を定義します。とくにクラウド型を検討する場合は、数年後のバージョンアップ費用や、契約終了時のデータの持ち出し可否まで非機能要件に含めておくと、後述する長期コストの想定外を防げます。機能要件が「何ができるか」なら、非機能要件は「安心して使い続けられるか」を担保する条件群だと言えます。

機能要件を書くとき、機能リストを上から埋めるのではなく、現場の利用シーンから逆算することをおすすめします。「保全員が朝、その日の点検予定を確認する」「設備の前でQRコードを読み取り、点検結果を入力する」「異常を見つけたら写真を撮って報告する」といった具体的な業務の流れを書き出し、それを支える機能を要件化するのです。この進め方をすると、現場で本当に使われる機能と、カタログにはあるが自社では使わない機能を、明確に切り分けられます。

利用シーンから逆算する利点は、要件の抜け漏れと過剰の両方を防げる点にあります。机上で機能リストを眺めているだけでは気づかない「点検中に手袋をしたまま操作できるか」「騒音の中でも入力ミスが起きにくいか」といった、現場ならではの要件が見えてきます。逆に、誰も使わない高度な分析機能を必須に入れてしまう過剰も避けられます。要件定義は現場の業務に立脚してこそ実用的になります。利用シーンを起点に置くことが、現場に使われる要件を書く確実な方法です。

データ移行・Excel連携の要件定義

CMMS導入で見積もりが膨らみやすく、トラブルにもなりやすいのが、データ移行と既存システム・Excelとの連携です。多くの工場は、設備台帳や点検記録、故障履歴をExcelで管理してきました。これらをどう移行し、既存のExcel運用とどう共存させるかを要件定義で詰めておくことが、導入をスムーズに進める鍵になります。

要件定義でありがちな失敗が、「Excelを完全に脱却する」という理想論を掲げてしまうことです。現実には、既存のExcel台帳やマクロ、帳票レイアウトには長年の業務知識が詰まっており、一気に捨てると現場が混乱します。むしろ、CMMSとExcelを賢く共存させる方が定着は進みます。要件としては「設備マスターや点検履歴をCSVで取り込み・書き出しできること」「既存の帳票をExcel形式で出力できること」を明記します。

とくに注意したいのが、CSVのやり取りで起きる文字化けや列ズレです。CSV変換のたびに手作業の修正が必要になると、かえって工数が増えてしまいます。RFPには「文字化けや列ズレなく、自社のExcel形式でダイレクトに入出力できるか」を確認項目として盛り込むとよいでしょう。Excel完全脱却を目標にするのではなく、現場が慣れたExcelを残しつつ、記録の一元管理だけCMMSに集約する。この現実的な段階移行を要件化することが、定着率を高める実践的な工夫です。

既存のERPや生産管理システム、IoTセンサーとの連携要件も、要件定義で線引きしておきます。たとえば「部品の発注は既存の購買システムに連携する」「設備の稼働データはIoTセンサーから取り込む」といった連携を、初期フェーズで実装するのか、将来対応とするのかを明記します。連携はコストと難易度が高い領域なので、必須でないものを初期に詰め込むと、予算と納期を圧迫します。

過去データの移行範囲も重要な論点です。何年分の故障履歴を移行するのか、紙の記録はどこまでデータ化するのかを決めないと、移行作業が際限なく膨らみます。「直近3年分の故障履歴のみ移行し、それ以前は参照用にPDFで保管する」といった割り切りを要件化すると、移行コストを抑えられます。このマスター登録やデータ整備の一部は、設備を熟知した自社の保全員が内製化することで、外部委託費を削減し、見積もりから除外できる部分でもあります。何を移行し、何を内製化し、何をベンダーに任せるかの線引きが、要件定義の腕の見せどころです。

RFP（提案依頼書）の構成と評価基準

要件定義の内容を、ベンダーに提案を依頼する形にまとめたものがRFP（提案依頼書）です。RFPの出来が、返ってくる提案の質と、その後の比較・選定のしやすさを決めます。良いRFPは、自社の背景・目的・要件・制約・評価基準を過不足なく伝え、ベンダーが的確な提案をしやすいよう設計されています。

CMMSのRFPには、次の要素を盛り込みます。プロジェクトの背景と目的、対象範囲（設備・拠点・利用者）、機能要件（必須・推奨・任意の優先度付き）、非機能要件（性能・モバイル・セキュリティ・運用）、データ移行・連携の要件、想定スケジュールと予算感、そして提案に記載してほしい項目（実績、体制、保守内容、見積もり内訳）です。これらを整理して示すことで、ベンダーは前提を揃えた提案を作れます。

とくに見積もりは、内訳を明示するよう求めることが重要です。ライセンス費・導入支援費・カスタマイズ費・ハードウェア費・保守費を分けて提示してもらえば、どこにコストがかかっているかが見え、削減の余地を検討できます。マスター登録や現場教育を自社で内製化する前提も、RFPに明記しておくとよいでしょう。コンサル費は人月単価100〜200万円に達することもあり、内製化できる部分を切り出して見積もりから外すだけで、導入費を3割程度抑えられる可能性があります。RFPは、こうしたコスト構造を透明化するための道具でもあります。

RFPには、提案をどう評価するかの基準も示します。価格だけで選ぶと、安くても現場に合わないシステムを掴むリスクがあります。機能の適合度、現場の使いやすさ、保全分野での導入実績、保守サポートの手厚さ、将来の拡張性などを評価軸に設定し、それぞれに重みをつけて点数化すると、選定が客観的になります。評価基準を事前に社内で合意しておけば、選定後に「なぜこのベンダーなのか」を説明しやすくなります。

そして、契約前にPoC（実機検証）を行う条件をRFPに盛り込むことを強く推奨します。PoCでは、自社の代表設備と実際の保全データを使い、「典型的な点検フローがそのまま流れるか」「自社のデータ量でも表示速度が落ちないか」「マニュアルなしで現場が触れるか」を検証します。机上の提案だけで決めず、実機で確かめることで、導入後の「思っていたのと違う」を防げます。要件定義からRFP、PoCまでを丁寧に踏むことが、CMMS導入の失敗確率を大きく下げる最善の保険になります。

RFPには、想定するスケジュールと推進体制も明記しておきます。一般にCMMSの導入は、要件定義から稼働まで3〜6カ月程度を要します。いつまでに稼働させたいか、設備マスター整備をいつ始めるか、PoCをどの期間で行うかといったマイルストーンを示すと、ベンダーは現実的な提案体制を組めます。自社側の推進担当者や、現場のキーパーソンを誰が務めるかも示しておくと、プロジェクトの責任分担が明確になります。

補助金の活用を見込む場合は、その要件もRFPに織り込みます。IT導入補助金などを使うなら、補助対象となる経費の区分や、申請に必要な事業計画書の作成支援をベンダーに求められるかを確認します。補助金は補助率1/2〜2/3で初期負担を軽減できますが、年度ごとに公募要領が変わるため、申請のスケジュールが導入計画と整合しているかが重要です。スケジュール・体制・補助金まで含めてRFPに記載することで、提案の精度が上がり、導入後のプロジェクト運営もスムーズになります。

まとめ

設備保全管理システム（CMMS）の要件定義とRFPは、現状分析と導入目的の明確化から始まり、対象範囲の定義、機能要件・非機能要件の書き分け、データ移行・Excel連携の要件化、そしてRFPの構成と評価基準・PoC条件の設定まで、一連の流れで作り込むことが大切です。保全方式の方針が機能の優先順位を決め、機能要件を必須・推奨・任意に仕分けることがカスタマイズ費の膨張を防ぎ、Excelの完全脱却ではなく共存・段階移行を要件にすることが現場の定着を支えます。見積もりの内訳明示と内製化の切り分けは導入費の3割削減につながり、評価基準とPoCの設定が「思っていたのと違う」という失敗を未然に防ぎます。

要件定義で最も大切なのは、機能を多く盛り込むことではなく、現場の保全業務の実態から逆算して優先順位をつけ、何を内製化し何をベンダーに任せるかを線引きすることです。RFPはその要件を公平な比較が成り立つ形に整える道具であり、PoCはそれを実機で検証する最後の関門です。riplaはフルスクラッチ受託と国内開発の立場から、保全業務から逆算した要件整理と、現場に定着するシステムづくりを一貫して支援します。要件定義の全体像を確認する際は、あらためて完全ガイドをご活用ください。

株式会社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を創業。