GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

チケットを営利目的で転売する問題をどう解決するか

今日はセ・リーグの優勝が決まるかもしれない日です。しかも、ホームでの神宮球場の試合。チケット争奪戦が予想されていました。

当然のごとく、チケットの販売時間から球団公式サイト「スワチケ」は非常に接続が困難になり、仮押さえしたらSorryページに飛んだり、クレカの決済確認でSorryページに飛ばされて購入できない人がたくさん出ました。熱心なヤクルトファンの方が購入できなかったり、昨日のチケットをとっていたのに中止になって今日のチケットを買えなかった人も、たくさんいると思います...

その一方で、転売目的でチケットを入手した人もたくさんいたようで、ヤフオクで「神宮 ヤクルト 10/2」で検索した所、かなりの数が引っかかりました。

f:id:gothedistance:20151002114957p:plain

心情としては、本当にその公演を楽しみにしている人に適切な価格で購入できるチャンスが損なわれてしまう誠に遺憾であります。

本人縛りでは不都合も多い

転売自体を防ぐことは可能です。可能にするには、購入者以外の譲渡を一切できないように縛れば良い。購入時に顔認証やAppleのTouchIDのような指紋認証を入れるなどすれば本人以外の来場は無効となります。購入時にチケットに対して指紋を紐付けて、その指紋の変更を不可にし、入場時に来場者との指紋称号を行えば入場可能となる。こんな仕組みがあれば、転売を防ぐことは可能でしょう。

オークション等の転売市場に流出することを防ぐのはまず無理ですから、購入者以外の来場を全て無効にしてしまうのが、一番シンプルな解決策です。

が、他人に全く譲渡できないというのも不都合が多いですよね。

転売は真っ当な商取引

恐らくコンサートでも野球でも同じでしょうが、その公演自体が中止にならない限り、チケット購入後のキャンセル・変更・払い戻しは一切できません。明確な理由はわからないのですが、変更が可能となると色々と手続きが大変なのでしょう。

体調が悪くなったり、都合がつかなくなったりで、自分の友だちに代わりに行ってもらって楽しんでもらいたいと思うのは当然のことですし、「そんなの知るか。来れないなら買うな」では乱暴すぎるのも事実です。購入した商品をどういう形で使うかは、原則として消費者の自由。

が、転売を可能にする仕組みがあると、その転売の良し悪しを判断する手段が無いんですよね。違法性が無いからです。転売がNGなら、オークションは全てNGになります。大きく言えばフリマもNGになるでしょうし、金券ショップに売りに行くのもNG。

ダフ屋が現地会場近くで転売してれば地方迷惑条例等でひっかかりアウトですが、ネットオークションや金券ショップで買った事自体は完全に合法なわけですよね。乱暴に言えば「転売の問題って、チケットを定価で買えない恨み節でしょ?」と言えばそれまでの話。3倍でも買いたいという要求自体に違法性は無い。

嵐のコンサートチケットでヤフオクで出店されたのが確認された座席を無効とするという試みがあったそうです。本来は転売屋が罰せられるべきで金で解決した人には罪はない。転売を間接的に無効にするぐらいなら、本人認証必須のほうが筋が良いと思います。

転売の是非を決めるのは主催者

結局のところ、転売自体は真っ当な商取引ですからそれを取り締まるのは無理があります。さしたる社会的意義もない。公演を主催する立場の方が、転売を是とするか非とするかを決めるしか無いというのが現実的な落とし所だと思います。

転売を非とした場合、都合がつかない等でそのチケットが不要になった場合にどうするかという課題は残ります。ぴあの再販サービスのように、「キャンセル待ちで定価で買える」サービスを作って、そこを通さないで購入したチケットは無効とする。

・・・が、そこまでのインフラを作る金銭的負担は主催者にあるわけですし、チケットの売買利益が食われちゃうとやる意味がなくなる。その分の投資をするんでチケット代が15%上がりますとかだったら、納得出来ない人が多いよね。そんなことにはならないと思うけど。


なかなか難しい問題ですが、良い落とし所が見つからないものかと悩みます。

【書評】PHPはどのように動くのか〜PHPコアから読み解く仕組みと定石〜

