Goalmap-OOUI

はじめに

「計画を立てる機能」からではなく、
学習者が扱うゴールと学習対象からUIを考える

司会

Goal Mapを題材に、OOUIにおけるUIモデリングを説明してください。

ゴール、学習工程、学習項目、学習記録など、利用者が扱う対象を抽出し、その関係・状態・操作を整理します。そのうえで、一覧と詳細のビューへ落とし込み、計画と実績を同じ対象の変化として確認できる構造を考えます。

個人プロダクトを、現在のOOUIに対する理解で振り返る

Goal Mapは、資格取得、受験、就職活動など、期限のあるゴールから逆算して学習計画を立て、日々の進捗や理解度を管理するために企画した学習支援アプリです。

元となるPRDは、以下のページで紹介しています。

Goal Map -PRD｜ゴールから逆算する学習進捗管理アプリの企画・設計 - TFキリンのMVP開発

01. プロジェクト概要 プロジェクト名：Goal Map ジャンル：学習進捗管理 / 資格学習支援 / ロードマップ管理 対象：資格取得、受験、就職活動など、明確なゴールに向けて継続的に行動する人 主な利用シーン：資格試験日や就職活動の期限から逆算し、学習計画・進捗・理解度を管理する場面 開発環境・使用技術：画面モック作成、競合分析、WordPress掲載用記事化 ※具体ツールは要確認 担当：企…

当初の企画では、課題整理、競合分析、主要機能、体験フロー、開発フェーズ、画面モックを中心にまとめました。本記事では、その設計を、現在のOOUIに対する理解に基づいて再整理します。

「当時からOOUIを正式な工程として採用していた」と置き換えるのではなく、既存の企画と画面を題材に、オブジェクト中心で考えると、どのような構造と判断が必要になるかを検討します。

今回の再モデリングで確認すること

本記事では、次の7つのSTEPに沿って、Goal Mapの構造を再モデリングします。

1. STEP 1：Goal Mapに存在するオブジェクト候補を抽出する
2. STEP 2：オブジェクトと属性・状態・集計値・ビューの境界を整理する
3. STEP 3：ゴール、学習工程、学習項目、学習記録の関係を整理する
4. STEP 4：上位の中心オブジェクトと、日々の中心オブジェクトを判断する
5. STEP 5：コレクションビューとシングルビューへ落とし込む
6. STEP 6：計画と実績の差を、同じオブジェクトの情報として提示する
7. STEP 7：OOUIとタスクフローを組み合わせて検証する

OOUIに対する理解

機能メニューを並べる前に、
利用者が管理する「対象」を明確にする

司会

Goal Mapをタスク指向で設計すると、どのような構造になりますか？

「ゴールを設定する」「計画を作る」「進捗を入力する」「理解度を確認する」など、操作を入口にした構造になりやすいです。
そこでOOUIでは、先にゴールや学習項目を選び、その対象に対して可能な操作を提示します。

操作の入口が増えると、対象と文脈が分断される

Goal Mapの主要機能を、そのままメニューとして並べると次のようになります。

• ゴールを設定する
• ロードマップを作成する
• 学習予定を登録する
• 進捗を入力する
• 理解度を確認する
• 計画を見直す

これらは必要なタスクですが、操作ごとに入口が分かれると、「どの資格取得のゴールを扱っているのか」「どの学習項目の進捗なのか」を都度選び直す可能性があります。

学習者が実際に意識しているのは、機能名よりも「取得したい資格」「今週取り組む章」「復習が必要な問題集」のような対象です。

そこで、まず「ゴール」や「学習項目」を提示し、対象を選択した状態で、編集、記録、見直しなどの操作を行える構造を考えます。

OOUIで重視する基本の順序

1. 利用者が扱うオブジェクト候補を見つける
2. オブジェクトの属性、状態、アクションを整理する
3. オブジェクト同士の関係を整理する
4. 複数の対象を選ぶコレクションビューを考える
5. 選んだ対象を理解・操作するシングルビューを考える
6. 主要ユースケースと例外状態を検証する

画面一覧から情報を割り振るのではなく、利用者が認識する対象を起点に、必要なビューを導くことを重視します。

プロダクト背景

ゴールまでの現在地と、次に取り組む対象を理解できる状態へ

司会

Goal Mapでは、どのような課題を解決したいと考えましたか？

学習計画を立てても、ゴールに対する現在地、計画と実績の差、理解が不足している対象を把握しにくい課題です。学習者が次に何を調整すべきか判断できる状態を目指しました。

