開発を1社に頼む？2社に分ける？受注画面と在庫更新の担当を決める方法

まず、両案で同じ改修を比べているか確認する

この例で相談するのは、受注画面から在庫更新へ注文番号と数量を渡す改修です。画面を作る仕事だけを比べる案と、在庫側への受け渡しや確認まで含む案では、同じ仕事を比べたことになりません。両案へ、どこからどこまでを今回頼みたいのかを同じ言葉で示します。

受注担当には、画面で何を入力し、どの状態を確かめたいかを説明してもらいます。在庫を扱う業務担当には、「在庫更新」が何を意味するかを尋ねます。例えば、受注時の引当、出荷後の数量変更などでは、更新する時点と確認する状態が違います。これは意味を具体化するための例で、この架空案の更新方法が決まっているという意味ではありません。

発注担当は、対象となる画面と在庫側の仕組み、担当者が確かめたい操作、分かっていない点を一枚にまとめます。対象外にする作業も候補へ確認します。既存の在庫の仕組みを残すのか、どこを変えるのかが不明なら、その範囲を尋ねるところから始めてください。依頼全体を整理する場合は、開発会社へ伝える提案依頼書の作り方も使えます。

1社案と2社案で、分かっている担当を並べる

二案で同じ会社か別の会社かを追えるよう、受注画面を頼む仮の会社を「開発会社A」、在庫更新を別会社へ頼む案の仮の会社を「開発会社B」とします。この例だけの架空の会社名です。以下の担当名は作る部分を示しており、接続や試験、契約上の責任まで示したものではありません。

1社案で同じ会社名が二か所にあっても、どの部署が受け渡しを設計し、どこまで試すかは確認が必要です。2社案では、受け渡す側と受け取る側の両方へ、同じ仕様と試し方を確認します。どちらの案も、図に線を引いたことだけで「連携できる」「担当が了承した」とは扱いません。

注文番号と数量を、どう渡すかを具体化する

接続部分、あるいはインターフェースとは、二つの仕組みが情報を受け渡す境目です。この例では受注画面側と在庫更新側の間にあります。発注担当が通信方式の細部を一人で設計する必要はありませんが、現場で何を実現したいかと、誰が双方の仕様をそろえるかは説明できるようにします。

「注文番号と数量を渡す」という短い言葉でも、番号が何を識別するか、数量の単位が何か、どの時点の情報かによって、受け取った側の扱いが変わります。必要な項目はこの二つだけで足りるかも含め、業務担当と開発会社に具体化してもらってください。記事から桁数や方式、更新処理を決定済みとして転記しません。

送るものと、受け取る側での意味

注文番号・数量を含む必要項目、形式、必須か任意か、在庫側で何に使うかを尋ねます。発注側は業務上の意味を説明し、開発側へ具体的な仕様と未決定点を示してもらいます。

渡す時点と、更新する時点

どの操作をきっかけに、いつ渡し、いつ反映を確かめるかを確認します。「入力したらすぐ」などの希望があれば、必要な理由と一緒に伝え、実現条件を回答してもらいます。この記事の案には時点の合意はありません。

受け取れないときの扱い

入力の不足、重複、通信の失敗などが起きた場合、誰が分かり、どう直して再開するかを尋ねます。これは確認する状況の例で、実際に障害が起きた記録ではありません。

仕様を書く人と、双方で確認する人

どの資料にまとめ、受注画面側・在庫更新側・業務担当の誰が内容を確かめるかを示してもらいます。変更があったときの連絡先と、どの版を使うかを合わせる方法も確認します。

IPAの外部インタフェースの合意形成ガイドは、接続先、情報の向き、方式や処理タイミング、項目の意味、例外時の扱いなどを整理する資料を説明しています。ここでは、送る側と受け取る側の認識をそろえる視点を参考にしています。2010年の例の通信方式や項目を、そのまま現在の自社仕様へ採用するものではありません。

