不具合が残ったシステムを受け取る？業務への影響と対応約束の確かめ方

受け取る判断を、業務の確認と契約の条件へ結ぶ

まず「何を決めたいのか」をそろえます。必要な仕事ができるかを確かめる作業、契約や仕様と納品物を照合する手続き、本番で使い始める判断、支払いの扱いは、同じ一つの確認ではありません。この記事は、未解決の報告を持つ納品候補について、発注側が判断材料を整える方法に絞ります。

操作を確かめた記録と、契約・仕様で約束した内容を、分けて示せるでしょうか。

この節の解説図を原寸で見る

受入確認・検収・利用開始を同じ印にしない

受入確認では、業務担当が普段の仕事として何を行い、期待する状態と実際の結果がどう違うかを調べます。検収については、契約・仕様で何を納め、どの手続きで照合する約束かを原文で確認します。確認記録をまとめたこと自体で、契約上の受領や利用開始が決まるわけではありません。

デジタル庁の政府調達向け実践ガイドは、契約・仕様と納品物の照合と、サービス・業務の実現に足るかの受入を分けて説明しています。本稿では、資料の目的を混ぜない考え方の参考にします。民間の契約に共通する手続きや、支払時期を定める根拠にはしません。

納品候補と、二つの報告が同じ対象かを確かめる

この例では、納品候補の版と、二報告で使った版・環境は未確認です。開発会社へ、何を候補として提示し、それぞれの報告がどの版・環境のものかを聞きます。別の版の結果を、今の候補へそのまま当てはめないためです。

合意した受入条件の原文は未確認で、受入を判断する担当も未確認です。まず業務責任者と契約を管理する担当へ、条件の参照先と、誰がどこまで決められるかを確かめます。IT窓口で資料を整理できることと、受け取る権限を持つことを分けてください。

発注前に受入条件を作る段階は、納品物と確かめ方を発注前にそろえる記事で扱います。本稿は、その準備全体を繰り返すのではなく、今残っている報告を条件へ照らして相談する段階です。

予約が予定表に見当たらない報告から、仕事への影響を聞く

最初は貸出予約が予定表へ反映されない報告です。「表示されない」という申告から、仕事のどこを確かめ、どこまで影響を広げてよいかを読みます。画面を開き直す手順や原因を、この報告だけから決め付けません。

予約票と予定表のどこが対応せず、その事実から何を判断できるでしょうか。

この節の解説図を原寸で見る

操作・期待・申告された結果を一組にする

行った操作は「貸出予約を登録して営業所の予定表を開く」、期待する状態は「同じ予約を予定表で確認できる」です。届いた申告は「一つの試行では予定表に予約が見当たらない」。確認範囲は架空の一試行の報告のみに限られます。予約が保存されなかったのか、予定表への反映や表示の条件が違うのかは、まだ区別できません。

IT発注担当は、報告者へどの予約をどんな条件で登録し、どの予定表を見たかを聞きます。開発会社には、同じ候補版・権限・営業所の条件で何を確かめれば、期待と実際の違いを調べられるかを説明してもらいます。実際の報告にない予約番号、日付、画面の文言や保存結果は、説明のために作りません。

予約の仕事を進められるかを、業務側へ聞く

予定表で同じ予約を確かめられないなら、担当が貸出の予定を何で確認できるかが判断の問いになります。業務責任者へ、予約の受け付けから準備・受渡しまでのどの仕事が困るか、確認できている範囲を聞きます。この一試行から、全営業所が止まった、予約が消えた、受渡しを誤ったという結果へは広げません。

この報告の回避案は未確認です。紙へ写す、別画面を見るなどの方法が話に出ても、今回使えると決まった方法として記事に足しません。実際の案が出たら、元の予約と対応し、抜けや重複なく仕事を続けられるかを、確認する人と方法へ結びます。

機材名の違いは軽微か、元台帳を見る案を確かめる

もう一つは社内表示の機材名が異なる報告です。予約の報告を直した後の例ではなく、同じ納品候補について残る別の報告として読みます。名称の違いだけを見て、仕事には影響がないと先に結論付けないことが大切です。

機材一覧と元台帳を見比べる案は、必要な受渡しの仕事まで確かめられたでしょうか。

この節の解説図を原寸で見る

名称の違いという申告と、業務の影響を分ける

