SolidJSのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

SolidJSのシステム開発は、要件整理から定着まで6段階で進めます。この順に進めると、現場で使えるシステムにつながります。

費用の目安と見積もりの確認項目も、この流れに沿って示します。

▼全体ガイドの記事
・SolidJSのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

SolidJSのシステム開発の全体像

SolidJSを導入するかどうかは、業務の待ち時間や入力負荷を減らす目的を定めてから検討します。品質は画面だけでなく、業務フローやAPIなどの設計にも左右されます。

SolidJSの担当範囲

システムの機能は、SolidJSが担当する範囲と、別に設計する範囲に分けて考えます。

• 画面と状態管理：ブラウザ画面、商品検索、一覧の絞り込み、在庫表示、承認ボタンの切り替えを担います。
• 別に設計する機能：API、PostgreSQLなどのDB、ログイン認証、ロール別権限、外部サービス連携。
• 細かな画面更新：signalやstoreで変更状態に関係するDOMを更新し、大量一覧や複数指標画面の操作性を高める可能性があります。

実際の体感は、データ量やAPIの応答、ネットワーク、画像や帳票の処理にも左右されます。そのため、実データを使ったPoCで確かめます。

SolidJSとSolidStartの使い分け

ログイン後の操作が中心の管理画面や社内ポータルでは、SolidJSをAPIと組み合わせる構成が候補になります。一方で、検索流入や初期表示を重視する公開ページ、ヘルプ、採用ページでは、SolidStartのSSRやSSGを検討します。

SolidStartの公式資料は、CSR、同期・非同期・ストリーミングSSR、SSGを案内しています（出典: SolidStart公式ドキュメント、2026年確認）。また、Netlify、Vercel、AWS、Cloudflareなどのデプロイ先も案内しています（出典: SolidStart公式ドキュメント、2026年確認）。

長期運用では、SolidStartとSolid 2.0のベータ状況を踏まえて進めます。

• SolidStart：資料はベータとして整備中のため、バージョンの固定と更新方針、障害時の切り戻しを決めておきます。
• Solid 2.0：2026年時点でベータ段階です。

Solid 2.0は、既存APIからの変更点と移行ガイドが公開されています（出典: SolidJS公式GitHubリリース、2026年確認）。安定版を使う範囲と検証用の範囲を分けておくと安全です。

SolidJSのシステム開発の進め方

各段階で仕上げるものと判断の基準を決めておくと、現場で使えない画面や権限・帳票の抜けによる手戻りを抑えられます。

1. 要件整理：業務の目的と例外処理

システム名や機能名より先に、業務の流れを洗い出します。受注であれば、問い合わせから見積、承認までを書き出します。在庫引当や請求への受け渡しも、同じ流れに含めます。

各工程で誰が入力し、誰が判断するのか、期限や例外はどうするのかを整理します。現行のExcelや紙帳票、FAX、メールを集めます。さらに、既存SaaSの画面も見ると、二重入力や転記の箇所が見えてきます。

確認項目をそろえ、業務のどこまでをシステムが担い、どこを人が受け持つかを決めます。

• 利用・データ：利用者、業務範囲、対象データ、権限区分、保存期間。
• 機能・運用：検索条件、CSV、帳票、通知・外部連携、休日・締め処理、障害時の代替手段。
• 採否の判断：画面操作が成果に直結するか、既存APIを使えるか、保守担当者を確保できるか。

AI機能や高価なダッシュボードを先に決めず、表記の揺れやマスタの重複も整理します。

2. 選定：SolidJSを使う範囲と代替案

選定では、業務標準への適合度と画面操作の特性を見比べます。そのうえで、候補ごとの違いから、SolidJSを使う範囲を決めます。

• 既存SaaS・パッケージ：法改正への追随や給与計算など、標準機能の継続的な更新が欠かせない業務に向きます。
• ローコード・既存ReactやVueの改修：既存の資産を生かせるかを比べます。
• SolidJSの新規開発：独自の業務が競争力になり、操作量が多い場合に検討します。

SaaSなどを中心にして、不足する社内ポータルや検索画面だけをSolidJSで補うほうが合理的な場合もあります。

ベンチマークの数字だけで決めず、実データ10〜20件程度で検索、並べ替え、インライン編集を試します。権限エラーや通信失敗、再送を検証し、スマートフォン表示やキーボード操作も確かめます。さらに、現場が許容できる応答時間も確認します。

