令和5年度 春期 システムアーキテクト 午後問題
練習用オリジナル問題です
本ページの設問・題材・模範解答は、IPA 試験本番の出題傾向を模して作成した練習用オリジナル問題であり、 実際の試験で出題された問題ではありません。AI 採点機能の動作確認用としてご活用ください。 本番形式の学習には、実際の IPA 過去問（午前問題）をご利用ください。
⚠️ 練習用オリジナル問題です。本ページに掲載している午後問題は、IPA過去問の形式を模して作成した練習用オリジナル問題であり、実際の試験で出題された問題ではありません。
AI採点は目安です。本試験の採点とは異なる可能性があります。 採点結果は学習の参考程度にご利用ください。
情報システムの段階的な刷新における移行アーキテクチャの設計について
設問ア
0 / 800 字あなたが携わった情報システムの刷新の対象業務とシステムの概要、刷新の背景について、800字以内で述べよ。
構成のポイント（ヒント）
- 冒頭2-3行で対象（業種／規模／自身の役割）を提示し、文脈を即座に把握できる構成にする
- 背景は3要素以上を挙げ、具体的な数値や事実を添える
- 設問イへの橋渡しとして、最終段落で次の論点に着地させる
- 「私は〜の立場で」と主語を明示し、当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私は、中堅企業の基幹業務システム刷新プロジェクトにおいて、システムアーキテクトとして移行アーキテクチャの設計を担当した。 刷新対象は、企業の主要な受発注、在庫管理、会計処理を一元的に担うオンプレミス型の基幹システムであった。このシステムは稼働から15年以上が経過し、老朽化が著しかった。具体的には、COBOLで記述された複雑なビジネスロジックがブラックボックス化しており、新規事業への対応や法改正への追従に多大な時間とコストを要していた。また、システム障害時の影響範囲が広範にわたり、復旧に時間を要するケースも散見され、ビジネス継続性へのリスクが高まっていた。 刷新の背景としては、まずビジネス環境の変化が挙げられる。ECサイトとの連携強化や、顧客ニーズの多様化に対応するための柔軟なサービス提供が求められていたが、既存システムではこれらを迅速に実現することが不可能であった。次に、運用コストの増大と保守要員の高齢化・不足があった。老朽化したシステムの維持には専門的な知識が必要であり、属人化が進んでいたため、将来的な運用継続に懸念があった。これらの課題を解決するため、クラウドネイティブなマイクロサービスアーキテクチャへの移行を伴う全面的な刷新が決定された。特に、ビジネスへの影響を最小限に抑えつつ、段階的に新システムへ切り替える移行戦略が必須とされた。
採点の観点
【A評価相当】 - 対象事業／プロジェクトの概要（規模／自身の立場）が具体的に記述されている - 背景・前提が複数の論点から立体的に分析されている - 設問イ・ウへの伏線として論点の構造化が為されている 【B評価相当】 - 概要は記載されているが規模感や立場が曖昧 - 背景の記述が単発的で構造化が弱い 【C評価相当（要改善）】 - どの組織でも当てはまる一般論 - 背景・前提が当該事業／プロジェクトに紐付いていない
設問イ
0 / 800〜1600 字設問アで述べた背景を踏まえて、あなたが設計した段階的移行アーキテクチャの内容と、設計上で重視した点を、800字以上1,600字以内で具体的に述べよ。
構成のポイント（ヒント）
- 全体像を冒頭で要約し、読み手に骨格を先に提示する（パラグラフ・ライティング）
- 「重視した点」は2〜3点に絞り、それぞれを独立した節として論述する
- 各重視点には『なぜそう判断したか』『代替案を取らなかった理由』を添える
- 設問アとの整合を1対1で対応させ、論理的整合性を見せる
- 数値（投資額／期間／顧客数／市場規模）を最低3箇所に織り込む
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設問アで述べた背景を踏まえ、私はビジネスへの影響を最小限に抑えつつ、リスクを分散するための段階的移行アーキテクチャを設計した。このアーキテクチャは、新旧システムの並行稼働を前提とし、データ整合性の確保と業務継続性を最優先に考慮した。 設計上で最も重視した点は、「マイグレーションパスの明確化」と「データ同期の信頼性」である。まず、マイグレーションパスについては、機能単位での段階的移行を計画した。具体的には、初期段階で参照系機能（在庫照会、顧客情報照会など）を新システムへ移行し、次に更新系機能のうち影響範囲の小さいもの（新規受注登録など）を移行、最終的に基幹となる会計連携や既存受注変更機能を移行する3段階のパスを設定した。各段階において、新旧システムの境界を明確にし、APIゲートウェイを介した疎結合アーキテクチャを採用することで、相互の依存度を低減させた。これにより、問題発生時の影響範囲を限定し、迅速なロールバックを可能とした。 次に、データ同期の信頼性確保である。新旧システム間でデータ整合性を維持するため、私はメッセージキューイングシステムと変更データキャプチャ（CDC）技術を組み合わせたハイブリッド型データ同期アーキテクチャを設計した。旧システムからの更新はCDCでリアルタイムに検知し、メッセージキューを介して新システムへ連携する。新システムからの更新は、非同期処理としてメッセージキューに格納し、旧システムが定期的にバッチ処理で取り込む方式とした。この設計により、旧システムへの負荷を最小限に抑えつつ、データ同期の遅延を許容範囲内に収めた。さらに、データ同期の異常を検知するための監視メカニズムを組み込み、両システム間のデータ不整合を自動的に検知・通知する仕組みを構築した。 設計過程で直面した困難の一つは、旧システムのデータ構造の複雑性であった。長年の改修により、一つの論理エンティティが複数の物理テーブルに分散していたり、非正規化されたデータが多数存在したりしていた。これに対し、私はデータ移行チームと密に連携し、旧システムのデータ辞書を徹底的に分析した。そして、新システムへのマッピングルールを詳細に定義し、データクレンジングと変換ロジックを事前に実装・検証することで対応した。この作業には、延べ3ヶ月を要したが、後のデータ移行における手戻りを大幅に削減できた。 もう一つの困難は、業務部門からの「移行期間中の業務負荷増大」への懸念であった。特に、新旧システムが並行稼働する期間は、業務ユーザーが複数のシステムを操作したり、データ入力が二重になったりする可能性があった。これに対し、私は業務部門と繰り返しワークショップを開催し、暫定的な業務手順を詳細に検討した。例えば、新システムで登録されたデータを旧システムに自動連携する仕組みを導入し、手動での二重入力を極力排除した。また、業務ユーザー向けのトレーニングプログラムを早期に開始し、新システムへの習熟度を高めることで、移行期間中の混乱を最小限に抑えるよう努めた。この取り組みは、PMBOKの「ステークホルダー・エンゲージメント」の原則に基づき、関係者の期待値を管理し、積極的に巻き込むことを意識したものであった。
採点の観点
【A評価相当】 - 戦略／設計／計画／監査手続の内容が具体的に記述されている - 設問アの背景と論理的に対応している - 「重視した点」が3つ程度、それぞれに具体的判断と理由が明示されている - 数値（金額／期間／規模）が適切に織り込まれている 【B評価相当】 - 戦略／設計／計画は記述されているが、提供価値が一般論にとどまる - 重視点が単に列挙されているだけで判断理由が弱い - 設問アとの連携が弱く、戦略が独立して語られている 【C評価相当（要改善）】 - 標語の繰り返しで具体性に欠ける - 自身の役割が見えず、評論的記述に終始
設問ウ
0 / 600〜1200 字設問イで述べた移行アーキテクチャについて、移行実行時の工夫、関係者との合意形成、及び評価と今後の改善点を、600字以上1,200字以内で具体的に述べよ。
構成のポイント（ヒント）
- 経営層／関係者への説明と合意形成を、それぞれ独立段落で論じる
- 反対意見や困難の具体例を必ず1つ以上盛り込み、それへの対応を描く
- 評価点と改善点を明確に分け、改善点には今後への具体的アクションを添える
- 数値（期間／工数／合意までのステップ数）を散りばめて当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設問イで述べた移行アーキテクチャに基づき、移行実行時には以下の工夫を行った。まず、段階的移行の各フェーズにおいて、小規模なパイロット運用を導入した。これは、全ユーザーに影響が及ぶ前に、特定の部門やユーザーグループで新システムを先行利用してもらい、潜在的な問題や改善点を洗い出すことを目的とした。パイロット運用期間中には、ユーザーからのフィードバックを迅速に収集し、システムや業務手順に反映させるアジャイルなアプローチを採用した。これにより、本番移行時のリスクを大幅に低減できた。 関係者との合意形成においては、特に経営層と業務部門の理解を得ることに注力した。私は、移行アーキテクチャの全体像と各段階でのビジネスメリット、リスクを可視化した「マイグレーションロードマップ」を作成し、定期的に進捗報告会を開催した。このロードマップには、各段階でのデータ整合性保証の仕組みや、障害発生時の対応フローも明確に記載し、透明性を高めた。特に、データ整合性の確保については、ISO/IEC 27001に基づく情報セキュリティマネジメントの観点から、データ保護と正確性の重要性を繰り返し説明し、経営層からの信頼を得た。また、業務部門に対しては、ITILのサービス移行プロセスを参照し、新システムへの切り替えに伴うサービスレベルの変化や、新たな運用体制について丁寧に説明し、不安の解消に努めた。 移行実行時の困難として、新旧システム間のデータ同期で一時的な遅延が発生したことが挙げられる。これは、特定の時間帯に旧システムへのデータ更新が集中し、CDCの処理能力を超過したためであった。この事態に対し、私は緊急でデータ同期基盤のスケールアウトを実施し、メッセージキューの処理能力を増強することで対応した。また、恒久的な対策として、データ更新が集中する業務プロセスの見直しを提案し、バッチ処理の分散化を促した。 最終的な評価として、本プロジェクトは計画通りに全機能の新システムへの移行を完了した。新システム稼働後、旧システムと比較して、業務処理速度が平均で約30%向上し、特に受注処理ではピーク時で約50%の高速化を達成した。また、運用コストは年間で約20%削減され、属人化されていた保守業務も大幅に改善された。これは、クラウドインフラへの移行とマイクロサービス化による効果である。さらに、新システムはAPI連携により、ECサイトとの連携にかかる開発期間を従来の半分に短縮できる見込みである。 今後は、移行中だけ必要な二重入力と照合作業を棚卸しし、不要になった暫定手順を廃止する。新旧データの照合結果と障害時の差戻し記録を保存し、残った不整合の解消を担当部門と確認する。各段階の運用負担を次の移行計画へ反映し、短い納期だけで移行完了を判断しない。
採点の観点
【A評価相当】 - 関係者への説明・合意形成の両方を具体的に記述 - 「評価」と「改善点」が両方明示され、改善点には次への学びがある - 反対意見・困難への対応プロセスが具体的に描かれている - 自身の関与と判断が明確 【B評価相当】 - 説明や合意形成は記述されているが、困難の描写が弱い - 評価のみで改善点が形式的、または逆 【C評価相当（要改善）】 - 「説明した」「合意を得た」と結果のみで過程が不明 - 改善点が当たり障りのない一般論