SyntaxHighlighter

2016/10/02

Garmin Forerunner 235のGPS受信感度を検証する

こりゃもうスマホGPSには頼れませんな

Garmin Forerunneer 235
出典:Garmin社プレスキットより


Garmin Forerunner 235を入手してから5日ほど、使用してのランニングを3回ほどやってみて、ランニングライフがずいぶん変わりました。端的に言うと、


  • いちいちスマホを取り出してアンロックせずともリアルタイムでペースが分かり、ペース維持や変更がしやすい
  • 走破距離が常時分かるので、今自分がどのくらいの場所に居るのか分かり、コースの変更など柔軟に対応できる
  • GPS信号の受信感度が高く、データが信頼できる


というあたり。特に3番目が大きい。


私が普段使っているGalaxy S6 Edgeは、いわゆる衛星を使う通常のGPSに加え、Wi-FiやLTE/3Gなどのモバイルネットワークの信号を使って位置を特定する機能を持っています。

しかしながら、これらの機能は補助的なもの。GPS信号を受信できない時に「大まかに居場所を特定する」程度の機能しかなく、その精度はランニングで活用できるレベルのものではないようです。


実例を2つほど見てみます。



左:Garmin Forerunner 235 | 右:Samsung Galaxy S6 Edge
もうこれだけで一目瞭然ですな

こちら、私のランニングコースにある橋です。橋の長さは30メートルほどでしょうか。

この橋は山なりになっていて、クルマは普通に渡れるのですが、歩行者は一度橋の下をくぐり、進行方向とは逆に坂を上り、両車道に挟まれた中央部分を通って渡ります。

上記のトラッキングは、いずれも左上方向から右下方向に渡りました。左のForerunnerはきちんと「橋の下をくぐり、少し逆方向に上り、車道中央を渡り、さらに同じように歩道に戻る」ことがきちんと読み取れます。

一方で右のGalaxyは、見事にGPS信号をロスト。渡り終えても信号受信まで時間がかかっているのか、大まかにしか経路をトラックできていません。


どちらがより正確に走行距離を把握できるか…言うまでもありませんね。


もうひとつ、実例。

左:Garmin Forerunner 235 | 右:Samsung Galaxy S6 Edge

こちらは、高速道路(画像の左下から右上に伸びるグレーの道)の下をくぐるルートです。高速道路は片側3車線の6車線、道幅にして20メートルほどでしょうか。私は行きと帰り、両方同じ道を通っています。

左のGarminは完全に同じ道をきれいに表現。右のGalaxyは、右下の上空がクリアでGPS信号を適正に受信できるはずの環境でも、大まかな場所しか得られていません。



一目瞭然ですね。



もちろん、これをもってGalaxy S6のGPSはダメだ、と言い切るわけではありません。一般的にスマートフォンのGPSで、ここまで高い精度、高い受信感度が求められるケースはそう多くないでしょうし、コストとのバランスで考えれば充分ともいえるでしょう。

一方で、ランニングトラッキングの用途で考えると、Garminの方が何枚も上手。専用に設計されている強みはあるでしょうが、ここまでの差があるとなると購入の検討余地あり、といったところでしょうか。


GarminのGPS、さすがの一言です。


2016/09/25

ランナー向けGPS Watchを比較してみた

色々あるんだけどさ、どれが良いのよ?


2016年8月に発表されたGarmin Forerunner 35。$200で高感度GPS搭載のエントリーレベル機です。
カジュアルランナーには必要十分な機能がついているのではないでしょうか。
出典:Garmin社プレスリリースより


2016年3月から、ダイエット(と、フィットネストラッカーで遊ぶこと)を目的にランニングしているわけなんですが、どうも本格的に10マイル16kmとか走るようになると、どうしてもスマートフォンでアクティビティトラッキングすることに限界を感じてきていまして。


  • スマホのGPS信号受信感度って決して高くなく、ちょっとした木陰に入るとシグナルロストして走った距離がすぐ不正確になる
  • そもそもスマホを身に着けて走るとバッサバッサ揺れて邪魔
  • ペースとか、ゴールまでの距離とかを見る時わざわざ取り出してアンロックしてとか煩わしい


そんなわけで、スマートフォンをクルマや家に置いたままでトラッキングできる、GPSウォッチが欲しいな、と。


しかし、今まで持ったことがないカテゴリの商品なので、どう選んでいいのかわからない。基礎知識をつけるためにも色々調べて絞り込んでみました。


で、私の結論は、というと



先に結論を書いてしまうと、2016年9月現在、私にとってベストの選択は「Garmin Forerunner 235」でした。2016年1月発売、まだ次モデルが出るにはもう少し時間がかかりそうな時期ですね。

Garmin ForeRunner 235
出典:Garmin社プレスキットより


なお、この種の商品選定の常ですが、どんな機能を必要とするか、どんな見た目が好みかは人それぞれかと思います。ご自身で色々と調べてみる中で、このポストが少しでも参考になれば幸いです。


まず、自分がどんなものが欲しいのかを理解する


自分、どれが欲しいんだろう?


全く新しいカテゴリの商品を買うときって、選び方も良く分かりませんよね。もちろん「見た目の良さ」という、とっても分かりやすいポイントはすぐ分かるものの、どのくらいの値段を支払うのが妥当なのか皆目見当がつかない。


こういう時は、とっても一般的な言葉でググってメディアのレビューなどを読むのがオススメです。
今回の場合は「GPS runner watch」でした。


そこで、広告を除いてTopに来たのがWareableのGPS Watch比較記事。ええやん、ドンズバ。


Wareableの記者さんの視点で、各種製品にどんな特徴があるのかをまとめてくれています。ここで、そのカテゴリの商品の選び方の「軸」とか「ポイント」を学びます。また、どういうメーカーがどういう商品を作っているのかも知ることが出来ます。

私はこの記事から


  • Apple、TomTom、Garmin、Polar、Fitbit、Motorolaが、私が欲しそうな製品を作っている
  • Apple WatchやAndroid Wearのようなスマートウォッチ寄りの製品と、純粋なランナーウォッチの2系統がある
  • 値段は$200から、上は$900とかまである

