コラム

ガワアプリの作り方

smp.jpg

【ガワアプリとは何か】

スマホやタブレットのアプリには、Webページを使って画面を実現する「ガワアプリ」と呼ばれるタイプが存在します。

ガワアプリの「ガワ」は少々俗な表現で、「外側」あるいは「何かを包む皮」の「ガワ」を指しています。ガワアプリとは、ブラウザ機能を内蔵して特定のWebサイトを表示することを主機能としているアプリのことです。逆に通常のアプリはネイティブアプリと呼ばれます。

ガワアプリの最大の特徴は開発費が安いことです。Webサイトがすでにある場合は、プログラムの開発対象が「ガワ」とその付加機能に限られるため、ごく少ない開発規模でアプリを作成できます。

ガワアプリであっても、アプリとしての体裁は普通のアプリと同じです。App StoreやGoogle Play等からスマホやタブレットにインストールし、アイコンをタップして起動、普通に操作できます。ユーザーインターフェイスはWebページなので、操作時のなめらかさや凝った操作性の画面は実現しにくいのですが、表示自体はWebコンテンツなので十分リッチです。細かな違いを気にしないユーザーは、アプリに表示されているのがWebであることに気づかないかも知れません。

【開発方法・作り方】

アプリでWebページを表示するには、「アプリ内ブラウザ」と呼ばれるブラウザ機能をアプリに組み込みます。ガワアプリでは、基本的なUIをこのアプリ内ブラウザで実現するため、ユーザー操作に対する反応の処理は、HTMLに組み込んだJava Scriptかサーバー上のプログラムで行います。

画面に表示されているのはWebページなのでサーバー上のプログラムは普通にPOSTで呼び出せますし、Ajaxの手法でHTMLの画面を切り替えること無く、バックグラウンドで呼び出すこともできます。

少々凝った実装だと、アプリ内ブラウザに表示したWebページと、ガワアプリ自体のネイティブコードを連携させることもできます。最も代表的なのはカスタムURLスキームと呼ばれる手法です。htmlやスクリプトから特殊なURLを指定することで、Webページからアプリのプログラムロジックを呼び出します。他にはアプリ内ブラウザのサーバーアクセスをアプリのネイティブコードから監視する方法もあります。

この連携によってWeb画面上のボタンのタップを起点に、Webでは実現できない機能、例えばスマホのカメラを使ってバーコードを読み取るなど、ブラウザだけでは不可能な機能を実現できます。

【アプリ審査】

開発したアプリを企業内のみで利用する場合は良いのですが、アプリを一般公開する場合、iPhone/iPadアプリはApp Storeに登録するための審査を受ける必要があります。ガワアプリを申請する場合は、Webサイトが単純すぎる場合は、単にWebページをアプリから表示するだけであると判断され、アプリとしての価値がないとして却下される可能性が高いです。

審査ではアプリのUIは常に「very good」のレベルが要求されるほか、様々な条件をクリアする必要があります。この審査対象はネイティブ実装かどうかは関係なく、アプリ内ブラウザに表示されるWebページもアプリの一部とみなされますので注意が必要です。

【ガワアプリの例】

例えば、自社専用のECサイトがある場合、次のようなガワアプリを安価に開発できます。

自社のECサイト専用のガワアプリを作成します。次の仕様を盛り込みます。
・自動でユーザーのログイン状態を維持します。
・ユーザーが希望するキャンペーン情報や、購入後の発送情報をプッシュ通知で伝えます。
・ECサイトには掲載していない新着商品や、店舗情報、店舗のスタッフブログを表示します。

【まとめ】

ガワアプリは安価に開発可能です。しかも表示するコンテンツ次第で素晴らしいアプリになります。またWebページを表示するだけではなく、プッシュ通知や地図表示などアプリならではの機能を組み合わせることで、さらに優れたユーザー価値を得ることができます。スマホやタブレットに最適化されたECなどのWebシステムをお持ちの企業は、一度ガワアプリの作成を検討してみると良いのではないでしょうか。


