Quest PM

米系スタートアップで働くプロダクトマネージャー(PM)の姿をサンフランシスコから

「エンジニアのためのマネジメントキャリアパス」をPMの観点で読み解く

f:id:questpm:20181015134014p:plain


及川さん(@takoratta)さんに先日お会いした時におすすめしていただいたこの本。「エンジニアのための」とあるものの、PMの観点で読んでも読み応えがありました。学びのあった部分を一部紹介します。(ちなみに翻訳前のバージョンで読んでいるので洋書ベースの書評になります。)

Strategies for Saying NO (NOというための戦略)

PMは多岐にわたるステークホルダーと仕事をする以上、なんでもYesと言ってしまう八方美人では何も決まらず物事が進まない。Noと言わなければいけない場面も往々にしてある。そんな時どのようにうまくNoというかは非常に需要なコミュンケーションスキルの一つ。本書ではいかのオプションを提示しています。

 

 "Yes, and.."

まずは相手の意向を「Yes」で受け取る。その後に逆説的な表現でYesであるための意味を伝える。例えば、

"Yes, we can do this, and all I need to do is to delay the start of this other project which is currently on the roadmap."

というような表現。訳すと「それならできますよ。自分がしないとけないのはロードマップにある他のプロジェクトのスタートを全て遅らせることです。(-> それはかなり難しいですよね?ちゃんと他のステークホルダーにも相談しました?という裏の意味を含んでいる)」

 

Create policies

Noと言わなければいけない場面が多いのは、その裏返しとしてチームや会社としての「決まりごと」がないとも言える。例えば営業チームが「顧客AがXという新機能を必要としている」からといって、基本的なWhy/Whatや見込める収益も定義せずに提案していては当然PMからNoと言われて致し方ない。

リクエストがあるのなら、それが有効だと理解してもらえる情報群をしっかり集める。どんな情報群が最低限必要なのか、PMによる定義(もしくは会社による定義)がポリシーとなる。一旦これができれば、基本的にリクエストする側もまずはポリシーで決められた情報を集めなければいけない。PMが「XとYとZという情報が集まってから議論しましょう」とリクエストのたびに言う必要がなくなる。

 

"Help me say yes"

これは上のポリシーに近いかもしれない。自分としてはNoと言いたくないけど、Yesと言うためにはあまりにロジックや裏付けが弱いよ、というシグナルを伝えるための表現。そんな時にこの言い方が使える。ただ、その場合PMはYesというための基準がなんなのかを説明する必要があります。

 

Appeal to bugdet

PMがかかわるプロダクトチームの稼働状況について時間的・人的リソースの状況がいかにタイトかを伝えることで、"Not right now"(今はムリ)というシグナルを送るという方法。

逆に、PMから「今はムリ」と言われた側は「いつなら可能なのか」、「リソースをどこからか用意できれば可能なのか」をフォローアップすべし。PMのプライオリティーに関する意思決定を助けてあげれば、Yesと言わせることも可能。

 

Let's work as a team

自分一人でNoと言うより、チームとしての意思決定プロセスを経て決めようというリクエストのリダイレクト。

 

Don't *prevaricate(*言葉を濁す)

Noと言わなければならないのなら、後回しにしない。とはいえ、あまりに先走ってNoと言ってしまったらそれはあとで謝らないといけないケースもあります。ただ、時間価値を考えれば全ての決断マターに時間をかけていくわけにも行かない。であれば、その場を濁して、相手がどうしていいかわからない状況にしてしまうのだけはやめましょう。

 

”Say No"を使いこなすのはPMとしての一つのスキル

同じNoと言うにしても、一方的にはねつけるのではなく相手がアクションしやすいようにNoと言うほうがお互いのためになる。上記以外にも表現のしかたはあると思うが、大事なのは、"Responding positively but articulrating the boundary." 「ポジティブに反応しつつも、どこがYesの境界線なのかしっかり伝える」ということ。PMは「良い人」であるよりも「芯の強さと頭の柔らかさがある人」でいたほうが信頼されるし、結果的に関わる人の生産性があがるのだ。

 

(Strech goal) ぜひ洋書版にもチャレンジを

