blog

[sakanabacca]
sakana bacca 店舗で使われているラベラーアプリ開発の歴史

sakana bacca 店舗で使われているラベラーアプリ開発の歴史

はじめに

この記事は、foodison advent calendar 2015 の 22日目の記事です。

どうも。冬感がイマイチない vimtaku です。
今日は業務で作った Android アプリについて説明します。
この記事は思い出しながら書きたいため、話し言葉で書くことをご容赦ください。

当時の状況

3月に foodison に入社して1ヶ月くらいは魚や店舗の仕組みなどを勉強しつつ、店舗の仕入れシステムを作っていた。
4月頃になると店舗のラベルアプリを作成するような話が出てきた。

この頃はsakana bacca 店舗は武蔵小山、中目黒の2店舗だった。

ラベラーアプリ開発の背景と問題意識

このプロジェクト発足には問題意識と背景があった。

一つはラベラーのコスト感だ。

(具体的には社名は出せないが、ここでは仮にT社と呼ぶことにしよう)T社のラベラーを使用していた。
T社のそれは数十万するもので、ベンチャー企業である我らにはかなり高いものであった。
またラベル用紙のコストも、馬鹿にならない。

さらには店舗のIT化を進めるとなったとき、ラベルの印刷データや、レジとの連携ができたら
商品の分析などに大きな可能性が生まれるのではないかということだ。

問題はまだあった。
当時スマレジを使って運営されていたが、スマレジは展開する店舗のターゲットがアパレル系などが多く、
生鮮バーコードを使用するには大きな問題があった。
あるバーコードと商品の価格が1:1 で紐づくので、たとえばある商品の重さで値段が変わる、などの場合に、
その分の商品のデータを事前に登録しなければ読み込めないのだった。
つまり、100円から300円の幅で販売しようと思っていた商品があった場合、100円,110円,120円,…. 290円,300円 と
データを10円刻みで30個も登録しなければならないのだった。
おかげで商品数は1000件くらいしかなかったのだが、6万件くらいスマレジのレコードを消費していた。
悲劇だ。

さらに問題があった。
T社のラベラーのデータを更新するのと、レジのデータを更新するのは別管理なので、商品マスタを別管理しておき
それぞれのデータ構造で CSV を吐き出し、 USB にデータを入れて、ワクワクしながら店舗に出向き、
T社のラベラーにUSBをさして更新するという、とてもクールな作業があった。
新しい商品を登録するたびにこれを行う必要がある。クールだ、とても。
さらにレジにも同様のデータをアップロードするんだ。… もう最高!

・・・まぁ、とにかく問題が山積していたんだ。
(そしてここでは述べないが他にも問題や、やったら解決できることがたくさんあった)

そこであまりにも自然に導き出された仮説はこうだ。

「店舗で使われるラベラーのアプリを開発したら、
店舗でどんなものが生産されているのかわかるし、仕入れたものが
どのように加工されているか追うことができるかもしれないし、
商品の自動更新も可能だし、なにより今の状態じゃ最高にクールすぎて死んでしまう!
おそらくデザインももっとお洒落にできるはずだし、
これは当然開発して最高のプロダクトにするべきなんじゃないか?」

こうしてプロジェクトが発足したのだった。
プロジェクトメンバーは当然(リソースの関係で)自分一人だ。

調査

まずはなによりも調査だ。
何が必要か。何を作ればよいのか。
コストはどうなるか。

調査すべきことは何か

調査すべきことは大体以下のようになった。

  • iphone アプリか android アプリかのどちらかで作成ができるか?
  • タブレットから操作できるようなラベルプリンタは存在するのか?値段は?開発工数は?
  • 各ネイティブアプリ未経験者が、このアプリを作るのにどれだけ時間がかかるか?

調査結果

調査を進めていくと、だいたい以下の様なことがわかってきた。

  • ブラザー工業のラベルプリンタ 「TD2130NSA」 があればどうやらデザインが自由に編集でき、SDK もあるのでタブレットから印刷が出来そうだった
    • iOS SDK, Android SDK 両方ある
    • 1台4-5万程度で購入できる
  • 連絡して実際に端末を貸していただいて試したところ、行けそうな感触があった
  • 画像をそのままプリントした時のクオリティについて調べた所、画像をそのまま印刷するのは、文字が荒くなるので不可能のようだった
  • 印刷速度はまぁまぁといったところだった。カイゼンすれば実用レベルに追いつく感触があった
  • アプリ作成経験はないけど、画面遷移もおそらく相当少なく、シンプルなモノになるはずなのでイケるはず
    • 幸い、会社は違えど、知り合いに優秀なエンジニアたちが居たのでいろいろ教えてもらえるだろうという認識があった
  • 開発期間?こういうのはだいたい調査設計実装含めて1ヶ月なんだよ!!!!!!

決めたこと

調査した結果、だいたい以下の方針ですすめることにした。

  • TD2130N を使う(NSA とはディスプレイがない、などの違いがあるが、比較的安いため)
  • 印刷モードは USB を使用する。
    • Bluetooth, USB, LAN という3つの接続方法があるが、 USB が一番印刷速度(データ転送)が早かったため
  • P-touch Editor というテンプレート作成機能を使用してプリンタに予め仕込んでおき、テンプレートに文字列を送信して達成する
    • プログラムで画像を作成してデータを送信して印刷することを当初想定していたが、画質が荒かったため
  • iOS, Android はどちらでもよかったが、 Android で作成することにした
    • タブレットの入手しやすさ、業務アプリという特性、値段の観点から Android に部があると判断した
  • 開発期間は全部込みで1ヶ月。そこまでやってそれ以上掛かりそうだったら考える

システム設計

システム構成