学習時間だけでは、ゴールへの距離を判断できない

資格取得や受験では、期限と学習範囲があり、複数の教材や分野を継続して進めます。

しかし、学習時間だけを記録しても、次のことは十分に把握できません。

• ゴールに対して、現在どこまで進んでいるか
• どの学習項目が予定より遅れているか
• 完了したが、理解が不足している項目は何か
• 次にどの対象へ時間を使うべきか
• 期限に合わせて、どの計画を見直す必要があるか

そのため、単なるタスク管理ではなく、ゴール、学習工程、学習項目、実績の関係を保ちながら確認できる構造が必要だと考えました。

計画と実績を、別々の画面だけで管理しない

計画画面と実績画面が分断されていると、利用者は同じ学習項目について、予定と結果を頭の中で照合する必要があります。

OOUIの観点では、計画と実績を別機能として扱う前に、同じ学習項目オブジェクトが、予定情報と実績情報の両方を持つ構造を検討できます。

学習項目の詳細を開けば、予定日、目標量、実績、理解度、現在状態を同じ文脈で確認でき、必要に応じて計画を修正できます。

モデリング STEP 1

利用シーンを文章化し、オブジェクト候補とアクションを抽出する

司会

Goal Mapでは、どのようなオブジェクト候補がありますか？

ゴール、ロードマップ、学習工程、学習項目、学習記録などが候補になります。ただし、進捗や理解度は、独立した対象ではなく属性や集計値として扱う可能性も検討します。

代表的な利用シーンを文章にする

今回の再モデリングでは、代表的な利用シーンを次のように置きました。

学習者が資格取得のゴールと試験日を登録する。ゴールまでに必要な学習工程と学習項目を作成し、予定日と目標量を設定する。日々の学習後に実績と理解度を記録し、遅れている項目や復習が必要な項目を確認して、計画を見直す。

この文章から、名詞と動詞を分けます。

• 名詞：学習者、資格、ゴール、試験日、学習工程、学習項目、予定日、目標量、学習実績、理解度、復習、計画
• 動詞：登録する、作成する、設定する、記録する、確認する、見直す

名詞はオブジェクトまたは属性の候補となり、動詞はアクションまたは関係の候補になります。

初期のオブジェクト候補

候補をすべて独立オブジェクトにしない

名詞として抽出された「試験日」「予定日」「目標量」は、それだけで一覧・詳細・固有操作を持つ必要がなければ、ゴールや学習項目の属性として扱えます。

「理解度」も、学習項目に対する現在値だけを扱うなら属性です。一方、理解度の変化を時系列で残し、複数回のテスト結果を比較する場合は、「理解度評価」や「テスト結果」を独立したオブジェクトとして扱う可能性があります。

オブジェクトとして扱うかどうかは、次の観点で判断します。

• 独立した識別情報を持つか
• 独自の状態やライフサイクルを持つか
• 利用者がその対象を直接選択・操作するか
• 複数のオブジェクトから参照されるか
• 履歴や権限を個別に管理する必要があるか
• コレクションとシングルのビューが必要か

モデリング STEP 2

オブジェクト・属性・状態・集計値・ビューの境界を見極める

司会

ロードマップや進捗も、オブジェクトとして扱いますか？

自動的にオブジェクトとは決めません。ロードマップは学習工程や学習項目を時間軸で並べるビュー、進捗は実績から計算する集計値として扱う方が自然な場合があります。

ここでは、抽出した候補を「独立したオブジェクト」「オブジェクトが持つ属性や状態」「ほかの情報から算出される集計値」「複数のオブジェクトを表現するビュー」に分類し、それぞれの境界を整理します。

ロードマップは、オブジェクトにもビューにもなり得る

Goal Mapでは「ロードマップ」という言葉がプロダクト体験の中心にあります。

ただし、ロードマップが独立オブジェクトかどうかは、要件によって変わります。

• ビューとして扱う場合：ひとつのゴールに属する学習工程と学習項目を、時間軸で表示する
• オブジェクトとして扱う場合：複数案を保存する、版を管理する、テンプレートとして共有する、公開範囲を設定する

初期MVPで、ひとつのゴールにひとつの計画だけを持つなら、ロードマップを独立させず、ゴール配下の工程と項目を可視化するビューとして扱う方がシンプルです。

将来、計画A・計画Bを比較する、講師が作ったロードマップを学習者が複製する、といった要件が生まれた場合は、独立したオブジェクトとして再検討できます。

進捗は、ほかの情報から導かれる集計値

