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

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

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

▼谷村は語る

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

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

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

▼ある日の会議にて

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

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

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

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

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

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

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

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

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

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

▼会議は再開する

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

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

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

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

ざわざわ。

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

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

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

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

▼Squareリーダー

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

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

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

実験開始！

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

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

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

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

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

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

3. 商品（と商品マスタ）を準備する

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

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

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

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

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

検証！

▼売上は伸びたか

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

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

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

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

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

フィードバック

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Statspackってなにーなにー？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Top 5 Timed Eventsは超頑張ってる奴ら！

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

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

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

このサンプルの場合だと、「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を示してくれてるんだよね！！超タスカルー！！

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

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

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

とかね。

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

 でわ、ばいばぁ〜い

こんにちわ〜はじめまして〜Oracle女子のhiromiです

hiromiのことを先にちょっとだけ紹介させてね。あたし、

カワイイものすき〜

イケメンすき〜

みんなでワイワイするの大すき〜

な感じのふつ〜の女の子。でも、ITエンジニアなの。見えないってよく言われる。

でも、Oracleと出会って、DBが気になってきて・・・で、ER図描くのが好きになって〜って、自分でもウケる〜。

そんなあたしが、みんなのお役に立てたらなって思って、hiromiが知ってるOracleのパフォーマンスチューニング（ぱふぉちゅ）を教えるよ〜

hiromiと一緒に楽しくパフォチュしてみよ〜

SQL遅ぉ－い（泣）、と思ったら実行計画を見てみよう

作ったアプリケーションがなんか遅いな〜なんて思って調べてみたらSQLが遅いせいだった！なんてことよくあるよね。

そういう場合はまずSQLの実行計画を見るの。そっこ〜見る!!実行計画は、どうやってどんな順番でデータを読みに行くのかっていう道すじを表してくれるもののことね。

SQLの実行計画を見るには３つの方法があるんだけど

だよ。すぐ使えちゃうから、試してみてね!!

AUTOTRACE機能

Oracleの機能にはAUTOTRACE機能っていうのがあるの。おーととれーす

で、これがなにかっていうと、SQLの実行計画を集める機能なの。SQL*Plusなんかで「SET AUTOTRACE」っていうコマンドを実行すると使えるんだけど、そのあとに実行したSQLの実行計画が自動的に出力されるようになるんだよ。ちょ〜便利〜

オプションがいくつかあるんだけど、それぞれの意味を書いておくね。ぶっちゃけ、「SET AUTOTRACE ON」だけ覚えてたら十分見れるんだけどね〜

このSET AUTOTRACEコマンド、気をつけなきゃいけないのは、実際にSQLも実行されちゃうってこと。だから、DELETE文の実行計画を確認したい場合にはちょっと不向きかなぁ。せっかく入れたデータが消えちゃった－（爆泣）!!ってことになっちゃう。

でも、簡単で覚えやすいから１番おすすめ〜

EXPLAIN PLAN文

実行次はEXPLAIN PLANだよ。

さっきのAUTOTRACE機能は、実際にSQLが実行されちゃってDELETE文のとき困るよね。どうすりゃいいの〜ってときに使えるのがEXPLAIN PLAN

じゃあ実行の仕方を教えちゃうよ〜

これでこのSQLの実行計画が出力されるの。でも、長くて覚えるのたいへんだよね〜・・・

だから、hiromiも使うときメモったの見たり、調べなおしたりしちゃう（笑）EXPLAIN PLANは、AUTOTRACE機能と違って解析したSQL１回ぽっきりの出力で終了。その代わり、１回解析したSQLは、さっきの実行方法２行目のSELECT文を実行すればEXPLAIN PLAN文を打たなくても見れるからね。

実際に実行したらこんな感じに出力されるよ

V$SQL_PLAN参照

最後はV$SQL_PLAN。

V$ってなんだろね？よくわかんないけど、Oracleが用意してくれいてる便利なビューはV$という文字で始まるみたいだよ。ちなみに動的パフォーマンスビューっていうらしいよ。どうてきぱふぉーまんすびゅうV＄はぶいだらー。このV$で始まるビューはほかにもいろいろあってどれも便利で使えるヨ!!

じゃあ、V$SQL_PLANってどんなビューかっていうと、ハードパースされたSQLの実行計画を一気に確認できる表なの。ハードパースって、OracleがSQLを解析することね。

SQLを実行するときって、まず最初にSQLを解析して実行できるかどうか、どう実行するのかを考えて、その解析結果とか実行計画をライブラリキャッシュっていう箱に入れておくの。それで、次に同じSQLを実行しようとしたときには、この箱から出して使うの。ハードパースするのに時間くっちゃうからね、同じSQLだったら解析する手間を省いて、はやく結果を返してあげられるってことね。

Oracle賢い〜やさしい〜!!

賢くてやさしいOracle君のイメージを描いたら、こんな感じかな。

イメージつかめてもらえたかなぁ？

ライブラリキャッシュっていう箱がある共有プールってのは、Oracleのなかにあるメモリのお話だよ。
みんなで一緒に使うものをためておくところだから「共有プール」って名前っぽいよね、hiromiも知らないけど〜

それで、ハードパースしたSQLの実行計画はV$SQL_PLANを検索すると見れるんだけどね、実際にV$SQL_PLANを全件参照してみた結果サンプルを見てみて。

なんだこれ〜〜〜〜〜、うーん、、、って、よくわかんないよね

結局、V$SQL_PLANだけ見ても、どのSQLのものなのかわからないのが正直なところ。解析済みのSQLの解析結果が全部入ってるからね。だから、どのSQLの実行計画か知るためには、先にV$SQLっていうビューから実行計画を見たいSQLのSQL_IDっていうキーを拾っておかないといけないんだよね。

なんか、これだけ聞くとV$SQL_PLANとか見るの面倒くさいし、使わなくてよくない？って思うけど、ちゃんと出番があるんだよ〜

実際にそのDBを使ってるアプリケーションが実行したSQLの実行計画を見たいってときには、コレしかないんだよね。今までの２つの方法は、SQL*Plusなんかで直接SQLを実行するときに見る方法だからね。

それとね、アプリケーションが動いてたくさんのSQLが実行されたなかから、全表走査（テーブルの全レコードを読み取ること）している実行計画を見つけて、そのSQLを探りあてたい！ってときとかV$SQL_PLANを見ることから始まるね。全表走査は、レコード数が多いとその分読み取るのに時間がかかってしまうから、場合によっては良くなかったりするの。

実行計画を見る３つの方法の説明はここまでだけど、そういえば実行計画の見方を教えてなかったね

実行計画で確認する項目にアクセスパスがあって、OPERATIONってところに（V$SQL_PLANは、OPTIONS列も）「TABLE ACCESS FULL」とか「UNIQUE SCAN」とか書いてるよね。これが「データをどうやって検索するかー？」ってことなの。アクセスパスにはいろんな種類があって、さっき話に出てきた’全表走査’ってのもコレでわかるってこと。「TABLE ACCESS FULL」ってのが、それだよ〜

ほかにもインデックスとテーブルのアクセスパスがあるから挙げておくね。

じゃあ今日はこのへんでおしまい

次回は「Vol.2 Statspackを見てみよう」でね！ばいばぁ〜い