納品後に見つかった不具合は誰に相談する？開発契約と保守契約の確認方法

不具合の申告・合意仕様・保守・追加希望を分ける

「不具合だから開発会社へ」「納品後だから保守へ」と、言葉だけで振り分けると、調べる対象も費用の前提も混ざります。まず、何が分かっていて、どの判断が残っているかを分けます。

不具合らしい事象の申告

利用した人から伝わった操作や表示です。申告を記録した段階と、担当者が同じ条件で再現し、原因を調べた段階を区別します。

合意した仕様

どんな仕事を、どの条件でできるようにするかについて、双方が参照する内容です。契約書、仕様書、見積りの注記など、どの版のどの記載を用いるかを確かめます。

納品時の確認記録

その版を、ある条件で確かめた記録です。短い入力で保存できた記録は、その条件についての材料です。長い入力や、変わった環境まで確認したかは別に読みます。

契約不適合

納品したものが契約の内容に合っているかを考える際の法律上の用語です。事象を見ただけで該当性や責任を決めず、実際の合意内容と事実、契約や法令に照らして確認します。

保守・サポート

契約で定める対象について、調査や復旧、更新、利用上の問い合わせなどを扱う仕事です。何を含むか、誰が担当するかは、その契約の文面で確かめます。

追加希望

利用者が新しくしてほしいこととして伝えた要望です。希望が明示されていても、元の契約に含むか、費用がどうなるかは別に確認します。

契約や見積りに「保証」「サポート」と書かれている場合も、名称だけで安心できる範囲を広げず、実際に何をしてもらえる意味かを作業に戻して聞いてください。

納品版・合意文・確認記録と、今の事象をそろえる

この例の共通資料には、顧客のメールアドレスを登録して保存できるという架空の合意文と、納品時には短いアドレスで保存を確認したという架空の記録があります。同じ版を照合する仮の呼び名を「納品版A」としています。

IT窓口は、申告で示された版と、納品時の資料が指す版を照らします。業務責任者は、どの入力や操作で、何を期待し、実際に何が見えたかを申告者へ確かめます。資料にない原因や確認結果を足さず、見たことと、これから調べることを一件にまとめます。

登録操作と、保存されたことの確認を分ける

登録ボタンを押したこと、一覧に表示されたこと、後で読み直して対象の値を確認したことは、それぞれ見ている場所が違います。今回の申告は、登録操作後も保存済み一覧に現れないという内容です。保存処理、一覧の表示、入力条件のどこに問題があるかは、まだ確認できていません。

「保存できない」という申告名を、そのまま原因の確定に使わず、入力した条件、操作、表示やメッセージ、読み直した結果を、分かる範囲で相手へ渡します。再現に使う例や確認の方法は、業務担当と調査する担当でそろえます。

納品時に確かめた範囲へ戻る

短いアドレスで確認した記録から、すべての長さや形式で保存できたとは言えません。反対に、長い入力で問題の申告が来たことだけで、当時の確認記録全体を誤りにもできません。元の合意文にどこまで入力条件が書かれ、その記録では何を確かめたかを読みます。

不具合の操作・期待と実際・修正後の確認を詳しく記録する段階では、課題管理と再確認の方法を使えます。この記事では、その材料をどの契約の扱いとして尋ねるかへつなげます。

三つの申告を、同じ契約の結論にまとめない

三件は、同じ受注管理アプリの納品版Aを示す、別々の架空申告です。申告の違いによって、先に照らす資料と質問が変わります。どの件も、契約上の対応先、相手の回答、費用、修正結果は未確認です。

長いアドレスを保存できない

長めのメールアドレスを入れ、登録ボタンを押した後も、保存済み一覧に現れないと申告されています。新機能の希望は明示されていません。合意した入力条件と今回の入力、納品時の確認範囲を照らし、担当者が同じ条件で再現できるかを確認します。

合意文にはメールアドレスを登録して保存できるとありますが、今回の条件がどこまで一致するかは未確認です。この時点で契約不適合、無償修正、特定の原因を確定せず、調査の対象と回答する人を尋ねます。

一覧を新しい形式で出したい

