読者です 読者をやめる 読者になる 読者になる

GoTheDistance

ユーザ系SIerから全く別業種の会社で「ひとり情シス」として内製してる変わったエンジニアのブログです

雑貨業界の展示会運営サービス、Handy(ハンディ) をリリースしました

今年からずっと取り組んでおりまして、数件の実戦投入を経てWebサイトをリリースしました。

handy-order.net

作った背景

弊社は雑貨の製造と卸をやっているんですが、取引先様が色んな展示会に出展されます。一番有名な所で言うと、「東京インターナショナル・ギフトショー」です。ビックサイトで年2回、開催されます。

その展示会には色んな方がいらっしゃるわけですが、とにかく時間勝負なんですね。10時〜18時の間で、より多くのお客様とコミュニケーションを取って回さないといけない。会社さんによっては、バーコードを読み込むハンディーターミナルを使って、ピッピピッピと注文取りをしています。が、結構な投資が必要。100万近いそうです。なので、手で管理する所がほとんど。年何回かの展示会のためにお金をかけたくはない。100万の粗利を叩くのは大変なことですから。

手管理というのは、注文票に手書きで品番と数量と値段を書き込んで電卓で計算して... みたいなことです。その作業にすごく時間がかる上に、後で集計するのがすごく面倒。やだ...そんな事務作業は自動化しないと...

スマホとワイヤレスバーコードスキャナーを使えば、出来そう。誰もやってないし、面白そうなので作ってみまーす。というのがはじまり。

ハンディーターミナルの代替としてスマホをベースに、注文取りのアプリを入れて、Bluetoothでワイヤレスバーコードスキャナーを接続して、その場で注文が自動で取れて管理画面から控えのPDFがダウンロード出来ます。また、売上がリアルタイムで集計されますし、注文明細をCSVに落として御社システムに取り込み〜なんてことも出来ます。

注文にかかる時間は、最低でも10分は短縮できます。3人が同時に動けば30分の短縮が可能です。時間勝負の場では、回転率が命!

技術的なアレ

nginx+Flask+uWSGI+Python3.4+mysql5.6 です。さくらのVPSで動いています。サーバーサイドは凄くシンプルです。

で、アプリはiOSAndroid、両方をネイティブで開発しました。最初は期間的な問題でHTMLの画面でやったましたが、動作が遅いのと万が一セッションに入ってるカートの中身が消えたら終わるので、サクサクかつローカルにデータを入れられるネイティブに切り替えました。はじめてのモバイルアプリ。iOSSwiftで書きました。ニッチな法人向けアプリなんで、iOS7以下は切りました。AndroidbluetoothのHIDモードが4.0以上でないとサポートしないので、4.0以上をサポートしています。

リピート率が勝負

業界も使用用途も頻度も限られているため、ガンガンと新規顧客が伸びていく種のものではない。なので、いかに「もう1度このサービスを使いたい」と思ってもらえるかが大切。時間が許す限り、ご利用して頂いてる現場に張り付いて商談の様子を見させて頂いております。現状では「もう使いたくない」とおっしゃられた所はありませんが、今後もそうあり続けられるよう頑張ります。

使う喜びないものは、誰もお金を払ってくれませんので。

最速で身につく要件定義入門という講座をスクーでやります

ご依頼があったので、やります。

schoo.jp

システムやアプリを構築する技術がどれだけ向上しても、技術だけでは「こういうシステムが欲しい」という合意形成を得ることは無理。

要件定義には、プログラミングと全く違う「技術」が求められるわけですよね。要件定義と言うと受託の香りがしますけど、サービス運営しているところだって同じことですからね。要件定義しないと、リリースできないわけですから。

個人的には、ITシステムが欲しいけど何をどうやってシステム屋に頼んだら良いか分からないユーザー様に、受講して頂ければと思います。生放送で受講される場合に限り、無料ですので。

それでは、どうぞよろしくお願い致します。

「エンジニアのためのデザイン入門」という授業をスクーさんでやります

schoo.jp

