静岡県のシステム開発会社5社｜選び方、RFP、見積、契約、補助制度

静岡県でシステム開発会社を探すときは、会社名を比べる前に、解決したい業務課題と発注範囲を整理する必要があります。条件が曖昧なままでは、各社の提案と見積の前提がそろわず、金額や納期を公平に比較できないためです。

本記事では、静岡県内に拠点を置くシステム開発会社5社の対応領域を紹介し、要件定義、RFP、見積、契約、補助制度、運用までを発注の順番に沿って説明します。初めて外部へ開発を依頼する担当者も、社内で何を決め、開発会社へ何を確認すればよいかを把握できます。

発注前に押さえたい四つの結論

• 最初に決めるのは機能ではなく、解決したい課題と成功の判断基準です。
• 複数社を比較する場合は、同じRFPと回答様式を渡して提案条件をそろえます。
• 見積は総額だけでなく、作業範囲、前提条件、追加費用が発生する条件まで確認します。
• 補助制度の利用可否と開発会社の選定は分けて考え、制度が使えない場合の計画も用意します。

システム開発を依頼する流れ

システム開発とは、業務上の課題を解決するために、必要な機能を整理し、設計、実装、テスト、導入、運用へ進める取り組みです。開発会社へ相談する前にすべての仕様を決める必要はありませんが、目的と対象業務が不明なままでは、提案の軸を作れません。

例えば、工場の点検記録を紙と表計算で二重管理している場合、「点検画面を作る」だけでは目的が不足しています。入力する人、承認する人、異常時の連絡先、残す記録、既存データの移行方法まで整理すると、開発会社は必要な機能と運用を同じ前提で検討できます。

要件定義で曖昧さを減らす

要件定義は、システムで実現することと実現しないことを決める工程です。「在庫管理を効率化したい」という希望だけでは、対象業務も成功条件も決まりません。現在の作業時間や誤入力の発生状況を確認し、導入後に何を測るかまで決めます。

KPIは、目的に近づいたかを継続して確認する指標です。目標値は根拠なく置かず、現在の状態を測ってから決めます。対象業務の範囲を示すスコープには、今回扱わない業務も書きます。対象外を明記すると、提案と見積に含まれる範囲の違いを見つけやすくなります。

発注前の確認項目

• 解決したい課題と、その課題が起きている業務
• 利用者の部署、役割、人数、利用場所
• 必要な機能と、今回の開発では扱わない機能
• 既存システム、外部サービス、機器との連携
• 移行するデータの種類、量、品質、管理責任
• 権限、バックアップ、監査に必要な記録
• 受入時に確認する操作と合格条件
• 公開後の問い合わせ、障害対応、改善の担当者

監査や障害調査に使う記録を決める際は、Webシステムの操作ログ設計と保存方法も参考になります。

RFPで各社の提案条件をそろえる

RFP（提案依頼書）は、開発会社に提案してほしい内容と回答条件をまとめた文書です。完成した設計書ではありません。発注側が把握している課題、制約、評価方法を示し、開発会社に実現方法、体制、見積、リスクを提案してもらうために使います。

RFPに含めたい項目

1. 背景、現在の業務、解決したい課題
2. 目的、KPI、導入後の利用イメージ
3. 対象部門、利用者、拠点、開発範囲
4. 必要な機能と優先順位
5. 性能、可用性、セキュリティ、バックアップなどの非機能要件
6. 既存システム、外部サービス、機器との連携
7. データ移行と受入テストの分担
8. 希望時期、社内体制、意思決定の流れ
9. 提案書と見積書に記載してほしい項目
10. 評価基準、質問方法、回答期限

不明な項目は無理に確定せず、「提案を求める事項」として分けます。未確定事項を隠すと、各社が異なる前提で見積もり、後から追加作業になりやすいためです。

見積は総額と前提条件を一緒に比べる

システム開発の費用は、機能数だけで決まりません。既存システムとの連携、データ移行、求める性能、セキュリティ、テスト、利用者教育、公開後の支援によって作業範囲が変わります。そのため、本稿では根拠を確認できない一律の価格帯を示しません。

WBSは、プロジェクトの作業を工程や成果物ごとに分けた一覧です。見積書にWBSと前提条件があると、各社がどこまでを見積もったかを追いやすくなります。

契約前に合意する内容

契約書の名称だけでは、実際の分担は判断できません。RFP、提案書、見積書、要件定義書、契約書の内容が矛盾していないかを確認し、曖昧な点は契約前に文書へ反映します。法的な判断が必要な条項は、専門家への確認も検討してください。

