平成28年度 秋期に実施されたシステムアーキテクト試験
午後Ⅱの全3問（論述式）です。問題文・設問と，問われていることの整理をそのまま読めます。
問1 業務要件の優先順位付けについて
情報システムの開発における要件定義において，システムアーキテクトは利用者などとともに，提示された業務要件を精査する。その際，提示された業務要件の全てをシステム化すると，コストが増大したり，開発期間が延びたりするおそれがある。そのため，システムアーキテクトは，業務要件のシステム化によって得られる効果と必要なコストや開発期間などから，例えば次のような手順で，提示された業務要件に優先順位を付ける。
- 1. 業務の特性や情報システムの開発の目的などを踏まえて，組織の整備や教育訓練などの準備の負荷，業務コスト削減の効果及び業務スピードアップの度合いといった業務面での評価項目を設定する。また，適用する技術の検証の必要性，影響する他の情報システムの修正を含む開発コスト及び開発期間といったシステム面での評価項目を設定する。
- 2. 業務の特性や情報システムの開発の目的などを踏まえて，評価項目ごとに重み付けをする。
- 3. 業務面，システム面でのそれぞれの評価項目について，業務要件ごとに定量的に評価する。このとき，定性的な評価項目についても，定量化した上で評価する。
- 4. 評価項目ごとに付与された重みを加味して総合的に評価し，実現すべき業務要件の優先順位を付ける。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
情報システムの開発における要件定義において，システムアーキテクトは利用者などとともに，提示された業務要件を精査する。その際，業務要件のシステム化によって得られる効果とコストや開発期間などを総合的に評価し，業務要件の優先順位を付ける。
本問では，業務要件の優先順位付けをするための手順と評価の方法について，具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要な，業務要件を分析して評価する能力と経験を評価する。
設問と問われていること
設問ア
800字以内
あなたが要件定義に携わった情報システムについて，その概要を，情報システムの開発の目的，対象の業務の概要を含めて，800字以内で述べよ。
問われていること
- 要件定義に携わった情報システムの概要
- 情報システムの開発の目的
- 対象の業務の概要
組み立ての注意
開発の目的は，設問イの評価項目の設定と重み付けの前提になる。前文の手順1・2も，業務の特性や情報システムの開発の目的などを踏まえて評価項目を設定し，重み付けをするとしている。
採点講評は，情報システムの開発の目的と評価項目・重み付けの間の関連が分からない論述が多かったとしている。ここで書く目的と，設問イの評価項目・重み付けがつながるようにする。
設問イ
800字以上1,600字以内
設問アで述べた情報システムの要件定義で，業務要件をどのような手順で評価したか。その際，どのような評価項目を設定し，どのような考えで重み付けをしたか。800字以上1,600字以内で具体的に述べよ。
問われていること
- 業務要件を評価した手順
- 設定した評価項目
- 重み付けの考え
組み立ての注意
手順は，前文の例（評価項目の設定，評価項目ごとの重み付け，業務要件ごとの定量的な評価，重みを加味した総合評価）のように，段階を追って書く。
評価項目は，前文の例のように業務面（準備の負荷，業務コスト削減の効果，業務スピードアップの度合い）とシステム面（技術の検証の必要性，他の情報システムの修正を含む開発コスト，開発期間）の両方から挙げる。採点講評は，業務要件ではなくシステム要件を評価している論述を挙げ，業務要件と情報システムの両面から分析することを求めている。
重み付けは「どのような考えで」が問われている。設問アの開発の目的からなぜその重みにしたのかを書く。採点講評の全問共通の指摘のとおり，問題文の手順や観点は例示であり，抜き出して一般論と組み合わせるだけにしない。
設問ウ
600字以上1,200字以内
設問イで述べた評価手順に沿って，どのような業務要件をどのように評価したか。また，その結果それらの業務要件にどのような優先順位を付けたか。幾つかの業務要件について，600字以上1,200字以内で具体的に述べよ。
問われていること
- 評価した業務要件と評価の仕方
- 業務要件に付けた優先順位
- 幾つかの業務要件を取り上げる
組み立ての注意
設問イで述べた手順と評価項目・重み付けを，実際の業務要件に当てはめた結果として書く。「幾つかの業務要件について」とあるので，複数の業務要件を取り上げ，それぞれの評価と付けた優先順位を示す。
前文の手順3は，定性的な評価項目も定量化した上で評価するとしている。
採点講評（IPA）
問1（業務要件の優先順位付けについて）では，どのような評価のプロセスと評価項目で業務要件の優先度を評価したか，また情報システム開発の目的に沿った重み付けをしたか，を具体的に論述することを期待した。評価のプロセスと評価項目については，多くの受験者が論述できていた。一方で，情報システムの開発の目的と評価項目・重み付けの間の関連が分からない論述や，業務要件ではなくシステム要件を評価している論述も多かった。システムアーキテクトには，情報システムの開発目的を理解した上で，業務要件と情報システムの両面から分析することが求められる。情報システムだけでなく，業務要件と情報システムの両面からの分析能力を高めてほしい。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多かった。一方で，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述も引き続き見られた。問題文に記載したプロセスや観点は例示である。自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：平成28年度 秋期 システムアーキテクト試験 午後Ⅱ 問1（表記を一部改変）
問2 情報システムの移行方法について
情報システムの機能強化のために，新たに開発した情報システム（以下，新システムという）を稼働させる場合，現在稼働している情報システム（以下，現システムという）から新システムへの移行作業が必要になる。
システムアーキテクトは，移行方法の検討において，対象業務の特性による制約条件を踏まえ，例えば，次のような情報システムの移行方法を選択する。
- 多数の利用部門があり，教育に時間が掛かるので，利用部門ごとに新システムに切り替える。
- 移行当日までに発生したデータを当日中に全て処理しなければ，データの整合性を維持できないので，全部門で現システムから新システムに一斉に切り替える。
- 障害が発生すると社会的な影響が大きいので，現システムと新システムを並行稼働させる期間を設けた上で，障害のリスクを最小限にして移行する。
また，移行作業後の業務に支障が出ないようにするために，例えば，次のような工夫をすることも重要である。
- 移行作業が正確に完了したことを確認するために，現システムのデータと新システムのデータを比較する仕組みを準備しておく。
- 移行作業中に遅延や障害が発生した場合に移行作業を継続するかどうかを判断できるように，切戻しのリハーサルを実施し，所要時間を計測しておく。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
情報システムの機能強化のために，新たに開発した情報システムを稼働させる場合，移行作業が必要になる。システムアーキテクトは，対象業務の特性による制約条件から，情報システムの移行方法を検討する。
本問では，対象業務の特性による制約条件を踏まえて選択した移行方法と，移行作業後の業務に支障が出ないようにするための工夫について，具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要な，情報システムの移行に関わる設計能力と経験を評価する。
設問と問われていること
設問ア
800字以内
あなたが移行に携わった情報システムについて，対象業務の概要，現システムの概要，及び現システムから新システムへの変更の概要について，800字以内で述べよ。
問われていること
- 対象業務の概要
- 現システムの概要
- 現システムから新システムへの変更の概要
組み立ての注意
設問イで対象業務の特性による制約条件を述べるので，対象業務の概要は，その特性が分かるように書いておく。
現システムの概要と，新システムへの変更の概要は分けて書く。
設問イ
800字以上1,600字以内
設問アで述べた情報システムにおいて，対象業務の特性によるどのような制約条件を踏まえ，どのような移行方法を選択したか。選択した理由とともに，800字以上1,600字以内で具体的に述べよ。
問われていること
- 対象業務の特性による制約条件
- 選択した移行方法
- その移行方法を選択した理由
組み立ての注意
前文の例は，いずれも「業務の特性（多数の利用部門があり教育に時間が掛かる，当日中に全て処理しなければデータの整合性を維持できない，障害が発生すると社会的な影響が大きい）→ 移行方法（利用部門ごとの切替え，一斉切替え，並行稼働）」の形になっている。制約条件と移行方法のつながりが分かるように書く。
採点講評は，業務特性の記述がなくシステム上の制約条件を考慮しただけの論述や，対象業務の特性ではなく情報システムの開発プロジェクトの制約を業務特性としていた論述を挙げている。制約条件は，その業務の性質から来るものにする。
設問ウ
600字以上1,200字以内
設問イで述べた情報システムの移行において，移行作業後の業務に支障が出ないようにするために，どのような工夫をしたか。想定した支障の内容とともに，600字以上1,200字以内で具体的に述べよ。
問われていること
- 移行作業後の業務に支障が出ないようにするための工夫
- 想定した支障の内容
組み立ての注意
工夫は，前文の例（現システムと新システムのデータを比較する仕組みの準備，切戻しのリハーサルと所要時間の計測）のように書く。
想定した支障の内容も問われている。どのような支障を想定して，その工夫をしたのかが分かるようにする。支障は「移行作業後の業務」に出るものなので，採点講評が求めるとおり，情報システムが業務でどのように使われているのかを意識して書く。
採点講評（IPA）
問2（情報システムの移行方法について）では，対象業務の特性による制約条件を踏まえ，どのような移行方法を選択したか，移行作業後の業務に支障が出ないようにするためにどのような工夫をしたか，を具体的に論述することを期待した。多くの受験者が業務特性を明確に論述していた。一方で，業務特性の記述がなくシステム上の制約条件を考慮しただけの論述や，対象業務の特性ではなく情報システムの開発プロジェクトの制約を業務特性としていた論述も見られた。システムアーキテクトには，情報システムが業務でどのように使われているのかを正しく理解することが求められる。情報システムの設計，開発に当たっては常に業務を意識してほしい。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多かった。一方で，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述も引き続き見られた。問題文に記載したプロセスや観点は例示である。自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：平成28年度 秋期 システムアーキテクト試験 午後Ⅱ 問2（表記を一部改変）
問3 組込みシステムにおけるオープンソースソフトウェアの導入について
組込みシステムに要求される機能は，年々専門化，高度化しているが，その一方で開発期間は短縮化が求められている。これを解決する方法として，社内で保有していない技術及び標準的な機能は，外部からOS，ライブラリ及びプラットフォームを導入して実現することがある。外部技術の導入に際し，例えばLinuxなど，ソースコードが公開されているオープンソースソフトウェア（以下，OSSという）を利用することがある。また，プラットフォームの採用に際し，顧客からAndroidなどのOSSを使うように要求されることもある。
OSSの多くは無償で利用できる。また，多数の人が利用し開発した成果が更にOSSとして公開されていたり，標準的な装置のデバイスドライバが提供されていたり，インタフェースがデファクトスタンダードになっていたりして，開発者の利便性が高い。
しかし，OSSは市販品とは異なり，一般的には保証やサポートがない。また，OSSの使用許諾条件には，自社開発部分の外部への開示を要求されるものがあるなど，利用においての注意点がある。組込みシステムでは，性能要件達成，独自ハードウェア制御などのために，OSS部分に手を加えたり自社開発ソフトウェアと組み合わせて使ったりすることがあるので，関係部署を交えた協議を要することがある。
このように組込みシステムのシステムアーキテクトは，OSS導入に際して，自社開発ソフトウェアとOSSとをどのように組み合わせるかについて，利点，注意点などを考慮してシステム構築を検討する必要がある。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
近年，オープンソースソフトウェア（以下，OSSという）を利用した組込みシステムが増えている。
本問では，組込みシステムへのOSS導入の利点，注意点などを踏まえ，OSS導入に際しての関係部署との協議内容，OSSの適用方法についての考慮事項，及び開発時に下した判断の妥当性について具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要な，設計能力と統合力を評価する。
設問と問われていること
設問ア
800字以内
あなたが携わった組込みシステムの概要と，OSS導入の是非を検討するに至った経緯を，OSS導入の目的を含めて800字以内で述べよ。
問われていること
- 携わった組込みシステムの概要
- OSS導入の是非を検討するに至った経緯
- OSS導入の目的
組み立ての注意
経緯は，前文の例（機能の専門化・高度化と開発期間の短縮化の両立，顧客からAndroidなどのOSSを使うように要求された）のように，なぜOSSの導入を考えることになったかとして書く。
導入の目的は，設問ウで目的の達成度を踏まえて判断の妥当性を述べる基準になる。
設問イ
800字以上1,600字以内
設問アで述べた組込みシステムの構築において，OSS導入の是非を検討した際に，関係部署とどのような協議を行い，OSS及び市販品と自社開発ソフトウェアとの組合せに関してどのような考慮をしたか，800字以上1,600字以内で具体的に述べよ。
問われていること
- 関係部署と行った協議
- OSS及び市販品と自社開発ソフトウェアとの組合せに関する考慮
組み立ての注意
協議の中身は，前文が挙げるOSSの利点（無償で利用できる，公開された成果やデバイスドライバがある，インタフェースがデファクトスタンダード）と注意点（保証やサポートがない，使用許諾条件で自社開発部分の開示を要求されるものがある）を材料にする。
組合せの考慮は，前文のとおり，性能要件達成や独自ハードウェア制御のためにOSS部分に手を加えたり自社開発ソフトウェアと組み合わせたりする場面を念頭に，どの部分をOSS・市販品・自社開発にしたかとして書く。採点講評は，非採用の決定を含めた組合せの考慮を期待したとしている。
採点講評は，システムの一部の構成要素の記述だけであったり，既存のシステムの説明となっていたりして，OSSの検討への関与がうかがえない論述を挙げている。
設問ウ
600字以上1,200字以内
設問アで述べた組込みシステムについて，OSS導入に際し，開発段階で発生した課題，目的の達成度を踏まえて開発時に下した導入の是非に対する判断の妥当性，及び今後の対応について，600字以上1,200字以内で具体的に述べよ。
問われていること
- 開発段階で発生した課題
- 目的の達成度を踏まえた導入の是非に対する判断の妥当性
- 今後の対応
組み立ての注意
問われているのは3つ（開発段階で発生した課題，判断の妥当性，今後の対応）。判断の妥当性は，設問アで述べたOSS導入の目的の達成度を踏まえて書く。
判断は「導入の是非」に対するものなので，導入しないと決めた場合もその判断の妥当性として書ける。採点講評も非採用の決定を含めた論述を期待したとしている。
採点講評（IPA）
問3（組込みシステムにおけるオープンソースソフトウェアの導入について）では，システムへの外部技術の導入において，オープンソースソフトウェアのもつ利点と注意点を関連部署と検討し，非採用の決定を含め自社開発ソフトウェアとの組合せを考慮したシステム設計の実践経験をうかがわせる論文を期待した。全体的に適切に論述されているものが多かった。一方，システムの一部の構成要素の記述だけであったり，既存のシステムの説明となっていたりして，オープンソースソフトウェアの検討への関与がうかがえない論述も散見された。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多かった。一方で，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述も引き続き見られた。問題文に記載したプロセスや観点は例示である。自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：平成28年度 秋期 システムアーキテクト試験 午後Ⅱ 問3（表記を一部改変）