見出し画像

次に何を直すか迷ったら（1-5／第5回）

drama

プロダクトの改善候補がいくつも並んだとき、どれから手を付けるか迷いませんか？しかも急に「これやって！」と上司から言われたりませんか？

その順番を決める物差しの一つとして、サービスレベルという考え方を提案します。


サービスレベルとは

サービスがユーザーに提供する価値には段階があります。次に何をやるべきかを決めるとき、この段階を意識すると意思決定の精度が上がります。

ここでは、深津さんの note「サービスに求められるものを、6段階に分類する」で示した6段階を借りて解説します。賃貸住宅を例にした元記事の説明がとても分かりやすいので、詳しくはぜひ原典を読んでみてください。

また、その6段階をソフトウェアのプロダクトに置き換えて整理してみました。

6つのレベル

Lv6. 生きがいとか人生とか = 使うこと自体が日々の張り合いになる
Lv5. 嬉しい・楽しい・美しい = 手触りや見た目に気持ちが動く
Lv4. 快適・生産性UP = なくても困らないが、あると嬉しい
Lv3. 使いやすい・わかりやすい = 迷わず操作でき、説明がなくても目的にたどり着く
Lv2. 安全と安心 = 落ちない。データが消えない。不正に使われない
Lv1. 機能がある = やりたいことが一通りできる

当たり前に使えると感じるようなことはLv3くらいまでにあり、このプロダクトが良い！と思えるようなことはLv4以降です。このLv4以降にプロダクトの独自価値があります。
基礎がないといけないという上では、マズローの欲求段階に近い考えです。

下のレベルから積み上げる

世の中の多くのサービスは低いレベルは満たされた状態なので、ユーザーに満足してもらうには、まず前提部分である下から順番に積み上げていく必要があります。
下のレベルが崩れているのに上のレベルの施策を打っても、ユーザーには届きません。

例: 家計簿アプリの改善候補

例えば、家計簿アプリで次の3つが改善の候補に挙がっているとします。

A. 画面デザインの刷新 = Lv5
B. 銀行との連携が週に数回失敗し、残高がずれる不具合の修正 = Lv2
C. グラフの切り替えを1タップ減らす = Lv4

要望として目立つのはAかもしれませんが、Bが直っていないと、家計簿の数字そのものが信用されません。新しいデザインで開いた画面の残高が合っていなければ、ユーザーは離れていきます。なので、基本的な優先順は B → C → A になりそうです。

迷ったときは、候補をレベルに当てはめ、それより下の段に未解決のものがないかを先に確かめます。

身近な開発だと、チュートリアルやメインのフローが成り立っていない状態で、課金施策やイノベーション的な施策を行っても、その効果が十分に発揮できないかもしれません。施策自体が良いものであっても、前提が不足していたことにより失敗と判断されてしまうこともあるでしょう。

レベルを決める基準

サービス品質を目標化したものを SLO、その目標を顧客等と合意したものが SLA といいます。
例えばLv2の「安全と安心」レイヤーでは、稼働率や障害からの復旧時間などがよく設定されます。これらを定めることは、どこに注力しているかを関係者と認識合わせする上でも有効です。

また、Lv3の「使いやすい・わかりやすい」は、長くプロダクト側の裁量でしたが、ここには現在、法律による下限があります。
例えば2024年には改正障害者差別解消法で、民間事業者にも合理的配慮の提供が義務づけられました。EU向けには2025年からはEuropean Accessibility Act も適用されています。

今後、アクセシビリティは付加価値ではなく土台側だと考えておく必要がありそうです。

これらを踏まえ、どこまでを下限とするかはプロダクトの状況によりますが、複数施策のどれが下のレベルかは判断できると思います。
優先度に悩んでいたら、改善内容が下のレベルの内容であるほど、プロダクトの品質を根本から揺るがす可能性があるので、基本的には優先度を高くしてください。
それでも、上司から「これやって！」と言われたら断れないとは思いますが、そのときは断るのではなく、レベルの図を見せて「先にBを直さないと、Aの効果が十分に出ません」と順番の話をしてみましょう。
また、上のレベルを狙う場合は下からの積み上げが成り立っているかを確認しましょう。その方が十分に効果を発揮できます。

より細かなユーザー理解やSLO/SLAについては以降の回で書きます。

まとめ

  • サービスレベル = サービスが提供する価値の段階

  • 土台が崩れていると上は届かないので、なるべく下から片付ける

  • レベルの基準は時代や環境によって変化する

次回は、今回のような内容をどこまでシステム化するか、その判断基準について解説します。

参考文献

6段階の名称は上記の記事によります。各段の説明は、ソフトウェアのプロダクトに置き換えて本連載で書き起こしたものです。

「プロダクトマネジメントわかりたい」

プロダクトマネジメントに関するnoteを週2ペースで連載してます。
よければ記事に対するリアクションや疑問、感想いただけると嬉しいです！

いいなと思ったら応援しよう！