ReactやVueからの移行では、画面単位の段階移行、API分離、マイクロフロントエンドの要否を検討し、全面刷新を前提にはしません。

3. 設計・開発：データと権限の先行設計

設計で扱う範囲をそろえ、画面とサーバーがそれぞれ何を担うかを具体化します。

• システム設計：画面一覧・遷移、データモデル、API仕様、認証方式、権限マトリクスを定めます。
• 運用・連携設計：エラー処理、監査ログ、バックアップ、外部連携の扱い。
• SolidJS設計：signalやstoreの利用箇所、コンポーネントの責務、共通UI、フォーム検証、読み込み表示、通信エラー表示を揃えます。
• SolidStart設計：採用するなら、ページごとのCSR・SSR・SSG、メタデータ、サーバー処理の配置、デプロイ先を決めます。

モックや試作画面を早めに利用者へ見せ、名称や業務ルールの誤解を直しておきます。見た目だけを優先すると、権限外のデータ表示などが残るおそれがあります。

戻る操作による二重登録やCSVの文字コードの崩れも確認します。正常系に加えて、入力途中の離脱や同時更新、APIのタイムアウトを仕様に含めます。さらに、重複送信、在庫不足、承認者不在も仕様に入れます。

4. テスト：業務シナリオと非機能要件の検証

テストを段階に分け、画面表示だけでなく業務データの連動まで確かめます。

• 単体テスト：機能ごとの動作を確かめます。
• API・画面結合テスト：APIと画面の連携を検証する段階です。
• 総合・受入テスト：業務シナリオに沿って、利用者が確認します。

在庫管理では、入荷から出荷までの流れを一連で試します。返品や棚卸、在庫不足、複数人による同一商品の更新も、同じ流れに含めます。登録後に、帳票や集計に正しく反映されるかも検証します。

個人情報や権限を扱う場合は、認証や認可、セッションを確認します。さらに、入力値検証や機密情報のログ出力、バックアップの復元、脆弱性診断も確かめます。

OWASP ASVS 5.0は、Webアプリなどのセキュリティ検証標準です（出典: OWASP Application Security Verification Standard、2025年版）。「OWASP Top 10に該当しない」だけで合格とせず、案件のリスクに応じたASVS要求を設計、コードレビュー、テストに反映します。

5. 稼働：移行と切り戻しの準備

本番移行に必要な準備と照合の方法を決め、切り戻しまで具体化します。

• 事前準備：マスタと過去データの移行、アカウントや権限、外部連携、本番監視、バックアップ、問い合わせ窓口を用意します。
• 移行照合：件数に加え、合計金額、在庫残高、未処理承認、日付範囲などで突き合わせます。
• 切り戻し：旧システムの停止時期や並行稼働、障害時の戻し方を、担当者名と時刻まで決めます。

リリース当日は、重要業務の担当者が立ち会います。ログインや登録、検索を順に確認します。出力や承認、連携、バックアップも、同じ日に確かめます。

問題が起きたときに備えて、暫定運用と緊急修正の判断者も用意します。業務が止まらず、記録が残り、問い合わせに対応できる状態を稼働完了とします。

6. 定着：利用状況に応じた改善

マニュアルを配るだけで終えず、利用者が止まる箇所を確かめます。検索項目や入力エラーの多い欄、CSVの出力頻度を集めます。問い合わせや処理時間も集めて、改善候補の優先順位を付けます。

導入直後は、キーユーザーから質問を集め、FAQや画面文言に反映します。

保守契約では、障害対応、軽微な改修、問い合わせ時間を分けて定めます。また、OS・ブラウザ対応、SolidJSや依存パッケージの更新、脆弱性対応を、別の項目として書き出します。バックアップ確認も、項目に加えておきます。

• 更新判断：Solid 2.0などを、すぐに適用するか、検証環境で互換性を確認してから適用するかを決めます。
• 引き継ぎ資料：ソースコードやCI/CD、インフラ構成、OSSライセンス、テスト仕様、運用手順を、発注側が読める形で保管します。

SolidJSのシステム開発の費用相場とコストの内訳

費用の中心は、要件定義から運用設計までの工数です。SolidJSを採用しただけで、開発費全体が下がるとは限りません。

