Pleasanterの発注は、業務の整理、発注形態の選択、要件・契約・費用・委託先の検討という順に進めると、費用と納期を見通しやすくなります。
発注形態は社内の設定人材や外部連携の有無で選び、RFPは自社要件を整理する設計図として、後の比較の前提になります。
▼全体ガイドの記事
・Pleasanterのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Pleasanterのシステム開発を発注する前に知るべき全体像
Pleasanterは、テーブルと項目を組み合わせて業務アプリを作るノーコード／ローコード開発基盤です。案件管理や設備台帳、申請、問い合わせ、点検、在庫などに向いていて、完成済みの業務パッケージをそのまま使う製品ではありません。
Excelや紙の台帳をWebデータベースへ移したい企業で活用されます。特に、業務ルールとデータ構造の設計が発注の成否を左右します。
標準機能と追加開発の境界の決め方
標準機能で対応できる範囲を把握しておくと、どこから追加開発が要るか、保守への影響も見極めやすくなります。その領域は、項目・検索、データ操作、画面・管理、業務機能の4つにまとまっています。
- 項目・検索：項目カスタマイズ、検索・フィルタに対応します。
- データ操作：インポート・エクスポート、変更履歴、リンク・ルックアップを使えます。
- 画面・管理：アクセス制御、集計、カレンダー、ガントチャート、カンバンがあります。
- 業務機能：通知やワークフローを利用できます。
入力チェックや自動採番、複数テーブルの更新は、スクリプトやAPIで拡張できます。外部サービスへの通知も拡張の対象になります。ただし、最初から拡張を前提にすると保守が難しくなります。
追加開発の要否を判断したうえで、RFPでは各要件を「標準設定」「画面スクリプト」「サーバスクリプト」「API・外部製品」「対象外」に分類します。
小規模PoCと全社基盤の発注条件の違い
1〜3テーブルで一部門の台帳を試すPoCなら、短期の設定支援とCSV取込だけで始められる場合があります。
一方、複数部門の業務基盤では、認証連携や権限、監査ログのほか、障害復旧や運用ルールも設計対象です。バックアップや性能、教育も含まれます。
無料版や低価格SaaSで始められても、企業導入の総額が安くなるとは限りません。そのため、「最初に検証する範囲」と「本番運用で満たす条件」を分けて考えます。
発注形態の選択肢：内製・伴走支援・一括委託
発注形態は、社内に設定を担える人材がいるか、業務要件を言語化できるか、外部連携やセキュリティ審査があるかで選びます。
検証段階は内製か伴走支援で進め、本番化で不足する設計・移行・連携だけを外注する方法があります。一括委託を選ぶ場合も、納品後に社内で変更できる範囲を契約に含めます。
標準機能中心の小さな業務から始める内製
内製が合うのは、対象業務が一つで既存データが整理され、業務担当者が画面や項目を試せる場合です。
社内でサイトを作る一方、ベンダーに頼むのは初期設計レビューと権限設計、移行相談、教育だけです。こうすると、業務知識を社内に残せます。
担当者が異動しても運用が続くよう、サイト構成や命名規則を文書にまとめます。また、変更申請とテスト環境の使い方も、同じ文書に含めます。
内製化と専門知識を両立する伴走支援
伴走支援では、社内チームが設定と開発を担い、外部専門家が設計レビューや技術相談を受け持ちます。社内に業務知識があり、進め方を補いたい企業向けです。
公式技術支援サービスでは、テーブル設計やアクセス権限のほか、スクリプト構成と外部連携方式のレビューも支援内容に示しています。
発注時は相談回数だけでなく、レビュー対象と成果物、回答期限を確認します。さらに、サンプルコードの権利と利用範囲も確かめておきます。
成果物と責任分界を細かく定める一括委託
一括委託は、要件定義から運用開始までを一社に任せる方法です。設計や構築、移行に加えて、テストと教育も含まれます。
一括委託が合うのは、社内IT人材が不足する場合や、認証やAPI、帳票、複数拠点を同時に進める場合です。ただし、業務部門がレビューを怠ると、使われない画面や過剰なカスタマイズが増えます。
契約書とRFPには、納品物と受入条件、移行対象を明記します。そのうえで、障害対応と引き継ぎ、追加変更の扱いも書きます。
RFPと要件整理で具体化する業務・データ・運用
RFPは希望を伝える資料であり、自社要件を整理する設計図です。提案の前提をそろえるには、「使いやすい台帳」という言い方より具体的な条件が要ります。
RFPには、現行業務と利用者、データ量を記載します。例外処理や連携、セキュリティに加えて、納期や予算の考え方も盛り込みます。特に、業務フローと受入基準を示すと、画面一覧だけの場合より見積もりの漏れを抑えられます。
現状・理想・効果に分けた業務要件
現状・理想・効果を分けて書くと、受入テストと導入後の評価につながる要件になります。現状には担当者や使っているファイル・紙、承認の流れを、理想には一元管理する情報と検索・通知のルールを、効果には入力時間や承認日数などのKPIを書きます。
- 現状：担当者、使用するファイルや紙、承認の流れ
- 理想：一元管理する情報、検索・通知・承認のルール、閲覧者と編集者の違い
- 効果：入力時間、承認日数、未更新台帳数、問い合わせ対応時間などのKPI
「月次集計を半日から1時間以内にする」のように、測れる形で書きます。一方で「Excelをなくす」は、達成を測りにくい表現です。
件数・本数・頻度で示すデータ移行と外部連携
見積もりに必要な移行条件と連携条件を、対象ごとに具体化します。
- 移行対象：ファイル数、レコード件数、添付容量、重複・欠損、コード変換、保持期間
- 外部連携：対象、方向、項目、頻度、エラー時の再送、認証方式
Pleasanter.netのAPI制限は、フリー・ライトが1サイトあたり1日100回、スタンダードが同10,000回です（出典：株式会社インプリム「環境別機能比較表 2026年7月版」）。
この制限を見ずに連携本数だけで見積もると、契約後にプラン変更や処理方式の見直しが必要になります。
発注時点で含めるセキュリティと運用要件
認証方式や運用対策は要件に含め、設定・監視・復旧をそれぞれ誰が担うかを決めておきます。
- 認証・権限：認証方式、SSO、二要素認証、IP制御、権限単位
- 保護・復旧：操作ログ、バックアップ、復元時間、脆弱性対応
- アカウント管理：退職者アカウントの無効化方法
公式案内では、TLS通信やデータ暗号化、WAFを説明しています。パスワードのハッシュ化やリクエストのロギングにも触れられています。
国内のMicrosoft Azureデータセンターについても説明されています（出典：株式会社インプリム「FAQ：Pleasanter.netのセキュリティについて」）。
サービス側の対策は、自社の委託先管理や権限設計とは別に進める必要があります。そのため、誰が設定・監視・復旧を担うかを、責任分界表に書いておきます。
要件の確定度と変更の多さで選ぶ契約形態
成果物を明確にできるか、開発中に要件が変わるか、社内とベンダーの役割をどう分けるかで契約を選びます。
Pleasanterは設定や業務ルールの調整が起きやすいため、要件をすべて固定して一契約にするより、フェーズに分けたほうがリスクを管理しやすい場合があります。法務・調達部門と責任範囲を確認します。
完成条件と検収基準を明確にする請負契約
請負契約は、合意した成果物を完成させ、発注者が検収する形の契約です。そのため、成果物と検収条件を具体化します。
- 成果物：サイト構成、項目定義、権限設定、スクリプト、API、移行データ
- 納品物：操作マニュアルとテスト結果も含めます
- 検収条件：検収日、修正回数、瑕疵対応期間
「使いやすい」「十分な性能」は、同時利用者数や検索応答時間、登録件数に置き換えます。承認フローの完了条件も、具体的な条件として書きます。
調査・伴走・継続改善に向く準委任契約
準委任契約は専門家の稼働や業務支援を依頼する形で、要件整理や技術相談、設計レビューのほか、内製伴走や運用改善に向いています。
仕様が固まらない段階でも、月次またはフェーズ単位で課題を解消できます。一方で、稼働時間の記録だけでは成果が見えにくくなります。
成果報告には、月ごとの作業計画やレビュー資料、判断記録を含めます。加えて、残課題と次月の提案も入れます。
要件定義・構築・保守を分けたフェーズ分割
フェーズ分割の例は、要件定義・PoCから始めて、本番構築・移行、追加開発・外部連携、保守・運用支援へ進む形です。
PoCで標準機能への適合性を確認してから本番契約へ進めば、完成後に使えないと判明するリスクを抑えられます。
さらに、各フェーズには終了条件を定め、次へ進まない場合にデータ・設定・文書をどう返すかも決めておきます。
Pleasanterのシステム開発費用相場と見積もりの内訳
費用は、ライセンスやSaaS利用料に加えて、要件定義から保守までの各工程の費用を合わせた総額で比べます。その内訳には、環境構築や設定、開発が入ります。移行と連携、テストと教育も含まれます。
ここで示すのは、公式支援メニューと業務システム一般の相場を基にした目安で、公式の定価ではありません。データ量や利用者数、セキュリティ要件、既存システムの複雑さで変わります。
公式資料で確認できる利用料と支援料金
利用環境と技術支援では料金体系が異なるため、契約時点の公式資料で次の料金を確かめます。
- エディション：Community Editionは無償、Enterprise Editionは年額42万円からです。
- Pleasanter.net：フリー無料、ライト月額2,500円、スタンダードは1ユーザー月額750円です。
- 技術支援：環境構築・移行は35万円から、テクニカルコンサルティングは45万円から、開発プロジェクト支援は75万円からです。
- Web相談：60分のWeb相談は5万円からです。
利用人数やサイト数、レコード数の条件は、プランによって変わります。SSOやIP制御、API回数のほか、帳票や外部公開も、プランごとに違います。
年間サポートサービスは、2026年7月1日から新プランへ移行しています。そのため、旧資料の金額は使わず、契約時点の公式資料で確認します。
エディションとSaaSの利用料は、比較表に記載されています（出典：株式会社インプリム「環境別機能比較表 2026年7月版」）。技術支援とWeb相談の料金は、公開サービスの価格です（出典：株式会社インプリム「プリザンター技術支援サービス」2026年確認）。
支援料金は作業内容の最低目安で、業務アプリ全体の構築費ではありません。利用料やクラウド費、ベンダー開発費とは分けて積算します。
総額の目安として使う開発規模別の費用レンジ
開発規模ごとの初期費用と期間は、対象機能と体制を合わせて目安として見ます。小規模PoCから全社展開へ進むほど、対象の機能や連携、移行の範囲が広がります。
- 小規模PoC：1〜3テーブル、CSV取込、基本権限、簡単な通知で25万〜100万円程度、2〜6週間が目安です。
- 部門アプリ：5〜20テーブル、ワークフロー、帳票、移行、教育を含み100万〜500万円程度、1〜3か月程度です。
- 連携を含む案件：API・認証連携、複数拠点、監査・性能要件を含み500万〜2,000万円程度、3〜9か月程度です。
- 全社展開：数百〜数千ユーザーの移行、冗長化、段階リリースで1,000万〜5,000万円超、6〜18か月程度となる可能性があります。
これらは、公開支援料金と業務システム一般の相場から整理した推定レンジで、公式の一律価格ではありません。
費用を押し上げる要因には、画面数のほか、移行データのクレンジングや連携本数があります。加えて、セキュリティ審査やテスト、教育にも工数がかかります。
別枠で見るランニングコストと追加変更費
運用費には、SaaSまたはライセンス、クラウド・サーバー、バックアップが含まれます。さらに、監視や問い合わせ、バージョンアップ、追加開発と教育も運用費に入ります。
保守契約は、初期開発費の年15〜25％程度と仮に置いて考える方法もあります。これは一般的な予算の目安で、Pleasanter公式の一律料金ではありません。
金額を比べる前に、契約で対応時間や障害連絡、復旧目標を定めておきます。脆弱性対応や軽微な変更の範囲も、契約に書いておきます。
委託先選定と見積比較で確認すべきポイント
委託先の比較では、認定の有無を一つの材料にします。そのうえで、業務実績や支援範囲、移行経験を見ます。連携・認証の技術力や、セキュリティ回答、引き継ぎも比べます。
安い見積もりでも、要件定義やテストが別料金なら総額は上がります。そこで、同じRFPを複数社へ渡し、前提をそろえて見積もってもらいます。
社名より案件の条件の近さで見る実績
製品を使った実績があるかに加えて、自社案件と共通する難所を説明できるかを確かめます。
- 規模：利用者数、テーブル数
- 移行・連携：データ移行の有無、API・認証連携の本数
- 運用：権限の細かさ、稼働後の保守期間
導入事例では、株式会社SMSデータテックが、JR西日本近畿地区の約500店舗・25ホテル施設の店舗設備データを一元管理しました（出典：株式会社インプリム「株式会社ジェイアール西日本デイリーサービスネット導入事例」）。
同事例では、高いセキュリティ要件への対応に加えて、各PC・サーバーからのデータ移行も支援しています（同出典）。
工程・工数・前提条件を横並びにした見積書
見積もりでは、工程ごとの作業量と除外条件を比べ、後から増額する要因を探します。
- 工程：要件定義、設計、設定、スクリプト、API、環境構築
- 納品・運用：データ移行、テスト、教育、リリース、保守
- 前提：担当、工数、単価、期間、成果物、除外事項
「データ移行一式」「連携一式」「テスト一式」と書かれている場合は、対象件数や項目数、エラー処理、再移行の回数を質問します。
比較表には金額に加えて、標準機能の割合やカスタマイズ方法、社内変更の範囲を並べます。再委託や保守時間帯、追加変更単価も、同じ表に入れます。前提が明確で、増額要因を先に説明する会社なら、総額と納期を管理しやすくなります。
PoCと受入テストを発注条件にして失敗を防ぐ方法
例外処理を見ずに画面を作ることや、権限を後回しにすることは、失敗につながります。移行品質を発注者任せにすることや、保守担当を決めないままにすることも、失敗の原因になります。
代表業務のPoCでは、検索や登録、承認を検証します。通知や権限、CSV出力、エラー復旧も、同じPoCで確かめます。
受入テストには、正常系だけでなく、例外の場面も含めます。
- 入力・データ：入力漏れや重複
- 業務フロー：退職者や承認差し戻し
- 連携：外部連携停止時の動作
RFPでは、ベンダーから質問事項と代替案も求めます。標準機能やスクリプト、外部製品の案を比べると、更新や担当者の交代に備えられます。
公式技術支援では、標準機能とカスタマイズの使い分けや設計レビューを支援対象にしています。移行や性能改善も対象に含まれ、判断しにくい点は発注前に専門家へ相談できます。
よくある質問（FAQ）
発注では、料金だけでなく、標準機能や移行・連携の難しさ、社内運用体制も確認します。担当者からよく寄せられる質問に答えます。
Pleasanterのシステム開発を外注するといくらかかりますか？
推定レンジは、小規模PoCが初期25万〜100万円程度、部門アプリが100万〜500万円程度、複数連携案件が500万〜2,000万円程度です。
公式の一律価格ではなく、公開支援料金と一般相場による参考値です。金額は、利用料や移行の内容で変わります。教育や保守、セキュリティ対応によっても変わるため、工程別に見積もります。
ノーコードなら発注せずに社内だけで作れますか？
標準機能中心の小規模な台帳なら、社内で作れる可能性があります。認証連携や複雑な権限、移行には、専門家のレビューが有効です。APIや帳票、性能、バックアップについても、専門家の見方が役立ちます。
社内で業務要件と運用を担い、ベンダーには設計レビューや難しい連携だけを依頼する方法もあります。
委託先はPleasanterの認定パートナーから選ぶべきですか？
認定パートナーは候補を探すうえで有効ですが、認定の有無だけで優劣を決めないようにします。
近い業務・規模の実績や、移行・連携の経験を確認します。要件定義から保守までの担当範囲や、セキュリティ対応、引き継ぎも見ます。複数社に同じRFPを渡して、前提を比べます。
OSS版と商用版の違いは発注時に確認できますか？
確認できます。発注時には、利用形態ごとの料金や機能の条件を比べます。比べる観点は4つで、利用条件から権利帰属までが含まれます。
- 利用条件：エディションやPleasanter.netごとの利用料、認証、IP制御
- 開発・運用条件：運用・開発支援ツール、API、サーバスクリプトの条件
- ライセンス：AGPLのコピーレフト、商用の取り扱い、外部ユーザーの利用
- 権利帰属：開発したスクリプトや帳票の権利は、技術担当だけでなく法務・調達・情報システムと契約前に確認します
まとめ
発注前に要件と見積もりの前提をそろえること
まず対象業務とKPIを決めて、標準機能と追加開発の境界を整理します。そのうえで、SaaSや自社環境、Enterprise Editionなどの形態を比べます。
RFPには、利用者数やテーブル数、データ量を書きます。連携や権限、セキュリティも記載します。移行や教育、保守も、RFPに書き込みます。
小さく検証してから広げる本番の発注範囲
本番へ進む前に、費用の比べ方から支援範囲の決め方まで、4つの点を照らし合わせます。総額では、利用料に加えて、要件定義と環境構築、設定、開発の費用を比べます。移行、テスト、教育、運用の費用も、同じ総額の中で見ます。
- 総額で比較：利用料、要件定義から運用までの各工程
- PoCで確認：受入条件の検証と、過剰なカスタマイズや追加費用の抑制
- 委託先を選ぶ：複数社へ同じ条件で相談し、実績と見積もりの前提が明確な会社を選びます
- 支援範囲を決める：比較したうえで、自社に必要な範囲を見極める
▼全体ガイドの記事
・Pleasanterのシステム開発の完全ガイド
▼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を創業。