UX/UIデザイン用語集⑧｜開発との連携

この用語集は以下①〜⑧の記事で構成されています。UX/UIデザインの基本概念から設計フレーム、調査手法、UI構成要素、ドキュメント、チーム体制、開発連携に至るまで、全体を俯瞰できる用語を選定して整理しています。

様々な企業や職種が関わるプロダクト開発の現場において、UX/UIデザインへの共通理解を深め、意思決定や進行の遅れを防ぐお手伝いになれば幸いです。

＜UX/UIデザイン用語集へのリンク＞

Figma / Adobe XD

デジタルプロダクトやサービスの設計に用いるソフトウェア。
UI設計やプロトタイピングを効率化し、チームのコラボレーションも支援する。

Figma / Adobe XD

UIのデジタル制作ツール

FigmaやXDは、WebサイトやアプリなどのUI（ユーザーインターフェース）を設計・構築するためのソフトウェアです。代表的なものにはFigmaやAdobe XDがあり、ワイヤーフレーム作成からビジュアルデザイン、プロトタイプ作成、フィードバックの収集まで、一貫した作業が可能です。主に以下のような機能を備えています。

・画面単位での構成（アートボード）
・パーツの再利用（コンポーネント、ライブラリ）
・操作感の再現（インタラクション設計）
・チームとのリアルタイム共有やコメント

クラウドベースやプラグイン対応、デザインシステムとの連携など、進化を続けている分野でもあります。

使われる場面

スタートアップがMVPのUIを素早く制作する際に活用されるほか、デザインスプリントの中で仮説を検証するためのプロトタイプ作成にも利用されます。また、エンジニアやステークホルダーへデザインの意図を伝えるための資料としても役立ちます。

POINT

・最初にワイヤーフレームから始めて構造を固める
・デザインシステムを活用して一貫性を保つ
・コメントや共有リンクでチームとの認識を合わせる

MVP（Minimum Viable Product）

最小限の機能で構成された製品の試作品を指し、ユーザーからの早期フィードバックを得ることを目的とする。

MVP（Minimum Viable Product）

本質的価値を見極める最小構成

MVPは、ユーザーにとって価値のある最小限の機能だけを備えた初期版の製品です。市場に早く投入し、実際のユーザーからの反応やデータを得ることで、以降の開発方向を検証・調整することができます。

すべての機能を完成させてからリリースするのではなく、リスクとコストを抑えながら、学習と改善を重ねていく「リーンスタートアップ」の核となる考え方です。

「MVP」という概念は2001年にFrank Robinsonが提唱し、その後Eric Riesによってリーンスタートアップの中心的要素として普及しました。

よくある誤解

「MVP＝完成度の低い製品」と誤解されがちですが、重要なのは「ユーザーにとって意味のある価値を提供できるか」です。粗削りでも、本質的な価値が体験できるものである必要があります。また、MVPは単なる試作品ではなく、「学びのための仕組み」であり、仮説を検証する目的で複数回繰り返されるプロセスでもあります。

POINT

・ユーザーの課題を1つだけ解決することに集中する
・定量・定性のフィードバックを活用。完成より学習習効果を重視
・繰り返し使える仮説検証の手段として位置づける

アジャイル開発

短いサイクル（スプリント）で反復的にソフトウェアを開発・リリースし、継続的に改善を進める手法。
柔軟性と顧客価値の提供を重視する。

アジャイル開発

変化に強いスピーディな反復開発

アジャイル開発は、仕様をあらかじめすべて決めるのではなく、短い期間（スプリント）で実装と検証を繰り返しながら、継続的にプロダクトを改善していく手法です。2001年に提唱された「アジャイルソフトウェア開発宣言」では「個人と対話」「動くソフトウェア」「顧客との協調」「変化への対応」の4つの価値が掲げられ、スクラムやXP、カンバンといったフレームワークと共に以下のような特徴を持ちます。

・スプリント単位で実装・評価・改善を実施
・チーム間のコミュニケーションを重視
・市場やユーザーの変化に即応可能

UXデザインにおいても、実際のユーザーからのフィードバックを早期に取り入れやすく、プロトタイピングやユーザビリティテストとの親和性が高い手法です。

使われる場面

アジャイル開発は、要件が変わりやすいWebサービスやスタートアップのプロダクト開発に特に適しています。UXデザイナー、エンジニア、プロダクトオーナーが一体となり、迅速かつ柔軟に開発を進める必要がある現場で多く採用されています。

POINT

・スプリントごとに検証を行い、改善サイクルを仕組み化
・MVPでリリースし、実ユーザーの反応をもとに進化させる
・デザイナーもスクラムに参加し、早期に仕様を調整する

要求定義

ユーザーや関係者のニーズや目的を明確にし、それを設計や開発の出発点として共有可能な形で言語化・構造化する工程。

要求定義

ユーザーのニーズを明確化

要求定義は、プロジェクトの初期段階に行われる重要なステップで、ユーザーやステークホルダーからのニーズや課題をヒアリングし、それを設計や開発に反映可能な「要求」として整理します。

この段階での理解不足や齟齬は後の設計ミスや開発コストの増加に直結するため、UXデザイナーはユーザーインタビューやカスタマージャーニーなどの手法を用いて、ニーズを深掘りし、定義内容の妥当性を確認します。

よくある誤解

要求定義は「要件定義」と混同されがちですが、両者は異なります。要求定義は「何を実現すべきか（Why/What）」を明らかにする段階であり、要件定義は「どう実現するか（How）」を詳細に決める工程です。

POINT

・ユーザーの声をそのまま鵜呑みにせず、本質的な課題を探る
・関係者ごとの視点やゴールの違いを意識して調整する
・文書化は曖昧な表現を避け、具体的な言葉で記述する

要件定義

ユーザーの要求を実現するために必要な機能や仕様を決め、文書化してステークホルダー間で合意を得る工程。

要件定義

実現性を技術的に詰める

要件定義は、要求定義で明らかになった目的やニーズを、システムやアプリケーションの具体的な仕様へと落とし込む工程です。

UXデザイナーやエンジニアが協働し、機能要件（何をできるようにするか）と非機能要件（性能、セキュリティ、操作性など）を定義します。この段階では、ユーザーストーリーやワイヤーフレームなどを用いて、実装可能で現実的な設計を目指します。

使われる場面

要件定義は、プロジェクトの要件定義書や仕様書を作成する際に用いられます。クライアントや開発チームとの合意形成の土台となり、以後の設計・実装・テストすべての基準になります。

POINT

・機能だけでなく操作性やパフォーマンスなど非機能面も明確にする
・ユーザー視点と技術視点の両方から妥当性を検証する
・曖昧さを残さないよう図や例を使って仕様を伝える

その他のUX/UIデザイン用語集へのリンク

以下の記事でもUX/UIについて紹介しています。興味を持っていただけましたらぜひご覧ください。

この用語集をPDF版として見たい方は以下よりダウンロードください。

最後に

本シリーズが、みなさまのプロジェクトにおける「共通言語づくり」の一助となれば幸いです。
UX/UIデザインを「難解な専門領域」ではなく、誰もがよりよいプロダクトづくりに参加するための「思考の土台」と捉え、気になる用語や概念があれば、ぜひ実務に照らして深掘りしてみてください。