令和3年度 春期に実施されたシステムアーキテクト試験
午後Ⅱの全3問（論述式）です。問題文・設問と，問われていることの整理をそのまま読めます。
問1 アジャイル開発における要件定義の進め方について
情報システムの開発をアジャイル開発で進めることが増えてきている。代表的な手法のスクラムでは，スクラムマスタがアジャイル開発を主導する。システムアーキテクトはスクラムマスタの役割を担うことが多い。
スクラムでは，要件の“誰が・何のために・何をするか”をユーザストーリ（以下，USという）として定め，必要に応じてスプリントごとに見直す。例えば，スマートフォンアプリケーションによるポイントカードシステムでは，主なUSとして，“利用者が，商品を得るために，ためたポイントを商品と交換する”，“利用者が，ポイントの失効を防ぐために，ポイントの有効期限を確認する”などがある。
スクラムマスタはプロダクトオーナとともに，まずUSをスプリントの期間内で完了できる規模や難易度に調整する必要がある。そのためにはUSを人・場所・時間・操作頻度などで分類して，規模や難易度を明らかにする。USに抜け漏れが判明した場合は不足のUSを追加する。USの規模が大き過ぎる場合や難易度が高過ぎる場合は，操作の切れ目，操作結果などで分割する。USの規模が小さ過ぎる場合は統合することもある。
次に，USに優先順位を付け，プロダクトオーナと合意の上でプロダクトバックログにし，今回のスプリント内で実現すべきUSを決定する。スクラムでは，USに表現される“誰が”にとって価値の高いUSを優先することが一般的である。例えば先の例で，利用者のメリットの度合いに着目して優先順位を付ける場合，“利用者が，商品を得るために，ためたポイントを商品と交換する”のUSを優先する。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
情報システムの開発をアジャイル開発で進めることが増えてきている。代表的な手法のスクラムでは，スクラムマスタがアジャイル開発を主導する。システムアーキテクトはスクラムマスタの役割を担うことが多い。スクラムでは，要件の“誰が・何のために・何をするか”をユーザストーリ（以下，USという）として定め，必要に応じてスプリントごとに見直す。スクラムマスタはプロダクトオーナとともに，USをスプリントの期間内で完了できる規模や難易度に調整する必要がある。さらに，USに優先順位を付け，プロダクトオーナと合意の上でプロダクトバックログにし，今回のスプリント内で実現すべきUSを決定しなければならない。
本問は，アジャイル開発におけるUSの規模や難易度の調整と優先順位の決定について，具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要なアジャイル開発の主導者としての能力を評価する。
設問と問われていること
設問ア
800字以内
あなたが携わったアジャイル開発について，対象の業務と情報システムの概要，アジャイル開発を選択した理由を，800字以内で述べよ。
問われていること
- 対象の業務と情報システムの概要
- アジャイル開発を選択した理由
組み立ての注意
前文は，システムアーキテクトがスクラムマスタの役割を担い，プロダクトオーナとともにUSの調整や優先順位付けを進める場面を想定している。設問イ・ウはUSについて問うので，概要では，どのような利用者が何をする情報システムなのかが分かるように書いておくと，後でUSを具体的に示しやすい。
設問イ
800字以上1,600字以内
設問アで述べた開発において，あなたは，どのようなUSをどのように分類し，規模や難易度をどのように調整したか。分類方法を選択した理由を含めて，800字以上1,600字以内で具体的に述べよ。
問われていること
- 分類したUS
- USをどのように分類したか
- 規模や難易度をどのように調整したか
- 分類方法を選択した理由
組み立ての注意
前文は，USを人・場所・時間・操作頻度などで分類して規模や難易度を明らかにし，抜け漏れがあれば追加，大き過ぎる・難し過ぎるものは操作の切れ目や操作結果などで分割，小さ過ぎるものは統合する，という流れを示している。分類で規模や難易度が明らかになり，それを基に調整する，というつながりが分かるように書く。
採点講評は，具体的なUSやその価値に言及せず一般的な仕様や機能の要件定義を述べた論述や，USの規模や難易度は述べていてもその調整について具体的に述べていない論述を挙げている。USは“誰が・何のために・何をするか”の形で具体的に示す。
設問ウ
600字以上1,200字以内
設問イで述べたUSに関して，あなたは，どのような価値に着目して，USの優先順位を付けたか。具体的なUSの例を交えて，600字以上1,200字以内で述べよ。
問われていること
組み立ての注意
前文は，USに表現される“誰が”にとって価値の高いUSを優先することが一般的だとし，利用者のメリットの度合いに着目してポイントと商品の交換のUSを優先する例を挙げている。着目した価値が誰にとっての価値かを明らかにし，その価値からどのUSを優先したかを具体例で示す。
採点講評は，具体的なUSやその価値について言及していない論述を，趣旨に沿っていないものとして挙げている。
採点講評（IPA）
問1では，アジャイル開発におけるユーザストーリ（以下，USという）の規模や難易度の調整と価値に基づく優先順位の決定について，具体的に論述することを期待した。適切な論述では，USの分類，規模や難易度の調整，価値に基づく優先順位付けについて具体的に述べていた。一方で，具体的なUSやその価値について言及しておらず，一般的な仕様や機能の要件定義について述べている論述や，USの規模や難易度は論述されていても，その調整について具体的に述べられていない論述など，求められている趣旨に沿って適切に論述できていないものも散見された。システムアーキテクトは，USの抽出・調整・優先順位付けなどのアジャイル開発の手法を利用し，アジャイル開発を主導することを心掛けてほしい。
全問共通
全問に共通して，自らの経験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施事項の論述にとどまり，実施した理由や検討の経緯など，システムアーキテクトとして考慮した点が読み取れない論述も見受けられた。自らが実際にシステムアーキテクトとして，結論を導くに当たり，検討して取り組んだ内容を具体的に論述してほしい。
出典：令和3年度 春期 システムアーキテクト試験 午後Ⅱ 問1（表記を一部改変）
問2 情報システムの機能追加における業務要件の分析と設計について
現代の情報システムは，法改正，製品やサービスのサブスクリプション化などを背景に機能追加が必要になることが増えている。
このような機能追加において，例えば，新サービスの提供を対外発表直後に始めるという業務要件がある場合，システムアーキテクトは次のように業務要件を分析し設計する。
- 1. 新サービスの特性がどのようなものなのかを，契約条件，業務プロセス，関連する情報システムの機能など様々な視点で分析する。
- 2. 新サービスは従来のサービスと請求方法だけが異なるという分析結果の場合，情報システムの契約管理機能と請求管理機能の変更が必要であると判断する。
- 3. 契約管理機能では，契約形態の項目に新サービス用のコード値を追加して，追加した契約形態を取扱い可能にする。同時に請求管理機能に新たな請求方法のためのコンポーネントを追加し，新サービスの請求では，このコンポーネントを呼び出すように設計する。
このような設計では，例えば次のような設計上の工夫をすることも重要である。
- 対外発表前にマスタを準備するために，契約形態のマスタに適用開始日時を追加し，適用開始前には新サービスを選択できないようにしておく。
- 他のシステムに影響が及ばないようにするために，外部へのインタフェースファイルを従来と同じフォーマットにするための変換機能を用意する。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
法改正やサービスのサブスクリプション化などを背景に情報システムの機能追加が必要になることが増えている。
システムアーキテクトは，このような情報システムの機能追加において，要件を対象業務の制約条件，業務プロセス，関連する情報システムの機能など様々な視点で分析し設計する。
本問は，情報システムの機能追加で実施した設計について，業務要件の分析の視点と分析方法，設計の結果，設計で工夫したことについて，具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要な要件の分析及び設計の能力などを評価する。
設問と問われていること
設問ア
800字以内
あなたが携わった情報システムの機能追加について，対象の業務と情報システムの概要，環境の変化などの機能追加が必要になった背景，対応が求められた業務要件を，800字以内で述べよ。
問われていること
- 対象の業務と情報システムの概要
- 機能追加が必要になった背景
- 対応が求められた業務要件
組み立ての注意
背景は，前文の例（法改正，製品やサービスのサブスクリプション化）のような環境の変化として書く。
業務要件は，前文の「新サービスの提供を対外発表直後に始める」のように，業務の側から求められたことを書く。設問イはこの業務要件の分析を問うので，ここで情報システムの機能まで書き込んでしまうと，分析の余地がなくなる。
設問イ
800字以上1,600字以内
設問アで述べた機能追加において，あなたは業務要件をどのような視点でどのように分析したか。またその結果どのような設計をしたか，800字以上1,600字以内で具体的に述べよ。
問われていること
- 業務要件を分析した視点
- 業務要件をどのように分析したか
- 分析の結果行った設計
組み立ての注意
前文は，契約条件，業務プロセス，関連する情報システムの機能などの視点で分析し，その結果から変更が必要な機能を判断して設計する，という1〜3の流れを示している。分析の視点 → 分析結果 → 設計のつながりが分かるように書く。
採点講評は，業務要件の分析の視点がなく業務要件そのものを分析結果とした論述や，“要件を実現する設計”だけにとどまり，分析結果に基づく設計とは言い難い論述を挙げ，業務と情報システム双方の視点から業務要件を分析するよう求めている。
設問ウ
600字以上1,200字以内
設問イで述べた機能追加における設計において，どのような目的でどのような工夫をしたか，600字以上1,200字以内で具体的に述べよ。
問われていること
組み立ての注意
前文は，設計上の工夫の例として「対外発表前にマスタを準備するために」適用開始日時を追加すること，「他のシステムに影響が及ばないようにするために」インタフェースファイルの変換機能を用意することを挙げている。どちらも目的と工夫が対になっている。
工夫は，設問イで述べた設計に対するものにする。前文の例は，設問アの業務要件（対外発表直後の提供開始）から目的が導かれている。
採点講評（IPA）
問2では，情報システムの機能追加における業務要件の分析と，その結果に基づく設計について，具体的に論述することを期待した。多くの論述が業務要件の分析とその設計について具体的に述べていた。一方で，業務要件の分析の視点がなく業務要件そのものを分析結果とした論述や，“要件を実現する設計”だけにとどまり，分析結果に基づく設計とは言い難い論述も散見された。システムアーキテクトは，業務と情報システムを橋渡しする役割を担う。そのため，業務と情報システム双方の視点から業務要件を分析し，分析結果に基づいて設計を進めることを心掛けてほしい。
全問共通
全問に共通して，自らの経験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施事項の論述にとどまり，実施した理由や検討の経緯など，システムアーキテクトとして考慮した点が読み取れない論述も見受けられた。自らが実際にシステムアーキテクトとして，結論を導くに当たり，検討して取り組んだ内容を具体的に論述してほしい。
出典：令和3年度 春期 システムアーキテクト試験 午後Ⅱ 問2（表記を一部改変）
問3 IoTの普及に伴う組込みシステムのネットワーク化について
IoTの普及に伴い，従来スタンドアロンで利用していた組込みシステムをネットワークに接続し，ほかの組込みシステム，サーバなどと協調して動作させることによって，高度な機能を実現することが増えている。このネットワーク化された組込みシステムを端末機器とし，更に大きなシステムを構築することもある。例えば，コネクテッド・カーにおいて，車載の端末機器で車両情報をリアルタイムに検出，送信し，サーバ側で受信データをAI処理して故障の予兆診断を行うシステムがある。また，交差点などで死角となる位置にいる車両を信号機に設置した端末機器で検出し，車内の端末機器でその情報を受信して運転者に注意喚起するシステムもある。
ネットワーク化においては，負荷が高い処理をサーバ側で実行する，収集したデータを端末機器に一旦格納して間欠的にサーバに送り通信負荷を軽減する，また，ほかの端末機器を遠隔操作して機能を実現するなど，機能をサーバ・各端末機器にどのように割り当てるかが重要になる。さらに，ネットワークセキュリティを考慮するとともに，接続先の端末機器又はネットワークに不具合が発生した場合に被害が拡大しない安全性の工夫が必要になる。
組込みシステムのシステムアーキテクトは，組込みシステムのネットワーク化について，開発する組込みシステム及びほかの組込みシステム，サーバ，ネットワーク，これらを含むシステム全体の特徴だけでなく，セキュリティと安全性を考慮した上で，最適な機能分担になるようシステムを構築する必要がある。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
組込みシステムのシステムアーキテクトは，対象とする組込みシステムの機能向上を図るために，ネットワークに接続し，ネットワーク上のほかのシステムと協調動作させることがある。
本問は，組込みシステムのネットワーク化において，開発する組込みシステム及び接続したネットワーク，協調動作するほかのシステムとの間でどのように機能を分担したか，さらに，障害の発生，セキュリティなどについてどのように配慮したかを具体的に論述することを求めている。論述を通じて，組込みシステムのシステムアーキテクトに必要なシステムの理解力，適切な機能分担の設計及び非機能要件への配慮を踏まえたシステム構成能力を評価する。
設問と問われていること
設問ア
800字以内
あなたが開発に携わった組込みシステムの概要と，接続先の端末機器及びネットワークの概要を，ネットワーク化の目的を含め，800字以内で述べよ。
問われていること
- 開発に携わった組込みシステムの概要
- 接続先の端末機器及びネットワークの概要
- ネットワーク化の目的
組み立ての注意
設問イは「システム全体の特徴に基づく機能の分担」を問うので，開発する組込みシステムだけでなく，接続先の端末機器，サーバ，ネットワークを含めたシステム全体の構成が分かるように書く。採点講評は，システム全体の抽象的・一般的な説明に終始している論述を挙げている。
ネットワーク化の目的は，設問ウで達成状況を評価する基準になる。
設問イ
800字以上1,600字以内
設問アで述べた組込みシステムにおいて，システム全体の特徴に基づく機能の分担をどのように検討したか。その決定理由，想定した障害及びその回避策を含め，800字以上1,600字以内で具体的に述べよ。
問われていること
- システム全体の特徴に基づく機能の分担の検討
- 機能の分担の決定理由
- 想定した障害
- 障害の回避策
組み立ての注意
前文は，機能分担の例として，負荷が高い処理をサーバ側で実行する，収集したデータを端末機器に一旦格納して間欠的に送り通信負荷を軽減する，ほかの端末機器を遠隔操作して機能を実現する，を挙げている。決定理由は，システム全体のどの特徴からその分担にしたのかとして書く。
障害と回避策は，前文の「接続先の端末機器又はネットワークに不具合が発生した場合に被害が拡大しない安全性の工夫」に当たる。出題趣旨は，セキュリティなどへの配慮も挙げている。
採点講評は，実装の細部にとどまっている論述を挙げている。
設問ウ
600字以上1,200字以内
設問イで述べた組込みシステムにおいて，ネットワーク化の目的の達成状況及び考慮した事項の有用性の評価と，未達成の事項を含めた今後の課題を，600字以上1,200字以内で具体的に述べよ。
問われていること
- ネットワーク化の目的の達成状況の評価
- 考慮した事項の有用性の評価
- 未達成の事項を含めた今後の課題
組み立ての注意
達成状況は設問アで述べたネットワーク化の目的に，有用性は設問イで考慮した事項（機能の分担，障害の回避策）に照らして評価する。
今後の課題には「未達成の事項を含めた」とあるので，達成状況の評価で残ったことを課題につなげる。
採点講評（IPA）
問3では，組込みシステムのネットワーク化について，開発する組込みシステム，ネットワーク及びネットワークに接続されたほかの組込みシステムを含めたシステム全体を考慮した上でのシステムアーキテクチャの設計について，具体的に論述することを期待した。多くの論述はシステム全体を説明した上で，その特徴に基づく課題・制約・解決策について具体的に述べていた。一方で，システム全体の抽象的・一般的な説明に終始している論述や，実装の細部にとどまっている論述も散見された。
組込みシステムのシステムアーキテクトは，対象となる組込みシステムの課題とその解決策を関係者に説明する機会が多いと思われる。平素からシステム全体の概要を適切に把握し，課題と解決策を提案できるよう心掛けてほしい。
全問共通
全問に共通して，自らの経験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施事項の論述にとどまり，実施した理由や検討の経緯など，システムアーキテクトとして考慮した点が読み取れない論述も見受けられた。自らが実際にシステムアーキテクトとして，結論を導くに当たり，検討して取り組んだ内容を具体的に論述してほしい。
出典：令和3年度 春期 システムアーキテクト試験 午後Ⅱ 問3（表記を一部改変）