「絶対売れる！」と思ったのに利用実績はたった1社　プロダクト開発の大失敗から学んだ“視点変換”と“共有と意思決定の細かさ”の重要性

自己紹介と株式会社カミナシについて

後藤健佑氏（以下、後藤）：開発、実装の話ではありませんが、今僕がプロダクトマネージャーとしてやっていて、「これは売れる！」と確信して出したものの、機能の利用社数が1社で、膝から崩れ落ちた話をしようかなと思っています。よろしくお願いします。

自己紹介です。今、株式会社カミナシでプロダクトマネージャーをやっている後藤と言います。ふだんはプロダクトの仕様を決めるなどをやっています。もともとはエンジニアからスタートしていて、GolangやTS、AWS周りがけっこう好きです。今はプロダクト周りの仕様や、「どうして作るの？」みたいなところを作っています。

まず「カミナシとは何か？」をお話します。「カミナシは現場の改善プラットフォームを作っている」とよく言いますが、現場のルーチンワークであったり、事務作業のを自動化するアプリを作ったりしています。現場は、手書きの情報やデータを1個ずつ集計したりしていて、紙やエクセルを使って面倒な作業をしています。食品や小売り、製造のような、さまざまな現場で使われています。こういうものを1個ずつスマートにして、働き方を変えていきたいと思っています

「絶対売れる！」と思ったのにすべった話

さっそく今日のお題です。「絶対売れる！」って思って機能を出してみたら、めっちゃすべった、という話を今日しようかなと思っています。前提知識を揃えておきたいと思うので、登場人物を紹介します。監査担当者さん。これは後ほどちょっと説明します。あと、現場従業員さん。この2人が出てくるので、覚えていてください。

「監査担当者さんって誰？」という話です。僕らの業務の中に“業務監査”と呼ばれるようなものがあって、これが何かというと、例えば店舗の状況や工場の状況を、定期的に確認しに行くような業務です。

なぜこれを行うかというと、法や社内規定みたいなところを会社ごとに作っていて、それがちゃんと行われているかどうかを、定期的に確認する人がいます。ISMSがけっこうイメージ近いんですが、こういった監査の業務も現場では行われていて、企業によっては国際で定められた規格に沿っているかどうかをチェックしています。

店舗数が300、工場数が100あるってなったときに、監査担当者さんが、監査業務で年間300店舗や100工場を毎回飛び回る必要がある。「年間で数百現場を飛び回るって、なんかめっちゃ辛そう」で、監査担当者さんが困ってるんじゃないかな、というのがこのプロダクトを作ろうと思ったきっかけでした。

実際に深堀ってみると、やはり困っていて（笑）。何に困っているかというと、紙やデジカメを使ってチェックしていたり、エクセルに手作業で転記していくみたいな業務です。前回のレポートは1年くらい前に作っていて、だいぶ過去にさかのぼって紙を探しています。

現場のやり取りも、メールやエクセルを使ってけっこう時間かけていて。1年経つと「もしかしたら辞めてることも……」みたいなのがあって、担当者変わることもある。「なんかメチャクチャ大変そうだな」という話になり、「情報共有にかかる手間をなくしたいな」と思ってプロダクトを開発しました。

監査業務の課題解決のために出した施策

出した施策を紹介します。こういう工場や、店舗の間に発生する業務監査業務をデジタル化しようと施策を打ち出しました。この監査担当者さんが、写真や紙を使ってチェックしていったりします。指摘事項を1個ずつエクセルファイルに作ってメールで送って、「改善してほしいですよ」みたいに、毎回ラリーをしていた業務がありました。

「その間の面倒くさいこと、全部カミナシにやっちゃえばいいじゃん」みたいなことを、施策としてやっていました。写真を使って、タブレット上で報告書を作れるとか、離れた場所でもリアルタイムに報告書を作れたり。改善の状況を随時チェックができるアプリを作ろうと企画していました。

