新規事業などでスピード感を持って開発を進めたい場合や、価値検証のためのMVP（Minimum Viable Product：価値提供可能な最小限のプロダクト）を開発する場合は、必要な機能から優先的に開発したり、開発を進めながら仕様を変更していくことが求められます。このようなアジャイル開発において、仕様書をどのように作成すれば良いか悩む方は多いのではないでしょうか。

この記事では、ユーザー体験を軸に仕様を定義し、スピーディーに開発を行っていくための仕様書「UI Spec」の内容とGoodpatchのプロジェクトでの活用例をご紹介します。

ユーザー体験を軸にした開発仕様書「UI Spec」

UI Specとは

UI SpecとはUI Specification（ユーザーインターフェース仕様）の略です。一般的な仕様書は画面ごとに機能要件を記述するのに対してUI Specが異なる点は、ユースケースをベースにしている点です。

ユースケースとは
ユーザーが実際にどのようにサービスを使用するかを示したものです。「ユーザーがプロフィール情報を入力する」など、誰が・なにを・どうするかを端的にまとめて整理します。このユースケースをベースに仕様書をかくことでユーザー体験をベースにした開発を実現しました。

UI Specには以下のような利点があります。

  • ユースケースをベースにするので機能単位で仕様が分散せず、ユーザーに届けたい価値の共通認識を持って開発を進めることができる
  • ユースケースに対して優先順位をつけることで、ユーザーにとって必要な機能をもったプロダクトを素早く開発できる

また、UI Specは開発途中での仕様の追加や変更を前提にしています。開発中に生じた変更点や変更理由をUI Spec上に追記することで、仕様がなぜ・どのように変更されたかをチーム内で共有することができます。そのため、UI Specは単なるドキュメントとしてだけではなく、デザイナーやエンジニアのコミュニケーションを記録するツールとしても有用です。

スプリントが終了して次のスプリントに進むタイミングや、ある程度プロダクトが完成しチーム内でレビューを行う際、UI Specを参照することでユースケースに沿って実装されているかを確認することができます。

Goodpatchのプロジェクトでの活用例

ここからは、Goodpatchのデザインパートナー事業で実際にUI Specを用いてアジャイル開発を行った事例をご紹介します。

プロジェクトの概要

今回ご紹介するのは、新規サービスの開発をリサーチ・企画からデザイン、開発まで一貫して支援するプロジェクトです。

概要 スマートフォンアプリのMVPの開発（iOS/Android）
開発期間 2022年2月〜6月（5ヶ月間）
体制 Goodpatch：UXデザイナー・UIデザイナー
デザインパートナー：エンジニア

作成手順

今回のプロジェクトでは、以下の手順でUI Specの作成し開発を行いました。

    1. ユースケースを作成（UXデザイナー）
      ユーザーがどんな目的で行動し、その結果どのような反応や状態になるのかという一連の体験の流れをシナリオ化した後に、ユースケースを洗い出しました。この後の工程の基礎となるため、時間をかけて定義していきます。
    2. プロトタイプを制作（UIデザイナー）
      1で作成したユースケースを元にオブジェクトモデリングを行い、プロトタイプを作成。また、この段階でユーザーテストを行い、プロトタイプの質を高めることに取り組みました。
      参考：オブジェクトモデリング入門編！SmartHRでOOUIワークショップを開催しました
    3. 開発の優先順位づけ（UXデザイナー・UIデザイナー・エンジニア）
      提供したい価値やユーザーニーズの優先度も考慮しながら、ユースケースごとに開発優先度を決定。見積もり時に開発コストを考慮し、場合によってはユースケースをさらに分割しました。
    4. UI Specを作成（UXデザイナー・UIデザイナー）
      ユースケースとプロトタイプを合わせてUI Specを作成。UI画面上の細かい仕様をUI Specの項目に沿って定義していきました。
    5. UI Specレビュー（UXデザイナー・UIデザイナー・エンジニア）
      作成したUI Specをチーム全員でレビュー。エンジニア視点で考慮が必要な観点はここで補足しました。
    6. スプリントプランニング（エンジニア）
      決定した優先順位を元にスプリントを計画。優先順位をつけた後に技術的観点や工数的観点をもとに対応順の調整も行いました。
    7. スプリント開始（エンジニア）
      スプリント計画に沿って実装を開始。

