私の仕様レビューのやり方(抽象的な観点から指摘事項を導くまでの具体例)

仕様レビュー時のプロセス、マインド、観点リストはWeb上などでも多く文献を見かけます。ただ、私の経験上、抽象的な観点リストがあっても観点から具体的な指摘事項を洗い出せるか否かは比較的属人化していました。 そこで、本記事では、いくつかの属人化しがちと感じた観点について、私が仕様レビューを行う際の思考過程を紹介します。 *1

本記事では、自社が運営するメンズファッションのECサイトにおける追加開発のプロジェクトで仕様レビューを行なっていきます。 重厚な要件定義書や基本設計書などがない現場という前提で*2、プロジェクトの仕様レビュー時に与えられた情報は以下の通りです。

  • ECサイトのトップページの上部に「おすすめのアイテム」という枠を新たに追加する
  • 「おすすめのアイテム」枠には、DBの販売開始日の新しさ上位3点の商品、サイト運営者が選んだ定番商品3点を表示する
  • 「おすすめのアイテム」枠に表示する内容は1時間毎に更新(商品一覧を返すAPIはレスポンス内容を1時間キャッシュする)
  • 「おすすめのアイテム」枠の下のエリアには、元々トップページに表示していた「トップス」「ボトムス」「その他」というカテゴリ毎の商品を、注文数の多い順に6点ずつ表示する(仕様変更なし)

f:id:kawabeaver:20211103231645p:plain
トップページのUI(「ボトムス」「その他」カテゴリの記載は省略)

上記を見てツッコミどころがたくさんあるとウズウズしている方は、ぜひ本記事を読む前に仕様レビューを実施して指摘事項を考えてみてください。 その後、本記事を読んだ皆さんが新たな指摘に気づけるようになったのであれば、本記事は成功です。 それではレビューをしていきます。*3

目次

観点:仕様の方向性が正しいか

まずは、このプロジェクトがそもそも顧客の役に立つか、顧客の課題を解決する手段として適切か否かを確認します。 事業者側の視点でいうと「トップページで販売開始日が新しい商品や定番商品を目立たせたら本当に利益が増えるのか」という点の確認です。

サービスに関係するステークホルダーと要求を洗い出し

ステークホルダーと要求を洗い出す理由は以下の2つです。

  • プロジェクトが解決したい顧客の課題を知る
  • プロジェクトが各ステークホルダーに悪影響を及ぼす可能性の判断材料にする

私はECサイトに詳しくないですが、本プロジェクトに関係するステークホルダーは、仮で以下のようにします。*4

分類 ステークホルダー 要求の例
サイト訪問者 オシャレさん 次シーズンの流行の新作商品を買いたい。オシャレだと思われたい。新しい服を着て満足感を得たい
機能性重視さん 現シーズンの不足した服を買い足したい。流行は気にしないが、ダサいとは思われたくない
価格重視さん 安くなった商品を買いたい。お得な買い物をしたという満足感を得たい
プレゼント探し中さん 喜んでもらえるプレゼントを買いたい。プレゼントは予算以内に収めたい
ウィンドウショッピングさん 良い商品を眺めて楽しみたい。実際に商品を購入するつもりはない
サイト運営者 商品の販促を行う人 自分の施策によって売上を伸ばしたい。定番商品の設定に手間をかけたくない
在庫管理を行う人 在庫切れや余剰在庫を避けたい
発送業務を行う人 会社規定の営業日までに発送業務を完了したい
事業責任者 売上を伸ばし、コストを抑えて利益を増やしたい
配送業者 商品の配送を行う人 指定された日時までに配送を完了したい
経営者 人手不足の中でうまくやりくりしたい

プロジェクトのターゲットが要求を満たすまでのプロセスの洗い出し

プロジェクトで解決したい課題を特定するために、顧客が要求を満たすまでのプロセスを洗い出します。

今回はECサイトの追加開発なので、サイト訪問者がサイトを訪問してから商品を手に入れて満足するまでのプロセスを洗い出します。

  1. サイト訪問者が何らかの流入経路でサイトに訪問する
  2. サイト訪問者が商品を探す
  3. サイト訪問者が購入したい商品をカートに入れる
  4. サイト訪問者がカート内の商品を注文をする
  5. サイト運営者が商品を発送する
  6. 配送業者が商品を配送する
  7. サイト訪問者が商品を受け取る
  8. サイト訪問者が商品の品質に満足する