操作は「社内の貸出一覧で機材名を読む」、期待は「元の機材台帳と同じ名称が表示される」です。申告された結果は「一つの一覧に元台帳と異なる名称が表示された」で、確認範囲は架空の一表示の報告のみです。具体的な正誤の名称や機材番号は、この教材では定めていません。

業務担当へ、その一覧を何の確認で使い、機材をどの情報で特定して、予定や受渡し書と何を照合するかを聞きます。名称の違いが単なる表記なのか、対象の取り違えや他の資料にも関係するのかは、調べた結果と分けて説明してもらいます。名前の違いという分類だけで、影響の大きさを決めません。

元台帳を見る案と、確認済みの回避策を分ける

提案されているのは「元台帳を見て確認する案」です。ただし、両報告の回避方法を検証した結果は未確認です。元台帳を開けるという説明だけで、機材の選択、予定の照合、受渡しまで安全に続けられると認定しません。

実際に回避案を相談するなら、どの版と権限で、何の一覧と元台帳を用い、どの機材を同じ対象として確かめるかをそろえます。業務担当が必要な情報を照合できるか、余分な作業や見落としが生じないかを確認し、使える範囲と残る問題を判断者へ返します。ここで確認を実行した結果は示していません。

二報告とも他の営業所への影響は未確認で、原因も未確認です。名称の報告が一つの一覧だけだったことと、他の場所では問題がないと確かめたことを分けます。原因や影響を決める資料が足りなければ、どの対象を誰が調べるかを開発側と業務側でそろえます。

修正する人・方法・期限を、報告と再確認へ結び付ける

残す不具合に対する「後で直す」という返答だけでは、判断する人が、何をいつ誰から受け取り、どの条件で確認し直すかを読めません。二つの報告それぞれに、変更する対象と、確認する仕事を結び付けます。修正を約束する段階と、実際に修正して確かめた段階を分けてください。

修正する約束と、修正後に確かめる仕事が、同じ報告へつながっているでしょうか。

この節の解説図を原寸で見る

担当と方法は、報告ごとに説明してもらう

二件の修正担当は未確認で、修正方法も未確認です。開発窓口には、調査する人と実際に対応する人、修正する範囲と提示する版を確認します。窓口の名前が分かっただけで、相手が改修を引き受けたことにはしません。

予約の報告なら、予定表との対応について何を変更し、どの操作で同じ予約を確かめる提案かを聞きます。名称の報告なら、どの名称・元台帳との対応を直し、関連する一覧や受渡し資料へ何の影響があるかを聞きます。原因や実際の変更箇所を本稿で確定するのではなく、開発側の説明を求める問いです。

期限は、修正を出す時点と再確認の時間を合わせる

両報告の修正期限は未確認です。一般的な日数を埋めず、必要な利用時期、契約の期間、開発側が提示できる時点と、発注側が確認する時間を合わせます。修正版を渡す期限だけでなく、確認で違いが残った場合に誰へ戻すかも相談します。

デジタル庁の同ガイドは、残存する課題の改修について、期限・責任を持つ人・対応方法を明らかにし、発注側が受け入れられる計画かを契約期間の終了前に確認・合意する考え方を示します。政府調達の参考文書の説明であり、この架空の民間契約に修正義務や無償対応、特定の期限が生じたと決めるものではありません。

受入・条件付きの扱い・保留を、証拠と残条件で相談する

受入、条件付きの扱い、保留を、名称や件数だけの自動判定表にはしません。何を満たす必要があり、どの範囲を確かめ、何が残るかを、権限のある人へ説明して判断を受けます。この教材では、どれかを選んだ事実はありません。

報告、受入条件、修正の約束のうち、判断する人へまだ渡せない材料はどれでしょうか。

この節の解説図を原寸で見る

判断に使う原本と、実際の合意を確かめる

この例では、契約原本・テスト報告原本・開発会社の改修計画は未取得の想定です。また、実際の納品物を受領した記録でもありません。契約原本が手元にないことを、契約が存在しない、残件は無償で直す約束だ、という意味に補いません。

開発側の合意と業務責任者の合意はいずれも未確認です。条件付きの扱いを契約が認めるかも未確認なので、回避案と修正予定を並べただけで成立したとは説明できません。実際の原文と判断権限を、契約を管理する担当と双方の責任者へ確かめます。

必要な仕事を確かめられなければ、その条件を保留する

