“一次情報”にこだわり「課題仮説」と「解決策仮説」を立てる　カミナシの開発プロセスにおける、課題と解決策を特定方法

山下氏の自己紹介と、カミナシの紹介

山下亜梨沙 氏（以下、山下）：今日は、一次情報から課題とソリューションを特定するリアルなプロセスを話そうと思います。

私は山下亜梨沙と言いまして、社内では“かもしー”と呼ばれています。好きなことは銭湯とかサウナとか旅行で、カミナシでのプロダクトマネージャー歴は1年ですね。

いろいろお話しする前に、カミナシのことを簡単に伝えたほうが、話がたぶんわかりやすいと思うので、さくっと話そうと思います。

カミナシはミッションとして「ノンデスクワーカーの才能を解き放つ」を掲げています。

日本にノンデスクワーカーは約3,900万人いると言われていて、カフェの店員さんから食品工場で働いている方まで、本当にいろいろな職種の方がいます。

ノンデスクワーカーの業務ですが、紙の業務などのアナログで非効率な業務がすごく多いところが課題だなって思っています。

そんなノンデスクワーカーのエネルギーとかポテンシャルを少しでも解放したいなと思い、カミナシは業務をリデザインすることで、そのきっかけを作りたいなと思っています。

カミナシのプロダクトですが、なにができるかというのを簡単に伝えると、現場で紙の帳票に記録する業務がすごくたくさんあって、多い工場だと、1日に何千枚とか、少なくても何十枚、何百枚みたいなものを記録していることがあります。

それを現場で記録して、その記録したものを承認して、それをExcelに転記するみたいな業務をやっているところがすごく多くて。そのような業務をデジタル化していくようなことをやっています。現場ではiPadで記録して、管理者の方がパソコンでその結果を確認できるようなことが、ざっくり（カミナシのプロダクトで）できることのポイントかなと思います。

そんな「カミナシ」ですが、今は30以上の業界に導入いただいていて、7,000を超える現場に入っているサービスです。

カミナシは、一次情報を取りにいくことをすごく大事にしている会社です。私が入社して1年で、実際に現場に訪問してユーザーの業務を見せてもらった回数は14回。ユーザーヒアリングをした回数も、ざっと数えて35回ぐらいあるなという感じです。

常にヒアリングをしているわけではなく、エンジニアとコミュニケーションを取ったり、仕様書を書いたり、そういうことをやっていく中でなので波はありますが、けっこう多いほうなのかなと思います。

どうやって一次情報をもとに、課題とソリューションを特定しているのか？

（スライドを示して）実際に「どうやって一次情報をもとに課題とソリューションを特定しているのか？」というところですが、カミナシの開発プロセスをざっと俯瞰すると、こんな感じかなと。

この図は、先ほどの（小谷 草志氏のセッションで見せた）スライドとちょっと似ているかもしれません。ビジネス仮説を検証して、課題仮説、解決策仮説、機能仮説を検証して、開発して、リリース後の検証をするというような感じです。

今日はその中でも、課題仮説と解決策仮説の話をしようと思います。

ステップを分けると、3つになるかなと思います。まず1つ目が「課題っぽいものを見つける」。2つ目が「課題を特定する」。3つ目が「解決策を特定する」です。これを順に話していきます。

ステップ1　課題っぽいものを見つける

まず「課題っぽいものを見つける」です。例えば「〇〇機能が欲しいらしい」とか、「ユーザー訪問をしたら、この業務に1日2時間もかかっていた」とか。「これを作るとこういう人に売れるらしい」みたいな、CSやセールスから聞いたり、ユーザーと仲良くなって、話していた時に「実はこれ大変でさぁ」とか。実際に現場に行った時に「あぁ、これめっちゃ大変そうだな」みたいなものからヒントを得ているという感じで、アンテナを張っている感じですね。

今回実例として「同時記録ができると売れるっぽい」という課題のようなものがあったので、この話を具体的にしようと思います。

カミナシの現状の仕様からさくっと説明すると、左の人と右の人が、同じレポートを別のiPadで記録しようとしていますが、レポートに（別々の人が）記録できないという状況になっています。

具体的に、左の人が12時に保存して右の人が12時3分に保存したら、12時3分のほうに完全に上書きされちゃうという感じですね。

「同時記録、そりゃできればいいよね」というところはあるんですが、どこまでやればいいのかが、今回の一番のポイントだなと思います。