[inline]
<p>
最近の業務用のWebシステムではグラフ表示を取り入れる機会が増えてきました。
<br />
</p>
[script src="http://www.cmpd.jp/blog/Chart.min.js"][/script]
<style>
.center {
margin-left: auto;
margin-right: auto;
text-align: center;
}
#pieLegend {
padding: 10px;
overflow: hidden;
position: relative;
}
ul.pie-legend {
list-style: none outside none;
float: left;
margin: 0 0 0 0;
padding: 0;
position: relative;
left: 50%;
}
ul.pie-legend > li {
float: left;
margin-right: 5px;
padding: 5px;
position: relative;
left: -50%;
}
</style>
<div id="chartArea" class="center">
<canvas id="pieArea" height="260" width="260"></canvas>
<div id="pieLegend"></div>
</div>
[script]
var datasets = [
{
value: 30,
color:"#aaf2fb",
lineColor: "#aaf2fb",
label:"最初の分類"
},
{
value : 50,
color : "#ffb6b9",
lineColor : "#ffb6b9",
label:"次の分類"
},
{
value : 120,
color : "#ffe361",
lineColor : "#ffe361",
label:"3番目の分類"
},
{
value : 170,
color : "#fbaa6e",
lineColor : "#fbaa6e",
label:"4番目の分類"
}

];
var options = {
legendTemplate : "<ul class=\"<%=name.toLowerCase()%>-legend\"><% for (var i=0; i<datasets.length; i++){%><li><span style=\"background-color:<%=datasets[i].lineColor%>\">&nbsp;&nbsp;&nbsp;</span><%if(datasets[i].label){%><%=datasets[i].label%><%}%></li><%}%></ul>"
};
var myPie = new Chart(document.getElementById("pieArea").getContext("2d")).Pie(datasets, options);
document.getElementById("pieLegend").innerHTML = myPie.generateLegend();
[/script]
<p> ほんの数年前はグラフ表示のライブラリは、高価だったり使いにくかったりと良いものが見当たらなかったのですが、現在は見た目も機能性も素晴らしいオープンソースのライブラリが多数登場してきています。</p>
<p> 私が最もWebの業務システムに適していると思うのはchart.jsと言うライブラリ。上のサンプルのとおり、デザイン性に優れています。グラフ表示の際のアニメーションも良好です。ライブラリ自体をサイトに配置するので、ライブラリのアップデートやサービス終了を気にすること無く運用できます。</p>
<p> 分析のためのグラフ描画は、どうしても大量のデータアクセスがついて回るので、設計には考慮が必要です。例えば、1年間の売上で商品種類毎の比率を見るには、1年間の全ての売上データにアクセスする必要があります。</p>
<p> データ量が多い場合や同時利用数が多い場合等、どうしても負荷が高い場合は、業務用のデータベースサーバーと分析用のデータベースサーバーを分離する方法が有効です。現状でデータ量が少なく、ビジネスの成長と合わせてデータ量が増えていくことが見込まれる場合は、論理的に別サーバーで動作するようにデータベースを設計しておき、当初は1台のサーバーに配置する方式をとります。</p>
[/inline]
<img src="http://www.cmpd.jp/sy/wp-content/uploads/2016/05/chart.png" alt="chart.jpサンプルグラフ" width="600" height="443" class="alignnone size-full wp-image-68" />


ASIOとWASAPIの比較

PCオーディオで利用するDAC(デジタルをアナログに変換する装置)が提供するインターフェイスには、WASAPIとASIOの2種類が存在します。このコラムではこの2つの特徴について解説します。

WASAPIとASIOはともにWindows PCからDAC(正確にはDACドライバ)を操作するためのAPI仕様(あるいはオーディオドライバの規格)です。再生プログラムがDACを操作するための「呼び出し手順などの規約」と表現するとわかりやすいかと思います。

【WASAPIとASIOの概要】

WASAPI(ワサピと呼びます)はMicrosoft社、ASIO(正式な発音は聞いたことがないのですが、私はアジオと呼んでいます)はスタインバーグ社のAPI仕様です。

WASAPIはWindowsを提供しているMicrosoft社らしく、中立の立ち位置でDACの機能をプログラムに提供する位置づけで設計されていると感じます。再生プログラムは自分でループしながらDACへのデータ出力を繰り返します。
対してASIOは、オーディオのハードウェアとソフトウェアを両方作っているスタインバーグ社ならではの設計で、私の個人的な感覚ではデバイス側(DAC側)の立ち位置で再生プログラムに機能を提供しているように思えます。
ASIOの再生は、最初にAPI側で高い優先順位のスレッドが起動され、そのスレッド上で再生プログラムが繰り返し呼び出される(コールバック)方式です。

【ビット深度の取り扱い】

再生プログラムがWASAPIを使う場合、再生開始時にDACの仕様を取得し、どの仕様を適用するかを選択します。
この仕様にはサンプリング周波数(44.1kHzとか96kHz等、1秒間にサンプリングする回数のことです)とビット深度(16bitや24bitなどの1回のサンプリングをどの程度の精度で記録するか)の指定が含まれます。

このビット深度はDACにより異なり、16,24,32bitの3種類に対応する機種もあれば、16bitや32bitなど1種のみに対応する機種も存在します。

対してASIOはサンプリング周波数は再生プログラムが指定しますが、ビット深度はDACの指定に従う方式です。つまり音源のビット深度に合わせてビット深度を指定することは行いません。一般的なDACは32bitを指定してくることが多いようです。

※参考:Pioneer社のU-05はASIOの設定画面でユーザーがビット深度を指定します。

【ビット深度についての詳しい解説】

ビット深度とは1回のサンプリング値をどのサイズの整数で扱うかを示すものです。24bitは24桁の2進数で、32bitは32桁の2進数のことを指します。