次の金額は、2026年時点の業務システム公開相場とSolidJSの公開価格をもとにした概算です。画面数だけで決まる正式な見積ではありません。

規模別の費用相場

規模ごとの相場は、画面数や機能、期間の前提と合わせて比べます。

• 検証・小規模CRUD：5〜10画面、ログイン、検索、登録、簡易APIで100万〜300万円、1〜3か月が目安です。
• 部門向け：10〜30画面、権限、承認、CSV、帳票、監査ログを含み300万〜800万円、3〜6か月が目安です。
• 複数部門・連携：ERPやCRM連携、移行、リアルタイム更新、SSRなどを含み800万〜2,000万円以上、6〜12か月以上です。
• 基幹刷新・大規模スクラッチ：1,500万〜5,000万円以上、12〜24か月以上になることもあります。

小規模の100万〜300万円、中規模の300万〜800万円という幅は、2026年公開の国内相場情報にも示されています（出典: イー・ジーシステム株式会社、SIA株式会社の2026年公開情報）。また、小規模CRUDの金額は、SolidJSの操作感や既存API接続を確かめるPoCとして考えます。

費用の内訳

見積書では、工程費とSolidJS固有の作業、初期費用のあとの継続費を分けて見ます。

• 工程：要件定義・企画、設計（基本・詳細）、実装、結合・総合テスト、移行・導入、保守。
• SolidJS関連：画面コンポーネント、状態管理、アクセシビリティ、ブラウザ検証、UIテスト。
• 継続費：クラウドや監視、ログ保管、メール・帳票サービス、ライセンス、脆弱性診断・バックアップ、保守改修。

業務システム全般の配分の目安は、要件定義が10〜15%、基本設計が15〜20%、実装が30〜40%です。結合・総合テストは15〜20%、移行・導入は5〜10%程度で、難易度により変わります。

保守費は、初期開発費の年15〜20%程度という公開の目安があります。ただし、対応時間や含まれる改修量によって変わります。

海外ベンダーには、Solid.jsのWebサイトが9,995ユーロから、Webアプリが14,995ユーロからという例があります。

Node.jsやDBを含むフルスタックについては、19,995ユーロからの掲載例もあります（出典: ilovesolution公開価格、2026年確認）。

これらは、税、国内の業務要件、移行、保守を含む日本の比較見積ではありません。そのため、この金額をそのまま予算に置かないようにします。

SolidJSのシステム開発で見積もりを取る際のポイント

見積もりでは総額だけでなく、開発範囲、除外範囲、金額が変わる条件を確認します。同じ資料を複数社に渡すと、技術費と業務要件の費用を同じ土台で比べられます。

見積前に準備する要件と仕様書

見積もりの前提をそろえるため、業務や利用者、現行の手順を整理します。必要な機能と優先度も書き出しておきます。

• 業務情報：対象業務、利用者数・部門、現行手順、困りごと、希望時期。
• システム範囲：画面、帳票、CSV、外部連携、権限、データ量。
• 優先度：画面ラフや現行Excelを添え、必須・できれば必要・将来検討に分けます。

SolidJSを選ぶ理由は、一覧の再描画を減らして入力待ちを改善するといった業務上の仮説とし、「新しいから」を理由にはしません。

見積依頼書には、PoC、設計・実装範囲、テスト・本番環境を記載します。さらに、移行、マニュアル、教育、保守、コード納品も書き添えます。

著作権とOSSライセンスも明記します。要件が固まっていない場合は、要件定義だけを先に発注できます。判断に必要な不確かな点を減らしてから本開発を見積もり直すと、追加費用を管理しやすくなります。

開発会社の比較基準

技術実績だけでなく、体制と契約条件も見て比べます。

• 実績・保守：SolidJSやSolidStartの本番URL、レビュー可能な実績、担当者の経験、更新方針を確認します。
• 業務体制：要件整理、API・DB設計、テスト、運用を担う人が揃うか見ます。
• 契約・納品：固定価格と準委任の範囲、追加要望の単価・承認、納品するものを明確にします。

公開実績がなくても、画面設計の資料やテスト方針を質問できます。障害対応の例や依存パッケージの更新方針も尋ねられます。

国内契約、日本語の要件定義、時差も確認します。さらに、個人情報の扱いや再委託、保守窓口も確かめます。

