AS400保守・改修を外部依頼する時のRFP/要件整理チェックリスト

AS400 / IBM i の保守や改修を外部へ依頼する時は、技術者の経験年数だけでなく、対象業務、現行調査、完了条件、本番反映、切戻し、知識移管までRFPに書きます。依頼内容が曖昧なままでは、各社が別の前提で見積もるため、金額も作業範囲も比較できません。

RFPで最初に決める7項目

項目最低限書く内容曖昧な場合の問題
業務目的誰が、何に困り、何を改善したいか技術変更だけ行い業務課題が残る
対象範囲業務、画面、帳票、RPG/CL、PF/LF、バッチ、外部連携見積もり後に対象が増える
対象外今回変更しない業務、過去データ、周辺システム委託先ごとに前提が変わる
現行調査仕様不明点、調査方法、判断者、調査成果物推測した仕様で改修が進む
完了条件入力値、期待結果、件数・金額、性能、業務確認「動いた」の基準が一致しない
本番・切戻し反映時間、承認者、バックアップ、戻す条件と担当障害時に戻す判断が遅れる
引き継ぎソース、設計書、調査メモ、テスト証跡、教育範囲改修後も社内に知識が残らない

曖昧な依頼を完了条件のある依頼へ変える例

曖昧な例: 「月次売上一覧へ得意先分類を追加してください。できるだけ早くお願いします」

この書き方では、対象帳票、分類の取得元、過去分への適用、空欄時の扱い、並び順、合格条件が分かりません。次のように業務条件へ分解します。

確認項目記入例
目的営業担当が得意先分類別の売上を確認できるようにする
対象月次売上一覧。次回締め分から適用し、過去帳票の再作成は対象外
取得元得意先マスターの分類コードと分類マスターの名称
未設定「未設定」と表示し、処理は異常終了させない
合格条件指定した3得意先で分類名、合計金額、改ページが期待結果と一致する
影響確認RPG/CL、使用ファイル、CSV出力、後続バッチ、帳票保管
切戻し変更前オブジェクトとソースを保存し、承認後に戻せるようにする

現行仕様が分からない項目は調査工程にする

古いRPG、CL、Query、帳票、EDI連携が混在する環境では、RFP作成時点で全仕様が分かっているとは限りません。不明点を推測で要件にせず、「何を調べるか」「調査結果を誰が確認するか」「どの時点で改修範囲を確定するか」を工程として書きます。

  • 呼び出し元・呼び出し先と使用ファイルを確認する
  • 夜間バッチ、締め処理、帳票、外部連携への影響を確認する
  • 現行画面と帳票を業務担当者に確認してもらう
  • 調査で範囲が増えた場合の見積もり変更手順を決める

価格以外で比較する項目

比較項目確認する質問
業務理解受注、出荷、在庫、請求、締め処理をどう確認するか
障害対応連絡時間、一次切り分け、復旧判断、再発防止を誰が行うか
品質レビュー、テスト、証跡、承認をどう残すか
安全本番データ、機密情報、権限、AI利用をどう管理するか
知識移管社内担当者が次回調査できる資料と説明が残るか

成果物を名前だけでなく中身まで決める

「設計書一式」「テスト結果一式」だけでは、納品時に必要な情報が足りないことがあります。成果物ごとに、対象、記載項目、形式、更新責任者、レビュー者を決めます。現行調査を依頼する場合は、判明した仕様だけでなく、未確認事項と判断根拠も成果物に含めます。

成果物含める内容受入確認
影響調査一覧呼び出し元、使用ファイル、帳票、バッチ、外部連携対象外と未確認箇所も記載されているか
変更設計変更前後、業務ルール、例外、権限、エラー処理業務担当者が期待結果を確認したか
テスト証跡入力、期待値、実結果、確認者、実施環境正常系だけでなく境界値と異常系があるか
本番手順事前確認、反映、確認、切戻し、連絡順実施者と承認者が区別されているか
引き継ぎ資料日常確認、障害時の入口、連絡先、更新方法社内担当者が資料だけで一次確認できるか

追加要望が出た時の変更手順も決める

現行調査後に対象プログラムや連携が増えることはあります。追加要望が出た時は、口頭で作業へ混ぜず、追加理由、影響、費用、納期、受入条件を変更票へ記録します。元の見積範囲、追加範囲、対象外を分ければ、納期遅延や請求差の理由を後から説明できます。

本番情報とAI利用の条件を明記する

委託先へ渡してよい情報、社外へ出せない情報、マスキング方法、接続方法、ログ保存、アカウント終了時の処理を決めます。CodexなどのAIを使う場合も、入力禁止情報、利用できる環境、出力のレビュー責任、ソースやデータの保管方法をRFPに含めます。「AI利用可」だけでは安全条件になりません。

関連する確認資料