24bitで扱える数値は、10進数に換算すると-8,388,608 ~ 8,388,607の16,777,216段階で、32bitの場合は-2,147,483,648 ~ 2,147,483,647の4,294,967,296段階です。32bitは24bitのちょうど8bit分、つまり256倍の細かさを持ちます。

CDクオリティのビット深度は16bitですので、-32,768 ~ 32,767の65,536段階であり、ハイレゾ音源(PCM方式)のビット深度は大概が24bitです。これはCDの256倍の細かさである24bitで十分と考えられているのだと思います。
尚、音源が24bitのデータを32bitデータとして送出する時は、単にデータを256倍します。(別の表現では下位8bitを0にして、上位24bitに音源データをコピーします)

【DSDの再生方式】

DSDの再生については、ASIOにはDSDデータ専用のインターフェイス仕様があります。一方、WASAPIにはDSD専用のインターフェイス仕様は用意されていません。

WASAPIでは、24bitのPCMデータにDSDデータを載せるDoPという方式が使われます。これは、DSDデータだということをDACに示す8bitのマーカーと16bit分の実データを、普通のPCMの24bitデータのようにDACに送出する方式です。一部にはASIOのDoPを採用しているDACも存在します。

【WASAPIの共有モードと排他モード】

WASAPIは共有モードと排他モードという2種類のモードが存在します。共有モードはWindowsのミキサーを使う実装で、排他モードは1つの再生ソフトがDACを排他的に使用する実装です。Windowsは音楽再生中に警告音を鳴らすなど、複数の音を混ぜるミキサー機能があり、これが共有モードの正体です。PCMで音を混ぜるには、サンプリングレートやビット深度を揃えてから演算する必要があるので、このときにビットロスが生じることがあります。つまり音質は悪くなる方向です。

良い音を追求するオーディオにおいては、WASAPIは排他モードで使用することになります。

【結局どちらが優れているのか】

DACはWASAPIとASIOのどちらかに対応するものと、両方に対応するものがあります。この2つの方式に絶対的な優劣はありません。使用するDACが両方に対応している場合、どちらが好ましいかはメーカーの推奨を確認するか、実際に視聴してどちらを使うのかを決めることになります。

DSDを再生するときにWASAPIはDoPだから1.5倍のデータ転送が必要で音質的に不利であり、ASIOが優秀であるとの話を聞くことがあります。これはある意味では正しいのですが、音質については必ずしもそうではないと考えるのが自然です。ちなみにPCMはASIOはほとんどのDACで32bit固定であり、24bitだけを転送する場合に比べて1.33倍のデータ転送が必要ということになっています。(これも音質の絶対的な優劣を決める要素ではありません)

[PR] 先日リリースしたハイレゾに対応した再生ソフトHYSOLIDはスマホアプリで音源とDACの両方のビット深度を確認できます。

→ ハイレゾ再生ソフト、HYSOLIDのサイト


このコラムでは開発したアプリを社内(組織内)に配布する方法を説明します。

【iOSアプリの社内配布にはiOS Developer Programの参加が必要】

App Storeを経由せずにiPhone、iPadアプリ(以下iOSアプリと表記します。)を実機で動作させるためには、Apple社のデベロッパープログラムに参加する必要があります。このプログラムに参加せずにアプリを実機で動作させることは、電子的にできない仕掛けとなっているのです。

このデベロッパープログラムはいくつかの種類があるのですが、ちょうどこの用途のために「iOS Developer Enterprise Program」が用意されていますので、通常はこのプログラムに参加します。費用は年間で37,800円(税別)(2015年4月3日現在)で1年毎に更新が必要です。

このプログラムはアプリを利用する企業が参加する必要があります。アプリの開発を私たちコンポーネントデザインのようなアプリ開発会社に発注する場合でも個別の参加が必要です。なおこのプログラムは社内に配布するプログラムが複数の場合でも、1つだけで大丈夫です。

 

【iOSアプリの配布方法】

最も簡単な方法は配布用のWebサーバーを用意することです。OTA配信(Over The Air)と呼ばれる方法で、具体的には次の4つを用意してサーバーに配置します。サーバーはLinuxでもWindows Serverでも大丈夫ですが、以下で紹介する2番目のplistは、SSLでのアクセスが必須とされていますので、サーバー証明書の導入が必要です。

1.インストールをガイドするためのhtml(Webページ)

 通常のWebページです。インストールボタンを配置します。このボタンが押されたときにhtmlのAタグで2のplistを参照するようにhtmlを記述します。

2.plist

 アプリのモジュールの場所や、インストール中に表示するアイコンの場所などを記録したxmlファイルです。決まった書式に従って記述します。このファイルにはSSLでアクセスする必要があります。

3.ipaファイル

 アプリの実行モジュールです。

4.アイコン

 インストール中にデバイスに表示するアイコンです。インストール中のアイコン表示が白アイコンでよければ配置を省略できます。