https://i.gyazo.com/e70d8e77859e9945f345a98ba4f69aab.png

説明

店舗に Android タブレットとラベルプリンタを用意し、そのうえでアプリを動作させる。
そのアプリは、ラベルプリンタにデータを送信し、ラベルを印刷する。
同時にそのアプリは、サーバにそのログを送信することで、様々なことを出来るようになる。
サーバにログを送信されたタイミングで、サーバのプログラムがスマレジの 商品登録 API を叩くことで、
レジにも直接データが入るようになる。
店舗では、(ここが激しくイケてないが)手動で定期的に商品同期を行う。
これによって、ラベルが発行された時点で必要な値段のバーコードがスマレジに登録されて
商品が正しく読み込める!

これであらゆる煩悩から開放される!

開発

開発するにあたっては Android 初心者だったのでゼロから学んでいった。
前職の友人などから援助を受け、ある程度の高速道路を頂いた感じがある。
幸い Java の経験があったので特に問題なくコードは書けたが、
Android に慣れることが一番大変で、ゴールデンウィーク中 はひたすら Android を勉強し続けた。

開発環境

Android Studio が良いよと聞いたので Android Studio にした。
Genny motion(エミュレータ) も良いと聞いたが、実機と直接繋いでたのであまり使ってない。

なぜか alfred2 から Android Studio が開けなかったので
launch application "/Users/vimtaku/Applications/Android Studio.app"

のようなものを スクリプトエディタで作って対応した。

ライブラリ

gradle.properties の一部を抜粋するとこうだ。

    compile fileTree(include: ['*.jar'], dir: 'libs')
    compile 'com.android.support:appcompat-v7:22.1.0'
    compile project(':libs:BrotherAndroidSdkSample')
    compile 'com.jakewharton:butterknife:6.1.0'
    compile 'com.michaelpardo:activeandroid:3.1.0-SNAPSHOT'
    compile 'com.google.code.gson:gson:1.7.2'
    compile 'net.danlew:android.joda:2.7.2'
    compile files('lib/lucene-gosen-4.5.1-naist-chasen.jar')
    compile 'org.lucasr.twowayview:twowayview:0.1.4'
    compile 'com.squareup.okhttp:okhttp:2.4.0-RC1'
    compile 'com.deploygate:sdk:3.1'

    testCompile 'junit:junit:4.12'
    testCompile 'org.mockito:mockito-core:1.9.5'
    compile 'org.jdeferred:jdeferred-android-aar:1.2.4'
    compile 'org.jdeferred:jdeferred-core:1.2.4'

Android での開発の所感を書くと、

  • active android がそこそこ便利だったが、 active record に慣れていると結構なツラミを感じる
    • Iterator とか懐かしいなとおもって使ってた
    • Iterator ではなく 拡張 for で回さないと getId() でIDが取れないみたいな現象で2,3時間くらいハマって死ぬかと思った
  • 全体的に、設計をサーバに厚めにデータとかを持たせるようにしてたが、一部、最近使った値段などを端末に保存してたので、アップデートの時に新しいDB とかにすると消えてしまう問題が大変だった。
    • これは migration をちゃんと書けば問題ないはず
  • Java が何となく冗長だけど、Android Studio がよく出来ててめっちゃ書きやすかった
  • テスト書くのはそれほど大変じゃないけど、テストの実行が涙出るほど大変だった気が..
  • この時は使ってないけど eventbus が便利
  • このとき RxJava が流行りだしていたが、単純に promise 使いたい位の要求だったので jdeferred で進めた
  • butterknife を教えてもらった時のありがたみ

という感じだった。
個人的には iOS よりレイアウトが書きやすくて便利だなと思った。

導入

sakana bacca 中目黒の店舗に持って行ってもなかなか最初は使われなかった。
やはりなれたものが使いやすいわけだし、そもそもラベラーは別の物があったからだ。
しかし徐々に使われ始めるようになり、いろんな改善点も出てきて改善をしていった。

家が近くにあったため、足繁く通って導入のサポートをした。
ただし、使い方は非常にシンプルでわかりやすいので、そこまで難しい説明は必要なかった。

成果物

ラベル

https://i.gyazo.com/99b8de5e7614c6e591fd6531a44381f2.png

ロゴとかも入って KA WA II !!!!

アプリ

写真が見当たらなかったので、
find-job さんにちょうどこの頃取り上げてもらった記事があるので こちらをどうぞ。

ラベルアプリの問題点と現在

2015年12月現在では、サカナバッカは6店舗あり、それらのレジとラベラーはすべて、とある会社のものに統一された。
僕の作ったものが無駄になったかのように思えた。
しかし幸い僕の作ったものもちゃんと併用されているようなので何よりである。
上記諸事情に関しては、かなり難しい事情があるのだが、、、

フーディソンではこのような実際に使われるアプリを作って価値を生むことができます!楽しい!
詳しく聞きたい人は是非弊社に遊びに来てください!

その他の影響としては、ブラザー工業株式会社様の展示会で展示され、好評を博しているようだった。
このようなソリューションを必要としている人たちがいれば、ノウハウを共有したり、ソリューションを提供したり
できるかもしれない。

このアプリにはまだまだ可能性があって、1人月程度のリソースでここまでの影響を与えられた。
新食品表示法対応や、レジとの連携などに関していえば、まだまだ可能性はある。
このアプリがこの先どのように進化をとげるかは分からないが、
この経験が僕にとって素晴らしい物になったと思う気持ちは変わらない。

終わりに

foodison のミッションは「世界の食をもっと楽しく」です。
このミッションに共感するようなエンジニアの方は、是非一度遊びに来てください!
採用関連に関してもっと知りたい方は こちらの wantedly を参照してください。