イシジマさんが「エンジニアやプログラマ向けに特化したWebデザインの書籍をやろうとしてるけど、エンジニアとコミュニケーション取りながらやらないとねぇ...」みたいな所に、僕がサンプルのサイトを提供したのがきっかけです。じゃあ一緒に授業もやりましょう、と。作った人間が目の前にいるほうが、より授業にも深みが出て面白いよねってことです。

僕はバックエンドよりもフロントエンドが好き。UIとか考えるの好きだけど、デザインのロジックがわからないので、いっつも適当にやって適当に出来上がってアンニュイな気持ちになっていました。

「デザインはどんなルールがあるのか、他の要因とどんな関係があるのかをロジカルに伝える」ことをポイントにしています。デザインってコードと違って写経するのも難しかったりしますよね。その意味で、この授業が「デザインを支える技術」についての理解の手助けとなるよう工夫していきますし、僕もその観点から講師のイシジマさんの知見を引き出そうと頑張ります。

7月14日、19時から生放送です。全4回の、1回目。どうぞよろしくお願い致します。

schoo.jp

【書評】C#実践開発手法 〜デザインパターンとSOLID原則によるアジャイルなコーディング〜

監訳者でおられる通りすがりのエバンジェリスト 長沢智治 (@tnagasawa) | Twitterから献本頂きました。

本書では「Adaptive Code」をテーマにしています。Adaptiveとは、コードを大幅に変更すること無く、新しい要求やシナリオに対処する適応力のこと、と定義されています。コードを大幅に変更すること無く変化に適用するためにはどうしたらいいんだっけ...っていう話を、デザインパターンやSOLID原則という概念を用いて解説する一冊になっています。

Adaptiveであるためには、とにもかくにも依存関係を整理しなければなりませんよね、という話から始まります。それをコードで表現したパターンを「Stairwayパターン」と表現しており、具象クラスの隠蔽を階段を登り降りするかのように表現しています。

依存関係をゼロにすることは出来ないけど、依存関係を疎結合にすることは出来ます。また、そうしないとダメな理由をこれでもかと言うぐらいサンプルコードを交えて説明しています。デザインパターンやTDDなども触れていますが、それらはあくまでも依存関係を整理することで、コードを変更すること無く変化に対応し、そのようなコードのテスタビリティが高い理由を説明する補足説明で使われています。

SOLIDの原則

この内容については本書をあたって頂くとして、面白かったのがSOLIDの「L」のパートで紹介されている、リスコフの置換原則というお話です。その中で「事前条件と事後条件」について語られており、それをコードベースで書くことが出来ます。事前条件は「入力となる対象全部の値が、そのメソッド正常に動作する条件を満たしているか」です。事後条件は「戻り値が有効な状態であるかどうか」です。

これを.NETの仕組みを使ってやるとこうなります。Beforeがif分岐コード、Afterが事前条件と事後条件をContractsを使ったものです。条件を満たせないとContractExceptionがスローされます。JavaでいうAssertみたいなもんですかね。

Before
public decimal CalulateCost(float kilograms,Size<float> inch) {
  if( kilograms < 0f ) {
   throw new Exception();
  }
  if(inch.X < 0f || inch.Y < 0f ) {  throw new Exception(); }
} 
After
using System.Diagnostics.Contracts;

public decimal CalulateCost(float kilograms,Size<float> inch) {

  Contract.Requires(kilograms > 0f);
  Contract.Requires(inch.X > 0f && inch.Y);

} 

C#erなら取り敢えず読んどけ

とにかく本書はしつこいです。しつこいぐらいコードを載せて「Adaptive」について400p近く語られています。本書でも「抽象化を行わなければ、無数の要求が大きな泥だんごと化し、責務はほとんど描写されず、結果としてユニットテストがなく保守も拡張も難しいのに、業務上不可欠なアプリケーションが出来上がります」と警鐘を鳴らしています。自分の明日の仕事をラクにするためにも、C#erは本書をあたる価値があるでしょう。