上記が用意できたら、iPhoneやiPadの標準ブラウザのSafariから上記1のWebページにアクセスし、インストールボタンを押すとアプリのインストールあるいは更新が行えます。インストールは上記のサーバーへのアクセスだけではなく、インターネットへのアクセスが必要ですので、インターネットへのアクセスを制限したネットワーク環境を構築している場合は注意して下さい。

 

【iOSアプリは毎年更新が必要】

社内配布用のアプリにはプロビジョニングプロファイルというアプリの配布元などの素性が記録されたデータが内蔵されており、これには有効期限があります。有効期限が切れたアプリは起動することができないため、アプリは年に1回のペースで更新する必要があります。このアプリの更新とiOS Developer Enterprise Progamの契約更新タイミングを一致させる必要はありません。

 

【Androidのアプリ配布は簡単】

Androidアプリの配布は簡単です。特段の仕掛けを用意することなく、完成したアプリの実行モジュール(apkファイル)を実機に配布できます。具体的な方法はいくつかありますが、最も簡単なのはメールの添付ファイルを利用する方法です。PCからAndroidで利用しているgmailアドレス充てにメールの添付ファイルでモジュールを送り、Androidに標準でインストールされているgmailアプリで添付ファイルを開くのです。アプリの有効期限もありません。

 


新たにスマホアプリを開発するときに、対応OSの範囲をどうすべきかをまとめました。

5D3_3969s.JPG

 

【iPhoneアプリはiOS 6~8のサポートが現実的】

ストアにアプリを公開する場合は、iPhoneもAndroidもまず最新のOSをサポートし、無理の無い範囲で古いOSもサポートすることが基本となります。

iPhoneアプリの場合、開発ツールXcodeに配布ターゲットの設定があり、ここにアプリがサポートする最も古いOSのバージョンを指定します。このコラムを書いている時点の最新のXCode 6.2では配布ターゲットにiOS6.0~8.2が選択できます。

iOS6は2012年9月リリースなのでiOS6以降だとサポート範囲が狭いように感じますが、少なくともApp Storeにアクセスするデバイスの99%以上はiOS6以上になっているようですのでiOS6以上がサポートできれば十分と考えることになります。

iOS 6はiPhoneもiPadも一番古い機種を除き全ての機種にインストールできます。(具体的にはiPhone 3GS以降、iPad2以降)

もちろん古い開発ツールを利用すれば古いOSに対応するアプリが作成できますが、最新OSへの対応は出来ないため、アプリを2つにする必要があり、App Storeにアプリを申請するには、最新OS(時期によっては1つ前のOSも可)に対応している必要があるので、この方法は現実的ではありません。

【Androidは古いOSに対応可能。機能とサポート範囲のバランスを考えて選択】

Androidアプリの場合も開発ツールにminSdkVersionという設定があり、アプリがサポートする最も古いOSのバージョンを指定できます。Androidは新しいOSのアップデートが提供されない機種が多く、古いOSを使うユーザーが残りやすいのですが、古いOSで新しい機能が利用できるサポートライブラリが提供されており、少々の制約はありますが、アプリが古いOSに対応しやすい状況です。

以下はアプリがサポートするOSバージョンの代表的な例です。

 ・v8(Android 2.2)以上(約100%)

 ・v9(Android 2.3)以上(約99.5%)

 ・v14(Android 4.0)以上(約90.4%)

 ※カッコ内のパーセント表示は、Google Playストアにアクセスするデバイスのサポート割合(本コラム執筆時点。開発ツールAndroid Studioの表示より転記)です。V8(Version 2.2)以上をサポートすると、Google Playストアにアクセスするほぼ100%のデバイスをサポートできることになり、V9(Version 2.3)以上をサポートすると99.5%、V14(Version 4.0)以上では90.4%のデバイスをサポートできます。

対応バージョンは、アプリの目的に応じて機能とサポート割合のバランスを考えて決定します。最近のOSにすればするほど開発時に新機能が扱いやすく、その代わりにアプリを利用できないデバイスが増えていくのです。

私たちの提供しているスマホがポイントカードになるアプリ(Cardfeel)は、機能の拡充よりも多くの機種で動くことが求められると判断し、V8(Android 2.2)以上を選択しています。

最近リリースされるアプリではV14(Android 4.0)以上を選択することが増えてきているようです。

【企業内でアプリを配布する場合】

企業内(In house)のアプリを開発する場合は、App Storeの制約はないので、iPhoneアプリであっても対応OSを自由に決めることができます。

ただしサポート範囲を広げれば広げるほど、使える機能(API)は限定されるうえに、開発コスト(特にテストの作業規模)が増えるので、できる限り狭い範囲にするのが通例です。OSをアップグレードできない古いデバイスを利用する場合を除き、できるだけOSのバージョンを統一することでコストを節約できます。


サイトをリニューアルするとき、どのような手法をとっているでしょうか。

何も対処せずにWebページのURLが変更されると、せっかくGoogleやYahooなどの検索エンジンの登録やユーザーにブックマークされた内容が無駄になってしまいます。

