SyntaxHighlighter

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時間くらいロスした。ああもったいない。



    2016/08/02

    Windows 10 へのアップグレードに使うドライブを指定するには

    Windowsユーザーの皆さん、アップグレードはしましたか?

     
     
     
     
    2016/7/29をもって無償アップグレード期間を終えたWindows 10。私用のマシンは早々に終えていたのですが、仕事用はなんだかんだ直前まで持ち越してしまっていました。
     
    そして期間最終日の29日、社内のPCのいくつかをWin10にあげたのですが、そのうち一台で奇妙な現象に見舞われました。もう何の役にも立たないとは思いますが、記録として残しておきます。
     
     

    なんでQドライブなんかに書き込みに行くわけ?

     
    奇妙な現象とは「Win10のインストーラが、普段はアクセスできない、ファクトリーリセット用のデータドライブにインストールデータを書き込みに行く」というもの。
     
    我々が利用しているラップトップにはQドライブがあらかじめ用意してあり、そこに工場出荷状態に戻すためのデータが入っています。15GBくらいのパーティションで、7割方が使用済み、空き容量としては4GBといったところ。ほとんど空いてません。
     
    で、どういうわけかWindows 10のインストーラがQドライブにデータを置きに行っているようで、インストールが失敗する症状が出ました。同時にWindows 7が「Qドライブの空き容量がなくなりましたよ」と言った警告を出すので、これは明らかにQに書きに行ってる。メインかつ唯一のユーザードライブであるCには空き容量が28GBもあるというのに。
     
     

    解決策はテキストファイルにあった

     
    サクッと解法に行くと、答えは C:\Windows10upgrade\configuration.ini にありました。
     
    Explorerで C:\Windows10upgrade\ を開き、configuration.ini を探します。

     
     
    これを右クリックし「編集」を選択。
     
    以下、引用。
    [Default]
    PartnerId=9194
    Flight=fast
    DownloadESDFolder=Q:\Windows10Upgrade\
    この4行目にある通り、どうも Q:\Windows10upgrade にデータがある、あるいはそこにデータを置こうとしているように見えます。ここを C:\Windows10upgrade に、つまりQをCに変えたところ、上手く進むようになりました。
     
     
    何かのキッカケでインストーラが「Qを使えばいいんだね!」と思い込んでしまったのでしょう。設定ファイルをそのままQで進めるべく作ってしまったようです。
     

    もしかしたら、だけれども

     
    以下は試していませんが、ここを例えばUSBの外付けHDDまたはUSBメモリのドライブレターに変更すれば、PCのHDDに空きが充分になくてもインストールさせることが出来るかもしれません。
    実際、20GBの空きがないとアップグレードできないWin10。これで空き容量を作る手間が省けるのであれば、32GBほどのUSBメモリを買って済ませるのもアリではないかなー、と思います。

     

    2016/07/19

    越境社内DNSでAkamai化が逆効果になる事象を発見した

    まさかこんな影響があるとは思わなかった…

    サンフランシスコにある私のオフィスから、San Francisco Chronicleという新聞社のWebサイトへのtraceroute結果


    ある日のこと、オフィスで仕事をしていて「どうもWebサイトが開くの遅いよな、ウチのオフィス…」とボンヤリ考えていました。

    遅いけれども、別に開かないわけじゃない。ちゃんとWebサイトは表示される。でも、画像がちょっとずつ表示されたり(スパっ、と出るのではなく、がっががっ、と出る、と言えば伝わりますでしょうか)、リンクをクリックしてから一瞬、時間にして1.5秒くらいブラウザが考え込んでから次のページのロードが始まったり、といった具合です。

    最初は「Wi-Fiが混雑してるんだろうな、どうせ」と思っていましたが、有線LANにしても同じく遅い。これは何かがおかしいぞ、ということで調べてみることにしました。


    まずはPingとTracerouteだよね


    ネットワークエンジニアとしては、PingとTraceroute。最近はPingに応答しないWebサーバーも増えてきているので、インターネット上のHTTPを調べる時はいきなりTracerouteで途中の経路まで調べるのが私の中で常態化しています。

    とりあえず遅いと感じたのが、私の地元にある地方紙新聞のSan Francisco Chronicle。さすがに地方紙だから地元にあるだろう、と思ってTracerouteしてみたら…。


    その結果が、冒頭にも掲出したコチラ。

    私のオフィスからwww.sfchronicle.comにtracerouteした結果(再掲)

    異常が出ていること、お分かりでしょうか?

    11ホップ目で、なんと日本のkddi.ne.jpを通っていて、その直前と直後で100ミリ秒(=0.1秒)のレイテンシ差が出ています。

    そして最終到達点はAkamai。最初はなんでこんなことになるのか分からなかったのですが、この画像をFacebookにシェアしたところ、友人の一人から「AkamaiのDNSが日本のサーバーのIPを返している、ということだ」とのご指摘。

    このご指摘でピンと来ました。これ、原因はウチの社内DNSです。


    どういうことか、というと…


    セキュリティ的に詳しく書けないので相当模式化していますが、ざっくり絵にするとウチのネットワーク構成はこんな感じです。

    今回のケースを説明するための模式図

    まず右下が私のオフィスがあるネットワーク。社内ではWindows中心で、Active Directoryによるドメイン管理を行っています。

    一方で私のオフィスはまだ規模が小さいため、ドメインコントローラーは日本にあるものを使っています(図の左下)。そして日米間はIPSec VPNで常時結ばれていて、100~300ミリ秒くらいのレイテンシはあるものの安定して日米間接続は稼働しています(図の中央下)。

    Windowsドメインでの運用のためには、クライアントPCにDHCPで配布するDNSサーバーはドメコンにする必要があります。このため、すべてのDNS名前解決クエリは日米間VPNを通って日本から解決されます。

    これを示しているのが以下の図。

    クライアントPCからHTTPアクセスする際のDNS名前解決の模式図

    名前解決で普通にアメリカのIPアドレスが帰ってくれば、HTTPリクエストは日米間VPNを通らず、普通に米国側のインターネットアクセスラインから出ていきます。実際、Google関連サービスなんかは(おそらく)その経路。

    ※GoogleへのTracerouteは経路上のホスト名が出てこず、すべてIPアドレスなので推測しかできないのですが、レイテンシが100ミリ秒以下とあまり大きくないことからまず間違いないです。


    一方で、わざわざTracerouteが日本へ抜けているということは、DNS名前解決クエリで戻ってきたIPアドレス(つまりHTTPリクエストを送る先)のサーバーが日本にあるということ。


    ここは推測ですが、Akamai化されているWebサーバーのDNSエントリはCNAMEで定義されていて、実態はAkamaiのキャッシュサーバー群に向いている。そしてAkamaiのゾーンオーソリティは、DNSクエリの発信元IPアドレスを元に、そのクエリ発信元にネットワーク的に最も近いキャッシュサーバーのIPアドレスを返しているのではないかというのが私の仮説です。


    実際、Akamai社は全世界に20万台を超えるキャッシュサーバーを持っており、そのどれにクライアントからアクセスさせるかがAkamaiの技術のキモであるはず。そのくらいのことはやっていてもおかしくありません。


    つまり、Akamai化されているWebサイトへのアクセスは、現状だと全て日本のキャッシュサーバーにデータを取りに行ってしまう。せっかくSan Francisco ChronicleやAppleが見る人にAkamaiで高速化を提供してくれているのに、こちら側のLAN構成によりそれが逆効果になってしまっている、という現象です。


    Akamaiの仕様にツベコベいってもしょうがないし、そもそもわざわざ日本のDNSを見に行っているこっちの構成の方がイレギュラーなので、これはまぁ仕方ない。


    とはいえWindowsドメインを運用するためには、少なくとも動的DNSを米国側に立てる必要がある。BINDとかで立てても良いが、どうせならドメコンを立てた方が耐障害性も高くなるので好ましい。


    解決策は、と言うと…


    要するに、こういう構成にする必要があるってこと。

    ドメコンを米国側に立てた構成

    そしてDNSクエリを模式化した絵がこちら。

    米国のドメコンを通じた名前解決の流れ


    米国にあるドメコンからAkamaiに対する名前解決クエリが飛ぶので、Akamai DNSが返してくるDNSの期待値は米国にあるAkamaiサーバーのIP。それが返ってくれば、HTTPリクエストもわざわざ日米間トンネルを通ることなく、直接インターネットに出ていくはず。


    ドメコン立てるのもカンタンではないので、まだこの構成は試せていませんが、追って対策後についてもブログ記事にまとめてみようと思います。


    しかしまぁ、なんというか。


    インターネットもずいぶんと複雑化したものですね。AkamaiのようなCDNやらWAPやらIDSやら、セキュリティを高めたり利便性を高めたりするために色々なレイヤーが重なり合って、インターネットが持つ「シンプルさ」はとうの昔に捨て去られた、ということを改めて実感した次第です。


    …とはいえ、ドメコンをわざわざ太平洋越しに見に行くようにした私の設計もちょっとどうかとは思いますけどね…。だって運用する時間もなければドメコン立てるような規模でもないんだもん…。







    2016/07/10

    経営論連載Vol.3 - Coinの失敗事例に学ぶ、ビジネス論文の使い方

    わりとセオリー通りに見えるんだけれど


    クレジットカード、デビットカード、ポイントカードなど複数のカードを1枚にまとめられる製品として
    大きな話題を集めたCoin。
    出典:Coin社Webサイト Press kit より

    2013年11月、ある起業家がCoinというクラウドファンディングプロジェクトを立ち上げました。Yコンビネーター(シリコンバレーでは有名な、最近は日本でも有名なベンチャーキャピタル兼インキュベーション組織)を含む多数の投資家から資金を集め、かつクラウドファンディングプロジェクトでは350,000オーダー、1700万ドル (日本円で約20億円!)もの資金を集めたとされています(出典:recodeの記事内で350,000オーダーが集められたと語られており、当時プレオーダーは1件$50だった)。


    しかしながら、現在同社はフィットネストラッカーのFitbit社に買収され、かつ現行製品であるCoin 2.0は売り切れ。さらに後継製品の開発は行わないと明言されているため、これは明確に「失敗」です。


    アイデア、プロトタイプ、テスト、製品化。

    豊富な資金、成功請負インキュベーター。


    経営論連載の最終回は、典型的なシリコンバレーの成功要件を備えているように見えるこのCoinプロジェクトの失敗例を紐解きつつ、デザイン思考のような「ビジネス的な考え方」「方法論」の使い方に踏み込んでみようと思います。

    他の連載は以下からどうぞ。

    なお本稿の執筆にあたり、サンフランシスコと東京を拠点とするブランド&マーケティングエージェンシー Btrax のCEO、Brandon Hill氏のブログから着想を得ました。ここにお礼申し上げます。


    Coin社が失敗した理由


    同社の失敗理由は様々語られていますが(前述のBrandonのブログが分かりやすいです)、私は「品質の低さ」が最大の要因だったと思います。

    本稿の執筆にあたって英語のCoinレビューを数件読みました。いずれも、クレジットカード端末がCoinを認識せず、それで支払えなかった体験を深刻な問題として指摘しています。

    Coinは、クレジットカードなどにあるいわゆる磁気ストライプの情報をスマートフォンで読み取り、Coin本体に登録。ユーザーがどのカードを選ぶかによって、Coin自身の磁気ストライプの情報を書き換えます。

    この磁気ストライプ書き換えが、どうやら安定しなかった模様。カードを読み取っても認識しないケースが多数報告されていました。


    でも、ちょっと待ってください。シリコンバレー的には「クイックに失敗し、すぐに学んで作り直す」ことが良しとされています。
    まず作ってみる。デザイン思考の中でもそれが説かれています。


    デザイン思考の5つのプロセス


    ではなぜ、Coinの失敗は成功の母になれなかったのでしょうか?



    失敗することに失敗した


    これは私の推論ですが、端的に言うと「Coinは失敗することに失敗した」のだと思います。
    後戻りできないところまで言ってからの失敗は、クイックな失敗とは言えません。

    Recodeの記事に、Coin社CEOであるKanishk Parashar氏への電話インタビューがありましたので引用します。和訳は私によるものです。

    “A big part of doing mass production is stabilizing each unit so it performs as well as we want. When you build tens of thousands, you get some variability,” he said. “With us, you’re holding the thinnest wearable ever made so it kind of tests limits of those tolerances. Over time, as we figure things out, we’ll make that variability smaller and smaller.”

    「ひとつひとつの製品を望むとおりに稼働させるべく、製品を安定させることが量産段階における大きな課題でした。何万個も製造すれば、多少のバラツキは出てきてしまいます。我々の製品はかつてないほど薄く作られているためちょっとしたことでもうまく動作しません。こうしたことが分かってくるにつれて、バラツキをどんどん小さくしていけると思っています」

    He said the company was making hardware updates at least every two months, which means customers who received their card first may have a card that doesn’t work quite as well as those in the back of the line. The company is producing about 10,000 cards a week.

    彼は、2ケ月に1回はハードウェアに修正をかけていると言っていました。それはつまり、Coinを一番最初に受け取った人は、もっと後に受け取った人ほどは上手く動作しない可能性があるということです。Coin社は、週に1万枚のカードを製造しています。

    As for the bum card reader, Parashar believes “issues will subside as we improve the UX on how to use it.” He said a user interface upgrade was coming sometime this month.

    Coinを認識しないクレジットカードリーダーについては、Parasharは「Coinの使い方を改善すれば、その問題は沈静化すると考えています」と語り、間もなくCoinのUIが変更になると語りました。

    What’s clear beyond my experience is that the demand for Coin overwhelmed the startup. The company had been planning for tens of thousands of orders, Parashar says. Instead, the company has received around 350,000. That meant the initial plan to manufacture the cards in a facility in the U.S. went out the window when it was clear the volume that plant could produce would not be enough. That was an unexpected complication and a big reason for the year-long delay on shipping.

    私の知る限りにおいて一つ明確に言えることは、Coinに対しての需要がベンチャー企業に対しては高すぎたと言えるでしょう。Coin社は数万個の受注を想定していましたが、一方で受注は何と約35万個。これはつまり、米国で想定していたCoinの製造設備の能力を超えていて、別の方法を探さなければならないことを意味します。これは想定外で、1年以上にもわたって出荷を遅らせる要因となりました。

    What’s not clear is why Coin kept accepting preorders when it was clear they were already unable to keep up. I asked Parashar this in a phone interview and there was a long pause on the other end of the line before he answered.

    では、なぜCoin社は自社の能力を超えるオーダーを受け付けてしまったのでしょうか?私はこの質問を電話インタビューの中でParasharに聞いたところ、彼は電話の向こうで長い沈黙の後にこう語りました。

    “That’s going back and trying to have 20/20 hindsight,” he said, finally. “That’s a hard one to answer.”

    「振り返ってみれば、当然のことかもしれないが…いや、難しい質問です」

    “It’s been way, way harder than we imagined,” he added.

    さらに、彼はこう付け加えました。「我々が想定していたより、ずっと…ずっと難しかった」


    このインタビューから、好調なプレオーダー受注に気を良くし、資金さえあれば製造は何とかなる…という気の緩みがあったように私には思えます。確かに後から言うことはたやすいけれども、きっとParasherはその時、上手く行く未来しか見えていなかったのではないでしょうか。いや完全な憶測ですが。


    たられば論にあまり意味はありませんが、仮にプレオーダーをキャパ一杯の100,000に絞っていたら?
    かつ、先行数千人の「リテラシーの高い」テストユーザーに先行配布し、資金に余裕があるうちに生産ラインの方針転換を判断出来ていたら?


    これが私が「失敗することに失敗した」と感じる理由です。


    私が少額支援しているZNAPSは、プロトタイプをごく限られた(1000人程度の)支援者に使わせ、その結果品質が十分に出ていないことを悟り、作り直しのプロセスに入っています。
    (私が2016年3月にブログ記事にしています)


    シリコンバレー的な成功の方程式に乗っていても、デザイン思考的な考え方に基づいた事業開発をしていても、失敗するときは失敗する。それらのセオリー通りにやったとて、成功は保証されていないのがビジネスというものなんだろう、と思います。


    つまり、私がここで言いたいのは…


    本連載のキッカケを作ってくれた、あるコンサルタントは現在米国の大学に留学中で、間もなく論文をまとめようとされています。私も昔、ビジネススクールの教授が書いた論文はいくつか読みました。

    しかし、ビジネス論文に関しては、実際に事業を行う中でその実用性を感じることはあまりありません。むしろ、そうした考え方は「そのまま使っても意味がない」とさえ感じます。デザイン思考のような便利な考え方でさえ、実務にはさほど役に立たない。


    一方で、ビジネス論文にあるような「考え方」を知っているのと知らないのとでは、失敗の確率が大きく違うとは思います。


    例えば、プロトタイプの重要性を理解していないプロジェクトリーダーの元でいくらプロトタイプの重要性を説いても、時間ばかりかかってしまう。しかし、プロトタイプの重要性を全員が分かっているチームでは、おそらくデザイン思考の考え方は受け入れられ、「プロジェクトの進め方に関する議論」という、やや非生産的なことに時間を使ってしまうことはないでしょう。


    ビジネス論文を読み、学ぶことそのものが無駄だと言う意図はありません。しかし、それを学んだとて、使い方を誤ってはならないな、と感じる次第です。

    例えばチーム内の共通認識を作るために、みんなで学んだり。

    類似の事例の失敗事例を扱った論文を読んでおくことで、自らの仕事への戒めとしたり。


    そういった使い方をしなければならないのだろうな、と、ビジネス論文について感じた次第であります。


    2016/07/08

    経営論連載Vol.2 - デザイン思考の5プロセスから見る日本のWebデザインの限界

    Webデザイナーと名乗るからには


    デザイン思考の5つのプロセス。和訳は筆者による。
    出展:An Introduction to Design Thinking PROCESS GUIDE

    なんだかんだ、私がWeb界隈のビジネスに身をおいてはや10年近く経ちました。生まれて初めてHTMLに触れたのは確か学生時代の1996年とか97年とかなので、それから20年くらい。まだCSSという規格がなかった時代に、テキストエディタ(メモ帳的なもの)でHTMLを打ち込んで自分のWebページを作ったものです。

    あいにく私には絵心がなくセンスゼロだったので、制作方面では全く大成しませんでした。それゆえ、自分が仕事で関わったWeb制作はほとんど外部のWebデザイナーさんにお願いして作ってもらっています。そうして作ってきたページ数は、もう数えられませんが1,000ページは超えると思います。そして、お付き合いしてきたWebデザイナーさんも数十人になります。

    その数十人の方々について「この方とはちょっと上手くやれないなー」とか「この方にはぜひ次もお願いしたい!」という感想は正直言うとありました。でも、今まではそれが何なのか、使う写真やイラストなどのクオリティ以外には何が良かった・悪かったのか、上手く言語化できませんでした。

    連載Vol.2として、この違和感についてデザイン思考の5つのプロセスの観点でまとめてみようと思います。

    その他の連載はこちらからご覧ください。




    そもそもデザイン思考って?


    デザイン思考そのものの解説はここでは控えますが、本論の入り口として、デザイン思考のビジネス応用提唱者 Tim Brown による説明を引用します。

    Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

    以下、私による意訳です。

    デザイン思考とは、デザイナーの感性や手法を用いて「人々のニーズ」と「出来るのか?」「やるべきなのか?」をマッチングさせて、お客様への価値を実際に形にして提供する考え方のことです。

    少々ややこしいので誤解を恐れずにさらに噛み砕くと「デザイナーのモノの考え方を応用して、ビジネスチャンスを広げるための考え方」ということかと思います。

    つまり、元々は「優れたデザイナーさんのアタマの中を整理するとこういうことなんです」というものかと私は解釈しています。


    それで、「デザイン」「デザイナー」って?


    日本語で「デザイナー」というと、何というか、モノや絵の見た目を作る人、というイメージが強いですよね。プロダクトデザイナー、Webデザイナー、服飾デザイナー。

    でも英語で「design」というと「企てる」とか「設計する」という意味合いの方が強い。それって、日本語で言うと「プランナー」みたいな感覚だと思うんです。広告プランナー、イベントプランナー、映像プランナー。

    まぁ肩書きの定義は別の場で論じるとして、つまり英語で言う「Design Thinking」のDesignとは、設計する、という意味合いなのではないかと思います。なので、「設計する人の考え方を整理したものがデザイン思考」ということかな、と。


    そして英語で「Web design」というと、単にWebページの見た目を作ることではなく「そのページは何を目的としていて、見ている人に何をして欲しいのかを設計してページにする」ということだと私は解釈しています。


    そしてデザイン思考をWebデザインに当てはめると


    以上の2つの疑問への私の解釈を踏まえて、Webデザインの領域にデザイン思考の5つのプロセスを当てはめてみると、これがずいぶんシックリ来るんです。今までの経験の「良かったWebデザイン」「悪かったWebデザイン」が言語化できるんです。


    1. Empathize - 感情移入する




    まず、そのページを訪れる人の気持ちになってみる。

    私は、何がしたくてわざわざこのページを開いたんだろう?

    その時、何に困っていたんだろう?あるいは何にも困ってなくて電車の中のヒマつぶし?

    私は投資家で、その会社の財務情報を見たい?私はお客様で、とりあえず店舗の場所が知りたい?

    とりあえず新しいメガネが欲しいけど、どれを買ったらいいのか分からない?


    よくマーケティングの世界では「ペルソナの設定」などといいますよね。それと同じことではないかと思います。


    2. Define - 問題を定める



    自分は、本当は何がしたいんだろう?

    ある有名な言葉があります。


    「ドリルを買いたい人は、ドリルが欲しいのではない。穴が欲しいのだ」


    ペルソナを設定したからといって、すぐに表層的に見た目づくりに入ってはならない、と言われているように感じます。

    私はドリルを探しているけど、本当に欲しいのはドリルを使って作る椅子なのかもしれない。


    私がドリルを探している理由は、壁に穴をあけて棚を据え付けたいのかもしれない。


    私がお店の場所を探している理由は、カメラを修理したいたけで本当はお店には行きたくないのかもしれない。


    そうやって、お客様の心の声を想像し、問題を設定する段階がDefineです。


    3. Ideate - アイデアを出す



    さて、お客様の心の声が見えてきたら、その解決策のアイデア出し。どうすればお客様の要望を満たせるページが出来るでしょうか?
    (もしかしたらWebページじゃなくてメールマガジンが解決策かもしれないですけどね)


    お店の場所を検索している人に、郵送修理サービスを提案してはどうだろう?あるいはカスタマーサポートの電話番号を表示してはどうだろう?

    ドリルを検索した人に、椅子や棚などのカスタムメイドサービスを提供してはどうだろう?

    この時、もはや解決策がWebページの制作ではなくなるかもしれない。でも、それでいいんじゃないかと思います。
    なぜなら「Webページ作らなきゃ」という解決策の設定そのものが間違いだった、ということですから。
    (とはいえ、他のEmphasizeやDefineからWebページ制作の必要性は見えてくると思いますけどね)


    4. Prototype - 解を作ってみる



    さて、解決策の設定が出来たら、次は作ってみること。この文脈においては作るものはWebページなので、とりあえずもうコーディングしちゃう。カンプ(Photoshopなどで作る、とりあえず画像などを貼り合わせて見た目を整えたもの)も作らない。

    ちなみにデザイン思考の考え方では、模型でも紙芝居でもコンセプト動画でもいいからカタチにすることが大事、と説かれていますが、Webやスマートフォンアプリの場合は、骨組みだけでもいいから実際に動くものを作ることが大事だと思っています。

    なぜなら、Webやスマートフォンアプリは「インタラクティブなもの」だから。つまり、使っていて気持ちがいいか、押しやすいところにボタンがあるか、スマートフォンの小さい画面で見て十分な大きさか、といった「人間の感性との対話」が大切だから。スマホアプリの動作概要を紙芝居でやるのは正直限界があって、本当の意味でのプロトタイプにならない。

    こういう話をすると、制作する側、デザイナーさんは「いや、でも思い込みで作っても全然ダメだったら無駄手間になってしまうので」という話をされる方がいます。

    私も昔アプリケーションエンジニアだったころには「いや、どういうアプリケーションがいいかはお客様じゃないと分からないから」と一歩引いてしまっていました。なので、そのお気持ちも良く分かります。


    そう、ここが本論のポイント。


    一歩引いてしまっているということは、デザイン思考で言うところの Emphasize が出来ていないからなのではないでしょうかね。

    そのWebページなりスマートフォンアプリなりの、ユーザーさんの気持ちに共感できていないために、そういう発想になってしまう。

    これが出来るWebデザイナーさんは、私が考える「よいデザインを作れる人」であったのかな、と気が付いた次第です。

    ※だからと言って、発注側である私が共感しなくてよい理由にはなりません、というのがVol.1のお話だったりします。


    発注者も、Web制作者も、お客様の気持ちに共感してこそ、本当に価値のあるWebページが生まれるんじゃないでしょうかね。

    このポイントを理解しているWebデザイナーさんは、日本にはちょっと少なかったかなー、と振り返ると思います。


    5. TEST - 試してみる



    …とか何とかエラそうに私が言ってみても、真の意味でお客様が欲しているものはお客様に聞かないと分からない。
    もちろん制作者自身もイチお客様になり得るわけですが、統計的にはより少し多くの人に見てもらったほうがより「確からしく」なりますよね。

    とりあえず動く、触れるWebページが出来上がったら、それを試してもらう。なにもお金を払って本当の一般消費者の人に来てもらう必要はありません(それが出来れば一番いいけど)。社内の別部門の人、社員の友達とかでも良い。実際に触れてもらい、そしてフィードバックをもらう。

    そうやって出来上がるものが「よいデザイン」なのではないかな、とデザイン思考では説いているように思います。



    総括


    そういうわけで、私が日本に居た頃にWeb制作を発注していて感じていたモヤモヤ感を、デザイン思考の切り口で言葉にしてみました。願わくば、このような考え方を体得しているWebデザイナーさんが日本でも増えて、日本のWeb界隈の品質が上がっていくと良いな、と思います。

    ※ちなみに言うと、アメリカではこれまで2社ほどWeb制作を委託してきましたが、うち1社はデザイン思考をナチュラルに実践しておられ、もう1社はちょっと違う感じでした。このあたり、発注前にどう見極めるか、私も模索してみたいと思います。



    参考文献


    IDEO社 Aboutページ(英語):デザイン思考の超概略が分かりやすくまとまっています

    Stanford大学 d.school によるデザイン思考のプロセス解説(英語):英語たくさんですが網羅感あり


    0から1を創り出すデザイン思考 ― 新たなイノベーション創出手法(日本語):ちょっと固いけど良くまとまっています

    SAP社によるデザイン思考の活用に関する動画(日本語字幕):EmpathizeとDefineのプロセスが分かりやすく紹介されています


    Special Thanks


    なお、私のデザイン思考に関する知識は SAP社 Palo Alto Labにお勤めの小松原 威さんから大部分を頂いております。彼の教えなくして本連載はありません。ここに改めて感謝の意を表したいと思います。





    2016/07/04

    経営論連載Vol.1 - デザイン思考の3要素と昔のビジネスコンサルティングの限界

    昔、コンサルタントだったことがありましてね


    デザイン思考の3つの要素。ちなみにこれがデザイン思考のすべてではありません


    先日、ひょんなことから現役の経営コンサルタントである方と酒杯を傾けながらお話する機会がありまして。

    その時に、最近いろいろシリコンバレー流の考え方をインプットしている中で、新しい事業価値の創造についてボンヤリ考えていたことが急に線でつながったので、それをまとめてみたいと思います。
    (赤字部分、重要です。本論では、あくまで「新事業価値創出についてのみ」論じています。


    その後、自宅のソファでふんぞり返りながら、一瞬眠りに落ちたりしながら考えると、どうも以下の三部作に分けるのがよさそうだ、と思い至りました。


    今日はこのVol.1について書いてみようと思います。


    少しだけ昔話:2005年頃のビジネスコンサルティング


    今をさかのぼること10年以上前のこと、私の転職活動中に、とある世界的な戦略コンサルティングファームのパートナー(一般に、コンサルティングファームにおけるコンサルタントの最上位職位)の方と面接をする機会がありました。

    その際に、当時の私が疑問に思っていた質問をぶつけてみました。その時のやり取りは、おおよそ以下のようなものでした。


    私 「戦略コンサルタントは、顧客と利害が一致しないことが強みでもありますが、同時に弱みでもあります。弱みは、コンサル案件の結論にコンサルタントは最終的に責任を持てない。ゆえに、本当の意味で顧客の価値創造が出来ない。なぜ、コンサルタントは責任を取らないのでしょう?」


    パートナー 「それはコンサルタントのすることではないからです。事業の責任はクライアントにある。コンサルタントは、あくまで第三者の立場でクライアントに価値を提供することが仕事です」


    私 「でも、コンサルタントに案件を依頼するクライアントは何かしらの価値創造を求めているわけですよね?真にクライアントの価値を考えるのであれば、コンサルタントも例えば出資するなどして共同責任を負う立場にならないと、クライアントの利益という本当の価値は出ないのでは?」

    最後の質問に対する答えは忘れてしまいましたが、少なくとも当時の私が納得する答えではなかったことだけ覚えています。

    上記は、今でも感じているコンサルティングの限界です。現在はコンサルタントではなく、コンサルタントに仕事を依頼する側に居る身として常に念頭に置いているのが「コンサルタントは結論に責任を取るのではなく、結論に至る過程をアシストしてくれるだけだ」という点です。

    ※ちなみに、私は戦略コンサルタントの価値を否定しているわけではありません。私がコンサルタントの価値を見誤っていた、というだけです。

    ※さらにちなみに、当時の私はベンチャーキャピタルという存在を知りませんでした。自ら出資し、時には人も出してクライアント(投資先)とともに成長する、というビジネスは世の中には存在します。つまり、私はコンサルタントに対して「なぜベンチャーキャピタルのような仕事をしないのか?」という、無知な質問をしていたわけです。そりゃ不採用にもなるわな。


    閑話休題。


    この「私が考えたコンサルティングの限界」について、デザイン思考の3つの要素が見事に説明してくれていました。


    デザイン思考とは?


    デザイン思考の概論については、すでに日本語での解説も多くあるようですのでここでは割愛します。以下の参考リンクをご参照ください。

    (日本語) デザイン思考を15分で学ぶページ

    (英語) デザイン思考のビジネス応用提唱者デイビッド ケリーが創業したIDEO社の会社説明



    デザイン思考の3つの要素


    さて、ここで冒頭に掲出した画像の出番です…が、少しだけ色の場所を変えます。

    デザイン思考の3つの要素、Desirability, Viability, Feasibility。


    デザイン思考の考え方では、何よりまず「Desirability」、つまり「お客様はこれを欲しがるのか?」についてを最初に考えるべき、と説いています。これはこれで私も共感するところなのですが、本論においては「Viability」に色を付けます。

    Desirability、つまり「顧客の悩みを解決し、顧客が対価を支払いそうか?」については第三者であるコンサルタントでもある程度判断は出来ます。市場調査、テスト販売、あるいはコンサルタント自身が消費者としてそれを求めるか?など。

    Feasibilityは客観的な視点です。技術的に、物理的に、あるいは社内の資金や人材などのリソース的に見て、できるのか、できないのか。ある意味、コンサルタントが最も得意とするところではないかと思います。



    しかしながらViabilityについては、第三者であるコンサルタントには判断が出来ない。


    「客観的に見て、この新規事業が最もリスクが低く、かつ成功する可能性があります」


    それ以上のことは言えないんです。クライアントのビジョン、事業目的をアタマでは理解したとて、そのクライアントの中の人ではない。



    基本的には、コンサルタントというのは第三者。クライアントからモノ・サービスを買う顧客でもないし、株主でもないし、オーナーでもない。このViabilityを「本当の意味で」判断することはできない存在です。


    これが、私が考えるビジネスコンサルティングの限界。



    従って、もしあなたが、自分の会社を何とか変えたい、新しい価値を生み出したいと考えるのであれば、依頼先はコンサルタントではないように思います。

    (では、どうするか? 試しにデザイン思考を使って考えてみてはいかがでしょうか)


    コンサルタントの価値は、「卓越した知見と明晰な頭脳をもって、複雑怪奇な事象を解析し整理する」ことであったり、「現状最も確からしい、リスクの低い選択肢の提案」にあるのであって「新しい事業価値の創造」ではないのかな、と今になって考える次第です。


    …ただ、私の「ビジネスコンサルティング」に対する知見は10年以上前のものです。もしかしたら今は変わっているのかもしれません。もしそうであれば、ぜひ一度お話を伺ってみたいものです。


    総括


    なんだかビジネスコンサルティングを否定する文章みたいになってしまいましたが、決して私にその意図はありません。例えばクライアントのワークスタイル改革だとか、生産性向上だとか、企業内の病の治療などには相性バツグン。それはコンサルタントが第三者であることが最も強みとして活きる領域です。


    単に私がコンサルティングをしているなかで感じていたもどかしさは、このデザイン思考の3要素を使うと明確に説明できると感じた、というだけの話です。


    つまり、新しい事業価値を創造したかったら、自分たちでやるしかないんだよな、ということ。


    もしコンサルタントさんたちに、どうしてもその輪に入ってほしかったら、きっと利害関係を一致させるしかないんでしょうね。出資してもらうか、雇用契約を結ぶか。でもきっと、その人との関係はもはやコンサルティングじゃない。そのヒト個人と目標を共有して「自分たち」になってもらう、ということでしょうね。