今回Management Pathを洋書で読んだが、読みやすい英語で書かれていてページ数も200ページくらいと薄い本。なのでそこそこ英語の読解力がある人なら、ちょっと自分にストレッチをかけるだけで読めるはずです。洋書と聞いて「そんなの無理」と避けてしまう前に、部分的に触るだけでもいい。筆者の生の声が読める原書は和訳とは違った学びがあります。つねに広い視野を要求されるPMとして、洋書を読めるようになると自分の知性の世界観が広がりますよ。

 

 日本語版   

 

洋書版

プロダクトマネージャーがすべきプライオリティーづけについて

f:id:questpm:20181006152355j:plain

 

 PMが開発要件に関して「全て大事」と言ってきた。

本当に迷惑ですよね。そのプロダクトを作る際に何が一番大事かを知りたいのに、「全部大事」と言ってくるプロダクトマネージャー。困るんですよ、開発する側から言わせると。当然コストも時間もかかるし、クオリティーを担保するのも一大事。ゴールがとてつもなく遠く見えてしまう。プロダクトチームとしてビジョンに一向に近づかない、枝葉にとらわれて森を見ず、何も進まないという状況に陥ります。PMが「全て」という言葉を使いだしたら、それはそのPMが思考停止していると言ってもいい。こういうことはシリコンバレー企業ではまず起こりえません。それはなぜか?

 

PMがすべき大事な仕事、それはプライオリティーづけ

プロダクトマネージャーはプロダクトの運命を決める人であり、ユーザーエクスペリエンスとそこからあがる収益に責任を持つ人です。それは最初のプランニングから、リリースしてユーザーが定着して収益がついてきて、最終的には次期バーションにユーザーを載せ替えるところまでも場合によっては考えます。

そのEnd to Endのサイクルは短いと数週間、長いと年単位の期間になるもの。当然開発する側からするとサイクルが短かろうが長かろうがScope of Workが適切でなければ作れるものも適切に作れなくなる。GAFAクラスの企業でもなければ潤沢なリソースがないので、必ずどこにフォーカスするのかを決めなければ、プロダクトチームのメンバーも会社自体も「一体PMはどこに向かっているのか?」という疑問を持つことになります。こういう空気が出てきてしまうのはPMとしては負けです。シリコンバレー企業ではPMのこのプライオリティーづけがスタートアップから大企業まで徹底しています。ここをうまくできないPMは評価されない。

だからこそPMは「全て大事」などと軽々しく言うのは間違い。プロダクトチームおよび、会社に対して、その期間はプロダクト開発のどこにフォーカスして何にプラオイリティーを置くかをクリアに伝えなければいけない。

 

プライオリティーづけでPMが意識すること

では「全て大事」と言ってしまうPMの何が問題か?それは「判断の軸」がないこと。優先度を決めるということは個別のアイテムを比べてどちらが上か下かを決めることであり、そのためには判断の軸がなければ無理。自分がこの地でPMを経験してきてひしひしと感じるのは、軸とは「インパクト」につきる。これを分解すると、

1. 短期・長期的に会社として達成したいことへのインパク
2. ユーザーへのインパクト(UI/UX的に。Customer Wow Factorと呼んだりもする。)
3. KPIに対するインパクト(ユーザー継続率や収益性など、どのくらいKPI向上に効果ありそうか)
4. フロントエンド・バックエンドへのインパクト(開発負荷・運用負荷という点で)

が代表的な軸。

PMはこうした軸を使ってプラスのインパクトとマイナスのインパクトのそれぞれの大きさを評価していく。当然マイナスのインパクトが大きければ、対策をするというよりも、一歩引いてそもそもなぜそんなにマイナスのインパクトがあるのかを考える。その結果として開発スコープを変更したり、狭めたりするなどしてインパクトのコントロールを行う。

 

PMがするプライオリティーづけはアートとサイエンスの掛け算である。

上の1,3,4に関して、もし社内でデータ化ができていないのならまずは会社としてこうした部分を数値化することを始めてください。この地のスタートアップも大企業もどの会社もPMがプロダクトに関するデータを自由に取得できる状態です。なのでSQLを叩いてデータ取得して、Pythonで加工してビジュアライズとかも自分も普通にやります。語るならデータなしには語ってはならないというのが徹底しています。