正直、これ作ったとき「売れるぞ！」と思ったんですが、2021年4月実績で利用者数1社。血の気引きました。「え、嘘でしょ」「ぜんぜん使われてない......」みたいな感じでした。

失敗した理由の振り返り

どうして失敗しのたかをちょっと振り返って確認してみると、お客さんの業務の中で、重大な課題を1個見落としてしまっていたのと、チームや組織にうまく課題を説明しきれてなかったことが問題でした

1つ目が、監査の業務は確かに大変だけど、どうして大変かというと、社内のやり取り、ラリーではなく、社外の人たちとラリーをするから大変というところ。情報共有する先のことをあまり考えてなかった、というのが1個目の課題としてあります。

もう1つが、チームや組織にうまく課題を説明できていなかった、というのがあります。特にCSや営業など、売りだしてくれる人にちゃんと説明ができていなかった。ちゃんと合意形成して、どうしてそのお客さんが困っているのかを説明した上で進めるべきだった、というのが失敗の要因と思っています。

改善のために打ち出した施策

「早急になんとかしなきゃ」というところで、この後に打ち出した施策の部分を説明しようと思います。まず問題から整理しようと、簡単にジャーニーマップみたいなものを作って、2、30個お客さんの課題がどこにあるのかを洗い出してみました。そこでやっと「外側で行われているラリーのほうが、実は大変なんじゃないかな」みたいなことを発見した感じになっています。

この後にインタビューなどをしながら、実際にどこが困っているのかを具体的に聞いていきますが、大枠としてどこが実際ダメなのかをつかむために、ジャーニーマップを使って、判断、認識のズレをなくしました。

もう1つが、やはり社内にどう伝えるのかがけっこう大事で。まず、テーブルの上に1回「やりたいこと」みたいなものを、バーッと出してみる。意思決定しないといけないものをとりあえず並べてみる。

みんなでちゃんと合意した上でやっていく必要があるので、背景をちゃんと説明資料として作っていく。「これをやっていくのはなんで？」みたいなものをちゃんと作っていくことがすごく大事だと思います。

進めていく中で起きた変化

実際に進めていく中で変わったことでいうと、「監査で使いたい」と言ってくれるお客さんがちょっと増え始めてきました。これはさらにうれしかったことですが、CSのほうから「ここ、もっとこうした方がいいかもしれません。一緒に現場行きましょう」みたいなことを、あげてくれるようになったことです。

徐々に職務間を超えて連携出来るようになってきたので「今度は絶対逃がさんぞ！」と負けん気が出てくる。ちゃんと使える機能になるまで磨き込もう、みたいな。「ゼロベースで考え直して、もう1回プロダクトを出していこう」みたいなことを出せるきっかけになったかな、と思っています。

あとは自分の反省点で一番のしくじりですが、やはり個人技で進み過ぎた、というのがあって。きちんとチームで合意していくところからやっていく必要がありました。課題と過程をちゃんと共有して、背景を揃えていくことが、人が多くなってきた今のタイミングで大事だと感じています。

ただ、1度失敗したくらい。しくじってもちゃんとチームが支えてくれるので、一緒にチームと前に進めていけばいいぐらいのスタンスで、もうちょっとがんばっていきたいと思っています。

白紙に戻して考えると視点のズレが発見できる

まとめです。課題が深いだけでは、実際にユーザーが困っている場所を探し出せません今の状態を正しいとせず、1回白紙に戻して視点を変えてみると、視点のズレを発見できるので、「1回落ち着こう」が大事です。

もう1つが、思ってるよりも、情報共有はコストが高いのを認識することです。背景、取り組む課題を合意して、チーム全員で取り組んでいく姿勢がすごく大事になってきたと思っています。共有と意思決定はサボらず、細かくやっていきましょう、というのが教訓です。

以上です。ありがとうございました。

質疑応答

