それもまたUIだね。インタフェース散歩！(11) 常にMVP（Minimum Viable Product）を意識する

人とコンピュータの関係を考えると、二者間には常にインタフェースが存在します。本連載では、人とコンピュータの間に介在するインタフェースに着目し、インタフェースとそれらを世に生み出すプロダクト開発について議論します。Helpfeelが、独自のインタフェースを実装しながら、便利さと楽しさを備えたWebサービスをどのように開発しているのかについてお伝えします。

こんにちは。アプリケーションエンジニアのyadoです。エンタープライズサーチ「Helpfeel」の機能設計・開発を行っています。また、「世の中を少し楽しいものにする」をモットーに個人開発も活発に行っています。本稿ではさまざまなアプリケーション開発に携わってきた筆者の体験を元に、ユーザーからの要望に対応するときの取り組み方について考えていきます。

小さく作ることの効果

皆さんは "MVP（Minimum Viable Product）" という概念をご存知でしょうか。日本語では「最小限の機能を備えた製品」と訳される、プロダクト開発におけるアプローチです。このアプローチでは、新しい製品やサービスを市場に投入する際に最低限必要な機能のみを持たせてリリースし、実際のユーザーからのフィードバックを受けながら改良・発展させていきます。

一般的にMVPのアプローチは、プロダクトの0→1のフェーズにおいて用いられるイメージを持ってる方が多いと思いますが、既にある程度大きくなったプロダクトの機能追加においても有効な手法だと筆者は考えています。

「〇〇の機能を追加してほしい」という要望が届いたとき、ユーザーにとって必要なのはその機能自体ではなく、その機能がほしいと思うきっかけになった課題の解決なはずです。「顧客が本当に必要だったもの」という表現がありますが、ユーザーから寄せられる要望がtoo muchなものであったり、特定の状況下でしか活用できないものであったりといったことはしばしばあります。要望の背景を丁寧にヒアリングして、より少ない労力でより多くの課題を解決できる方法を意識することが重要になるでしょう。

また、小さく作ることのメリットとして「工数を少なく抑えられる」というのはもちろんのこと、「シンプルな機能に落ち着きやすいのでユーザーの混乱が起きにくい」といったメリットもあります。

実例から考える

筆者がこれまでに実際にユーザーから寄せられた要望を3例挙げるので、皆さんだったらどのように対応するかを考えながら読んでみてください。

ケース① グラフ表示機能の改善

あるプロダクトのCMS（Contents Management System：コンテンツ管理システム）上に表示されている統計グラフがありました。このグラフは直近1か月間の複数のデータを折れ線グラフで表示しています。

グラフのイメージ

このグラフ表示を「任意の日付にさかのぼってデータを参照できるようにしてほしい」という要望がユーザーから届きました。グラフの描画にはChart.jsなど便利なライブラリがありますが、「任意の日付にさかのぼれる」という要望を満たすにはいろいろなアプローチがありそうです。仕様によっては複雑なUIになってしまう可能性もあります。

そこで、筆者は「そもそも任意の日付にさかのぼる必要はあるのだろうか？」というところに着目し、ユーザーにアンケートを取りました。その結果、「さかのぼって確認したいのはせいぜい2～3か月前のデータである」ということがわかりました。これは大きな情報ですね。

筆者が実装したのは、下図のようなイメージです。

機能追加後のイメージ、月 / 年の表示が選べるようになっている

ラジオボタンでグラフの描画エリアを「1カ月」または「1年」の2択で選べるようにしました。これなら欲しい範囲のデータは充分表示できていますし、UIの操作で迷うこともまずありません。

この機能追加を提供したのは1年以上前ですが、「もっと前のデータも確認できるようにして欲しい」という要望はまだ届いていません。今のところ必要十分である機能を最小の工数で実装できた例です。

ケース② 設定変更履歴の閲覧機能