現在の一覧は見えており、業務担当が新しい形式で書き出したいと希望しています。この申告では新機能の希望が明示されています。ただし、元の合意で書き出しをどこまで扱っているかは未確認です。

新しい希望という言い方だけで、元の契約の対象外や有償対応を決めません。希望する使い方と、元の合意範囲を開発側へ説明し、変更相談として何を確認し、どの作業と費用を誰が回答するかを尋ねます。現在の一覧が見えることも、機能全体が正常という証拠へ広げません。

利用環境を変えた後の表示差

使う端末の環境を更新した後、入力欄の一部が見切れるという申告です。環境の更新という前提はありますが、原因の確認や再現はまだです。どの環境を前提にした合意か、今の利用条件は何か、元の環境とどう違うかを相手と照らします。

環境を変えたという事実だけで、すべて利用者側の責任、保守だけの対象、元の開発範囲外とは決めません。当時の環境を確認する方法、調査できる範囲、開発側と保守側の役割を聞きます。特定のOSや版、原因をこの記事の例へ補いません。

開発契約と保守契約へ、同じ質問を返す

開発した会社と保守を受け持つ会社が同じ場合も、契約ごとにどこまで対応するかを区別します。別の会社なら、調査資料を誰が渡し、どこが回答をまとめるかも決めます。契約書が手元にないときは、社内の契約管理者へ対象文書と窓口を確認し、分かる事象を先に整理します。

対象と作業を具体的に聞く

「この不具合は保守ですか」だけでなく、今回の画面や保存・一覧のどこまでを調べ、何を回答し、修正をどう相談するかを聞きます。開発側に確認する合意仕様の範囲と、保守側が扱う利用環境や調査・復旧などの範囲を、同じ申告資料へ対応させてください。

「対応する」という回答も、問い合わせを受け付ける、調べる、回避方法を示す、修正する、修正後を確かめる、では内容が違います。どこまでが回答されたかを作業で区別します。

期間は、起点と通知方法を一緒に読む

納品時に確認する期間、契約に定める対応対象の期間、不具合を伝える方法と期限、実際の調査・修正の予定を、一つの日数として扱いません。どの記載がどの期間を指すか、何を起点に数え、どこへ何を伝える必要があるかを原文で確かめます。

この架空例では、対応期間と通知期限は未確認です。一般的な日数や海外相談の期間を埋めず、実際の契約先へ質問します。期間内に連絡したが調査や修正が続く場合の扱いも、回答を得て記録します。連絡の方法や期限が関わる所は、原因の確定を待たず、窓口と原文を早めに確かめてください。

調査を頼むことと、修正の費用を了承することを分ける

原因や契約上の扱いを調べる仕事について、どの資料を用い、何を回答してもらえるか、調査に費用が発生するかを聞きます。調査の相談をしただけで、すべての修正と費用を了承した記録にしません。

費用が必要という回答なら、対象の作業、範囲や見積り、契約のどの記載に対応する説明かを確認します。費用を含む範囲や、進める判断をする人が不明なまま、金額を0円や確定額へ補わないでください。年間の保守見積を比べたい場合は、対象・作業範囲・応答条件をそろえる保守費比較で別に扱います。

図で、申告から元の資料と確認先をたどる

解説図を原寸で見る

この図を読んだ後の判断：保存できない申告は合意条件との照合と再現を、書き出し希望は元の範囲と変更の扱いを、環境更新後の差は前提となる環境と調査範囲を質問にできます。対応先・費用・結果は、契約原文と相手の回答が来るまで保留します。IT窓口は、確認できた回答と残る質問を、本文と図で同じ内容へ更新します。

相手の回答で扱いを更新し、調査と修正を分ける

回答が来たら、今回の申告と同じ版・操作・環境について答えているかを読みます。別の条件の説明を、今回の原因や対応範囲として使わないよう、参照した仕様と回答の版を結びます。次は、回答を得た場合の整理方法で、この架空例の実際の返答ではありません。

合意内容との対応と、担当が明らかになった場合

