要件が完全に固まっていなくても、請負開発で相談できるのか
- 4 日前
- 読了時間: 11分
更新日：3 日前
顧客から案件を受注したものの、バックエンド部分の詳細要件まではまだ固まっていない。そんな段階で、外部の開発会社へ相談してよいのでしょうか。
結論から言えば、要件が完全に固まる前でも相談は可能です。 大切なのは、「相談を始めるタイミング」と「成果物単位の請負として発注するタイミング」を分けて考えることです。
はじめに：要件確定を待ってから外注先を探す必要はない
SIerやWeb開発会社が顧客案件を進めていると、すべての要件が決まる前に外部パートナーを探さなければならない場面があります。
たとえば、
顧客から「既存システムと外部サービスをAPI連携したい」と相談された
フロントエンドや画面設計は進んでいるが、バックエンドの方式が決まっていない
AWSを使う方針までは決まっているが、具体的な構成や非機能要件が未確定
決済機能を追加したいが、決済事業者との連携方式をまだ選定できていない
といったケースです。
この状態で「仕様書が完成するまで外注先には相談できない」と考える必要はありません。
むしろ、技術的な不確定要素がある案件では、要件整理や技術調査の段階から開発会社を交えた方が、実現方式や影響範囲を整理しやすくなることがあります。
一方で、未確定事項を大量に残したまま、開発全体を固定した金額・納期の請負契約にすることには慎重になるべきです。
この記事では、要件が固まりきっていない案件を、どの段階から外部へ相談し、どこから請負開発として切り出せばよいのかを整理します。
結論：相談開始と請負開発の開始を分けて考える
要件が完全に固まっていなくても、開発会社への相談は始められます。
ただし、不確定な部分まで無理に一括請負にするのではなく、次のように段階を分ける方が整理しやすくなります。
現状・要望・技術的な制約を確認する
未確定事項を調査し、開発範囲を整理する
成果物・前提条件・検収条件を定義する
定義できた範囲を成果物単位で請負開発する
つまり、
「何を作るかを整理する工程」と「決まったものを完成させる工程」を分ける
という考え方です。
IPAの「情報システム・モデル取引・契約書（第二版）」に関連する解説資料でも、要件定義は準委任、ソフトウェア設計・プログラミング・ソフトウェアテストは請負という工程別の整理が示されています。
また、最終的な成果物の完成状態を早い段階では明確に定義しづらい場合について、開発検討の進展に応じて契約を分ける「多段階契約」という考え方が示されています。
契約作業の手間は増えるものの、開発が進むにつれて徐々に明確になる仕様や、途中で発生する仕様変更が及ぼす影響を抑える方法の一つとされています。
参考：IPA「情報システム・モデル取引・契約書（第二版）」
工程別の契約類型・多段階契約に関する解説：IPA「システム開発の健全化に向けて」
工程別の契約類型：p.61／多段階契約：p.53-54
もちろん、実際にどの契約類型を採用するかは個別の契約内容や取引実態によって異なります。本記事では法的な判断ではなく、システム開発を発注・協業する際の一般的な進め方として説明します。
なぜ要件未確定のまま一括請負にすると難しいのか
請負開発では、「何を完成させるのか」「どの状態なら完成と判断するのか」を発注側と受注側で認識できる必要があります。
要件が曖昧なままだと、特に次の3つが問題になりやすくなります。
見積の前提が定まらない
たとえば「外部サービスとAPI連携する」という一文だけでは、実際の開発量は判断できません。
APIはいくつ利用するのか
認証方式は何か
どのデータを送受信するのか
リアルタイム連携かバッチ連携か
エラー時にはどう復旧するのか
既存システムをどこまで変更するのか
こうした条件によって、必要な設計・実装・テストは変わります。
情報が不足した状態で固定金額を出そうとすると、見積に大きなリスクを織り込むか、後から認識差が生じやすくなります。
追加変更の扱いが曖昧になる
開発途中で新しい要求が出たとき、当初の対象範囲が明確でなければ、
「それは追加開発です」
「最初から含まれていると思っていました」
という認識差が生まれます。
そのため、機能だけでなく、前提条件・対象外範囲・未確定事項も整理しておくことが重要です。
検収条件を決めにくい
「いい感じにAPI連携できること」では、完成したかどうかを客観的に判断できません。
一方、
指定したAPIへ所定形式でデータを送信できる
正常時には連携結果をDBへ保存する
APIエラー時にはエラー状態を記録する
定義したテストケースを満たす
といったところまで決まれば、成果物として扱いやすくなります。
成果物の具体的な切り出し方については、関連記事「バックエンド開発を外注するとき、どこまでを成果物として切り出せるのか」で詳しく解説しています。
どこまで決まっていれば開発会社へ相談できるのか
詳細な仕様書や設計書まで完成している必要はありません。
最初の相談時点では、次のような情報が分かる範囲で整理されていれば、話を始められます。
何を実現したいのか
現在どこまで決まっているのか
何がまだ決まっていないのか
既存システムがある場合、その概要
利用予定の外部サービスやAPI
希望する時期
自社で担当する範囲と、外注したい範囲
すべて決まっている必要はありません。
むしろ重要なのは、未確定事項を未確定のまま共有できることです。
「この部分はまだ顧客と調整中」「現行システムを調査しないと影響範囲が分からない」「連携方式そのものから相談したい」と最初に伝えた方が、開発会社側も調査が必要なのか、すでに見積可能なのかを判断できます。
要件が未確定であること自体より、どこが未確定なのか分からない状態の方が、発注を難しくします。
調査・要件整理の工程では、何をアウトプットにするのか
バックエンド側の検討を後回しにする
要件が固まっていない案件では、最初の工程を「システムを完成させる工程」ではなく、後続の開発範囲を見積・発注できる状態にする工程として切り出す方法があります。
たとえば、調査・要件整理工程では次のようなものを整理します。
対象機能一覧
現行システムの構成
関連するAPI・外部インターフェース
データの流れや連携方式
技術的な制約
開発時の前提条件
対象外範囲
未確定事項と確認先
実装工程を見積もるための条件
ここまで整理できれば、後続工程について、
「どの機能を作るのか」
「何を納品するのか」
「どこまでを今回の責任範囲とするのか」
を具体化しやすくなります。
プレイリーソリューションズが過去に担当した旅行販売システムの案件でも、要件定義・基本設計を担当し、実装自体は発注側で行うという分担で進めたケースがあります。
この案件では、複数システムとの連携方式やツアー組み立て機能のデータモデルを設計し、文書としてまとめて納品しました。その後、別の管理画面についても再度ご依頼をいただいています。
「外部会社に頼むなら実装まで全部任せなければならない」ということではなく、要件整理や設計部分だけを先に外部へ切り出すという進め方も可能です。
要件が変わったときの扱いを、先に決めておく
要件未確定案件で特に重要なのが、開発開始後に変更が発生した場合の扱いです。
システム開発では、事前に調査していても、新しい情報が後から判明することがあります。
そのとき、
当初の契約範囲内なのか
追加見積が必要なのか
納期も変更するのか
そもそも今回の開発では対応しないのか
を判断できるようにしておく必要があります。
そのため、請負開発へ移る段階では、少なくとも次の点を整理します。
対象範囲
今回どの機能・システム・API・データを扱うのか。
対象外範囲
インフラ変更、データ移行、既存機能の修正、本番運用など、今回含めないものは何か。
前提条件
API仕様書やテスト環境の提供、発注側で決めてもらう事項など、見積時に前提とした条件は何か。
成果物と検収条件
ソースコード、設計書、試験結果など何を納品し、どの条件を満たせば完了なのか。
そして、これらに加えて重要なのが、前提が変わった場合の変更手続きです。
IPAのモデル契約書（第二版）でも、
第34条：システム仕様書等の変更
第36条：未確定事項の取扱い
第37条：変更管理手続
が設けられています。
要件変更そのものを防ぐことより、変更が起きたときに、範囲・費用・納期への影響を確認して双方で判断できる状態にしておくことが重要です。
具体例：外部APIとの連携機能を追加する場合
たとえば、顧客から次のような相談を受けているとします。
既存の業務システムに、新しく契約したクラウドサービスとのAPI連携を追加したい。
しかし相談時点では、
連携対象データの詳細が未確定
API仕様書はあるが既存システム側の影響範囲が不明
データ同期のタイミングが決まっていない
エラー時の運用方法も決まっていない
という状態です。
この段階で「API連携一式」として固定金額を確定するのは難しいでしょう。
まず、
API仕様を確認する
既存システムの関連機能を調査する
データ項目の対応関係を整理する
同期タイミングを決める
異常時の処理方針を整理する
改修対象を特定する
といった作業を行います。
その結果、
「注文情報連携APIの実装、連携履歴管理、エラー処理、単体・結合試験」
のように対象が明確になれば、その部分を成果物単位の請負として発注しやすくなります。
認証方式やエラー処理、再送など、API連携そのものを発注する際に確認したい項目については、関連記事「API連携開発を外注するときに確認すべきポイント」でも解説しています。
請負にする範囲を決めるため、先に調査が必要な案件もある
成果物単位での請負開発を前提としていても、最初の調査・検証段階まで無理に請負にする必要はありません。
不確定性が高い部分を先に整理し、「ここから先なら成果物として定義できる」という境界を作ることで、その後の開発を請負として切り出しやすくなります。
たとえば、
技術的に実現可能かどうか自体を検証するPoC
開発しながら優先順位を継続的に変更する案件
利用者の反応を見ながら仕様を変えていく開発
既存システムを調査するまで影響範囲がほとんど分からない案件
などでは、最初の段階から成果物を固定することが案件の性質に合わない場合があります。
IPAの「情報システム・モデル取引・契約書（アジャイル開発版）」でも、開発中の機能追加・変更や優先順位変更へ柔軟に対応するアジャイル開発について、特定した成果物の完成に対して対価を支払う請負ではなく、準委任契約を前提としています。
参考：IPA「情報システム・モデル取引・契約書（アジャイル開発版）」
重要なのは、最初からすべてを請負にすることではありません。
不確定な部分を先に整理し、成果物と責任範囲を定義できた部分から請負として切り出すことです。
プレイリーソリューションズでは、要件整理の段階から相談できます
バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、要件が完全に固まった後の実装だけでなく、要件整理・既存システム調査・技術調査の段階からご相談いただけます。
たとえば、
顧客から相談を受けているが、バックエンドの構成をまだ決められていない
Javaを使うバックエンド部分を外部へ任せたい
AWS構成を含めて整理したい
APIや決済連携の方式を先に検討したい
既存システムを調査してから改修範囲を決めたい
といった段階でも対応可能です。
まず調査・要件整理工程を小さく切り出し、その結果をもとに対象範囲・成果物・検収条件を整理してから、設計・実装・試験などを成果物単位の請負開発へ移す進め方もできます。
「仕様書ができてから外注先を探す」のではなく、仕様を固めるために技術的な支援が必要な段階から相談することも選択肢の一つです。
まとめ：要件が固まるのを待つのではなく、固め方から相談する
要件が完全に固まっていなくても、請負開発を前提とした相談を始めることは可能です。
ポイントは、
相談・調査 → 要件と未確定事項の整理 → 開発範囲の確定 → 成果物単位の請負開発
と段階を分けることです。
最初に確認したいのは、「要件が全部決まっているか」ではありません。
何が決まっていて、何がまだ決まっていないのか。
そこが整理できれば、外部の開発会社も、調査から始めるべきなのか、すでに成果物として見積できるのかを判断できます。
顧客案件を受注しているSIer・Web開発会社の方で、「まだ要件整理の途中だが、バックエンド部分をどこから外部へ切り出せるか相談したい」という場合は、プレイリーソリューションズへご相談ください。
Java / AWSを中心としたバックエンド開発、API連携、決済連携（GMOペイメントゲートウェイの導入経験を含む）、既存Webシステム改修について、要件整理から設計・実装・試験まで対応しています。
