CMMSの導入は、現状分析、要件整理、RFP作成の順に進めると、提案比較と手戻り防止につながります。保全業務は工場ごとに設備構成や保全ルールが異なり、現場慣行も積み重なっています。
本記事は要件定義に絞って解説します。全体像は設備保全管理システム（CMMS）の完全ガイドもご覧ください。
▼全体ガイドの記事
・設備保全管理システム（CMMS）の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現状分析と導入目的の要件化
要件定義は、機能を並べる前に、保全業務の現状分析と導入目的の明確化から始めます。「なぜCMMSを入れるのか」「どんな状態なら成功か」が曖昧なままだと、機能を足すだけになり、課題は解決できません。
AsIs/ToBeと保全方式（BM/TBM/CBM）の整理
現状分析では、点検・記録・故障対応・部品管理の流れを書き出します。
- AsIs：現在の保全業務と記録方法の実態
- ToBe：現状を踏まえて、CMMS導入後に実現したい状態
- 保全方式：BM・TBM・CBMそれぞれの目標と移行段階
現状を見ると、故障履歴の個人管理や点検漏れなどの課題が見つかります。
保全方式は、事後保全（BM）から時間基準保全（TBM）へ移るのか、センサーを使う状態基準保全（CBM）まで目指すのかを整理します。方式によって必要な機能が変わるため、現状はBM中心で、まずTBMを定着させ、将来は重要設備でCBMを導入するといった段階方針を記しておきます。この方針をもとに、後続の機能要件に優先順位をつけます。
対象設備・拠点・利用者範囲の定義
導入目的が定まったら、対象範囲（スコープ）を要件として定めます。
- 設備・拠点：対象工場やライン、設備台数、部品点数
- 利用者：保全員、生産部門、経営層などの対象者
- 導入範囲：初期対象と、効果確認後に広げる範囲
最初から全工場・全設備を対象にすると、設備マスターの整備だけで工数が膨らみ、導入が頓挫することがあります。そこで現実的なのは、初期フェーズを停止影響の大きい重要設備に絞り、効果を見てから範囲を広げる進め方です。
加えて、利用者ごとの役割も記しておきます。保全員は点検記録を入力し、管理者は計画立案と分析、経営層はKPIを閲覧します。
利用者範囲は、権限設計とライセンス費の見積もりに関わります。そのため、人数や利用場面が明確なら、ベンダーの見積もり精度も上がります。
範囲が曖昧なままRFPを出すと、ベンダーごとに前提の異なる見積もりが届きます。したがって、範囲を明確にしておくことが、公平な比較の前提になります。
機能要件・非機能要件の書き分け
要件定義書の中核は、機能要件と非機能要件です。機能要件はシステムの機能を、非機能要件は品質・性能・運用条件を定めます。両者を分けて書くことが、提案の比較しやすさと導入後の満足度を左右します。
必須・推奨・任意による機能要件の仕分け
まず、保全業務で使う機能ごとに必要な内容を洗い出し、優先度をつけます。
- 必須（MUST）：設備のQRコードから点検画面を開けること
- 推奨（WANT）：故障傾向のグラフによる分析
- 任意（NICE）：標準機能で対応できる範囲の検討
対象にするのは、設備台帳、保全計画、ワークオーダーです。点検記録や故障履歴も対象に含め、部品在庫とコスト管理も加えます。
すべてを必須にすると標準機能では足りず、カスタマイズが積み上がります。そのため、優先度の仕分けは、カスタマイズ費の膨張を防ぐ働きをします。
特に生産・保全系システムでは、カスタマイズ費が全体の3〜4割を占めることもあります。そこで、必須でない要件は標準機能の範囲で妥協する方針をRFPに示しておくと、現実的な提案を受けやすくなります。
非機能要件（性能・モバイル・セキュリティ）の明記
非機能要件は見落とされがちですが、CMMSの使い勝手を大きく左右します。このため、性能、モバイル、運用・安全の3点を、具体的に記しておきます。
- 性能：指定した設備台数・部品点数でも画面を数秒以内に表示
- モバイル：オフライン入力後、通信回復時に同期
- 運用・安全：保管場所、バックアップ、復旧目標、保守対応を明記
性能の水準を示しておくと、現場でストレスなく使えるかを、ベンダーに確認できます。工場特有の通信状況を踏まえて、オフライン対応と同期条件も要件に含めます。
クラウド型かオンプレミス型かを決め、データの保管場所とバックアップ頻度を定めます。障害時の復旧目標時間（RTO）、保守サポートの体制、対応時間も確認します。
さらに、クラウド型では、数年後のバージョンアップ費用と契約終了時のデータ持ち出しの可否を確認します。非機能要件に含めておくと、長期コストの想定外を防げます。
機能要件が「何ができるか」を示すのに対し、非機能要件は「安心して使い続けられるか」を担保します。
現場の利用シーンからの機能の逆算
機能要件は、現場の利用シーンから逆算して書きます。
- 点検前：保全員が当日の点検予定を確認する
- 点検中：QRコードの読み取りと結果の入力
- 異常時：写真の撮影と報告
利用シーンを要件にすると、現場で使う機能と自社では使わない機能を分けられます。加えて、手袋をしたまま操作できるか、騒音の中でも入力ミスが起きにくいかも確認できます。
この進め方によって、要件の抜け漏れと過剰を防ぎ、現場の業務に即した実用的な要件になります。また、利用者がいない高度な分析機能を必須として書いてしまう、といった事態も避けられます。
データ移行・Excel連携の要件定義
移行・連携は、見積もりの増加やトラブルが起きやすい領域です。特にExcel管理では、設備台帳・点検記録・故障履歴の移行と共存を要件にすることが、導入を円滑に進めるうえで欠かせません。
Excelとの共存・段階移行の要件化
要件定義では、Excelの完全脱却を理想として掲げがちです。ただし、既存の台帳やマクロ、帳票に蓄積された業務知識を失うと、現場が混乱することがあります。
- データ入出力：設備マスターや点検履歴のCSVによる取り込みと書き出し
- 帳票：既存の帳票のExcel形式での出力
- 運用移行：Excelを残しつつ、記録をCMMSで一元的に管理する
CSVの文字化けや列ズレがあると、変換のたびに手作業が発生し、工数が増えます。そのため、RFPでは、自社のExcel形式で文字化けや列ズレなく直接入出力できるかを確かめておきます。
Excelとの共存を前提に段階移行を要件化すると、現場の混乱を抑えて定着率を高められます。
既存システム・IoT連携と移行範囲の線引き
ERPや生産管理システム、IoTセンサーとの連携は、初期に実装するか、将来対応にするかを決めます。
- 購買連携：部品の発注を既存の購買システムにつなぐ
- 設備データ：IoTセンサーからの稼働データの取り込み
- 過去記録：移行する履歴と、参照用に残す記録の振り分け
連携はコストも難易度も高いため、必須でないものを初期に加えると、予算や納期を圧迫します。
過去の故障履歴を何年分移すか、紙の記録をどこまでデータ化するかも、決めておく必要があります。たとえば、直近3年分だけを移し、それ以前は参照用PDFで保管する方法があります。
設備を熟知する自社の保全員がマスター登録やデータ整備を担えば、外部委託費を削減できます。
最後に、何を移行し、何を自社で内製化し、何をベンダーに任せるかを、発注側で線引きします。
RFP（提案依頼書）の構成と評価基準
RFP（提案依頼書）は、要件定義の内容を、ベンダーへの提案依頼の形にまとめた文書です。自社の背景・目的・要件・制約・評価基準を伝えると、提案を比較しやすくなります。
RFPに盛り込むべき構成要素
CMMSのRFPには、提案の前提と回答項目をそろえて記します。そうすると、ベンダーは同じ条件で提案を作れます。
- プロジェクト：背景・目的・対象範囲（設備、拠点、利用者）
- 要件：優先度付き機能、性能・モバイル・セキュリティ・運用、移行・連携
- 提案条件：日程・予算、実績・体制・保守、見積もり内訳など回答項目
とくに見積もりは、内訳を明示するよう求めます。ライセンス費、導入支援費、カスタマイズ費に分けてもらい、ハードウェア費と保守費も別に示してもらいます。
費目ごとに分けると、コストのかかる部分が分かり、削減の余地も検討できます。RFPは、コスト構造を透明にする道具です。また、マスター登録や現場教育を自社で内製化する前提も、RFPに明記しておきます。
コンサル費は人月単価が100〜200万円に達することがあります。そのため、内製化できる作業を見積もりから外すと、導入費を3割程度抑えられる可能性があります。
評価基準とPoC（実機検証）条件の明記
価格だけで選ぶと、安くても現場に合わないシステムを選ぶおそれがあります。
- 適合性：機能の適合度と将来の拡張性
- 現場対応：使いやすさと保全分野での導入実績
- 支援：保守サポートの手厚さ
評価軸に重みをつけて点数化すると、選定を客観的に進められます。さらに、基準を事前に社内で合意しておけば、選定後にベンダーを選んだ理由も説明できます。
契約前にPoC（実機検証）を行う条件も、RFPに盛り込むことを推奨します。
- 自社の代表設備と実際の保全データを用意する
- 典型的な点検フローがそのまま進むか確かめる
- 自社のデータ量でも表示速度が落ちないかを確認する
- マニュアルなしで現場が操作できるかを試す
実機で検証してから決めれば、導入後の認識違いを防げます。要件定義、RFP、PoCを丁寧に進めることが、CMMS導入の失敗確率を大きく下げます。
スケジュール・体制・補助金要件の記載
RFPには、想定スケジュールと社内外の推進体制も明記します。
- 日程：稼働日、設備マスター整備、PoCの期間
- 体制：自社の推進担当者、現場のキーパーソンとそれぞれの責任
- 補助金：対象経費と申請支援の要否
CMMS導入は一般に、要件定義から稼働まで3〜6カ月程度かかります。そのため、マイルストーンを示しておくと、ベンダーは現実的な提案体制を組めます。
補助金を使う場合は、対象経費の区分や事業計画書の作成支援を、ベンダーに依頼できるかを確認します。
補助金は補助率1/2〜2/3で初期負担を軽減できます。ただし、公募要領は年度ごとに変わります。
申請の日程と導入計画は、すり合わせておきます。そのうえで、日程・体制・補助金までRFPに記すと、提案精度が上がり、導入後の運営にも役立ちます。
まとめ
CMMSの要件定義は、現状分析と目的の明確化から始め、対象範囲、機能・非機能要件、データ移行、連携条件へ進みます。
保全方式の方針が、機能の優先順位を決めます。必須・推奨・任意の仕分けは、カスタマイズ費の膨張を防ぎます。
Excelとは共存しながら段階的に移行する要件にすると、現場の定着を支えます。さらに、見積もり内訳と内製化の切り分けで、導入費を3割程度抑えられる可能性があります。
機能を増やすより、現場の保全業務から優先順位をつけ、内製化する作業とベンダーに任せる範囲を決めます。
評価基準とPoCは、導入後の「思っていたのと違う」を防ぎます。RFPは要件を公平に比べ、PoCは実機で確かめる最後の関門です。
riplaは、フルスクラッチ受託と国内開発の立場から、保全業務に沿った要件整理と、現場に定着するシステムづくりを一貫して支援しています。
要件定義の全体像は、設備保全管理システム（CMMS）の完全ガイドをご覧ください。
▼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を創業。