田仲紘典氏（以下、田仲）：ありがとうございました。全員でちゃんと課題の認識を合わせて進めていくって、すげー大事だと思って聞いていました。

僕から質問したいです。問題整理からたぶんやっていくとは思いますが、どんなメンバー構成、その職種の範囲、みたいなところがあれば教えてほしいです。巻き込む範囲って、各社たぶん違うじゃないですか。

後藤：確かに。ありがとうございます。絶対やるべきことは、開発とビジネスを分けない。必ずビジネスの担当している人を起点に考えていってやっていました。さっき言った、CSや営業みたいなところを、少人数メンバーで巻き込んでいくのが初めにやったことです。

田仲：なるほど。業務理解、ドメイン知識みたいなところからも知識を入れ込んで、PM側に渡して、あとで開発メンバーも巻き込んでいくみたいなイメージですね。

後藤：そのとおりです。やはり開発メンバー、営業、CSの違うところで、やっぱいろいろなチームで、いろいろなバイアスかかっていたりするので。開発だったら、「早く作らねば」とかのバイアスとか。そこを全部1回ゼロに考え直すのは、いろいろなチームを巻き込むのが一番早くて。

田仲：「フラットな目線でみんな見ようぜ」みたいな感じで進めていったんですね。

津田遼氏（以下、津田）：他の部門も含めて巻き込むときのコツというか、ビフォーアフターでどう変えてったかみたいなことってありますか？

後藤：完璧に最初から作り過ぎないことです。ドキュメント作り込んで渡したけど、「何を言ってるかわからん」みたいな感じになってしまったんです。

だから、一緒に作っていく姿勢はすごい大事ですね。隙を作るじゃないですけど、ドキュメントもちゃんと議論する余地を残して、一緒に作っていくのはすごい大事だったりしましたね。僕は特にそれが一番下手だったので、意識するようにしました。

津田：隙がないと、「じゃあ後藤さんよろしく」みたいな感じになっちゃうけど、残しておいて、「ここどう思いますか？」みたいにやると、自分が関わったから自分の子供になる、というか。そういうことですよね（笑）。

後藤：ですです。だから、情報を渡すときの言葉（の表現）も変わっていきます。

中山太雅氏（以下、中山）：それはメチャクチャ大事だと思っていて。エンジニアも一緒に企画段階から一緒に入ることによって、理解度がぜんぜん違ってくるし、それによって打ち合わせしたときに、「ここは違うんじゃないか」「ここはこうしたほうがたぶんワクワクする」みたいなことを、議論しやすくなる。

私は、企画の人が作ってきたものを「じゃあ作りましょう」じゃなく、そもそも企画を作るところから、エンジニアがどっぷり入ってやるべきだと思ってます。

だから、「エンジニア、コード書いてる」みたいな概念で見るのをやめて、もう一緒に企画から作っていくかたちにしたほうがいいんじゃないかと個人的には思っています。

田仲：わかります。あともう1問、この話ってたぶん仮説検証の話かなと思って聞いていました。

この仮説検証はどうやって行ったのかとか、最初の段階で、どんなプロダクト、機能が本当にリリースされたら刺さるのかというところの気持ちの高ぶりというか（笑）。あったら教えてほしいなと思います。

後藤：“正しい問いをいかに作るか”みたいな話かなと思っています。問いをたくさん自分の中にインプットしておくことがすごく大事だなと。だから、まずその情報を仕入れるために、ユーザーヒアリングの方法や、お客さんにとにかく会いに行くことを意識して、情報をかき集めるようにしてます。

そこから仮説を立てて、1個ずつあてていく感じです。その問いを作るときには、まず最初に情報をとにかくたくさんインプットすることは意識して作っていますね。

田仲：なるほど。一次情報をいかに取りに行くか、みたいな感じですよね。

後藤：本当にそう。一次情報はすごく大事です。

田仲：はい。わかりました。ではここで終わります。後藤さんありがとうございました。

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