もちろんGoogleドキュメントとかスプレッドシートとかNotionみたいに、1文字打ったら相手も1文字変更される、そういう感じになれば最高だと思います。開発工数とかの現実的なところも考えた時に、どこまでやることがミニマムで大事なのかを見極めるのが、今回のポイントだなと思いました。

リアルタイム性の度合いで、左が低い、右が高いと（して）一直線上に並べてみると、程度がありそうだなと思います。今のカミナシが一番左にあるとすると、どこまでやるといいのか。それはつまり、どんな課題を解決するべきなのかというところを明確に特定するのがすごく大事だなと思いました。

ステップ2　課題を特定する

なので、「課題を特定する」という2つ目のステップが、今回においては一番大事だなと思って進めていました。

「課題を特定する」には、まず一次情報を集めます。とりあえず10社分ぐらいの一次情報を集めてみました。ぼかしていますが、カミナシには現場で使っている紙の帳票での情報や、CSがユーザーのサポートをする上で情報を持っていたりするので、（その）情報をCSに聞きながら、ユーザーが具体的にどんな業務をしているのかを集めていった感じです。

今回「同時で編集したい」となった時の課題の発生要因や前提となるものはなにかというと、具体的な業務フローだと思い、それぞれ10社分図解しています。例えばこれ（業務フロー図）だったら、部屋が3つあって、それぞれ3人がガスボンベの数を数えるという棚卸しの業務ですね。

まず部屋が3つあって、この中で（ガスボンベが）散らばっていてみたいなところを図解しています。これを10社分ぐらい作って、理解したという感じですね。

これを踏まえて課題の発生の理由に注目すると、課題が5種類ぐらいに分類できる。詳細は割愛しますが、発生要因によって分けている感じですね。

（スライドを示して）さらに課題を整理しました。今回は縦軸・横軸でリアルタイム度合いで分けていて、右に行けば行くほどリアルタイムに更新される必要がある。下に行けば行くほど、リアルタイムではなくて「保存」とした時にマージされればいいといったあまり同時記録のニーズではない（もの）という感じでプロットしています。

円の大きさは推定ですが、だいたいこれぐらいのインパクトがありそうだなというところを表しています。

その上でどこまでやるべきかというところですけど、これは開発工数というところもあるし、会社としてどんな資産をプロダクトとして積みたいのかも意識して切っています。

短期的にMRR（Monthly Recurring Revenue）が伸びればいいのか、解約が下がればいいのか。はたまたこういうデータを獲得することで次につなげたいのか。あとは、こういう業界を開拓できるかどうかを検証したいのか。いろいろ欲しいものがあると思いますが、それによってどこまでやるべきかを線引きしている感じです。今回は囲っているところを解決したいなと思いました。

今回の「課題を特定」のサマリーとしては、スプレッドシートのように分単位の同時編集ではなく、完了した時に最後にマージするぐらいのリアルタイム度合いでよさそうというところが明確になった感じですね。

ステップ3　解決策を特定する

もうここまで来れば、後はもう解決策を幅出しして検証する感じです。

幅出しする時は、なるべく5案以上ぐらい出すようにしています。それぞれメリット、デメリットを並べていくことが多いです。

それを実際に検証するんですが、現場に行ければ現場に行き、行けなければオンラインでユーザーヒアリングをします。（ヒアリングは）5社以上行う感じですね。

実際にA案、B案みたいなものを具体的に持っていって、この解決策をフックに「本当にこれは課題だったんだっけ？」みたいなところに戻ったり、行ったり来たりして特定していくというのを行っています。投票をしたいわけではないので、実際にどんな業務なのかというところも併せて確認しつつ、課題と解決策を特定していくという感じです。

最終的には「これで運用したい」「導入したい」と思ってもらえたら、BtoB SaaSとして解決策を特定できたかなというところで、次の要件定義に行くという感じです。

大事なのは仮説を持って検証すること

まとめると、一次情報からどうやって（課題と解決策を）特定しているかというと、この3ステップで行っています。

最後ですが、ユーザーを知ることが目的になると、「これどういうアウトプットにつなげればいいんだっけ？」が迷子になっちゃうと思います。自分にもそういうことがすごくあるなと思うんです。

そうではなく、仮説を持って検証するというところが一番大事だなと思い、それを意識してやっているという感じです。

ありがとうございました。