「進捗」は重要ですが、必ずしも独立した対象ではありません。

たとえば、学習項目の完了数、目標量と実績の差、期限までの残日数などから計算される値として扱えます。

• ゴール全体の進捗
• 学習工程ごとの進捗
• 学習項目ごとの達成率
• 予定進捗と実績進捗の差

進捗値そのものを利用者が直接編集するのではなく、学習記録や完了状態を更新した結果として変化する構造が自然です。

計画は、予定情報とオブジェクト間の関係として表現する

初期段階では、「計画」を大きな独立機能として扱う前に、ゴール、学習工程、学習項目が持つ予定情報として整理できます。

• ゴールが、達成期限を持つ
• 学習工程が、開始日と終了日を持つ
• 学習項目が、予定日と目標量を持つ
• 学習項目が、前後の項目や工程と関係する

計画変更は、抽象的な「計画」を編集するのではなく、対象となる工程や学習項目の予定情報を変更する操作として設計できます。

モデリング STEP 3

ゴールから学習記録まで、親子関係と生成関係を整理する

司会

抽出したオブジェクト同士は、どのようにつながりますか？

学習者がゴールを持ち、ゴールが学習工程を含み、工程が学習項目を含みます。学習項目へ取り組むと学習記録が追加され、その結果から進捗や理解度を確認します。

オブジェクト同士を、業務上の動詞でつなぐ

初期MVPを想定し、次の関係を基本形として整理しました。

1. 学習者が、ひとつ以上のゴールを持つ
2. ゴールが、複数の学習工程を含む
3. 学習工程が、複数の学習項目を含む
4. 学習項目が、必要に応じて教材を参照する
5. 学習項目へ取り組むと、学習記録が追加される
6. 学習記録の集計から、学習項目・工程・ゴールの進捗を算出する

関係を線で結ぶだけでなく、「含む」「参照する」「記録される」「算出される」といった動詞で説明することで、情報の所属と操作結果を確認しやすくなります。

親を削除・変更したときの影響も確認する

関係を整理するときは、正常な表示だけでなく、変更時の影響も確認します。

• ゴールの期限を変更した場合、工程と学習項目の予定をどう扱うか
• 学習工程を削除した場合、配下の学習項目をどう扱うか
• 学習項目を別の工程へ移動できるか
• 完了済みの学習項目を再開できるか
• 学習項目を削除しても、学習記録を履歴として残すか
• ゴール達成後も、記録を閲覧できるか

画面を作る前に関係とライフサイクルを確認することで、実装段階で発生する矛盾や例外を減らせます。

モデリング STEP 4

上位では「ゴール」、日々の操作では「学習項目」を中心にする

司会

Goal Mapの中心オブジェクトは「ゴール」ですか？

プロダクト全体の入口ではゴールが中心です。一方、日々の学習では、実績や理解度を記録する学習項目が中心になります。利用文脈に応じて、二段階で考えます。

プロダクト全体のルートオブジェクトは「ゴール」

利用者は、資格取得、受験、就職活動など、複数のゴールを同時に持つ可能性があります。

ゴールを選ぶと、そのゴールに関係する工程、学習項目、期限、進捗、学習記録へアクセスできます。

ゴールには、次の操作が属します。

• 名称や期限を編集する
• 工程と学習項目を見る
• 全体進捗を確認する
• 計画を見直す
• 一時停止する
• 達成済みにする
• アーカイブする

日々の行動を支える中心オブジェクトは「学習項目」

学習者が日常的に操作するのは、「参考書の第3章を読む」「過去問題を20問解く」といった学習項目です。

学習項目には、予定と実績が集まります。

• いつ取り組む予定か
• どの教材を使うか
• どの程度まで進めるか
• 実際にどこまで進んだか
• 理解できたか
• 復習が必要か

そのため、日々のホーム画面では、機能メニューを並べるよりも「今日の学習項目」「遅れている学習項目」「復習が必要な学習項目」など、学習項目のコレクションを入口にする方が自然です。

ひとつの中心だけへ固定しない

中心オブジェクトは、画面全体でひとつに固定する必要はありません。

プロダクト全体を見渡す場面ではゴール、ロードマップを確認する場面では学習工程、日々の記録では学習項目が主役になります。

重要なのは、それぞれを別機能として分断せず、親子関係と現在の文脈を保ったまま移動できることです。

モデリング STEP 5

コレクションビューとシングルビューで、
対象を探す・理解する・操作する

司会

オブジェクトモデルを、どのようにUIへ落とし込みますか？

