アクセス管理減量とAPIについて学んだこと

このエントリーをはてなブックマークに追加
Bookmark this on Delicious
Bookmark this on Yahoo Bookmark
Bookmark this on BuzzURL
Newsing it!
Choix it!
Bookmark this on Livedoor Clip

年を重ねて、体型の維持は終わりなき人生の戦いの1つなのだと思うようになりました。 ここ何年かは、健康的な体型からあまり健康的ではない体型の間を行ったり来たりしながら、理想体型をわずかに外れた状態を何とか維持しています。数か月前に、体重を数キロ落とそうと(再び)決意するに至り、生活を(これも再び)見直し始めました。 ただ、この過程で、APIについて学ぶことになろうとは思ってもいませんでした。

 

減量の方法は人それぞれですが、私はいつも計測可能で合理的なやり方を選んできました。摂取カロリを計算し、消費カロリを引き算して管理するのです。このやり方の良い点は、自分が何を摂取し、何をしているのか考えさせられるところです。一方、非常に大きな難点は、すべてのデータを追跡し続けるのは単調でうんざりする作業なので、「もう止めてしまおう」と思いがちなことです。

 

もちろん、今では何をするにもアプリがあるわけで、私も食事内容やそのカロリを記録するためのツールを使い始めました。この手のツールで1つ問題なのは、バーコード・スキャナやクラウド (crowd) ベースのデータなどを利用して摂取した食品を記録するのは簡単ながら、運動やカロリ消費を記録するのは全て手作業になってしまうということです。私のようなユーザは日々のカロリ消費を過大または過少に見積もってしまうため、目標の体重に落とすことが難しくなってしまいます。

 

幸い、身体活動をモニタリングするデバイスは存在し、その価格も入手しやすい設定になっています。 1日に歩いた歩数、上った階段数、活動量を集計するウェアラブル・デバイスは、大量の個人データを提供してくれます。正直なところ、こうしたデバイスはGoogle Glassと同類の、新しいもの好きが自らの尊厳を犠牲にしてまで公の場で身につけるクールなテクノロジだと思っていたのですが、使っていたカロリ計算アプリをウェアラブル・フィットネス・デバイスに接続することが可能だと気づいたとき、新たに見えてくるものがありました。そこで、早速デバイスを購入したのです。

 

食事を記録するアプリケーションと活動を記録するデバイスを接続することにより、1日の予定摂取カロリをより正確に把握できるようになりました。システム同士は非常にうまく統合され、あと何カロリ摂取できるのか分かるとともに ゲーミフィケーション機能もあるので、体を動かすとともに食事量を減らす意欲を高めてくれました。

 

結局、「トリガ、アラート、フィードバック」というサイクルで行動の条件付けをする方法が私には合っていたようで、数キロの減量に成功しました。 1カ月ほど前に飛行機の中にデバイスを置き忘れてしまった私の体型は急速に梨型に戻りつつありますが、それはまた別の話です。 「私の体験から何を学ぶことができるのか」という話の方がよほど面白いでしょう。

 

1. APIは、様々なプラットフォームへのアクセスを拡大する素晴らしい方法
APIの作成を考えるとき、通常、モバイル・デバイスやソーシャル・プラットフォームへの拡張を考えます。しかし、対象ユーザベースが積極的に使用する、ニッチで従来とは異なるプラットフォームへの拡張方法も考えるべきです。もし、私が購入したウェアラブル・デバイスと既に使用していたカロリ計算アプリケーションとの連携ができなかったら、そもそもデバイスを購入することすら考えなかったでしょう。 しかし、APIベースでの統合のおかげで、自分がデバイスを使用しているところをイメージでき、購入につながったのです。

 

2. 統合は機能ではなくコア要件になりつつある
ウェアラブル・デバイスのウェブサイトにあるフォーラムを覗いていて、他のエクササイズ・プラットフォームとの統合に関する投稿の多さに気付きました。このユーザベースにとって、お気に入りのランニング記録ツール、カロリ計算ツール、フィットネス・ゲーミフィケーションツールとの統合は、「あれば便利」なものではなく、「最低限あるべき」ものなのです。 エンドユーザは、自分が選択したプラットフォームを各製品メーカがサポートするよう求める傾向を強め、自由に選びたいと思っているようです。 つまり、普及度が低い記録ツールやマーケットシェアが低いモバイルフォンOSを押しつけられたくないのです。

 

3. 競合との統合も利益をもたらす
先ほどは書きませんでしたが、購入したデバイスにはカロリ消費のトラッキング機能が付いていました。 実は、この製品の場合、フィットネス総合管理プログラムの一環としてメーカが提供しているフィットネス・ポータルの使用料が収益源の1つとなっています。他のフィットネス記録ツールと統合されているということは、このデバイスメーカの売上げを一部犠牲にする可能性があるということです。 しかし、私のような顧客を引き付けることから得られる全体的な収益メリットの方が、ユーザがポータルを使用しないことによる収益の喪失より大きいと言えるでしょう。競合製品との統合にリスクはありますが、賢くリスクを取れば十分な効果を期待できます。

 

モノのインターネット (IoT:Internet of Things) への関心が高まるにつれ、デバイスからプラットフォームへの興味深い統合事例が増えてゆくものと期待しています。企業は、この新しい世界に拡張してゆくための一貫したビジネス戦略を立てる必要があります。そこでは、APIが裏方として重要な役割を果たすでしょう。

 

それから、もし私を見かけることがありましたら、ぜひ「最近はすっきりしていますね」とお声掛けください。


原文:http://www.layer7tech.com/blogs/index.php/how-i-lost-weight-learned-about-apis/

 

Ronnie Mitraについて

Ronnie Mitraは、ヨーロッパ全土でLayer 7のAPIアーキテクチャおよびデザイン・プラクティスを指揮するエンタープライズ開発/統合の専門家で、大きく広がるAPIの可能性を活用できるよう様々な企業を支援しています。Layer 7に入社する前はIBMに勤務し、WebSphere接続製品に関する活動をグローバルに指揮していました。
タグ: , , ,
ronnie | Permalink | Trackback (0)

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>