古いシステムとの接続は使える？一つの仕事で試す技術検証

何を確かめれば、旧接続を残す判断に使える？

技術検証は、設計を決めるうえで分からない一点を、小さく作る・試すことで確かめる仕事です。PoC（概念実証）と呼ぶ場合もあります。この例で知りたいのは、見栄えのよい新画面を作れるかではなく、古い接続を通じて点検予約を登録する仕組みを、新しい呼び出し元でも使えるかです。

APIは、別の仕組みから決めた形で情報を渡し、返答を受けるための窓口です。XMLは、情報をタグで区切って表す形式、DB（データベース）は予約などを保管する仕組みです。XMLだと分かっても、そのシステムが受け取る項目や書式、返し方まで分かるわけではありません。

現行の仕事のうち、今回はどの接続を試すのでしょうか。

図では、新しい画面案と、予約を受ける旧側の窓口を別にしています。画面の絵ができても接続を確かめたことにはなりません。今回は「点検予約1件の登録」を対象とし、どこまで確認できれば設計の次の相談へ進めるかを先に決めます。

試す場所・使う例・旧記録の確認先をそろえる

「一件だけなら試してよい」と自己判断する前に、使える環境と、結果を見る場所を確認します。接続先が違うと旧本番の予約を書き換えたり、検証結果を本番でも同じと誤解したりするためです。この架空例で分かることと、まだ答えがないことを分けます。

試す前に、どの場所と情報を担当へ確かめるでしょうか。

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

旧接続を読むための手掛かり

XMLの書式は文書化されていません。一方、旧側から返された内容の例は資料としてあります。返答例があることだけで、今回送る依頼の形式や、新しい呼び出し方が正しいとは決められません。旧側を保守する担当に、どの版・操作・環境の例かを聞きます。

試す環境と、試験用の情報

利用できる試験環境は未確認、仮名化した例を使ってよいかも未確認です。IT発注担当からシステム管理者へ、環境を用意できるか、誰が利用を認めるか、旧本番とのつながりをどう切り分けるかを確かめます。

旧記録を見る方法と、本番への接続

対象予約が旧側へ記録されたかを確認できるかは未確認です。保守担当と、許可された参照画面・記録の控えなど、同じ予約を確かめられる方法を相談します。この架空例では本番へのアクセスは許可されていません。試験環境が不明という理由で本番を代用しません。

書式が文書化されていないことは、接続が必ず使えないという判定ではありません。まず保守担当と、既存の動きから確かめられる説明・例・観測方法を探します。それでも必要な形式や確認先が分からなければ、検証前の調査として何が必要かを分けて依頼します。

現行の接続先そのものが分からないときは、古い構成図の接続を確かめ直す方法から整理できます。本稿は、絞った接続を実際に試すための条件と、その証拠で設計を選ぶ範囲へ進みます。

一件の入力・期待する返答・旧記録を対応させる

入力を作ってから「何が返ればよいか」を考えると、返ったものを都合よく成功と呼びやすくなります。業務側と旧システムの担当が、登録したい予約、受け付けたと分かる返答、記録を見つける方法を、同じ一件で説明します。

同じ予約を送る予定と、受け取った後に見る場所は対応していますか。

「架空OK」は説明用に置いた期待値です。旧システムにこの正式なコードがある、あるいは実際に返ったという意味ではありません。返答例を旧担当と読み、何を受け付けたことを、どの情報で区別できるかを確認してから期待する内容を直します。予約番号は、入力・返答・旧記録が同じ対象かを追うための仮の名前です。

予約番号、仮名、日付を並べても、送信するXMLの形は完成しません。必要な項目、文字の表し方、日付の形式、登録済み番号との関係などは、対象の旧仕様で確認します。ここでは実際のタグ名、送信先、認証情報、データベースの表名を推測して作りません。

入力項目の意味や、使ってよい値そのものが決まっていない場合は、社内APIの必須IDと返答を決める方法が先の確認になります。本稿では、その説明を得たうえで、旧接続が指定条件で使えるかを試す計画へつなげます。

依頼・返答・旧記録を、同じ条件で順に確かめる

試験環境、使う例、旧記録の確認方法がそろったら、開発担当と旧側の保守担当が、限った条件で依頼から記録までを追います。新しいWeb画面の完成を待たず、検証用の小さな呼び出し方を選ぶ場合もあります。ただし、何を省略したか、実際の画面や環境と何が違うかを残してください。

点検予約の依頼を送ることと、登録を確かめることは同じでしょうか。

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

1. 送る前の状態を確かめる対象の環境と版、使う入力、旧記録を見る担当を合わせます。同じ番号の予約が既にあるか、試した記録をどう区別し、後でどう扱うかも相談します。具体的な消去や書き換えの方法は、管理担当の手順へ従います。
2. 合意した一件を送り、何を送ったかを残す入力と、使った呼び出し方・環境を対応させます。操作したつもりという記憶だけでなく、許可された記録方法で対象を追えるようにします。検証用コードの作り方や実行権限は、案件の開発担当が確認します。
3. 返答を入力と結び付ける返答がどの予約へのものか、期待した内容とどこが同じかを読みます。通信の完了、受付の返事、予約の記録がそろうことを、別の確認として扱います。
4. 旧側の記録で、登録した予約を確かめる許可された方法で、同じ予約番号の内容を確認します。入力した表示名や日付に相当する情報が、想定した場所・状態で扱われているかを旧担当と照合します。見られない場合は確認待ちとし、返答があったことだけで登録完了にしません。