複数の対象から選ぶコレクションビューと、ひとつの対象を理解・操作するシングルビューを基本にします。同じ学習項目を、ロードマップ、今日の学習、遅れている項目、復習が必要な項目など、異なるコレクションで扱えます。

ゴールの『コレクションビュー』

利用者が複数のゴールを持つ場合は、ゴール一覧を入口にします。

• ゴール名
• 期限と残日数
• 全体進捗
• 予定と実績の差
• 現在の状態
• 次に確認すべき学習項目

ゴールを選択すると、そのゴールのシングルビューへ進みます。

ゴールの『シングルビュー』

ゴール詳細では、対象の概要と配下の学習工程・学習項目を確認します。

• 名称、目的、期限
• 全体進捗と予定進捗
• 工程ごとの状態
• 遅れている学習項目
• 復習が必要な学習項目
• 直近の学習記録
• 計画を見直すアクション

学習項目の複数のコレクションビュー

同じ学習項目でも、利用目的に応じて異なるコレクションとして表示できます。

• ロードマップ：工程と時間軸の中で位置を理解する
• 今日の学習：本日取り組む対象を確認する
• 遅れている項目：予定と実績の差から見直し対象を確認する
• 復習が必要な項目：理解度や前回記録から再学習対象を確認する
• 完了した項目：学習履歴と達成を振り返る

コレクションが変わっても、選択後は同じ学習項目のシングルビューへ進みます。

学習項目のシングルビュー

学習項目の詳細では、予定・実績・状態・操作を同じ文脈にまとめます。

• 学習項目名と所属工程
• 教材と対象範囲
• 予定日と目標量
• 現在の達成量
• 理解度と復習状態
• 過去の学習記録
• 実績を記録する、完了する、予定を変更するなどの操作

機能画面を移動して予定と実績を確認するのではなく、対象となる学習項目の中で一貫して扱える構造を目指します。

設計補足 1

現在の状態に応じて、次に行える操作を対象の近くに提示する

司会

学習項目の状態とアクションは、どのように整理しますか？

未計画、予定済み、進行中、完了、復習必要などの状態を整理し、その状態で実行できる操作を学習項目にひもづけます。

学習項目の状態を整理する

状態とアクションを分離しすぎない

「実績を入力する」という独立メニューを開いた後に学習項目を探すより、学習項目を選び、その対象に「実績を記録する」操作を提示する方が、対象を取り違えにくくなります。

また、完了状態の項目には「開始する」ではなく、「記録を見る」「再開する」「復習対象にする」など、現在状態に合った操作を提示します。

ゴールにも独自の状態を持たせる

上位オブジェクトであるゴールにも、次のような状態があります。

• 下書き
• 進行中
• 一時停止
• 期限超過
• 達成
• アーカイブ

ゴールの状態によって、新しい学習項目を追加できるか、実績を記録できるか、計画を編集できるかなどの操作条件が変わります。

モデリング STEP 6

予定と結果を、同じ学習項目の異なる情報として比較する

司会

Goal Mapで重要な、計画と実績の差はどのように見せますか？

別々の機能として比較させるのではなく、学習項目や工程の中に予定と実績を並べます。差がある対象をコレクションとして抽出し、対象の詳細から修正できる構造にします。

計画と実績を、対象ごとに比較する

たとえば、学習項目に次の情報を持たせます。

• 計画：予定日、目標量、想定時間、優先度
• 実績：実施日、達成量、学習時間、理解度
• 差分：日数の遅れ、未達量、理解度不足

学習項目の詳細で計画と実績を確認できるほか、差が大きい学習項目を「遅れている項目」のコレクションとして提示します。

差を示すだけでなく、次の判断へつなげる

遅れを強調するだけでは、学習者へ心理的な負担を与える可能性があります。

重要なのは、遅れを責めることではなく、次の調整へつなげることです。

• 予定日を変更する
• 目標量を分割する
• 別の学習項目の優先度を下げる
• 復習項目として追加する
• ゴール全体の期限や工程構成を見直す

差が発生している対象を選び、その対象に対して調整を行えることが重要です。

全体の進捗から、具体的な対象へ降りられる構造

ゴール詳細では全体進捗を要約し、工程、学習項目へ段階的に掘り下げます。

1. ゴール全体で、予定と実績の差を確認する
2. 差が大きい学習工程を確認する
3. 遅れや理解不足がある学習項目を確認する
4. 対象となる学習項目の予定・実績・記録を見る
5. 学習項目または上位計画を調整する

