見出し画像

ウェブサービスに向けた多くのユーザー要望、どれから取り組む？

こちょう（古長克彦）

マネーフォワード クラウドはおかげさまで多くのユーザー様にご利用いただいています。お客様の属性は、個人事業主の方からエンタープライズ企業まで幅広く、抱える課題も様々です。

マネーフォワード クラウドはSaaSという性質上、課題の異なるユーザー様のご要望にすべて応えることは難しいですが、一方で、多くのユーザー様のメリットになるご要望は、短期間で少しづつ改善することが可能です。

現状では、セールスやカスタマーサクセスを中心に、利用中または導入検討中のお客様から日々いただくご要望をストックし、各プロダクトチームで次のリリースタイミングに取り入れる改善を検討します。

システム開発における改善判断は、一般的に「現在のシステムに影響も開発コストも少ないものから」となりがちです。それ自体は間違いではないですが、その改善がユーザーにとってどれだけの価値があるか議論されないまま決まってしまうこともあります。

そんな時、デザイナーこそが率先してユーザー価値を基準に改善の優先度を決めるのが理想です。今回は、ユーザーのご要望からユーザー価値を図り改善優先度を決める手順を説明します。

1. 要望の声から本来の課題を導く

ユーザーからのご要望は、現サービスを使っている中で感じた不便さからくるものが多いため、直接的な解決手段がよく挙がってきます。例えば、以下のようなご要望です。

  • 入力画面の項目Aにチェックを入れ忘れてしまうので、最初からチェックありの状態にしてほしい

  • 一覧画面で期限が近いデータを探したいので検索条件で期間を指定できるようにしてほしい

  • 一部の人にしか見えないデータの状況が変わったら全員に通知してほしい

  • まとめてデータを変更することがあるので一覧画面で項目Bの一括変更する機能がほしい

  • 現在のエラー文章だとどうすればいいか分からないと問合わせが多く、補足情報を一緒に表示してほしい

しかし、これらの要望をそのまま対応することが、本当に根本的な解決になるでしょうか。ユーザーがそのように考えた背景をもう少し深ぼっていくと、本来の課題が見えてきます。

  • そもそも、業務の性質がまったく違うにも関わらず、入力画面のチェックの有無で切り替えるようになっていることが問題

  • そもそも、ユーザーが能動的に期限の迫っているデータを探しにいかなければいけないことのほうが問題

  • そもそも、全員に見えても問題ないデータなのに一部の人にしか見えないのが問題

  • そもそも、全体的な変更のしにくさが問題（一括変更は、組織変更が起こる期末期初に集中し、項目Bを一括変更できても、その変更を何度も繰り返すのも手間で、項目B以外を変更する場合もある）

  • そもそも、複雑な業務をエラー文章だけで解決していること自体が問題

このように本来の課題を整理すると、もう少し視野を広げ、同じ課題を抱えるユーザーが他にもいないか？本来のあるべき姿は？などと立ち返ることができるようになります。

2. 本来の課題に対して改善策を考える

前述した課題に対して、根本的な改善策を考えてみましょう。

  • 入力メニューを２つに分け、最初のメニュー選択でチェック有無が変わるようにしてチェックミスをなくす

  • ホーム画面に期限の迫ったデータのショートカットを表示し、一覧画面では期限でのソート機能をつけたりアラート表示を追加したりする

  • データの閲覧権限の設定機能をつける

  • CSV/Excelファイルインポートによる一括変更機能をつける

  • エラーが起こりにくい入力補助機能をつける

根本的な改善策は、もともとのユーザー要望をそのまま叶えるよりも、開発コストがかかりやすい傾向にあります。そのため、コストをかけてでもやる価値があるかの吟味が必要です。

3. 改善策を３つの軸で評価をする

根本的な改善策を導いても、いざ対応する段階になると、冒頭でも説明した「現在のシステムに影響も開発コストも少ないものから」対応する判断をしてしまうことがよくあります。

これは「ユーザーへの提供価値」を評価軸に入れていないことが大きな原因です。さらに、開発予算を使い切りたい組織の慣習がある場合、無理に低コストな対応を組み込んでしまいやすいことも原因の一つでしょう。

短期目線での場当たり的な改善は、開発コストを抑えることができる一方、UIやシステムそのものを複雑にし、いわゆる「つぎはぎだらけのシステム」を生んでしまうリスクがあります。

将来的には、要望を挙げていない他ユーザーにとって使いにくくなり解約に繋がったり、小さな改善にも大きなコストがかかる柔軟性のないシステムになったり、ビジネス的なデメリットを多く抱えてしまうかもしれません。

こうならないためには、長期目線で改善策を評価する必要があります。ユーザー価値の「質」と「量」の軸を含めた、以下の３つの軸で評価することをおすすめします。

ユーザー要望の改善案の評価軸（評価基準は例）

Ａ. 作業効率の改善度

作業効率の改善度はユーザー価値の「質」となる軸です。この改善によりユーザーの作業効率がどれだけ高まるかを評価します。

