2012-06
11
04:16:27
LINEは何故急成長できたか – LINEの発明の光と闇


NHN JapanのLINEアプリが大人気だ。
全世界のユーザー数が4000万人を超え、国内でも1800万人のユーザーを突破したという。 今でも月に500万人が登録し続けており、年内にも1億ユーザーを目指す、という。

驚くべきはその成長率であり、LINEは2011年6月に公開されてまだ1年しか経っていない。しかし全くの新規アプリ・サービスでそれだけの期間に4000万人が登録したコミュニティというのは他に例は無いだろう。
OGC2012のNHN Japan自身の講演によれば、 会員2000万人突破にかかった期間は256日であり、これはTwitterの1035日・Facebookの1152日に比べても驚異的と言えるだろう。

無論こうした爆発的な人気の原因には、そもそものコミュニケーションツールとしての使いやすさ・取っつきやすさや、無料であること、TVCMなどのマーケティングなども大きな要因であろう。
しかし僕はそこには、これまでどのサービスも乗り越えてこなかった大きなポイントがあると思う。
それは「ネットワーク構築のショートカット」である。

LINEはネットワーク構築のショートカットを発明した

ネットワーク外部性」とは、もう既に説明するまでも無いかも知れない。元々は経済用語なので幾つかの理解もあるようだが、IT分野においては一般に「コミュニティやコミュニケーションツールは利用者が増えれば増えるほど利用者にとってのメリット(利用価値)が高くなる」ことを意味する。
例えばLINEのようなコミュニケーションツールで利用者が少なく、せっかく登録しても友人が誰も使っていなければ全く利用価値は無いだろう。しかし4000万人もユーザーがいて多くの友人たちとコミュニケーションできるなら利用者にとっても利用価値は増大したことになる。
メールから始まりIM、SkypeなどのVoIPアプリ、mixi・Twitter・Facebookに至るまで、これまで世の中を席巻してきたツールやSNSなども例外なく、最初ほとんどネットワーク外部性が無いところから始まり、徐々にユーザーを集めるうちに利便性を増し社会的影響力を持つ大規模ネットワークとなってきた。「Twitterの1035日・Facebookの1152日」とはすなわちこのネットワーク外部性を「育てるために」要した期間であったと言える。
逆に言えば、このネットワーク外部性を得られなかったサービスは決して成長することは無い。 だからこそどのツール・サービスともネットワーク外部性を獲得するためには血眼になるしスタートアップ時には最大の目標となるし、それは新規事業にとっては宿命的な「呪縛」であるとも言える。

ではLINEは何故256日という期間で成長できたのか。それは「旧来のネットワーク構築をショートカットしてユーザーが急速にメットワーク外部性を享受できる」仕組みを最初から備えていたからだ。
それが「ユーザー端末のアドレス帳情報の送信」である。

アドレス帳収集によるネットワーク構築

今では一応ユーザーの許可を取るようになったが、初期バージョンのLINEでは起動時に「無条件で」サービス側へユーザー端末内のアドレス帳に登録されている「友人・知り合いの電話番号」をすべて送信していた。
LINEではチャットや通話のための識別番号としてユーザーの電話番号(携帯電話番号) をそのまま利用している。ユーザーが単にサービス登録するだけなら自身の電話番号が登録されるだけで、チャットや通話を行うなら、同様に友人や知り合いが登録してきて他のSNSのように検索やフォローなどしなければネットワークは構築されないところだ。つまりこれが一般的な「ネットワーク構築のコスト」となる。
しかし友人のアドレス帳に自分の電話番号が含まれておりあらかじめサービス側に登録されていたならば、初期登録した瞬間に既に「友人・知り合いである可能性の高い」ユーザーネットワークが既に用意されることになる。
最初の頃こそその確率はまだ低くとも、ある程度のユーザー数を超える頃からは従来的なSNSなどのネットワーク成長率との差異は際だって高くなってくるはずだ。ユーザーからすれば「登録すれば(友人を探したりフォローしたりしなくとも)すぐ使える便利なアプリ」と映るだろう。

これこそがLINEが「発明」した「ネットワークを急速に成長させてネットワーク外部性のコストデメリットを回避する」方法論である。
それまでどこも試してこなかった「ネットワーク外部性の呪縛」を解き放す方法としては、(様々な意味において)驚異的と言っていいだろう。当初から意図されていたかどうかは分からない。しかし結果としてLINEの大躍進の大きな原動力となったのでは無いだろうか。

LINEの「発明」におけるプライバシー問題

