Blog
開発会社に「できません」と言われたら?システム開発で代替案を出してもらう方法
「技術的に不可能」「対応できません」と言われた発注者向けに、代替案を引き出す方法と、技術力のある開発会社の見分け方を解説します。
- 受託開発
- 技術選定
- 発注失敗回避
「その要件は技術的に不可能です。」「うちでは対応できません。」
開発会社からこう言われたとき、発注者は途方に暮れる。本当に不可能なのか、対応する気がないだけなのか——見分けがつかない。
「できません」は会話の終わりではない。代替案の始まりだ。 代替案を出せない会社は、技術力か関与意志の限界を超えている。
結論:先に聞くべきこと
「できません」の直後に確認するのは次の3つだけだ。
- 何が障壁か(技術・コスト・スキル・意思)
- 近い要件の成功事例はあるか
- 代替案は何か(工数・リスク・効果付き)
この3つに具体で答えられないなら、その一文を採択理由にしてはいけない。
「できません」の3つの意味
1. 本当に技術的に困難
例: レガシーシステムとのリアルタイム連携、秒間10万リクエストの処理、特殊な規制要件。
技術的に可能でも、コストとリスクが見合わないケースもここに含まれる。
2. 会社のスキルセット外
例: モバイルアプリ未経験の会社にネイティブアプリを依頼、インフラ未経験の会社に大規模クラウド構築。
「できない」のではなく「やったことがない」——この区別が重要だ。
3. やる気がない
例: 工数が読めない、利益率が低い、リスクが高い——「できません」は断り文句になっている。
代替案を引き出す3つの質問
「できません」と言われたら、以下を聞く。
1. 「何が障壁ですか?」
技術的な制約を具体的に説明してもらう。説明できない場合、スキル不足の可能性が高い。
2. 「近い要件で成功した事例は?」
類似案件の実績を確認する。事例がない場合、正直に「未経験」と言ってくれる会社の方が信頼できる。
3. 「代替案はありますか?」
これが最も重要だ。技術力のある会社は「できません」で終わらない。 必ず代替案を出す。
| 元の要件 | 代替案の例 |
|---|---|
| リアルタイム連携 | バッチ連携+キャッシュ |
| 全機能を一度に | MVP分割+段階リリース |
| レガシー改修 | APIラッパー+段階リプレイス |
| 大規模スケール | 段階的な分離と負荷対策 |
赤旗/青旗
赤旗(危険)
- 「無理です」だけで終わる
- 障壁の説明が抽象(「大変なので」)
- 代替なし、調査もしない
- いきなりスコープ削除だけを提案する
青旗(信頼できる兆候)
- 「できません。ただし〜なら可能」と続く
- トレードオフを工数・リスク・効果で比較する
- 未経験なら調査期間を提案する
- 事業目的を保ったまま手段を変える
現場で見た、「無理」が「段階リリース」に変わった案件
匿名化した一例だ。発注側は「既存基幹とリアルタイム双方向同期」を必須と言い、ベンダーは「できません」と返した。会話が止まっていた。
聞き直すと障壁は次だった。
- 基幹側APIが夜間バッチ前提
- リアルタイム化には基幹改修が別予算で必要
- ベンダー単体では基幹ベンダーの協力が取れない
代替として「日中はキャッシュ参照、差分は15分間隔、重要操作だけ同期API」を提案し、事業側の「画面上すぐ反映されてほしい」を満たす形に落ちた。当初の一文は技術的に正しかったが、事業目的に対する代替が欠けていただけだった。
技術力のある会社の見分け方
- 「できません」の後に、必ず「ただし〜という方法なら可能です」と続く
- 制約を説明した上で、トレードオフを提示する
- 複数の選択肢を工数・リスク・効果で比較してくれる
- 「やったことがないが、調査して提案します」と正直に言える
判断軸:押し通す/代替を採る/相手を変える
| 状況 | 推奨 |
|---|---|
| 障壁が具体で、代替が事業目的を満たす | 代替を採る |
| 「無理」だけで代替も調査もない | 相手を変えるか、第三者レビューを入れる |
| スキル外だが調査提案がある | 短期間の調査契約を検討 |
| 本当に規制・物理制約で不可能 | 要件そのものを事業側で見直す |
次に確認すること
- 「できません」の障壁は具体か
- 類似事例または未経験の明示はあるか
- 代替案は工数・リスク付きか
- 事業目的は代替でも守れるか
- 調査が必要なら期間と成果物は何か
- 相手を変える判断基準は何か
Beast Technologyのアプローチ
当社が得意とするのは、「できません」と言われた案件の再設計だ。
- レガシーシステムのリプレイス
- 大規模トラフィックへのスケール
- 複雑なデータ移行
- 技術的に難しい要件の代替設計
「できない」ではなく「こうすれば実現できる」——技術的な制約を事業目標に変換するのが、技術パートナーの仕事だ。
まとめ
「できません」は、会話の終わりではない。代替案の始まりだ。
代替案を出せない会社は、技術力の限界を超えているか、関与する意思がない。代替案を出してくれる会社は、パートナーとして信頼できる。
技術的に難しい案件の相談・代替案設計は、お問い合わせフォーム からどうぞ。
Related
関連記事
システム開発会社を変えたい……途中でベンダー変更はできる?
開発がうまくいかず、ベンダー変更を検討している——そんな発注者向けに、途中変更の可否、手順、リスク、費用感を整理します。
システム開発会社のコンペで失敗しない方法|3社の提案を比較するときのポイント
開発会社のコンペで3社の提案を比較するとき、何を見ればいいか。価格・技術・体制・提案力の4軸で失敗しない比較方法を解説します。