例えば、業務アプリケーションの場合、作業効率の改善度を高・中・低の３段階で評価すると以下のとおりです。

  • 高：あとになって気づく業務ミスを予防できる

  • 中：その場で気づく不備の手戻りを予防できる

  • 低：業務スピードが上がる

業務ミスや手戻りのような作業のやり直しを伴う課題は、ユーザーの不満がたまりやすいため、改善によるユーザー価値が高いと言えます。

業務スピードは程度の差があることも多いため、さらに段階を分けてもいいでしょう。10分のスピードアップと10秒のスピードアップを同じ評価にはできません。

注意すべきは、説明文やラベル表記の変更などのような「ちょっとした改善」の評価を低くしすぎてしまうことです。分かりにくい説明文やラベル表記は、ユーザーを誤認させミスを誘発することが多いため、改善の効果を高くすべき場合もあります。無意識に開発コストと同じような評価をしないよう気をつけましょう。

Ｂ. ユーザー影響範囲

ユーザー影響範囲はユーザー価値の「量」となる軸です。どれだけのユーザー数に好影響があるかを評価します。

ユーザー数といっても対象のウェブサービスにより適正な人数は異なり、決まった値で評価するのは難しいため、ユーザー属性ごとのユーザー数の分布傾向で評価します。

例えば、ワークフロー機能のある業務アプリケーションでは、申請者・承認者・管理者の３権限のユーザー属性があります。この場合、ユーザー影響範囲を高・中・低の３段階で評価すると以下のとおりです。

  • 高：すべての権限ユーザーに影響

  • 中：複数の権限ユーザーに影響

  • 低：一つの権限ユーザーに影響

さらに、一つの権限でも分布を踏まえユーザー数を比較すると以下のようになります。

申請者 ＞ 承認者 ＞ 管理者

ユーザー数の多い申請者向けの改善は、より評価が高くなります。サービス導入企業の規模が大きいほど権限ごとのユーザー数の差も大きくなります。

ユーザー属性のみでの評価が難しい場合は、該当機能の利用頻度で評価することも可能です。利用頻度の高い機能の改善はユーザー価値も高いと言えます。アクセスログを分析して影響範囲を見極めましょう。

C. 開発コスト

改善策の対応優先度は、先述した２つのユーザー価値と開発コストの兼ね合いで評価する必要があります。いくらユーザー価値が高くても開発コストがかかりすぎる改善は現実的ではありません。

とはいえ、すべての改善策に対してエンジニアにコストを算出してもらうのはかなりの手間がかかります。おおまかなコスト評価軸は、サービス関係者が理解しておくとよいでしょう。

例えば、業務アプリケーションにて開発コストを高・中・低の３段階で評価する場合、以下のような基準で評価する方法があります。

  • 高：データ構造変更による改修

  • 中：機能拡張・変更の改修

  • 低：画面の見た目のみの軽微な改修

画面、いわゆるフロントエンドのみの改修で済む場合、比較的開発コストを抑えて実現が可能なことが多いです。

一方で、機能変更の改修、いわゆるビジネスロジック（業務に関わる処理）に影響する場合、開発コストは大きくなります。さらにデータ構造を変更する場合、処理だけではなくデータベースにまで影響が及ぶため広範囲の改修を伴います。

以上のような観点で、開発コストの影響範囲に当たりをつける必要がありますが、採用しているアーキテクチャによって開発コストの影響の差もあるため、エンジニアと協議し正確な評価基準を定めるようにしましょう。

さらに、想定よりも開発コストがかかることがわかった時点で、対応優先度を見直せるとよりよいでしょう。

4. 優先度を決めて順次対応する

改善策の評価ができたら、優先度を決めて対応します。

ユーザー価値が高く開発コストが低い改善案は、最優先で対応すべきでしょう。逆に、ユーザー価値が低いにも関わらずと開発コストの高い改善案は、優先度を低くするか、対応しない判断をしてもいいかもしれません。

それ以外の評価については、基本的にはサービス価値の評価を重視しますが、サービスの性質や状況により優先度の判断も変わるので、これといった答えはありません。

改善策の評価から対応優先度を決める方法

サービス関係者でどの軸を優先すべきかの判断基準を定め、要望を管理するとよいでしょう。併せて、３つの評価軸に点数をつけ定量評価できるようにしておくと、優先度づけを効率化でき、関係者との合意もしやすいです。

さいごに

日々ユーザーから多くのご要望から継続的に改善活動を行うSaaSでは、定期的に改善の優先度を見直し、かつシステムを複雑化させずに対応することが求められます。

今回ご紹介した1〜4を仕組化し素早く要望を整理できれば、改善サイクルを健全に回すことができるでしょう。さらに、サービス状況に合わせて重視する評価軸を柔軟に見直せば、よりよいサービス運営を行うことができます。

現在マネーフォワード クラウドは、電子帳簿保存法やインボイス制度などの法令対応が最優先ではありますが、そんな中でも価値ある改善を日々行い、これからもユーザーに愛されるサービスを作っていけたらと思います。


この記事が気に入ったらサポートをしてみませんか？