サービスデザインの成果を開発につなげる

三越伊勢丹のサービス開発において重要な要素となる「デジタルサービスデザイン」について、これまで3回に渡って紹介してきました。サービスデザインを行ったら、その成果を開発チームに伝えていく必要があります。
「デジタルサービスデザイン」って何？（第1回 バリュープロポジションキャンバス）
「デジタルサービスデザイン」って何？（第2回 ユーザーエクスペリエンスマップ）
「デジタルサービスデザイン」って何？（第3回 サービスブループリント）

- IM Digital Lab（アイムデジタルラボ） ホームページ
- 婦人靴向けパーソナルフィッティングサービス YourFIT 365
- 紳士靴向けパーソナルフィッティングサービス YourFIT 365 Men's

■エピックに分割する

サービスデザインの記事で紹介してきたようにサービス開発においては、バリュープロポジションキャンバスやユーザーエクスペリエンスマップを使ってターゲット顧客や提供価値を明確にし、顧客体験の大まかな流れを整理します。そして、アーキテクチャと顧客体験をデザインするためにサービスブループリントを作りました。

IMDLではスクラム開発を採用しているため、これらの成果を段階的に詳細化していく必要があります。まず、サービスデザインによって大きな流れが整理できたら「エピック」という単位に分割します。この単位で具体的な開発作業に落としていくための詳細化を行います。エピック（epic）を辞書で引くと「叙事詩」と出てきますが、神話や伝承などを物語として記述したものを意味します。転じてエピックは「顧客がプロダクトやサービスを利用した体験や価値を、ある程度の大きさで記述したもの」をしめします。

YourFIT 365ではリリース後にフィードバックを受けて以下のようなエピックが出てきました。

・レコメンド精度改善のためのデータ収集
・適合度の表示
・購入商品に基づく新作商品ご紹介
・担当者・メモの履歴管理
・メンズ館ビジネスシューズ売場でのサービス提供

エピックは「現状の課題」「実現したいこと」「期待できる効果」という3つの情報を整理し、エピックの価値を分かりやすくします。例えば「レコメンドロジックの精度改善のためのデータ蓄積」だと以下のよう記述しました。

Epic1.レコメンド精度改善のためのデータ収集

■現状の課題
レコメンドされた商品をお客さまが試着された際、実際にはお客さまの足に合わないケースが発生している。ただ、具体的にどういったケースでレコメンド商品がお客様の足にフィットしないのかが不明確なため、どのようにレコメンドロジックを見直すべきかがわからない。そのため、レコメンドされた商品をお客さまがご試着された際のフィッティング結果を収集して分析、レコメンド精度を向上させていく必要がある。

■実現したいこと
スタイリストが、接客中に靴とお客様の足のフィッティング度合いを客観的な視点かつ共通の観点でレビューすることで、レコメンドロジック全体の精度を改善するためのデータを収集したい。

■期待できる効果
レビューデータを収集してそのデータを分析することで、レコメンドロジックの修正箇所を検討することが可能となる。結果、お客さまへのレコメンド精度が高くなる。

■エピックに優先順位をつける

エピックをすべて同時に解決していくことはできないので、エピックに優先順位付けをおこない、開発順を決めます。優先順位を決める上でもっとも重要なのは、そのエピックによってもたらされるビジネス価値です。実際にYourFIT 365で行なった改善を例に挙げてみます。

ビジネス価値で評価すると以下の様な順になりました。
1.レコメンド精度改善のためのデータ収集
2.購入商品に基づく新作商品ご紹介
3.適合度の表示

1.レコメンド精度改善のためのデータ収集は、足形に適合した靴をレコメンドする精度を改善させる取り組みです。2.購入商品に基づく新作商品ご紹介は、YourFIT 365で購入したお客様に対して足に合う靴を紹介するというプロモーション機能です。3.適合度の表示は、レコメンド結果の靴に適合度を表示するというものです。リリース当初、一定上の適合度のものは全て表示する仕組みにしていますが、それでは表示される件数が多すぎて逆に迷ってしまうという課題がありました。

しかし、実際に開発を行った順番は以下のように、まったく逆です。
3.適合度の表示
2.購入商品に基づく新作商品ご紹介
1.レコメンド精度改善のためのデータ収集

まず、1.レコメンド精度改善のためのデータ収集については、レコメンド結果に対して、実際にお客様の足と適合したのか、というデータを収集する必要があります。しかし、そもそも、どのようなデータを収集すればいいのか？から検討が必要でした。そのためビジネス価値は高いものの開発着手は最も遅くなりました。別の開発をしながら以下のようなことを検討していたのです。
・レコメンド精度の改善に必要なデータは何か
・そのデータを、どのように収集するか

2.購入商品に基づく新作商品ご紹介についてはタイミングの問題で開発優先度を下げました。YourFIT 365がスタートしたのは8月なので購入対象は秋物です。よって次に新作が多く揃うのは冬物が売れてくる11月です。そこまで待たなくては効果検証が正しくできないと判断し、そのタイミングに合わせて開発をすることにしました。

一方で、3.適合度の表示については表示方法を検討すれば良いだけだったので、お客様の反応を元に整理をして、すぐに開発に着手することができました。

このように機能の優先度というのはビジネス上の価値だけではなく、その機能の仕様の確定度や、価値が出るタイミングを意識して決定していくのです。

■プロダクトバックログに分割する

エピックを具体的な開発タスクに落とし込んだものが「プロダクトバックログ」になります。エピックは「顧客価値」（顧客への提供価値）寄り、プロダクトバックログは「機能の利用方法」（プロダクトの使い方）寄りの情報になります。

「レコメンド精度改善のためのデータ収集」であれば

・スタイリストが靴のフィッティング度合いをレビューする
・レビュー結果を収集する

と分解すると、具体的に開発すべき機能が見えてきます。さらに実際の開発を進めるにあたっては、ワイヤーフレームや以下のような詳細な受入条件を設定します。

・商品詳細画面のレビューアイコンをタップしたら、レビュー入力画面が表示されること
・レビュー入力画面には、以下の項目が表示されること
　- サイズ名（プルダウン）
　- 足形画像（L、Rアイコンとレビューポイント含む）
　- カルーセル
　- 「登録する」ボタン
　- 「閉じる」ボタン
・「登録する」ボタンは非アクティブ状態で表示されること
…など

その後の流れはスクラム開発のイベントに従います。POと開発チームはスプリントプランニングを行い、作成したプロダクトバックログを見ながら、スプリントバックログを作成し、スプリントを回していくことになります。

■まとめ

今回は具体的なプロダクト開発のフェーズに入るための「エピック」への分割とその優先順位付け、さらに「プロダクトバックログ」にしていく流れについて説明しました。これによってサービスデザインの成果をきれいに開発チームに伝えていくことができるのです。

最後までお読みいただき、ありがとうございました！