上で言うCustomer Wow Factorは計算で求められるものではないものの、PMがデザイナーと議論して1(low) - 10 (high)の間で感覚でスコアを決める。ここは完全にアートの世界。PMとしてのユーザーに対する理念やセンスが問われるところ。

従いプライオリティーづけは1,3,4のサイエンスの部分と、2のアートの部分の 「掛け算」。どちらかがゼロだとそのプライオリティーづけは裏付けがなくなってしまい、後々なぜそのプライオリティーづけで良かったのか(悪かったのか)きちんとトラックできなくなってしまう。4つの軸がなければどう決めてよいかわからず「全て大事」となるわけだ。

PMの仕事の面白さは0->1を作るだけではない。作ったプロダクトを不確実性の中で進化させ、チームや会社のサポートを正しい方向に導く指揮者となる部分にもある。このプライオリティーづけは多様な知識と経験、アートとサイエンスな洞察力をミックスして行うもの。今までなんとなくプライオリティーを決めていたのであれば、ぜひ上の軸を意識してやってみてください。ステークホルダーの納得感が変わり、何をすべきかがより明確になります。

Silicon Valley Workersさんにインタビューしていただきました

 

 

Silicon Valley Workersというウェブメディアがあるんですが、そこでインタビューされた記事が公開されました。日本からやってきてどのようにシリコンバレー外資の中でPMになり、現地のスタートアップでどんなことを考えてプロダクトマネジメントをしているのかが垣間見れます。グローバルにキャリアを展開してきた一つの事例として読んでみてください。

 

プロダクトマネージャーは攻守の要(ボランチ)だと思う

f:id:questpm:20180716114851j:plain

勝戦はフランスの勝利。その裏にいた立役者

4−2というスコア以上にポグバの活躍がフランスの強さを支えたと思う。ボールを持ったときのエムバペの怖さがクローズアップされがちだが、フィールドを縦横無尽に動き、相手の攻撃の目を潰し、攻めてはパスをつなぎ、時としてエムバペに長距離のパスを何度か成功させた。そして自らもゴールを決めている。

彼の活躍ぶりはプレー時間を示したヒートマップにも現れていた。これはポグバがボールに絡んだエリアを色の濃淡で示したもの。

(ソースはスポーツデータサイエンスで有名なOpta社のデータが出ていたサイト。) 

f:id:questpm:20180716120057p:plain

 

今大会を見ていて、つくづくプロダクトマネージャーってのが攻守の要ボランチとスタイルが一緒だな〜と思わせることがたくさんあった。実はこのメタファーこそPMの理想的な動きを表す一つの格好の事例なのではないかとも思う。今日はそのことについて。

期待はずれどころか、悪い意味で期待通りなアルゼンチン

メッシは選手として好きだが、アルゼンチンには期待していなかった。彼に任せておけば大丈夫という空気が蔓延していたからだ。

アルゼンチン代表はロシアW杯の予選18試合で19ゴール。そのうち1/3はメッシで、残りは他のメンバーだが誰一人3ゴール以上あげたものはいない。(ディマリアが唯一2ゴール。FWのアグエロに至ってはケガもあってゴールなし。)代表124キャップで6度もハットトリックを達成していれば、監督だってチームだって彼に任せたくなる気持ちは当然ある。(Source: Forbes)

だが、今回のW杯の結果を見ての通り、スーパースターが率いるチームは、彼の好不調もしくは相手チームによる封殺や寸断によってチーム力がガタッと落ちてしまうのだ。

なぜなら他のメンバーが自律的に動けず、つねにメッシを探しているから。今回のグループリーグ敗退は順当負けだったのかも知れない。

 

同じことがPMの世界に起こったらどうなるか?

PMは仕事柄、会社のいろんな部署の人と話すし各々やっていることが見える。いろんな情報にアクセスできるし、おのずと集まってくる。それがPMとして全能感に陥り過信になったときが一番危ない。そのPMのやることなすこと当たりまくり、そのPMの言うことに従ってプロダクトを作っていれば大丈夫、そんな「当たっている」ときは良い。だが、外れた時、不調になった時に悲惨になる。自律性を失ったチームはいつまでも不機嫌・不調なPMの顔色をうかがい、どうすべきかクリエイティブな答えを自分たちで見つけ出してチームで議論するということができなくなる。やがてプロダクトチームの誰もPMを信じなくなり、会社の競争力を大きく削ぐことになる。それこそアルゼンチンの二の舞。

 