同じ依頼を繰り返しても結果が増えない性質を、冪等性（べきとうせい）と呼びます。登録処理にその性質があるとは限りません。重複した予約番号を送った場合、返答が途中で届かなくなった場合などは、通常の一件とは別の試験条件として、影響のない環境と確認方法を決めます。自動再送の実装があると推測して話を進めません。

分かったことと、まだ見ていないことを切り分ける

結果は「つながった」の一言へまとめず、依頼を送ったか、何が返ったか、旧側で何を確かめたかを分けます。下の状態は、この説明用の架空例ではまだ観測していないことを表します。確認項目があること自体を、実施した結果へ変えないでください。

「使える」と言うために必要な証拠のうち、どこがまだ取れていないでしょうか。

この例で、まだ実際の結果を得ていないこと

1. 依頼を送った記録実際に送ったか：未確認。送信前で止まったなら、まず環境・形式・利用条件のどこが未解決かを確かめます。
2. 返答を受けた記録返答を受けたか：未確認。返答があっても、何を受け付けたか、その一件と対応するかを確認します。
3. 旧側の予約を見た記録旧記録を確かめたか：未確認。参照できなければ、旧担当へ対象を示して確認を依頼し、その部分は未確認として残します。
4. 期待と比べた判断期待どおりか：未確認。返答だけ、旧記録だけではなく、最初に決めた条件のどこまで一致したかを説明します。

違いが出た場所から、必要な調査へ戻る

送信前に入力の形を作れないなら、書式の説明と元の例へ戻ります。返答の意味が読めないなら、旧側が何を受け付け、何を処理したかを保守担当へ聞きます。返答は受付を示すのに旧記録が見つからないなら、対象の環境、番号の対応、記録される時点や確認場所をそろえて調べます。この例で非同期の処理や特定の原因があると決めたわけではありません。

比較中に入力や接続方法を直した場合は、どの条件を変えてから得た結果かを区別します。最初の条件での結果を後から上書きし、初めからその方法で成立していたように説明しません。関係のない変更を一度に混ぜると、何が効いたかを確かめにくくなります。

この例の実際の性能は未測定、安全性の確認結果も未確認です。代表一件の成立性が分かっても、集中時の処理や全操作の安全性を確認したことにはなりません。必要な性能や安全上の確認は、その条件を決めた別の検証へ残します。

結果に応じて、接続を使う案・見直す案・追加検証を選ぶ

検証の返却先は、単なる実施報告の受け取り手ではありません。どの条件なら旧接続を使う案の設計へ進めるか、何が残ると判断を待つかを決める人です。IT発注担当は、結果と未確認を開発会社へ渡し、選択肢ごとの追加作業を説明してもらいます。

同じ検証メモから、どの案の判断材料が得られ、何が残るでしょうか。

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

この架空例では、旧APIを残す決定は未判断、置き換える決定も未判断です。設計の承認は未確認で、本番で使用できる状態ではありません。未確認事項を引き取る実際の担当も未定です。担当名や決定を推測で埋めず、社内の窓口と開発会社へ確認します。

検証結果を踏まえて設計案を判断した後の記録は、見た版・判断範囲・保留を対応させます。本稿の技術的に試した証拠と、誰がどの案を承認したかの記録は、用途を分けてつなげてください。

開発会社へ、試す範囲と受け取る材料を具体的に頼む

開発会社へ「PoCをお願いします」とだけ依頼すると、実演する画面を作る仕事なのか、旧接続を調べる仕事なのかが分かれます。今回確かめたいのは、点検予約の一操作について、指定条件で旧接続を使えるかです。検証に入る前に、何を受け取れば次の設計判断をできるかを合わせます。

発注時の問いと、返却される証拠は対応していますか。

1. 範囲と対象外を合わせる代表操作、利用できる環境、入力の範囲、旧側で見る場所を示します。新画面の完成、全業務、負荷や安全性の総合確認などを含むかは、必要性と範囲を別に話し合います。
2. 結果を受け取る方法を合わせる説明資料だけでなく、どの条件で何が観測され、何を確かめられなかったかを追える材料を求めます。元の例・修正した条件・結果を対応させ、実データの取り扱いは管理担当と相談します。
3. 質問と追加作業の相談先を合わせる旧システムの説明は誰が確認し、試験環境やデータの利用は誰に聞き、設計の次の判断は誰へ返すかを明確にします。調査で新しい仕事が必要と分かったら、目的・影響・追加作業の扱いを相談し、最初から含まれていたと決めつけません。

検証の日数、費用、成果物の利用条件、責任の範囲は案件で確かめる内容です。この記事の架空例から具体的な契約条件を確定しません。新しい接続方式の実装が必要と分かった場合は、調査で分かったことと、実装への着手を決めることを分けて説明してください。

まとめ：一つの仕事の証拠を、次の設計判断へつなげる

明日、旧側の担当へ何を見せ、何を聞けばよいでしょうか。

古い接続を残せるかは、画面の印象や、返答例が一つあることだけでは決まりません。代表する仕事を一つ選び、許可された試験環境と入力、期待する返答、旧記録の確認先をそろえます。実施後は、観測した範囲で設計の選択肢を比べ、足りない証拠は次の調査へ返します。

例中の架空OKは期待値であり、実際に返った応答ではない。旧接続の1操作で全運用/全データ移行は判定しない。