令和6年度 春期 システムアーキテクト試験 午後II 問2 バッチ処理の設計(論文)

テクノロジシステム開発技術システム構成

この問題は2024(R6)春 システムアーキテクト 午後IIに出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。

本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています(改行・記号・数式・図表参照の調整)。設問の趣旨および正解に影響する変更は加えていません。

学習ガイド

大量データを扱うバッチ処理の設計をテーマにした論述問題です。解答例は公表されないので、採点基準と講評から合格答案の要件を読み解きます。講評では、バッチの実行時間帯をずらすといった運用上の対処や、サーバ増設によるハードでの解決は「設計の工夫」と認められないと明言されており、処理方式そのものの設計判断を書く必要があります。エラー時の再処理の仕組みまで含めた設計の因果を固めて臨みましょう。

この記事で押さえる論点

  • 業務特性・制約から生じるバッチ処理の課題を特定する
  • 処理分割・多重化など設計上の工夫として課題解決を論述する
  • エラー時に処理を継続・再処理できる仕組みの設計理由を述べる

問題本文

バッチ処理の設計について

業務処理において,一定のリソースの下で大量データを効率的に処理するためにバッチ処理を選択することがある。バッチ処理では,大量データを処理すると処理時間が長い,オンライン処理との並行実施が必要,など様々な課題が生じる。システムアーキテクトには,業務上の特性や制約に基づいて課題を解決することが求められる。

課題を解決するために,例えば次のように,バッチ処理の設計を工夫する。

  • 売上データの取込件数が多いので後続の締め処理に間に合わなくなる,という課題に対して,インメモリデータ処理やオフラインバッチ処理などの処理方式を選択してスループットを上げる。
  • 現在のリソースではピークの日に全ての取引を処理しきれない可能性がある,という課題に対して,1日の処理件数の上限を設け,業務上優先度が高い取引から処理し,上限を超過した取引を翌日の処理に持ち越すようにする。
  • 画面で入力しているデータをバッチ処理が同時に更新しようとするとデータの競合が生じる可能性がある,という課題に対して,画面で入力したデータを一時保存し,バッチ処理終了後に非同期でデータベースに反映する。

また,エラーが発生しても処理を継続させる仕組みを組み込んでおくことも重要である。例えば,給与振込データ作成時に後続処理に影響を与えないために,エラーデータを読み飛ばして後で再処理できるようにする。再処理時には,二重更新させないために,処理済データを読み飛ばして未処理データだけ処理するようにする。

あなたの経験と考えに基づいて,設問ア~ウに従って論述せよ。

設問と解答・解説

設問ア

あなたが携わったバッチ処理の設計について,対象とする業務と情報システムの概要,及び業務上の特性や制約について,800字以内で述べよ。

模範解答

模範解答は公表されていません。下の採点基準と解説から、解答に求められる要素を読み取ってください。

採点基準(配点 34点)

知識・理解度(内容)(18点)

  • 18: 業務と情報システムの概要、及び業務上の特性や制約が、システムアーキテクトの視点から具体的かつ明確に把握・記述されている。
  • 14: 業務と情報システムの概要、及び特性や制約が記述されているが、一部具体性に欠ける部分がある。
  • 9: 業務とシステムの概要は記述されているが、特性や制約についての記述が不十分である。
  • 5: 業務やシステムの概要についての記述が極めて抽象的であり、特性や制約への言及がほぼない。
  • 0: 記述がないか、全く無関係の内容である。

論理性(構造)(16点)

  • 16: 業務内容とシステム概要、特性や制約の間に明確な関連性があり、論理的な構成で一貫して記述されている。
  • 12: 概ね論理的な構成で記述されているが、項目間の関連性がやや不明確な箇所がある。
  • 8: 論理構成にやや難があり、読み手が意図を読み取るのに苦労する。
  • 4: 構造化されておらず、単なる事象の羅列にとどまっている。
  • 0: 記述がないか、全く無関係の内容である。

解説

設問の意図と概要

本問は、システムアーキテクトとして、大量データを効率的に処理するバッチ処理の設計において、対象となる業務や情報システムの概要、および業務上の特性や制約を明確に把握・整理する能力を問うものです。

高得点のポイント

  • 業務と情報システムの概要が具体的であり、どのような目的のシステムかが第三者にも理解できること。
  • バッチ処理における業務上の特性(データ量、処理の頻度など)や、制約事項(処理時間の制限、オンライン処理との並行稼働の必要性など)が明確に述べられていること。
  • 続く設問で論じる「課題」と「設計の工夫」の前提となるため、それらと論理的に繋がる制約や特性を適切に設定していること。

