なぜ、仕様をシンプルにすべきか？ バクラクビジネスカードの開発で見えてきた良いプロダクトの定義
バクラクビジネスカードでプロダクトマネージャーをしている原山です。
バクラクビジネスカードは、利用する“前後”の業務もラクになる、年会費無料の法人クレジットカードです。
社内では仕様を検討している時や、機能開発をしている時に、「仕様をシンプルにしよう」という言葉がよく飛び交います。 弊社のバクラク事業CPO mosaさんの「開発速度が速いとは」という記事でも、仕様をシンプルにすることが重要であると述べられています。
一見すると、機能が多い方がプロダクトとしての価値が高そうに思えます。 しかし実際には、仕様がシンプルな方が良い結果を生むことが多いです。 その理由を、最近自分なりに言語化できたので、発信してみようと思います。
できないことを明確にする
これが最も重要なことです。 なんでもできるプロダクトは、なんにもできないプロダクトと同じです。
機能やカバーできるユースケースを増やすと、お客様のプロダクト仕様への認知負荷も高まります。さらには、それ自体がプロダクトの負債となります。仕様パターンが増えると、バグの温床になってしまうし、今後の機能拡張に対しても負債になる可能性があります。
具体的にどういう形で負債として残ってしまうのか考えてみます。
例えば、最近バクラクビジネスカードで「カードカテゴリ機能」をリリースしました。 この機能は、カードをグループ化して管理するためのフォルダのようなものです。
カードカテゴリ機能を考える上で、カードとカードカテゴリの関係をN:N（多対多）にすることで様々なユースケースに対応できるのではないかという案がありました。
このカードカテゴリ機能は紐づくカードの権限制御とも連動しています。 カードカテゴリ管理者を設定することで、その管理者は紐づくカードの一部の編集権限を与えられます。さまざまな事業部でカードを配布していて、カードを使わないタイミングでのカードステータスを一時的に停止するなど、そういった細かなカードの編集依頼が全体の管理部に集中してしまうと大変なため、各部長に編集権限を移譲して負荷を分散してもらう使い方を想定しています。
カードとカードカテゴリの関係をN:N（多対多）で、1つのカードが複数のカテゴリに属していたとすると、複数のカードカテゴリ管理者からカードが編集されうることになります。
具体例だと、Aさんが兼務をしている方で、Aさんのカードが営業部とマーケティング部両方に所属していて、それぞれの部長がAさんのカードを編集できる状態です。
この時に仮に営業部長はAさんのカードを停止すべきだと思って停止したが、それがマーケティング部の部長に連携されておらずカード利用を再開させてしまう可能性があります。本当はカードが盗難にあったのでAさんのカードを停止したが、マーケティング部長はそれを把握しておらずに利用再開してしまうと、お客様のリスクになってしまいます。このように対応できるユースケースを増やすことで、お客様に仕様の認知負荷を上げてしまい、結果的に使いづらい・わかりづらいプロダクトになってしまったり、カードカテゴリ管理者ができることを今後拡張した時にこの仕様が負債になってしまうということが起きます。
そのため、カードとカードカテゴリの関係性はN:1（多対一）としました。 仮にN:Nにしていたら柔軟性は上がったかもしれませんが、それによってカバーできるユースケースに対して、お客様の仕様に対する認知負荷、DB設計、QAパターン・将来の拡張機能への負債の可能性リスクが見合いません。 そのため、カードとカードカテゴリはN:1とし、カードは一つのカテゴリにしか属せないようにしています。
このカードカテゴリの例は一例ですが、お客様のご要望を叶えるための必要十分な仕様を考えることが、結果的にお客様にとって使いやすいものになると思います。 意思を持ってカバーしないユースケースを決めることが大切です。
各ページにおけるユーザーのメンタルモデルを意識する
ユーザーは各ページで「これをやりたい」というメンタルモデルを持っているはずです。 例えば、それとズレるような動線やボタンが配置されていると、ユーザーは混乱してしまいます。 そのようなズレが積み重なると、「これがやりたいんだけど、どこから操作すれば良いんだっけ？」という状態に陥ってしまいます。
例えば、カード一覧にその月のカードの請求金額があると、カードを確認したり発行しにきているだろうというユーザーのメンタルモデルからズレてしまいます。 そういったものがプロダクトに積み重なると、どこから何ができるかが分かりづらくなります。
あれもこれも詰め込まずに、必要に応じてページを切り分けたり、プライマリーボタンもできるだけ絞ってあげましょう。 お客様にとって余計なことを考えなくて良い、「これがやりたいならこのページに行けば良いんだ！」という体験を一貫して届けることで、仕様がシンプルになり、使いやすいプロダクトになります。
お客様の行動の頻度を意識する
これもメンタルモデルを意識することに近いですが、ユーザーストーリーには頻度があります。 頻繁に行う業務と、月一回程度しか行わない業務があります。 それぞれの業務を行うためのボタンが同じ優先度で並んでいると、押し間違いや、お客様に余計な思考をさせてしまいます。 そのため、画面上も優先度をつける必要があります。
例えばカード一覧画面において、カードの詳細を確認するケースと、カード設定情報を一括変更するケースでは、圧倒的に詳細を確認するケースが多いです。画像の例では一括編集のボタンを常に左上においてPrimaryボタンにしてますが、これだとかなり目立ってしまって一括編集の作業を行わない時でもお客様の視界に入ってしまいます。選択した時だけ表示してあげるなど、画面上でも優先度をつけてあげると、一括編集をしたい時だけ意識することができます。
画面上でも優先度をつけて、お客様の行動頻度に合わせて画面を提供することが大事だなと感じます。（頻度が少なくても、重要な業務はあるのでバランスは大事です。）
最後に
お客様に使いやすいプロダクトを提供するために、こんなことを意識しているよということがあれば、ぜひ教えてください。 バクラク事業部では、一緒に働く仲間を募集しています。 決済事業やプロダクトマネジメントについて、その他なんでも興味のある方、ぜひお話ししましょう！