Pleasanterのシステム開発は、業務とKPIを絞り込み、標準機能を軸に設計することから始まります。要件整理から定着までの6つのフェーズに分け、各フェーズの完了条件をそろえて、小さく検証しながら進めます。
▼全体ガイドの記事
・Pleasanterのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Pleasanterのシステム開発の全体像
Pleasanterは、株式会社インプリムが提供する日本発のオープンソース型ノーコード・ローコード開発プラットフォームです。完成済みの業務機能を一式導入するERPのような製品とは違い、テーブル（サイト）と項目、権限、プロセスを組み合わせて、案件管理や設備台帳、申請、問い合わせ、点検などの業務アプリを構成する基盤です。
標準機能で作れる業務アプリの範囲
標準機能では、項目を配置し、検索や絞り込み、データ入出力、変更履歴、アクセス制御などを設定できます。
- データ管理：分類、日付、数値、説明、チェック、添付ファイルを扱えます。
- 表示・集計：カレンダー、ガントチャート、カンバン、クロス集計、時系列チャート、ダッシュボードで見られます。
- 業務処理：リンク、ルックアップ、計算式、通知、リマインダー、プロセス（ワークフロー）の設定。
これらを組み合わせると、「登録する」「探す」「承認する」「状況を把握する」といった業務の流れを、設定だけで表せます。
たとえば設備台帳では、設備名、設置場所、管理部門、点検日、状態、関連図面を登録し、期限前の通知や担当者別の一覧も作れます。また、案件管理では、顧客、案件ステージ、受注見込み、次回アクション、添付資料を一つのサイトで追跡できます。
Community EditionやPleasanter.netのスタンダードプランでは、アクセス制御や変更履歴も掲載されています。さらに、入出力、通知、プロセスも利用できます（出典: プリザンター公式「環境別機能比較表」、2026年版）。
標準機能と拡張開発の境界の決め方
標準機能で足りない部分は、画面側のスクリプト、サーバスクリプト、API、帳票製品、外部サービス連携で補えないかを、開発会社と一緒に検討します。
- 拡張候補：採番、入力チェック、自動通知、複数テーブル更新、基幹連携。
- 保守負担：スクリプトが増えると属人化し、更新時の検証も必要になります。
- 機能の配分：業務の七割から八割を標準機能で表し、残りを設定、スクリプト、外部システムに分けます。
一方で、給与計算や会計など、制度や専門ロジックが中心の領域は専用パッケージを残します。Pleasanterを申請、台帳、進捗、周辺データのハブとして使うほうが保守しやすいケースもあります。
Pleasanterのシステム開発の進め方
画面を先に急いで作ると、業務が早くならない、既存データを移せない、権限が複雑で公開できないといった問題が生じます。そこで、開発を6つのフェーズに分け、各フェーズの完了条件を決めてから次へ進みます。最初は要件整理で、続けて環境・エディション選定、設計・開発と進みます。残る3フェーズは、動くものを検証してから公開し、稼働後の運用までを見届ける段階です。
- テスト：登録から完了までの流れを通して確かめる工程。
- 稼働：段階公開と切り戻し方法を含む工程。
- 定着：稼働後の変更管理と内製化の仕組みを含む工程。
1. 要件整理フェーズでの業務とKPIの限定
「Excelをなくす」といった言い方より、改善したいことを数値で置くほうが、開発の判断材料になります。例えば、入力時間を一件あたり30分から10分へ減らす、といった形で書きます。
- 承認：リードタイムを5営業日から2営業日へ短縮。
- 棚卸し：未確認件数を月20件から5件以下に減らす。
KPIが一つか二つに絞られていれば、不要な機能を後回しにできます。発注側と開発会社は、現行のExcel、紙、既存データベース、メール、共有フォルダを一覧にして洗い出します。そのうえで、項目名だけでなく、入力者や更新頻度も確かめます。
必須条件、コード体系、重複、例外処理を調べます。保持期間、参照者、管理責任者も確かめます。「誰が何のために入力する列か」を現場に聞くと、未使用の項目や、別システムが正本になっている項目が見つかります。
このフェーズの完了条件は、要件が一枚の要件一覧にまとまっていることです。一覧には、対象業務・部門、利用者数、対象データを載せます。加えて、次の項目も書き込みます。
- KPI：数値で置いた改善目標。
- 連携先：データを受け渡す外部システム。
- セキュリティ制約：認証や公開範囲などの条件。
「後で決める」とした項目には、期限と決定者を置きます。そうしておけば、未確定のまま開発へ進むことを防げます。
2. 環境・エディション選定フェーズでの制約の突き合わせ
この段階では、Pleasanter.netなどのSaaSと、自社サーバーやAWSに構築するCommunity Editionを比べます。Enterprise Editionや専用クラウドも候補に入ります。
- SaaS：短期で始めたく、インフラ運用を減らしたい場合の候補。
- 自社環境：データ所在、閉域網、既存の認証・監視基盤を優先する場合に検討します。
- Enterprise Edition：商用ライセンスや大規模運用支援が必要な場合の候補。
料金が無料かどうかだけで決めず、利用人数、サイト・レコード数、ストレージ、API回数を照合します。
認証まわりでは、SSO、LDAP、二要素認証を確認します。公開や出力まわりでは、IP制御、外部公開、帳票、サーバスクリプトの扱いも確かめます。
バックアップや障害時の連絡窓口は、要件表と突き合わせて確かめます。
公式比較表を見ると、Pleasanter.netのフリー・ライトプランはAPIが1サイトあたり1日100回、スタンダードは1日10,000回です（出典: プリザンター公式「環境別機能比較表」、2026年版）。
特に連携を後から付け足す場合、この上限の差が設計変更につながることがあります。
AGPLのコピーレフトや商用ライセンスについては、法務・調達・情報システムと早めに確認します。
契約法人以外の利用者を含める場合は、スクリプトや帳票の権利帰属、外部提供の範囲、再委託先がどこまでを受け持つかを契約書で確認します。これにより、稼働直前の差し戻しを防ぎやすくなります。
3. 設計・開発フェーズの小さなPoCからの始め方
全社の業務をまとめて作る前に、1業務、1部門、少数データでPoCを作ります。次に、実利用者に一連の操作を試してもらい、想定KPIの改善を確かめます。
- 操作確認：登録、検索、承認、通知、添付、一覧出力を、実際に試します。
- 設計記録：サイト構成、項目定義、必須・任意、初期値を書き残します。コード、権限、プロセス、通知条件、採番も、同じ記録に含めます。
- データ設計：連携、エラー時の扱い、バックアップと復元方法を記録し、移行項目を整理する。
PoCを動かすと、入力できない項目や現場の例外が見えてきて、要件の精度も上がります。そこで、既存Excelの列は、正規化する項目、検索用に残す項目、履歴として持つ項目に分けておきます。
スクリプトやAPIでは、目的、入出力、実行者、再実行方法を記録に残します。ログ、テスト担当者、更新時の確認手順も、同じ記録に含めます。
保守負担を抑えるには、標準機能をコード化せず、外部システムの正本を勝手に変えず、連携の失敗を画面で確認できるようにしておくことが欠かせません。
4. テスト・リリースフェーズでの本番データと権限の検証
テストでは、登録から承認、検索、通知、完了までの流れを通して確かめます。また、役割ごとに見える項目と操作できるボタンも調べます。
- 正常系：登録、承認、検索、通知、完了までを通します。
- 異常系：必須漏れ、重複、期限切れ、権限外閲覧を試します。連携停止、添付容量超過、同時更新も確かめます。
- 利用者別：利用者、承認者、管理者、退職者相当のアカウントを用意します。
移行テストでは、件数だけでなく、キー、日付、コードを照合します。現行データをコピーするだけでは完了しません。さらに、添付、文字化け、重複、関連付け、更新履歴も確かめます。
移行では、不要データの廃棄、欠損値の補完、マスタの統一、移行後の責任者も決めておきます。これらが決まって、初めて移行の完了といえます。
移行は、画面作成とは別の大きな作業として扱います。たとえば、JR西日本近畿地区の約500店舗に散在した設備データや図面の移行事例も紹介されています（出典: プリザンター公式「JR西日本デイリーサービスネット導入事例」）。
5. 稼働フェーズの段階公開と切り戻し方法
本番稼働は、全社同時に公開するより、段階リリースのほうが安全です。PoC部門から他部門、外部連携、全社の順に展開します。
- 切り替え準備：日時、旧運用の停止条件、並行期間、移行時刻、窓口、切り戻し方法を決めます。
- 稼働状況：ログイン人数に加え、登録、必須入力、承認滞留を日次で確認します。通知、連携エラー、問い合わせの状況も見ます。
- 利用定着：1週間後や1か月後のKPIと比べ、旧Excelへ戻る場合は入力項目、検索性、権限設定を見直します。
現場が旧Excelへ戻った場合も、利用者を責めず、入力項目や検索性、権限などの原因を直します。
6. 定着フェーズの変更管理と内製化の仕組み
稼働後は、管理者、業務責任者、情報システム、現場代表の役割を分けておきます。
- 変更管理：変更申請、影響確認、テスト環境での検証、承認、リリース、履歴記録の流れを用意します。
- 本番反映：誰でも変更できる状態を避け、標準機能・設定・スクリプト・連携の変更箇所を記録します。
- 社内と外部の分担：項目変更や一覧作成は社内で担えます。認証連携、性能改善、複雑な移行、重大障害、更新検証は専門家へ相談します。
変更箇所の記録は、障害原因を特定するときに役立ちます。
年間サポートには、操作・設定のQ&A、トラブル対応、更新や開発機能の相談、サンプルスクリプト提供などが含まれると案内されています（出典: プリザンター公式「年間サポートサービス」、2026年7月改定後の案内）。
Pleasanterのシステム開発にかかる費用相場
Pleasanterの費用は、ライセンスやSaaS利用料に加えて、開発や移行などの作業費で構成されます。作業費は、要件整理や環境構築、サイト設計、スクリプト・API開発、移行に分けて考えます。さらに、認証・権限、帳票、テスト、教育、保守も分けて捉えます。
ここで示す開発費は、公式の定価ではなく、公式の支援メニューと業務システム一般の相場をもとにした編集部の推定です。実額は、対象業務と見積条件によって変わります。
ライセンス・SaaS・サポートの費用
利用環境や契約内容によって費用が変わるため、料金、利用条件、支援範囲を分けて確認します。
- ライセンス・SaaS：Community Editionとフリーは無償で、ライトは月額2,500円、スタンダードは1ユーザー月額750円（税抜）です。
- プラン条件：利用人数、サイト・レコード上限、API回数に条件があります。SSO、IP制御、帳票、サーバスクリプトにも、条件が付きます。
- 自社環境・サポート：サーバー、クラウド、DBの費用が別途発生します。バックアップ、監視、TLS証明書、障害対応も、見積もりに含めて考えます。
- 技術支援：環境構築・移行は35万円から、技術コンサルは45万円から、開発支援は75万円から、Web相談は5万円からです。
料金は税抜です。年間サポートは、2026年7月改定後の案内で、エントリーが年額42万円、ベーシックが年額72万円などとされ、利用者数やインシデント件数に応じて決まります（出典: プリザンター公式「年間サポートサービス」、2026年8月確認）。
旧資料と新プランで表示が違う場合は、契約時点の見積書で範囲を確かめます。
技術支援の金額は公開メニューの価格で、業務アプリ全体の開発費ではありません（出典: プリザンター公式「技術支援サービス」、2026年8月確認）。そのため、見積もりでは含まれる作業を確認します。
開発規模別の推定レンジと期間
開発規模ごとの推定額と期間は、含める機能や作業範囲をそろえて比較します。
- 小規模PoC：1〜3テーブル、CSV取込、基本的な権限、簡単な通知を含む規模。初期25万〜100万円程度、期間2〜6週間。
- 部門アプリ：5〜20テーブル、ワークフロー、帳票、既存データ移行、利用者教育を含む規模。初期100万〜500万円程度、期間1〜3か月。
- 連携案件：API連携、SSO、複数拠点、監査・性能要件を含み、初期500万〜2,000万円程度、期間3〜9か月。
- 全社基盤：数百〜数千ユーザー、複数業務、冗長化、段階展開。初期1,000万〜5,000万円超、期間6〜18か月となる可能性があります。
この推定は、小規模PoCを標準機能中心で、要件整理と操作確認を短く行う場合を前提にしています。SaaS利用料、クラウド費、複雑なデータ整形は、別途かかる可能性があります。
部門アプリでは、権限の組み合わせ、移行元の品質、承認経路、テストケース数によって工数が変わります。
これらは、公式価格ではなく、公開されている支援価格と業務システム一般の相場による推定です。予算申請では、前提条件と合わせて示します。
Pleasanterの見積もりを取る際のポイント
見積もりは、同じ条件で何を実現する金額かをそろえてから、金額を比べます。標準機能の設定だけで済む案件と、移行・認証・連携・帳票・性能検証が必要な案件では、工数の差が大きくなります。
見積書の作業範囲と成果物の確認
後からの追加費用を防ぐには、工程ごとに作業範囲と成果物を分けて見積もってもらうことが大切です。
- 企画・環境：要件整理、現行調査、環境構築、サイト設計。
- 開発・移行：画面・権限設定、スクリプト、API、帳票、データ整備と移行。
- 導入・運用：テスト、マニュアル、教育、リリース、保守。
成果物が要件一覧、設計書、動作するサイト、テスト報告書のどれに当たるかも、各工程で確かめます。
「データ移行一式」「連携一式」「保守一式」は、後から追加費用が発生しやすい項目です。
移行対象のファイル数、レコード数、添付、重複整理を確認します。連携本数、APIの方向、失敗時の再送、問い合わせ受付時間も見ます。対象外の作業も、見積書に明記してもらいます。
発注先の選び方と支援範囲
発注先は、認定の有無だけで決めず、支援内容と自社の課題への適合性を比べます。
- 実績と範囲：認定、類似業務の実績、要件定義から運用までの担当範囲、標準機能と拡張の分け方。
- 支援力：データ移行経験、認証・セキュリティへの回答力、障害時のSLA、内製化支援の有無。
- 会社のタイプ：開発元直結、運用自動化、既存システム連携、内製化支援などから課題に合う先を選びます。
問い合わせの際は、利用者数と役割、テーブル数、既存データの形式と件数、外部連携数を、同じ様式でそろえて伝えます。
さらに、SSO・IP制御、帳票、監査ログ、希望納期、保守時間も伝えます。提案では、PoC、操作テスト、移行リハーサル、教育、稼働後のKPI確認の有無を確かめます。
PoCや操作テスト、移行リハーサル、教育、稼働後のKPI確認を提案に含める会社は、画面作成で終わらず、業務定着まで見ている可能性があります。
見積もり段階のリスクと追加費用の洗い出し
見積もりの前提が曖昧なままだと、要件やデータの状況に応じて、追加費用が生じる場合があります。
- 要件・データ：要件の後出し、移行元データの欠損。
- 設計・審査：権限の例外、外部システムの仕様未確定、帳票、性能、セキュリティ審査。
- 導入後：利用者教育、稼働後の追加開発。
不明な項目は「確認中」と明記したうえで、仮定条件、判断期限、条件変更時の精算方法を記載します。
保守費は初期費用の割合だけで決めず、まずSaaS・サーバー費、バックアップ、監視、問い合わせに分けます。障害・脆弱性対応、更新検証、追加開発も、それぞれ分けて見積もります。
業務システム一般では、保守費を初期費用の年15〜25%程度と仮置きする考え方があります。これは、Pleasanterの公式料金ではありません。
対応時間、月の作業時間、未使用分の扱い、緊急対応の単価は、契約書で確認します。
よくある質問（FAQ）
Pleasanterは無料で始められる一方、企業で安全に運用できるとは限りません。初期相談で多く出る疑問を、判断の軸と合わせて整理します。
Pleasanterはノーコードだけでシステム開発できますか？
台帳、案件管理、申請、通知、検索、集計などは、項目や権限の設定を中心に組み立てられます。一方で、複雑な入力チェック、自動採番、複数システム連携、特殊帳票では、スクリプト、API、外部製品が必要になる場合があります。
標準機能でPoCを作り、不足する部分だけを拡張していく進め方が安全です。
Pleasanterのシステム開発費用は無料ですか？
Community EditionやPleasanter.netのフリープランなど、無償で試せる選択肢はあります。ただし、要件整理、環境構築、移行、教育、連携、保守まで無料になるわけではありません。そのため、SaaS利用料やサポート、クラウド・サーバー費と開発費は、分けて考えます。
PoCと本番展開の予算を別々に見積もると、総額を把握しやすくなります。
既存のExcelや他システムのデータを移行できますか？
CSVなどで取り込めますが、取り込めることと、品質を保って使えることは別の話です。
- データ整備：項目対応、コード変換、重複整理、日付形式の確認。
- 関連情報：添付、関連レコード、不要データを確かめます。
- 検証：件数を照合し、本番前にリハーサルを行います。
複数拠点にデータが散在する場合は、データの持ち主と正本を決める作業も見積もりに含めます。
内製と外注はどのように分ければよいですか？
日常的な項目変更、一覧作成、利用者の一次受付は社内管理者が担当できます。
認証連携、複雑なAPI、データ移行、性能改善、重大障害、更新検証は、開発会社や開発元へ相談する分け方が現実的です。
外注先には、設計書、テスト仕様、操作マニュアル、引き継ぎ、稼働後の相談範囲も成果物に含めてもらいます。そうすると、担当者が変わっても運用できる成果物がそろいます。
まとめ
Pleasanterの開発では、対象業務とKPIを絞り、標準機能と拡張の境界を決めます。そのうえで、データ、権限、運用まで一続きで設計します。
6つのフェーズそれぞれに完了条件を置くと、無料・ノーコードという印象だけで判断するリスクを減らせます。
着手前に決める事項
着手前に、改善KPI、利用部門、利用者数、移行対象を決めます。認証方式、必要な連携、データの正本、保守担当も決めておきます。
法務・セキュリティ審査の期限も定めます。これらが決まれば、環境の比較と開発会社への相見積もりを、同じ前提で進められます。
最初の一歩は小さなPoCと現行データの棚卸し
全社展開を決める前に、1業務・1部門・少数データでPoCを行います。そこでは、検索性、入力負担、通知、権限、移行後の品質を確認します。
結果をもとに本番範囲と費用を見直し、段階的に利用を広げます。こうして、Pleasanterを現場で使われ続ける業務基盤へ育てていけます。
▼全体ガイドの記事
・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を創業。