社内スポーツイベント!

こんにちは!株式会社スマレジ、開発部のマサです!

3連休第1陣、皆様はお出かけされていますか?社内でもツーリングやBBQなどに出かける人が多いようでした。

今日は最近始動したバスケ部の第1回活動について、ご紹介したいと思います!

スマレジの社内スポーツイベント

スマレジはスポーツ系のリクリエーション(フットサル、マラソン、サイクリング etc...)が割と盛んで、月1くらいで何かしらのイベントをやっています。(僕も1度フットサルにお邪魔したりしてます。)

ちなみにフットサルは天王寺キャプテン翼スタジアムとかで活動してます!


てんしば キャプテン翼スタジアム天王寺 フットサルコート 天王寺

 

そんな中、最近入社した社員さんがたまたま「バスケ好き」が多く、
「夏暑いし、たまには屋内でバスケやりてーー!」という声があがり、
バスケ部(仮)が発足したのでした・・・。

当日はこんな感じでした

場所はHOOP7 東大阪店

いつもより早めの9:30に出社して(スマレジ出社時間が8:00~10:00で自由に調整できます!)18:30には、参加者7人全員で退社→本町駅から荒本駅へ移動!

HOOP7さんはバッシュの貸し出しもやっていますので、荷物が少ない分、
会社帰りによりやすい環境だったと思います!(本町からは少し距離がありますが汗)

価格表はこちら

 準備運動をして、人数も少なめだったのでワンゴールで3 on 3で遊びました!

バスケといってもそこまでハードではなく、大体15~20分に5分休憩くらいの緩い感じで、とても楽しめました!

僕はバスケットボール自体、高校卒業以来触っていなかったのですが、聞けば皆さんも似たような感じだとか。

やっぱりメンバー集めと、場所取りがバスケは手間がかかるみたいですね・・・

しかし!10月にもすでに次の場所取りもしていただいているとのことなので今から楽しみです!

 

 

 

 

MySQL Workbench 8.0.16でテーブル情報がfetchできないときの回避法

こんにちは!株式会社スマレジ、開発部のmasaです。

今週はスカッと晴れた週末になりましたね。
その分暑さも容赦ないですけどねー。。。

まだまだ暑さ厳しい日が続きますので、皆様ご自愛ください。

今日は個人で開発しているときに詰まった部分を備忘録的に書き留めておこうかなと
思います。

MySQL Workbenchでテーブル情報を取得
できない・・・

4か月ほど前にSQLクライアントにOracle公式ツールのMySQL workBenchの最新版
(当時、8.0.16)をダウンロードして、テーブル定義を書いていたのですが、先日、修正しようと思い、再度起動してDBサーバに接続したところ・・・

f:id:masa2019:20190908152652p:plain

Error Code: 1146 Table 'performance_schema.user_variables_by_thread' doesn't exist

Error Code: 1146 Table 'performance_schema.user_variables_by_thread' doesn't existというエラーにより、テーブル情報を取得できないように・・・

原因を調べていくと、こんな記事が出てきました。

https://stackoverflow.com/questions/56298805/mysql-workbench-error-when-connecting-to-mariadb-table-performance-schema-user

以下、URLより引用

"Setting aside the fact that MySQL Workbench is made for MySQL (as the name says), this problem was introduced in 8.0.16 and will be corrected in 8.0.17. The mentioned table doesn't exist in other versions than MySQL 8."

どうやら、8.0.16, 8.0.17で起こっている不具合のようです。

というわけで、Oracleのページで別の8系をダウンロードしようとしたのですが・・・

f:id:masa2019:20190908153249p:plain

あれ、8.0.x系、なくない・・・?
Looking for previous GA versions?から以前のバージョンをダウンロードしようとしたところ、
6.3.10が直近の最新のようです。(ただ、さっきのStackOverFlowをみると8.0.15ではこの問題は起きていないという趣旨のリンクがあったので、どこかで入手できるのかも?)

というわけで、6.3.10にダウングレード。

f:id:masa2019:20190908154127p:plain

テーブル情報を取得!


無事にテーブル情報を取得できました!


 
 
 
 
 

開発部ランチ!(定番編)

こんにちは!株式会社スマレジ、開発部のマサです!

今週は涼しい日が多かったですが、週末に天気が崩れてしまいましたね・・・。

皆様もゲリラ豪雨にはお気を付けください・・・!

今日は、僕の所属するスマレジサーバーチームでランチでよく行くお店を紹介します!

 

釣天狗 本町店

男組 釣天狗 本町店

食べログ 男組 釣天狗 本町店

スマレジの入っている東芝ビルから歩いて5分ほどにあるアーケードにあります。

ここになるときの流れは・・・「魚食べたい!」と、だれかが言った時になるときが多いですね。

