一次情報をもとに課題・解決策を特定する3ステップ｜カミナシ 山下 亜梨沙

今回は、BtoB SaaSとしてノンデスクワーカーの業務効率化を支援するカミナシ社を招き、「一次情報の収集や、それをプロダクト開発へ活かす方法」をテーマにLTイベントを開催。

「ユーザーの課題に基づいた開発をするためにはどうしたらいいのか」
「現場ドリブンの文化を浸透させるために何をすべきか」

そんな疑問に、カミナシ社の山下 亜里沙さんが答えます。

カミナシ社がプロダクト開発において大切にしていること

私たちカミナシ社は「ノンデスクワーカーの才能を解き放つ」というミッションのもと、アナログで非効率な現場業務のデジタル化に取り組んでいます。

そんなカミナシ社が大切にしているのは、一次情報を得ること。実際、私は入社1年で14回の現場訪問と35回のユーザーヒアリングを経験しました。今回はその経験を活かして「一次情報をもとに課題とソリューションを特定する方法」をお話しします。

カミナシのサービス（以下、カミナシ）の開発プロセスは次の通り。今回は、その中でも「課題仮説」と「解決策仮説」の話をします。

工程は、大まかに次の3ステップに分けられます。

• “課題っぽいもの”を見つける
• 課題を特定する
• 解決策を特定する

1．“課題っぽいもの”を見つける

例えば、「この機能が欲しいらしい」「現場を訪問したら特定の業務に2時間もかかっていた」など、クライアントの情報をCSやセールスから収集します。あるいは、自分で現場に足を運んでヒントを得ることも。

過去の“課題っぽいもの”の例として、「カミナシで同時記録ができると売れるっぽい」というものがあります。現状のカミナシは、同じレポートを別のデバイスで同時に記録できない仕様で、他の人がレポートを更新すると、直前に編集したものが完全に上書きされてしまいます。

そこでカギとなったのは、「同時記録をどこまで実現すべきか？」でした。Googleドキュメントのように1文字単位で変更を即時反映するのは、設計から大きく見直す必要があったため現実的ではありませでした。

そこで、リアルタイム性の度合いごとに、単位を一直線に並べてみました。カミナシのシステムの現状が一番左であり、どこまで対応すべきか・どんな課題を解決すべきかを明確にしなければなりません。

2．課題を特定する

続いて、課題を特定します。このステップが今回のキモです。

課題特定のために、まずは10社分の一次情報を集め、ユーザーの具体的な業務内容を明らかにしました。「同時編集したい」という課題の発生要因や前提は、具体的な業務フローにあるからです。

例として、ガスボンベを数える棚卸しの業務フローを、10社分図解しました。

課題を発生要因ごとに分類・整理した結果が、次の図です。今回は縦軸・横軸でリアルタイム度合いで分けました。

右上の課題についてはリアルタイムにカミナシが更新される必要があり、左下の課題については同時記録をしなくても編集後に内容を結合すれば済みます。

その上でどこまで対応すべきかを考えます。開発工数だけでなく、会社としてどのような資産を積みたいのかを意識することが大切です。短期的に収益が伸びればいいのか、解約が下がればいいのか。それを踏まえて、どの程度対応すべきかの線引きをします。

今回は青い線で囲んだ箇所を解決したいと考えました。今回の課題としては、分単位の同時編集ではなく、完了後に編集結果をマージできれば良さそうです。

3．解決策を特定する

ここからは、解決策を幅出し・検証し、特定します。

なるべく5案以上を出し、メリット・デメリットをピックアップ。検証時は可能な限り現場に行き、難しい場合はオンラインで5社以上のユーザーへヒアリングします。クライアントから「この案を採用したい！」と思ってもらえたら、解決策の特定を完了し、要件定義へ移ります。

今回の方法で注意すべきは、ユーザーを知ること自体をヒアリングの目的としないこと。それではアウトプットを見失ってしまいますので、必ず仮説を持って検証するよう意識することが大切です。

---

自分自身がプロダクトのユーザーとなる機会がないからこそ、一次情報の収集をもって仮説検証することを何より大切にするカミナシ。

ユーザーに寄り添ったプロダクト開発に近道などなく、クライアントに泥臭く向き合っていくことが大切なのだとわかりました。