両方をつないで試す人と、確かめる状態を決める

結合試験とは、作った部分をつないだ状態で、受け渡しや組み合わせが予定したとおりに働くかを確かめる試験です。画面だけの確認、在庫側だけの確認と分けて、両方をつなぐ試験を誰が準備・実行・記録するのかを尋ねます。作る会社が同じでも、この仕事を含む範囲は資料で確認します。

その場で動けばよいという説明だけでは、どの条件を確認できたかが残りません。正常な受け渡しに加え、情報が足りない場合、同じ情報が重複した場合、途中で止まった場合など、今回の業務に必要な状況を相談します。取り上げる状況と期待する結果は、現場の業務と仕様に合わせて決め、記事の例を自社の確定条件へ置き換えないでください。

試験用の環境とデータを誰が用意するか、両社が同時に参加する必要があるか、問題を見つけた後に誰が整理し再確認するかも尋ねます。1社案では会社内でまとめてもらえる範囲を、2社案では会社をまたぐ調整を含む範囲を確認します。試験担当が書かれたことと、業務として完成を受け入れる人が決まったことは別です。

検収という言葉が出たら、契約で定めた内容に合うかを確かめ、受け入れを判断する手続きとして、その対象・方法・判断者・時点を読みます。開発会社の試験記録、現場担当による操作確認、契約上の受け入れ判断を、同じ一つの作業だと省略しません。この架空案では、最終的に完成を判断する担当も未確認です。

日程と不具合の調整を、誰が束ねるか確認する

それぞれの会社が自分の部分の日程を出していても、つないで試せる日程になるとは限りません。受け渡し仕様の確認、画面側と在庫側の準備、結合試験、問題の修正、業務担当の確認には順序と依存関係があります。全体の日程を誰がまとめ、変更を誰へ知らせるかを両案へ尋ねます。

• 作業を始めるために、相手から必要なもの

  受注画面側が在庫側の仕様をいつ必要とするか、在庫側が画面側のどの情報を待つか、現場の確認時間をいつ確保するかを整理します。発注側が資料や担当者を用意する作業も含め、担当と前提を見える形にしてもらいます。

• 不具合が見つかったときの最初の連絡先

  現場担当が原因を特定できない段階でも、最初にどこへ連絡すればよいかを確認します。その窓口が何を受け取り、どの範囲で調査や会社間の連絡をまとめるかも尋ねます。一次窓口であることを、全ての原因や費用を負担する約束へ広げません。

• 仕様や日程が変わったときの扱い

  変更の内容、相手側への影響、試験のやり直し、費用や予定の見直しを誰が確認するかを尋ねます。会社間で直接話し合う場を設ける場合も、誰が決定内容をまとめ、発注側へ戻すかを明らかにします。

自社が全体調整を担当する案なら、その作業を引き受けられる人・時間・判断権限を確認します。開発会社へ調整支援を頼む案なら、会議の設定だけなのか、仕様の食い違いの整理や試験の進行まで含むのかを具体化します。担当者名があっても、引き受ける仕事と相手の了承が確認できなければ、決定済みとは扱いません。

両案へ同じ質問を返し、回答を記録する

発注担当は、画面と在庫更新を含む同じ改修範囲を両案へ見せ、つなぎ目について同じ質問を返します。回答欄を自社の予想で埋めるのではなく、どの会社が何を引き受けると答えたか、発注側へ何を求めているかを分けて残します。

