令和元年度 秋期に実施されたシステムアーキテクト試験
午後Ⅱの全3問（論述式）です。問題文・設問と，問われていることの整理をそのまま読めます。
問1 ユーザビリティを重視したユーザインタフェースの設計について
近年，情報システムとの接点としてスマートフォンやタブレットなど多様なデバイスが使われてきており，様々な特性の利用者が情報システムを利用するようになった。それに伴い，ユーザビリティの善しあしが企業の競争優位を左右する要素として注目されている。ユーザビリティとは，特定の目的を達成するために特定の利用者が特定の利用状況下で情報システムの機能を用いる際の，有効性，効率，及び満足度の度合いのことである。
優れたユーザビリティを実現するためには，利用者がストレスを感じないユーザインタフェース（以下，UIという）を設計することが重要である。例えば，次のように，利用者の特性及び利用シーンを想定して，重視するユーザビリティを明確にした上で設計することが望ましい。
- 操作に慣れていない利用者のために，操作の全体の流れが分かるようにナビゲーション機能を用意することで，有効性を高める。
- 操作に精通した利用者のために，利用頻度の高い機能にショートカットを用意することで，効率を高める。
また，ユーザビリティを高めるために，UIを設計する際には，想定した利用者に近い特性を持った協力者に操作を体感してもらい，仮説検証を繰り返しながら改良する，といった設計プロセスの工夫も必要である。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
近年，ユーザビリティの善しあしが，企業競争優位の獲得手段として注目されている。システムアーキテクトには，情報システムが提供する機能，その機能の利用シーン及び想定した利用者の特性を考慮して，ユーザビリティを高めるようユーザインタフェース（以下，UIという）を設計することが求められる。
本問は，どのような利用者がどのようにUIを利用するかを想定して，ユーザビリティを高めるためのUI設計をしたか，また，その際にどのような工夫をすることでUIの仕様を確定したかを具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要なユーザビリティを重視した情報システムの設計能力と経験を評価する。
設問と問われていること
設問ア
800字以内
あなたがUIの設計に携わった情報システムについて，対象業務と提供する機能の概要，想定した利用者の特性及び利用シーンを，800字以内で述べよ。
問われていること
- 対象業務と提供する機能の概要
- 想定した利用者の特性
- 想定した利用シーン
組み立ての注意
利用者の特性と利用シーンは，設問イで重視するユーザビリティを導く出発点になる。前文の例の「操作に慣れていない利用者」「操作に精通した利用者」のように，UIの設計に効いてくる特性として書く。
採点講評は，利用者の特性や利用シーンが不明瞭な論述を挙げている。
設問イ
800字以上1,600字以内
設問アで述べた利用者の特性及び利用シーンから，どのようなユーザビリティを重視して，どのようなUIを設計したか。800字以上1,600字以内で具体的に述べよ。
問われていること
組み立ての注意
前文はユーザビリティを有効性，効率，満足度の度合いと定義し，操作に慣れていない利用者にはナビゲーション機能で有効性を，操作に精通した利用者にはショートカットで効率を高める例を挙げている。利用者の特性 → 重視したユーザビリティ → UI の順につながるように書く。
採点講評は，ユーザビリティとの関係が薄い論述や，ユーザビリティではなく機能の説明に終始している論述を挙げ，利用者の立場に立って検討し提案するよう求めている。
設問ウ
600字以上1,200字以内
設問イで述べたUIの設計において，ユーザビリティを高めるために，設計プロセスにおいて，どのような工夫をしたか。600字以上1,200字以内で具体的に述べよ。
問われていること
組み立ての注意
問われているのはUIそのものではなく，UIを設計する進め方（設計プロセス）の工夫である。前文は，想定した利用者に近い特性を持った協力者に操作を体感してもらい，仮説検証を繰り返しながら改良することを例に挙げている。出題趣旨も，どのような工夫をすることでUIの仕様を確定したかを問うとしている。
採点講評（IPA）
問1（ユーザビリティを重視したユーザインタフェースの設計について）ユーザビリティを高めるためのユーザインタフェース設計を具体的に論述することを期待した。ユーザインタフェース設計について具体的に論述しているものが多く，受験者がユーザインタフェース設計の経験を有していることがうかがわれた。一方で，利用者の特性や利用シーンが不明瞭，又はユーザビリティとの関係が薄い論述，ユーザビリティではなく機能の説明に終始しているものなども散見された。システムアーキテクトはユーザインタフェース設計において，要求にそのまま答えるだけでなく，利用者の立場に立って検討し提案することを心掛けてほしい。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施した事項をただ論述しただけにとどまり，実施した理由や検討の経緯が読み取れない論述も見受けられた。受験者自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：令和元年度 秋期 システムアーキテクト試験 午後Ⅱ 問1（表記を一部改変）
問2 システム適格性確認テストの計画について
情報システムの開発では，定義された機能要件及び非機能要件を満たしているか，実際の業務として運用が可能であるかを確認する，システム適格性確認テスト（以下，システムテストという）が重要である。システムアーキテクトは，システムテストの適切な計画を立案しなければならない。
システムテストの計画を立案する際，テストを効率的に実施するために，例えば次のような区分けや配慮を行う。
- テストを，販売・生産管理・会計などの業務システム単位，商品・サービスなどの事業の範囲，日次・月次などの業務サイクルで区分けする。
- 他の関連プロジェクトと同期をとるなどの制約について配慮する。
- 処理負荷に応じた性能が出ているかなどの非機能要件を確認するタイミングについて配慮する。
さらに，テスト結果を効率的に確認する方法についても検討しておくことが重要である。例えば，次のような確認方法が考えられる。
- 結果を検証するためのツールを開発し，テスト結果が要件どおりであることを確認する。
- 本番のデータを投入して，出力帳票を本番のものと比較する。
- ピーク時の負荷を擬似的にテスト環境で実現して，処理能力の妥当性を確認する。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
情報システムの開発では，定義された機能要件及び非機能要件を満たしているか，実際の業務として運用が可能であるかを確認する，システム適格性確認テスト（以下，システムテストという）が重要である。システムアーキテクトは，システムテストの適切な計画を立案しなければならない。
本問は，システムテストの計画について，テストを効率的に実施するための区分けや配慮とテスト結果を効率的に確認する方法を具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要なシステムテストの計画立案能力とその経験を評価する。
設問と問われていること
設問ア
800字以内
あなたがシステムテストの計画に携わった情報システムについて，対象業務と情報システムの概要を800字以内で述べよ。
問われていること
組み立ての注意
設問イの区分けは，前文の例（業務システム単位，事業の範囲，業務サイクル）のように業務の観点で行うものである。概要では，業務システムの構成，扱う商品・サービス，日次・月次などの業務サイクルといった，後で区分けの根拠になることが分かるように書いておく。
設問イ
800字以上1,600字以内
設問アで述べた情報システムのシステムテストの計画で，テストを効率的に実施するために，どのような区分けや配慮を行ったか。そのような区分けや配慮を行うことで，テストが効率的に実施できると考えた理由とともに，800字以上1,600字以内で具体的に述べよ。
問われていること
- テストを効率的に実施するために行った区分けや配慮
- テストが効率的に実施できると考えた理由
組み立ての注意
前文は，区分けの例として業務システム単位，事業の範囲，業務サイクル，配慮の例として他の関連プロジェクトとの同期などの制約と，非機能要件を確認するタイミングを挙げている。
採点講評は，業務の視点からテストを区分けし，実行に際して様々な配慮をすることを想定したとしている。一方で，単体テストや結合テストなどシステム適格性確認テストとは異なるテストの計画や，システム適格性確認テストの一部の実施だけを論述したものを挙げている。対象は，機能要件・非機能要件を満たし業務として運用が可能かを確認するテストの計画である。
設問ウ
600字以上1,200字以内
設問アで述べた情報システムのシステムテストの計画で，テスト結果を効率的に確認するために，どのような確認方法を検討し採用したか。採用した理由とともに，600字以上1,200字以内で具体的に述べよ。
問われていること
- テスト結果を効率的に確認するために検討し採用した確認方法
- 採用した理由
組み立ての注意
設問イはテストの実施の効率，設問ウはテスト結果の確認の効率を問うており，対象が異なる。前文は確認方法の例として，結果を検証するツールの開発，本番のデータを投入した出力帳票の比較，ピーク時の負荷の擬似的な再現を挙げている。
「検討し採用した」とあるので，どの方法を採用し，なぜそれにしたのかを，対象の業務や情報システムの特徴と結び付けて書く。
採点講評（IPA）
問2（システム適格性確認テストの計画について）立案したシステム適格性確認テストの計画を，業務の視点を交えて具体的に論述することを期待した。テストを効率的に実施するために，業務の視点からテストを区分けしたり，実行に際しての様々な配慮をしたりすることが想定される。多くの受験者が，商品・サービス・利用者・業務サイクルなどの業務の観点での区分けと，その理由について具体的に論述していた。一方で，一部の受験者は，単体テストや結合テストなどのシステム適格性確認テストとは異なるテストの計画や，システム適格性確認テストの一部の実施だけを論述しており，システム適格性確認テストの理解と経験が不足していることがうかがわれた。システム適格性確認テストは，業務運用が可能かどうかを確認する重要なものである。システムアーキテクトは，情報システムと対象の業務の双方について正しく理解し，適切なテスト計画の立案を心掛けてほしい。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施した事項をただ論述しただけにとどまり，実施した理由や検討の経緯が読み取れない論述も見受けられた。受験者自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：令和元年度 秋期 システムアーキテクト試験 午後Ⅱ 問2（表記を一部改変）
問3 組込みシステムのデバッグモニタ機能について
組込みシステムの機能の拡大・複雑化に対応して，開発中のデバッグ及び出荷後のメンテナンスのためのデバッグモニタ機能を設けることが増えている。
多くの組込みシステムは汎用の入出力装置を装備していないことから，不具合の解析及び故障診断のための操作と結果の出力において，それぞれのシステムに応じた工夫が必要となる。また，開発・検証・出荷後の各段階において，各利用者が必要とする機能と利用可能な装置が変わることがある。例えば，開発段階では開発支援ツールを用いて詳細な検証・確認を行えるが，検証段階では実際の環境下でリアルタイム性を確保するために，実機を利用することが多い。さらに，出荷後の製品では，通常使わない組合せでボタンを押してデバッグモニタ機能を起動するなど，システムに装備された入出力装置だけで機能を実現しなければならない場合もある。
組込みシステムの特徴によって，そのシステムに特有な工夫・配慮が必要となることがある。例えば，IoT機器では，ネットワーク経由の操作によってリモート診断を実施できるが，通信障害が発生した場合の対処を考慮しなければならない。AI利用など，大量のデータを処理する装置はメモリの制限などから，診断に用いるデータの一部を保持しておくといった工夫も必要となる。さらに，デバッグモニタ機能の不正利用の可能性を考慮し，セキュリティ上のリスクにも配慮する必要がある。
組込みシステムのシステムアーキテクトは，開発・検証・出荷後の各段階において，利用可能なリソース及び操作・診断に要求される機能を把握し，セキュリティなどを考慮した上で，デバッグモニタ機能の要件を定義しなければならない。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
組込みシステムは，PCなどとは異なり，キーボード・ディスプレイのような汎用の入出力装置を装備していないことが多く，また，デバッグ時及びメンテナンス時で必要とされる機能がそれぞれ異なるので，デバッグモニタ機能の装備には，それぞれのシステムに応じた工夫が必要となる。
本問は，対象とする組込みシステム特有の入出力の制約の下で，開発・検証・出荷後の各段階において必要とされるデバッグモニタ機能をセキュリティなどへの配慮を含めて実現した経緯，検討過程及び結果の評価を具体的に論述することを求めている。論述を通じて，組込みシステムのシステムアーキテクトに必要とされるシステム構築能力を評価する。
設問と問われていること
設問ア
800字以内
あなたが開発に携わった組込みシステムの概要と，そのシステムにおいてデバッグモニタ機能が必要となった経緯を，800字以内で述べよ。
問われていること
- 開発に携わった組込みシステムの概要
- デバッグモニタ機能が必要となった経緯
組み立ての注意
前文は，多くの組込みシステムが汎用の入出力装置を装備していないことを挙げている。概要では，そのシステムが備える入出力装置や，メモリなどのリソースの制約が分かるように書いておくと，設問イの工夫・配慮につながる。
経緯は，前文の「機能の拡大・複雑化」のように，なぜそのシステムでデバッグモニタ機能を設ける必要があったのかとして書く。
設問イ
800字以上1,600字以内
設問アで述べた組込みシステムにおいて，各利用者との協議などに基づき，開発・検証・出荷後の各段階を想定してどのようなデバッグモニタ機能を設けたか。工夫・配慮事項を含め，800字以上1,600字以内で具体的に述べよ。
問われていること
- 各段階を想定して設けたデバッグモニタ機能
- 各利用者との協議などに基づいたこと
- 工夫・配慮事項
組み立ての注意
前文は，開発段階では開発支援ツール，検証段階では実機，出荷後はシステムに装備された入出力装置だけ，というように段階ごとに利用者が必要とする機能と利用可能な装置が変わることを示している。開発・検証・出荷後のそれぞれについて，誰が何を必要としたかを書く。
工夫・配慮は，前文の例（IoT機器の通信障害への対処，メモリの制限からのデータの一部保持，不正利用に対するセキュリティ上のリスクへの配慮）のように，そのシステムの特徴に由来するものにする。採点講評は，組込みシステムの特徴に乏しく一般的な課題・解決策にとどまる論述や，実装結果を説明しただけの論述を挙げている。
設問ウ
600字以上1,200字以内
設問イで述べたデバッグモニタ機能において，各段階における利用者のニーズを含めた評価と，今後の課題を，600字以上1,200字以内で具体的に述べよ。
問われていること
- 各段階における利用者のニーズを含めた評価
- 今後の課題
組み立ての注意
評価は，設問イで各段階について述べた利用者の要求に照らし，それぞれの段階でニーズを満たせたかとして書く。
採点講評（IPA）
問3（組込みシステムのデバッグモニタ機能について）開発・検証・出荷後の各段階で，各利用者から要求されるデバッグモニタ機能について，組込みシステムの特有の制約，セキュリティなどを考慮した上での具体的な論述を期待した。多くの論述は各段階での要求と対応内容に具体性があり，実際の経験に基づいて論述していることがうかがわれた。一方で，組込みシステムの特徴に乏しく，一般的な課題・解決策にとどまる論述，実装結果を説明しただけという論述も見受けられた。組込みシステムのシステムアーキテクトは，対象となる組込みシステムの特徴を理解して，適切なシステム設計ができるよう能力を高めてほしい。
全問共通
全問に共通して，自らの体験に基づき設問に素直に答えている論述が多く，問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述は少なかった。一方で，実施した事項をただ論述しただけにとどまり，実施した理由や検討の経緯が読み取れない論述も見受けられた。受験者自らが実際にシステムアーキテクトとして，検討し取り組んだことを具体的に論述してほしい。
出典：令和元年度 秋期 システムアーキテクト試験 午後Ⅱ 問3（表記を一部改変）