技術評論社の傅様よりご恵贈頂きました。いつもありがとうございます。

PHPの文法の解説ではなく、PHP4以降のコアとなっているZend Engineの解説書です。技術評論社でしか世に出せない一冊ではないでしょうか。

PHPコアとは何か

PHPは御存知の通り、インタプリタ型の言語です。PHPスクリプトを字句解析→構文解析を行い、「オペコード(opcode)」にコンパイルして、PHPの実行エンジン(Zend Engine)に食わせて実行します。このオペコードがどのように生成され、実行されているのか。割り当てた変数や関数のメモリはどう管理されているかを実行エンジンレベルで読み解いていくことで、PHPで書いたスクリプトの意味を見直そうというのが本書の趣旨です。目の付け所が濃ゆいですね。

オペコードのパフォーマンス

本書の第2章「オペコードのパフォーマンスを考える」が最も個人的に面白かったです。PHPスクリプトのパフォーマンスはオペコードで決まる、と。自分の書いたPHPスクリプトがこう評価されて実行されるのかと。演算子ひとつとっても、変換されるオペコードが違うのだなぁ...と。気をつけようって思いました。

著者とは違う方の資料ですが、この資料もオペコードを知るのに大変参考になりました。PHP5.5系から組み込まれたオペコードの最適化及びキャッシュを行う「OPcache」の解説です。

www.slideshare.net

コピーオンライト

PHPの実行エンジンの仕組みとして、コピーオンライトというものがあります。PHP5系では、全ての変数の型がコピーオンライトで管理されます。ある変数を代入して参照する時は同じメモリ領域を参照するだけで、コピー後の変数を書き換えた時に新たにメモリ領域を確保するという仕組みです。

<?php
$foo = 'foo';
$bar = $foo; //同じメモリ領域を指す
$bar = 'bar'; //新規にメモリ領域を割当

メモリ領域を節約できるので良さそうなのですが、PHP7系ではコピーオンライトを行う変数の型が制限されました。それ故にパフォーマンスの向上が見込めると本書にはあります。なかなか面白い話ですので、続きは本書をあたって下さい。

C言語の知識があると望ましい

Zend EngineがC言語で実装されていますので、C言語の知識があるとより本書の言わんとしてることが見えてくると思います。僕はほとんど知らないので、基礎文法ぐらいは抑えておこうかなって思いました...

PHPを書くなら目を通しておこう

オペコードを見て「へーそうなんだ」ぐらいの解釈でも全然OKだと思います。オペコードなるものに変換され実行される仕組みを全く知らないのは、PHPを書くのならもったいない。基礎知識として持っておくべきです。ざっと目を通しておくだけでも、何かしら知らなかったPHPの知見を得られることでしょう。

面白かったです!

雑貨業界の展示会運営サービス、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

システム内製か外注か、どちらを選択すべきか問題

atsuizoさん、ちーす。また飲みましょうー。

atsuizo.hatenadiary.jp

僕も強烈な内製回帰厨なので、本件については黙ってはおれませんでした。

内製がメリットを生む条件

何事も条件が揃わないとメリットは生まれません。僕は以下のとおりに考えています。

  • 事業の差別化要因が強化されることが期待できる。
  • 継続的に手を入れるだけの理由がある。
  • 外部サービスで代替出来ない理由が明確である。
  • デモテープを作ることが出来る人材がいる。

これら全てにYESと言えない場合、外注を検討したほうが良いでしょう。継続的に手を入れる理由がないなら、買ってくればいいんです。改善する理由が見つからないなら、リソースを割く意味が無い。リターンがないからです。重要なのはROI...というか、これだけ。内製することでROIを高めるためには、事業の魅力がアップしなければならない。よりお客さんが選んでくれる理由を濃くするか、増やさなければなりません。

ITで事業の魅力を高める手段は、色々あります。ネットショップの自作なのか、社内業務の高度化なのか、顧客向けサービス開発になるのかは、なんとも言えません。共通していることを大きく言えば、競争力の強化ですか。で、それはどうすれば実現されるかって話なんですけど、この2つしか無いんじゃないかと思ってます。

  • ビジネスモデルは今まで通りだけど、圧倒的にオペレーションが高度化される。
  • ビジネスモデルの再構築を行い、競争優位に立てる。

