平成29年度 秋期に実施されたシステムアーキテクト試験
午後Ⅱの全3問（論述式）です。問題文・設問と，問われていることの整理をそのまま読めます。
問1 非機能要件を定義するプロセスについて
情報システムは，非機能要件の考慮漏れによって重大な障害を引き起こすことがある。非機能要件とは，信頼性を含む品質要件，運用・操作要件など，機能要件以外の要件のことである。利用者は非機能要件を明確に認識していないことが多いので，システムアーキテクトは，利用者を含む関連部門へのヒアリングによって必要な情報を収集する。収集した情報を基に，業務及び情報システム両方の視点から非機能要件を検討し，検討結果を意思決定者に提示し，判断してもらう。
例えば，信頼性要件の場合，次のようなプロセスで検討する。
- リスクを洗い出し，想定される損失並びに事業及び業務への影響を分析する。
- 分析結果に基づき，目標とすべき復旧時間を設定する。
- 設定した復旧時間を達成するための情報システムの実現方式を具体化する。
その際，前提となるシステム構成，開発標準，システム運用形態など，非機能要件を定義するに当たって制約となる事項を示した上で，例えば次のように，意思決定者に判断してもらうための工夫をすることも必要である。
- 複数のシステム構成方式について，想定される損失と，対策に必要なコストの比較を示す。
- 信頼性を向上させるためにデュアルシステム方式にすると効率性の指標の一つであるスループットが下がる，といった非機能要件間でのトレードオフが生じる場合，各非機能要件の関係性を示す。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
情報システムは，非機能要件の考慮漏れがあると，本稼働後に重大な障害を引き起こすことがある。システムアーキテクトは，非機能要件を適切に定義しなければならない。
本問は，システムアーキテクトが，非機能要件を業務及び情報システム両方のどのような視点から，どのようなプロセスで検討したか，また，意思決定者に判断してもらうためにどのような工夫をしたのかを，具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要な非機能要件を定義する能力と経験，意思決定者へ説明する能力を評価する。
設問と問われていること
設問ア
800字以内
あなたが要件定義に携わった情報システムについて，対象業務の概要と情報システムの概要を，800字以内で述べよ。
問われていること
組み立ての注意
設問イで非機能要件を業務及び情報システム両方の視点から検討するので，その前提になる対象業務と情報システムの特徴が分かるように書いておくと，後の論述がつながる。
採点講評は，業務との関連性が乏しい論述を挙げている。対象業務の概要は，設問イの業務の視点につながる内容にする。
設問イ
800字以上1,600字以内
設問アで述べた情報システムについて，どのような非機能要件を，業務及び情報システム両方のどのような視点から，どのようなプロセスで検討したか。検討した結果とともに，800字以上1,600字以内で具体的に述べよ。
問われていること
- 検討した非機能要件
- 業務及び情報システム両方の視点
- 検討のプロセス
- 検討した結果
組み立ての注意
問われているのは，非機能要件，視点，プロセス，検討した結果の4つ。視点は業務と情報システムの「両方」が問われている。
プロセスは，前文の信頼性要件の例（リスクを洗い出して損失と影響を分析する，目標とすべき復旧時間を設定する，実現方式を具体化する）のように，段階を追って書く。
採点講評は，非機能要件の検討ではなく実現方法の検討に終始した論述を挙げている。前文の例でも，実現方式の具体化はプロセスの最後の一段階にとどまる。
設問ウ
600字以上1,200字以内
設問イで述べた非機能要件の検討の際，意思決定者に判断してもらうためにどのような工夫をしたか。600字以上1,200字以内で具体的に述べよ。
問われていること
組み立ての注意
工夫は，前文の例（複数のシステム構成方式について想定される損失と対策コストの比較を示す，非機能要件間のトレードオフが生じる場合に各非機能要件の関係性を示す）のように，判断しやすくするために何をどう示したかとして書く。前文は，前提となるシステム構成，開発標準，システム運用形態など，制約となる事項を示すことも挙げている。
採点講評は，意思決定者への説明に関する工夫を問うたにもかかわらず，説明した内容だけを述べており，工夫に触れていない論述を挙げている。
採点講評（IPA）
問1（非機能要件を定義するプロセスについて）では，どのような非機能要件を，業務及び情報システム両方の視点からどのようなプロセスで検討したか，それを第三者に説明する際にどのような工夫をしたかについての具体的な論述を期待した。多くの論述は具体性があり，実際に要件定義に携わった経験がうかがえた。一方で，業務との関連性が乏しい論述や，非機能要件の検討ではなく実現方法の検討に終始した論述も見受けられた。また，意思決定者への説明に関する工夫を問うたにもかかわらず，説明した内容だけを述べており，工夫に触れていない論述も見受けられた。システムアーキテクトには，業務及び情報システムの両方の視点から非機能要件を含む要件定義を行い，それを分かりやすく第三者に説明することが求められる。要件の検討に加えて，検討結果を分かりやすく説明することも心掛けてほしい。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施事項だけの論述にとどまり，実施した理由や検討の経緯が読み取れない論述も見受けられた。自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：平成29年度 秋期 システムアーキテクト試験 午後Ⅱ 問1（表記を一部改変）
問2 柔軟性をもたせた機能の設計について
販売管理システムにおける販売方法の追加，生産管理システムにおける生産方式の変更など，業務ルールが度々変化する情報システムや業務ソフトウェアパッケージの開発では，様々な変化や要望に対して，迅速かつ低コストでの対応を可能にする設計，言い換えると柔軟性をもたせた機能の設計が求められる。
システムアーキテクトは，情報システムの機能に柔軟性をもたせるために，例えば，次のような設計をする。
- “商品ごとに保管する倉庫が一つ決まっている”という多対1の業務ルールを，“商品はどの倉庫でも保管できる”という多対多の業務ルールに変更できるように，商品と倉庫の対応を関係テーブルにしておく。
- 多様な見積ロジックに対応できるように，複数の見積ロジックをあらかじめ用意しておき，外部パラメタの設定で選択できるようにしておく。
また，このような柔軟性をもたせた機能の設計では，処理が複雑化する傾向があり，開発コストが増加してしまうことが多い。開発コストの増加を抑えるためには，例えば，次のように対象とする機能や項目を絞り込むことも重要である。
- 過去の実績，事業環境の変化，今後の計画などから変更の可能性を見極め，柔軟性をもたせる機能を絞り込む。
- 業務の特性などから，変更可能な項目を絞り込むことで，ロジックを簡略化する。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
情報システムの開発では，柔軟性をもたせた設計をすることがある。システムアーキテクトは，このような場合，機能の構造やデータの構造などによって柔軟性をもたせるための設計をする。
本問は，情報システムの機能に柔軟性をもたせるための設計と，設計の結果，開発コストの増加を抑えるために実施した機能や項目の絞り込みとその理由を，具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要な情報システムの設計能力，業務や情報システムの分析能力，経験を評価する。
設問と問われていること
設問ア
800字以内
あなたが設計に携わった情報システムについて，対象業務の概要，情報システムの概要，柔軟性をもたせた機能の設計が必要になった背景を，800字以内で述べよ。
問われていること
- 対象業務の概要
- 情報システムの概要
- 柔軟性をもたせた機能の設計が必要になった背景
組み立ての注意
背景は，前文の例（販売方法の追加，生産方式の変更）のように，業務ルールが度々変化する事情として書く。
ここで書く業務ルールの変化が，設問イの「柔軟性の対象にした業務ルール」につながる。採点講評は，現在の要望だけでなく，将来の変化も意識した設計を求めている。
設問イ
800字以上1,600字以内
設問アで述べた情報システムで，機能に柔軟性をもたせるために，どのような機能に，どのような設計をしたか。柔軟性の対象にした業務ルールを含めて，800字以上1,600字以内で具体的に述べよ。
問われていること
- 柔軟性をもたせた機能
- 柔軟性をもたせるための設計
- 柔軟性の対象にした業務ルール
組み立ての注意
設計は，前文の例（商品と倉庫の対応を関係テーブルにしておく，複数の見積ロジックを用意して外部パラメタで選択できるようにしておく）のように，データの構造や機能の構造をどうしたかまで書く。出題趣旨も，機能の構造やデータの構造などによって柔軟性をもたせる設計を挙げている。
業務ルールも問われている。前文の例の“多対1”から“多対多”への変更のように，どの業務ルールの変化に備えたのかが分かるように書く。
採点講評は，要求事項又は設計方針だけにとどまり，具体的な設計内容が不明な論述を挙げている。
設問ウ
600字以上1,200字以内
設問イで述べた設計において，開発コストの増加を抑えるために実施した機能や項目の絞り込みについて，その絞り込みが適切であると考えた理由を，600字以上1,200字以内で具体的に述べよ。
問われていること
- 開発コストの増加を抑えるために実施した機能や項目の絞り込み
- その絞り込みが適切であると考えた理由
組み立ての注意
絞り込みは，前文の例（過去の実績，事業環境の変化，今後の計画などから変更の可能性を見極めて機能を絞り込む，業務の特性などから変更可能な項目を絞り込んでロジックを簡略化する）のように書く。何を根拠に絞り込んだかが，適切であると考えた理由になる。
採点講評は，設計内容と絞り込みとの関連が薄い論述を挙げている。絞り込みの対象は，設問イで述べた設計の中の機能や項目にする。
採点講評（IPA）
問2（柔軟性をもたせた機能の設計）では，柔軟性をもたせるための設計と，対象にした業務ルールについての具体的な論述を期待した。多くの論述は，柔軟性をもたせるための機能の設計内容を具体的に論述していた。一方で，要求事項又は設計方針だけにとどまり，具体的な設計内容が不明な論述も見受けられた。また，その設計に当たって，開発コストを抑えるために実施した機能や項目の絞り込みについての論述を期待したが，設計内容と絞り込みとの関連が薄い論述も見受けられた。システムアーキテクトには，様々な変化や要望に対して，迅速かつ低コストで対応できる情報システムを設計する能力が求められる。現在の要望だけでなく，将来の変化も意識した設計を心掛けてほしい。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施事項だけの論述にとどまり，実施した理由や検討の経緯が読み取れない論述も見受けられた。自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：平成29年度 秋期 システムアーキテクト試験 午後Ⅱ 問2（表記を一部改変）
問3 IoTの進展と組込みシステムのセキュリティ対応について
IoTの進展に伴い，ネットワークに接続される組込みシステムが増えている。ネットワークを利用して，機器のデータをアップロードする，プログラムをダウンロードして更新するといった機能の他に，ネットワークに接続された他の機器と協調して動作する，サーバと連携して動作するなど，更に高度な機能を実現することができる。
このようにIoTの進展は組込みシステムの利便性を向上させる一方で，ネットワーク経由で外部から不正に利用される懸念も増大させている。例えば，改ざんしたプログラムに書き換えられたり，なりすましによって機器を不正に利用されたりするなどの被害が想定される。最近では，自律走行車両のように，不正に利用されると物理的損害が懸念されるものもあり，それぞれの組込みシステムの特徴に応じたセキュリティリスクを特定し，適切に対応する必要がある。
セキュリティリスクへの対応策には，例えば，重要な情報を保護するためにプロセッサを物理的に分けたり，なりすましを防ぐために高度な認証方式を採用したりするなどの手段がある。しかし，その一方でこれらの対応策によって，原価の上昇，リアルタイム性の低下も発生し得る。したがって，トレードオフを考慮した適切な対応策が必要である。また，複数の機器が協調して動作する場合には，どの機器に，どのような対応策を適用するかというアーキテクチャの選択も，費用対効果の観点で重要となる。
組込みシステムのシステムアーキテクトは，組込みシステムのセキュリティリスクと不正利用防止の重要性に基づき，適切な対応策を講じなければならない。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
IoTの進展から，組込みシステムをネットワークに接続することによって，高度な機能を実現できるようになった。その一方で，ネットワークを介した不正な利用に対するセキュリティへの対応が必要となっている。
本問は，対象としている組込みシステムに特有なセキュリティリスクを明確にして，その対応策をどの箇所にどのように講じたか，アーキテクチャ，トレードオフを含めて具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要なセキュリティへの対応を考慮したシステム構築能力を評価する。
設問と問われていること
設問ア
800字以内
あなたが開発に携わった組込みシステムの概要と特徴，及び特定したセキュリティリスクについて，経緯を含め，800字以内で述べよ。
問われていること
- 開発に携わった組込みシステムの概要と特徴
- 特定したセキュリティリスク
- リスクを特定した経緯
組み立ての注意
前文は，それぞれの組込みシステムの特徴に応じたセキュリティリスクを特定するとしている。概要と特徴を書いたうえで，その特徴からどのようなリスクを特定したのかがつながるように書く。
採点講評は，リスクの特定が一般論に終始している論述を挙げている。出題趣旨も，対象としている組込みシステムに特有なセキュリティリスクを明確にすることを求めている。
設問イ
800字以上1,600字以内
設問アで述べた組込みシステムにおいて，セキュリティリスクに対し，どのような考えに基づいて対応策を検討したか。アーキテクチャ選択の観点，トレードオフの考慮を含め，800字以上1,600字以内で具体的に述べよ。
問われていること
- 対応策を検討した考え
- アーキテクチャ選択の観点
- トレードオフの考慮
組み立ての注意
対応策は，前文の例（重要な情報を保護するためにプロセッサを物理的に分ける，なりすましを防ぐために高度な認証方式を採用する）のように書き，どのような考えに基づいてそれを選んだかを示す。
アーキテクチャ選択の観点は，前文のとおり，複数の機器が協調して動作する場合にどの機器にどの対応策を適用するか。トレードオフは，前文の例（原価の上昇，リアルタイム性の低下）のように，対応策によって何を失うかと，それをどう考慮したかとして書く。
採点講評は，既存のシステムのセキュリティ対策の説明にとどまる論述や，対応策が一般論に終始している論述を挙げている。
設問ウ
600字以上1,200字以内
設問イで述べた対応策について，費用対効果からみた評価，及び今後の課題について，600字以上1,200字以内で具体的に述べよ。
問われていること
組み立ての注意
評価は「費用対効果から」と観点が指定されている。前文も，アーキテクチャの選択は費用対効果の観点で重要としている。設問イで考慮したトレードオフ（原価の上昇など）と，防ごうとしたリスクの大きさを照らして書くと，設問どうしがつながる。
今後の課題は評価と分けて書く。
採点講評（IPA）
問3（IoTの進展と組込みシステムのセキュリティ対応について）では，担当した組込みシステムに特有なセキュリティリスクを特定し，コスト・性能などとのトレードオフ及び当該組込みシステムの特徴を考慮した対応策から，システム設計の実戦的能力がうかがえる論述を期待した。全体的に適切に論述されているものが多かった。一方，既存のシステムのセキュリティ対策の説明にとどまっていたり，リスクの特定及び対応策が一般論に終始していたりする論述も見受けられた。組込みシステムのシステムアーキテクトには，IoTの進展に伴うセキュリティ対応を考慮した組込みシステムを構築する能力が求められる。組込みシステムのセキュリティリスクと不正利用防止の重要性に基づき，適切な対応策を講じられるように心掛けてほしい。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施事項だけの論述にとどまり，実施した理由や検討の経緯が読み取れない論述も見受けられた。自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：平成29年度 秋期 システムアーキテクト試験 午後Ⅱ 問3（表記を一部改変）