抽象的な進捗率を見るだけで終わらず、原因となっているオブジェクトへ到達できることを重視します。

設計補足 2

「完了」と「理解」を分け、復習が必要な対象を見つける

司会

学習項目を完了したら、それでゴールへ近づいたと判断できますか？

学習量を消化したことと、理解・定着したことは分けて考える必要があります。完了状態に加えて理解度を持ち、復習が必要な学習項目を別のコレクションとして提示します。

完了状態と理解度は、異なる軸として扱う

学習項目が完了していても、理解度が低い場合があります。

そのため、次の情報を分けて扱います。

• 進行状態：未着手、進行中、完了
• 達成量：予定した範囲をどこまで終えたか
• 理解度：内容をどの程度理解・定着できたか
• 復習状態：復習不要、復習予定、復習中、再確認済み

これにより、「完了しているが復習が必要」という状態を表現できます。

復習を、独立機能ではなく学習項目との関係で扱う

「復習する」というメニューから対象を探すのではなく、理解度や学習記録をもとに、復習が必要な学習項目のコレクションを作ります。

対象を選ぶと、元の学習項目の詳細へ移動し、過去の実績、理解度、教材、復習予定を同じ文脈で確認します。

将来、復習予定が複数回発生し、それぞれに期限や結果を持つ場合は、「復習セッション」や「理解度評価」を独立オブジェクトとして扱うことも検討できます。

モデリング STEP 7

オブジェクトモデルを土台に、初回設定と日々の利用フローを検証する

司会

Goal Mapでも、タスクフローは必要ですか？

必要です。OOUIで対象と関係を整理したうえで、初回設定、日々の記録、計画見直しなどの重要なシナリオを通し、情報や状態が不足していないか確認します。

初回設定には、順序を支援する導線が必要

新しいゴールを作るときは、期限から逆算して工程と学習項目を作る必要があります。

この場面では、対象を自由に操作できるだけでなく、必要な情報を順番に登録できるステップ形式が有効な場合があります。

1. ゴール名と期限を登録する
2. 必要な学習工程を登録する
3. 工程に学習項目を追加する
4. 予定日と目標量を設定する
5. 全体のロードマップを確認する

ただし、作成後はステップ形式に閉じ込めず、ゴール、工程、学習項目の各シングルビューから編集できるようにします。

日々の利用は、対象から操作できることを優先する

日々の学習では、取り組むべき対象をすぐに見つけられることが重要です。

• 今日取り組む学習項目
• 期限が近い学習項目
• 遅れている学習項目
• 復習が必要な学習項目

学習項目を選んだ後に、実績を記録する、完了する、予定を変更するなどの操作を提示します。

OOUIとタスクフローを往復して改善する

1. オブジェクト候補と関係を整理する
2. コレクションとシングルのビューを設計する
3. 状態とアクションを定義する
4. 初回設定や日々の利用をタスクフローで確認する
5. 不足する属性・状態・関係をモデルへ戻す
6. プロトタイプで理解しやすさと操作性を検証する

OOUIだけ、タスクフローだけに寄せるのではなく、設計上の目的に応じて組み合わせます。

MVPによる検証

最小のオブジェクト構成で、ゴールから日々の記録までの体験を確かめる

司会

最初から、すべてのオブジェクトと機能を実装しますか？

初期MVPでは、ゴール、学習工程、学習項目、学習記録に絞ります。理解度評価や自動調整などは、基本体験を検証してから追加します。

初期MVPで扱う範囲

• ゴールを作成し、期限を設定できる
• ゴールに学習工程を追加できる
• 工程に学習項目を追加できる
• 学習項目に予定日と目標量を設定できる
• 学習項目に実績を記録できる
• 工程とゴールの進捗を確認できる
• 予定と実績の差がある学習項目を見つけられる

初期段階では、オブジェクト数を増やすことよりも、基本となる親子関係と記録の流れを利用者が理解できるかを確認します。

検証したい問い

• 利用者は、ゴール・工程・学習項目の違いを理解できるか
• 現在どのゴールを扱っているか見失わないか
• 今日取り組む学習項目を短時間で見つけられるか
• 学習項目の予定と実績を同じ対象として理解できるか
• 進捗の遅れから、原因となる学習項目へ到達できるか
• 計画変更後に、どの工程や項目が変わったか理解できるか
• 完了と理解度の違いを理解できるか

確認したい指標

