はじめに

こちらの記事は広島大学ITエンジニア Advent Calendar 2020 19日目の記事です。

私は今年の5月ごろから広島の株式会社ウーオという水産業界の流通をITで支える会社でエンジニアインターンをしています。

uuuo.co.jp

8月はじめから11月末にかけて、エンジニアインターン生の2人で始まったカニの在庫管理アプリプロジェクト「かにっこ」を一度クローズすることになりました。

こちらの振り返り記事ではプロジェクトの振り返りとかにっこを通して学んだことについて共有したいと思います。

かにっこ

「カニは鮮魚と違って、在庫として抱えることがあるから管理が大変」

この課題を解決するために「かにっこ」は始まりました。

まずはカニのオペレーション(商品をセリ落としてからお客さんに出荷するまでの流れ)について学ばないといけないので、管理がどう大変なのかを切り出して考えることにしました。

カニは鮮魚とは異なり、セリ落とした商品をその日に出荷するだけでなく、UUUOの在庫として確保することがある。
また、在庫として確保されたカニは急にいなくなったり(脱出...)水死して売れなくなる場合がある。
カニには様々な規格や状態がある。
- 例)
  - 松葉ガニ5番(底)ウスA一折
  - セコガニ2番(底)
  - 松葉ガニ五輝星(底)
- めちゃくちゃ多いです🦀
- 同じ1番2番でも港によって規格が微妙に異なります。
出荷の際、松葉ガニは枚数、セコガニはcs数(規格によって決まった枚数を1ケースとしてまとめて出荷する)で管理する。
- 雌のカニのことをメガニまたはセコガニと呼ぶらしいです。
- カニの数え方は1匹、2匹ではなく、1枚、2枚と数えます。

これらのことから、カニの在庫管理は鮮魚でのオペレーションと異なり複雑で大変になっていることがわかりました。

システム設計

今回はインターン生の２人でプロジェクトの立ち上げから設計、そしてリリースまでを任せていただけるという機会をいただきました。実際に使っていただく広島のオフィスにいらっしゃるセールスチームや港でセリに参加して商品をセリ落し出荷作業を行うベースチームの方々に対してヒヤリングを行ったり、オペレーションフローの情報を元に「かにっこ」がオペレーションのどこで使われるかを考え設計を進めていきました。

f:id:kugi_masa:20201214143723p:plain — オペレーションフローとかにっこ

以前までのUUUOの業務では私がFlutterを用いたフロントエンド実装、もう一人のインターン生がrailsを用いたサーバーサイド実装を主にしていました。今回のプロジェクトではお互いのスキルアップのためにもロールを途中で入れ替えて取り組みました。モブプロ形式も取り入れ、お互いの得意な方を相手に教えることで得意な方の実装への理解も深まりました。

また、Miroを使ってタスクの見える化、言語化を行い、GitHub Issueで実際に着手する実装タスクの管理を行いました。

これまでCammelで行ってきた開発やハッカソンではFirebaseなどのBaaSを用いて実装していたので、バックエンド実装についてあまり考えずフロント実装に専念していました。しかし、今回APIの実装やデータベースの設計に触れることで、フロント側で呼び出したAPIのリクエストがサーバーサイドでどのように動くのかを知ることができとても良い学びになりました。

今後はサーバーサイドのことも考えてフロント実装に取り組んでいきたいと思います。

運用の難しさ

「かにっこ」はファーストリリース(社内アプリなのでTestFlightでの内部リリース)まではできたものの、「かにっこ」の運用までには至らず、結果としてプロジェクトをクローズすることになりました。

実際にテスト運用してみると、モバイルよりPCでの入力の方が向いていた
現在スプレッドシートで運用ができている
オペレーションのなかで変更の要望があったとき、アプリケーションでの実装よりも、スプレッドシートの修正の方が素早くカイゼンできる

以上の要因から今回クローズをすることにインターン生二人で決めました。

管理ができないままでは問題なので、セールスチームの方がスプレッドシートで管理シートを作成され現在はそちらでカニの在庫管理運用をしています。

カニのオペレーション以前から、ベースチームやセールスチームの皆さんにはお時間を取っていただいてアプリの壁あてにご協力いただきました。しかし、実際カニのオペレーションが始まりテスト運用をしていただく中で、現実的にオペレーションに組み込みづらい点や修正点が出てきました。そして、そこからの修正(主にデータベースの再設計)に時間がかかってしまいました。

今回得た学びは、課題をもっとシンプルに切り分けて小さい領域(MVP)でテストをする方が良いということです。実際にアプリを作っている段階では「一折、二折」といったカニの状態や松葉ガニとセコガニの枚数とcs数の違いまで実装に組み込んでいましたが、実際にテスト運用をしてみると、カニが生きているかと水死しているかが一番重要で、カニの状態までは確認と管理している時間はありませんでした。また、松葉ガニとセコガニでの違いは管理する単位だけなので、最初は松葉ガニのみに絞ってテストしてみる方が早く修正し次のテストに取り掛かれたと思います。