プロジェクトで解決したい課題の特定

今回のプロジェクトは、ECサイト上で新しい商品と定番商品を目立たせることで、「サイト訪問者が商品を探す」際の「商品の探しやすさ」という課題の解決を目指します。

仕様は課題の解決策として適切かを確認

サイト訪問者の要求と照らし合わせ、仕様が課題の解決策として適切かを確認していきます。

今回のプロジェクトでいうと、各サイト訪問者が欲しい商品を探しやすくなるか否かを確認します。

サイト訪問者 仕様と要求とのマッチ度
オシャレさん 「次シーズンの流行の新作商品を買いたい」ので、新しい商品を目立たせると欲しい商品を探しやすくなりそう
機能性重視さん 「現シーズンの不足した服を買い足したい」「ダサいと思われたくない=ダサくない服が欲しい」ので、定番商品として表示する商品次第では欲しい商品を探しやすくなりそう
価格重視さん 「安くなった商品を買いたい」ので、セール品がわからない本プロジェクトでは欲しい商品を探しやすくならない
プレゼント探し中さん 欲しい商品を探しやすくなるかは、プレゼントの予算とプレゼント相手の好み次第

今回のプロジェクトは、全サイト訪問者が欲しい商品を探しやすくなるわけではないようです。 そのため、本プロジェクトがどの程度利益を生み出すかを予測するには、ECサイトにアクセスしている各サイト訪問者の割合などが重要になってきます。

仕様が課題を解決しても悪影響が出ないかを確認

サービスのステークホルダーが多くいる場合、1つのステークホルダーの課題を解決すると他のステークホルダーに悪影響を及ぼす場合があります。 そのため、他のステークホルダーへの悪影響が出ないかを確認します。悪影響が出る場合は、何らかの対策を検討します。もしA/Bテストを行う場合は、他のステークホルダーへの悪影響の大きさも観測します。

修正する画面の他のコンテンツへの悪影響を確認

画面を修正する場合、修正の影響で同じ画面内の他コンテンツが閲覧しにくくなったり使いづらくなることがあります。

今回のプロジェクトではトップページに新たなコンテンツを追加します。そのため、追加したコンテンツより下の「カテゴリ毎の商品」はサイト訪問者が閲覧しにくくなります。 そのため、「おすすめのアイテム」枠の商品に興味がないサイト訪問者にとっては、UXが悪化するプロジェクトになります。

他プロセスへの悪影響を確認

プロジェクトがサービスの部分最適の内容となり、サービス全体として最適ではない結果を生み出す場合があります。 そのため、プロジェクトがサービスの他のプロセスに及ぼす影響を考えます。

今回のプロジェクトでは、以下のような悪影響の可能性が考えられます。

ステークホルダー 考えられる悪影響
商品の販促を行う人 定期的に定番商品を更新するプロセスが増える。その結果、他の施策を行う工数が減少する
在庫管理を行う人 目立つ「おすすめのアイテム」枠の商品のみ過剰に注文される。その結果、当該商品の在庫切れが発生する、他商品の在庫が余る
発送業務を行う人 「おすすめのアイテム」枠の表示内容が更新されるタイミングに注文が殺到する。その結果、発送作業に遅延が発生する
事業責任者 注文される商品の偏りや注文タイミングのムラが生じる。その結果、余剰在庫や余剰リソースなどのコストが発生する
商品の配送を行う人 「おすすめのアイテム」枠の表示内容が更新されるタイミングに注文が殺到する。その結果、配送作業に遅延が発生する

顧客の可処分時間の奪い合いがないかを確認

あるコンテンツを追加した結果、顧客がより利益を生み出すコンテンツに割く時間を奪ってしまう場合があります。

今回のプロジェクトでは、説明のための無理やりな解釈ですが、価格重視さんが「おすすめのアイテム」枠を見てウィンドウショッピングさんに変わり、そのまま寝る時間となってサイトを離脱してしまうといったことが考えられます。*5

観点:仕様が課題解決の方法として合理的か

仕様の方向性が正しいとして、仕様が課題解決に対してどの程度インパクトを出せるかを確認します。

本プロジェクトで言えば、「おすすめのアイテム」枠を表示することでどの程度サイト訪問者が商品を探しやすくなるか、もっと良い仕様がないかを確認します。

