（演習）良いユーザインタフェースとは／保守期間と情報処理システム

• 日程: Day 2 / セッション8
• 時間: 14:30-15:10
• 形式: 演習
• ゴール: 良いUIの条件を3つ挙げ、開発テーマのシステムに必要な保守期間（1年／5年／10年以上）を根拠つきで選べる
• 学習形式: AIディスカッション

🗣️ 要約

• 良いUIには共通する条件があり、チームで言語化する
• システムの想定使用期間（1年〜10年以上）によって、UIも情報アーキテクチャも作り方が変わる
• 保守期間を曖昧にしたまま実装に入ると、後から作り直しになりやすい

前のセッションでは、UIの種類（CUI/CLI/GUI）やWebブラウザの技術、購買行動モデルを学びました。知識としてのUIは頭に入りましたね。

ここで少し考えてみてください。あなたが最近「使いやすい」と感じたアプリやWebサイトはありますか？逆に「使いにくい」と感じたものは？

実は、良いUIには共通する条件があります。このセッションでは、その条件をチームで言語化します。さらに、開発テーマのシステムが「1年で使い捨てるのか」「10年以上使い続けるのか」によって、UIも情報アーキテクチャも作り方が変わってくることを体験します。

なぜこれを学ぶのか。開発テーマを実装するDay4に向けて、「誰にとって・どれくらいの期間使われるUIなのか」を先に決めておく必要があるからです。ここを曖昧にしたまま実装に入ると、後から作り直しになりがちです。

🗣️ 要約

• 良いUIとは「利用者が迷わず、目的を達成できる入出力の仕組み」
• 良いUIの条件は一貫性・フィードバック・誤り耐性など
• 情報処理システムの保守期間（1年／5年／10年以上）によって、UIと情報モデルの作り込み方が変わる

🗣️ 要約

• 良いUIとは「利用者が迷わず、目的を達成できる入出力の仕組み」（例：券売機）
• 良いUIの条件は一貫性・フィードバック・誤り耐性
• ボタンの位置や操作結果が分からないUIは、利用者に推測を強いるため該当しない

良いUIを一言で言うと「利用者が迷わず、目的を達成できる入出力の仕組み」です。

たとえば、券売機は良いUIの例です。行き先のボタンを押す→金額を入れる→切符が出る、という手順が誰の目にも明らかだからです。一方、ボタンがどこにあるか分からない、押した結果が何も表示されない券売機は該当しません。なぜなら、利用者が「次に何をすればいいか」を推測しなければならないからです。

良いUIの条件は、たとえば次のようなものが挙げられます。

• 一貫性（同じ操作は同じ結果になる）
• フィードバック（操作した結果がすぐ分かる）
• 誤り耐性（間違えてもすぐ元に戻せる）

ここまでで、良いUIのイメージは掴めましたか？次は、このUIをどれくらいの期間使い続けるかによって、設計の重みづけが変わってくる話をします。

🗣️ 要約

• 情報処理システムの保守期間は「1年」「5年」「10年以上」に大別できる
• 1年程度ならUIは最小限・スピード優先、5年程度なら一貫性・保守性に投資、10年以上なら情報モデルの拡張性を重視する
• 保守期間の考え方は建物の設計（仮設イベント会場か100年住む家か）に似ている

情報処理システムには、想定される保守期間があります。おおよそ「1年」「5年」「10年以上」に分けて考えることができます。

これは、いわば建物の設計に似ています。仮設のイベント会場と、100年住み続ける家では、使う材料も基礎工事のかけ方もまったく違いますよね。情報システムも同じで、1年だけ使う社内ツールと、10年以上使う基幹システムとでは、UIの作り込み方も、情報モデルの柔軟性も変えるべきです。

• 1年程度の想定であれば、UIは最小限で作り、スピード優先でよい場合が多い
• 5年程度の想定であれば、UIの一貫性やメンテナンス性にもある程度投資すべき
• 10年以上の想定であれば、ペルソナや情報モデルが将来変化することを見込んで、拡張しやすい設計にしておく必要がある

なぜ保守期間を最初に決めるのでしょうか。少し考えてみてください。もし決めずに作り始めると、どんなことが起きるでしょうか。

保守期間による設計判断の違いをフローで示すと、次のようになります。

