練習：システムアーキテクト試験 PM2（令和元年 問一）

設問ア あなたが UI の設計に携わった情報システムについて，対象業務と提供する機能の概要，想定した利用者の特性及び利用シーンを800字以内で述べよ。

（787文字）

第１章　対象業務、機能、利用者の特性及び利用シーン
１−１　システムの概要
　対象業務としては、社員の育成・評価・業務状況の管理を行うマネジメント業務である。
マネージャーは部下の業務報告や1on1を通して業務成果や資格取得等の目標策定、評価を行う。
部下は目標を基に業務に従事し、必要に応じて達成状況の棚卸しを行う。
業務、個人目標の成果は、成果、課題解力、コミュニケーション能力の3つの指標（以下、評価指標という）で評価し、結果を基にマネージャーから部下へフィードバックすることで、部下の育成を図る。
また、業務の報告や稼働時間から業務状況を把握し、業務トラブルや部下の不調に対して、早期に対処できる体制の構築をしている。

　システムが提供する機能としては、業務成果や資格取得等の目標策定機能（以下、目標策定機能という）、業務報告や1on1に向けて目標に対する実績を参照・更新する機能（以下、実績更新・参照機能という）、目標や実績を基に評価指標を用いて評価を行う機能（以下、評価機能という）、勤怠管理システムから連携された情報を基に、超過勤務勤務時間や有給消化割合を表示する機能（以下、稼働表示機能という）が挙げられる。

１−２　想定した利用者の特性及び利用シーン
　利用者は、複数の部下をマネジメントするマネージャーと、自分の目標や実績を管理する部下である。
　マネージャーは、複数の部下の状況を把握する必要がある。日常の状況確認では、各部下の目標の実績や超過勤務勤務時間をまとめて確認し、支援が必要な部下を把握する。また、1on1や評価の前には、対象の部下の業務情報や過去の面談記録を詳しく確認する。
　部下は、自分の目標に対する成果や課題を具体的に把握する必要がある。このため、日々の業務終了後、業務報告時や1on1の前に自分の目標と実績の詳細を確認し、報告するべき成果や課題を整理する。

設問イ 設問アで述べた利用者の特性及び利用シーンから、どのようなユーザビリティを重視して，どのようなUIを設計したか。800字以上1,600字以内で具体的に述べよ。

（1,372文字）

第２章　重視したユーザービリティと設計したUI
２−１　利用者の特性及び利用シーンから重視したユーザービリティ
　マネージャーは、複数の部下の状況を把握する必要があるという利用者の特性を挙げることができる。また、マネージャーはプレイヤーとして業務を推進しており、限られた稼働で部下の状況を把握する必要があった。
部下についても、業務に従事しながら目標や実績を整理するため、効率的に利用できる必要があった。
　その様な利用者特性と利用シーンから、重視したユーザービリティは”効率”としてUIを設計する方針とした。

２−２　設計したUI
　マネージャーと部下の利用シーンが異なるという対象業務の特徴を踏まえ、マネージャー向けUIと部下向けUIをそれぞれ個別に設計することにした。なぜならば、それぞれの利用者が求める情報の粒度や、使用する機能が異なるため、共通のUIでは両者に最大限の効率性を提供できないと考えたからである。マネージャーの日常的な状況確認では、各部下の成果実績や稼働確認を行うことが多く、部下ごとの実績確認、目標策定や評価は四半期に一度の実施であるため、実績参照・更新機能の参照および、稼働表示機能に重点を置いてUIを設計した。また、部下については、自分の目標に対する成果や課題を具体的に把握することが求められるため、実績更新・参照機能に重点を置いてUIを設計した。

　マネージャー向けUIでは、部下ごとに個別のページを設けてしまうと、視認性が悪く部下の状況を効率的に把握できないということが課題となった。そこで私は、マネージャーの業務を基に部下の名前・実績・稼働状況という情報に絞った一覧で表示する機能を実装し、一覧UIを設計した。また、より視認性を向上させ見落としを防止するために、一定の稼働を超えた場合や、実績の進捗状況が計画より遅延している場合はアラート表示する工夫を行った。

　部下向けUIでは、自分の実績更新を行う際、保存する前にシステムを閉じてしまうと途中まで記述した内容が初期化され、再記述する手間が課題となった。そこで、保存機能を下書き機能、下書き自動保存機能、下書き提出機能に分割し、再記述が発生しないような設計を行った。下書き機能を設けた理由としては、記述途中で自動保存された実績情報が意図せず公開され、マネージャーから参照されることを防ぐためである。また、下書き提出機能を利用することで、マネージャーは部下の提出状況を把握できるようになり、効率的に確認できるように工夫を行った。

　ただし、業務報告や1on1は目標策定機能や評価機能は、マネージャーと部下の両者が同じ情報を共有し、打合せ形式で認識合わせをするため、個別のUI設計ではスムーズに目標策定や評価が行えないという新たな課題が生じた。そこで私は、業務報告や1on1を実施する際に両者が利用できるように、目標策定機能や評価機能を中心とした打ち合わせ向けUIを設計した。また、システムを利用して効率的に業務報告や1on1を実施するために同時編集機能を実装した。なぜならば、両者が目標策定機能や評価機能を利用しながら打合せをすることで、改めて目標等をシステムに入力する必要がなくなり、かつ打合せの場で、合意を取って保存できるため、認識誤りの抑止に繋がり、全体の効率化に繋がると考えたからである。

設問ウ設 問イで述べた UI の設計において，ユーザビリティを高めるために，設計プロセスにおいて，どのような工夫をしたか。600 字以上 1,200 字以内で具体的に述べよ。

（860文字）

第３章　設計プロセスにおける工夫
３．１　設計プロセスにおける課題
　UIの設計では、ユーザービリティを高めることが重要である。要件定義工程では、重視するユーザービリティを効率と定めた。そこで、効率をどのように高めるかが課題となった。

３．２　仮説検証を含めた設計プロセスにおける工夫
　課題に対して、目標とする効率が十分な度合いであることを検証する工程を盛り込むことにした。ただし、利用者特性や、利用シーンが多様であるため、設計者のみでは目標とする効率が十分であるかを設計者だけで判断することが難しいという課題に直面した。そこで、要件定義工程の後に次に設計プロセスを盛り込むことにした。
（１）効率に関わる要件における仮説の確認
　マネージャー、部下、打ち合わせ向けとして、個別にUIを設計したことで、各利用者が効率的にシステムを利用できるという仮説を確認する。
（２）プロトタイプ作成と、プロトタイプによる実験
　設計・実装後の出戻りを防ぎ利用者と、要件定義後にプロトタイプを作成し、各利用者が効率的にシステムを利用できるか実験を行う。
実験の被験者は、リリース後のシステムを利用する社内の一部組織を対象として実施する。なぜならば、実業務で実際に利用する社員で実験することで精度の高い検証結果が得られるためである。
（３）仮説検証
　実験における被験者からのフィードバックに基づき仮説を検証する。被験者からのフィードバックはアンケートに加え、思考発話法や、システムで操作所要時間を計測し、総合的に判断する。なぜならば、アンケートでの言語化は被験者の負荷が高く意図したフィードバックが得られない可能性があると考えたからである。そのため、限られた実験を有効活用するため、複数の方法で計測を行う。
　仮説が誤っている場合は、仮説を見直して再度（２）のプロセスから繰り返す。ただし、仮説検証を繰り返した場合に終わらないため、仮説検証を2回実施するか、プロトタイプの操作所要時間が全体で50%改善していれば、効率が達成されたと判定し、仮説検証を修了するとした。

ー以上ー