海外の公開価格だけで安さを判断せず、納品物は要件定義書、設計書、API仕様、テスト結果まで確認します。ソースコードやCI/CD、インフラ構成、操作マニュアル、OSS一覧も、納品物として確かめます。

採用・開発・運用のリスク対策

SolidJSはReactなどと比べ、社内経験者やUI部品、事例、移行ノウハウを集めにくい可能性があります。そのため、判断内容と保守の情報を、引き継げる形に整えます。

• 技術継承：選定記録、標準構成、固定した依存パッケージ、コード規約、テストを残します。
• セキュリティ：個人情報を扱うなら権限分離、暗号化、アクセス・操作ログ、バックアップを要件化します。
• 運用継続：検知時間、復旧目標、復元確認の頻度、告知、更新検証環境を見積もりに含めます。

SolidJSを採用しない場合の比較結果も残すと、担当者が交代したあとも判断をやり直さずに済みます。

漏えいが起きた場合の報告・通知の手順を定め、個人情報保護委員会の法令やガイドラインも確認します。さらに、委託先やクラウドについて、どこまでを誰が受け持つかも整理します。

SolidJSのシステム開発でよくある質問（FAQ）

よくある疑問は、フレームワークの特徴だけで判断せず、業務要件や保守体制、費用とあわせて見ます。

SolidJSだけで業務システムを開発できますか？

SolidJSは、画面と状態管理を担うUIライブラリです。業務システム全体を作るには、API、DB、認証、権限、監査ログなどを組み合わせる必要があります。

そのため、帳票やバッチ、バックアップも含め、バックエンドや運用まで構成を考えます。画面操作の価値は、その過程で確かめます。

ReactやVueで作った既存システムからSolidJSへ移行できますか？

移行はできますが、全画面を一度に置き換える必要はありません。既存APIを維持し、読み取り専用ダッシュボードや検索画面から段階的に移行できます。

操作量の多い画面を順に置き換える方法もあります。共通認証やデザインシステム、状態管理、エラー処理、計測方法を整理し、既存画面と使い勝手を比べます。

SolidJSを使うと開発費用は安くなりますか？

SolidJSの採用だけで総額が下がるとは限りません。

小規模CRUDは100万〜300万円、中規模の部門システムは300万〜800万円が相場の目安です。

費用は、画面数や権限、外部連携によって増減します。移行、テスト、保守も、費用を左右します。PoCで効果を確かめ、費用と入力時間の短縮やミス削減を比べます。

SolidJSの開発会社は何を基準に選べばよいですか？

本番実績に加えて、要件定義や認証・権限、APIセキュリティまで説明できる会社を選びます。さらに、テスト、移行、保守の進め方も説明できるかを確かめます。

公開実績が少ない場合は、PoCで作ったもの、設計レビュー、テスト計画、コードとインフラの納品範囲を確認します。さらに、日本語での契約、担当の継続性、障害連絡、将来の引き継ぎや会社変更も確かめます。

まとめ

SolidJSを採用するときの重要な判断

技術の速さを先に決めず、業務の待ち時間や入力負荷を明確にします。そのうえで、実データのPoCを行ったあとに採用範囲を決めます。

SolidJSは主にUI層を担います。そのため、APIやデータ、権限、監査ログを含めて設計します。さらに、帳票や移行、バックアップ、保守まで考えます。

次に行うべき準備

SolidJSの開発に入る前に、進行手順、費用の幅、発注条件を整理しておきます。進行手順は段階ごとの流れ、費用は規模ごとの幅、発注条件は見積もりの前提として、それぞれ押さえておきます。

• 進め方：要件整理、選定、設計・開発、テスト、稼働、定着の順です。各段階で仕上げるものと判断の基準を置きます。
• 費用目安：小規模CRUD100万〜300万円、中規模300万〜800万円、外部連携や基幹刷新800万〜数千万円以上です。画面外の工数でも変わります。
• 見積・発注：開発・除外範囲、移行、セキュリティ、保守、納品物、追加費用の条件と将来の引き継ぎを確認します。
• 着手前の検証：現行業務と困りごとを整理し、代表的な一覧・検索・登録画面を試して、採用範囲を決めます。

▼全体ガイドの記事
・SolidJSのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。