予定表で予約を確認する必要があるのに、その状態を満たせたか分からなければ、その条件を受入済みにしません。報告の対象版と再現条件、業務への影響、対応案と再確認の結果をそろえる作業へ戻します。何の回答が得られれば判断できるかを示すことが、単に「保留」とだけ返すこととの違いです。

名称の報告も、表示の違いだけから受入可能とは決めません。元台帳を見る案が必要な仕事に使えるか、影響をどこまで確かめたか、修正をどう約束できるかが未確認なら、その点を判断者へ渡します。確認の結果、必要条件を満たさないと分かった場合は、その差を明示し、修正や範囲の見直しを相談します。

条件を残す扱いを相談するなら、対象と合意を明らかにする

確認済みの回避策で必要な仕事を続けられると分かった場合でも、残す不具合の対象、影響と範囲、暫定手順、修正の誰・いつ・どう、再確認、残条件を、判断者と双方が同じ内容で理解しているかを確かめます。自社の契約と権限に照らして扱えるかを相談するもので、この記事の二報告が条件付き受入できた例ではありません。

二件の受入判断と今回の実際の受入結果は未確認です。支払いへの実際の影響も未確認です。利用開始や支払の扱いまで、この資料の整理だけで決めません。判断が必要なら実際の原文を契約担当や必要な専門家と確認し、異なる判断を同じ「完了」の印へまとめないようにします。

本番へ切り替える日の続行・保留・復旧は、切替と戻す条件を決める移行計画のように、利用開始の条件として別に整理します。納品候補についての受入相談を、切替実行や支払いの指示へ読み替えません。

回答と修正版が届いたら、元報告と業務の確認へ戻す

開発会社から返答が届いたら、元の二報告へ戻して読みます。何の版について何を説明し、どこを変更し、何がまだ分からないかを対応させます。返答が来たこと、修正したこと、業務で確かめたこと、受入を判断したことは別です。

修正の連絡は、同じ報告と必要な業務確認へ戻れているでしょうか。

この節の解説図を原寸で見る

誰が確かめ、どこまで見直すかを合わせる

両報告の再確認担当は未確認で、修正後の再確認結果も未確認です。業務担当がどの版でどの操作と資料を使うかを決め、開発側には変更が関係する他の箇所も説明してもらいます。

予約の修正なら、登録した予約と営業所の予定表の対応を、合意した条件で確認します。名称の修正なら、元台帳と一覧で同じ機材を確認できるかを見ます。別の営業所や関連資料を見る必要があるなら、その理由と対象を追加します。未確認の範囲を無条件に合格へ広げたり、理由なく全機能を一から再確認したりしないようにします。

回答の内容に応じて、次の相談を変える

原因や方法の説明だけが来たなら、対象版と提示予定、再確認の方法を続けて聞きます。回避案の検証結果が来たなら、使える仕事と条件、残る影響を業務側と読みます。修正版が来たなら、同じ報告の期待と実際の結果を記録して判断者へ返します。どの場合も、まだ届いていない証拠をあるものとして埋めません。

条件が変わる回答なら、変更前の条件と結果を残し、どこを変える合意かと新しい版で確かめる範囲をそろえます。元の結果を、そのまま新しい条件の成功へ移しません。二報告のどちらかが解決しても、もう一方まで解決済みとは扱わず、報告ごとに残る問いを追います。

一件の対応と再確認を継続して追う方法は、システム導入の課題管理へつなげます。本稿の主目的は、台帳の一般的な作り方ではなく、その記録から今の納品候補をどう判断者へ返すかです。

まとめ：報告の事実・残る条件・修正の約束を、判断者へ返す

未解決の不具合が残るときは、件数や呼び方を結論にせず、同じ納品候補の版、受入条件の原文、操作と申告、仕事への影響、回避案の確認結果、修正の約束と再確認を対応させます。判断できる人へ、分かったことと不足する材料を一緒に返してください。

今日、二つの報告のどちらから、誰へ何を尋ねるでしょうか。

この節の解説図を原寸で見る

二件は別の未解決報告で、修正の前後ではありません。名称違いを軽微、元台帳を見る案を安全確認済みの回避策とは決めません。架空の申告と、未取得の版・環境・影響・改修・再確認・受入の情報を分け、未確認をゼロ・失敗・成功・承諾へ変えずに読みます。