スタートアップとしては命取りだ。

だからこそあえて言いたい。PMをスター扱いする必要もないし、逆にPMだからといって一方的に上から目線はやめたほうが良い。あくまでプロダクトチームの一人という姿勢は崩さない。キャプテンマークを巻く程度の感覚。PMの成功はプロダクトチームが連動して動き、ユーザーに喜びを提供することであるはず。決めるべきときは率先して決めるが、基本はチームプレイ。

 

PMと攻守の要(ボランチ)の共通点 

そんな姿は日本代表のボランチ柴崎にも重ねて見て取れる。日本の多くの人が感動したベルギー戦。柴崎は攻守に渡ってチームに貢献した。彼の動きを示したヒートマップを見てほしい。

 

f:id:questpm:20180715121101p:plain

(ソースは同じくこのサイトから)

そして、彼が出したパスの位置と受け手のデータ。フィールド全体を使い、様々なポジションにパスを出す視野の広いプレースタイルが見て取れる。

 

f:id:questpm:20180715121105p:plain

 

パス=PMにとってのコミュニケーション

PMの動きもこれに重なる。ある時はマーケとプロダクトのLaunch戦略を、ある時は法務とGDPR対策を、ある時は上層部と長期的なロードマップを、ある時は財務とプロダクトのROIを、PMはボールの受け手(コミュニケーションの受け手)が受け取りやすいパス(=メッセージ)を常に出さなければいけない。

パスをもらった相手が次に動きやすくなければいけないのだ。サッカーで例えるなら、前を向いてボールをもらえる、ポストプレーしやすいように足元に落とす、といったところか。PMで言えば、メッセージをもらった側がその人のポジションの中で何をするかが明確ということ。そのボールをもらって次にどうしろと・・と思われるようではPM失格だ。

 

また、ポグバや柴崎のようにフィールドのどこかに偏るのではなく、試合の状況に応じていろいろなところに顔を出しては味方を助けたり、自分でゴールへ向かう。PMとて同じ。プロダクトチームのメンバーを、そしてサポートしてくれる人たちを孤立させてはいけない。自分が前に出るときは出るし、誰かに出てもらうときにはしっかり後方支援する。

 

これまでの日本代表の中で一番よくボールが周り、ゴールにつながり、チームとしてまとまっていた裏にはこの柴崎の動きが強いアクセントになっていたのは間違いない。そうしたポグバや柴崎の働きに、PMが機能したときのプロダクトチームの躍動感がかなり重なると思った次第でした。

イニエスタクラスのボランチともなると「フィールドの皇帝」と呼ばれるように、PMは「製品のCEO」。そのパフォーマンスはプロダクトチーム全体に、ひいては会社全体に影響する。

PMってどんな動き方をするのが理想?と思ったときに今回の記事が一つの参考になれば幸いです。 

それ何の話だっけ?と言われた人に効く、会話の効率を上げる4つの視点

f:id:questpm:20180422131500j:plain

身近で起こっている働き方改革の足かせ: コミュニケーション

ここ数年ビジネスの世界では、ChatworkやSlack, Skypeなどチャットを使ったコミュニケーションが当たり前になってきました。手軽に会話できるのは良いのですが、同時にチャットだけだと話がこじれてしまう場合もあります。

ことプロダクトマネージャーのような役割だと関わる人が増える一方、自分のコミュニケーションスタイルがそのまま相手にも同じように通用するとは限りません。あるときはほとんど関わったことのない別チームのエンジニアだったり、法務部門や財務部門の非技術系、常に時間のないエグゼクティブなど様々です。

こういう時サクっとチャットで「これお願いします」といったところで、聞いてくれることは殆どいないでしょう。返事がなければ2,3日後にまたフォローアップすればいいんじゃ?と考える人もいると思いますが、実はこの時点であなた自身とメッセージの受け手の生産性を2−3日分失ったことと同じ。「それ何の話しだっけ?」と言われておしまいです。そんなことが毎日どこかで、仮に全社員の50%以上で起こっているとしたら・・・これでは働き方改革どころではありません。

