www.youtube.com 本動画では、令和5年度春期システムアーキテクト試験の午後Ⅰ問1「システム再構築における移行計画」を、問題文・解答例・採点講評の観点に沿って解説します。題材はA社および関連会社を含むAグループが、ERPパッケージのサポート期限を契機に基幹システムと情報系システムを再構築し、停止期間を抑えつつ月曜本稼働に接続する移行計画を立案する事例です。本問が問う本質は、データ移行を単なる技術作業として扱うのではなく、コード統一という業務改善の目的、ERP新旧で異なるデータ構造という技術制約、移行タイミングという運用制約を同時に満たす計画へ落とし込めるかにあります。午後Ⅰとしては、与件の制約条件を読み落とさず、設問が要求する観点で「何を」「なぜ」そうするのかを、根拠付きで簡潔に言い切れるかが合否を分けます。 背景としてAグループでは、現行ERPと分析ツールを利用しているもののサポート期限が迫っており、新ERPへの移行が不可避です。ただし単なるバージョンアップではなく、関連会社ごとにばらばらな勘定科目や各種コードをA社コードへ統一する必要があります。ここが本問の最重要論点で、コードが統一されていないこと自体はシステムの状態に過ぎず、業務としては経理担当者が表計算ソフトで個別集計を余儀なくされ事務処理負担が大きいという問題として顕在化しています。したがって移行計画では、停止期間を短くするだけでなく、コード統一を移行工程に確実に織り込んで再構築後の業務負担を解消することが必須になります。またERPの現行版と新版ではデータ構造が異なるため、単純移行では受け入れられず、構造変換とコード変換の順序設計が必要になります。さらに移行タイミングは業務影響が少ない月の中旬の土日を停止期間とし、月曜に新システムを本稼働させるという制約があり、受注停止や出荷、納品日設定などの業務側の依頼事項まで含めて計画しなければなりません。 設問1は、土曜日の受注停止という運用制約が顧客側の期待納期に与える影響を読み、得意先へ何を依頼すべきかを具体化する問題です。与件では受注データの納品日が受注日の翌営業日になるのが通常であり、かつ納品日は7日先までの営業日を設定できるとされています。移行期間の土曜日は受注を停止する一方で、金曜日までの受注に基づく土曜日の出荷は通常通り実施されるという前提がある以上、月曜日に品物を受け取りたい得意先は土曜日に注文できません。そこで依頼すべき内容は、金曜日までに月曜日を納品日とした発注を行ってもらうことです。午後Ⅰでの書き方のポイントは、「いつまでに」という期限と「どの条件で」という納品日指定を両方入れて、業務側が実行可能な依頼文として成立させることにあります。単に「前倒し発注」だけでは曖昧で、月曜納品という要件が落ちると採点者が評価しにくくなります。 設問2は、データ移行パターンのうち個別の移行プログラムを作るパターン3において、抽出後にコード変換を行う前に何をすべきかという工程順序の理解を問うています。ここでの読解ポイントは、コード変換はデータの値の変換であり、ERP新旧でデータ構造そのものが異なるという制約とは別問題である点です。新ERPが受け入れられる形へデータ構造を変換してからでないと、コード値を変えても格納先の形が合わず移行が成立しません。したがって抽出後、コード変換の前に行うべき処理は、現行バージョンのデータ構造から新バージョンのデータ構造へ変更することになります。この設問は、移行手順を一般論で並べるのではなく、与件が与える制約である「データ構造が異なる」を工程に正しく反映できるかを見ています。 設問3(1)は、パターン2としてERP移行ツールのみを使う場合に、再構築後も解決できない業務上の問題は何かを問うています。パターン2の本質は、データの値を加工できずそのまま移行することにあるため、関連会社のコードをA社コードへ統一できません。ここで問われているのは「コードが統一されない」というシステム状態ではなく、その結果として残る業務上の痛みです。つまり、コード不統一のため経理担当者が表計算ソフトで個別集計する手間が残り、事務処理の負担が大きいことが解決されないという点です。採点講評が強調しがちなポイントはまさにここで、状態を書いてしまう受験者が多い一方、採点者が求めるのは業務問題としての表現です。午後Ⅰでは、設問文が「業務上の問題」と指定した時点で、必ず業務影響や負担に言い換えて答える癖を付けることが安定得点につながります。 設問3(2)は、情報系システムへのデータ移行方針の理由付けで、データ整合性をどう保つかが論点です。A社のデータはコード変更がないため現行情報系から移行しても整合が崩れにくい一方、関連会社のデータは新基幹システムへの移行時にA社コードへ統一するためコード値が変わります。もし現行情報系から関連会社データをそのまま移すと旧コードのまま残り、新基幹システムのデータとコード体系が不整合になり、グループ横断の分析に支障が出ます。したがって情報系は現行情報系のデータをそのまま移行するのではなく、新基幹システム側でコード変換された後のデータに基づいて登録する必要があるという理由になります。ここは午後Ⅰらしく、整合性が崩れる対象が「関連会社データ」であること、崩れる原因が「コード変換の有無」であることを、因果で短くまとめられるかがポイントです。 設問3(3)は、過去データを全量移行する判断の根拠がどの方針に基づくかを問うています。停止期間短縮のために過去データを切り捨てるのは一般的ですが、本問ではあえて全て移行します。その根拠は、情報システム担当役員の指示である、過去の経営状況を新たな切り口でも分析できるようにするという方針です。過去データを移行しないと、新しい切り口で過去を分析することができず、方針に反します。ここは「全量移行＝停止が長くなる」という技術常識に引っ張られず、与件の経営判断を最上位の根拠として引用できるかが問われています。 設問3(4)は、停止期間短縮のために事前移行できる実績データの範囲と理由を、データ更新特性から導く問題です。与件では現行基幹システムの実績データは前月分と当月分だけ更新できる仕様であり、逆に言えば前々月以前は更新されず確定しています。移行前に内容が変わらないデータは稼働中でも移してよいので、事前移行できる範囲は前々月以前となり、その理由は前々月以前の実績データは更新されないからです。午後Ⅰの読解ポイントは、範囲の表現を「前月以前」などと曖昧にせず、更新対象が当月と前月であることから、確定範囲が前々月以前であると論理的に確定させることです。ここを曖昧にすると、事前移行後に差分が発生して二重移行や不整合のリスクが高まるため、設計としても成り立ちません。 本問全体を通じて重要なのは、移行計画が技術と業務の境界にあるという理解です。土曜受注停止のように顧客へ依頼すべき事項を具体化するのは業務設計であり、データ構造変換とコード変換の順序を誤らないのは技術設計です。さらにコード統一は業務改善の本丸であり、単にデータを移すだけのパターンでは目的が達成できないという評価軸がはっきり置かれています。採点講評で差がつくのは、こうした評価軸に沿って、状態ではなく業務問題として答えるべき箇所、データ鮮度や更新特性から事前移行範囲を導く箇所、そしてデータ構造差という前提を工程に反映させる箇所で、いずれも与件の一文を根拠として拾い上げられるかが勝負になります。 最後に、この動画を見る意義をまとめると、ERP再構築という現実のプロジェクトで必ず直面するサポート期限、停止期間制約、データ構造差、コード統一、分析要求という複合条件を、移行計画として破綻なく整理し、午後Ⅰで求められる粒度で根拠付きに答える手順を、令和5年度春期システムアーキテクト午後Ⅰ問1を通じて身に付けられる点にあります。解答例の暗記ではなく、与件から制約と目的を抽出し、工程順序とデータ範囲を論理的に確定し、業務上の問題を業務の言葉で表現するという作法を徹底することで、同種の移行計画問題でも安定して得点できる力を固めてください。
