令和5年度 春期 システムアーキテクト試験 午後II 問2 利用者と接点がないシステムのUI検討(論述)

テクノロジインタフェース・メディアシステム開発技術開発プロセス

この問題は2023(R5)春 システムアーキテクト 午後IIに出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。

本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています(改行・記号・数式・図表参照の調整)。設問の趣旨および正解に影響する変更は加えていません。

学習ガイド

利用者と直接接点を持ちにくい情報システムのUI要件を論じる午後II問題です。対象利用者の特性、検討したUI、検討中に生じた課題と対応を具体的につなぎます。稼働後の利用状況を測定し、短い開発サイクルで改善する仕組みまで含めた論文構成を解説します。設問アからウまで同じ事例と因果関係を保ち、一般論に流れず、実施内容と評価を具体的に書き切るための構成を示します。

この記事で押さえる論点

  • 通販サイトやスマホアプリのように利用者に直接確認できないシステムを対象として選定する
  • 性別・年齢層・ITリテラシーなどから利用者像を想定し、提供機能とUIを検討する流れを構成する
  • 支援機能やメニュー階層の深さなど、UI選択で生じた課題とその対応策を具体的に論述する
  • 利用状況のモニタリングや短い開発サイクルによる運用中の改訂の仕組みを工夫として述べる

問題本文

問2 利用者と直接の接点がない情報システムのユーザーインタフェースの検討について

近年,通販サイトやスマートフォンアプリケーションのように,開発者が利用者と直接の接点を持つことが難しい情報システムの開発が増えてきている。
システムアーキテクトは,このような情報システムの開発に当たり,利用者に直接確認することが困難な状況で要件を取りまとめなければならない。
特にユーザーインタフェース(以下,UIという)は,要件の確認が困難であるため,情報システムの利用者像を想定することから始める必要がある。利用者像は,利用者の性別や年齢層,スマートフォンやPCなどの利用環境におけるITリテラシーなどから想定することが多い。その上で,利用者に提供する機能を洗い出し,適切と思われるUIを検討する。
このような検討では,適切なUIを選択する際に課題が発生することも多く,その課題に対応しなければならない。課題には,例えば次のようなものがある。

  • 想定される利用者が多岐にわたるので,利用ガイドなどの支援機能が決まらない。
  • メニューの階層を浅くする方法と,深くする方法のどちらが利用者に受け入れられるのかが分からない。

また,このような情報システムの場合,開発やデリバリーのプロセスを自動化し開発サイクルを短期化した上で情報システムを運用しながら改訂していくことを可能にしたり,画面や機能の利用状況をモニタリングする機能を用意し改善点を発見しやすくしたりするなど,UIを継続的に適切化していくための工夫をすることも重要である。
あなたの経験と考えに基づいて,設問ア~設問ウに従って論述せよ。

設問と解答・解説

設問ア

あなたが開発に携わった,開発者が利用者と直接の接点を持つことが難しい情報システムについて,開発の目的,対象の業務と情報システムの概要を,800字以内で述べよ。

模範解答

模範解答は公表されていません。下の採点基準と解説から、解答に求められる要素を読み取ってください。

採点基準(配点 34点)

知識・理解度(内容)(17点)

  • 17: 開発の目的、対象業務、システムの概要が具体的かつ妥当に記述されており、開発者が利用者と直接接点を持つことが難しいシステムであることが明確に示されている。
  • 13: 概ね具体的に記述されているが、目的、業務、システムの概要のいずれかの記述がやや薄い、または具体性に少し欠ける。
  • 9: 記述が一般論に留まっているか、設問で求められている要求事項(目的、業務、概要)の一部が欠けている。
  • 4: 自社内システム等の直接接点があるシステムを題材としているか、要求事項の大半が欠落しており、題意を満たしていない。
  • 0: 白紙、または設問と全く無関係な内容である。

論理性(構造)(17点)

  • 17: 開発の目的から対象業務、システムの概要への論理的なつながりが自然であり、後続の設問の前提として非常に分かりやすい構成となっている。
  • 13: 論理構成は概ね適切であるが、各要素間の結びつきにやや飛躍や分かりにくさが見られる。
  • 9: 論理構成に不自然な点があり、システム全体の像や業務の目的を把握するのにやや困難を伴う。
  • 4: 論理が破綻しており、どのようなシステムを開発しようとしているのか理解が極めて困難である。
  • 0: 評価不能。

解説

本問は、開発者が利用者と直接の接点を持つことが難しい情報システム(例:一般消費者向けの通販サイトやスマートフォンアプリケーションなど)の要件定義において、システムアーキテクトとしての経験を問うものです。

高得点のポイント

  • 対象システムの適切な選定: 自社内向けの業務システムなど、利用者に直接ヒアリング可能なシステムを挙げた場合は、設問の前提条件から外れるため減点対象となります。
  • 具体性と経験に基づく記述: 開発の目的、対象となる業務、情報システムの概要について、一般論ではなく、自身が実際に携わった(あるいは想定した)具体的な事例として800字以内で端的に記述することが求められます。
  • 後続設問への布石: ここで定義した「目的」や「システムの概要」が、設問イや設問ウにおける「UIの課題」や「継続的な適切化」の論述の土台となるため、一貫性を持たせることが極めて重要です。

