月別アーカイブ: 2013年9月

[製品たまご]小銭不要のお菓子販売機「オフィス・クロノス」を構築してみた!

 

クロノスでは、iPhoneアプリやWebサービスといった製品開発に取り組んでいます。日々の製品開発の取り組みの中で、多くのアイデアが生まれています。シリーズ[製品たまご]では、製品化まであと一歩、そんなちょっとした面白アイデアをご紹介します。

製品たまごの記念すべき第1回は、製品開発チームのリーダー的存在、谷村(仮称)が取り組んだ小銭不要のお菓子販売機「オフィス・クロノス」をご紹介します!

問題:財布に30円しかない

▼谷村は語る

突然だがネットの前のみなさんはSquareリーダーをご存知だろうか。SquareリーダーはiPhone、iPad、Android端末につないで使うクレジットカードリーダーだ。早い話がSquareリーダーを使うとスマホでクレジット決済ができるというわけだ。

squarerimage

 

今日はSquareリーダーを使った小銭不要のお菓子販売機オフィス・クロノスの話をしようと思う。

ことの始まりはこんなかんじだったんだ。

 

▼ある日の会議にて

その日の製品開発会議は白熱していた。
議題はたしか、弊社のiPadアプリ「かおわらい」が市場に上手くリーチできていないとかだった気がする。

かおわらい:無料の子供向けおもしろ顔作成アプリです。

 

会議は紛糾し、予定の1時間を超過して延長戦に突入することになった。

ここで10分の休憩。時計は17時を過ぎている。

小腹が空いたな、オフィスグリコでお菓子でも買おうとおれは席を立った。

 

▼オフィスグリコの前にて

「堅あげポテトでも買うかな」おれは財布から小銭を取り出そうとした。そのとき事件は起きた。

 

財布に30円しかないのである。

 

一度話を整理しよう。30円しかない、というのは正確ではない。正しくは1万円札はあるのだ。しかし、オフィスグリコのインタフェースは1万円札に対応していないのは明らかだ。

officeg

 

このとき、おれの製品開発魂に火がついた。

 

▼会議は再開する

間もなく会議は再開した。室長がモニターを操作している中、開口一番、私は提案した。

「みんな聞いてくれ!小銭がなくてもオフィスグリコで買い物できないかな?」

 

あっけに取られた参加者達。静寂が会議室を包む。

 

「意味がわからないしぃ、カエルかわいいけどむりむりー!image517DB担当hiromiが静寂を破る。

 

ざわざわ。

 

「・・・かおわらい、の会議中ですよ」室長がつぶやく。

「すみません、でもどうしてもオフィスグリコで買い物をしたいんです!小銭がないんです!」

「・・・よろしい、これを使いたまえ」室長は胸ポケットからSquareリーダーを取り出した。

解決:クレジットカードでお買い物

▼Squareリーダー

SquareリーダーはiPhone、iPad、Android端末につないで使うクレジットカードリーダーだ。(詳しくはGigazineさんの記事を参考にしてほしい)

squarerimage

 

「Squareリーダー・・・これなら、これならいけるかもしれない!」

おれの脳内で右脳と左脳が激しく共鳴した。
オフィスグリコのような「置き型お菓子サービス」に「Squareリーダー」を組み合わせれば、小銭による買い物の煩わしさを解消できる。そして、以下のような効果が得られのではないか。
小銭を準備しないでお菓子が買えるのでお菓子がたくさん売れるはず!
そして社員の満足度もUPするはずだ!

実験開始!

▼オフィス・クロノス開店準備

翌日、アイデアが固まったので早速、実験してみることにした。作業は次の3ステップだ。

 

1. Squareリーダーを入手する

カード決済を行うためには、iPhoneやAndroid端末に接続する「Squareリーダー」を入手しなければならない。驚くなかれ、Squareリーダーはローソンで販売されているのである。コンビニでクレジット決済システムが買える、なんだか夢のような話だ。

 

