立ちはだかった2つの大きな課題。PMF達成のためにやった7つのこと
β版を始めてみて思いのほか初期設定に時間がかかってしまったのは、確かに大変でした。この初期設定は機能開発で改善し、オンラインでも完結できるまでになりました。ただ初期設定の壁を乗り越えたとて、その先に待っていたのはなかなか厳しい現実でした。
データ管理には手応えも
5社の生産者にサービスを使ってもらって毎週フィードバックをもらうというのを約2カ月続けました。フィードバックをもらうたびに仕様を見直し、毎週改善を重ねました。
β版の提供終了を控えた6月、僕たちはアンケートを実施します。そこには率直な生産者さんの意見がつづられていました。嬉しい声もたくさんいただきました。これまで紙で管理されていた（しきれていなかった）養殖の生産管理記録がストレスなくデータ化されるようになるというところには確かな手ごたえも感じました。
「生産管理の事務的仕事が省力化できた」
「入力しやすいフォームになってるので1番のネックである継続はできるのではないか」
「船の上で入力できるのがいい」
「生体の数が具体的に把握出来るようになった」
「紙媒体では、記録した書類を飼育池に落としたり、雨晒しにしてずぶ濡れになり、文字が読めなくなることがあったが、その心配がなくなった。 圧倒的にデータを見返す行為がラクになった。」
PMFしていない現実
しかし、「プロダクトがPMFしていない」というのは受け入れざるを得ない事実でした。PMFとはProduct Market Fitの頭文字を取ったもので、新規事業やスタートアップでのプロダクト開発において非常に重要な概念です。すごくざっくりいってしまうと「そのサービスほんとに売れんの？」に答えるフェーズがPMFです。
顧客である生産者の人がサービスに価値を感じたり喜んでくれたりすることでサービスは使い続けてもらうことができ、売上も継続的に立つようになります。良い顧客体験は良い口コミを生み出し、サービスも半自動的に広がるようになります。
逆にPMFしていない状態は、組織運営もプロダクト開発もマーケティングも苦しいものになります。リードを取るにもコストがかかる、反応が悪い、売上が積みあがらない、機能開発しても喜ばれないし使われない、解約される、銀行の残高がどんどん減っていく。考えるだけで辛いですが、プロダクトがPMFしていないとこうなります。
PMFは曖昧な概念で測り方が難しいのですが、今回は「もしサービスが使えなくなったら、どう感じますか？」と質問して「とても残念」と答えた割合が4割以上かどうかという基準で判断することにしました。β版を提供している生産者さんにはかなり密にコミュニケーションしていることもあるので、正直なところ8割くらいが「とても残念」を選んでくれないんだったら厳しいなと思っていました。ただ結果は4割という基準を大きく割りました。
話を聞いてみると、確かに絶対にないと困るというほどの熱量がありません。あくまでも「あったらいいな」の域を出ていない。
プロダクト開発はまだ道半ばとはいえ、1年半いろんな生産者さんに話も聞いて、サービスの中身も都度見直してきました。内心、いいものができていると思っていました。60点くらいで出したとはいえ、コアの価値になる部分は合格ラインを超えていると思っていました。だからそれだけにこの結果はかなりショックでした。全然足りていない。その事実と向き合わないと前には進めません。
2つの大きな課題
何を改善したら「あったらいいな」ではなく「なくてはならない」サービスになれるのか。毎週生産者さんから話を聞いたり、率直な意見をもらったりする中で感じた課題は大きく2つありました。
１）適切なデータの入力体験を提供できていない
２）データ分析の価値を実感しづらい
課題1：適切なデータの入力体験を提供できていない
開発しているuwotechは魚類養殖の生産データ（給餌・斃死・出荷・投薬…etc）を効率的に管理し、生産者さんの経験や勘に基づいた意思決定をサポートすることを目的にしたサービスです。養殖事業で扱うことになるデータは実は結構たくさんあります。
・生簀にいるのはいつどこから買ってきた魚か
・今何尾いて、重さはどれくらいなのか
・何のエサをどのくらい、どんなスピード、どんな割合、どんな頻度で給餌して、エサ食いはどんな感じだったか
・エサはいくらでどこからどのくらい買ってきて、在庫はいくらあるのか
・死んだ魚はどれくらいいて、どんな様子で、水産試験場からはどういうフィードバックが返ってきたのか
・投薬するならいつどんな薬をやるか、やったか
…etc
上記は記録する内容の一部ですが、これだけの記録を生簀/水槽の数の分だけ毎日記録することになります。現場の魚を見て感じたコメントも記録しておくとデータの意味が後から解釈しやすいので、定量的なものだけでなく定性的なデータも蓄積できると良いです。小規模なところであれば無理なく入力できても、生簀が20個、30個と増えてくるとデータを入力するだけでかなり大変です。
だから開発するときはタブレットでストレスなく、手軽に記録できるという入力体験を創ることを大切にしていました。どれだけ素晴らしい分析ツールを作っても、データの入力が日々続かなければ何の役にも立ちません。
こだわっていた部分なので好評も頂いた反面、β版提供前は想像していなかったことが起こりました。データを記録するための機能群が生産者さんによっては不足していたり、逆に過剰になっていたりしたんです。要するに必要だと思って開発した機能が実は生産者さんからすると要らない機能で、逆に生産者さんからすると「これないと厳しいっしょ」と感じる機能群の開発は追い付いていない、みたいなことが起こっていたということですね。
なぜこんなことが起こってしまったのか。実はβ版提供前は想像していなかった複数の事象・要因が背景にありました。
記録がつかない3つの要因
一番最初に困ったのは、「そもそも記録がつかない」ということでした。やる気はあっても家計簿つけるの面倒くさいから後回し…みたいな感じなのでしょうか…話を聞いてみると、生産者さんの熱量は高いのですが、三者三様のボトルネックがあることが分かってきました。
1）既存機能で対応できない給餌パターンが存在した
2）別担当を巻き込むハードルが高い
3）デジタルリテラシーに合わせたサポートができていなかった
以下でそれぞれをもう少し詳しく書きます。
1.既存機能で対応できない給餌パターン
初期設定のため、とある愛媛の生産者さんの現場を訪問したときのことです。思ってもいなかったことが起こりました。我々が認識していなかった給餌方法で生産者さんがエサやりしていたのです…
魚種によって異なる給餌方法の数々…
養殖業があまりなじみのない人が魚のエサやりと聞いて思い浮かぶのはペレットでの給餌方法だと思います。家で金魚育てるのと同じですね。魚粉をベースにした固形飼料を魚に与えて成長を促します。食べ残しが少なく、環境への負荷を抑えやすいこと、保存しやすいこと、飼料の研究が進んできていることなどを背景にこの給餌方法が選択されるケースは多くなっています。感覚値ですが、4割くらいはこのペレット（業界の人っぽくいうとDP/EP）での給餌かなと思います。
生産管理としてもシンプルで、ソフトウェア開発もしやすいです。なんといっても重量を測るだけですから。最先端のAI給餌とかが話題になるのもこの給餌方法です。自動給餌機にカメラやソナーをつければ給餌最適化ができます。
一方で、摂食や成長、魚病対策の観点からDP/EPが必ずしもベストな選択であるとは限りません。魚種によって最適な生産方法が実は結構変わります。たとえばヒラメはキビナゴやマイワシなどの魚をそのまま給餌しますし、マグロもサバをそのまま給餌するのが一般的です。ウナギは粉末状の配合飼料と水、油を混ぜた練り餌を使います。カンパチやブリみたいな青魚は生の魚（生餌といいます）と配合飼料や栄養剤を一緒に混ぜ込んでペレット状にまとめてから給餌するMP（モイストペレット）という給餌方法が選択されることが多いです。
MPは生産管理の鬼門
これまで僕たちが認識していた給餌方法はこのMPを船の上で作るパターンだけでした。ところが、この生産者さんはMPを工場の人に作ってもらい、製造済みのMPを買っていました。
「だから何？」と思うかもしれませんが、これが少なくともシステム開発の視点からは全くの別ものでした。船の上でエサを混ぜる場合、仕入を起こすのは船の上に積む資材になります。生餌（冷凍のマイワシなど）や配合飼料、栄養剤などですね。そしてこれを船の上で混ぜ合わせて給餌します。生簀ごとにMPを作り給餌するので使用する飼料の量は配合時に都度把握できます。
ただ生餌は目分量になるので、正確な給餌量を把握するためには生餌の在庫管理をして、全体量を見ながら各生簀の給餌量を微調整する必要が出てきます。これはこれで複雑です。
ただ工場でMPを作ると複雑度がさらに増します。配合バランスを後から決められる船上のMPと違って、予め配合バランスが決まってしまうのが一番の違いです。たとえば生餌8、配合飼料2の割合でMPをつくるみたいなイメージですね。そしてこの違いをシステム上でも記録できるようにしようとすると、暴力的に複雑な要件になってしまいます。
まず注文はケース単位です。このケースは注文によってケースあたりの重量が18kgになったり、15kgになったりします。魚の口の大きさによって適切なエサのサイズは違うので、エサの直径も4～5種類あります。そして配合される配合飼料は定期的に見直され、配合バランスも変わります。魚が病気になったら薬を混ぜたり、栄養剤を混ぜたりします。すでに混ざった状態で仕入れているわけですから、エサが余った場合も配合されたバランスで按分しないといけないです。
単一飼料の在庫管理だけを考えればよかった船上のMPとは違い、工場でMPを作る場合まず単一飼料をMP用に割り当てて、そこから投与量をMPの配合割合と全体量から計算し、廃棄したり余ったりした分はもとの単一飼料側の在庫管理としてフィードバックするという超複雑なことをやらないといけません。もはや何のことだかわからないですね。
給餌記録のUXだけは妥協したくない
「半分近くの給餌方法がペレットならMPは無視してもいいでしょ」と割り切って、全部kgで無理やり入力してもらうサービスにすることもできました。でも僕らが作っている仕組みは魚の生産管理をする仕組みです。給餌方法にできるだけフィットしたデータ入力ができるということは結構大事な要件だと考えていました。
確かに他のプレイヤーからみると無駄だったり遠回りだったりするかもしれません。給餌方法に対応するだけで契約が増えるわけでもないと思います。それでも生産管理に尖ってサービス開発を行う者の矜持があります。ここを妥協するわけにはいきません。
これまでも船上で混ぜるMPや生餌給餌、DP・EP給餌は要件を生産者さんからヒアリングしながら整理し、すでに直感的にデータ入力できるところまで開発してきました。
ただ情報構造を整理して画面を作ってみたところで、どうしても機能としてはかなり複雑なものになってしまいます。生産者さんからは「もっとざっくりでいいんだけど。こんなにいちいち入力するのは難しいよ」と言われました。直感的に入力できて、かつこの複雑な仕様を実現できるUXとは何なのか
悩みに悩みました。仕様検討だけで1ヵ月、開発でさらに1ヵ月。データ入力のための開発としてはまさにラスボスです。
2.別担当を巻き込むハードルが高い
問題は開発された機能群だけではありませんでした。運用の方でもいくつかの失敗と学びがありました。初期からずっと開発を一緒に進めてきた結城さんの漁場でも、実は記録がつかないという事象が発生しました。
複数の作業船に別れて作業をするため、結城さん自身が乗っていない作業船での給餌記録や仕入記録は記録をつけようにもつけられない状態でした。別の担当者を結城さんが立てて記録をつけてもらおうとすると、今のサービスを結城さんがまず使いこなせていないとレクチャーもできません。担当者の業務が増えてしまう、個人用のスマホを業務に利用させないといけないといったこともネックになっていました。
3.デジタルリテラシーにあわせたサポート
初期設定を終えて「明日から頑張ります！」と言っていた高知の生産者さん。現場も見せていただいたのですが、魚のことを熱く、わかりやすく教えてくださる方でした。ところが、次の日から全く記録がつきません。もしかしたらめっちゃ使いづらかったかな、それともとんでもなく忙しいのかな…LINEでも「よかったら記録を入れてみてくださいね」とプッシュしてみましたが、もうモヤモヤと嫌な予感が止まりません。
1.5週くらい経ってその生産者さんとミーティングすることになりました。そうするとこんなことを言われました。
「あれ？給餌の記録もついとらんかね？」
記録はつけているらしいのです。でもどこからどう見ても記録がついてないんですよ。おかしいなと思って、その場でついていない記録を試しに入れてもらいました。
「ほら、これでいいんでしょ？」
これがよくなかった…笑 なんと「確定ボタン」を押下してくれていないんです。おかげでデータをいれたのに、サービス側には反映されないままになっていました。入力が終わったら確定ボタンを押すというのは「言わないでもわかる」ことだと僕らが勝手に勘違いして説明していませんでした。結局2週間分の給餌記録、斃死記録をすべて付け直してもらうことになり、迷惑をかけることになってしまいました…
タブレットがほぼ使われない
「記録がそもそもされない」ということ以外にも、データ入力という観点で事前に想定していなかったことがいろいろありました。その一つが入力デバイスです。結構複雑なことをやらないといけないシステムなので、基本的にはタブレットでサービスを使ってもらうことを想定していました。タブレットがないと困るかなと思ってわざわざタブレットも買って渡しました。
ところが蓋を開けてみると、ことごとく皆さんスマホを使われていて、タブレットの使用率が低いのです。現場は水にも濡れやすいし、タブレットはなんだか故障しそうなので、パッと入力しやすいのはスマホだというのが多くの生産者さんの見解でした。
システム開発をしたことがある方は分かると思いますが、タブレットとスマホは全然画面サイズが違うので、ユーザーフレンドリーなサービスを開発しようと思うと、タブレットとスマホは別のデザインを組む必要があります。
僕たちはタブレットでの記録を前提としてたため、スマホは「エサやりできればいいか」くらいのとても軽いテンションでしか捉えていませんでした。結果的にスマホ版は機能不足な状態にならざるを得ず、生産者さんからすると物足りなさを感じるものになりました。出荷記録はできないの？在庫はわからないの？といろいろご要望もいただきましたが、他の開発案件も多く、対応はどうしても後手に回ってしまいました。
毎回忘れられる投薬・消毒・ワクチンの記録
ここに関連して生じた課題がリスク管理周りの記録でした。エサやりと死んだ尾数、魚病の情報はそれなりに記録してもらえるのですが、投薬や消毒、ワクチンといったリスク管理周りの作業記録がどうしてもつかないんです。
生産者さんによってはワクチンをやらない、投薬をやらないという方もいらっしゃるので、限られた方のための機能ではあります。とはいえ、それでも大切な魚が死ぬリスクを避け、歩留まりを最大限まで引き上げるためにやっている大切な作業です。食の安全性やトレーサビリティに繋げようと思うとこのあたりの記録はとても大事になりそうです。やっぱり記録を付けてほしいという思いはありました。
原因のひとつはやはりこれらの機能をスマホで提供していなかったことでしょう。自宅や事務所に帰ってきてから、投薬の記録だけをシステムにつけるためにタブレットの電源をわざわざ入れる生産者さんが多いとは正直考えづらいです。
「要らない」機能で不完全燃焼
「こんなにたくさんの機能はいらないです。必要なものだけに絞ってくれた方がありがたいです」
東京で内水面養殖をしている生産者さんから言われました。他の生産者さんからも似たようなことを言われました。やり玉にあがったのは在庫管理の機能です。
飼料の在庫を管理することは原価管理には欠かせません。なぜならば給餌記録だけでは、記録の確からしさを担保できないからです。生産管理のアウトプットのひとつは生産コストの可視化です。つまり魚を育てるのにいくらかかったのかを明確にするということです。
給餌記録だけでは記録モレがあった時、二重記録があった時、記録間違いがあった時に気づけません。60kgしか餌を使っていないのに、600kgの給餌記録を間違えて記録してしまうかもしれません。在庫管理をしていれば、仕入量や在庫量と給餌量を比べることで、全体の整合性を確認することができます。人間は機械ではありません。必ず間違えます。だから間違えたときに気づくためのポイントをあらかじめ仕組みとして持っておくべきです。
しかしこの在庫管理に対する温度感が生産者さんによってなかなか違うのが現実でした。ワクチンは管理しなくていいけど、エサは管理したい人。仕入記録が付けられない（金額が分からない）ので在庫管理の仕組みがワークしない人、在庫管理自体にそもそも必要性を感じない人、様々でした。確かに小規模であれば、生簀ごとに給餌量をすべて確認することもできるので、在庫管理がなくてもなんとかなるという側面もあります。
原価をしっかり把握して経営に活かしたい生産者さんからはこの在庫管理の機能はとても重宝されました。一方で、一部またはすべての投与物について在庫管理することに興味・関心がない人からすると、この機能は完全に無駄です。結果「機能が多すぎてこんなに要らない」ということになってしまいました。
記録を修正するUXがすこぶる悪い
在庫管理が「要らない」となったのは、在庫管理の手前にある記録の修正導線にも原因がありました。記録が間違っていたときの修正がなかなか大変だったんです。記録を修正するためにはいちいち以下の操作が必要でした。
❶各生簀の画面にいく
❷修正したい日付まで移動する
❸給餌記録を開く
❹給餌記録を修正する
一カ所の給餌記録を修正するだけならこれでもできるかもしれませんが、後からミスに気付くケースもありますし、全体でみるといろいろ記録の整合性がとれていないというケースもあります。後者のパターンは多くの生産者さんで散見されました。
「200kg足りんみたい。200kg仕入したことにすればエラーは消えるかね」
こんなことをおっしゃる生産者さんもいました。仕様としては正しいですが、そんなことをしてもらうために在庫管理機能を作ったわけではありません。つぎはぎでその場しのぎの辻褄合わせのデータを入れ続けても正しい結果は得られません。
課題2：データ分析の価値を実感しづらい
2つ目の課題はデータ分析の価値を実感しづらいことでした。データの入力部分の開発が重たく、分析機能まで手が回っていなかったというところも正直あります。ただデータ活用はこのサービスの価値を決める本丸です。
種苗ごとに原価や生産効率を可視化できるのが一番の強みですが、種苗ごとの評価をしようと思うと出荷完了していないと分析になりません。養殖は池入から出荷まで通常2～3年かかります。3年間使わないと何も分析できない仕組みになってしまうと、3年間使うまでは忍耐の期間みたいになってしまいます。その間は価値を実感しづらく、記録の継続は難しくなってしまうでしょう。
渾身の週次レポートが大滑り
そこで開発したのがレポート機能です。月や週の単位でデータを合算し、簡単なレポートみたいなものを自動で発行してあげると、振り返りに使えるのではないかなと思いました。
週次レポートに出していたのはその週の給餌量や死んだ魚、出荷した魚の尾数です。機能が実装されたとき正直「かなりいい」と思いました。さっそく、自信満々でこんなの作ったんですよ！って生産者さんの方々にドヤりました。
しかし返ってきた反応は思いがけないものでした。
「ふーん、ありがとうございます」
「ごめんなさい、先週は忙しくて見てないです」
「一応あるので見てますよ」
全然刺さってませんでした…！！涙
参照点がないので解釈できない
給餌量や斃死数を合算して出すこと自体はやらないよりはやった方がいいと思いますが、問題はその数字を生産者さんが解釈できていないことでした。「ふーん」で終わってしまうのです。
「ふーん」で終わってしまうことの要因は3つあると思いました。まず一つ目は基準となる参照点がないことです。たとえば今週の給餌量が200kgだったよというデータが得られても、それがいいのか悪いのかがそれだけでは判断できません。
良い、悪いの判断ができないと、意思決定なんてできません。そしてそれを決めるのは参照点です。基準となる点に対して高いのか低いのかを判断することで、初めてデータには意味が出てきます。
たとえば理論的には500kg給餌すべきという参照点があれば、200kgは少なすぎるからダメだよねという話になります。基準になるデータがあれば、そのデータを参照点にして判断ができます。このケースだと給餌量が増えているので、いいペースで給餌できているとか、給餌量を増やしすぎているとかという解釈ができることになりますね。
指標が比較に適していない
ふたつ目の要因は僕の指標設計が甘かったということです。たとえば先ほどの給餌量。この数字を生簀間や魚種間で比べる画面を僕は作っていました。でもこれ、果たして意味あるでしょうか？
災害や病気、出荷で大きく尾数が減った場合、適切な給餌量は下がりますよね。水温が下がってもやっぱり給餌量は下がりそうです。分養（魚を複数の生簀に分けること）で尾数が減っても給餌量は減りますね。同じ魚種、同じ尾数でも、大きい魚がいる生簀の方が給餌量は多くなりますよね。大きさが同じなら尾数が多い生簀の方が給餌量は多くなります。魚はエサをあげることで成長します。トータルの給餌量が上がったからといって1尾あたりの給餌量も増えているとはいえません。
魚種、尾数、平均体重といった様々な変数によって数字が大きく変わる給餌量のデータはそれそのものを合算したり、平均したりしても実は何の意味もないのです。「So What？」に答えられないのだから、生産者さんからすると確かに「ふーん」以上でも以下でもありません。
「データをどう活用したいか」生産者にも答えがない
3つ目は期待していたよりも、強い意志やWILLが生産者さんから感じられなかったことです。仮説がないので、データをかみ砕いて解釈するための切り口が見つからないのです。ゆえに給餌量や斃死数から何かを読み取ろうとしても何も出てこない感じになってしまっていました。
もともとデジタルの仕事をしていたので、データを解釈した上で何らかの答えを導き出してくるというのは僕にとっては当たり前の基本動作でした。だから勝手にこの常識が養殖業界でも通用すると思っていました。
でも違いました。まずそもそも今回作っているプロダクトはデータを作るところからスタートしています。そして得られたデータをどう料理するかにも教科書的な答えがありません。webのアナリティクスの世界とは全然違います。webのアクセス解析であれば、データは勝手にたまっていきます。分析についてもCVRやCTRなど見るべき指標は概ね最初から決まっています。だから仮説も考えやすいし、ある程度場数を踏めばそれなりに分析ができるようになります。
何を分析できたらいいのか。いくら生産者さんに聞いてもその答えは出てきませんでした。「Why So?」を考えるためには、やはり仮説や切り口が必要です。
PMFを実現するためにやった7つのこと
PMFしていないという現実と向き合うのは、正直言って苦しかったです。役に立ちたくてサービスを開発しているので、「足りていない」ということがわかるのはなんとももどかしい気持ちでした。でも逃げずに課題の構造感を捉えようとしたことで、壁の乗り越え方はなんとなく見えてきました。現時点ではまだ開発途中なので、これで足りているのかどうかはまだよくわかりません。ただどんなことを考え、何をやっていたかを書き残しておくことには意味があると思うので、記録として残しておきます。
1.業務フローを定義する
まずサポートの仕方を変えました。水産業の現場で働く人たちの中にはスマホやタブレット、PCといったデジタル端末の操作に慣れていない方が結構いらっしゃいます。生産者さんが悪いというわけでは全くなく、その温度感・レベル感に合わせたサポートができていなければサービスはうまく活用してもらえないということを理解しておくことが重要です。いわゆるオンボーディングやカスタマーサクセスの部分です。
そこで初期導入のタイミングで誰がいつ記録を付けるのかを明確にしておき、必要なタイミングでサポートができるようにしました。
また、タブレットやスマホ操作に不慣れな方には高頻度で厚めにコミュニケーションすることで、つまずいてしまっているポイントがどこかクリアに把握できるようにしました。
2.問題を後回しにせず、その場で解決する
私「記録がついていないですね」
生産者さん「あとでやっておきます」
私「了解です！」
こういう会話もやめました。
記録がついていなかったり、間違っていたりする場合はその場ですぐに修正してもらいました。実際に操作してもらうことで操作感にも慣れることができます。とにかく後回しにせず、サポートしたときに積み残したものをクリアにすることで「記録できない」状態をリセットさせることに努めました。
ミスの原因も一緒に振り返ることができれば、どうすれば次に同じようなミスをしないかを生産者さんも考えられるようになります。
特に有効だと思うのは導入初期の1～2週間です。機能の全体感が頭に入っていないですし、ミスもしやすいのでサポートのレバレッジが効きやすいです。
3.負の体験を生み出しているUXを改善する
データ修正の導線やUXが悪いという問題も併せて改善しました。この問題はシンプルに自分の考慮不足が原因でした。生簀ごとの給餌内容を一覧表示し、そのまま修正できるようにしました。また各生簀の給餌内容を修正するときに日付設定を引き継げるようにしました。
これまではいちいちデータ入力を間違っていた生簀の最新日付の飼育画面に飛んで…みたいなことをしていましたが、データを修正したいニーズが発生したときにできるだけストレスなく修正ができるようにUXを見直しました。
まだ開発途上ですが、データ入力が日常業務として定着した生産者さんの入力負荷はだいぶ下げられると思います。
4.欲しいアウトプットに立ち戻る
投薬や消毒の記録がつかないのはスマホ版の提供がないという理由が大きかったと思いますが、スマホ版にならなかったのはそもそも機能が重たかったからです。単純にスマホ化すればいいというより、今の仕様が適切なのかを一度冷静に判断した方がいいと思いました。
記録のつけ方を都度生産者さんに案内しながら思ったのは「機能として過剰だった」ということです。生産者さんからすると「エサやりしたときに薬を混ぜました！以上！」って感じなのに、僕らが開発したものは「まず薬を投薬する日程を決めます。次に今日の投薬量をいれてください。投薬しなかった場合は投薬期間を見直しましょう」みたいなことをやっていました。言い換えてみると、生産者さんからすると正しいけどまどろっこしい機能です。
生産管理をすることで生産者さんが得たいものは理論的に正しく正確なデータ、ではありません。養殖の生産管理の文脈から考えれば、今の成長効率やコストを見える化し、歩留まりが低いのであればどういう対策を取れば望ましい結果になりそうなのかの示唆を得ることです。
その結果を得たいというゴール感からすると、リスク管理周りの機能は必要十分な量を超えています。投薬したという記録は重要ですが、そのプロセスはあまり重要ではないのかもしれません。
5.思い切って引き算する
目的から考えて不要な機能は逆にノイズになり、UXを低下させます。そうなるくらいであれば、引き算して機能は絞った方がいいと考えました。そんなわけでリスク管理周りの機能は欲しいアウトプットを見極めた上で、もろもろ全体的にダイエットさせました。その後、スマホ版への実装も行いました。
要件が複雑になりすぎて手に負えなくなっていた工場MPの機能開発でも引き算の発想が必要でした。MPを買ってくる場合はほぼその日か次の日に使い切るだろうという前提から、在庫管理をしないという引き算の意思決定をすることによって仕様を軽くし、何とか開発にこぎつけました。
エンジニアが頑張って作ってくれた週次レポートも生産者さんに役に立たないのであれば、置いていても意味がありません。たまたま読んだ本にこんなことが書いてあってハッとしました。
データをグラフや表にしてダッシュボードにただ埋めているだけでは活用されない。こうなるのは要件定義や設計に問題がある。どんな目的で誰がどう使うのかを事前に決める必要がある。
データ分析する人は勉強になると思うのでオススメです ↓
設計がダメなのであれば、微修正をしても仕方ありません。思い切ってすべて捨て、思想や哲学から根本的に見直すことにしました。
PMFを達成するために何をすべきかを考えるとき、どうしても人間の頭は足し算的な頭の使い方になりやすいです。今ない機能を足すことで喜んでもらおうと考えるわけです。でも必ずしも足し算だけが解であるとは限りません。
6.管理すべき指標を定義・提案する
データをどう活用すればいいのか、どんな分析をしたいかという問いに答えられないなら、分析はできません。そして生産者さん自身の中にもその答えがありません。となると、残された道はひとつだけです。どんな分析をすべきかの王道シナリオ、データ分析の型を僕たちが定義するという道です。
まずは何が重要なのかの観点を整理し、目的やゴールに対して適したKPIを選択、導入する必要があります。そのKPIを定期的にモニタリングしていけば、経営状況や飼育状況を客観的に把握することができるというのが最初のゴールです。そこで以下の3つの指標を主要KPIとして設定しました。
❶日間給餌率
給餌戦略を立て、早く効率よく成長させる
❷1万尾あたり斃死数
リスク管理を行い、死んでしまう尾数を抑える
❸B品率
B品（訳アリ品）の割合を下げ、高い単価で出荷できる魚を増やす
なぜこれらの指標を選んだのかはすべて理由があります。結構長くなってしまったので、詳しいプロセスや思考の過程は以下のnoteにまとめています。
7.課題解決のためのステップを示す
データはあるだけでは意味がないし、活用されるだけでもダメです。意思決定が変わることが何よりも重要です。指標を定義するだけでなく、その指標をいつ振り返るかを決め、改善するためのステップを具体的に提案します。利益を生み出すというゴールから逆算して、データの活用手順を設計するということです。
考えたのは計画と振り返りを分析期間で切り分けてしまう方法です。毎週見るレポートと毎月見るレポートでそれぞれ何を見るべきかを変えることで、日間給餌率の最適化が行えるのではないかと考えました。詳しくはこちら↓
このあたりはコンサルのキャリアや業務経験が役に立ちました。僕らなりのuwotech wayを示し、その型に乗ってデータを分析していけば、勝手に生産コストが下がるような仕組みをつくったわけです。データ分析のレールを敷いてしまうということですね。参照点がないことを課題に感じていたのも、生産者さんごとに計画を立てるサポートができれば課題をクリアできます。
バックナンバー
創業時からどんなことに悩み、何を考えてきたのか。恥ずかしながら、思うようにいかないことばかりです。それでも試行錯誤しながら、目の前のことに必死に向き合ってきた過程をこのマガジンではありのままに綴っています。
もし興味をもっていただけるのであれば、過去のバックナンバーも読んでみてください。
Vol1 事業領域のピボット
Vol2 問いのピボット
Vol3 手応えと未来への布石
vol4 山と谷
vol5 顧客体験のリ・デザイン
vol6 β版リリース
vol7 遠いPMF ←今ここ
8月にサービスローンチします！
まだまだ開発途上のサービスではありますが、なによりサービスに期待していただいている方と本気で養殖業と向かい合って、成功事例を一緒に作りたいと思っています。経験や勘も活かしながら、データを上手く使っていきたいと熱量高く思ってくださる方の力が必要です。一緒に悩み一緒に考え、一緒に未来を切り拓いていきたいです。
もし少しでも興味をもっていただける方は是非、資料請求でも無料トライアル（正式リリース後からですが）でも構いません。お気軽にお問合せください！
Twitterもやってます！
Twitterもやってます。プロダクトやサービスに興味を持っていただいた方はフォローいただけると嬉しいです。気軽にメッセージもいただければ！
この記事が気に入ったらサポートをしてみませんか？