設問イ

設問アで述べた情報システムにおけるUIについて,利用者像をどのように想定し,どのようなUIを検討したか。検討で発生した適切なUIを選択する際の課題とその対応策を交え,800字以上1,600字以内で具体的に述べよ。

模範解答

模範解答は公表されていません。下の採点基準と解説から、解答に求められる要素を読み取ってください。

採点基準(配点 33点)

知識・理解度(内容)(17点)

  • 17: 想定した利用者像、検討したUI、適切なUI選択時の課題と対応策がすべて具体的に網羅され、直接接点が持ちにくいシステム特有の課題として非常に妥当である。
  • 13: 要求事項は概ね網羅されているが、利用者像や検討したUIの詳細、または課題・対応策のいずれかにおいて具体性がやや不足している。
  • 9: 課題や対応策の記述が一般論に終始しており実体験としての具体性に欠けるか、あるいは要求事項のいずれかに漏れがある。
  • 4: 挙げられた課題や対応策が設問の前提(直接接点が持ちにくいシステム)に合致していない、または要求事項の大半が欠落している。
  • 0: 白紙、または設問と全く無関係な内容である。

説得力(考察)(16点)

  • 16: システムアーキテクトとしての自らの経験や深い洞察に基づき、UI選択の課題に対する対応策が極めて実践的かつ説得力をもって論じられている。
  • 12: 課題に対する対応策の考察は概ね妥当であるが、経験に基づく実践的な工夫という点でやや説得力に欠ける部分がある。
  • 8: 対応策が表層的または一般的であり、実務的な説得力が不十分である。
  • 4: 提案された対応策が非現実的であるか、課題との論理的な繋がりがなく説得力が全くない。
  • 0: 評価不能。

解説

設問アで定義したシステムを前提に、具体的な利用者像検討したUI、そして適切なUIを選択する際の課題と対応策について論述します。

高得点のポイント

  • 明確な利用者像の設定: 直接接点が持ちにくいからこそ、どのような属性やリテラシーを持つ利用者をターゲットとしたのか(ペルソナの設定など)を具体的に記述する必要があります。
  • 特有の課題の抽出: 直接ヒアリングができない状況下において、「どのUIが最適か」を判断する際に生じたシステム特有の困難や迷いを明確に記述します。
  • 実践的な対応策の提示: 抽出した課題に対して、A/Bテストの実施プロトタイプを用いた限定的なユーザーテストアクセス解析やヒートマップツールの導入など、システムアーキテクトとしての経験に基づく具体的な対応策を論じていることが高評価につながります。一般論に終始しないよう注意が必要です。

設問ウ

設問アで述べた情報システムでUIを継続的に適切化していくための工夫について,600字以上1,200字以内で具体的に述べよ。

模範解答

模範解答は公表されていません。下の採点基準と解説から、解答に求められる要素を読み取ってください。

採点基準(配点 33点)

知識・理解度(内容)(17点)

  • 17: UIを継続的に適切化していくための工夫(データの収集・分析手法、フィードバックの反映の仕組みなど)が具体的に網羅され、設問の要件を完全に満たしている。
  • 13: 継続的に適切化していくための工夫について記述されているが、具体的な実践方法や仕組みの詳細がやや不足している。
  • 9: 工夫の内容が一般論に終始しており、当該システム特有の具体的な実践方法への言及が乏しい。
  • 4: 「継続的な適切化」というテーマから逸脱している、あるいは内容が極めて薄く具体性が全くない。
  • 0: 白紙、または設問と全く無関係な内容である。

説得力(考察)(16点)

  • 16: システムアーキテクトとしての経験に基づき、リリース後の継続的な改善プロセスが組織やシステムの特性を踏まえて構築されており、非常に高い説得力を持つ。
  • 12: 継続的改善のプロセスは妥当であるが、独自の工夫や深い洞察という観点でやや説得力が不足している。
  • 8: 考察が浅く、教科書的な説明に留まっており実務担当者としての説得力に欠ける。
  • 4: 提案された工夫に実現性が乏しいか、論理が破綻しており説得力がない。
  • 0: 評価不能。

解説

情報システムのリリース・稼働後において、UIを継続的に適切化していくための工夫について論述します。

高得点のポイント

  • 継続的な改善プロセスの具体化: 単発の対応ではなく、稼働後の利用状況データ(ログ、コンバージョン率、離脱率など)の収集・分析手法や、利用者からのフィードバック収集の仕組みを具体的に記述することが求められます。
  • 適切化のための実践的工夫: 収集したデータをどのように評価し、次のUI改善(アジャイル的な開発サイクルへの組み込みや要件見直し)にどう繋げるかという、仕組みづくりや体制整備を含む実践的な工夫を記述すると説得力が増します。
  • 一般論からの脱却: 「使いやすくするために意見を聞く」といった抽象的な内容ではなく、設問ア・イで挙げた対象システムや想定利用者像と整合性のある、現場視点の具体的な施策を論じることが重要です。