会話の効率を上げる4つの視点

プロジェクトがグローバル化してくると、ここに時差や文化の違いが絡んできてさらにコミュニケーションがうまくいかなくなる場面がでてきます。こうした問題にどう立ち向かうか?

会話の効率を上げる抑えるべき4つの視点とは、

Time
Place
Control
Information processing

です。

この4つの軸には目盛りがあります。

f:id:questpm:20180422144854j:plain


Time軸は相手のチャンネルが最もオープンな時を選ぶ

Time軸で考える際に必要なのは、相手が最も話しを聞いてくれる時間帯はどこかということです。その人は朝方でオフィスに来るのか、遅出で10:30過ぎないとこないのか、夜は社内に残る方かそうでないか、などです。相手が受け取りやすい時間帯でないと、後回しにされます。


Place軸は残したいメッセージのインパクトに応じて決める

どうしても相手に理解しておいてもらいたい、ならばメールを送って済ますのはやめましょう。ちゃんと電話やビデオ会議を予定すべきです。(対面が可能な場合はそれもありです)チャットはしょっちゅうやりとりしている人たちであれば最速で効率は抜群ですが、こちらはとても重要だと思っているのに、相手が同じレベルで感じてくれない、インパクトが残らない可能性があります。またあまり顔見知りでない人、込み入った話しの場合は一度はPlace軸のレベルをあげましょう。(メール・チャットより電話会議、ビデオ会議より対面といった形)

 

Control軸は「仕切りたい」度合いの差

何かをお願いする時に、「それ自分に預けてもらえますか?」というケースと、「一緒にやりましょう」、もしくは「そちらでやってしまってOKです」といった「仕切り」の度合いが異なる場合がある。仕事の性質上だけではなく、その人のキャラ的にその仕切り度合いが変わってくることもあるのだ。抱えたい人、サボりがちなのでこっちでやったほうが(コントロールした方が)良い人など様々です。このあたりの見極めを間違えると、余計に時間がかかってしまうことになります。


Information Processing軸は相手の情報処理能力の速さ

コミュニケーションする相手がどれだけ情報処理能力がある人なのかも重要な要素。例えば相手がプリントアウトしてじっくり読んでからでないと反応できない人なのか、ランチオンミーティングで諸々説明したらすぐに分かってくれるような人なのか、もしくはチャットで少し話せばすぐに答えてくれるのか、情報処理能力の速さは、単に頭の回転という意味だけではなく、相手と共有している文脈の多寡も影響してきます。

 

ゴールはCommunication Costを最小化し、インパクトを最大化すること

 ごく当たり前に行っているビジネス活動も、コストの上に成り立っています。全てのコストが悪いということはありませんが、プロフェショナルとして働くのなら少なくとも無駄なコストを最小化する行動はあって然るべきです。

コミュニケーションは当たり前のように行われるがゆえに、簡単に見落としがちなもの。実は無駄が簡単に発生しやすいのです。そのおかげでお互いの生産性が下がるということはコミュニケーションコストが高いということ。

しかし上記4点の視点を意識すれば、明日からでもコミニケーションコストがどんどん下がり、仕事が効率よく周る(仕事のインパクトが上がる)ようになるはずです。ぜひやってみてください!

知らないと痛い目にあう、5Gを使ったアプリ開発 - Part 2

http://hanabi.autoweek.com/sites/default/files/styles/gen-1200-675/public/3-byton-shared-experience-display-1.jpg?itok=xSMeXfOz

5G時代を見据えたByton社のConnected car (Autoweekより)

 

5Gの何がすごいのか(後編)

前回の記事をご覧になっていなければ↓からどうぞ。

questpm.hatenablog.com


5G以前のネットワークアーキテクチャーだと遅延やデータロスの影響をモロに受けるという話しをしました。では5G以降はどうなるか?早速下の図を見てみましょう。

 5G後

f:id:questpm:20180318132946j:plain

 

お気づきになったと思うが、5Gの無線施設のそばにエッジコンピューティングサイトができている。これこそが5Gのキモ。エッジコンピューティングサイトはある種の小規模データセンターです。通信キャリアにとって5Gを導入するといのは、こうしたサイトをアプリ開発者や利用者のために準備するということでもある。逆に言えば5Gを利用したアプリというのはこうしたエッジコンピューティングサイトでアプリのバックエンドを動かすことにほかならない。ユーザーからすれば、この存在のおかげで遠く離れたデータセンターやクラウド環境へアクセスする頻度は少なくて済むということ。(その分体感速度は大幅に上がる)

 