設問イ

設問アで述べたバッチ処理について,どのような課題があったか。その課題を解決するために,どのような設計にしたか。工夫した点を中心に,800字以上1,600字以内で具体的に述べよ。

模範解答

模範解答は公表されていません。下の採点基準と解説から、解答に求められる要素を読み取ってください。

採点基準(配点 33点)

知識・理解度(内容)(17点)

  • 17: バッチ処理における課題を的確に抽出し、それを解決するためのシステムアーキテクトとしての「設計の工夫」が具体的に記述されている。
  • 13: 課題と設計の工夫が記述されているが、ハードウェアによる解決や運用での対処など、「設計の工夫」とは言い難い要素が一部含まれている。
  • 9: 課題は抽出されているが、解決策が抽象的であるか、業務要件との関係などが具体的に述べられていない。
  • 4: 課題抽出や解決策の記述が極めて不十分であり、妥当性が判断できない。
  • 0: 記述がないか、全く無関係の内容である。

説得力(考察)(16点)

  • 16: 業務特性や制約に基づいて課題解決策が導出されており、要求事項に対する技術適用の妥当性が高く説得力がある。
  • 12: 業務特性や制約に基づいた解決策が提示されているが、一部説得力に欠ける箇所がある。
  • 8: 解決策は提示されているが、業務特性や制約との関連性が薄く、妥当性の判断が難しい。
  • 4: 解決策の根拠が示されておらず、説得力が全くない。
  • 0: 記述がないか、全く無関係の内容である。

解説

設問の意図と概要

本問は、前段で定義した業務特性や制約に基づき、バッチ処理における課題をどのように抽出し、それを解決するための設計の工夫をどのように行ったかという技術適用能力と問題解決能力を評価します。

高得点のポイント

  • 抽出した課題が、「業務上の特性や制約」から論理的に導かれていること。
  • 課題解決のアプローチが、「サーバ増設」のようなハードウェアによる対応や「運用での回避」ではなく、システムアーキテクトとしての設計の工夫(アーキテクチャやソフトウェア設計レベルの工夫)であること。
  • 「優先度が高いものを取り込んだ」といった抽象的な記述にとどまらず、業務と優先度の関係など、工夫の背景にある業務上の要件が具体的に記述され、設計の妥当性が明確に示されていること。

設問ウ

設問アで述べたバッチ処理で,エラーが発生しても処理を継続させるようにするために,どのような仕組みを組み込んだか。そのように設計した理由とともに,600字以上1,200字以内で具体的に述べよ。

模範解答

模範解答は公表されていません。下の採点基準と解説から、解答に求められる要素を読み取ってください。

採点基準(配点 33点)

知識・理解度(内容)(17点)

  • 17: エラー発生時に処理を継続または再処理するための仕組み(設計)と、その仕組みを採用した理由が極めて具体的に述べられている。
  • 13: 継続の仕組みと理由は述べられているが、一部具体性に欠け、実務経験としての深みがやや不足している。
  • 9: エラー時の継続の仕組みは述べられているが、それを設計した理由の記述が不十分である。
  • 4: エラー対応の仕組みに関する記述が抽象的または表層的である。
  • 0: 記述がないか、全く無関係の内容である。

論理性(構造)(16点)

  • 16: 前段までの業務特性や課題設計と整合した形で、エラー対応の仕組みとその理由が論理的かつ一貫して記述されている。
  • 12: 概ね論理的に記述されているが、前段の設問との整合性が一部見えにくい箇所がある。
  • 8: 論理構成に飛躍があり、なぜその仕組みが必要だったかの理由付けが不明確である。
  • 4: 全体として一貫性がなく、内容の把握が困難である。
  • 0: 記述がないか、全く無関係の内容である。

解説

設問の意図と概要

本問は、バッチ処理においてエラーが発生した場合の対処について、手動運用によるカバーではなく、処理を継続させるための仕組みをどのようにシステムに組み込んだか、その設計理由とともに説明する能力を問うものです。

高得点のポイント

  • エラー発生時に処理を継続する、あるいは適切に再処理(リカバリ)を行うための具体的な仕組み(リトライ機構、チェックポイントリスタート、エラーデータの一時退避とスキップなど)が明確に記述されていること。
  • その仕組みを組み込んだ理由が、対象業務の特性(ダウンタイムの許容度、データの一貫性要件など)に基づき論理的に説明されていること。
  • 業務要件や課題に関するこれまでの内容と一貫性があり、システム全体の設計方針と矛盾しないこと。