そんなときサーバーに設定すべきなのが、301リダイレクトです。301リダイレクトとは、RFCで定義されたHTTPステータスコードの1つで"Moved Permanently"、つまりWebページの永続的な移動を意味します。

301.png

301リダイレクトは、サーバーがブラウザに返すステータスです。ブラウザはサーバーから301リダイレクトの結果を受け取ると、自動的にその結果に含まれるURLへアクセスします。

GoogleやYahooの検索エンジンも同じ動きをするようです。保証されている訳ではありませんが、この仕掛けでSEO効果もほぼ引き継がれるはずです。実際にGoogleもURLの変更時は301リダイレクトの使用を勧めています。

設定は簡単です。サーバーでApacheを使っている場合は、ドキュメントルートに.htaccessのテキストファイルを配置します。.htaccessには、1ファイルの移転に対して1行ずつ記述します。例えば次のような具合です。

redirect 301 /cfplus/security/ http://www.cmpd.jp/apps/point.html

空白で区切られた3つめのワードが移転元のWebページ。http://ドメイン名/を除いたものを記述します。4つ目のワードが移転先のWebページ。ドメインは違ってもかまいません。

上記は実際に登録されています。次のリンクにアクセスしてみてください。すぐにブラウザのURL表示がwww.cmpd.jpのドメイン下のURLに書き換わることが確認できます。

http://www.componentdesign.co.jp/cfplus/security/

上記は見えているとおりのURLにアクセスするリンクですが、サーバーが301リダイレクトを返します。最終的にブラウザに表示されるURLはhttp://www.cmpd.jp/apps/point.htmlです。

ディレクトリを指定した場合は、その下の全てのディレクトリ・ファイルが移転扱いになります。移転先は.htaccessの上から下に向かってサーチが行われ、該当の行が見つかったところで決定扱いになりますので、ディレクトリ内で例外がある場合は例外を先に記述することで上手く機能します。

ドメインごと移転する場合で、同一サーバーに仮想ドメインが含まれる場合は注意が必要です。
例えば、弊社のwww.componentdesign.co.jpのドメインは、リニューアルに伴いwww.cmpd.jpに移転したのですが、このとき次のような設定を行うと、同一サーバーに含まれる仮想ドメインも移転した扱いになってしまいます。

redirect 301 / http://www.cmpd.jp/

これを防ぐには、RewriteCond、RewriteRuleを記述し、リクエストにドメインが指定されていることを条件に指定します。例えば次のように記述します。

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.componentdesign\.co\.jp$
RewriteRule ^$ http://www.cmpd.jp/ [R=301,L]

ホームページ等のサイトをリニューアルするときは是非この301リダイレクトを設定してください。ページ数が多いと作業は大変ですが、1ページあたりのSEO効果やユーザーのブックマークは長期間に渡って築いたものですので、設定すべき作業であることが理解できるかと思います。


iBeaconとはアップル社がiOS7から標準搭載したBluetooth Low Energy(BLE)を使用した位置情報サービスに該当する新しいテクノロジーです。ビーコンと呼ばれる電波を発信し続けるBLEモジュールを店舗等に配置することで、BLEモジュールに近づいたスマホアプリがこれを検知することができます。

iBeacon

写真 左:  モジュールからビーコン(電波)を発信
写真中央: アプリが起動されていなくても、スマホがビーコンを検知
写真 右: アプリにメッセージを表示し、効果的に訴求

※このサンプルはデモ用に用意したもので実際に動作します。デモをご希望の方はお気軽にご連絡ください。


 類似する技術で特殊な音を鳴らしておいて、これをアプリで検知する方法がありますが、この方法ではアプリをユーザーが起動する必要があったのに対し、iBeaconを使う場合は、アプリが起動していなくても、iOSがビーコンを検知してアプリを起動することができるので、来店客にプッシュ通知を送ったり、アプリ上で特定のメッセージを表示したりすることができます。


【アプリで場所を検知する方法の比較】

140406_02.png

 iBeaconは複数個のビーコンを使い分けることもできます。店舗毎、フロア毎、エリア毎など個別の番号(メジャー番号、マイナー番号)を設定したビーコンを配置し、アプリからその番号を識別することができます。BLEモジュールは安価なので多数のビーコン配置も現実的です。いくつかのビーコン検知をアプリ内に記録し、特定の条件になったらメッセージを表示する等の応用も可能です。


【応用例】

 このiBeacon、アイディア次第でいろいろ応用できそうです。少し考えるだけでもいろいろなパターンがあることに気づかれるかと思います。

 ・入り口付近のクーポン配布

 飲食店で一定の空席があるときだけビーコンをOnにすれば、その時だけ近くを通る会員にクーポンを送ることができます。

 ・スタンプラリー

 自動的にスタンプが押される。スタンプの場所をシークレットにすることも・・・

 ・商品情報表示

 エリア毎の取扱商品に合わせた商品情報を表示できます。