UI Specの作成例

プロジェクトで実際に作成したUI Specのサンプルをご紹介します。

UI Specのサンプル


UI Specに記載する主な項目

ユースケース 該当するユースケースを記載
関連するユースケース 他のユースケースとどのように関連するかを記載
提供したい価値 該当するユースケースがユーザーにどんな価値を提供するかを記載
検証項目 そのUI Specに含まれる画面や機能で何を検証したいかを記載
UI画面 画面名を記載・該当するUI画面を埋め込み
仕様 ・表示方法
・表示件数
・表示順列
・文字数
・遷移元/遷移先
・アラート/エラー/バリデーションの有無および対応
・入力形式
・タップエリア
・タップ時フィードバック
・挙動
・そのほか
※具体的な内容はサンプル画像に記載
関連するロジック データの扱いに関する内部仕様もUI Spec上で把握できるように、画面に現れないプロダクトの機能の詳細なロジックを記載

UI Specに記載する項目はプロダクトの特徴やチームの体制によって柔軟にアレンジできます。不要な情報が膨大に記載されるなどに注意し、最低限必要な項目を押さえた上で工夫してみましょう。

UI Specを活用することで実際に得られたメリット

確認漏れを防げた
作成したUI SpecはNotionで管理しました。開発優先度順に並べて、スプリントの進捗状況と紐付けてステータス管理を行うことで確認漏れを防ぎます。
Figmaで作成したデザインファイルとUI Specにそれぞれの該当するリンクを貼ることで、開発時の確認をスムーズにし画面の考慮漏れを防ぐことができました。

UI Specごとに仕様変更の経緯を漏れなく共有できた
開発時やレビュー後に仕様変更が行われた場合は、決定事項・変更日・なぜ仕様の変更を行ったのかをUI Spec上に記載しました。そうすることで同じ箇所を何回も検討したり、変更箇所の意図がわからなくなったりすることを防ぐことができます。

ユースケースに沿った開発成果物レビューが可能
開発成果物のレビュー時に、UI Specを参照しながら仕様通りに開発できているかを確認しました。QAテストもUI Specのユースケースをベースにテストシナリオを作成することで、漏れなく実際のユーザー行動に沿ったテストを実施することができます。

サービスの価値の共通認識を持って作成できた
UIデザイナー・UXデザイナー・エンジニアなどチームメンバーの全員がUI Specを作成・確認しながら開発を進めることで、なぜこの機能を作るのか、ユーザーに届けたい価値は何かを、それぞれの役割から同じ目線で考えることができました。

このように、UI Specは一時的なドキュメントではなく、プロダクト開発全体を通してユーザー体験を担保するために役立てることができます。

UI Specを活用したチームの声

実際にUI Specを用いて開発を行ったメンバーの感想を抜粋します

機能単位で仕様がばらばらにならないので、何を作っているのか自分たちでも常に認識しやすい（Gp・UXデザイナー）

ユースケースに紐づけて整理することで、UI上で達成したいことが明確になり、それが開発メンバーにも伝わりやすくなる（Gp・UIデザイナー）

ユースケースや提供価値など、なぜそのようなデザインや設計になっているかがはっきりしているので、プロジェクト全体で迷いが少ないのが良い（デザインパートナー・エンジニア）

まとめ

今回は、ユーザー体験を軸に仕様を定義し、スピーディーに開発を行っていくための仕様書「UI Spec」の内容とGoodpatchのプロジェクトでの活用例をご紹介しました。繰り返しになりますが、UI Specには絶対的に決まったやり方というものはありません。プロジェクトの体制やプロダクトの特性によって手順や内容をアレンジし、最適な方法を模索していくことが重要です。

Goodpatchでは、新規サービス開発やプロダクトのリニューアルをアイデア創出から開発まで一貫して支援しています。Goodpatchとの共創に興味を持たれた方は、ぜひお問い合わせいただきより詳しくお話しできればと思っています。まだやることが決まっていない段階でのディスカッションなども大歓迎です！

[共同投稿者] 児玉彩、山下由希、水野有稀、天野麻由

お問い合わせはこちら

Share on

水野 有稀
デザインと経営について関心を持ち勉強中のインターン生。2021年4月にUXデザイナーとして新卒入社予定。