Webシステム開発の見積もり依頼東京都千代田区からシステム開発会社へのお問い合わせ

その他

業務管理システム

提案依頼書(RFP)
開発体制・コードベース近代化診断
発行日: 2026年4月21日
発行元:Auditech
1. 背景と目的
1.1 発注者概要
当社は、特定業界向けSaaSプロダクトを開発・提供する中小企業である。主力プロダクトを2製品運営しており、ユーザー契約数は着実に拡大している。開発は現在、外部の開発パートナーに委託する形で進めている。
1.2 本診断の背景
近年、生成AIを活用したソフトウェア開発の進化は極めて速く、業界標準の開発プロセス・ツール・手法は過去1〜2年で大きく変化している。当社としても、開発体制の近代化を検討するにあたり、まず現状を客観的に把握する必要があると判断した。
これまで当社は現行の開発パートナーと協働してきたが、自社内に体系的な技術評価の仕組みがないため、以下の点について第三者による客観的な評価を受けたいと考えている。
•
現行のコードベース・開発プロセスが、業界ベストプラクティスと比較してどの水準にあるか
•
近代化するとしたら、どこから着手すべきか
•
AI駆動開発への移行を前提とした場合、現状のどこにGAPがあるか
1.3 本診断の目的

現状の開発体制・コードベースを6カテゴリで幅広く診断し、業界標準との差分を可視化する

近代化の優先順位付きロードマップを策定する