新しい仕様によって課題を解決するまでのプロセスを細かく洗い出す

前述の「商品を探す」という抽象度の高いプロセスだと仕様の合理性を判断しにくいため、更にプロセスを細かく洗い出します。

プロセスを洗い出す際は、顧客の操作だけではなく、顧客の思考内容も洗い出します。

  1. トップページにアクセス
  2. 「おすすめのアイテム」枠を見つける
  3. 「おすすめのアイテム」枠は自分の欲しい商品が表示されると期待する
  4. 「おすすめのアイテム」枠の商品を見つける
  5. 商品が欲しい商品かもしれないと認知する
  6. 商品画像をタップする
  7. 商品詳細ページの情報を確認する
  8. 商品が欲しいと思い購入を決める

仕様のプロセスが顧客の行動とマッチするかを確認

新しい仕様のプロセスが顧客が普段行なっている行動と異なり、新しい仕様のプロセスが使いづらい場合があります。

例えば、私は服を選ぶ際は衝動買いをすることはほとんどなく、いくつかの商品を見比べてから購入する商品を選びます。 そのため、私が仮に新作商品を選ぶ場合は、新作商品をより多く表示していた方がECサイトを使いやすいと感じるかもしれません。

仕様のプロセスごとに合理性を確認

仕様のプロセスが顧客の行動とマッチするとして、各プロセスにおける仕様の合理性を確認します。

例えば、次シーズンの流行の新作商品を買いたいオシャレさんがサイトを訪れた場合の仕様の合理性の確認結果は以下のようになります。

プロセス 合理性の確認結果
1. トップページにアクセス
2. 「おすすめのアイテム」枠を見つける 「おすすめのアイテム」枠が目立たないので、もう少し目立つようにしても良いかも
3. 「おすすめのアイテム」枠は自分の欲しい商品が表示されると期待する 「おすすめのアイテム」という名前から新作商品が表示されていると判断しにくいので、「新作商品」枠と「定番商品」枠で分けた方が分かりやすくないか。
4. おすすめのアイテム枠の商品を見つける
5. 商品が欲しい商品かもしれないと認知する 新作商品がどれかわからないので、NEWアイコンをつけたらどうか。服を選ぶときに商品名は気にしないので、不要ではないか。カラーバリエーションも知りたいので、カラーバリエーションも表示したい。
6. 商品画像をタップする 商品画像が小さくてタップしにくそうなので、タップできる領域を改善した方が良いかも
7. 商品詳細ページの情報を確認する トップページの商品画像が小さくて商品詳細ページの大きい画像を見た時に「素材感が思っていたものと違う」となるかもしれない
8. 商品が欲しいと思い購入を決める

観点:仕様が入力やデータなどのパターンを網羅しているか

仕様に記載されているロジックの抜け漏れを確認します。作業内容はテスト設計時にテストする条件を洗い出す作業と概ね同じです。

仕様に関係する入力やデータなどのパターンの洗い出し

仕様に関係する入力やデータなどのパターンをドメイン知識や同値分割や境界値分析といったテスト技法を用いて洗い出します。ここで私が一番気をつけているのは 仕様に記載されたロジックのパターンを網羅するだけでなく、仕様に関係する入力やデータのパターンを仕様に記載されたロジックに関係なく洗い出す ということです。仕様に記載されたロジックは不完全な場合があるので、仕様に記載されていることだけ網羅すると仕様の抜け漏れに気づきにくくなります。

本記事では主に商品に関する入力やデータが問題になりますので、以下のように洗い出します。

データ

データ テストする条件の例 仕様の指摘事項の例
商品の種類 トップス、ボトムス、その他 その他商品はシーズンとは無関係なので「おすすめのアイテム」枠に新商品として表示するとオシャレさんの要求を満たさなくなる。表示させないようにすべき
商品の在庫 なし、あり 在庫なしの商品は「おすすめのアイテム」枠に表示すべきではない
商品の販売開始日 昨日、今日、明日 販売開始日が未来の商品は「おすすめのアイテム」枠に表示すべきではない
商品の販売最終日 昨日、今日、明日 販売最終日が過去の商品は「おすすめのアイテム」枠に表示すべきではない
販売中の商品数 3件未満、3件、4件以上 販売中の商品数が3件未満の場合は「おすすめのアイテム」枠の表示内容はどうする?
商品の定番商品設定 なし、あり 販売開始日が最新、かつ、定番商品設定ありの商品がある場合は「おすすめのアイテム」枠の表示内容はどうする?
定番商品の商品数 0件、1件、3件未満、3件、4件以上 在庫なしの商品は「おすすめのアイテム」枠に表示すべきではない
商品名 最小文字数、最大文字数 長い商品名でも省略表示しなくて良い?
商品画像 なし、あり 商品画像なしの商品は「おすすめのアイテム」枠にどのように表示する?