2. アカウントを作成する

続いて、Squareサイトでアカウントを登録する(https://squareup.com/jp)。メールアドレスにパスワード、口座番号の入力が必要だ。
(アカウント登録後に、Squareが口座の利用確認を行う。そのために数日待つことになる)

 

3. 商品(と商品マスタ)を準備する

あとは商品を準備すれば完了だ。独自のルートで仕入れておいたお菓子に対して、商品の仕入れ値にカード決済手数料(2013年9月現在:3.25%)を上乗せするかたちで商品マスタの登録を行った。(今回はあくまで実験目的なので、利益が発生しないように設定した)

 

▼オフィス・クロノス開店!

準備は整った。心も整えた。まずはオフィス・クロノスを見てほしい。

officekronos

 

どうだろう。アカウントの登録確認に数日かかったが、実働3時間程度でここまでできた。写真右下のiPhoneに注目してほしい。オフィス・クロノスのお菓子類を購入する場合は、クレジットカードで決済することができるのだ。

準備ができたので、これから5日間の売上を確認することにした。

検証!

▼売上は伸びたか

開店から5日。お菓子のほとんどは完売した。予想していたとおり、売上は上々の結果を納めた。Squareサイト上で売上レポートも確認できる。

sale

 

▼社員満足度は高まったか

つづいて、社員満足度はどうか。社員へのアンケートから以下の回答が得られた。

「小銭を準備しないでいいのは良いね。カード決済が新鮮で面白い!」
「レシートがSMSで届くのはカッコいいね」
「お菓子買うだけでサインするのが面倒かな」
「好きなお菓子をリクエストしたいなー」
「お財布携帯は使えないの?」
「間違えて商品マスタを編集しそうになりました!」

また、社内メンバーの88%が利用したこともわかった。

フィードバック

まず、実験してみて気づいたことは3つある。

1. 売上動向を即座に確認できる
商品の売上データは、Squareのサイト上で確認できる。今回は検証していないが「スタッフを代理とした決済」機能も用意されている。この機能を使えば代理人のSquareリーダーからの売上情報も管理できるようになる。もし、実際の置き型お菓子販売業者が同様の仕組みを導入すれば、より効率よくお菓子を配布できる!のではないだろうか。

 

2. あくまでレジ。自動販売機のようには設置できない。
実際に試すまで気づかなかったのだが、Squareリーダーはレジのような位置づけの製品であった。つまりレジを操作する店側の人間のためのものだ。そのため、iPhone端末上で商品マスタを編集できるようになっている。今回実験したソリューションは自動販売機に近いものであった。そのため、利用者に対して商品マスタを編集しないよう周知しておく必要があった。
とはいえ、自動販売機型のソリューションに面白みがあった点は強調しておきたい。

 

3. クレジットカードよりお財布携帯の方がいい?
これも実際に購入を経験してみてはっきり感じたことだが、小額の決済(100円程度)にクレジットカードを使うのは仰々しい感があった。社員の声にあったお財布携帯のようなインタフェースで検証してみるのも面白そうだ。

 

インスピレーション:自動販売機型ガジェット!

今回の実験を通じて、小銭不要のお菓子販売機は面白いと感じることができた。一方で、Squareリーダーは自動販売機のように設置できない、また、お菓子の購入にクレジットカードの利用は仰々しいというフィードバックが得られた。これらの問題を解消するために、以下のような仕組みを提供すればどうだろうか。

・レジ端末に自動販売モードを追加する

・在庫管理システムと連携する

・クレジットカードだけでなく携帯電話や暗証番号で購入できる

 

次なる製品企画の輪郭が見えてきた。コンセプトは「自動販売機型ガジェット」といったところか。

 

明日の製品開発会議も長くなりそうだ。

 

一緒にまなぼ!「hiromi と楽しむOracleパフォーマンスチューニング!」【Vol.2 Statspackを見てみよう】

オラクル女子

 

こんにちわぁ~ひさしぶりだね~image465

 

また見にきてくれてありがとぉ~Oracle女子のhiromiですimage517

みんな元気だったかなぁ?hiromiは元気ーnewimageneru9

でも最近、お友達とショッピングするよりもOracleのサイジングについて考える方が楽しくなっちゃって、仲のいい友達がどんどん離れていっちゃうよーってのが一番の悩み。

でもまあOracle触ってたらそんなことすべて忘れちゃうんだけどね。ふふimage582

 

早速なんだけどー、前回は実行計画についてれくちゃーしたから、今回はStatspackについて教えちゃおうと思うのー。いいかなー?

Statspack、すたっつぱっく、ね。はー?Statspackってなにー?って感じだよねー?

早く知りたいよねー?じゃあもういっちゃおかーimage576

 

Statspackってなにーなにー?

 

Statspackっていうのは、Oracleが標準で提供してくれている性能を分析するためのツールだよ。

無料だよ、無料。It’s Free!

hiromi、無料大好き。サンプル化粧品とか試食とか無料って超好き!image582

 

実はAWRっていうものすごーく細かく分析できるツールもあるんだけど、こっちは有料なの。もしStatspackじゃものたりなーいって人はぜひ調べみてねimage517

 

で、Statspackを使うとOracleの使用状況を見ながら分析レポートを作ってくれるんだけど、定期的に、そう、1時間毎くらいにレポートを出力することなんかもできるんだよー。1時間単位のレポートだとその前後のスナップショットをもとにして、その1時間で繰り広げられた処理の情報を元にいろいろ教えてくれちゃうんだよー。まぢで、すごくない?image578

 

 

とりあえず、実際のレポートをみちゃおう!

 

どう?よくわかんないよねー?hiromiも最初見た時わけわかんなすぎて、Oracle女子やめてDB2女子になろうかと思ったもん。ウソだけどね。えへ。

 

大事なところを順番に拡大して説明しちゃうよーimage1601

 

 

いち

image1612データベースの特性を見るならLoad Profile♥image1612

 

 

そう、まずはここ。赤で囲んでいるところね。ここはLoad Profileっていう項目なんだけど、ここを見ればデータベースの特性とか傾向をざーっくり見ることができるんだよ。

 

  • Redo size:Redoログ生成量
  • Logical reads:論理読み込み量 (ブロック数)
  • Block changes:変更量(ブロック数)
  • Phsical reads:物理読み込み量 (ブロック数)
  • Phsical  writes:物理書き込み量(ブロック数)
  • User calls:ログイン、解析、フェッチ、実行などクライアントが生成した処理数
  • Parses:パース全体回数
  • Hard Pareses:ハードパース回数
  • Sorts:ソート回数
  • Logons:ログオン数
  • Executes:SQL実行回数
  • Transactions:トランザクション回数

 

なんか参考になりそうな感じするでしょ~!

たとえば、Parsesの回数に対してHard Parsesの割合が大きいほど超ハードパースしちゃってんじゃんてことだから、バインド変数を使うように修正できるSQLがないか探してみるとかー、共有プールサイズを大きくしてみるといいと思うよimage465

 

ちなみに、SQLの空白の数とか改行の位置が違うだけでも、それぞれ別ものってことでハードパースされちゃうからね~

 

じゃあ次のレポート見てみよっかーimage1687

 

 

 

に

image1612Instance Efficiency Percentageでインスタンスは効率的に♥image1612

 

 

Instance Efficiency Percentageっていう項目なんだけど、簡単に言うと「インスタンスが効率的に使われてるのー?」ってことだよ。非効率だと全体のパフォーマンスに影響するからねー。非効率ダメ、絶対アカン!

 

Load Profileにでてきた数値だけぢゃ、ぶっちゃけパフォーマンスどんなもんなの?ってところがパーセンテージでわかっちゃうー!

だいじな項目の意味はこんな感じだよimage517

 

  • Buffer Hit:バッファキャッシュヒット率、データがメモリにのっているか
  • Library Hit:ライブラリキャッシュヒット率、SQLがメモリにのっているか

 

このへんの項目が100%に近かったら効率的に使われてるよー、ってことなんだ。このサンプルとか超イイ感じ~♪データもSQLもメモリからスルスルスルリ~ンてとってこれてるねー。

ココはわかりやすよねー。hiromiも喜怒哀楽が激しいから、超わかりやすい子ってよく言われるんだー。激おこぷんぷん丸!image516

 

で、95%以上が理想的らしーんだけどね、それより低かったらどーすんのよって?まぢ焦るよね。Buffer Hitはー、バッファキャッシュのサイズを大きくするとかー、SQL実行タイミングを調整してみるといいかもねー。SQLを実行しまくって、いろんなデータを取得すればするほど、その分バッファキャッシュはパンクしちゃうからねー。パンクしたら、また物理読み込みが発生して、パフォーマンスが低下しちゃーう(泣)kame1

 

同じデータを使う処理をかためたり、バッチの実行時間をほかの処理とかぶらないようにを調整することで効果が出ることもあるかもしれないよ~piyo1

 

Library Hitは、Load Profileで書いた超ハードパースしてんじゃんってのがパーセンテージで見えるんだよねーわかりやすーい!でも、Hitって言ったらやっぱりイチローだよねー。4000本とかまぢ神!実は、hiromi野球好きだったり~、てゆーか、やっぱりやっぱりスポーツしてる男子とか超カッコイイっしょimage582

 

ハイ、次ね、次。次はここ。

 

 

 

 

さん

image1612Top 5 Timed Eventsは超頑張ってる奴ら!image1612

 

 

Top 5 Timed Events、簡単に言うと「超頑張っちゃってるイベントの上位5つ」だよーimage578

 

よく見るイベントはサンプルのなかからコレ!

 

  • CPU time:CPUの使用時間
  • db file sequential read:単一ブロック読み取り
  • db file scattered read:複数ブロック読み取り

 

「CPU  Time」はね、CPUを使用して処理してる時間だからいいとしてー、それ以外でなに頑張っちゃってるの?ってところがパフォチュの観点だよね。「CPU time」が一番上にきてると、まぁイイ感じらし~よ~image576

 

このサンプルの場合だと、「CPU Time」よりも上に「db file sequential read」てのがきてるよね。キングだよね~なんでキングとってんのかってゆーと、インデックスで検索をして単一ブロックを物理読み込みしたからってのが一番の理由だと思うんだよねー。

てことは、イベントだけで言うと悪いやつってわけでもないよね。「db file scattered read」も物理読み込みが発生してて、こっちは全表検索をして複数ブロックを読み込んでいる可能性が高いみたい。

 

「db file sequential read」でも「db file scattered read」でも、まずはどのSQLで物理読み込みが発生しているのかを突き止めちゃおーよー。で、どうやって突き止めるかというと・・・、Statspackのレポートの「SQL ordered by Reads」ってのが物理読み込み回数が多いSQLを示してくれてるんだよね!!超タスカルー!!

そしたら、インデックス設計を見直したりー、読み込み対象のデータが多くなりすぎてるようだったら、パーティションを使ってみるとか、考えてみてほしぃなぁ~image582

★もっとイロイロできちゃうStatspack

Statspackって実はもっともっといろんなことを調べられちゃうの。たとえば・・・

 

  • 実行時間が長いSQL(SQL ordered by Elapsed)
  • CPU使用時間が長いSQL(SQL ordered by CPU)
  • 実行回数が多いSQL(SQL ordered by Executions)

 

とかね。

でもhiromiはこれから青山でOracle男子とコンパだから、もし興味があったら各自で調べてみてー。うふふふーimage582

 

 でわ、ばいばぁ〜いkaerup