令和3年度春期 システムアーキテクト 午後Ⅱ 問2

業務要件を整理するための視点

機能追加を考えるときは、現場の目的や利用者の課題を起点に、業務の流れと必要な情報を整理し、関係者の認識や制約を確認して、設計上の判断につながる観点を順序立てて見ます。

この問題で問われていること

この問いでは、個別の機能名や実装方法に先に注目せず、業務上の目的と関係者の期待をどう捉え、現状との差分を要件として過不足なく整理するかという一つの視点に集中して考えます。

視点

業務要件の分析では、誰が何のために作業し、どの情報を受け取り、どの状態を目指すのかを確認します。そのうえで、現状と変更後の差分、関係者間の認識、制約や優先度を整理し、設計へ渡せる粒度になっているかを見直します。

確認ポイント

• 利用者と業務上の目的が対応して整理されているか
• 現状の流れと追加後に変わる点が区別されているか
• 必要な情報、制約、優先度の関係が曖昧なまま残っていないか

解説

法改正やサービス形態の変化などを背景とする情報システムの機能追加について、業務要件を多面的に分析し、その結果に基づく設計と設計上の工夫を一貫して論述する問題です。

問題の全体像

法改正や製品・サービスのサブスクリプション化など、外部環境の変化によって既存の情報システムに機能追加が必要になる場面が題材です。問題文は、新サービスの特性を契約条件、業務プロセス、関連システムの機能など複数の視点で分析し、変更対象を判断して設計する流れを示しています。さらに、適用開始日時を管理して発表前の誤利用を防ぐことや、外部インタフェースを従来形式に保つ変換機能を用意することも例示しています。公式の出題趣旨では、業務要件の分析の視点と方法、設計結果、設計で工夫したことを具体的に論述し、要件分析と設計の能力を評価すると説明されています。採点講評でも、業務と情報システムの双方から業務要件を分析し、分析結果に基づいて設計することが重視されています。

設問ア

まず、実際に携わった機能追加を一つ選び、対象業務と情報システムの概要を簡潔に示します。その上で、法改正、新サービス開始、契約形態の変更など、なぜ機能追加が必要になったのかを環境の変化と結び付けます。最後に、開始時期、処理方法、既存サービスとの互換性、利用者や周辺システムへの影響など、対応を求められた業務要件を明示します。800字以内なので、業務概要、背景、要求された事項をそれぞれ具体的に書き、後続の設問イ・ウで扱う機能追加と矛盾しない事例に絞ることが重要です。

設問イ

設問アの業務要件を、対象業務の制約条件、業務プロセス、関連する情報システムの機能という観点から具体的に分析します。分析方法として、関係者への確認、現行業務やデータの整理、例外処理・利用権限・外部連携の確認など、自分が何を調べ、どの事実から判断したかを示します。その結果として、どの機能を変更し、どの機能を追加し、既存機能やデータをどう扱う設計にしたかを記述します。問題文の例では、従来サービスとの差異が請求方法にあると分析し、契約管理に新しい契約形態のコード値を追加するとともに、請求管理に新たな請求方法のコンポーネントを追加しています。自分の事例でも、分析した内容から設計結果が導かれる因果関係を明確にします。800字以上1、600字以内のため、視点、方法、分析結果、設計の順に具体例を配分します。

設問ウ

設問イで述べた設計の中から、特に目的を持って行った工夫を取り上げます。工夫そのものだけでなく、何を防止・実現するためか、どのような仕組みを採用したか、導入後にどのような効果があるかを一組で書くことが重要です。問題文の例では、対外発表前にマスタを準備しつつ適用開始前の選択を防ぐため、契約形態マスタに適用開始日時を持たせます。また、周辺システムへの影響を抑えるため、外部向けファイルを従来形式に合わせる変換機能を用意します。採点講評が具体的な論述を求めているため、「柔軟性を高めた」「影響を抑えた」といった抽象的な表現だけで終えず、対象、目的、実装上の工夫、得られた効果まで記述します。600字以上1、200字以内なので、複数の工夫を挙げる場合も、それぞれの目的と仕組みを簡潔に対応付けます。

学習のポイント

業務とシステムの両面から分析し、設計結果や工夫に至る理由を具体化する力を身に付ける。