入力

入力 仕様の指摘事項
注文して在庫切れになる 「おすすめのアイテム」枠の表示内容が即時更新されるか(キャッシュがクリアされるか)
商品の作成 「おすすめのアイテム」枠の表示内容が即時更新されるか
商品の販売開始日の更新 「おすすめのアイテム」枠の表示内容が即時更新されるか
商品の削除 「おすすめのアイテム」枠の表示内容が即時更新されるか
商品の定番商品設定の更新 「おすすめのアイテム」枠の表示内容が即時更新されるか
時間経過(販売開始日になる、販売終了日翌日になる) 「おすすめのアイテム」枠の表示内容が即時更新されるか

上記は必要に応じて更にデシジョンテーブルを使って組み合わせを考えても構いません。

想定ユーザーに応じた操作の洗い出し

仕様を考える際は、開発側の期待通りに操作してくれるユーザーが前提となっていることが多いです。そのため、期待通りに操作しないユーザーの行動を想定しておく必要があります。

例えば、以下のようなユーザーです。

ユーザー 想定される操作の例
うっかりさん 操作を忘れる、操作ミスをする、操作内容をあとで訂正したくなる
せっかちさん 説明を読まない、ボタンを連打する、ブラウザバック
悪意のある利用者 ブラウザを複数立ち上げて同時操作、URLを改ざんして直接アクセス、1回だけしか利益が得られないことを複数回実施しようとする
攻撃者 システムの脆弱性に対する攻撃、ブルートフォースアタック
親のスマホを勝手に触る幼児 勝手に課金してしまう*6、勝手にデータを削除してしまう

本記事のプロジェクトでは問題とならなそうですが、他の事例だと例えば以下のようなものが考えられます。

  • 注文内容確認画面から各情報を編集する画面に遷移できるようにする
  • ボタンをクリックするとボタンを非活性化させて二重にクリックできないようにする
  • 幼児が課金処理を行っても処理から24時間以内ならばキャンセルできるようにする

データ更新処理の重複の可能性を洗い出し

Webでは、あるユーザーが参照・更新しようとしているデータを他のユーザーやバッチ処理が更新することがあります。

本記事のプロジェクトでは問題とならなそうですが、他の事例だと例えば以下のようなものが考えられます。

  • 在庫が1個の商品を2人のユーザーが同時にカートに入れて決済処理を行った場合に、一方はエラー画面に遷移させなければならない
  • 販売最終日にカートに入れて購入フローを操作中に日付が変わった場合、エラー画面に遷移させなければならない

おわりに

本記事を書いてみた感想として、私の思考過程は以下のことをやっているようでした。

  • 新たな仕様で解決したいことを特定する
  • レビュー対象を細かく分解して仕様の是非を考える
  • レビュー観点をより具体的な観点に分解して仕様の是非を考える
  • レビュー対象より上のレイヤーでも仕様の是非を考える
  • 記載されている仕様より広い視点でも仕様の是非を考える

レビュー観点のリストを運用して上手くいかない場合は、上記を試してみてると良いかもしれません。

UX、デザイン、ユーザビリティについてまだまだ勉強不足なので、より良い仕様レビューのやり方が見つかれば改めて記事を書きたいと思います。

思いの外長文になってしまいましたが、最後まで読んで下さりありがとうございました。

参考文献

レビューに関する資料

私の思考過程に影響したもの

*1:仕様レビューという言葉が曖昧なので、本記事の内容を皆さんの現場のプロセスに当てはめて考えてください。

*2:私が重厚なドキュメントのある現場での業務経験がないため

*3:なお、本記事中の指摘内容の適切さは本記事の主題ではありません。

*4:1人で複数タイプのステークホルダーになる可能性があります

*5:ウィンドウショッピングが長期的に見て利益を生み出す可能性はあります

*6:私はワンタップで有料会員になる導線のあるアプリで経験済み