次のケースは、社内メンバーのみが使う管理ツールに寄せられた要望です。このツールはプロジェクトごとに頻繁に設定変更されるため、「誰がどのような変更をしたかの履歴を閲覧できる画面が欲しい」という要望が届きました。

いわゆる変更履歴画面には変更履歴の一覧があって、詳細をクリックしたら変更内容の中身が確認できて……といった具合でしょうか。

変更履歴一覧のイメージ

しかし、「社内メンバーのみが使う」という点と、ヒアリングの結果から「頻繁に見るわけではなく何かあったときのための確認に使いたい」という用途が判明したことから、実装したのは次のような機能です。

Slack通知のイメージ

このように、SlackBotによる変更通知機能として実装しました。Slackアプリ内での検索機能で過去の変更履歴を確認できるので、要望を満たしています。そして画面のUI実装工数が全くかかりません。

社内限定の利用や、特定の人だけが確認できれば良い情報の場合は、「SlackBotで通知する」「ログ出力だけしておく」「DBに値だけ保存しておく」といった方法でまずトレーサビリティを確保するというアプローチを使うことがあります。

Slack通知＋DBへの値保存といった形で実装すれば、「やっぱり画面で見たい」という要望が出た場合も、後からUIを提供することで保存しておいたデータを活用できます。いつでも使えるわけではないですが、「UIに実装工数をかけないで実現する方法はないか」というのも頭の片隅に置いておきたい考え方ですね。

ケース③ 検索結果の操作

最後のケースは、FAQの検索システムの結果表示画面に関する機能要望です。このシステムでは入力されたキーワードに対して、内部の検索アルゴリズムに基づいてヒットした記事のタイトルが一覧表示されます。FAQのデータは各顧客企業の担当者が管理しているものです。

寄せられた要望は、例えば「会員」で検索したときに「会員登録の際にエラーメッセージが表示されます」という項目を一番上に表示したい、といったように「任意のキーワード入力に対して結果の表示順を自由に編集できるようにしたい」というものでした。

要望のイメージ

この要望はそれなりの頻度で出ていましたが、開発チームとしては対応に後ろ向きでした。なぜならば、この機能を実現してしまうとFAQ管理担当者の運用コストが膨大になることが予想されたからです。

「会員」という1キーワードだけの対応なら問題ないはずです。しかし、この機能があると、エンドユーザーが入力し得るあらゆるキーワードに対して表示順を調整する担当者が現れてしまうでしょう。

それだけではなく、「複数のキーワードが入力されているパターンも調整する？」「新しい記事が追加された場合の調整方法は？」といったように懸念事項を考え出すとキリがありません。開発担当者も顧客企業もどちらも不幸になる未来が見えたのです。

とはいえ、元の要望自体はニーズとしては理解できます。「よく検索されるキーワードに対して特定の記事を目立たせたい」というケースは少なからずあるでしょう。読者の皆さんならこの要望に対してどのような解決策を提示しますか？

筆者はまず、最小限の機能提供でどれくらいの課題が解決するかを確かめるために次のような機能を実装しました。

表示順調整UIイメージ

実装した機能は
・1つのキーワードに対し、最上位に表示する記事のIDを設定できる
・キーワード / 記事の組合せは最大5件まで登録できる
というものすごくシンプルなものです。

5件までという縛りを設けることにより、運用担当者が大量のキーワードを登録するような労力を払うことは起きません。実はこの機能は現在社内で試験的に運用しており、顧客企業にはまだ提供していません。社内メンバーからのフィードバックはおおむね良好で、出ていた要望の大部分がこれで解決するのでは、と見込んでいます。

提供後に要望元の顧客ユーザーが全員満足するとは限りませんが、大がかりな機能を時間をかけて開発するよりは、まずはこのような小さい機能から提供して徐々にブラッシュアップしていくのが正しいアプローチだと筆者は信じています。

この連載で筆者が次に執筆を担当するころにはこの機能がリリースされていると思うので、実際の反響はどうだったかの答え合わせはまたそのときにご報告します。