• ゴール作成から最初の学習項目登録までの完了率
• 今日の学習項目を見つけるまでの時間と操作数
• 実績記録の継続率
• 予定と実績の差に気づけた割合
• 計画見直しを完了できた割合
• ゴール・工程・学習項目を取り違えた操作
• 利用者が使う言葉と、UI上の名称のずれ

検証結果に応じて、オブジェクトの名称、粒度、関係、ビュー、操作を修正します。

学びと関心

ロードマップを画面名ではなく、オブジェクトの集合を表すビューとして捉え直す

司会

今回の再モデリングから、どのような学びがありましたか？

ロードマップや進捗といった画面上の言葉を、そのままオブジェクトにしないことです。利用者が直接扱う対象か、対象の集合を見せるビューか、計算による値かを分ける必要があると考えました。

画面名・機能名と、オブジェクトは同じではない

Goal Mapでは、「ロードマップ」「進捗」「計画」「理解度」といった言葉が頻繁に登場します。

しかし、これらをすべて独立したオブジェクトにすると、モデルが複雑になり、利用者が何を直接操作するのかが見えにくくなります。

今回の再モデリングでは、次のように整理しました。

• ロードマップ：工程と学習項目を時間軸で表すビューとして開始する
• 進捗：学習項目と記録から算出される集計値として扱う
• 計画：工程と学習項目が持つ予定情報として扱う
• 理解度：初期段階では学習項目または学習記録の属性として扱う

将来、独自の識別情報、履歴、共有、権限が必要になった段階で、独立オブジェクトへの拡張を検討します。

同じオブジェクトを、複数の切り口で再利用できる

学習項目を安定したオブジェクトとして定義すると、ロードマップ、今日、遅延、復習、完了など、複数のコレクションで再利用できます。

新しい画面を追加するたびに別のデータや操作を作るのではなく、同じ学習項目を別の条件で抽出し、同じシングルビューへ接続できます。

これは、UIの一貫性だけでなく、実装・テスト・運用の再現性にもつながると考えます。

今後、さらに深めたいこと

• ゴールや学習項目のテンプレート共有を含むオブジェクト設計
• 講師・学習者・管理者など、役割と権限によるビューの違い
• 計画変更時の依存関係と影響範囲の表現
• 理解度評価と復習履歴のライフサイクル
• 通知・リマインダーを、どのオブジェクトへ所属させるか
• オブジェクトモデルとデータモデル・API設計の接続
• ユーザーテストからモデルを修正する方法

まとめ

ゴールと学習項目を起点に、計画・実績・理解度がつながるUIへ

今回のUIモデリングで整理したこと

Goal MapをOOUIの観点から再モデリングし、冒頭で掲げた7つのSTEPを次のように整理しました。

1. STEP 1：利用シーンを文章化し、ゴール、学習工程、学習項目、学習記録などのオブジェクト候補を抽出しました。
2. STEP 2：試験日や目標量は属性、進捗は集計値、ロードマップは初期段階ではビューとして扱うなど、オブジェクトとの境界を整理しました。
3. STEP 3：ゴールが学習工程を含み、工程が学習項目を含み、学習項目への取り組みから学習記録が生成される関係を整理しました。
4. STEP 4：プロダクト全体の入口ではゴール、日々の学習では学習項目を中心オブジェクトとして位置づけました。
5. STEP 5：ロードマップ、今日の学習、遅れている項目、復習が必要な項目などをコレクションビューとし、選択後は共通のシングルビューへ接続する構造を整理しました。
6. STEP 6：学習項目のシングルビューで予定・実績・理解度・差分をまとめ、差が生じた対象から計画を調整できる構造を整理しました。
7. STEP 7：オブジェクトモデルを土台に、初回設定や日々の利用をタスクフローで検証し、結果をモデルへ戻す進め方を整理しました。

OOUIを、複雑化に耐えられる構造づくりへ活かす

Goal Mapは、初期段階ではシンプルな学習進捗管理アプリです。しかし、教材、理解度評価、復習、通知、講師、共有ロードマップなどを追加すると、扱う情報と機能は増えていきます。

機能を追加するたびに画面を増やすのではなく、その情報や操作が既存のどのオブジェクトに属するのか、新しいオブジェクトとして扱う必要があるのかを判断することが重要です。

利用者が認識する対象を明確にし、対象同士の関係を保ちながら、一覧・詳細・状態・操作を一貫して設計すること。

この考え方を、学習支援サービスだけでなく、目標管理、進捗管理、プロジェクト管理など、複雑な情報を扱うプロダクトの設計にも応用していきたいと考えています。