全然関係ないけど、個人的にはWPFのMVVMの決定的な入門書が欲しい。ピュアにC#で実現するパターンと、フレームワークを使うパターンで。しつこいぐらいそこを解説する本、なんか無いかな〜。

【書評】マリンITの出帆: 舟に乗り海に出た研究者のお話

地元の図書館にたまたま新着で入っていたので、読んでみた。とても面白い試みだったので、紹介します。

マリンITの出帆: 舟に乗り海に出た研究者のお話

マリンITの出帆: 舟に乗り海に出た研究者のお話

イカ釣りの機械のモーター制御からキャリアを開始

著者はカンブリア宮殿にも出演した東和電気製作所さんで、イカ釣りのモーター制御のプログラムを書くことからキャリアを開始。テグスがピンと張っている時は構造上イカが逃げることは出来ないが、船の揺れや海の状況によってテグスが緩みだすと、イカは逃げてしまう。

というわけで、漁船の揺れを検知してテグスが緩まないように、モーターの回転を制御するプログラムを書かれたそうです。C言語だよな、きっと。組み込み系の話は面白い。

ちなみに、簡単に言うとこういうロジックで算出されるそうです。計算の変換には積分を使うらしい。

  1. 加速度を検出し、速度に変換
  2. 速度を変位に変換し、モーターの回転速度に変換
  3. 補正する回転速度を出力

大人になると(特にITの仕事をすると)、数学が色んな現象をモデリングしていることに気づいて面白い。GPS三平方の定理を使って現在の位置を割り出すとか。学生の頃知りたかったですね。'`,、('∀`) '`,、

www.tbs.co.jp

ユビキタス・ブイ

「ホタテ養殖のために、海水温観測のブイを作って欲しい。10万で。」

環境省が導入するクラスのブイが、数千万円。漁業用で安価なものでも、数百万円。でも、ひとりの漁師が出せる予算は、10万円。水温観測をしたい理由は海水温を検知してホタテが大量死するのを未然に防ぐため。

・・・当初は10万円で出来るわけねーだろというお気持ちで試作品を作ったそうですが、漁業組合の青年会の方々の協力の下、地道なサンプルデータの収集を続けることで段々と実用化に向けた手応えを感じられ、「ノーマリーオフ」機能を組み込み実用化されたとのこと。素晴らしいですね。

その他にも色んなお話があり、iPadを使った漁業日誌アプリとか、漁船に無線LANを導入した話とか、現場に則した実践的なお話が多くて楽しく読めました。

制約なき開発は作業に過ぎない

本書の114p〜115pに書かれていて、これはと思いました。

新しいものを開発するときには、必ずチャレンジを含めるようにしている。つまり、少々厳しい制約を設けるのである。(中略) 何よりも、制約を設けないと工夫するために頭を働かせるチャンスを失ってしまうのである。実にもったいない。

最初からできる事が分かっている開発は単なる作業であり、そこに創造性はなく、次に活かせる技術も身につかない。その結果いいものはできず、達成感もないから愛着もわかない。

エンジニアの成長についてのほとんどすべてが書かれている文章ではないでしょうか。

マリンITの今後に期待します

今後のマリンITの目指す先はどこになるかわからないのですが、恐らくは方法論を確立して標準化を目指していくことになると思います。海水温のリアルタイム解析とか、海底の地図におけるGoogle Mapとか、やりたいことは色いろある中で、Python的な「間違えようのないやり方がひとつだけあるのが望ましい」という方法論を、産学連携して築いていけるといいなぁと思いました。

こういう話を聞いてると、ソフトのみでもたらすことが出来る革新的な物事って、そんなにないですよね。まずはハードを開発できないと新しい体験は生まれないだろうし、どんなにソフトをとっかえひっかえやっても、ハードそのものが変わらないとダメだなぁと。その意味で低レイヤーの技術とWeb技術の両方を会得するレイヤーフルスタックなエンジニアが、5年後には花型になってるかもしれませんね。

あわせてよみたい

news.mynavi.jp