1. 受け渡し仕様は、誰が書いて誰が確かめますか注文番号・数量を含む必要項目と意味、渡す時点、受け取れない場合の扱いを、どの資料へまとめるか尋ねます。画面側と在庫側が同じ版を使えるかも確認します。
2. つないだ試験と、完成確認を誰が進めますか試験の準備・実行・記録・問題の再確認、業務担当が試す範囲、受け入れを判断する人を、役割ごとに示してもらいます。現場で確認するための支援を含むかも尋ねます。
3. 日程と問題を、どの窓口がまとめますか全体の日程、遅れや仕様変更の連絡、原因が分からない問題の最初の連絡先、会社間の確認結果を発注側へ返す担当を尋ねます。
4. 自社に残る作業と、契約に含む範囲はどこですか自社が資料・データ・環境・担当者を用意する仕事、開発会社へ頼む調整の範囲、対象外、費用・契約条件を、根拠資料とともに示してもらいます。

これは説明用の質問例で、発注や契約を確定する文面ではありません。自社の業務と分からない点へ書き換えて使います。全てを理解してから相談を始める必要はありません。「在庫へ渡す仕様を、誰がまとめるか分からない」という一点から、両案へ返せます。

回答した人、回答日、対象の見積書・提案書・契約別紙と版を記録します。「連携は対応可能です」という答えだけなら、仕様作成、試験、調整、発注側の協力のうち何を含むのかを具体化してもらいます。回答内容が契約原文や別紙と食い違う場合は、どの記載を使うかを相手と契約担当へ確認します。

回答後に比較を直し、採用と保留の条件を分ける

回答が届いたら、会社名の欄だけを直すのではなく、接続仕様、結合試験、日程調整、一次窓口、完成確認、費用・契約条件を案ごとに更新します。回答がない箇所は、確認先と次の質問を添えて残します。「担当なし」「無料」「不要」へ置き換えません。

社内の判断では、必要な改修が含まれるか、自社が調整・業務確認を担えるか、未回答の重要条件が残っていないかを、理由と一緒に示します。費用や予定を比べる際も、それらが同じ作業範囲に対するものかを確かめてください。条件が整わなければ、回答を取り直す、案を修正してもらう、今は選ばないという判断を残します。

会社数と契約の相手・責任範囲を分けて読む

2社が作業する案でも、自社がそれぞれと直接契約するのか、一社が他社をまとめて引き受けるのかで、確認する契約関係が変わります。この記事の担当図は作る部分を示したもので、契約の相手や全体管理の取り決めは未確認です。会社名を二つ並べたことから、契約の構造まで決めつけません。

JEITA公開資料のモデル契約第13条と適用ガイドは、複数ベンダーへ分割する場合の全体管理と協力条件を扱い、統括するベンダーを置く場合や単一ベンダーの場合も説明しています。ここでは、誰と契約し、誰へ全体調整を頼むかを原文で確かめる視点を参考にします。特定モデルの説明を、全ての発注に当然に適用される法的責任や、架空二案の合意済み条項へ広げません。

契約を扱う社内担当・法務などの専門担当には、各社へ頼む範囲、全体調整の引受け、協力条件、試験と受け入れの扱いが、見積・提案・契約本文・別紙で対応しているかを示します。モデルの文言や記事の比較メモを使ったことだけで、自社の契約条件が適切だと認定しません。

二社の見積金額自体を同じ条件で比べる場合は、開発見積もりを比較する方法へ進めます。この記事の主な判断は、一つの改修を分担するときの接続・試験・調整の担当です。発注後の追加作業については、追加費用の回答と着手の了承を分ける方法で、変更後の確認を整理できます。

まとめ：作る担当と、つなぐ担当をそろえて選ぶ

同じ改修を1社に頼むか2社に分けるかは、画面と在庫更新を作る担当に加え、接続仕様、両方をつないだ試験、日程調整、不具合時の一次窓口、完成確認の担当をそろえて比べます。会社数だけでは、それらの担当や契約範囲は決まりません。

発注側が用意する資料や確認の時間、引き受ける調整も含めて候補へ尋ね、回答と根拠資料を比較へ戻します。未回答を予想で埋めず、自社の体制と契約範囲を照らして、採用する条件と確認を続ける条件を分けてください。架空二案の費用・契約・試験結果・採用は、いずれも決定済みではありません。