ITの話じゃなくなりましたね・・・。弊社の場合は前者の比率が大きかった。

ただ、経営判断をしたくても「出来上がったものを見せてよ」っていう話に絶対になります。口に入れてみないと判断できないので。その意味で「デモテープ」を作ることが出来る人材が必須で、極端に言えば「デモテープ作って下さい!」っていうオファーをクラウドソーシングでやってもいい。コード書かなくてもPaas(Kintone等)で作っても全然OKじゃないですかね。

デモテープ作ったら「やったぜ、これを公開して早速儲けよう」とするのが経営。しかし、どこかで「デモテープとレコーディングはレベルが違うんです」っていう話をしなくてはならず、それが出来る人材がユーザー企業に圧倒的に少ないというミスマッチを強く感じています。継続性に欠ける理由もここにありそうです。

内製化の人材確保問題

僕が何かしらの理由で一時的なり長期的なり永続的なり弊社を離れることになってしまったら、どうなるか。永続的に離れたらシステムダウンの時が弊社の終わりの時でしょうね。現場が崩壊します。零細企業なんてそんなもんで、そのリスクは受容するしか無い状態です。金もないし。

長期的(数年)離れても、別に問題無いです。仮に退職しても、僕個人にメンテ料を払ってもらえればちょいちょい手を入れるだけで済むぐらい、システムとして完成されたので。全てが僕の頭に入っているからできる事なんですけど。

僕の存在自体がメリットであり、リスクとなっています。死なないように鋭意努力します。

顧問プログラマ

人材確保のひとつの理想として、倉貫さんの「顧問プログラマ」っていう考え方を紹介します。IT技術は高度な専門職。会計士のように月額定額でサービスをして、IT経営を実現するためにコードを書いたり、要員の教育をしたり、外注とのやりとりをしたりする。そーゆー小回りの効くプログラマが圧倒的に足りないのは事実ですし、雇用するにはハードルが高過ぎるのも事実です。定額制でサービス化したいよね、と。人月最高だね。

kuranuki.sonicgarden.jp

世の中がソフトウエア化(ありとあらゆる情報がソフトウエアによって管理されること)する流れが進むわけですから、顧問プログラマにスポットが当たってもいいはずなんですけどねぇ... 特にユーザー企業さんに。本業がITではない所に。どうしたらいいんだろう。

作るだけじゃ意味が無いから、継続的にユーザー企業にIT支援を行えるような人材流通・流動の仕組みができるといいなぁという結論に、内製と外注を考えると落ち着いてしまう今日この頃です。

「これって、ドメイン駆動設計?」という資料を公開しました。

いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。

www.slideshare.net

ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。

ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。

  • その世界で現状行われていること
  • 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい)

上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが1つ。

で、ドメイン(特にいまやってる物事)を抽象化するには、「で、それってどういう情報をやりとりしてるんだっけ」「どんな意味があるんだっけ、その情報」って話になりますよね。それをモデルにして、モデルに対してプロパティとメソッドを与えていくのが、基本線なんじゃないでしょうか。オブジェクト指向やん、要は。

なので、ドメインっていうものをモデルに抽象化してオブジェクト指向の考え方を元に分割統治することで秩序を保ちながらドンドンできる事を進化させましょう、っていうのがもう少し実装に寄り添ったドメイン駆動設計で目指すことのように思いました。

未だによくわかりませんが、「ドメイン駆動設計は、みんなの心のなかにありまぁす!」っていう話は飽きたので、こんな感じでええんちゃうのという資料です。

ご興味のある方、ご自由にお使いくださいませ。

「みんなの転職」様に記事を寄稿しました

寄稿のご依頼を頂きまして、転職に関する記事を書きました。

www.tensyoku-hacker.com

能ある鷹は爪を隠すではダメで、能ある鷹は爪を出してアピールしないと何も始まらないぞ、という所を重点的に書いています。

よろしくお願い致します。

www.tensyoku-hacker.com

SQLを学習できるWebサービスを作りました。