Kindle Unlimited, 購入履歴をtodoアイテムに登録したいんだけど...

電子書籍の読み放題サービス、Kindle Unlimitedが始まったというので、早速利用してみた。

幸運にも、読みたいと思う本も少なからずあったので、ちゃんと読む時間が確保できるのであれば、毎月980円払ってもいいかな、といったサービスである。

問題なのはこの「ちゃんと読む時間が確保」というところで、時間確保のために、タスク管理系のサービス(iPhone標準のリマインダーとか。私の場合はTodoistというサービスを使っています)を使っていることもあり、「読み放題で読む」ボタンをクリックした際に(購入時と同様)メールが飛んでくるのであれば、そこをトリガーにやることリスト(とうまくいけば読了時間の見積もり)を自動的に登録させよう、などと考えておりました。

が、「読み放題で読む」ボタンを押してもメールが来たりはしないのでした(費用が発生しているわけではないから)。もちろん、同時並行で読める本は10冊までで、その10冊がどの本なのかとか、読んだ本は削除して別の本をダウンロードできるようにする、というのはAmazon.co.jp上の「コンテンツと端末の管理」画面からできるのですが、長い書名は後ろの方が省略されて見えないし(雑誌なんかだと肝心の何月号かがわからない)、そもそも手作業で書名コピー、タスクリスト作成ってのは全くイケていない。

確か、Kindle Oasisを出した際に、読書体験(Experience)にとことんこだわって、デザイン思考を使って作り上げた(だから一見してこれまでと違って「読みにくそう」な印象があったとしても、実際はより優れた体験を提供できるのである)、みたいな言い方がされていたかと思うが、是非、before reading, purchase, reading and purchase anotherのすべてのフェーズでよりキモチ良いExperienceをアマゾンさんには提供して欲しいと思う次第。

そもそも購入マネージメントとか利用管理とかって(Kindleに限らず)Amazonが握りやすいところだから、Amazon自体が「利用体験」のマネジメントを提供するとか、メッセージ系のサービス(LINEとか)が会話の中からやることリストを作ってくれるってのは嬉しい＋お金払って良いサービスになりそうなんですけどね(LINEだったら、Amazonの発送情報なんかも受け取れるし、他のサービスとの接続性も高いから)。

共感の重要性、そして難しさ、最後に楽しさ

お客様の悩みを先に見抜く

誕生日にプレゼントを送る際に、あらかじめ何が欲しいのかを誰か親しい人に聞き出してもらい、誕生日当日、用意しておいたプレゼントをサプライズで贈る。「それって、うまく行くのかも知れないけれど、聞き出している時点で負けじゃない？」

どの工場にもさまざまな悩みがあります。何が必要かを聞くのではなく、その悩みを先に見抜き、何があればよいかを提案する。

安川電機の産業用ロボット、モートマン(MOTOMAN)が世界ブランドになったのには、同社の持つ高い技術力があったのはもちろんでしょうが、そんな利島イズムが社内に浸透していたという背景もあるのでしょう(【九州の礎を築いた群像 安川電機編２】ロボット（中）「ホンダに納入できれば世界一が見える！」 利島イズムで新鋭ロボを続々開発)。

実際には欲しいものを聞き出すなんてできない

私がデザイン思考をビジネスにおいて活用しだしたのは、2007~08頃だったかと思います。テクノロジー製品をお客様に売り歩く中で、お客様に入っていきやすいのが、エンジニア(お客様) to エンジニア(自分) の間で波長が合う、共感ができる場合です。「こんな技術があるんです」「面白そうだね」「こんなことができるんです」「へぇ～、じゃあ、もしかしてこんなこともできるの？」「ほら、こんな感じでできるんですよ」といった会話ができるお客様が相手の場合です。

その一方で、波長が合わないわけではないのに、共感がしづらいケースもあります。「こんな技術があるんです」「面白そうだね」「こんなことができるんです」「いや欲しいのはそういうのじゃない。御社の技術はいいと思うんだ。僕が考えてきたことにはまりそうな気がする。売りたいんでしょう？何ができるのか、ちゃんと買いたくなるような提案をしてよ」。関心は持っていただけている。提案に対してNoを言ってくれても、これが欲しいと言ってくれるわけではない。

実は当の本人もわかっちゃいないから聞き出せない

そんなときに必要なのは、お客様自身を観察し、会話の中から思いの発露したキーワードや表情を捉える力であったり、お客様との間の会話を整理して、提示する力であったり(そうそう、俺が考えていたのはこういうことなんだよ)、お客様のお客様を観察する中での気づく力だったりするのでしょう。お客様自身がいじわるで自分が何が欲しいのかを教えてくれないのではなく、そこを考えること自体がお客様のミッションだという場合もあります。コンサルにいくらいくら払ったけど、結局大したことはなかったな、というのが往々にしてこのケース。

私から言えることは、「まずは試してから考えてみましょう」ということです。提案なりその中のアイデアがいい・悪いと評価するのではなく、プロトタイプを作り、使った上で、(お客様の考えている、ことによると言語化されていない、明確になっていない課題に対して)何が良いのか・悪いのかを洗い出してみるところから始めましょう、ということです。

筋のいいアイデアは課題解決に留まらない、オーバーアチーブ力がある

私には１歳３か月の息子がいるのですが、これくらいの年齢だと真理を語って、正しい行動に促すというのはまだまだ無理です。「かまれると痛いから噛むのを止めなさい」とか「後でおなかが痛くなるから、食事の前には手を洗いなさい」と言っても、前段が後段を促進するというのは100%無理です(言語的な理解力の不足ももちろんありますが)。