店舗の顧客対応の最たる目標は、得意客の獲得・維持といっても過言ではありません。店舗に収益をもたらす要は、新規客ではなく得意客であることは良く知られているとおりです。ところが、客数が多く顧客を特定しにくい小売業や飲食業では誰が得意客なのかを把握することは困難で、得意客を優遇する有効な手法を持っていないのが現実です。では、得意客を正しく認識し、優遇するにはどうすれば良いのでしょうか。このコラムでは航空会社の会員ランクプログラムを例に、顧客を優遇し得意客を獲得する手法を紹介します。

【個客を識別し、会員ランクを設定する】

 得意客を把握するためには、まず「個客」の識別が必要となりますが、店主が一人で対応しきれない規模の店舗では、何らかの会員システムを導入する必要があります。顧客に会員証を提示してもらうことで「個客」を識別するのです。とりわけポイントシステムは、顧客がポイントをためるために自ら会員証を提示するので、「個客」を上手に識別することができます。

 このポイントシステムを拡張し、一定期間の累計ポイントをシステムでチェックすることで、会員ランクプログラムの導入が可能になります。このとき「一定期間」は顧客が理解しやすいように月か暦年にすべきで、その期間内に顧客が得た累計ポイント数に応じてランクを自動設定する仕様が理想的です。

【秀逸な航空会社の会員ランクプログラム】

 多くの航空会社ではマイレージと呼ばれるポイントプログラムを採用しています。これは利用規模に応じて、無料の航空券や座席のアップグレード等をサービスするものです。このプログラムは得意客を優遇するものですが、特典を得るには一定の利用規模が必要なため、利用者は航空会社を1社に絞りこもうとするようになります。ただし、年に数回しか旅行しない顧客に対してはこれで効果的なのですが、1年間に数多く飛行機を利用する顧客は複数社のプログラムに参加しても効果を得られるので、得意客の囲い込みには至りません。

 そこで航空会社は会員ランクの考え方を導入することで、上得意客の囲い込みを図っています。JALなら「JMB FLY ONプログラム」、ANAなら「プレミアムメンバーサービス」と呼ばれる会員プログラムがそれに該当します。これらは会員ランクを獲得、維持することを主目的に旅行に行く人がいるほど、非常に良く出来た「会員ランクプログラム」です。

 航空会社の会員ランクプログラムは、どの会社も驚くほど事細かにルールが策定されており、多数の特徴があげられますが、参考にするべき特徴は次の4点です。

  1. 複数のランクを用意し、それぞれに魅力的な名前を付けること
  2. 顧客が喜ぶ会員特典を用意すること
  3. ルールと現在の状況を明示すること
  4. 基準を達成したら速やかに特典を提供すること

【1.複数のランクを用意し、それぞれに魅力的な名前を付けること】

 多くの航空会社には複数のランクが用意されています。これはランク獲得後に他社に浮気させないためでもあり、上客のレベルに応じたよりサービスを提供するためでもあります。ランク名にはゴールド、ダイヤモンドといった貴金属や宝石の名前が使われ、顧客にプレミアム感を感じてもらいように工夫されています。

【2.顧客が喜ぶ会員特典を用意すること】

 会員ランクの策定で最も重視されるのがこの会員特典です。航空会社では専用ラウンジの提供、特別なポイント付与率の提供、優先予約など通常では得られないサービスが用意されています。

 特典は会員が「優遇されている」と強く感じるかどうかが重要なファクターとなります。小売業なら特別な割引率、特別のセールへの招待、限定品の先行販売などが検討対象となりますし、すぐに売り切れてしまうレア商品や福袋などの取り置きなども人気のサービスになるかもしれません。飲食業ならお通しの無料ランクアップや、窓際席の予約、制限時間の延長、裏メニューの提供などが効果的と考えられます。

【3.ルールと現在の状況を明示すること】

 ランク獲得はルール化し、あとどれだけ利用すればランクアップやランクの維持ができるのかを、わかりやすく見える化すべきです。これにより、顧客はランクを獲得するために少々遠回りしてでもその店舗を選ぶようになります。

 わかりやすく示すことは重要な効果をもたらします。1つ例を挙げます。数年ほど前にコンピュータのディスプレイが付いたソフトダーツが流行したのをご存じでしょうか。ゲームに利用する道具が少々異なるものの、投げ方もルールも昔からのものと同じです。流行の理由はコンピュータによる点数の「見える化」でした。「数えればわかる」と「目に入ってくる」には雲泥の差があるのです。

【4.基準を達成したら速やかに特典を提供すること】

 会員ランクは獲得により会員が大きな満足感を得られることが大切です。一定の買い物をしたときに、しばらく先の翌年まで特典が得られない方法では、せっかくのランク獲得時の興奮が冷めてしまいますし、特典を待たせることによりストレスを感じさせてしまうリスクがあります。航空会社の例ではシステムの都合上、若干のタイムラグがあるのですが、各社のホームページでは顧客がランク獲得の条件を満たした後、早期に特典を提供することが目立つ箇所に明記されています。

 会員プログラムの策定にあたっては実質的なことより、顧客の心理面に配慮して顧客本位で組み立てる必要があるのです。


