この記事でわかること
-
事業仮説の検証を優先したいフェーズでRuby on Railsが選ばれる理由
-
水産業特有の複雑なドメイン（魚の規格・個体差）をモデルに落とし込む設計アプローチ
-
エンジニアが企画から参加する「施策オーナー制」が事業スピードを加速させる仕組み
電話やFAXでの取引がいまだ主流の水産業界。この巨大なレガシー産業の変革に、テクノロジーで挑むのが株式会社ウーオです。同社は、鮮魚のBtoBマーケットプレイス「UUUO（ウーオ）」と、水産卸向け業務改善SaaS「atohama（アトハマ）」を展開し、複雑な水産流通のDXを推進しています。
なぜ、彼らは技術選定としてRuby on Railsを選んだのか。そして、港ごとに異なる魚の名称や規格、日々変動する鮮度といった複雑なドメインに、どう立ち向かっているのか。
今回は、同社のプロダクト開発を牽引する取締役CPOの土谷太皓氏にインタビュー。エンジニアが企画から参加する「施策オーナー制」や、「パソコン閉じて、市場に行こう」というユニークなバリューは、いかにして事業の急成長を支えているのか、その開発戦略の裏側に迫ります。
土谷 太皓
株式会社ウーオ 取締役CPO
神奈川県出身。新卒でクックパッド株式会社に入社し、レシピサイトやクックパッドAndroidアプリのサービス開発を担当。PT. COOKPAD DIGITAL INDONESIAへの出向を経て、より上流の水産業でインパクトを起こしたいと考えウーオに入社。
目次
なぜ水産業DXにRailsを選んだのか？ 事業仮説の検証を最優先する技術選定
まず、事業内容について改めてお伺いしたいのですが、「UUUO」と「atohama」という2つのプロダクトがあるのですね。
まず、「UUUO」が鮮魚のBtoB向け水産マーケットプレイスです。UUUOは、産地の港にいる仲買人の方々が出品した魚を、全国の飲食店やスーパー、市場関係者などが購入できるモデルです。特徴として、売り手からは手数料をいただかず、無料で掲載いただけます。
もう一つの「atohama」は市場内の取引を効率化するSaaSなのですね。
はい。お客様との受発注を効率化するために使っていただく月額課金モデルのサービスです。この2つのプロダクトは、裏側のデータベースやソースコードを共有したモノリス（※1）な構成で作っています。
※1 モノリス：すべての機能が単一のプログラムとして構築されたアーキテクチャ。
モノリス構成にしているのには、何か理由があるのでしょうか？
主な理由は2つあります。1つは「atohama」と「UUUO」でデータ連携を構想していたこと、もう1つは人的リソースの流動性を高めたかったからです。
開発リソースが限られている中で、UUUOとatohama、どちらのプロダクトにもエンジニアが対応しやすい体制を維持したいと考えました。
その上で、バックエンドにRuby on Railsを選ばれた理由についてお伺いできますか。やはり複雑なドメインを扱う上で、オブジェクト指向言語が適していたのでしょうか。
そうですね。私自身、前職からRailsを長く書いていたのもありますが、それ以上に事業ドメインの理解やプロダクトの仮説検証に集中したかったのが一番の理由です。
水産業のドメインは複雑なので一から知る必要がありましたし、プロダクトの形はどんどん変わるだろうと想定していたので、開発のインフラに時間をかける余裕がありませんでした。最初のプロトタイプはReact Nativeで書いたりもしましたが、本格的な開発ではサービスの検証スピードを優先しました。
サービスの価値検証を最優先するための選択だったのですね。
はい、Railsはgemエコシステム（※2）が充実しているので、やりたいことがあればgemを探して素早く実現できます。認証やデータ処理といった一般的な機能をゼロから開発する必要がなく、私たちが本当に注力すべきサービス独自の価値を考える開発に集中できるので非常にありがたかったですね。
※2 gemエコシステム：Ruby言語で利用できる再利用可能なプログラム部品（gem）の豊富な集合体と、それを取り巻くコミュニティやツール全体のこと。
複雑なドメインの壁。全国2,700の港に存在する独自の商習慣との戦い
土谷様はもともと食品業界に携わられていたかと思いますが、「水産業」というドメインならではの複雑さについて、どのように感じていますか？
まず、関わるプレイヤーが圧倒的に多いですね。漁師さんから漁業協同組合、産地の仲買、市場の荷受や仲卸、そして小売店、飲食店まで、そのすべてが私たちの顧客になり得ます。誰にどんな価値を届けるかで、プロジェクトの形が全く変わってくるのが難しさの一つです。
プレイヤーがそれだけ多いと、最初のターゲットを定めるだけでも大変そうです。
それに加えて、地域による文化の違いも大きな課題です。例えば、魚の呼び方が全国で全く違うんですよ。ブリの幼魚を関西では「ハマチ」と呼びますが、関東では同サイズを「イナダ」と呼びます。もっと言えば、関東で「ハマチ」というと養殖のブリを指すことが多く、商品の価値も価格帯も全く変わってしまいます。
呼び名一つでいろいろなことが変わってくるんですね。
他にも、サイズの定義が地域によってバラバラです。多くの場合、発泡スチロールに何匹入っているか、何列で並んでいるか、といった現場のオペレーションに基づいて独自の呼び名が生まれています。例えば、ある港では「一番」（※3）というサイズがあったり、別の港では「二段」（※4）というサイズがあったりします。
※3 一番（いちばん）：発泡スチロールに魚を詰める際のサイズ規格の一つ。港によって定義は異なる。
※4 二段（にだん）：発泡スチロールに魚を2列で並べる詰め方。
そういった地域ごとの慣習が無数に存在する中で、どのようにプロダクトに落とし込んでいったのでしょうか。
初期はとにかく売り手である出品者さんの開拓が最優先だったので、彼らが混乱しないように、それぞれの港の呼び名で出品できる形に合わせにいきました。例えば、前回「一番」で出品した規格をコピーして、価格だけ変更して再出品できるようにするなど、UI/UX（※5）の工夫で、売り手と買い手の認識のズレを埋めていきましたね。
※5 UI/UX：UIはユーザーインターフェースの略で、ユーザーが製品と接する画面デザインなど。UXはユーザーエクスペリエンスの略で、製品を通じてユーザーが得る体験全体を指す。
買い手側には、それが具体的にどのような商品か伝わるように、アプリ上で情報を“翻訳”して表示するわけですね。規格や呼称もそうですが、「鮮度」というのも非常に複雑な要素だと思います。
おっしゃる通りです。ただ、その「鮮度」をどう伝えるかは難しく、単に水揚げからの経過時間という単一の軸だけでは、ユーザーの本当のニーズに応えられません。そこで私たちは「鮮度評価機能」を実装しました。例えばスーパーマーケットのバイヤーなら、「刺身用」で探しているのか、「焼き魚用」で探しているのかで求める鮮度は全く違います。
確かに、焼き魚用なら多少時間が経っていても価格が安ければ問題ない、ということもありますよね。
なので魚種ごとに評価の軸を設定したり、用途に応じた分類ができるように設計しました。単なる学術的な分類ではなく、スーパーの担当者さんが『定番魚』と『珍しい魚（特殊種）』を分けて探すような、実際の業務に即したカテゴリー分けを細かく行っています。
この軸の設計は、実際に魚の売買をしている社内のセールスチームとエンジニアが一緒になって考えました。常に「何のためにこの機能を作るのか」という目的を理解することが、柔軟な設計に繋がっています。
規格や鮮度以外にも、多くのプレイヤーが関わる「組織」の管理も複雑そうです。このあたりはRailsのモデル設計で何か意識されたことはありますか？
まさにおっしゃる通りで、「組織」モデルの設計は意識しました。買い手、売り手、さらに魚を提供する「荷主」など、多くのプレイヤーがいますが、それぞれ役割が違います。例えば、飲食店の組織はクレジットカード決済ができてヤマト運輸で受け取れるけれど、他の組織はそうではない、といった違いが後からどんどん出てくることが予想できました。
将来的な拡張性については、どのように担保したのでしょうか。
例えば「決済方法」や「配送方法」といった機能を、特定の組織モデルと1対1で決め打ちで実装するのではなく、うまく抽象化して、どの組織とどの機能の組み合わせでも柔軟に対応できるように意識しました。
特定のデザインパターンを厳密に適用したというよりは、オブジェクト指向の基本的な考え方に沿って、将来の拡張性を担保する設計を心がけた形です。
今お伺いした「組織」モデル以外に、『魚の規格』や『個体差』といった要件をRailsのモデルに落とし込む上で、特に工夫された点はありますか？
「魚の規格」に関しては、魚種のモデルとは別に「規格の抽象モデル」を作り、柔軟性を持たせています。さらに「atohama」では、顧客ごとに異なる値段の設定ができるようにもしました。
企画から実装まで一気通貫。「施策オーナー制」で事業スピードが加速
開発体制についてお伺いします。エンジニアが企画段階から関わる「施策オーナー制」を実践されているそうですね。どのようなメリットを感じていますか？
基本的にはメリットしかないと考えています。技術的な観点で言うと、企画段階からエンジニアが入ることで、技術的な制約や実現可能性の判断が非常に早くなります。企画やデザインが決まった後で「やっぱりそれ、実装にすごく時間がかかります」といった手戻りがなくなるんです。
なるほど。最初から現実的なラインを全員で共有できるわけですね。
それによって、ビジネスサイドから「それなら今の仕組みに少し手を加えれば、すぐに検証できるのでは？」といったアイデアが出てきやすくなります。さらにエンジニアから「まずはこのフラグを立てて、一部のユーザーにだけ見せて2週間試しませんか？」といった最小限の開発での価値検証を提案しやすくもなります。
それは事業スピードに直結しそうですね。全体的な開発工数で見た場合、やはり削減効果は大きいのでしょうか。
大きいと思います。リリースしてから「思っていたのと違った」というコミュニケーションの齟齬が、早い段階で解消されやすいからです。例えば、何か機能を追加するにしても、「そのためにはこのデータが必要ですが、そのデータは誰がどうやって入力するんですか？管理画面が必要ですよね？」といった、技術的に押さえるべきポイントを事前に洗い出せます。
素晴らしい仕組みですね。この体制を維持する上で、リソース配分などの工夫はありますか？
事業フェーズに応じて柔軟に変えています。以前は一つのプロジェクトで複数の機能を開発していたので、1機能あたり2名のエンジニアをアサインできていました。しかし今はプロジェクトが増えた分、一つのプロダクトに関わるエンジニアの数は以前より少なくなっています。その時々のリソース状況に合わせて、最適な体制を模索し続けることが重要だと考えています。
「施策オーナー制」は、新しく入ったメンバーが複雑なドメインをキャッチアップする上でも役立っているのでしょうか。
そうですね。Railsを採用した理由の一つに、他の言語を使っていた人でもキャッチアップしやすいという点がありましたが、この体制もドメイン理解に大きく貢献していると思います。
技術的なキャッチアップのしやすさに加えて、ドメイン理解にも繋がるということですね。それは具体的にどのような仕組みなのでしょうか？
一人のエンジニアがフロントエンドだけ、バックエンドだけ、と分業するのではなく、一つの機能について企画から実装まで一気通貫で担当します。そうすると、必然的にRuby（Rails）にも触れるし、水産業のドメインにも深く向き合うことになります。
なるほど。機能のスペシャリストになることが、そのままドメインのスペシャリストになることに繋がるわけですね。
新しく入ってきたメンバーも、まずは特定の機能のオーナーになってもらうことで、その領域のドメイン知識を素早くキャッチアップできます。そうしてチームに溶け込んでもらいやすいというメリットもありますね。
「パソコン閉じて、市場に行こう」現場の一次情報がプロダクトを強くする
チームのバリューについてもお伺いしたいです。「パソコン閉じて、市場に行こう」というバリューが非常にユニークだと感じました。
これはチーム全員が大事にしている価値観ですね。最近もエンジニアチームで京都の舞鶴港を訪問しました。
エンジニアの方も現場に行かれるのですね。
はい、現場に行かないと分からないことが本当に多いんです。例えば、出品者さんがどういう環境でアプリを使っているのか。市場でアプリを使おうとするとき、まず手が濡れていますし 、港によってはWi-Fiなどの電波が弱い場所も多い。そういう場所だと「アプリの起動が遅い」といった声を直接聞くことになります。
なるほど。実際の現場にいくと、起動スピードの重要性を肌で感じられるということですね。
出品者の方々が、魚を仕立てながら注文を確認し、どこに何を振り分けるか、というスピード感の中で作業されているのを見ると、「これを早くしなきゃ」と心から思えます。ユーザーが置かれている状況を身をもって体験することで、開発の優先順位や求められる品質レベルへの解像度が格段に上がるんです。
他に、エンジニアの成長やプロダクトの品質向上に繋がっているバリューはありますか？
「技を磨き、持続可能なものづくりを追求しよう」というバリューも大切にしています。スタートアップなので、事業成長のために技術的負債を積む判断をすることもありますが、そればかりでは成長がありません。その時々で最善を尽くすのはもちろん、その「最善」のレベル自体を上げていこう、という意図を込めています。
素晴らしい考え方ですね。具体的に、技術的負債を解消するための取り組みなどはされているのでしょうか。
週に1回「品質向上タイム」という時間を設けています。日々の施策開発とは別に、テストカバレッジの向上やアーキテクチャの改善など、普段なかなか手の付けられていない課題にエンジニア主導で取り組む時間を確保しているんです。
品質を高めるためには、新しく入社された方、特にRubyやRailsの経験が浅いエンジニアの方への技術的なサポート体制も重要かと思います。何か社内で取り組んでいることはありますか？
私たちは「とにかくコードを書く」という実践が一番だと考えているので、随時Meetなどで繋いでペアプログラミングを行っています。例えば、フロントエンドがメインのエンジニアにも、簡単なモデリングやAPIの開発をまるっとお任せするようにしています。
実践で学んでいくスタイルなのですね。
オフラインで集まる機会があれば、RSpec（テストフレームワーク）の書き方を全員で同じ画面を見ながら勉強したりもしました。まずは実践してもらうことを重視していますね。
新しいインフラを創る。レガシー産業におけるエンジニアリングの醍醐味
改めて、ウーオで働くことの面白さや、複雑なドメインに挑む醍醐味について、お聞かせいただけますか。
水産業は非常に複雑ですが、日本が世界に誇れる産業であり、市場規模も大きいです。そして、昔からほとんど仕組みが変わっていない業界でもあります。そうした領域で、自分たちの技術で新しい情報のインフラ、デジタル市場を創造していくのは非常にやりがいがあると思います。
実際に市場へ行くと、お客様からも「徐々にインフラになりつつあるね」といった声をいただけるので、業界の新たな仕組みを自分の技術で作っていけるのは、本当に面白いと思います。
両サービスの現在の普及状況や、導入されたお客様からの反響はいかがですか？
マーケットプレイスの「UUUO」は、ネットワークが順調に広がっており、産地の出品会社様は全国で200社以上、購入側の企業様も500社を超えました。今では、海に面する全ての都道府県からの出荷実績があります。
電話やFAXが主流だった業界で、これだけデジタルサービスが受け入れられたのはすごいですね。成功要因について、もう少し詳しくお伺いできますでしょうか。
プロダクト面では、やはりエンジニアが足を運んで現場に行っていることで顧客の課題をすぐキャッチできることに加えて、自分たちが元産地の仲買でありプレイヤーであったことも大きいです。つまり、社内にユーザーとほぼ同じ目線で語れる人(≒ドメインエキスパート)がいるんです。
元プレイヤーとしての知見が社内にあった、ということですね。「atohama」の方はいかがでしょうか。
「atohama」は現在、全水産卸売市場（約100市場）への導入を目指している段階で、主要な卸売市場にはほとんど導入いただいています。まだまだこれからのフェーズですが、導入いただいた企業様からは非常に大きな反響をいただいています。
最も劇的だったのは、働き方の改善です。ある卸売業者様では、これまで早朝2時出勤だったのが、atohama導入後は午前5時出勤で業務が回るようになりました。就寝時間が早まったことで、「退勤後に友達と遊べるようになった」という若い方の声も聞いています。
ユーザーの仕事がラクになったり、「インフラになりつつある」と直接フィードバックをもらったりするのは、何よりのやりがいですね。応募されるエンジニアは、それらの事業に魅力を感じたり、魚自体に興味を持ったりする方も、多いのでしょうか？
魚に興味があるというより、「食べるのが好き」という人が多いですね。ただ、仕事としてやっていくと、魚の名前を覚えたり、自分でサービスを使って買ってみたりと、どんどん魚好きになっていくと思います。僕もこの前マグロを買いましたし（笑）。
それに、水産業は知れば知るほど「まだこんなに知らないことがあるんだ」と発見の連続で、エンジニアとしても知的好奇心がすごく刺激されるドメインだと思います。
仕事を通じて食の楽しみも、知的な探究心も満たされるわけですね。改めて、土谷様が考える「ウーオでエンジニアとして働くこと」の最大の魅力とは何でしょうか。
市場に行くと、自分たちのプロダクトが徐々にインフラになりつつあるという声を直接いただけます。そうやって自分の技術が社会の仕組み作りに貢献していると実感できるのは、この仕事の大きな魅力です。知れば知るほど奥深い水産業の世界で、レガシー産業の変革に面白さを感じるエンジニアの方々と、ぜひ一緒に挑戦していきたいです。
ライター
