【個人開発】おすすめフリーツール
こんにちは！株式会社スマレジ、開発部のマサです！
今週は台風が来ていましたが、それ以外はカラっと乾いた日本晴れの日が多く、大阪本社周りは日差しがツライ真夏日でした。。。
今日は、個人的に気に入って使っている開発フリーツールを紹介します。
【エディタ編】Brackets
BracketsはAdobeが提供しているオープンソースのエディタです。
メリット
個人的に感じるこのエディタの一番の長所は「カスタマイズしなくても、Webの主要な言語の予測変換が出る」ことですね。
他のフリーエディタの場合、言語プラグインなどを導入しないと、予測変換がでなかったりと、パッと使うには少し面倒なときにこれを使うことが多いですね。
あとは、ライブプレビュー機能も便利ですね。PHPStormと同じで、保存せずにどんどん画面に反映してくれるので、うっかり保存ミス→反映されてない！？のトラップにはまらずにすみます(笑)
くわしくはこちら→ http://creating-homepage.com/archives/2975
デメリット
私が感じるのは拡張性のし辛さでしょうか。設定すれば、Xdebugなども利用できるらしいですが、正直、そこまでやるならVSCodeのほうが設定が楽なので、そっちをつかっちゃいますね。
J＆EはJSONビューアです。
機能はいたってシンプルで、JSONをテキストボックスに張り付けると、整形してくれます。また、Viewerタブではツリー化して、変数をみることもできます。
メリット
これも、ダウンロード→即使えるというのが好きですね。とくに、JSONの自動成型があるので、ハードコーディングされたスペースも改行もないJSONをみやすくしてくれるので、重宝しています。
デメリット
J＆Eはリクエスト送信機能がないため、そのままAPIの検証に使うことはできません。
普通はPostman(紹介URLhttps://www.webprofessional.jp/master-api-workflow-postman/)
なんかのpost機能のあるJSONエディタを使うと思いますが、すでに検証用のテストページがある場合は、そういう時はこっちを使います。（あとこれ、動作が軽いのでChtomeとPHPStormとDockerが走っている環境だと、ツール類は極力軽いのがいいという事情もあります）
というわけで、フリーツール紹介をしてみました。気が向いたらまたやると思います。
次回はスマレジ3.12.0のリリース内容について、お送りしたいと思います。
スマレジの機能が決まるまで
こんにちは！株式会社スマレジ、開発部のマサです！
今週は湿気がすごかったですね・・・。大阪本社周りも、雨はそれほどでしたが湿気がすごくてうっとおしかったです汗
さて、今週は、スマレジの機能がどんな風に決まるのかをご紹介したいと思います。
仕様のネタはいろいろ
以前、「ASPであるスマレジは、仕様はお客様ではなく、自分たちで策定していくことになる」とブログで書いたことがあると思います。ただ、実際には様々な方面から飛んでくる「お客様の要望」を形にしていくことが多いです。いくつかパターン分けして紹介しますね。
パターン１：個社対応（現在新規対応は行っていません）
いわゆるカスタマイズ案件というものです。個別に開発費用をお客様に負担していただき、そのお客様の要望を取り込んだ機能を開発するものになります。
現在では、新規のカスタマイズ要望については対応していませんが、以前はこういった個社対応の機能をベースに全アカウントに新機能としてリリースすることもありました。
個別カスタマイズを要望されるお客様は、店舗数が比較的多い小売業が多く、大型店舗特有の観点を取り込むことができるため、エンジニアも、リテールの世界の勉強になります。そういった、流通業界全般の仕様や文化を勉強したいエンジニアには、スマレジはとても良い環境だと思います。
パターン２：営業からの要望
次に上がるのが、営業からの要望に対応する形です。
「こんな機能があったら売りやすい！」という営業さんの声に応えて、機能を増強、拡張することになります。
このパターンの長所は何より、「作った機能が即時、顧客獲得に貢献できる」ところです。エンジニアとしては、やりがいを感じやすいですよね。
パターン３：ビジネスルールの変更
いわゆる、軽減税率対応がこれにあたります。
税や取引に関する法律やルール、制度が変わった時、スマレジもそれに対応できるようにする必要があります。
他のパターンもありますが、目立つところだとこのあたりになります。
直接的・間接的の違いはありますが、基本的にはお客様の声をベースに機能を拡張していることを、知っていただけると幸いです。
開発部発！大阪本社のおおきにデリバリー
こんにちは！株式会社スマレジ、開発部のマサです！
今日は、最近開発部・・・というか大阪支社で恒例イベントになりつつある、
おおきにデリバリーの様子をお届けします！
おおきにデリバリーは、おおきにコーヒー株式会社が提供しているジュースと軽食のデリバリーサービスです。（URL：https://coffee.ookini.jp/）
大阪本社では、毎週金曜日の午後、社内で注文を募ってデリバリーを頼んでいます！
その時の様子がこちら・・・！
ユーティリティスペースにずらりと並んだ、19杯のジュースたち！（しかもお菓子もあったりします）
実は、このジュースのデリバリーは開発部発！笑
というか、おおきにコーヒー大ファンの社員さんが一人いらして、ある時
「デリバリーしたい！」と言い出したら、みんなで乗っかって今に至る・・・
大体そんな感じです。
こんな感じで小さいことでも、取り上げて会社の文化にしていける風土もあるので、
みんなで楽しくワイワイやるのが好きな人にはおすすめの環境です！
というわけで、今日はおおきにデリバリーの様子について、おとどけしました！
半年がたちました。
こんにちは！株式会社スマレジ、開発部のマサです！
今週の大阪本社周りはG20開催で、物々しい雰囲気です…！難波～本町はお巡りさんが大量動員で警戒されています。
そんな今週のブログですが、入社してちょうど半年がたつので、少し振り返ってみようかなと思います。
以前のブログと比較しやすいように、SIerとの違いを中心にお話ししたいと思います。
大きな違いその1 コード品質
ここが一番違いが大きいんじゃないかなと、個人的には思っています。以前も書きましたが、「動くこと」が重視されるSIerとは異なり、つくったものをソフトウェア資産として持ち続けるASPは、製造工程にかける工数は非常に大きいです。
大きな違いその2 システムテストと移行
そして、SIerにはあって、ASPには存在しない工程が「移行」です。これは、SIerの場合は結合テストの後、お客さんのデータを移行させて、実際に使えるのか検証をするフェーズなのですが、そもそもデータ移行はお客さん自身がやるので、移行コストなどをエンジニアが負担しなくてもいいからです。その代わり、お客さんが移行や連携をスムーズに行えるように、APIを用意したり、大量データ投入時のパフォーマンスなどの検証を行っています。
大きな違いその3 上流工程
上流工程でのコストは正直比較出来ないと思います。SIerの場合はエンジニアや営業が入る前に、コンサルタントが戦略立案～システム化計画の途中くらいまで入っていますが、ASPにはそんなものはありませんので、自分たちでなにを作るべきかから考えなければいけません。これは経営層だけの話ではなく、エンジニアにも普通に求められることです。「なぜこの機能を作るのか」という部分から主体的に考え、納得ができない場合は上司であっても意見する姿勢が必要です。
逆に弊社のようにお客さん自身がショールームにきてもらうタイプの営業方式であれば、顧客に対する接待や、益体のない打合せに時間をとられることは少ないと思います。（営業職ではないので、詳しいことはわからないですが…）
ただ、その分お客さんの数が非常にふえるので、別のコストがかかってくると思います。
というわけで、半年版のSIerとの比較を書いてみました。たぶんこれ以上、この比較が変わることはないと思いますが、また気づきがあったらお知らせしますね。
【趣味回】痒い所に手が届...かないっ(VBSのクラス)
こんにちは！株式会社スマレジ、開発部のマサです。
ここ一週間くらいで、ぐっと暑くなってきましたねー！
大阪本社の冷房も日に日に強力になっています（笑）
今回は趣味回です。会社のお話は一切出てきません。
そこまで作って、なぜないのか(VBSの継承)
最近、休日に友人の仕事のお手伝いでVBSを書く機会機会があったので、
その時のお話。
VBSという言語自体、前の会社で少しだけ(1Kstepもないくらい）書いたことがある程度で、ほとんど未知の世界だったので、ググりながら作成していました。
すると、こんな記事が。
「お、VBSはクラスつかえるのか！」
そう思って浮かれたマサは詳しい仕様を調べずに、クラスをじゃんじゃかつくっていきました。
そして、基底クラスから継承しようとして、継承の書き方をググって・・・
継承がサポートされていないことに頭を抱えることになりましたとさ。
（継承に似たような実装はやりようはあるみたいです・・・が）
VBSの歴史とか、需要なんかはよく知らないので何とも言えないんですが、
なぜ継承がないんですかね？クラスの概念まで作ったのにもったいないなぁと
個人的には思いました。もしかしたら、何かしらの設計思想があるのかも
なお、件のツールは友人からの機能追加要望が多すぎり、結局Webで動かしたいらしいので、結局PHPで作り直し中だったりします。なんだったんだ、私の日曜日。。。
メジャーアップデート(2)
こんばんは！株式会社スマレジのエンジニア、マサてす。
今回は前回の続きでアップデート時の開発部の様子について、お話していきます。
アップデートされるまで（リリースまでの流れ）
スマレジでは、機能リリースは大きく次の流れで進んでいきます。
1. 要件定義
スマレジはASPなので、受託開発とは異なり自分たちで次作る機能を決定します。
どんな機能を実装・改修するのかはいろいろな基準がありますが、
私の知っている範囲だと、以下のような要件が関係します。
・その機能がどれくらい使われているか
・ユーザさんの要望
具体的にどんな要望があるのかなどのお話はできませんが、スマレジの場合はAPI
や在庫管理機能の要望が結構あるイメージです。
2. 概要設計
対応することが決まったら、Webデザイナーさんたちが画面デザインを作成します、
この辺りはいずれ1つの記事でご紹介したいですね。
3. 詳細設計
概要設計で決まった画面のデザインをもとに詳細設計を行います。
ここではデータベース定義や詳細な画面遷移、実装内容に対する他機能への影響範囲
の調査等を行います。
4 プログラミング
詳細設計に基づき、プログラムを作成します。フロントエンドのエンジニアさんと
協業で作業を進めていきます。
5 単体テスト
作成したプログラムについて、テストを行います。バックエンドエンジニアの
場合は、入力値の検証、エラー処理の網羅チェックなど、機能に関する部分を
テストしていきます。
品質管理部の専門のテストエンジニアさんたちが、作成した機能を本番環境と
同じデモ環境で結合テストを行います。
7 リリース
皆さんのお手元のスマレジに実装されます。
ざっくり書くとこんな感じです。ただ、SIerとは違い製造とテストに大きな時間を
かけます。これは、以前のブログでも書きましたが、コード品質が下がると著しく
生産効率が落ちてしまうためです。「あるべき姿があるべきように」つくることが、
皆さんに安心して使ってもらえる「スマレジ」の肝なんですね。
というわけで、ざっくりしたリリースまでの流れをご紹介しました。
メジャーアップデート
こんばんは！株式会社スマレジのエンジニア、マサてす。
引っ越しやらで忙しくて、五月はあいてしまいましたが、六月からはまたブログを更新していきます！
さて、先日スマレジは3.11.0にアップデートしました！
今回から2、3回に分けてアップデート時の開発部の様子について、お話しできればと思います。
アップデート時の忙しさ
一般に、ASPのアップデート前後は忙しいと言われています。スマレジでもそれは例外ではありません。
ただ、だからと言って残業がめちゃくちゃある！とかはありません。月換算でいつもより8～12時間増えるくらいです。なのであくまで、
いつもに比べれば少し忙しいくらいです。
忙しくなる原因は以下のような感じです。
まず、1についてですが、特に「在庫管理機能」の改修や機能追加の場合に顕著です。
※リテールビジネスプラン以上でご利用いただける高機能な在庫管理クラウドです。
あたりまえですが、在庫はPOS機能と異なり、ほぼすべての機能で数量を扱います。
それ故に会員や商品管理で行うテストケースに加えて、数値が正しく反映されているかを網羅的にチェックする必要が発生するんですね。
2についても、当たり前のお話です。
結合テストで明らかになった不具合は、自分以外の人が実装していない部分が関係することも多いため、他のエンジニアさんといっしょに修正作業をすることにあります。
こういうときに、自分だけでは気がつけない実装時のポイントなどを教えてもらえることも多いので、マサ的にはありがたい時間だったりもします(笑)
というわけで、まずは皆さん気になるリリース前の忙しさとその理由について書いてみました。
