株式会社ウーオ
水産業の新しいインフラをつくりたい
今回はRubyBizグランプリで大賞を受賞した「UUUO(ウーオ)」について、株式会社ウーオ CPOの土谷 太皓氏に話を伺った。
ウーオは2016年に設立、「日本の水産業にとって、新しい流通をつくる」ことをミッションとしている。
創業者の板倉 一智氏は島根県岩美町出身。岩美町には網代港があり、板倉氏の祖父、曽祖父も漁船を持っていて水産業はごく身近なものであった。
就職して地元を離れていたが、帰省するたびに水産業の衰退を目の当たりにし、水産業を元気にしたいとの思いから起業した。
ウーオは東京にも拠点はあるが、本社は広島にある。
広島は、地元鳥取のある中四国地方で最大の都市であるため、最大の消費地でもある。
そのため、買い手が多く集まるので、この地を選んだそうだ。
実際にセリに参加しながら課題を発見
まずは水産業の課題を調べ解決策を模索するために、実際にプレイヤーとして取引に関わるところから始めたそうだ。
プレイヤーといっても誰でもすぐに参入できるわけではなく、資格が必要であり、しかも簡単に取れるものではない。
代表自ら何度も港に通い、想いを伝え、信頼を得ていった。
努力が実り、2018年に鳥取港の仲買免許と賀露港の買参権、2019年に網代港の買参権を取得できた。
網代港での新規買参権取得は約20年ぶりだったそうである。
ようやく市場に出れるようになり、プレイヤーとなって実際に魚をセリで買い付け、豊洲や大阪、名古屋など全国の市場に出荷した。
流通の一プレイヤーとして魚を売買していると、課題や、オペレーションでボトルネックになっているところが明確になってきた。
売り手と買い手の取引先拡大が円滑にできておらず、取引先が固定化してしまっている。
新しく販路を作る仕組みが必要と考え、UUUOで解決しようと考えた。
取引経験を活かしたサービス作り
作ったサービスに、自ら買い付けた魚を出品してみるところから始めた。
これまで他の業者と同じように電話やFAXを使って取引していた買い手に、作ったアプリを紹介し使ってみてもらった。
売り手も自分たちだけではなく、隣の島根や徳島、京都などいろいろな産地を回ってアプリを紹介し、使ってみてもらった。
そうやって少しづつユーザーを増やすところから始めた。
着実にユーザーが増え、現在では売り手は約120業者、ほぼどの都道府県にもいる状況で、買い手も約450社ぐらい、さらに飲食店との取引も増えているそうである。
水産業では、今も電話やFAXでダイレクトにやりとりすることが多い。
この方法では、買い手のニーズ、今回購入した以外にも実はこんな魚が欲しい、実は売り手はこんな魚も持っているといった情報は伝わりにくい。
UUUOは「スマホでつながる水産市場」というキャッチコピーのとおり、売り手も買い手もスマホアプリひとつで売買できる。
魚を売買するアプリならエンジニアであれば簡単に作れそうと思われるかもしれない。
しかし、魚特有の複雑な事情もある。
産地によって商品の規格や魚の呼び名が違ったりもする。
人間でも体重が同じでも身長が違うように、重さが同じ魚でも大きさはさまざまである。
同じ種類で同じ重さの魚であっても、まったく同じものはない。
さらに生食用、加熱用といった区分があり、魚の種類によって区分が違うなど、工業製品とは違う難しさもある。
具体的には、鮮度が問われる、場合によっては生きたまま輸送するケースもある。
珍しい魚を売買する場合、買い手がその魚に詳しいとは限らない。
例えば輸送途中で水が抜けるなどして重さが変わるものもあり、出荷時に正しく計測していても、到着した時に重さが違うこともある。
買い手が事情を知らなければ、不正をされたと思ってしまうかもしれない。
そういった問題が生じた場合には、ウーオが間に立って解決を手伝う。
そんな時、実際にセリに参加し、魚を売買した経験が活きるそうだ。
また、そうやって何度も売買しているうちに、取引のコツを掴んで自分で解決するようになったユーザーさんもいるそうである。
「売買のトラブルであったり、重さが書いてあるのと違うとか、思った鮮度感じゃないみたいなトラブルが発生したときは、ウーオが間に入ることで安心して取引できるっていうところも、このサービスの価値になってます。
こういう時にも実際にセリに参加し、取引した経験が活きています」(土谷氏)
既存の仕組みと共存しながら販路を拡大
UUUOで買った魚も、物流は既存の仕組みを利用している。
売り手側からすると買い手のついている魚も通常の市場に送る魚と同じように送り、買い手側からすると、市場で買い付けた魚と一緒に市場の自分のところに届いている。
基本的に市場では大きなロットで魚の売買をしている。
大量に取れる、大量に売れる魚は市場で取引されるが、少量しか取れない魚など、市場に届かない魚も多い。
一方、少量でも良いから珍しい魚を常に探している買い手も多いが、小さいロットの魚を市場が取り扱うのは難しい。
また、いつも市場で扱っている魚でも、漁場の天候などで必要数入って来ないこともある。
そんな時、不足分をUUUOで買うということもできる。
市場で買うか、UUUOで買うかではなく、市場ではできなかったことをUUUOが補完するような形で実現しているところも受け入れられやすかったところだろう。
売り手も買い手も納得できる価格で取引
売り手からすると、市場では魚が高く売れなくなってきているという問題があるそうだ。
魚は基本的にセリで売買される。
いわゆるオークションのような形で、高くても良いから買いたい顧客がいるところに持っていくと高く売れる。
持っていった市場とは違う市場に、そのような顧客がいるかもしれない。
UUUOでは国内どこからでも買えるため、買いたい人の目に止まる確率は高くなる。
このため、買い叩かれることなく、両者が満足できる形で取引可能である。
手厚いサポート
スマホアプリを使った売買のプラットフォームの提供だけではなく、そこで売買する際のトラブルに関しても手厚くサポートしている印象だ。
そこはやはり仲買免許を取得し、実際に取引していた経験があるからだろうか。
「魚に関するトラブルは、仲買いの免許を取得していたこともあり、実際にプレイヤーとなってやってたので、社内に知見がありました。」(土谷氏)
例えば、「鮮度が悪い」というクレームがあった時、送ってもらった写真をもとに、この魚でこの感じなら鮮度はどうなのかという判断は、プロでなければ難しい。
その判断した鮮度具合をもとに売り手と値引き交渉するにも、かつて取引した経験が活きているそうだ。
「安心して買っていただきたいのですが、やはり一度良くない魚が来ちゃったりすると、次回使用するのを躊躇してしまいます。
そんな時に真摯に対応することをとても大切にしています。
実際、市場の中で対面でやってる時でも、「前回あれ悪かったよ」「じゃあ今回負けとくね」みたいなところで信頼がどんどん積み上がっていったりします。
何かあっても、継続的にコミュニケーションしながらきちんとリカバリーすることを大事にしています。
取引経験から、買い手の気持ちもわかるし、売り手の気持ちもわかる、この魚にはこんなクレームが来るという知見があるなど、取引経験が活きています。」(土谷氏)
アプリでは、出品者が出品する魚に評価をつけられる。
例えば鮮度の評価、生食の可不可、活魚、水揚げからの日数などを登録できる。
「実際に私たちが売っていた時に、よく電話で聞かれたことを落とし込んでいったところがこのサービスの特徴かもしれません。」(土谷氏)
Rubyを採用した背景
このようなサービスを作ると決めた際、Rubyを採用した理由は何だったのだろうか。
採用理由について土谷氏は以下の点をあげてくれた。
立ち上げ当時、一人でバックエンドを開発していた土谷氏が慣れ親しんだ言語であること、
今後、他の言語を使っていた人が入ってきてもキャッチアップしやすい言語であること、
水産業が複雑なドメインモデルであるため、オブジェクト指向の言語だと実装しやすいと思った、他にも、今後サービスが大きくなっていったときに拡張しやすいなどを考慮してRuby on Railsを採用したそうである。
Rubyを使って素早く開発し、機能の作り込みに時間を充てる
実際Rubyを使ってみてどうだったのだろうか。
「サービスを素早く立ち上げて、作ったサービスの価値検証に時間を使いたかったので、フレームワークに任せて開発スピードをあげることができたのが非常に良かったと思っています。
豊富なgemやいろいろなエコシステムも充実していて、こういうことをやりたいみたいなことがあった時、gemから探して取り入れて、やりたいことを実現していくみたいなところが非常にやりやすい環境だったかなと思っています。」(土谷氏)
ウーオでは、フロントエンドの担当とバックエンドの担当にわけるのではなく、一人の人が一つの機能を担当している。
「フロントエンドだけ、クライアントサイドだけ書くとかでもなく、APIも開発してもらっています。
そうすると必ずRubyに触る機会がある環境なので、このような環境に身を置いてもらうっていうところが、水産のドメインを一番素早くキャッチアップしやすい状態につながっているのかなと思っています。」(土谷氏)
一人の人が一つの機能の要件定義から実装まで担当することによって、その機能に詳しくなれる。
水産業は複雑な仕組みも多く、覚えることも膨大で一人の人が全てに詳しくなるのは難しい。
一つの機能に詳しくなると、その知識を膨らませる形で別の機能も作りやすくなる。
新しく入ってきた人もその機能のスペシャリストになることによって、チームに溶け込みやすいというメリットもあるそうだ。
「施作オーナー制を取っていて、その機能の全体のディレクション、実装も含めてリリースまで担当しています。
具体的には、仕様の詳細設計や、スタイルの実装、QA、リリースする前のテストなどをリードしてもらっています。」(土谷氏)
リリース後もずっと担当するわけではなく、別の機能の作成に移る。
リリースした後アップデートが必要になった際には他の人が担当することもある。
そうすることによって、ドメインに詳しくなっていき、今後他の人が担当することを意識して開発してもらうことにより、機能が属人化することを防いでいる。
ユーザーの声からつくられたatohama
ウーオは今後どのようなことをしていくのかについて伺ったところ、新しく開発したサービスとその融合について話してくれた。
新しいサービスとは、UUUOのユーザーから受けた相談をもとに開発し、2022年8月に提供された「atohama(アトハマ)」である。
atohamaは水産卸売企業向けに入荷案内・受注業務を支援するスマホアプリだ。
UUUOに出品した商品も、市場で売買している商品と一緒にこれまで通りに在庫管理されているため、UUUOで売れた商品の消し込みは手作業でする必要があった。
手作業で在庫管理をしていると、間違えて過剰受注してしまうことも起きたりする。
UUUOは市場での取引とは別に魚を売買するサービスであったが、atohamaは市場で取引する魚の管理にも使える
これまでアプリを使ったことがなかった人がUUUOのユーザーになり、アプリを使って良かったから、こんなサービスも作ってほしいという要望を出してくれるようになった。
使いやすくてユーザーに受け入れられるアプリを開発してきたからこそ、このような声をいただけたのではないだろうか。
UUUOとatohamaを連携して、売り手もより多くの顧客に売ることができ、買い手もより多くの商品の中から選ぶことができる。
そして、どちらも簡単に在庫管理できる、そのような仕組みを実現したいそうだ。
UUUOでアプリに慣れ、良さを知ったユーザーがアプリを使ってさらに業務改善をしたくなる。
自らアプリを使って取引を行い、ユーザーの痒い所に手が届くアプリを提供できたからこそ実現できたのではないだろうか。
※本事例に記載の内容は取材日時点(2023年12月)のものであり、現在変更されている可能性があります。
事例概要
- 会社名
- 株式会社ウーオ
- 開発した主なシステム
- スマホでつながる水産市場 UUUO
- 利用技術
- Ruby
- Ruby on Rails
- Flutter
- ニーズおよび解決したかったこと
水産流通には既存商流があります。既存商流では産地から消費地に水産物と情報が一方通行で流れるため、需要の把握や供給量の可視化がしづらい環境にあります。
可視化ができないことにより、特に買いたい人が買いたいものを買いたい時に手に入れられないことが課題です。飲食店では値段や鮮度、漁法、産地の情報もないまま、購入することもあり、場合によっては時化などで急に入荷できないということもありました。また産地側も固定化された商流の中で売ることがメインなため、売り方や販路の拡大がしにくく付加価値が付きにくいことが特徴です。
ウーオでは、水産流通プラットフォーム「UUUO」を通じて、情報や需要、価格などが明確な状態で売買が行われます。
これにより、「実は地方から金目鯛が欲しかったA会社」の存在が「UUUO」上で見えるため、今まで届いていなかったところに提供可能になり、売り手の「高く売りたい」と買い手の「安く買いたい」需給の最適化を通じて適正な価格が形成すると考えます。
- Ruby採用理由
この構成(主にRails + Heroku)にしたのには、水産業におけるプロダクト開発(≒価値の具体化)に集中し、標準的に備えたい仕組みや機能とともにサービスを素早く立ち上げて価値検証に時間を使いたかったからです。
Ruby未経験のエンジニアやインターン生中心に技術のフォローがしやすい、豊富なGemがあったりエコシステムが充実しているのも理由です。
水産業は魚という商材の名前(方言含む)や規格モデル、BtoBの物流モデルを始め非常に複雑なドメインだったため、OOPのポリモーフィズムとカプセル化を用いて各概念を適切にモジュール化したり等、拡張性と柔軟性をシステム全体にもたらしてくれると考えたためです。
- Ruby採用効果
ウーオでは、頻繁にエンジニア、プロダクトマネージャーが現場に行って観察を行います。 開発の比較的多くの時間を現場に入り込んで業界・ユーザ理解に比重が多く置かれる場面もあり、プロダクト開発に集中しやすい技術選定だと思います。
採用候補者の方へのアプローチ時もあまりRubyという枠では絞っていなくて、プロダクトづくり、ユーザに価値を届けること、課題解決が好き、と言ったメンバーが集まっていて、入った後にキャッチアップしていってくれています。
ドメインの複雑性を内包するロジックはなるべくカプセル化し外から扱いやすくする工夫を随時していっています。 これはどの言語を扱っても当然行うべきことだと思いますが、プロダクトや事業のフェーズに合わせて、エンジニアが柔軟にロジックの形をアップデートしていきやすい言語だなと思っています。