特に注意してほしいのは、保守期間の選択に「絶対の正解」はないという点です。よくある間違いとして「なんとなく長く使えそうだから10年」と選んでしまうケースがありますが、正しくは、ペルソナが何年その情報を必要としているか、開発テーマの性質（流行り廃りがあるか、法制度に紐づくか等）から根拠を持って決めることです。

家電製品には「補修用性能部品の保有期間」という考え方があり、メーカーは製品を作った後も、一定年数は修理用の部品を保管する義務のようなルールを設けています。情報システムの世界にはこうした明文化されたルールは少ないのですが、「作って終わり」ではなく「何年面倒を見るか」を最初に決めておくという発想は、家電の世界からも学べることです。

🗣️ 要約

• 良いUIの具体的な業界例、保守期間による情報モデルの作り方の違い、自分たちの開発テーマに適した保守期間などをAIに質問できる

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「良いUIの条件をもっと具体的な業界の例で教えて」
• 「保守期間が長いシステムと短いシステムで、情報モデルの作り方はどう変わるの？」
• 「自分たちの開発テーマ（〇〇）なら、保守期間は何年くらいが妥当？」

🗣️ 要約

• 良いUIの条件を3つ以上挙げ、開発テーマの保守期間を根拠つきで1つ選ぶ演習

🗣️ 要約

• 良いUIの条件をディスカッションで3つ以上挙げる
• 開発テーマの保守期間（1年／5年／10年以上）を1つ選び、根拠を2つ以上挙げる

1. 良いユーザインタフェースとは何か、チームでディスカッションし、条件を3つ以上挙げる
2. 開発テーマのシステムについて、保守期間（1年／5年／10年以上）を1つ選び、その根拠を2つ以上挙げる

🗣️ 要約

• 「良いUIの条件」リスト（3つ以上）と「保守期間とその根拠」メモ

• 「良いUIの条件」リスト（3つ以上）
• 「保守期間とその根拠」メモ

🗣️ 要約

• 意見がまとまらないときは、各自の「使いやすいアプリ」の共通点から探すとやりやすい
• 保守期間の根拠に迷ったら、ペルソナがこのシステムを何年使いたいかをAIに相談するとよい

• 意見がまとまらない場合は、まず一人ひとりが「使いやすいと思うアプリ」を1つ挙げてから、共通点を探すとやりやすくなります
• 保守期間の根拠に迷ったら、「Day1で定義したペルソナは、このシステムを何年使い続けたいと思うか」をAIに相談してみましょう

🗣️ 要約

• UIの良し悪しもシステムの寿命も、ペルソナと開発テーマの性質から逆算して決める
• 次回は保守期間の考え方を踏まえてモックアップツールで試作品を作る

今回学んだことを一言でまとめると「UIの良し悪しも、システムの寿命も、ペルソナと開発テーマの性質から逆算して決めるもの」です。

次回は、この保守期間の考え方を踏まえて、モックアップツールで実際に触れる試作品を作ります。今回決めた保守期間の長さが、試作品の作り込みの粒度にも関わってくるので、しっかり覚えておきましょう。

🗣️ 要約

• 良いUIの条件を3つ挙げられるか
• 保守期間が10年以上の場合と1年の場合で重視すべき点の違いを説明できるか

以下の問いに答えられるか確認してみましょう：

• 良いUIの条件を3つ挙げられますか？
• 保守期間が10年以上の場合、1年の場合と比べて何を重視すべきか説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

🗣️ 要約

• 参考リンクはなく、社内の開発テーマ資料・議論メモを参照する
• 発展課題は、普段使っているアプリの想定保守期間を推測すること

• 参考リンク: なし（社内の開発テーマ資料・チームの議論メモを参照）
• 発展課題: 自分たちが普段使っているアプリを1つ選び、想定される保守期間を推測してみる

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

🗣️ 要約

• 良いUIの条件は業界により上乗せされる部分があるが、一貫性・フィードバック・誤り耐性は共通の土台
• 保守期間は多数決ではなく、ペルソナの利用シーンや開発テーマの性質から根拠を導く

🗣️ 要約

• 良いUIの条件が「見た目」など主観的な話に終始しやすい
• 保守期間の根拠が「なんとなく」で終わりやすい