どの範囲を誰が調べ、どの結果を返すかを記録します。無償で扱うとの説明でも、何の調査や修正、どの対象版まで含むかを確認します。有償の説明なら、どの契約条件と作業範囲を根拠に、何を見積もる回答なのかを確かめます。回答を受け取ることと、社内で費用や着手を了承することは分けます。

追加希望や環境条件の確認が必要な場合

新しい書き出し形式については、元の合意との関係、必要な仕事、影響と費用の説明を求めます。環境条件については、当初の前提と今の状態、確認できる方法をそろえます。いずれも、申告名だけで誰の責任かを確定せず、担当者の回答と原文で判断材料を増やします。

契約の扱いや再現がまだ分からない場合

未回答を「問題なし」「有料に決定」「対応しない」と置き換えません。何の資料が足りず、誰がいつ回答できるかを残します。仕事に影響がある場合は、その範囲と利用予定を別に伝えます。影響の大きさと修正してほしい時期を整理する方法は、不具合の重要度・優先度の記事で確認できます。

修正候補が出た場合は、どの版を何の条件で確かめ、どの結果になったかを別に記録します。「直した」という連絡を、そのまま利用できる状態の確認へ変えず、必要な再確認へつなげてください。

三つの申告で違うことと、共通の未確認を分ける

三件で違うのは、申告の内容、入力・利用の前提、新機能を希望するという明示です。確認先・費用・修正の結果は、いずれも未確認です。別の架空の申告を同じ項目で読み、合意文、納品版、確認記録へ照らす質問を分けます。一つの障害や修正前後の経過ではありません。

「新機能の希望」の欄が「はい」なのは、一覧の新しい書き出しを望む申告です。その明示があっても、契約範囲と費用は未確認です。他の申告で希望が明示されていないことも、契約不適合や無償対応が確認できたという意味ではありません。

納品時の短い入力の記録は、その架空条件の確認材料として保持します。今回の申告を再現した記録や、修正後の結果へ書き換えません。相手から新しい材料が届いたら、何が追加で分かり、何がまだ不明かを分けて更新します。

一件の事象と未確認事項を、連絡文へそろえる

「保証で直してください」と結論だけを渡すより、見たこと、合意したはずの内容、その根拠、今分からない所を添えます。次は、保存できない申告を相談する架空の文面です。実際に送信した通知や、契約上の手続きを済ませた記録ではありません。

回答を受けたら、文面と記録に対象の版、担当、確認範囲、残る質問を反映します。相手の回答が自社の資料と食い違う場合は、どの合意文を参照しているかを確認し、責任者へ相談します。

期間・費用・法的責任を、日付だけで確定しない

納品から時間がたったこと、確認期間を過ぎたように見えること、保守契約という名前があることだけで、今回の無償・有償や法的責任は決められません。対象の合意、実際の事象、契約に書かれた期間や通知方法を照らす必要があります。この例では、その結論を出す相手の回答や契約条件が未確認です。

IPAの2019年のモデル契約解説は、対象システム、環境の再現可能性、期間に応じた費用の説明、保守との役割分担を、双方が対話する論点として示しています。本記事は、その観点を今回の質問へ応用しています。資料にある期間やOS更新の例を、現在の個別案件の法的結論へ当てはめるものではありません。

契約不適合の該当性、修正を求める権利や責任、支払義務などの判断は、実際の契約と事実、現在の法令に基づく確認が必要です。解釈が分かれる所や期限に関わる所は、原文をそろえて当事者の責任者や必要な専門家へ確認してください。この記事の記録や連絡文を作っただけで、法的な通知や手続きが完了したとは扱いません。

まとめ：事象と合意の対応を示し、誰が何を調べるか確かめる

納品後の不具合らしい事象は、発見日や「保守」という名称だけで振り分けません。納品版、合意仕様、当時の確認記録と、今の操作・表示・環境を一件にそろえ、開発契約と保守契約の対象、期間、通知方法、調査と費用の回答者を確かめます。

保存できない申告、追加希望、環境変更後の差は、質問する内容を分けます。再現や契約の扱いが未確認なら保留し、回答を得た範囲を更新します。調査、修正の相談、修正候補の提示、再確認の結果は、別の段階として残してください。