← Blog 一覧

Blog

開発会社に「できません」と言われたら?システム開発で代替案を出してもらう方法

「技術的に不可能」「対応できません」と言われた発注者向けに、代替案を引き出す方法と、技術力のある開発会社の見分け方を解説します。

村田 文太郎/代表取締役
  • 受託開発
  • 技術選定
  • 発注失敗回避

「その要件は技術的に不可能です。」「うちでは対応できません。」

開発会社からこう言われたとき、発注者は途方に暮れる。本当に不可能なのか、対応する気がないだけなのか——見分けがつかない。

「できません」は会話の終わりではない。代替案の始まりだ。 代替案を出せない会社は、技術力か関与意志の限界を超えている。

結論:先に聞くべきこと

「できません」の直後に確認するのは次の3つだけだ。

  1. 何が障壁か(技術・コスト・スキル・意思)
  2. 近い要件の成功事例はあるか
  3. 代替案は何か(工数・リスク・効果付き)

この3つに具体で答えられないなら、その一文を採択理由にしてはいけない。

「できません」の3つの意味

1. 本当に技術的に困難

例: レガシーシステムとのリアルタイム連携、秒間10万リクエストの処理、特殊な規制要件。

技術的に可能でも、コストとリスクが見合わないケースもここに含まれる。

2. 会社のスキルセット外

例: モバイルアプリ未経験の会社にネイティブアプリを依頼、インフラ未経験の会社に大規模クラウド構築。

「できない」のではなく「やったことがない」——この区別が重要だ。

3. やる気がない

例: 工数が読めない、利益率が低い、リスクが高い——「できません」は断り文句になっている。

代替案を引き出す3つの質問

「できません」と言われたら、以下を聞く。

1. 「何が障壁ですか?」

技術的な制約を具体的に説明してもらう。説明できない場合、スキル不足の可能性が高い。

2. 「近い要件で成功した事例は?」

類似案件の実績を確認する。事例がない場合、正直に「未経験」と言ってくれる会社の方が信頼できる。

3. 「代替案はありますか?」

これが最も重要だ。技術力のある会社は「できません」で終わらない。 必ず代替案を出す。

元の要件代替案の例
リアルタイム連携バッチ連携+キャッシュ
全機能を一度にMVP分割+段階リリース
レガシー改修APIラッパー+段階リプレイス
大規模スケール段階的な分離と負荷対策

赤旗/青旗

赤旗(危険)

  • 「無理です」だけで終わる
  • 障壁の説明が抽象(「大変なので」)
  • 代替なし、調査もしない
  • いきなりスコープ削除だけを提案する

青旗(信頼できる兆候)

  • 「できません。ただし〜なら可能」と続く
  • トレードオフを工数・リスク・効果で比較する
  • 未経験なら調査期間を提案する
  • 事業目的を保ったまま手段を変える

現場で見た、「無理」が「段階リリース」に変わった案件

匿名化した一例だ。発注側は「既存基幹とリアルタイム双方向同期」を必須と言い、ベンダーは「できません」と返した。会話が止まっていた。

聞き直すと障壁は次だった。

  • 基幹側APIが夜間バッチ前提
  • リアルタイム化には基幹改修が別予算で必要
  • ベンダー単体では基幹ベンダーの協力が取れない

代替として「日中はキャッシュ参照、差分は15分間隔、重要操作だけ同期API」を提案し、事業側の「画面上すぐ反映されてほしい」を満たす形に落ちた。当初の一文は技術的に正しかったが、事業目的に対する代替が欠けていただけだった。

技術力のある会社の見分け方

  • 「できません」の後に、必ず「ただし〜という方法なら可能です」と続く
  • 制約を説明した上で、トレードオフを提示する
  • 複数の選択肢を工数・リスク・効果で比較してくれる
  • 「やったことがないが、調査して提案します」と正直に言える

判断軸:押し通す/代替を採る/相手を変える

状況推奨
障壁が具体で、代替が事業目的を満たす代替を採る
「無理」だけで代替も調査もない相手を変えるか、第三者レビューを入れる
スキル外だが調査提案がある短期間の調査契約を検討
本当に規制・物理制約で不可能要件そのものを事業側で見直す

次に確認すること

  1. 「できません」の障壁は具体か
  2. 類似事例または未経験の明示はあるか
  3. 代替案は工数・リスク付きか
  4. 事業目的は代替でも守れるか
  5. 調査が必要なら期間と成果物は何か
  6. 相手を変える判断基準は何か

Beast Technologyのアプローチ

当社が得意とするのは、「できません」と言われた案件の再設計だ。

  • レガシーシステムのリプレイス
  • 大規模トラフィックへのスケール
  • 複雑なデータ移行
  • 技術的に難しい要件の代替設計

「できない」ではなく「こうすれば実現できる」——技術的な制約を事業目標に変換するのが、技術パートナーの仕事だ。

まとめ

「できません」は、会話の終わりではない。代替案の始まりだ。

代替案を出せない会社は、技術力の限界を超えているか、関与する意思がない。代替案を出してくれる会社は、パートナーとして信頼できる。


技術的に難しい案件の相談・代替案設計は、お問い合わせフォーム からどうぞ。

Related

関連記事