【ご参考: Cardfeelの会員ランク機能】

※ここからは弊社プロダクトのご紹介になりますので、興味がある方のみお読みください。

 弊社プロダクトのポイントシステムCardfeelでは、会員ランク機能を提供しています。この機能で上級会員を優遇して上得意客を獲得・維持する施策を実行可能です。

  • 会員が期間内に獲得した累計ポイントに応じて、最大5段階の会員ランクを自動設定します。
  • ポイントの累計期間は「1年間」か「1ヶ月間」のどちらかです。
  • 「ゴールド会員」、「ダイヤモンド会員」などのランク名と、必要ポイント数は自由に設定できます。
  • 期間内に必要ポイントを獲得したタイミングで会員にランクが付与されます。ランクは翌期末までキープされます。
  • 会員の画面には次ランク獲得のために、期限と必要ポイント数が表示され、会員の購買意欲を高めることが出来るようになっています。
  • 性別、年齢、居住都道府県、会員ランクを指定したプッシュ通知が行えます。これにより、上級会員限定の特別セールのお知らせをプッシュ通知できます。このときの送信条件に20代女性などの属性を絡めることも可能です。

本機能の対象プロダクト

 ・Cardfeel スタンダードプラン,エンタープライズプラン
  共通のアプリを利用した店舗向けのプランです。

 ・Cardfeel 公式アプリプラン
  ブランドやチェーン店向けの専用アプリを作成・提供するプランです。

 ・Cardfeel+
  Cardfeel公式アプリプランのアプリをベースにシステムをカスタマイズして提供します。


 FeliCaはActiveXコントロールを利用すれば、Webシステムで扱うことが出来ます。このコラムではその概要と実装方式をご紹介します。

felica.jpg

【FeliCaについて】
 FeliCaとはJRのSuicaやおサイフケータイ、nanacoなどで採用されている「非接触ICカード技術方式」でソニーの登録商標です。リーダーにかざすだけで読み書きができることから、広い範囲で応用されています。

 カードにはIDmと呼ばれる16桁の数字によるIDがあり、同じ番号が流通しないように管理されています。このIDmはPaSoRi(パソリ)と呼ばれる3,000円程度のリーダーを通じてPCで読み出すことができます。

 FeliCaはいろいろな分野で応用できます。例をいくつか挙げます。
 1)Webシステムの認証(カードをかざすとログイン)
 2)入退館の管理(カードで入館や退館を登録)
 3)ポイントシステム(カードにポイントが貯まる)
 4)会員システム(カードで会員であることを確認)

【セキュリティについて】
 IDmは他のソフトでも簡単に読み出せますので、セキュリティは目に見えるバーコードを読み込むときと同程度と考えておくべきです。一定以上のセキュリティが必要な場合は、他の方式と組み合わせるなどの方法をとることになります。簡単な例は以下のとおりです。
 1)初回はユーザーIDとパスワードでログインする。
 2)ログイン後にFeliCaから読み出したIDmをサーバーに登録し、シークレットキーをサーバーで発行する。IDmとシークレットキーはサーバーで管理する。
 3)シークレットキーはブラウザのクッキーに保存する。
 4)次回以降のログインでは、FeliCaをかざすことをトリガーに、読み出したIDmとクッキーのシークレットキーをサーバーに送信して認証を行う。

【FeliCaをWebシステムで扱う方法】
 システムの管理の事を考えると、FeliCaもWebシステムで扱えると便利です。ActiveXコントロールを開発することで、これを実現できます。

 実行時に必要な物
 1)リーダー
  SONY 非接触ICカードリーダー/ライター PaSoRi(パソリ) USB対応 RC-S380(3,000円程度)

 2)ソフトウェア開発キットに含まれるドライバ(無償)
  SONY SDK for NFC Starter Kit Ver.2.0「ICS-D010/20J」
  こちらはソニーのサイトからダウンロードできます。

 使い方のイメージは以下のとおりです。
 1)リーダーのPaSoRi(パソリ)をPCに接続します。
 2)あらかじめドライバをインストールしておきます。
 3)Webシステムを利用します。初めて当該のActiveXコントロールが含まれるWebページにアクセスした時に、そのActiveXコントロールがWebサイトからインストールされます。

【HTMLとJavaScript】
 ActiveXコントロールはHTML上に配置したJavaScriptから行います。htmlのコードのサンプルは以下のとおりです。シンプルで簡単です。

<OBJECT ID="FelicaCom" CLASSID="CLSID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" CODEBASE="http://xxx.xxx.com/feactx.dll#version=1,0,0,0"></OBJECT>

