提案書に並ぶエンジニア数、対応技術、単価。これらは比較しやすい一方で、実際のプロジェクト運営までは教えてくれません。自社の事業と開発方法に合うチームを作り、品質と知識を継続して管理できるかまで確認したいところです。
選定では、提案された人と仕組みで、自社の開発を再現可能に運営できるかを確かめます。以下の10項目を使い、体制、品質、セキュリティ、移管の具体性を提案書と面談から引き出します。
1. 類似プロジェクトの経験
業界名だけで判断せず、システム規模、利用者、技術、開発期間、ベンダーの担当範囲まで見ましょう。成果の数値については、測定方法と顧客の確認有無も質問します。
2. チーム構成とアサイン
提案時に紹介されたメンバーが実際に参加するか、氏名、経験、稼働率、開始可能日、代替要員の提示を求めます。大きな人材プールがあっても、必要な人を予定どおり確保できるとは限りません。
3. PM／BrSEの能力
日本語力だけでなく、要件整理、技術理解、課題管理、説明力も選定対象です。面談や想定課題を通じて、質問の仕方や説明の分かりやすさを見極めます。
4. 開発プロセス
バックログ、スプリント、レビュー、デモ、変更管理、リリースがどう進むかを聞きます。自社側で誰が意思決定し、どの会議に参加するかも合わせて整理します。
5. 品質管理
コードレビュー、テスト設計、自動テスト、欠陥分析、受け入れ支援について、実際の流れと成果物のサンプルを見せてもらいましょう。「QAあり」という説明だけでなく、いつ、誰が、どの基準で行うかが重要です。
6. セキュリティ
認証の名称だけでは、案件に適用される対策は分かりません。対象法人と拠点、端末、ネットワーク、権限、ログ、ソースコード、再委託がどう管理されるかを具体的に聞きます。
7. 知識と成果物の所有
顧客がリポジトリや設計資料、チケット、テスト結果、クラウド環境を参照・取得できる状態にします。知的財産、OSS、第三者素材の扱いも契約条件に含めます。
8. 増減員とメンバー交代
増員のリードタイム、引き継ぎ期間、交代時の費用、品質を維持する方法を質問します。特定の個人に知識が集中しない運営になっているかも見ておきたい点です。
9. 料金と契約
単価に含まれる役割、稼働率、超過、休日、ツール、環境、保証、変更費用を並べて比較します。契約名称ではなく、誰が何に責任を持つのかを基準に判断します。
10. 終了・移管
契約終了時のコード、文書、アカウント、データ、作業履歴、知識移管を事前に決めます。ベンダーロックインを防ぐ重要な項目です。
RFPで使える質問
- 提案チームの氏名、役割、稼働率、開始可能日を示してください。
- 類似案件で御社が担当した範囲と成果を説明してください。
- 仕様の不明点と変更をどのように管理しますか。
- コードレビューとQAの基準を提示してください。
- 重大な遅延・品質問題のエスカレーション例を示してください。
- ソースコードと顧客データにアクセスできる担当者・委託先を示してください。
- 再委託先とその管理方法を説明してください。
- メンバー交代時の引き継ぎ期間と費用は、どのようになっていますか。
- AIツールをどの工程で利用し、データをどう管理しますか。
- 契約終了時に返却する成果物一覧を示してください。
小規模な有償検証も選択肢
提案書だけで判断しにくい場合、小さな実案件で要件理解、実装、レビュー、報告を確認します。単なるコーディングテストではなく、実際の連携方法を評価することが目的です。
価格を除く必須条件に対して、提案書の記述、面談する担当者、契約後の実行チームが一致しているかが重要です。AMELAの専属チーム型オフショア開発についても、実際の体制、品質管理、セキュリティ、移管条件を具体的にご説明します。