ということを学び、また各製品のレビューから、以下が自分が欲しいものだな…と知りました。


  • GPSは必須。スマートフォン以上の信号感度が欲しい
  • 走った距離、ペースの表示は必須(GPS Watchなら大体大丈夫ですが)
  • LED液晶必須。日中、太陽光の下で見難いようならそもそも要らない(今使っているFitbit Charge HRがけっこう太陽光の下では見づらいのです)
  • スマートウォッチ的な機能はあまり要らないけど、電話の着信やソーシャルメディアの通知などが届くと便利(Fitbit Altaで便利に使っています)
  • 走っていると心拍で自分の限界がおおよそ分かるので、心拍センサーは欲しい。ただし胸にバンドをつけるのは煩わしいし、そこまでの精度は無くていい
  • 走る以外の運動はほとんどしないので、スイミングやゴルフ関連機能は要らない
  • 走りながら音楽を聴いたりはしないので音楽再生、ミュージックコントロール機能も要らない
  • ケータイがAndroidなので、Apple Watch Series 2は考慮から外す(結構良さそうなんですけどね。GPS受信感度が未知数ですが)



で、この条件に見合うものを絞り込んでいったら、上述のGarmin ForeRunner 235にたどり着いた、というわけです。
ちょうど所属するランナーチームにもユーザーさんがいて、一番のポイントであるGPSの信号感度が良いというコメントをされていたことも効いています。


せっかくなので、これ以外に見たものについてもカンタンに触れておこうと思います。


TomTom Spark 3 (2016年9月発売) £119.99~($139くらい?)


TomTom Spark 3 / 製品ページはこちら
出典:TomTom社 Media Resourcesより

まずご紹介したいのがTomTom Spark 3という、発売されたばかりの製品。この製品の最大の特徴は、GPS搭載はもちろん単体での音楽再生にも対応しているラインアップがあること。ランニング中に音楽も聞きたいよ、という方は、完全にこの子だけで対応でき、スマートフォンや音楽プレーヤーなどが一切不要になります。

…ただ、ランニング中に両耳ふさぐと、危ないよ…?

また、GPXデータを取り込んで大まかなランニングルートを事前に取り込める点も魅力。ただし地図の表示は出来ないようなので、大まかなルートしかわかりませんが。

ただ、私には音楽再生は要らないこと、出来ればカラー液晶が欲しいことから見送っています。


Polar M600 (2016年8月発売) $329.99~

Polar M600 / 製品ページはこちら
出典:Polar社 Media roomより

次にご紹介したいのがこちら、Polar社のM600。こちらも比較的新しい商品です。
Android Wearという、言ってみればAndroid業界のApple Watch的なOSを搭載した製品。機能面では文句なしなのですが、どうも Wareableのレビュー にある写真だと、太陽光の下では正直画面が見づらそう…。

また、M600はどちらかというと「GPSと心拍計付のスマートウォッチ」という印象。今私は別にスマートウォッチが欲しいわけではないのと、見た目がね…。いかにも過ぎるでしょう。ロゴの赤が主張しすぎ。



Moto 360 Sport(2016年1月発売) $199.99


Motorola Moto 360 Sport / 製品ページはこちら
出典:Motorola社 製品ページより

こちらもAndroid Wearのランナー用。必要機能は備えていますが、WareableのレビューによればGarminの方がランニングフォーム関連の情報が取れるとのことで、私の中では却下。



と、まぁそんなわけで、GPSならGarminがよさそうだなと


Garmin Forerunner 630 / 製品ページはこちら
残念ながら心拍計がついていないので却下
出典:Garmin社 メディアライブラリーより


Garminは元々カーナビメーカー、GPS周りは強いだろうという勝手な印象もあり見に行ってみました。

Garminだけですね、ランナー向けウォッチだけで6~7種類ものラインアップがあるのは。迷うっつの。

大まかに価格と機能から、以下5つに絞り込んでGarmin社のサイトで比較表を見てみました。


  • Garmin fenix 3 HR
  • Garmin Forerunner 735XT
  • Garmin Forerunner 235
  • Garmin Forerunner 35
  • Garmin Vivoactive HR


※これ以外の製品は、心拍取るのに胸にバンドが必要だったり、そもそも価格が予算外だったりで却下。

比較してみると…

fenix 3 HR

fenix 3の製品ページはこちら

  • ○機能は充実、ランニングフォーム関連データも取れるしゴルフ、トレッキングにも対応
  • ×高い($500)、重い


Forerunner 735XT

Forerunner 735XTの製品ページはこちら

  • ○ラン、ゴルフ、水泳など、あらゆるスポーツに対応するトライアスリート向け
  • ○目標ペースを設定しておくと、そこからズレるとアラートしてくれる
  • ×高い、ぶっちゃけゴルフと水泳あんまりやらないので要らない

Forerunner 35

Forerunner 35の製品ページはこちら



Vivoactive HR