ちなみに実際のエッジコンピューティングサイトは以下の写真のような感じ。 

http://www.datacenterknowledge.com/sites/datacenterknowledge.com/files/styles/article_featured_retina/public/Vapor%20Edge%20Module%20Photo%20Cell%20Site.png?itok=QFV2f6-7

奥の塔が5Gの電波塔、手前がVaporIO社のエッジコンピューティング施設 (Datacenter Knowledgeサイトより)

 

従って5G以前と比べてこのアーキテクチャーのなにが優れているかというと、ユーザーの端末から上の図の右端のデータセンターやクラウドサービスへのアクセスで発生する遅延やデータロスを大幅に減らせるというところになる。

 

5Gを使ったアプリを作るために知っておくべきこと

モバイルアプリ開発者にとって魅力的に見える5Gだが、重要な制約条件がある。それはエッジコンピューティングサイトから端末までの距離だ。あくまでこの距離と5Gで対応可能な電波の範囲でパフォーマンスが決まる。

例えばUSの通信キャリアは都市圏にいくつかのエッジコンピューティングサイトを設けるようなので、そこを勘案するとそのサイトから50−100キロ圏内が5−10−100の5Gのパフォーマンス範囲ということになる。

逆に言うと5Gだ、10Gbpsだと盲目的に信じたところで日本からインド、日本からUSが5ms以下の遅延になるわけではない。地球の裏側のいるユーザーとリアルタイムで高解像度なVRアプリを動かすのは、5G環境になったとしてもかなりコストのかかる話なのは変わりはないのだ。

 

ドイツテレコムの事例 - ヒトの体に医療情報をリアルタイムで表示

https://lh3.googleusercontent.com/KtNS2wMeacQufsdpviNgTxzOldMmgFlAbkySuVhFsANN7E40p6hxpanUagkaR0AfWZ0-xHVY4rIaZMz0kWuMnkSxG-OjeQ3LwRKlxmWJIbSPmLhva6Y50xhN8CL4SR1e4_3rwH42Cw=w2400

 

先月末に行われたMobile World Congressでは各キャリアが5Gのユースケースを展示。上の写真はドイツテレコムによる医療現場で使われるユースケースの例。マネキンに対して5G端末をかざすと、その患者の身体内の情報が4Kの解像度でリアルタイムで配信される。

端末は体の3次元座標をカメラから認識し、この位置情報を送信。エッジコンピューティング側で画像をレンダリングし、端末へ高精細画像を送り返している。ネットワークの遅延が極端に低いので背中側にまわれば背中側からみた情報がきっちり表示され、ゆらしても素早く動かしても残像がでることはなく常に高画質だった。要は手元の端末が、ハイスペックなマシンと直接つながっているようなイメージ。

 

4Gから5Gへの進化が意味するもの - Experience Divide

5G時代を迎えるにあたってもう一つアプリケーション開発をする側が意識しておくべきことがある。それは「5Gデバイスを持つ者」と、「持たざる者」におこるユーザーエクスペリエンスの大きな差だ。私はこれをExperience Divideと呼んでいる。2回にわたって解説したように、5Gはアプリケーションのユースケースに大きな変化をもたらす。だが、それにアクセスできるのは当然5G端末を持っている人だけだ。

そのアプリが対象とするマーケットにもよるが、もしグローバルにアプリを展開するとなると、当然5Gデバイスを手に入れられないセグメントがでてくる。だがそういうユーザーも自社にとっては大切なユーザーには変わりない。そうなった時にアプリ開発側として5Gを持つものと持たざる者、そして持つものへと移行していくユーザーに対してどうユーザーエクスペリエンスを定義していくかは、ユーザーに使い続けてもらうアプリになるために重要な視点。

今年末から2019年にかけてUSや中東では5Gが商用化される。一方日本は2020年。まだ「先の話し」とたかをくくっていると、先行するUSの企業にまたしても市場を席巻されてしまいかねない。そうなっては遅い。今のうちから議論を始めておくことをおすすめします。