本町周りは結構肉肉しいお店が多めなので、違うものを食べたいとなった時は、ココ!
という感じが多いですね。

梅田にも系列店があるみたいです↓

 

ニューハマヤ 瓦町店

ニューハマヤさんは、以前ブログでも紹介したおおきにコーヒーさんのはす向かいにある焼肉定食の店です。(以前のブログは↓)

 

masa2019.hatenablog.com

 ハマヤさんの特長は「ダブダブ、トリプル」です。

こってりした味付け肉がてんこ盛りになって出てくるスタミナがつくメニューなのですが、このお肉と肉と一緒についてくるスクランブルエッグの量に応じて、ダブル、トリプルという風に倍々になっていきます。

また、おひつにご飯を入れてそこから好きなだけよそって食べるので、お替りしたい人にもおすすめです!

 

ブライトンベル 本町通り店

ブライトンベル 本町通り店は会社からは3分くらいの激近なお店で夜はバー営業をしているお店です。

ここのランチはパスタが面白いです!

焼きそば風や中華風等、本来パスタではあまりしない味付けのものが日替わりで楽しむことができます。(クセが強いので好き嫌いが分かれると思います汗)

僕はたまには変わったものが食べたいなー!って気分の時に行きますね(笑)

 

今回は近場の良くいくランチをご紹介しました!

エンジニアとビジネス(4)

こんにちは!株式会社スマレジ、開発部のマサです。

 

お盆が明けて、お仕事再開ですね!少し休みが長すぎたのか、僕はまだ体の休み気分が抜けきりません。。。

今日はこのシリーズの最後に、性能の問題についてお話しします。

 

性能とスモールスタートの弊害

おそらく今売れているほとんどのクラウドサービスが、小規模な顧客数・利用者を想定してローンチして、すこしずつ規模が拡大するに合わせて、機能面の強化をして言っていることと思います。

スマレジも上記のパターンで大きなサービスへと進化してきました。しかし、そうであるがゆえに性能面では今なお課題があります。

一部のCSVの取り込みやWebAPIなどは、送信するデータ量によってはデータベースへ大量のデータを書き込むことになります。そして、機能の拡張の度にカラムが増えたり、JOINするテーブルが増えたり、少しずつ1つのSQL自体が巨大化していきます。

その結果、クエリの実行速度は改修とともに低下。加えて、利用者が増えることによりより大量のデータを扱うお客様も増えることにより、スロークエリーが発生してしまいます。

また、スマレジの開発はすでに7年近く続いており、現在では当たり前に考えられているスケーラビリティなどの考え方がまだ存在していなかったりと、時間の流れによるギャップが生まれている部分があります。

社内での性能問題への取り組み

現在、スマレジのPOSサーバー開発チームでは、この性能の問題について、特に注力して取り組んでいるところです。特に、クエリ1本ではなかなかうまくいかない場合、取得を複数カラムに分けてプログラム上で結合するなど、現在のスケールにあったSQL設計に切り替えています。そういう意味では、スマレジの機能は性能改善の過渡期だといえると思います。

これらの成果がお客様の手元へ届くにはまだ少し時間がかかる部分もあるかと思いますが、性能面での問題とはこれからも根気よくお付き合いして改善努力を重ねていきます。

また、こういった事例を経験・解決してきた知見のある方には、ぜひ力を貸してほしいです!その知識が何万という店舗の業務を最適なものにするとてもやりがいのある仕事だとおもうので、ご興味を持たれた方はぜひ、ご一報ください!

詳しくは下記URLをご覧ください。

https://corp.smaregi.jp/recruit/

エンジニアとビジネス(3)

こんにちは!

株式会社スマレジ、開発部のマサです!

皆様、お盆休みはいかがでしたか?僕は前半は夏風邪をひいてしまい、後半は台風と、お出かけはできませんでしたが、その分ゆっくり疲れを癒せました。

今回はお客様のスケール差によって変わる便利さについて、お話ししたいと思います。

 

スケールの種類とスマレジの強み

スマレジは小規模の小売店から大規模なアパレルショップまで、様々な業種業態のお客様にご利用いただいています。

それゆえに、同じ機能であっても使い方はお客様によってまちまちなこともあります。

店舗数

店舗数が多いお客様の場合だと、スマレジの持つ売上の分析機能や、各店舗の商品管理などの機能が強みを発揮します。これらの機能は、店舗を跨いだ横断的な集計をすることができ、現在の利益状況を教えてくれます。

また、在庫管理機能では店舗間の在庫移動をワークフロー化する店間移動機能が強みになってきます。

店舗数が少ないお客様の場合は、スタッフ登録とレジとの連携など、旧来のレジでは自分で設定するにはハードルが高かったり、そもそもレジ連携をあきらめていた方でも、簡単に設定頂けるインターフェースがあることが強みです。

取引数