今後、開発パートナーを評価・選定するための客観的な基準を整備する素材を得る
2. 診断対象
2.1 対象プロダクト
発注者が運営する主力SaaSプロダクト2製品(クラウド型Webアプリケーション)。詳細は契約後に開示する。
2.2 技術スタック概要(現時点)
以下は現時点で想定される技術スタックの概要である。詳細は契約後の情報開示で確認いただく。
•
インフラ: AWS(主要サービスを利用)
•
フロントエンド: Webブラウザベースのシングルページアプリケーション
•
バックエンド: API型のサービス設計
•
データベース: リレーショナルDB
•
認証: 外部IDプロバイダとの連携あり
2.3 対象範囲
2製品を対象とするが、個別プロダクトの機能品質ではなく、共通する「開発体制・プロセス・共通基盤」の健全性評価を主眼とする。
3. 診断スコープ
以下の6カテゴリについて、幅広く浅く(業界標準との比較を軸にした全体像の把握)診断を実施いただきたい。各カテゴリ内の代表的な診断項目を示すが、具体的なチェックリストは受託者の経験・ノウハウに基づく提案を歓迎する。
3.1 カテゴリ1: コードベースの健全性
•
使用言語・フレームワークのバージョンおよびサポート状況
•
依存ライブラリの古さ・既知脆弱性
•
コード重複率・循環的複雑度
•
型安全性(型システム使用率、型逸脱の多用の有無)
•
コメント・ドキュメントコメントの整備状況
3.2 カテゴリ2: テストと品質保証
•
単体テストのカバレッジ
•
テストの自動実行体制(PR時の自動実行、壊れたテストの放置状況)
•
E2Eテスト(エンドツーエンドテスト)の有無
•
新機能追加時のテスト作成文化
•
バグの検出タイミング(開発中か本番稼働後か)
3.3 カテゴリ3: CI/CD(ビルド・デプロイの自動化)
•
ビルド・デプロイの自動化状況
•
デプロイ頻度
•
ビルド時間
•
ロールバック手順の整備状況
•
環境の再現性(本番・ステージング・ローカルの一致)
•
リリースノートの生成方法
3.4 カテゴリ4: セキュリティ(Continuous Compliance)
•
SAST(静的アプリケーションセキュリティテスト)の有無
•
依存関係の脆弱性スキャン自動化
•
シークレット(認証情報等)管理の実装
•
認証・認可の実装方式
•
ログ・監査証跡の取得状況
•
クラウド基盤のセキュリティコンプライアンス状況
3.5 カテゴリ5: ドキュメント・ナレッジ管理
•
設計書の現行性(コードとの一致)
•
設計書の一元管理状況
•
ADR(Architecture Decision Record)の有無
•
オンボーディング資料の整備
•
APIドキュメントの自動生成
•
ドメイン用語集の整備
3.6 カテゴリ6: 開発プロセスとチーム運用
•
PR(プルリクエスト)運用の徹底度
•
コードレビューの実効性
•
ブランチ戦略の標準性
•
イシュー・タスク管理の可視化
•
スキル分布・属人性(バス係数)
•
AI駆動開発ツールの利用状況とガバナンス
•
フロントエンド固有項目(コンポーネント設計、状態管理、デザインシステム、アクセシビリティ)
3.7 診断の深度について
本診断は「幅広く浅く」を方針とする。各カテゴリを深掘りするのではなく、全体像をレーダーチャート等で可視化し、今後深掘りすべき領域を特定することを主眼とする。
4. 成果物
受託者は以下の成果物を納品すること。
成果物
内容
①診断レポート本体
6カテゴリの診断結果、業界標準との比較、発見事項の詳細記述(40〜60頁想定)
②スコアカード
6カテゴリ×各項目の5段階評価、レーダーチャート化したサマリ
③GAP一覧
業界ベストプラクティスとの差分を具体項目で列挙
④優先順位付きロードマップ
「短期」「中期」「長期」で対応すべき項目を整理。最優先3項目を明確化
⑤ベンダー評価基準の素材
今後の開発パートナー評価・選定に使える観点・項目のリスト
⑥報告会
発注者経営陣向けの報告会(90分程度)。質疑応答含む
5. スケジュール（案）
以下を目安とするが、提案時に妥当なスケジュールの提示を歓迎する。
フェーズ
期間
主な作業
フェーズ1
Week 1-2
キックオフ、情報収集、診断項目確定
フェーズ2
Week 3-5
実査(コード解析、ドキュメント確認、主要関係者インタビュー)
フェーズ3
Week 6-7
分析、レポート作成
フェーズ4
Week 8
報告会、質疑応答、引き継ぎ
※プロジェクト開始から最終納品まで合計8週間(約2ヶ月)を想定。
6. 提案依頼事項
応募される受託者は、以下の項目について提案書に記載すること。
6.1 診断アプローチ
•
本RFPに示した6カテゴリに対する具体的な診断手法
•
使用予定のツール(静的解析ツール、セキュリティスキャナ等)
•
発注者・現行開発パートナーへのインタビュー設計
•
レポーティングのサンプル(類似プロジェクトでの成果物の抜粋等)
6.2 実施体制
•
プロジェクト体制図(役割分担、担当者氏名)
•
主要メンバーの経歴・実績
•
再委託の有無と再委託先
6.3 実施スケジュール
•
本RFPの想定スケジュールへの対応可否
•
各フェーズの詳細タスク
•
マイルストーン
6.4 見積
•
総額(税抜)
•
内訳(人員別単価×工数、または作業項目別金額)
•
支払条件の希望
6.5 受託実績
•
類似診断プロジェクトの実績(3件以上)
•
SaaS事業者への支援実績
•
AI駆動開発または近代的開発プロセス導入支援の実績
6.6 機密保持
•
機密保持契約(NDA)締結への同意
•
診断中に取得する情報の取り扱い方針
•
成果物の著作権帰属
7. 選定基準
以下の観点で総合評価を行う。
評価項目
配点
評価の視点
診断アプローチの妥当性
30点
6カテゴリを幅広く網羅、業界標準ベンチマークとの比較、発注者の実情に即した方法論
実施体制・担当者の実力
40点
主要メンバーの技術的深度、SaaS事業者への支援経験、AI駆動開発への理解
類似実績
20点
類似診断案件の実績数、成果物の質、顧客からの評価
金額
10点
提案内容に対する費用の妥当性、費用対効果
8. 応募要領
8.1 応募スケジュール
RFP発行日
2026年4月21日
お打ち合わせ
～2026年5月13日
提案書提出期限
2026年5月20日
受託者決定通知
2026年5月29日
契約締結・プロジェクト開始
2026年6月15日
8.2 提出物
•
提案書
•
見積書
9. 契約条件
9.1 契約形態
業務委託契約(準委任型または請負型。提案時に適切な契約形態を提示いただく)
9.2 支払条件
原則として、プロジェクト完了後の一括払い。
9.3 機密保持
契約締結前に相互に機密保持契約を締結する。受託者が本プロジェクトで知り得た発注者の情報(コード、設計書、事業計画、取引先情報等)は、契約期間中および終了後5年間、第三者に開示または自己のために使用しないものとする。
 
別紙: 発注者が契約後に開示する情報(予定)
受託者選定後、機密保持契約締結のうえで、以下の情報を開示する予定である。

対象プロダクトの概要、ユーザー規模

技術スタック詳細(言語、フレームワーク、AWSサービス構成等)

コードリポジトリへのアクセス(読み取り権限)

現行のドキュメント類(設計書、手順書、運用マニュアル等)

CI/CD構成、監視・ログ基盤の情報

主要開発メンバー(社内・外注先)へのインタビュー協力

— 以上 —

3ヶ月以内の予定

相談して決めたい

提案が欲しい

この案件に対応したい方はこちら

お問い合わせする