しかしながら、当然「利用者のアドレス帳情報全てをサービス側へ送信してしまう」=「利用者が友人・知人の電話番号を本人の了解無く勝手に送信してしまう」ことには根強い批判がある。

LINEの個人情報の扱いはちょっと危ないのでは?の話

私がLINEを使わない理由

現在ではアドレス帳情報を送信するかは選択できるようにするなど「対処療法的な」対応はとられたようだが、本質論では無いだろう。
問題はこれまでにも指摘されてきているように「利用者の電話番号では無い第三者の電話番号を他社へ提供するのに、利用者本人の同意で事足りるのか」という問題だ。
これは古いようで新しい問題でもある。つまりスマホ(携帯電話)とは所有者個人の情報の宝庫なだけでは無く、他人の情報の宝庫でもある、ということを改めて知らしめたとも言えるだろう。
更にはこのような「個人が知り得た他者の情報をどこまで利用できるか」というコンセンサスやそもそもの一般的理解としての問題としては認知・議論されていないと感じる。
特に一般ユーザーにおいてこうした問題があり得ることを理解して利用している人たちはどれだけいるだろうか。

個人的にはLINEは本来素晴らしいプロダクトだと感じている。ちょっとしたエンジニアであれば難しくしてしまうチャットやVoIPアプリをここまでシンプルに楽に使えるようにしてユーザー層を格段に広げたこと、スタンプ販売というビジネスモデルはユーザー層に非常にマッチしているしガチャよりはよほど健全であると感じるし、ぜひとも今後のネットサービスの新しい可能性のためにも良い成功例となって欲しいと思っている。
しかしそうであるからこそ、NHN Japanは上記の問題にどう取り組むか、あるいはリカバリー・ケアしていくか、意味の分からないプレスリリースを出している場合では無く、きちんと利用ユーザーへ説明する義務があるはずだ。何より、「ここまで成長してネットワーク外部性問題は乗り越えたのでプライバシー問題は誤魔化し誤魔化し運用すればいい」 といった「勝ち逃げ」「やったもの勝ち」は絶対にあってはならない。「ここまでなら前例が出たので我々もやってもいいだろう」などという風潮(が仮にあるのならば)を業界に残したままにすべきでは無い。
ユーザーとネット全体に正面から向き合ってこその良い成功例となって欲しい。

ネットワーク外部性の呪縛を解き放すには

視点を変えて。
こうしたLINEの妙案若しくは反則技が考え出されるのも、偏に前述した「新規サービスにおけるネットワーク外部性の呪縛」がそれだけ厳しいものだからだ。
「新規ユーザーが集められないサービスが潰れていくのなど今に始まったことでは無い」との意見もあるだろう。
しかし近年においては、GoogleやFacebookの例を挙げるでも無く、新規サービスのスタートアップの優位性は、これら多数のユーザーを抱えるネット企業の動向に左右されすぎているようにも個人的には感じている。例えばSNSにおいては「ソーシャルグラフ」ということになると思うが、より大きなソーシャルグラフを持ったプラットフォームしか通用しなくなりつつあり、以前にも増して新規サービスでのネットワーク構築は困難になりつつあるのでは無いか。
もしLINEでの問題にもこうした背景があり、また故に例えば同じようなプライバシー情報を収集するアプリが今以上に氾濫したり、ユーザー登録を無理に促すためのステルス・マーケティングや他ユーザーにははた迷惑としか思えないリワード広告やアフィリエイトで埋め尽くされる世の中というのも、一般ユーザーとしてはぜひ遠慮願いたい。
既に巨大なソーシャルグラフやネットワークを手に入れた企業がそれを守ろうとするのは競争原理上当然のことではあるが、一方スタートアップの視点からは、「ビッグブラザー」とは言わないまでも様々な可能性のあるプロダクトやサービスがその機能やニーズではなくネットワーク外部性の呪縛のために人知れず退場していくのは実のところ損失であるかも知れない。

巨大なソーシャルグラフやネットワークはサービスでは無く「公平なプラットフォーム」であるべきだ。図らずも、これはティム・バーナーズ=リーの言うところの「閉じたWEB」との戦いであるかも知れない。
「ネットワークやソーシャルグラフはそれを構築した企業の単独所有物だ」という考え方から「フェアユース」「公共資産」という考え方が生まれた時、WEBはまた次の新しい価値を創造できるのでは無いだろうか。

 

 

LINEは何故急成長できたか – LINEの発明の光と闇」への1件のフィードバック

コメントを残す

メールアドレスが公開されることはありません。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください