BtoBサービスで、要望から機能に落とし込むときに気をつけたいこと

こんにちは。株式会社LegalForceでサービスのデザインを担当しています、鈴木智絵（@Sakurampoo）です。

株式会社LegalForceは、企業の法務部や弁護士事務所で働く方に向けて、契約業務をサポートするサービスを開発しています。2017年創業の、いわゆるリーガルテック領域のスタートアップです。
2021年12月現在2つのサービスと1つのメディアを提供しており、「LegalForce」は正式版リリースから2年半で1250社、「LegalForceキャビネ」は正式版リリースから約1年で300社の導入社数を突破しました。

toB サービスを作っていると、ユーザーさんから様々なフィードバックをいただき、やりたいことが無限に湧いてきますよね。ツール系のサービスだと、必要な機能もたくさん出てきます。けれどリソースは有限。あれもこれもはできない…さてどれから考えればいいのだろうか…。
そんな中からなんとか取捨選択をし、詳細な機能仕様を詰める段階。ここはこうした方が使い勝手が良さそうだぞ？この機能を成立させるためには、ここの修正が必要そうだな？etc…そして気づいたら開発スコープは膨大に。

そんなことを考えていたら、どんどん「何を」「どう作るか」ということばかりに意識が向き、あれ、私は何のためにこの機能を作ろうとしていたんだっけと、途中でふと我に返る。。

…のような失敗を、私はこの会社でたくさんやらかしてきました。その失敗から自分なりに考えた「こういう機能を実装したい…かもしれない！と思ったとき、思い出したいこと」を、自戒をこめてご紹介します。
主に、顧客要望から課題を発見し、詳細な機能仕様を詰めていくまでのフェーズの話になります。

1. その機能を「誰が」「いつ」「どう使うのか」を想像できますか？

ユーザーフィードバックによくある「こういう操作がしたい」という要望。
ちょっと待って、すぐにそのまま実装しようと思わないで！まずはその操作をすることで「ユーザーは何を達成したいのか」を探りましょう。例えばこんなこと。

・操作を通して「どんな情報にアクセス」したいのか。そして、それはどんな場面でどのように使いたい情報なのか。
・表示しようとしている情報は、どんな判断の手がかりにしたいのか。その判断の結果どんなアクションをしたいのか。

ここの整理がついたら、上記の「達成したいこと」を、どんな機能だったら「より良く」実現できるのか、改めて考えましょう。

次に頭の中でシミュレートしましょう。どんな人がサービスを操作中、どういう状況でその機能が使いたくなり、どの画面を操作してその機能を使い、その結果得た情報を次に何に使うのか。
最低限、その想像ができるようになってから機能の詳細仕様を考えましょう。

2. 考えすぎない。まずは手や足を動かす。

「ユーザーの達成したいこと」や「適切な解決方法」、本当にこれでいいのか判断がつかない…。もしかすると、結論を出すのに必要な情報が足りないだけかもしれません。
煮詰まりそうになった時は考えるのを一度諦めて、とりあえず手足を動かしましょう。

ユーザーの課題が明確ではない…という場合
・要望がどういう状況で発生したのか、営業のメンバー、社内外のユーザーに改めて聞きにいこう。（当社だと、お客様へのヒアリングを設定する前に、まずは社内の法務や開発チーム内にいる弁護士にサクッと聞きにいきます）
・話は聞いてみたけど結局わからん！という時は、例えばこんな解決方法はどうか？とアイディアをぶつけてみよう。そこから課題が見えることもあるはず。

このやり方で本当に解決できるのな？という場合
・プロトタイプを作って、営業のメンバー・ユーザーに見てもらいましょう。もちろん静止画でもok。手を動かすと頭の中がまとまることも良くあるし、文言ベースの説明より、絵を見せてしまった方が想像がつきやすく、話がスムーズに進みます。
・一度立ち止まって、他のサービスで似たような課題をどう解決しているのかを探しにいっても良いですね。

また、当社には機能をユーザーに提供できる形にするチームとは別に、言語処理や機械学習といった領域で研究開発をするチームがあります。LegalForceの機能で用いる機械学習基盤を作ったり、契約書に特化した独自の検索アルゴリズムなどを作っているのもこのチームです。また、開発チーム内に弁護士が何人も所属するチームがあり、専門的なコンテンツの作成を行っています。

煮詰まったら、こういった社内の別チームの視点を交えて、開発工数度外視・魔法があったらこんなことがやりたいくらいのノリでアイディアを発散させることも大事だと思います。

3. 「なんとなくあったほうが良さそうな機能」は、大抵の場合必要ない。

小規模な機能追加は「なんとなく良さそうだから」で実装すると、結局誰も使わないし、複雑性を増やしてバグの発生源になるだけ、みたいなことがあります。また、情報を全部載せようとして結局全部見られなくなるような、想定とは逆の効果を生むこともあります。

