Ruby biz 2023 大賞受賞に寄せて、水産流通における Ruby や Ruby on Rails の活用についての話

こんばんは、土谷(@taihaku0415)です！

ウーオは、11月8日に行われたRuby biz Grand prix 表彰式でありがたいことに大賞をいただきました。個人的には、プログラミングを始めた一番最初の言語がRubyだったのもあり、非常に感慨深かったです。

せっかくいただいた大賞をきっかけに、ウーオの開発のことを知っていただければなと思い、ブログを書きました(11月最終日になってしまいました)。

ウーオは、

水産マーケットプレイスのUUUO (サービスURL: 【UUUO】飲食店必見 100以上の産地から直送スマホで鮮魚仕入れ )
水産卸業者の業務効率化 SaaS atohama (サービスURL: UUUO | スマホで繋がる水産市場)

の2つのサービスを開発しています。

まず、UUUOとatohamaの使用技術を非常に簡単にご紹介すると、ユーザ側のクライアントサイドのアプリから叩かれるAPIサーバーは全てRuby on Railsを採用しています。APIサーバーはWebとWorkerからなり、非同期関連のジョブはSidekiqで構築しております。

また、基本的にインフラはPaaSのHerokuを使っており、データベースを始めエラー検知、データ解析、モニタリング等を目的としたツール等もHerokuのAdd onで実現しています。

社内で利用している管理画面(sashimori)はRailsのView(Haml)を利用してフロントを構築しています。

このブログでは、2019年に入社してから今まで、ウーオの開発でRuby+周辺技術*1を利用していますが、そこの背景や意図について書きたいと思います。

1. プロダクト作りに集中したかった

この構成(主にRails + Heroku)にしたのには、水産業におけるプロダクト開発(≒価値の具体化)に集中し、標準的に備えたい仕組みや機能とともにサービスを素早く立ち上げて価値検証に時間を使いたかったから*2、です。

水産業は専門性が高く、開発者も身近に感じづらい領域で、ユーザの課題1つとっても理解するために乗り越えるべきハードルが高い業界だと思います。

それは、具体的には

関わるプレイヤーが多く多岐に渡る
電話やFAX等の通信手段で売買が行われる
特有の商習慣があり参入しづらい

等、サービス開発するにおいて私自身も、どこから手をつけたらいいかわからないことだらけでした。

ウーオでは、頻繁にエンジニア、プロダクトマネージャーが現場に行って観察を行います。開発の比較的多くの時間を現場に入り込んで業界・ユーザ理解に比重が多く置かれる場面もあります。詳しくはパソコン捨てて、市場に行こう、港でパフォーマンスチューニング等をご覧ください。

2. 入社後のキャッチアップのしやすさ

採用や組織づくりという観点で言うと、ウーオでは、強弱はあれど実は Ruby に拘らず、一定のバックエンド・サーバーサイドの開発経験があれば、ウーオの事業やプロダクト開発に共感してくれるメンバーを積極的に採用してきました。なので、採用候補者の方へのアプローチ時もあまりRubyという枠では絞っていなくて、プロダクトづくり、ユーザに価値を届けること、課題解決が好き、と言ったメンバーが集まっています。

水産未経験は当然ですが、RubyやRailsも未経験だったというメンバーが多くいます。

土谷太皓氏は「Rubyのおかげで会社が成長できている。特にプログラミング未経験の人でも、Rubyを使うことで楽しみながら開発できていると感じる」とコメント - https://news.yahoo.co.jp/articles/7eb969867bdcda6b7dded6ae96ed05c30ea0afcb より引用

(プログラミング初心者ではなく、Rubyが未経験という意味で表彰式のスピーチでは話をしたつもりでしたが...笑) 上の記事にも書いていただいているように、実際今いるメンバーの内7割のエンジニアはウーオに入ってからRubyを書き始めました。

キャッチアップのしやすさの1つに、コミュニティやエコシステムが成熟しており、一定のレベルまでのキャッチアップまではすぐできるように支援してくれるドキュメントも豊富ですし、

https://www.ruby-lang.org/ja/documentation/
Ruby on Rails ガイド：体系的に Rails を学ぼう (よく入社するメンバーでRails未経験のメンバーに共有しています)

何か実現したい解決策がある時も豊富な Gems からパッと探して取り入れることもできると思います。

納品書・請求書作成作業を早くしたsashimoriという管理画面のお話｜ウーオ
- 入社直後に開発した管理画面でも GitHub - prawnpdf/prawn: Fast, Nimble PDF Writer for Ruby を利用してサクッと納品書や請求書の作成機能ツールを作れました
speakerdeck.com
- atohamaでプール型のマルチテナントを実現

もちろん、Ruby未経験だったメンバーにとっての難しいところもありますし(ex. 自由(?)に書け過ぎる)、チームとしては社内の開発ガイドラインを設けてみんな一定のルールのもと実装ができるようにしていたりもします。

3. 複雑なドメインロジックとうまく付き合っていきたい

冒頭にも書いた通り、水産業は多くの複雑なドメインが混在しています。

例えば、UUUOのRailsアプリのコードを見ても

魚種にまつわるモデル(呼び名、魚種ごとの規格)
物流のモデル
購入や決済のモデル
色々なプレイヤーがいることによる組織のモデル

等がパッと思い浮かびます。

(あまり詳細には踏み込みませんが) 少し具体的な話をすると、上記の例の物流のモデルにも関係する、ユーザごとの出荷方法を決定するだけでも、

通常のBtoBの市場間物流を使う
ラストワンマイルを配送してくれるヤマト配送を使う
その両方を使う

のか、購入するユーザの種類と、商品(発送地)の組み合わせで色々な分岐があります。 ※複雑なドメインを実装に落とし込む話については水産業ドメイン可視化と実装のコツ〜釣って捌いて食べてみる〜 - Speaker Deck が面白いのでぜひご覧ください!

speakerdeck.com

こういった複雑性を内包するロジックはなるべくカプセル化し外から扱いやすくする工夫を随時していっています。これはどの言語を扱っても当然行うべきことだと思いますが、プロダクトや事業のフェーズに合わせて、エンジニアが柔軟にロジックの形をアップデートしていきやすい言語だなと思っていて、個人的に好きなとてもポイントです。

Rubyの外観はシンプルです。けれど、内側はとても複雑なのです。それはちょうど私たちの身体と同じようなものです - https://www.ruby-lang.org/ja/about/ より

実際、上で挙げた例の出荷方法の決定方法についても、最初は1つの方法しかなく特に意識せず、それが複数になってきたタイミングで課題が出てきて、モジュールとして切り出そうという流れで開発されました。その裏側にあるビジネスロジックを詳しく知らないエンジニアでも扱いやすくなるようなっていて、こういう動きは現在進行形で随所で行われています。