<script language="javascript" type="text/javascript">
  function StartScan() {
    FelicaCom.StartScan(); // FeliCaのスキャンを開始するために、ActiveXのメソッドStartScan()を呼び出します。
  }
</script>

<script language="javascript" type="text/javascript" for="FelicaCom" event="FindIDm(idm)">
  // IDmが読み込めたときのイベント処理(ActiveXから呼び出されます。)

  // ここにIDmを使った処理を記述します。

  alert(idm); // 例えばこの1行でIDmをアラート表示できます。


</script>


【ActiveXコントロール】
 ActiveXコントロールを開発するために利用する開発環境、言語はVisual Studio、C++です。ライブラリはMFCではなく、ATLを利用することでコンパクトなモジュールを作成できます。以下に概要だけ説明します。専門的な内容になりますので、興味がある方のみお読みください。

 ActiveXコントロールは非表示のコントロールとし、イベントを送出するために接続ポイントを実装します。接続ポイントはイベントを送出するために必要です。また、スキャンを開始するためのStartScanメソッドを実装します。このメソッドではスキャンのために別スレッドを起動します。イベントの送出は別スレッドから行いますので、この接続ポイントを別スレッドに引き渡す必要があります。スレッド間の接続ポイントの引き渡しはマーシャリングが必要です。渡す側でCoMarshalInterThreadInterfaceInStreamを使い、受け取り側でCoGetInterfaceAndReleaseStreamを使います。

 別スレッドではFeliCaポートを監視します。監視はループ処理内でFeliCaポートのポーリングを繰り返すことで実現します。このポーリングには数百ミリ秒程度のスリープ処理を入れておくべきです。IDmの読み取りに成功したらイベントの送出を行います。イベントの送出コードは、ATLが自動生成してくれるFire_xxxxメソッドを参考に記述します。

 FeliCaのアクセスは、FeliCaの開発キットのサンプル通りにinitialize_library、open_reader_writer_autoを呼び出し、polling_and_get_card_informationで読み出すことができます。IDmが読み取れない時と、同じIDmが連続して読み出される時は通知をせずに、新たなIDmを読み取れたときのみ、イベントの送出を行うようにします。

 別スレッドを破棄するタイミングはATLが生成したFinalReleaseメソッドが適切です。このメソッドが呼ばれたタイミングで別スレッドが終了時の処理を行うようにします。


 業務システムはシステムのライフサイクルを考慮した全てのコスト、いわゆるTCO(総所有コスト)が重要とされます。TCOには、初期費用やランニング費用といった、わかりやすいコストのほかに、隠れコストとして「将来の変更コスト」が含まれます。

 業務システムは業務ルールの変更や、使い勝手の見直しの必要性などから、長期間に渡り、変更が発生するものです。そのためこの「変更コスト」は総所有コストを大きく左右するのです。

 この将来の変更コストを抑えるにはどうしたら良いのでしょうか。

【データベース構造が変更容易性を左右する】

 業務システムは一部の例外を除き、リレーショナルデータベース(以下データベースと表記します)にデータを保存します。データベースがシステムの中心に位置する構造です。画面から入力したデータはデータベースに保存しますし、画面に表示したり帳票に印字するデータはデータベースから取り出したデータ。何か情報を検索するときの操作対象もデータベースです。

 そのため、データベース構造の変更はシステムの広い範囲に影響します。データベース構造に無理があると、データベースにアクセスする各種のプログラムにも無理が及ぶのです。

 逆に将来の変更コストを抑えるためには、データベース構造が業務ルールに対して、自然な構造になるように設計すればよいことになります。例えば、「店舗」と「販売員」の関係が1:n(販売員は1つの店舗に所属)ではなく、n:m(販売員は複数の店舗に勤務)であるなら、データベースの「店舗」と「販売員」の関係も同じように設計するのです。

【データベース設計をレビューしよう】

 業務システムの基本設計では、画面や帳票は「業務のプロ」によって細かくレビューされることが多いのですが、データベース設計は技術的な専門性が高いことからレビューの対象外にされがちです。

 しかし、暗黙の業務ルールや将来の業務ルールの変更見込みについては、業務のプロでないと理解が難しいものです。私はデータベース設計も、業務のプロの方がレビューすることを推奨します。

 データベース設計に対して、将来の変更コストを抑えるために確認すべき事項は次の2点です。

 ・データがどのような種類に分類して保存されるか。(例えると販売システムでは、店舗、販売員、商品などが該当します。)

 ・保存されるデータの関連はどうなっているか。(先ほどの「店舗と販売員はn:m」などの関連性を確認してください。)

 如何でしょうか。技術的な事項は解らなくてもかまいません。業務ルールに対して、データベース構造の想定が正しいかどうかを、ベンダーの説明を聞いたり質問しながら確認すればよいのです。この確認作業で将来の変更コストの肥大化を避ける事が出来ます。



お問い合わせ

システムやアプリの開発のご相談、サービスに関するご質問など、どのようなことでもお気軽にお問い合わせください。