取引数の大小によっても、便利さは変わってきます。取引数の多いお客様にとっては、各API連携が重要になってきます。

というのも、取引の多いお客様は、スマレジ以外に基幹システムをお持ちの場合もあり、それら既存のシステムと動機をとれることが商談の決め手になることもあるとか。

逆に少ない場合は各種データのCSV出力も対応しているので、今まで使われていたExcel資産も一部流用いただけるようになっております。

スケールについて大切なこと

上述のように、スマレジで新しい機能を作るときは、どんなお客様に使っていただく想定なのか、ターゲット層のお客様以外には対応が必要なのかについて、設計段階で吟味しています。想定するパターンが多く、追いついていない部分も時にはありますが、とてもやりがいのあるお仕事なので、もし興味を持たれたら、いっしょに働いてみませんか?

エンジニアとビジネス(2)

こんにちは!株式会社スマレジ、エンジニアのmasaです!

今週も暑かったですねー!大阪本社はお盆休み前ということで、出勤の調整をしたり、旅行の準備で盛り上がっていました。

今回も前回に続いて、最近仕事をしていて感じた超上流のお話をしてみようかなと思います。

今回はスマレジの仕様を決める際に、重要になってくる3つのポイントのうち、既存機能についてお話ししたいと思います。

既存機能

これは、パッケージの追加回収案件などでも指摘されることです。要はいかに既存の機能と矛盾のない機能にするか、という点です。

スマレジは多機能であるがゆえにこの問題が非常に大きくなってきます。1例として、以下のような例を挙げてみます。

改修例:商品詳細に項目を追加する

商品詳細に項目を追加する場合、現状では最低でも以下の改修が必要になります。

  • 商品追加画面
  • 商品更新画面
  • 商品CSVアップロード
  • 商品CSVダウンロード
  • 商品更新API
  • 商品参照API
  • 商品送信API

内部的にはロジックを共有していたり、実装しない部分もあるので、この7つ全部に対応するわけではないですが、1つのカラムを追加するだけでも、結構な影響範囲があることがわかると思います。

また、たいていの場合、項目を追加する場合はほかの画面で参照したり、更新することもありますので、実際の影響範囲はこれ以上になります。

一つ一つについては、既存のソースを見ながら作成できるので、難しい実装はは少ないですが、プロダクトの規模が大きいだけに、論理的な矛盾(仕様レベルでの不備)とは日々戦いになる部分もあります。

これらの作業を通してあらためてMECE(モレなく、ダブりなく)を難しさを感じます。

次回は、お客様の規模の差(スケールさの問題)のお話をします。

 

 

エンジニアとビジネス(1)

こんにちは!株式会社スマレジ、エンジニアのmasaです!

今週は暑かったですねー!大阪本社まわりはいよいよ夏本番という感じの天気が続いていました。

今回から、予定を変更して何回かに分けて最近仕事をしていて感じた超上流のお話をしてみようかなと思います。

エンジニアとビジネス

結論から言うと、営業やお客様の「こんな機能が欲しい」という背景をどれくらい理解できるかが機能を考えるうえでとっても大事だなって感じたということです。(当たり前ですけどね)

今日はSIerが言うところの超上流工程のお話です。超上流工程とは、要件定義よりも前の段階のことです。つまり、営業さんが契約を受注するまでの工程です。

今回は比較対象として、SIerでの超上流を紹介したいと思います。

大手のベンダーの場合、営業に加えてグループのコンサルタントが中に入って、問題の発掘や解決プロセスを精査し、入札や提案に盛り込んでいくことが多いと思います。

f:id:masa2019:20190804152448j:plain

SIerの体制例


最近の日系メーカー系ベンダーなんかだと、「SEのコンサル力向上」が経営課題に挙がっていたりして、僕自身も前職ではフレームワークやらビジネス課題の発見研修みたいなのには結構行かされてました。(でもこの手の研修って、実戦経験とSEの興味関心がかみ合わないと身につかないんですよねー)

前職のイメージで言うと、エンタープライズ系のSEは特に行かされていたイメージがあります。公共や社会インフラ系SEと比較するとPJ規模が少額なため、専門のコンサルを入れるのではなく、SE自身が提案をしていくシーンが多いからだと思います。ゆくゆくは、SEだけで上流以前にコンサル料をとれるようにさせたいとか、そんな噂話も聞こえていました。

では、スマレジの場合はどうかというと、以前のブログで紹介したように、お客様のニーズを営業さんが取りまとめて、ニーズのある順に機能開発をしていきます。

以前のブログはこちら↓

 

masa2019.hatenablog.com

 

これだけ聞くと、エンジニア側は営業さんの要望に応えていけばそれでOKみたいに聞こえますか、実際はそういうわけではないです。

要件を理解する上で重要になる既存機能・スケール・性能について、次回からお話ししていければと思います。