Vivoactive HRの製品ページはこちら

  • ○カラーディスプレイ、タッチパネルは操作しやすそう
  • ×ちーと見た目がダサい


    ということで、この4つは帯に短し襷に長し。本当はForerunner 735XTと35の目標ペースアラート機能はちょっと欲しいな…と思うんだけど、235の盤面のペースの数字見りゃすぐ分かるやん、ということで諦めが付く。


    と、いうことで、最終選考の結果Forerunner 235に白羽の矢を立てた、という次第です。

    私が選んだのはこちら、Forerunner 235です


    所感


    繰り返しになりますが、スマートフォンでアクティビティトラッキングをする中での一番の不満はGPS受信感度でした。もちろん一般的なスマートフォンの利用スタイルでは必要十分な感度を持っていると思いますが(カーナビ中にロストされると結構痛いけど)、ランニング用途では少し心許ない。

    しかし、この受信感度、なかなかスペックでの表現はされていないですね。指標化が難しいんだろうな。

    似たような概念で、モバイルブロードバンドの実効速度なんかがあると思います。ADSL最大56Mbps!とか言っておきながら、実際には3Mbpsも出ればいい方…なんてことが昔ありました。

    しかしモバイルブロードバンドとランナー用GPSで一番違うのが「ユーザー数」。
    ランナー用GPSは、そんなにユーザーが多いとも思えない。メディアさんに、その受信感度をレビューしろ…と言ってもなかなか難しいし、ブロードバンドと違って共通の測定方法もないですしね。


    ニッチな要望であるが故の悩みがここにあり、という印象でした。
    ま、使ってみないと分からないのは仕方ないですけどねー。

    2016/09/24

    クルマはさらに賢くなる…?Automatic Pro

    ちょっとだけ変わりました、Automatic Proで


    Automatic Pro。アダプターが金色になりました


    このblogを始めた頃に書いたAutomaticの記事を覚えておられる方は少ないでしょうが、今年に入ってから私のクルマは常にスマートフォンに接続され、どこからどこまで運転したか、走行距離は、燃費は、といった情報がAutomaticのDashboardに保存され続けています。

    私のAutomaticでの走行記録。何月にどこに行って、どのくらいの燃費だったかなどがつぶさに分かります。


    さて、今年の8月にそのAutomaticの第3世代、Automatic Proが発売になりました。これまでのAutomatic(無印)は$99.99でしたが、Proは$129.99。


    世代ごとの違いは…


    • 第一世代:BlueToothでスマートフォンに繋がり、情報をインターネットに送れる
    • 第二世代:単独でGPSを搭載
    • 第三世代:単独でGPSと3G回線を搭載、データ送信にスマートフォンが不要に


    といったところです。正直、第三世代の機能を必要とする人がどれだけいるだろうか…とは疑問に思いますし、私もホントにこれ要るか?俺はクルマ乗るときは必ずスマートフォン持ってるぞ?と一瞬疑問に思いましたが、次の瞬間にはなぜか購入していました。不思議なものです。


    今回は、このProを1ヶ月ほど使ってみての所感をまとめてみようと思います。


    製品概要

    Automaticシリーズを使って何ができるかは以下の過去記事を参照頂くとして…、





    ここではPro版で変わったところをピックアップします。

    1. 3G回線搭載


    一番大きいのはこれでしょう。$129.99の値段の中に、5年間、データ量無制限で使える3G回線契約が含まれています。GPSは第二世代から搭載していたので、3G搭載により、Automatic Proアダプター単体でクルマの情報をインターネットに送信できるようになりました。

    …ただ、この機能を必要とするのは通常はごく限られたユースケースのみでしょうね。例えばタクシー会社がドライバーのスマートフォンを使わずにデータを集めたり、FedExやUPSといった配送会社なりバス会社なりが自社のクルマの運行状況を把握したり、といった程度でしょう。あとはカーシェアリングとかか。


    2. スマートフォンアプリがバージョンアップではなく完全新規で作り直された


    ここ、シリコンバレーのスタートアップっぽいなぁ、と思います。これまでの無印Automaticアプリのバージョンアップではなく、完全新規のアプリとしてAutomatic Pro版を出してきました。さくっと過去の遺産を捨ててしまう、この潔さ。私は好きです。


    実は無印版のアプリ…というかそのアプリに搭載されていた「燃費向上のための運転評価」機能、とても評判が悪かったようなんです。

    無印Automaticの運転評価。ここでは100点ですが…

    評価機能そのものはよいのですが、その「減点主義的なUX設計」がまずかったんでしょうね。何もしないと100点で、急ブレーキや時速70mph以上で走る時間が長くなると点数が減っていく。

    しかも、かなり機械的に判定しているので、例えば1時間、高速道路を時速70mphで走り続けると、街中をストップ&ゴーを繰り返しながら1時間運転するのでは、前者の方が点数が悪くなる。もちろん、ガソリンの量あたりの移動距離は前者の方が長くなるのにも関わらず。


    このあたりがAutomatic社が運営するコミュニティサイトでも散々な言われようだったので、同社もゼロから作り直したんじゃないかなぁ、と思う次第です。


    また、無印Automaticアプリでは「急加速、急ブレーキ、70mph以上」を検知するとピコピコと通知してくれていたのですが、Proではその機能も(現時点では)削除されているようです。


    新しくなったアプリの詳細は後ほど。


    3. (変わっていないところ)ブラウザで見るDashboardは引き続き無印と同じデータが見られる


    スマートフォンアプリは完全新規ですが、走行データを記録して統計的にみられる、ブラウザで見るDashboardは無印のデータもProのデータも全く同じように見ることが出来ます。


    再掲:AutomaticのWeb Dashboard

    私がAutomatic Proを自分のクルマに取り付けたのが9/4。それまでのデータの延長線上で、それ以降のデータも記録されています。あくまで変えたかったのはスマートフォンアプリでの体験と、運転中の体験だったようですね。



    Pro版アプリ概要:運転評価


    さて、次にアプリの機能を見ていきます。まず運転評価の機能がどう変わったのか?

    新・Proアプリでの運転評価。相対評価に変わっています

    こちらのスクリーンショット、私のDrive Styleを表示してみました。上から順に「街中でのスタイル」「高速道路でのスタイル」「減速のスタイル」「加速のスタイル」といったところでしょうか。


    大きなポイントが、無印版の「100点満点からの減点主義、絶対評価」であったのに対し、Pro版は「xx% smoother brakes/accels than average」といった表記、つまり「平均よりxx%良い/悪いです」という、相対評価に変わっています。なるほど、という感じですね。点数化するのではなく、平均と比べてどのくらい良いのか、悪いのかという伝え方にすることで、少しは印象が和らいでいる印象です。


    とはいえ、何をもって「良い」「悪い」は明示されていないので、このままだとちょっと改善には直結しない印象です。このあたり、今後改善予定があるようなので待ってみたいと思います。


    Pro版アプリ概要:給油記録と燃費


    次に、給油記録の機能を見てみます。無印版にはなかった機能です。

    Pro版の給油記録画面。グレード、単価、支払額を記録します。

    無印版では、ガソリンのグレードとおおよその単価しか設定できず、必ずしも運転ごとの費用データが正確ではありませんでした。一方、Pro版では給油を記録することで、より正確に運転ごとの費用を計算できることになります。


    もし友人たちと長距離のドライブ旅行に出かけたりした際は、ガソリン代も分担したりしますよね。そうした際には便利な機能ではないでしょうか。



    で、どう便利になったの?


    さぁ、大事な質問です。果たして私は、追加で $129.99 というお金を払ってPro版を買ったことでどんなメリットを享受しているのか?



    …はっきり言います、新たに買い替える必要は全くなかったです。



    私の場合、

    • スマホでカーナビしているのでクルマに乗るときは必ずスマホ持ってます
    • 基本的に私のクルマは私しか運転しません
    • 運転評価については無印版の方がより「良かった、悪かった」が運転ごとに分かりやすいです

    という、さんざんな状況…。これがもし、以下のいずれかに該当するのであれば、圧倒的にPro版をオススメします。


    • 自分以外にも、自分のクルマを運転する人がいる(例:子供、配偶者、あるいはカーシェア)
    • 無印版の運転評価には正直ムカついている
    • よくスマホを忘れる
    • 社用車を多数運用している

    …けっこうレアですよね、正直。


    ただ、残念ながらProアダプターの登場により無印版は廃版となった模様。今買うならProしか買えません。

    従って、現在無印をお使いで上記のオススメ理由に該当しない場合には、焦って買い替える必要は全くないですぞ、とオススメしておきます。


    補足:Automaticユーザーで良かったと思ったとき


    Pro版に限った話ではないのですが、Automaticを買ってよかった最大の理由が「私用車を社用で使ったときの経費精算がめっちゃラク」なこと。

    私は仕事柄、自分のクルマで取引先を回ったり、各所に動き回ることが多いです。住んでいる地域の公共交通機関があまりにも未発達、ということもありますが。

    で、アメリカでは通常、私用車を社用で使った場合、走行距離に一定のレートをかけて会社に経費請求が出来ます。だいたい1マイルあたり $0.54 とか $0.57 とか。

    もちろん精算のためには、どこからどこまで何マイル運転したかをレポートしなければならないわけです。Automatic以前は、極めてアナログ(?)にGoogle mapsで地点間Transit検索し、距離を出して計算していたのですが、Automaticを入れてからは全てDashboardに情報がある。

    Automatic Web Dashboardの走行履歴例。
    いつ、どこからどこまで、どのくらいの距離を走ったかがパっと出ます


    経費精算の手間が激減しました。


    アメリカで私用車を社用で使う方、これは買う価値ありですぞ。









    2016/09/10

    Crowdfundingレポート - NiftyX : ブレスレット型スマホ用USBケーブル

    意外と便利よ、意外と。うん、意外と。



    世界初のモバイルバッテリー付き革製ブレスレット型ケーブル…
    出典:NiftyX Indiegogoキャンペーンページより


    World's 1st Leather Bracelet Cable with POWERBANK  
    世界初、モバイルバッテリー付き革製ブレスレット型ケーブル


    最初に言っておきます。我ながら物好きだな、と。だって安かったんだもん。


    …普通の人はあんまり買わないよね。


    しかし、どういうわけか私の物欲が思いっきり刺激され、Indiegogoで見かけた次の瞬間にはお金払ってました。でも、結構便利に使っていますよ。


    今回はこの製品についてと、工芸品的な側面のあるこの商品のクラウドファンディングキャンペーンについて見ていこうと思います。


    NiftyXとは?


    「世界初のモバイルバッテリー付き革製ブレスレット型USBケーブル」という説明で終わってしまうように見えますが、実はそれだけじゃないんです。


    私が購入したのは、以下の2種類。それぞれiPhone/iPad用のLightningタイプとAndroid等用のMicro USBタイプがあります。


    • NiftyX Awesome Bracelet (NAB) : バッテリーなし。端的に言うとブレスレット型USBケーブル
    • NiftyX Lifesaving Bracelet (NLB) : バッテリー付きのブレスレット型USBケーブル


    上からNLB(Micro USB)、NAB(Micro USB)、NAB(Lightning)
    レザー部分の見た目はこれ以外にも何種類かあります

    ケーブル自体はごくシンプルな構造。一般によくあるケーブルの端子とまったく同じです。


    NAB(Lightning)のコネクタ部分拡大

    ただし、もちろんブレスレットとして機能するための工夫があります。拡大写真を見て頂くと、USB A側(パソコン側に挿す方)に小さなヘコミと端子周辺に盛り上がりがあり、Lightningコネクタ側(スマホに挿す方)に小さなデッパリと溝があります。

    ジョイントを接続した状態。割とフラットになります


    これらがパチンとかみ合うことで、ブレスレットのジョイントとして機能します。

    外すときは少しコツが要ります。引っ張るだけでは外れないようになっており、Lightning側をUSB A側から少し持ち上げるようにし、テコの原理のようにパチンと外します。少々外しにくいですが、逆にバッグにつけたりしても安心していられると思います。


    さて、NLBの充電機能を見てみます。

    NLBのバッテリースイッチをONにした状態。ONだと青いLEDが点滅します

    NLBにはこのような小さなバッテリーがあり、その側面にスライドスイッチがあります。これをスマホ未接続の状態でONにすると青いLEDが点滅し、ONであることを知らせてくれます。

    NLBをスマートフォンに繋いだ状態。スマートフォンの画面に「Charging」と
    表示されているのがお分かり頂けますでしょうか?

    ONの状態でスマートフォンに接続すると、青いLEDが点灯し充電中を示します。

    気になる充電時間ですが、公称上は急速充電対応となっていますが私のスマートフォン標準のACアダプタ+USBケーブルでの充電と比べると明らかに遅いです。スマートフォンの画面ONのままだとほぼ充電されて行かないレベル。

    あくまで急場をしのぐ目的くらいにとらえた方がよさそうですね。

    ちなみにバッテリーOFFの状態でも、PCやモバイルバッテリーと接続することで単なるUSBケーブルとして機能します。


    出張時や旅行時など、長いケーブルを持ち歩くとこんがらがったり散らばったりどこに入れたか分からなくなったり、ということがアリガチ、かついくつもデバイスを持っているせいで本来必要な本数を忘れたりする私にとっては、ブレスレット型で腕に付けるのはもちろん、バッグのストラップに巻いておくだけなど、便利に活用できそうです。



    クラウドファンディングプロジェクト概略


    さて、続いてクラウドファンディングプロジェクトについて見ていきます。

    このプロジェクトも比較的小規模で、目標額が $10,000 USD で設定されていました。まぁ、資材費はそう高くないでしょうし、ポイントは革部分がおそらく手作業で編まれているだろうことからその作業費がポイントなのでしょうね。

    そして記録によれば、この目標額はキャンペーン開始から8日間で達成されています。最終的には$51,192 を調達しています。単価はおおよそNLB(バッテリー付)が$10、NAB(ケーブルのみ)が$8であることを考えると、最終製造は5,000本くらいといったところでしょうか。

    またキャンペーン開始が2月、私が出資したのが3月で、その時にはすでに最低目標額は達成していました。そしてキャンペーンクローズが4月。私にとっては金額の低さもあり、出資額逸失のリスクがほぼない状態でした。


    これまたIndiegogoのようなクラウドファンディングプラットフォームのひとつの特徴で、本製品のような、工芸品というかクラフトワーク製品を売りやすいように思います。さほど数は売れないので受注のための仕組み(E-Commerceサイトとか)にお金はかけたくない。単体でWebサイトを作っても、そこにお客様を連れてくるのも一苦労。

    でもクラウドファンディングサイトなら、すでにそこに「新しい物好き」な人たちは集まっているし、大きな投資もなくWebサイトを立ち上げられるし、その費用もプラットフォーム側の取り分に含まれているでしょうから、受注金額が少なければその分費用も安く済む(通常、調達資金の○%をプラットフォーム側が取っていく形が多いようです)。

    なかなかに合理的な仕組みだと思います。



    プロジェクトまとめ




    全てIndiegogoのNiftyXプロジェクトページより
    目標金額 $10,000 USD
    総調達金額 $51,192 USD
    達成率 540%
    プロジェクト期間 2016年2月~4月
    製品1つあたり出資額 $8-$10 USD
    出資者数 1,408
    一人当たり出資額 $36.35 USD
    遅延有無 ほぼなし


    結論


    ひとつひとつ手作りということで量産は効かないのでしょうが、自分が欲しいと思ったものを自分で手作りし、それをクラウドファンディングでシェアする…というのは、なかなかに新しいビジネスだと思います。

    スケールはしないけれど、ちょっとした副業感覚でこうした価値共有が広がっていくのは、クラウドファンディングというプラットフォームの可能性を感じさせますね。今後もこうしたもので私が欲しいものがあれば、積極的に出資していきたいと思います。



    2016/09/05

    Crowdfundingレポート - Mifold: コンパクトチャイルドシート

    子供のいる家庭には、かなり便利なアイデア商品


    一言で言うならば、折りたためるチャイルドシート、です。
    出典:mifoldサイト Free downloadページより

    昨年来、いくつかのクラウドファンディングプロジェクトに出資してきて、今年の後半になってそのプロジェクトの成果が私の手元に届くようになってきました。順次、いくつかご紹介していきますが、その第一回目として扱いたいのが、こちら Grab-and-Go booster seat, つまり「持ち歩けるチャイルドシート」 Mifold です。

    ここでは、Mifoldの製品紹介と、そのクラウドファンディングプロジェクトの経緯について書いてみようと思います。

    Mifoldとは?


    冒頭にも書いた通り、Mifoldとは「折りたたんで持ち運べるチャイルドシート」です。写真を見て頂くのが一番わかりやすいでしょう。以下3つは、いずれもMifold Webサイトのフリーダウンロードギャラリーからのものです。




    折りたたむと、クラッチバックくらいのサイズと重さ。サイズは25cm × 12cm × 4cm、A4用紙の4分の1より一回り大きいくらい。重量は750gと、そこそこしっかり。安全性のためでしょうか、見た目よりはずっしりとした重さがあります。

    サイズ感はこのくらい。隣はiPhone 5sです。

    折りたたんだ状態。ベルト部分はシートベルトの肩にかけるストラップ

    開いた状態。左右の腰ベルトをひっかける部分は3段階に伸縮します

    我が家の6歳の息子、身長120㎝が装着した様子はこんな感じになります。



    本人と私の所感は以下の通りです。

    • ○:割としっかりしてる。シートが小さく暑い日でも体温がこもりにくく快適
    • ○:何といってもコンパクト
    • ○:装着もそんなに難しくない。肩と右手側の腰ストラップはそのままにして、シートベルトフックをつけてから左手側ストラップを装着すれば済む
    • ×:高さがないから窓の外が見えにくい
    • ×:座った後に動くと座面が少し動いちゃう(上の写真でもお尻の後ろに少し回り込んでしまっています)

    もちろん安全性そのものは評価できませんが、少なくともシートベルトの固定位置は一般的な座面のみのチャイルドシートとほぼ同じようにはなっています。一般的なチャイルドシートは座面を高くすることで肩ストラップが首にかからないようにしますが、Mifoldは肩ストラップでそれを行っている感じですね。


    なお安全性基準に関しては、北米、ヨーロッパ、日本の安全基準は満たしているとのこと。ただしオーストラリアは基準が特殊なようで、いったんは対応を見送っているようです(オーストラリア向けの出荷はしていないとのこと)。

    またMifoldの対応年齢は4歳~12歳。乳幼児向けの、背もたれ+サイドクッションが必要な年齢のお子様には対応していませんのでご注意ください。


    クラウドファンディングプロジェクト概略


    さて、次にクラウドファンディングプロジェクトについて見ていきます。このプロジェクトは少々特殊で、クラウドファンディングの前に投資家から $1.8百万ドル、日本円にして2億円あまりを事前に調達しています。つまり、クラウドファンディングの成否如何にかかわらず製品化はほぼ決まっていたようなもの。

    また、初期目標額が $40,000、製品価格が$49なので、約800個分しか目標として想定していないのもこれを裏付けています。おそらく、単にプレオーダーの受注窓口としてIndiegogoを使っただけなのでしょうね。

    実際、IndiegogoやKickstarterのようなプラットフォームを普通にプレオーダーに使うことは、受注側には以下のようなメリットがあります。
    (私は自分で資金集めをしたわけではないのであくまで想像ですが)

    • 製品情報のWebページなどを、定型フォーマットに従ってカンタンに作成できる
    • クレジットカード決済などの仕組みを自分で整えなくてよい
    • メールアドレスを集めてくれるし、出資者(注文者)へのメッセージ送付なども一元管理できる
    • 製品出荷前にお金を集めることが出来る(特に米国では、商品出荷前のクレジットカード請求確定は違法、または利用規約違反となることが多いです)

    従って、Mifoldはクラウドファンディングというよりは普通のプレオーダーと見る方が適切でしょうね。その意味で、出資額が消えてなくなってしまうリスクはかなり低かったということが出来ます。
    このやり方は、既存のメーカーさん、EC事業者さんも参考になるのではないでしょうか。

    プロジェクトまとめ



    全てIndiegogoのMifoldプロジェクトページより
    目標金額 $40,000 USD
    総調達金額 $2,362,284 USD
    達成率 1665%
    プロジェクト期間 2015年7月~9月
    ただしその後もプレオーダーとして受注は受付
    製品1つあたり出資額 $49 USD
    出資者数 27,591
    一人当たり出資額 $85.6 USD
    遅延有無 ほぼなし
    当初予定では2016年4月初回出荷、実際は初回出荷3月
    (ただし米国内の、グレーを注文したユーザーのみ)



    結論


    かなりの低リスククラウドファンディングであったMifold。製品としての完成度は高く、一般的なチャイルドシートよりも安価で持ち運べるというメリットも大きい。私のようなクラウドファンディング初心者にはもってこいのよいプロジェクトでした。満足満足。





    2016/08/14

    Windowsで使いたいWi-FiのSSIDが表示されない場合の対処方法

    やっぱりまだまだ難しいよねWi-Fiって


    無線LAN機器の相互接続性を保証するWi-Fiアライアンスのロゴ。
    そうは言っても、電波法の関係などで国をまたぐとうまく行かないこともありますな。
    (Wikipediaより転載。Creative Commonsライセンス)


    やや事情があり、家人が使うPCのUSB Wi-Fiアダプターを日本で新調したのですが、そのアダプターで米国の5GHz帯Wi-Fiに繋がらない…というトラブルに見舞われました。

    そもそも日本と米国ではWi-Fiに使える周波数帯も違うので、やっぱり米国用に買わなきゃダメやろ…ということで$20くらいのUSB Wi-Fiアダプターを購入したのですが、それでもどういうわけか繋がらない。

    症状は以下のような状況です。さて、ネットワークエンジニアな皆様、どのような可能性を探りますか?


    1. そもそも繋ぎたい5GHz帯のSSID(ネットワーク名)がWi-Fiのリストに表示されない
    2. でも、例えば私のスマートフォンやラップトップはそのSSIDに接続できていて通信できているので、存在していないわけではない
    3. SSIDブロードキャストもONなので、隠されているわけではない
    4. そもそもWindowsで「非公開のネットワーク」を選択しSSIDを手入力しても「接続できませんでした」となる
    5. もちろん、WPA2のセキュリティキーも5回くらい確認し、コピペもしているので間違っていない
    6. 購入したUSB Wi-Fiアダプターは5GHz帯対応を確認済み(むしろ2.4GHz帯が非対応)


    ちょっとこの下にスペース開けますので、ウデに自信のある皆様、考えてみてください。ちなみにデバイスの初期不良ではありませんでした。




    。。

    。。。

    。。。。

    。。。。。

    。。。。。。

    。。。。。。。

    。。。。。。。。

    。。。。。。。。。。。。。。。。。。。

    。。。。。。。。。。。。。。。。。。。。。。。。。


    さて、では私が取った手順を見ていきましょう。


    トラブルシュート時の常套手段:ぼんやり設定を眺めてみる


    Windows 10のWi-Fi設定周りは、以下どちらかにあります。


    1. スタートメニュー > 設定(歯車アイコン) > ネットワークとインターネット > Wi-Fi
    2. スタートメニュー > ncpa.cpl とタイプ > Wi-Fiアダプターを右クリック > プロパティ

    今回は2を掘り下げていきます。


    Wi-Fiのディープめな設定を開く方法

    ここに、お持ちのWi-Fiアダプターに関するディープめな設定が集まっています。

    ※注:設定内容を理解しないまま変更すると、安定して稼働しているものも稼働しなくなるリスクがあります。必ず設定内容をご理解いただいた上で変更してください。

    今回注目したのは「チャンネル コード(5GHz)」という設定項目。

    Windows 10で、Wi-Fiアダプターの構成から「詳細設定」タブを開いたところ。
    Wi-Fiに関する細かな設定が制御できます。ただし設定項目はアダプターにもよるようで、
    私のラップトップのオンボードWi-Fiにはチャンネル コードはありませんでした。

    この「値」プルダウン、初期値が#6 (36-48) になっていました。ここで「あれ?」と思ったのが解決のキッカケ。5GHz帯ってこんなにチャンネル幅狭かったっけ?

    Wi-Fiアクセスポイントのブラウザ設定画面を見に行くと…

    Wi-Fiアクセスポイントの5GHz帯設定画面。チャンネルは36-48、飛んで149-165が設定可能。
    もちろん設定はAutoですが。

    だよねぇ。149チャンネル以上もあるよねぇ。


    で、ここで私のAndroidスマホにWi-Fi Analyzer入ってたな、と思い出す。私が使っているアプリはこちらのリンクから


    Wi-Fi Analyzerによるチャンネルの可視化。はい、我が家のWi-Fiはチャンネル161で動いていました。

    ここですね、やはり。ウチのWi-Fiはチャンネル161、そしてアダプター側がこのチャネルをカバーしていない。

    ちなみにWi-Fi接続済みのWindows PCがあれば、以下からも使用チャンネルは確認可能です。



      • スタートメニュー > 設定(歯車アイコン) > ネットワークとインターネット > Wi-Fi > ハードウェアのプロパティ

      画面で見ると、こんな感じ。



      と、いうことで、家人のUSB Wi-Fiアダプタの「チャンネル コード(5GHz)」の設定を、アクセスポイント上で設定可能な範囲と同じ 「#10 (36 - 48, 149 - 165)」に設定して再起動したら無事に見えるようになりました。




      結論


      Wi-Fiは一度繋がればとっても便利な反面、トラブルに見舞われてしまうと「目に見えない」がゆえにハマり度も高い気がします。アダプターによっては上記のようなチャンネルコード設定がない場合もあり、そうした場合は手動でアクセスポイントとアダプターのチャンネル数字を合わせるなどの対応が必要になることもありそうです。ちょっとハードル高いですよね。


      とりあえず、見えるはずのWi-Fi SSIDが見えない時は


      • アクセスポイント側でSSIDブロードキャストがONになっているか(後でOFFにするにしてもトラブルシュート時はON推奨)
      • アダプター、アクセスポイントともに希望周波数帯(2.4GHz=802.11b/g/n or 5GHz=802.11a/n)に対応しているか
      • デバイスドライバーは最新になっているか(アクセスポイントとアダプターのメーカーが異なる場合の相互接続性が改善したりします)
      • チャンネル数カバレッジの設定はあっているか

      を確認すべし、というのが今回の私の結論でした。

      いやはや。IoTとかWi-Fi前提なものも多いけど、こういうところ、もうちょっと整えないと「思ったように繋がらない」問題ってきっと出てくるよね。電波法とか電波既得権とかいろいろあるの、分かるけどさ。



      2016/08/03

      AWS LambdaでサーバーレスFacebook定期ポストを作ってみる

      盛大なる技術のムダ使いですが…


      今回つくった仕組みの構成図。正直、拍子抜けするくらいカンタンにできました…。


      小売業で仕事をしていると、月曜日ってけっこう忙しいんですよね。週のうち最も売上が高い週末を踏まえ、前週までのパフォーマンスを振り返って今週以降のアクションを決めていく。主要メンバーを集めて「さて、どうすっぺ」を考え、話し合い、決めていくのが月曜日です。

      そしてアメリカでは珍しいこととは思いますが、日本に居た頃の慣習で月初ってのもこれまた忙しい。月締めの請求書がワラワラとメールで届くのでそれを支払処理に回しつつ、支払いの承認決裁をしたり、チェックつまり小切手にサインしたり(ビジネスの世界でこんなに小切手が使われているとは、私もアメリカに来るまで知りませんでした…)。


      そんなわけで、月初日の月曜日ってのは、モロモロに追い立てられるような一日になるわけです。

      なので、そのモヤモヤした気持ちを私は「誰だ月初日と月曜日を一緒にしたヤツは!」などとFacebookに投げつけていたわけですが、このポストに対する反応がそこそこあるので、もしかしたら普遍的に社会人が持つ気持ちなのかなぁ、と思っています。ゆえに、これを自動化できたら月初月曜日のモヤモヤも少し晴れるかなぁ、などと考えた次第です。


      ちょうどAWSについて勉強したかったし、AWS Lambdaに何となく可能性を感じていてPythonも勉強したかったので、この「月初月曜日のモヤモヤを自動的にサーバーレスでFacebookに投げつける」という仕組みを作ってみようと思い立ちました。


      …はい、そこ。


      「そんなことして何になるの?」とか聞かない。


      仕事じゃないんだから、手段と目的がゴッチャになったって別にいいんです。趣味ですから。


      最終的な構造の説明をしますと


      今回の盛大なる技術のムダ使いをするにあたって色々なやり方を考えてみたんですが、最終的には以下の図のようになりました。冒頭の図と同じです。


      処理の流れと逆にはなりますが、右から順に構造をご説明します。

      1. とりあえず私が一番良く使うソーシャルメディアであるFacebookへのポストを自動化することをゴールに設定します
      2. AWS Lambdaから直接Facebookに投げたいのですが、Facebook側が直接HTTPなどでポストを受け付ける口を持っておらず、OAuthコールバックAPIを私側に用意しなければならないとのことで、サーバーレスに出来ないようです
      3. 回避策として、間にTwitterを挟んでみました。TwitterにはPythonのAPIがあり、Twitter側に事前にLambdaプロセスをアプリとして登録しておけば難なくツイートが可能。そして、ツイートを自動的にFacebookに流す設定はTwitter本家が持っています
      4. Lambda上での処理は私が自分でプログラミングします。しかし、月初月曜日というのはそう頻繁には来ないので、何らかのエラーで処理が止まっていても気が付かない可能性があります
      5. なので、毎月の実行結果をAmazon SNSを使ってメールで私に送る処理も書いています
      6. 最後に、この一連の流れをキックするのはAmazon CloudWatchです

      これが構造です。で、処理の流れの順に説明すると、

      1. CloudWatchから毎月月初日に、Lambdaの処理をキックします
      2. Lambda処理で「今日は月初月曜日?」を判定します
      3. 判定結果が真でも偽でも、とりあえずSNSを通じて私にメールします
      4. 判定が真、つまり月初月曜日だった場合、定型文をTwitterにポストします
      5. Twitter上の設定により、その定型文がFacebookにも流れてきます


      ということになります。さて、さっそく実装に取り掛かります。


      AWSの設定とかPythonのセットアップとか


      この仕組みの実装にあたっては、AWSのアカウントを作ったりとか私のPCにPythonをセットアップしたりとか色々あるんですが、すでにWeb上にたくさんのリソース、情報、ブログなどがあるのでここでは省略します。私は以下のようなページを参考にしました。


      Pythonまわり

      AWSまわり

      PythonのTwitterライブラリまわり



      ホント、ちょっとググるだけでザクザク情報が出てくる。いい世の中です。


      Pythonコードの解説


      さて、私が書いた(一部サンプルソースをコピペもしてますが)Pythonコードの解説です。


      # -*- coding: utf-8 -*-
      import sys
      import traceback
      from datetime import datetime
      from TwitterTokens import tokens
      import pytz
      import tweepy
      import boto3
      
      sns = boto3.client('sns')
      
      def sendSNS(message):
          topic = 'arn:aws:sns:りーじょん:えーあーるえぬ:MondayBlue'
          day = datetime.today()
          subject = '%04d/%02d/%02d MondayBlue result' % (day.year, day.month, day.day)
          response = sns.publish(TopicArn=topic, Message=message, Subject=subject)
      
      
      def tweetBlue(date):
          # Twitter API tokens
          CONSUMER_KEY = tokens['consumer_key']
          CONSUMER_SECRET = tokens['consumer_secret']
          ACCESS_TOKEN = tokens['access_token']
          ACCESS_TOKEN_SECRET = tokens['access_token_secret']
      
          auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
          auth.set_access_token(ACCESS_TOKEN, ACCESS_TOKEN_SECRET)
          api = tweepy.API(auth)
      
          msg = '%04d/%02d/%02d %02d:%02d\n' % (date.year, date.month, date.day, date.hour, date.minute)
          msg += u'【定期ポスト】誰だ月初日と月曜日を一緒にしたヤツは!'
      
          try:
              api.update_status(msg)
              sendSNS("Tweeted. It's blue Monday today...")
      
          except tweepy.error.TweepError:
              sendSNS(traceback.format_exc(sys.exc_info()[2]).split('\n'))
              return traceback.format_exc(sys.exc_info()[2]).split('\n') 
      #        print traceback.format_exc(sys.exc_info()[2]).split('\n')
      
          return 'Posted successfully'
      
      
      def lambda_handler(event, context):
      
          now = datetime.now(pytz.timezone('US/Pacific'))
      #    now = datetime(2016,8,1, now.hour, now.minute)        # デバッグ用
      
          # 0 = Monday
          if now.weekday() == 0:
              return tweetBlue(now)
      
          sendSNS("Phew, it's not blue Monday today!")
          return "Ignored, it's not blue Monday today"
      
      if __name__ == '__main__':
          lambda_handler(None, None)
      



      わりと真面目にTweepyが投げるExceptionなんかもCatchしてますが、その辺の理由は後ほど。

      たったこれだけのコードで、図解した処理が実現できちゃうんですねー。便利便利。
      もちろん、CloudWatchのイベントトリガーとか、LambdaからSNSに通知出すためのIAM作成とか、専用Twitterアカウント(念のため鍵付き)作って私のFacebookと連動させたりとか、Pythonコード以外で色々とやってはいますが。

      パソコン1台とクレジットカード(と、あとAWSアカウントのアクティベーションのための電話番号)さえあれば、ここまでのことが出来てしまう。何て便利な世の中。


      この仕組みから見えてくること


      さて、盛大に技術をムダ使いするだけじゃAWSのソリューションアーキテクトさんたちに怒られてしまうので、少しだけ考察をば。

      企業の業務システムを完全サーバーレスにすることはカンタンではないし、その意味があるのかも分かりませんが、例えばこの仕組みを応用すると以下のようなことが出来そうですよね。


      • 週末の夕方4時の時点で目標売上高の7割に届いていなかったら、店長の携帯メール宛に社長名義で自動的にハッパをかける
      • ある商品の在庫が基準値を下回ったら、メールで自動的に仕入先に発注をかける
      • オフィスのウォーターサーバー内のタンクの重さを測る秤を入れておき、ある重さを下回ったらオフィスマネジャーの携帯メール宛に連絡してタンクを補充してもらう


      …なんでこんな社畜アイデアしか出てこないんだ俺は…というのはさておき、ちょっとした便利ツールをヒョイっとカンタンに実装できてしまいそうです。上記アイデアのいくつかはホントに作ってみようかな。


      ハマったこと


      さて、以下はオマケとして、今回の仕組みを作る上でハマった(解決するのに時間がかかった)ポイントをまとめておきます。


      ハマったこと1: LambdaはZip内のサブフォルダまでFunctionを探しに行ってはくれない


      Pythonのコード群をLambdaにアップロードする際にはZip圧縮します。Zipの中でさらにサブフォルダにファイル格納する挙動をするアーカイバがあって、その場合はLambdaが.pyファイルを見つけられなくなるようで、Lambda上で「Functionが見つからない」というエラーになってしまいます。

      Windowsの場合、Zipアーカイブしたいファイルを全選択後、メインの.pyファイルを右クリックしてZipファイルを作るのが良さそう。こうすることで、Zipファイルの中に直接ファイル群が並ぶ形にできます。


      ハマったこと2: Twitterは完全同一内容の連続ポストは403 Forbiddenを返す


      私のソースコードで、TweepyのExceptionをCatchしている理由がこれです。最初は理由が全然分からなかった…。

      もしTweepyを使ってTwitterにポストする際に「Status is a duplicate.」というエラーが表示される場合はこれに該当していると思ってよさそう。

      どうもTwitterは投稿前に、直前10程度のツイートと同じ場合には投稿がエラーになるような制御が入っている模様。ほとんどの場合は問題にならない(むしろ無駄ポスト対策には良い)と思いますが、今回のようなツールをテストする際には、だいたい同一内容を連続ポストすることになるので要注意。

      私は、とりあえずツイートに日付を入れることで回避しました。


      ハマったこと3: Pythonの型指定はわりと厳密


      Lambda上でPythonコードをテストしている際、以下のエラーが出ました。

      "errorType": "TypeError",
      "errorMessage": "list indices must be integers, not str"

      エラーメッセージを和訳すると「リストのインデックス(添え字)は文字列じゃなくて整数で指定してね!」というエラー。いやでもリストなんて使ってない…いや、使ってた!

      最終的な実装からは削除していますが、サンプルコードにリスト型とディクショナリ型の両方を使っているところがあり、そこで発生していた模様。

      Pythonのディクショナリ型(Perlでいう連想配列)は dict = {} のように中かっこで初期化するものの、値の参照は [] つまり大かっこを使う。てっきり値の参照で大かっこを使っていたものだから、ディクショナリ型で初期化しなきゃいけないことに気が付いてませんでした…。これで1時間くらいロスした。ああもったいない。