南アフリカで「子供たちに手を洗ってもらう」という課題を達成するために、石鹸の中におもちゃを入れておくというHOPE SOAPは、決して子供たちに衛生の重要性を教えているわけではありません。しかし、理解より実践が喫緊の問題です。子供たちはHOPE SOAPのおかげでおもちゃを手に入れようと、進んで手洗いするようになりました。それどころか、頼みもしないのに頭からつま先まで全身をきれいに洗ってくれるようになりました。そのほうがおもちゃがより早く手に入るからです。石鹸を使うことで自分の人生がどう変わるのか、どこかのタイミングで何かの理由で気づくのでしょう。そちらも追いかけてみる価値がありそうです。

HOPE SOAP - WHO Y&R (Cape town) - YouTube

思うに、そもそもの課題設定は「手を洗ってもらうこと」ではなく「病気の撲滅」だったり「予防医学による医療費の抑制」といったあたりが真の、ただし明確になっていない課題だったのでしょう。例えば、同様のアプローチで、交通ルールを守ってもらうために、事故の悲惨さというホラーストーリーに頼らない、別のアプローチが見つかるかもしれませんね。真の課題に迫ることもできそうです。

ちなみにウチの息子は手洗いが大好きです。蛇口のハンドルの上下が出る・出ない、左右が暑い・冷たいに対応しており、自分の欲しい「気持ちよさ」が自分の手で自由にコントロールできるのが手洗い大好きの理由のようです。それでは。

cloudBitを使ってデータを貯める・通知を飛ばす - その1 はじめに

littleBitsという(私と同じ or それ以上の世代ならご存知の)電子ブロックのLEGOブロック版のようなガジェットがある。ブロックを組み合わせることにより、部品をハンダ付けしたり、ブレッドボード上に配置することなく簡単に電気回路を組んだり、(本当の強みはここなのだが)気に入らなければ、簡単に部品の組み換えができる優れ物だ。

littlebits.cc

 このlittleBitsの各部品のことをbitと呼ぶ。bitは種別ごとに色分けされており、青はPower(電源)、赤はInput(センサやボタン等の入力系)、オレンジはWire(延長コード的な単純接続から、2入力を1入力にまとめる論理演算(ミックス)系など)、緑はOutput(光や音、振動、数字出力などの出力系)がある。

cloudBitはオレンジ色のWireに属し、赤bitの入力データをクラウドに送信したり、クラウドからイベントが上がると、データを受け取って次のbit(一般的には緑bit)に送ったりすることができる。

ただし、cloudBitのAPIのうち、cloudBit「から」データを受け取るAPIはsubscriptionという仕組みを取っている。ここでいうSubscriptionとは、何らかのデータが発生した時の呼び出し先URLをあらかじめlittleBits社のサーバに登録しておくと、実際にデータが発生した時に、cloudBitは(cloudBit内に埋め込まれたデータ送信先である)littleBits社のサーバにデータを送信し、littleBits社のサーバはあらかじめ登録されたURLをPOSTメソッドで呼び出す(その際、データやcloudBitに関わる情報、日時などはJSONフォーマットで送られる)という仕組みを取っている。

これは、一見すると回りくどく見えるかも知れないが、設定変更等により、データ受取先が変更になる場合であっても、cloudBit中の設定情報を変更することなく、littleBits社クラウド側の設定情報を変更すれば事足りる。タイムラグもまぁ、気にするほどでもなかろう。

したがって、cloudBIt APIを利用するためには、自分の(Web)アプリケーションは、外部から(=littleBits社クラウドから)アクセス可能な場所に存在している必要がある。ファイアーウォールの内側のPCでアプリケーションを動かしても、littleBits社のサーバからアクセスできず、したがって、何の通知を受け取ることもできない。

そうであれば、自分のアプリケーションはAzure上で動作させましょうか？ Amazon EC2上で動作させましょうか？(そうすれば外部からアクセス可能な位置にアプリケーションを設置、動作可能)ということにもなろう。タダでIP reachableな場所にアプリ構築可能なアプリケーションサーバ、かつ(インメモリにデータを置き、高速な)SQLデータベースサーバを備えるSAP HANA Cloud Platform(HCP - Developer Licenseは無料)が私のお勧めである。

HCPを使ったIoTサンプルとしては、すでにRaspberry Piと連携した場合やTesselと連携した場合のサンプルコードがあるのだが、littleBits連携のコードはなさそうなのと、HCP連携にかぎらず、cloudBitを使った良さ気なサンプルコードは日本語・英語問わずそれほど見ないので、私の記事が少しでもお役立ちできればと考えている(まぁ、これとは別にラズパイやTesselで作ったアプリを日本語でご紹介したい気持ちは持ってます。littleBitsを含め、それぞれが魅力あるプラットフォームなので)。

scn.sap.com

ちなみに筆者は2015年6月現在、SAP社のナカの人ではあるものの、HANAやHCPのナカの人ではない。普段はデザイン思考を使ったワークショップを社内外で企画、ファシリテートしているのだが、もともとはコテコテのエンジニアなので、アイデア出しに留まらずクイックなプロトタイピング(ソフト＋ハード)ラヴだったりする。

www.sapjp.com

前振りはこの辺りにして、その２からサンプルコードを交えて本題に入っていこう。