知らないと痛い目にあう、5Gを使ったアプリ開発 - Part 1

f:id:questpm:20180318130026j:plain

 

 

5Gの何がすごいのか

昨年から今年にかけておそらく5Gに関するニュースを見たり聞いたりしたことがある人は多いはず。ただ5G の何が今までと比べてすごいのか、5Gを利用するにあたって何に気をつけなければいけないのかをきちんと理解しているアプリ開発者は意外と少ないと感じた。なので今回はそのあたりをプロダクト開発の視点で2回に分けて解説します。

 

"5-10-100"  5Gの特徴3つ

5Gの特徴は大きく分けて3つ。低遅延・広帯域・同時接続性です。

遅延は5ms以下、帯域は最大10Gbpsまで、最大同時接続数は100万台サポート可能。
これだけだとピンとこない人がいるかもしれないので例をあげます。

例えばブルーレイDVDは1枚25ギガバイト分の動画容量あるが、5G対応デバイスはこれを3秒以内にダウンロードを終えてしまうことになる。これを4G/LTEでやろうとすると1時間以上かかってしまう。

次に遅延。使っているストリーミングサービスが海外サーバーへアクセスしていると、ひどい時は動画が止まってしまったり、画像と音声にズレがでたり、ローディングの画面からなかなか先に進まない、という経験をされたことはあるはず。これはネットワーク上の遅延が大きく関わっている。例えば日本からカリフォルニアにあるサーバーにアクセスしようとすると、それだけで120 - 200ms程度の遅延が発生する。低遅延というのはこうしたデータ転送のずれがほぼなくなり、データの出し手と受け手の時間の差がゼロに近づくということだ。

最大同時接続数は、一つの電波施設で処理できる端末の数。4Gだと4000台が限界だが、これが5Gになると100万台に一気に増加。ま、100万台全てが同時に25GBのダウンロードをすることは想定していないものの、これまでより高速でサクサクアプリが動くネットワーク環境を、多くのデバイスが同時に使えるとは言える。

 

なぜ低遅延、広帯域が実現できるのか?

上の3点の優位性がなぜ可能になったのか、モバイルアプリ開発の上で5Gの仕組みを理解しておくことはテクノロジーを正しく使うために重要。なぜなら往々にして優位性は制約条件とのトレードオフであることが多いから。その部分を正しく理解せずして5Gを使いこなすことはできない。なのでまずは5G前と5G後で何がどう変わるのかを比較してみます。

 

5G前

5G以前は、スマホでモバイルアプリを使ったり、ウェブサイトにアクセスするときにはキャリア側のネットワークやデータセンター、そこから別のインターネットを経由してAWSGCPなどでホストされているサービスを使うことになる(下の図参照)。この場合アクセス先の距離によって、直接遅延やデータロスの影響を受けることになる。

f:id:questpm:20180318132710j:plain

もちろん遅延の影響を最小化する工夫をアプリ上で仕込むことは可能。(オンラインゲームはその典型)だが、もともと4Gは通常でもダウンロードで2−12Mbps、最大でも45-50Mbpsでれば上等というレベル。(Verizonの調査より)5Gのベスト時と比べれば1/200くらいのパフォーマンスしかない。

下のグラフは、もともと45Mbpsの帯域が4G環境で使えたとして、そこに遅延やデータのロスが発生した場合体感速度がとこまで落ちるかを表したもの。ここでは、縦軸のMaximum Throughputが体感速度とここでは思っていただいていい。50msの遅延とデータ送受信の際にロスが0.01%発生しただけで体感速度は半分以下に。200msだとおよそ1/9まで落ちる。 

http://www.aryaka.com/wp-content/uploads/2015/03/packet-loss-percentage.png

(Aryaka社のサイトより)

 

なので上の5G以前のアーキテクチャーだと、遅延やデータロスの影響を直に受けることになり、例えばVRベースのアプリを8Kレベルの解像度のストリーミングで流すといったことは、ネットワークがボトルネックとなり非常に開発が困難なのだ。

こうした遅延やデータロスの影響をなくすために、5Gではアーキテクチャーのどこを変えたのか、そしてそれがどうモバイルアプリ開発に影響してくるかを次回解説します。