養殖生産管理SaaS -サービス開発の足跡vol2 問いのピボット
vol1は水産業への新規参入を決めて、水産加工業でのサービス展開を考えたけど、挫折したところまでの話を書いた。vol2は挫折した先にどうしたのかの話。
養殖業へのシフト
水産加工業での事業開発を断念したあとに目を付けたのが「養殖業界」だった。
一般に魚の給餌養殖は稚魚～出荷まで2～3年かかる（蓄養がメインだと仕入～出荷まで数カ月）。そのため足元の仕入量を決めるためには、現状のキャッシュフローや将来の売上の見立てなどを総合的に考える必要がある。
計画性や先見性が事業経営で求められることになるため、ITやシステムの力が発揮しやすいんじゃないかと考えた。漁師と違って、市場外の販路も比較的開拓しやすいのではないかという仮説もあった。
「問い」の見立て
そこで長野県で信州サーモンの養殖事業をしている生産者の方とつながって、サービスの方向性を模索し始めた。現状のヒアリングをしていると、どうやら出荷・販売まわりの業務プロセスが煩雑そうだった。
そこで以下を解くべき問題と定義した。
●電話・FAXが多いことで業務の手が止まり、生産性を下げている
●小売で指定されたシステムの使い勝手がよくない
●取引先ごとに単価がバラバラで金額計算でミスしやすい
プロトタイプ設計
検証すべきことは2つ。「問題が普遍的なのか」と「解決策としてのサービス像がどうあるべきか」。前者はヒアリング回数を重ねれば確認できる。後者はプロトタイプがないと客観的に評価ができないので、まずはサービス設計の粗々のプロトタイプをExcelで組んだ。
プロトタイプは主要な画面のみ20枚くらいをExcelで作って紙芝居式にパラパラと生産者の人にみてもらうことにした。ちなみにあまり時間をかけても仕方がないので、プロトタイプ自体は1～2週間くらいで作り切った。
プロジェクトチームの発足
プロトタイプができたタイミングで今の開発パートナー（生産者）の結城さんや社外取締役（予定）のパートナーの金田さん（マーケター）との出会いがあった。
今振り返ってみると、重要な出会いがたまたまこのタイミングに集中していて、そしてその出会いがプロダクト開発をドライブしている。今思い返してもなかなか奇跡的なことが起こっていると思う。
ちなみに今回はスコープから外れるので金田さんの登場シーンは少ないけど、彼もまためちゃくちゃすごい人で商社や流通の領域で結果を出してきた人。水産業のことも幅広く知っているし、話をするたびに思考の深さと鋭さに度肝を抜かれる。
そんなわけで生産者＋マーケター＋エンジニア＋僕（UXデザイン）という4名でプロジェクトチームが発足した。
プロトタイプ検証
2022年3月～4月半ばにかけて、もともと話を聞かせていただいた長野の生産者の方、結城水産の結城さんの他、数人の生産者さんにプロトタイプを見てもらってアドバイスをしていただいた。
反応は全然良くなかった。「いいかもね」とは言われるけど「喉から手が出るほど欲しい！」という熱狂さが感じられない。
養殖業の人たちの役に立ちたい、おいしい魚が食べられ続ける未来を守りたいという想いやビジョンをとにかく魂で伝えて、そこには共感してもらったり応援してもらったりした。だからこそ話も聞いていただけた。
だけど、肝心のサービスへの反応が全然良くない。僕たちがサービスを届けたいユーザに直接話を聞いているはずなのに、アドバイスっぽい感じの発言が多い印象。「こうしたらいいかもしれないですね（ウチは使わないですけど応援はしてます）」みたいな感じ。
一番きつかったのは最初にヒアリングさせていただいた信州サーモンの養殖生産者の人にプロトタイプを見せたとき。プロトタイプがある程度動くように作って、準備万端・自信満々で持って行った。なんなら受託開発で案件が取れるんじゃないかとすら思っていた。
「うーん、ちょっと楽になるくらいかな」
「タブレットの入力がめんどくさいと思う人もいそう」
「人力でもなんとかなっている」
「うーん、払っても月1000円くらい？高いなら、なくてもいいかな」
見事に、全然刺さらなかった。
エンジニアはすでにチームにいたけど、正直自分のサービスに自信が持てなくて、開発着手にすら踏み切れなかった。
そこからは結城さんと毎週定例を持たせていただいて、壁打ちに付き合っていただいた。毎週日曜日にヒアリングをして、画面を直す。また日曜にみてもらって直す。その繰り返し。
養殖現場見学
現場を見ないで机上の論理だけでプロダクトを作る最大のリスクは、プロダクトアウトにサービス設計者の理想論を押し付けるサービスをつくってしまうことだ。
どれだけ生産者の人に話を聞いても「刺さった！」という感覚が得られなかったので、もしかしたら独りよがりなサービスになっているんじゃないかという考えが何度も頭をよぎっていた。
この状況をなんとか打開したくて、わらにもすがる思いで2022年4月半ばに結城さんの宮崎の養殖現場を実際に見学させていただくことにした。海面養殖の現場を見に行ったのはこの時が初めてだった。
この時、現場で働く人たちの姿を見て、頭を殴られたような衝撃があった。自分がこれまで頭の中で考えていたことはすべてが間違っていたわけではないけど、いくつか大きな見落としがあった。
１）想像以上に忙しい
まず想像の何倍も養殖現場の仕事は大変だった。朝、日が出る前から仕事が始まり、夕方日が暮れるまで体を動かし続ける。詳しくは上記のnoteを読んでいただくとして、エサやりに出荷に分養にやるべきことが本当に毎日たくさんあった。ペーパーワークに使える時間は限られていたし、パソコンの前に座る時間なんてほとんどなかった。
２）販路開拓の営業マンがいない
次に限られた人数で現場仕事を回しているため、営業や販路開拓を専任でやっている人がいなかった。もう少し規模の大きい会社だと話が違うのかもしれないけれど、日本全国を見ても生産者が生産以外の領域に人を張れるケースはかなり稀なのかもしれない。
３）ロットサイズが大きい
さらに取り扱う魚のロット・量も想像と乖離していた。数千から数万単位で魚が各生簀に入っていて、毎日数百～数千の単位で出荷がある。数十の単位ならまだ個別の納品先ごとに納品書・請求書の発行業務ができる。でもこの規模になってくるとビジネスのロットサイズが生産者側と小売側で乖離する。個別の取引先と受発注を生産者が毎日こなすのは現実的じゃない。卸・問屋・商社といった人たちが間に入って生産者と小売を繋いでいるのにも、その商流が必要な理由や背景がちゃんとある。
サービス仮説の棄却
現場の見学を終えて、エンジニアの元同僚と結城さんの3人で飲みに行った。その場でこれまでずっと聞けなかったことをやっと聞けた。
「このプロダクトが完成したとしてお金はいくら払えるか」
柔らかい表現ではあるけど、厳しい回答が返ってきた。
「便利だと思うし、ほしい。だけどお金を払うかというと、販路をそもそも自社でそこまで持っていないところが多いわけだから、お金を払ってでも使いたいと思う人は少ないかもしれない」。
現場も見ているので、そりゃそうだよなと妙に腑に落ちた。道は2つあった。ひとつはこれまで作ってきたプロトタイプを磨くことで、このモヤッとした状況を突破する道。もうひとつは問いそのものを再定義する道。
このままプロトタイプを改善していく道はあった。すでにゼロベースで2～3回はすべての画面を作りなおしていたし、プロトタイプは毎週改善を重ねてきていたので、少しずつ良くはなっていた。
でも僕たちは後者の道を選んだ。プロトタイプを改善しても改善しても「お金を払ってもらえるプロダクトになるか」という問いには自信をもってYesと言えそうになかった。確信が持てないのは、そもそも解こうとしていた問いが微妙だったからなんじゃないかと思った。
現場が忙しく営業にリソースも割けないとすると、受発注業務の効率化でどれだけ使い勝手を上げても、個別取引が限定的である以上、貢献できる領域はどうしても限られてくる。問いから考え直した方が健全なサービス設計ができると考えた。
解けない「問い」
問いを変える意思決定をし、今までのアウトプットを捨てることで、労力は掛かるけど、より自分たちにとって好ましい未来を選び取れる可能性は手に入った。サービスローンチしてから戻るよりよっぽど痛手は少ない。
もし問題を解くために1時間あったとしたら、おそらく最初の55分は何が問題であるかを見つけ出すことに充て、残りの5分で答えを導き出すであろう
byアインシュタイン
何の問いを解くかは僕はかなり大事だと思っている。どうしても解決策にばかり目を向けがちだけど、考えても答えが出せない問いに向き合っても良い解決策は出てこない。
個人的にはいい問いかどうかには4つ要件があるのかなと思っている。
1）存在するか …現場で実際に課題になっているのか
2）痛みは大きいか …お金を払ってでも解決したいくらいの課題なのか
3）一般化できるか …市場全体のボリュームはどれくらいあるか
4）解けるか …自分たちの持つ知識・経験や他者の力を使って解決可能か
市場内流通は４がネックになって参入を断念したし、水産加工業は１がネックだった。今回は２で引っ掛かった。サービスをゼロベースで作るプロセスは「解くべき問いの定義」がどれだけシャープにできるかにかかっている。
問いが変わると何が変わるか。事業やサービスの評価、ビジョンはどう変化していったか。そのあたりはVol3に続きます。
この記事が気に入ったらサポートをしてみませんか？