「なんとなく良さそう」は、まだ「ユーザーがやりたいこと」「何が課題なのか」「どのくらいの頻度で発生することなのか」が特定できていない状態。再度手足を動かし、「誰が」「いつ」「どう使うのか」を想像できる状態にしましょう。

4. 迷ったら一番シンプルなものを。

機能仕様を考えるとき、いくつかの候補が出ることがあります。その時、一番人に説明しやすい機能仕様を選択しましょう。
例えば細かすぎる条件分岐。少し時間が経った後の機能改修・周辺機能の開発のときに、考慮もれを引き起こす要因になっていませんか？

説明がしにくいものは、実装が複雑になるし、何よりユーザーにとっても分かりづらい機能になりがちです。

5. 初回リリースから完成形を目指さなくて良い。

BtoBサービスだと、機能の削除や変更がお客様の業務に支障をきたす場合があり、どうしても開発内容に対して慎重になりがちです。リリース前に慎重に検証することはもちろん大事だけど、考えても確信が持てない！というときは、主要動線への影響を考慮しつつ、仮説検証のためにリリースすることは全然ありだと思います。（当社は保守的になるにはまだ早い！）

というより、本当にこの機能は必要だと思って開発しても、実際にリリースをしてユーザーの反応を見るまで全部仮説です。そこから学ぶことの方が大事なはず。　
仮説検証のためのリリースは、機能としては未熟な形でも良いので小さく出しましょう。その使いづらい状態でも、使い続けている人がいたら、それは目がある機能なのでは？と思います。

また、そのような開発をする場合、当たり前ですが1回では正解（完成形）に辿り着けません。継続的な改善を前提に考え、作りっぱなしにしないようにしましょう。

6. 自社のMissionを達成するために何が必要か？を考える。

機能開発をする上でユーザーの声を聞くことは非常に重要です。特に専門職の方がユーザーである当社は、ユーザーの声を聞かずに機能開発することはできません。

その一方で、要望に沿った機能だけを開発していると「現在ユーザーが業務をする上で行なっている操作と同等のことができる」ところを目指しつつ、しかし既存製品のレベルに達することすらできない（その領域に特化したサービスに追いつくことは至難の業です）、中途半端な製品になっちゃいがちだよな〜と感じます。

そんな時は、自社の Mission を思い出しましょう。組織として解決したい大きな課題は何ですか？開発しているものは、その課題を解決するものですか？自分たちが達成したい未来と現状とのギャップに、改めて目を向けましょう。この Mission がサービスを差別化する柱になります。

当社の企業 Mission は「全ての契約リスクを制御可能にする。」です。
言い換えると、契約に潜む事業上のリスクを可視化し、そのリスクを未然に防いだり、いざリスクが起きたときに適切に対応できる状態、を目指しています。

例えば、LegalForce というサービスには、契約書のレビューを補助する機能があります。一般的な論点のチェックリストと契約書の文書を突合し、契約書に潜むリスクの発見を助けます。加えて、チェックリストの項目には修正文の例や、なぜその論点のチェックが一般的に必要とされるかの解説があります。まさにリスクの可視化と、そのリスクをコントロールするための機能ですね。
この Mission を体現するような機能が、LegalForce というサービスを特徴づけています。

ユーザーの声を聞き、ユーザーの期待を超えた製品を作り続けましょう。

まとめ. サービスに取り組む根っこの考え方はtoBもtoCも同じ。

こうやって気をつけたいことを列挙すると、サービスに向かう根っこの姿勢は、C向けと変わらないのでは？とか思ったりします。とはいえ、B向けだからこそ、慎重にならざるを得ないところや、仕様が複雑になりがちな傾向があると思うので、上記のようなことをC向けサービスよりも意識しないとなぁと思います。

取り上げたポイントは、改めて見ると当たり前のことばかりだとは思いますが、当社はまだまだ未熟な組織、未熟なサービスを開発しています。だからこそ、こういうことに意識的になりたいです。

LegalForceはデザイナーを募集しています。

シニアUI/UX（プロダクト）デザイナー
グラフィックデザイナー

Meety も始めました。toBサービスについてでも会社のことでも、カジュアルにお話ししましょう〜！
LegalForceのプロダクトデザイナーについてお話しします！

雑談. 契約とポケモンバトル。

この間ポケモン（パールリメイク）をやっていて四天王に挑戦するとき、相手と自分の手持ちポケモンのタイプ（特性）を考えて、このポケモンにはどのポケモンを当てるのか、こういう場合にはこの道具を使おういったことを考えてから臨みました。

企業間で契約を結ぶとき、相手の企業と自分の企業の特性を念頭に、今回の取引ではどんなことが起こり得るのかを網羅的に挙げ、それぞれのケースで自社の損害を最小化する対応策を考えます。

もちろん契約とポケモンバトルだと何もかも違うのですが、何が起きうるか予測をして対応策を考えることは、こういうゲームで感じるようなワクワク感もあるのかもしれないと、ポケモンバトルをしながらちょっと思いました。