• 開発範囲、対象外の作業、納品する成果物
• 工程、確認日、発注側と開発側の担当範囲
• 仕様変更を申請し、費用と納期への影響を承認する手順
• 受入テストの内容、合格条件、修正と再確認の方法
• 成果物とソースコードの利用条件、引継ぎの可否
• 秘密情報、個人情報、アカウント、データの管理方法
• 再委託の有無と、再委託先へ共有できる情報の範囲
• 公開後の保守範囲、連絡窓口、対応時間、終了時の引継ぎ

UAT（受入テスト）は、発注側が実際の業務を想定して、納品されたシステムが合意した要件を満たすか確認するテストです。「問題なく動くこと」では判定できないため、操作手順、期待結果、合否条件を事前に決めます。

補助制度は契約前に公式情報を確認する

静岡県、市町、国が案内する補助制度や伴走支援は、年度や公募回によって対象者、対象経費、申請時期、必要書類が変わります。過去年度の上限額や締切を前提に予算を組まず、申請する年度の公式ページと募集要領で確認してください。

相談前に確認する項目

• 自社の所在地、規模、業種が対象に含まれるか
• システム開発費、クラウド費、機器費、研修費のどこまでが対象か
• 申請、採択、契約、発注、支払い、実績報告をどの順番で行うか
• 見積書、事業計画、効果測定に必要な資料は何か
• 同じ経費に対する他制度との併用条件はどうなっているか
• 制度を利用できない場合でも実施できる予算と範囲か

開発会社に制度の利用経験がある場合でも、申請主体と最終判断の責任まで移るわけではありません。担当窓口や支援機関にも確認し、開発日程と申請日程を別々に管理します。

静岡県で相談候補となるシステム開発会社5社

以下は、掲載時に確認した対応領域を基に整理した5社です。掲載順は優劣を示しません。現在のサービス、対応地域、体制、実績は、各社の公式サイトと個別提案で確認してください。

自社に合う開発会社を選ぶ質問

会社の知名度や所在地だけでは、プロジェクトとの相性は判断できません。提案書の表現ではなく、体制、成果物、進め方を具体的に質問します。

1. 類似案件：自社と近い業務、利用者、規模の案件で、どの範囲を担当したか。
2. 要件整理：現場への聞き取りと業務整理を、誰がどのように進めるか。
3. 担当体制：責任者、窓口、設計者、開発者、運用担当者は誰か。
4. 品質確認：設計レビュー、テスト、受入支援をどの工程で行うか。
5. セキュリティ：権限、ログ、脆弱性対応、バックアップをどう設計し、確認するか。
6. 変更管理：仕様変更をどの文書で管理し、見積と納期へ反映するか。
7. 運用と引継ぎ：障害対応、改善、契約終了時のデータと資料の引継ぎをどう行うか。

Webシステムを発注する場合は、公開前後の確認範囲をそろえるため、Webシステムの脆弱性を見つける方法と対策も確認しておくと、診断、コードレビュー、報告受付について質問しやすくなります。

提案を比較する手順

1. 社内で課題、優先順位、予算の上限、決裁者を整理します。
2. 同じRFPと質問票を候補各社へ渡します。
3. 回答内容を、実現方法、体制、費用、期間、リスク、運用で比較します。
4. 前提の違いと未確定事項を質問し、必要に応じて見積を更新してもらいます。
5. 担当者と現場の相性、説明の明確さ、変更時の進め方も確認します。
6. 契約書、提案書、見積書、要件の対応関係を確認してから発注します。

比較表には「できる」「対応可能」といった回答だけでなく、その根拠となる担当者、工程、成果物を書き込みます。根拠がそろえば、価格だけに偏らず、発注後の進め方まで含めて判断できます。

掲載を希望するシステム開発会社へ

本記事への掲載を希望する企業は、掲載依頼の問い合わせフォームから、会社名、所在地、連絡先、対応領域、得意業種、対応地域、公開可能な実績をお知らせください。掲載内容の確認に必要な公式ページも併せて提示してください。

発注準備のまとめ

静岡県でシステム開発会社を選ぶときは、課題と対象範囲を整理し、同じRFPで提案を依頼するところから始めます。見積では作業範囲と追加費用の条件を確認し、契約では受入、変更、運用、引継ぎの方法まで文書にします。

補助制度は予算を助ける可能性がありますが、制度の条件を開発要件の代わりにはできません。制度が使えない場合も含めて優先順位を決め、必要な機能から段階的に進められる計画を用意すると、開発会社との相談が具体的になります。