②基本的なプレイユニットを突き詰める|ネットワーク環境|Splatoon アーキテクチャ・デザインパターン

この回からは、単独プレイヤーに向けたデザインパターンを考えます。
それはチーム戦においても、チームメンバーひとりひとりが使う基本的なプレイユニットに着目して仕様を突き詰めていくことに他ならず、プレイ環境上では最も大切な要素になります。

単独プレイヤーに向けたデザインパターン(基本的なプレイユニットを突き詰める)

1人のプレイヤーがSplatoonをプレイするための環境をプレイユニットと呼びましょう。
これをどう突き詰めていくか、が今回のテーマです。

今回のテーマで重要な突き詰め要素は

  • 数ms(ミリ秒)に向き合うために
  • 操作精度と戦う
  • 状況把握精度と戦う
  • 最適な機材の入手方法
  • 振り返りという武器を手に入れる
  • 可能な限りシンプルに(何を捨て、何を得るか)

です。たくさんありますね。
ひとつひとつ紐解いていましょう。

数msに向き合うために

これは、最もベーシックであり、どのプレイヤーも最初に解決策に目を向けるべき項目です。
Splatoon、しいてはNintendo Swtichを取り巻く数msのロス原因を探り、解決方針を出していきましょう。

ホームネットワーク

これは、最もリーズナブルに解決できる可能性が高いポイントの一つです。
ネットワークにおいて、気にすべき項目は、優先度順に安定性・応答速度・回線速度です。
もしあなたの家が以下に示す様な条件下のネットワーク回線を利用してSplatoonをプレイしているならば、あなたが勝てない可能性の10%程度はネットワーク回線が握っているかもしれません。

  • 安定性 :回線落ちしないためには、安定性の高いホームネットワークへの接続方法が必要です
  • 応答速度:あなたが行なった操作を少しでも早くサーバーに届けるために、できるだけ応答速度の速い方法でホームネットワークに接続する必要があります
  • 回線速度:Splatoonに限って言えば、回線自体の通信速度は上り・下りとも1Mbpsも出ていれば十分と言われています。(実測もそのくらい)これを下回る回線を探す方が現代の日本では大変なので、無視していい観点かもしれません。

応答速度の考え方と、目標性能値

FPSプレイ時の目安として、 20ms前後 に総合的なタイムラグを押さえておきたい、という一つの目標があります。

スプラトゥーン2の為にプロバイダをBIGLOBEに変えた


では、FPSのプレイ時の目安として

可能なら20ms、許せるのは40ms、70ms以上ならラグがあるって感じだったかな?

と語っています。

ラグがあると弾が当たってないのにやられたり、自インクの中から敵が出てきたりする。

恐ろしいと思いませんか。心当たりはありませんか。
快適なプレイ環境ができているかの指標として応答速度は大切なのです。
※ちなみに20ms付近はインターネット広告システムの一部に使われるデファクト的な目標応答速度としても知られています。このあたり見ると参考になるかな。

https://books.google.co.jp/books?id=7iD9B10c1A8C&pg=PA530&lpg=PA530&dq=DSP+20ms&source=bl&ots=DCvk6eNhhU&sig=YkUq3sOYQhjoiAO-kDofv_BGslQ&hl=ja&sa=X&ved=2ahUKEwiyotPW6_3cAhWKWrwKHdkJAJ0Q6AEwBnoECAMQAQ#v=onepage&q=DSP%2020ms&f=false

また、このブログでは、ネットワークに関する視点を以下の3つに捉えています。
http://kanai6274.blogspot.com/2017/03/splatoon2.html

  • End-to-Endで有線・固定回線であること
  • 回線速度 上り下り 1Mbps が、常にでること
  • 対戦相手とのRTT(*)が常に低いこと(目安は50ミリ秒以下)

上記は非常に良い整理です。
また、同じ記事内のRTTとpingの考え方の違いも重要ですのでおさらいしておきましょう。

(*)RTTとは、Round-Trip Timeのことで、自分が発したパケットが相手に届いて、それがまた自分に帰ってくるまでの時間(ミリ秒)のことです。一部の方は「ping値」と言ったりしていますが、これは誤用ですのでやめましょう。pingとはRTTを測定するツールの名前です。
RTT = アプリケーション遅延 + 伝送遅延(ルータ処理) + 伝搬遅延(光ファイバ) + キューイング遅延 で表されます。

この記事ではRTTの優劣を図る身近な基準であるping値を参考に、各セクションでの最適化方針を探っていきましょう。

有線LAN接続を導入する

Switchを無線LANに接続していて、さらにその無線LANルータが古めの規格のものである場合、Switch – ルーター間の接続を有線接続に切り替えることで応答速度が改善する場合があります。

ゲーミングPCは無線と有線どちらで繋ぐべきか


では、

一昔前は有線なら100MBで10Pingなのに、無線だと6MBで50Pingみたいな感じだったのですが…無線規格の進化により、少なくともPing応答速度が明らかに遅すぎるという事はありません。

というコメントを書いています。
最近の無線規格であればあるほどその差は小さいですが、有意な差があることは明確です。
また加えて回線の 安定性 が増し「回線落ちが格段に減る」というのが有線の何者にも代えがたいメリットです。

最近のネットワーク接続規格を見てみると、回線速度は有線よりも速い!みたいな規格がざらにあり、時には有線にした方が数値上遅い、ということもありますが、最初に言った通り、 回線速度 はネットワークFPSにおいてはどの規格も十分に速いので、その違いは無視できることもお伝えしておきます。
あくまでこのセクションで補強する重要な要素は 応答速度安定性 なのです。

★有線LAN接続機器はこれが良さそう
ギガビット対応USB-LANアダプタ
https://www.amazon.co.jp/dp/B00VSGJ7BI/

IPoE系光の固定回線を導入する

まずはじめに、ネットワーク回線そのものの方式を考えると、答えはひとつ、理想はフレッツに代表されるIPoE系の固定回線です。
この環境にて、ネットワーク遅延の指標に用いられるping値は
9〜20ms程度
です。これが、家庭における目指すべきネットワーク環境のMAXとなります。

この固定の光回線に比べて、その他の環境がいかに我々を不利にさせているかを見てみましょう。

この記事をご覧ください。
スマホのテザリングや、WiMAXなど、無線通信系のping値について触れています。
https://ワイmax.com/netgame/
ping値は50〜70ms程度
です。我々が目指す応答速度の3〜7倍近い差があります。
相手の操作が反映されるまでの時間が、環境強者の3〜7倍あるということです。

また、他の通信形式も並べてみますと、概ね次のような感じです。

IPoE系光回線 > 非IPoE系光回線 > USENなどの集中コントロール型光回線 > ADSL > 大手モバイルルーター系・WiMAX・スマホテザリング

この状況を改善するには、やはりより品質の高い回線方式と、プロバイダを選ぶべきです。

同じ光回線でも、IPoE系光回線、非IPoE系光回線、USENなどの集中コントロール型光回線 は応答速度の観点から言うと別物です。
MVNOの回線がネイティブ御三家に比べてワンテンポ分モッサリするのと宿命的理屈は似ていて、通信経路の中継キャラクターが多い分不利なのです。

★応答速度で光回線を選ぶなら、やっぱりNTTのお膝元になってしまう。どうしても。
BIGLOBEの光回線
https://www.b-hikari.com/

追記:Gaming+というESports専用を謳っている回線を発見しました。
これも僕は使って見たことはないですが、IPv4 over IPv6 IPoE方式を利用しています。
さらなる高みを目指す方は試す価値があるんじゃないでしょうか。
https://www.gaming-plus.net

ちなみに我が家の通信環境はこんな感じです。(計測はSPEED TESTが便利です)

BIGLOBEやソフトバンク光などと同じく、プロバイダを介さない IPv4 ovre IPv6 IPoE のauひかりです。
これにGoogle WiFiの3台メッシュの構成です。

マンションタイプで無線接続PCからの計測なので、少し上乗せされている事を鑑みると結構頑張ってると思います。

さて、いきなり骨の折れる改善案も出てきているかとは思いますが、該当する方は、これらを解決するだけでもかなりストレスが減るかと思います。
上記を全て満たした同士の対戦であれば、通信経路的にはこのような感じ。

数msへの向き合い方はまだあります。
次回はネットワーク以外の数msへの向き合い方を考えます。

Makuakeで一緒にエンジニアリングしませんか。
https://www.wantedly.com/companies/makuake?ql=gaJpZM4ATBNM

Splatoon アーキテクチャ・デザインパターン①Splatoonの基本的な世界観

これはSplatoonのための記事ですが、Splatoonのプレイが上達するためのヒントを与えるものではありません。
SplatoonをはじめとしたFPSはゲーム環境を整えていく過程もまた非常にアーキテクティブで楽しい工程なので、そんな点に着目しました。
このテーマは、事業におけるプロダクト構想や、事業ドメインの観察から見出すアーキテクチャの設計方針などの工程と、非常に良く似ています。
ちょうど仕事上の役目がそんなですから、頭の体操にと書きはじめたシリーズです。
とりあえず、飽きるまで書いてみます。

Splatoonの基本的な世界観

Splatoon上では「オンラインで世界の誰かと戦う、もしくは協力する。」という非常にわかりやすい世界観が展開されています。
世界観の基本的な構築要素は以下の通りです。(ストーリーモードは除く)

  • 基本的にチーム行動。4人1チーム。
  • 単独参加の場合は4人のそれぞれ単独の参加者が自動的にマッチングしてチームを結成
  • ペア参加の場合は2ペアがマッチングしてチームを形成
  • チーム対戦は1:1で、複数チームが同じステージで同時に対戦することはない
  • ステージはすべて対面対象

また、バトル参加者にはタイムアップの概念は存在しても、死んでゲームオーバーという概念は存在しません。
バトルに参加した場合は不幸にも撃ち抜かれて死んでも何度でも蘇りながら、時間いっぱいその場を楽しむことになります。
バトルには以下のバリエーションの明確な目的が設定され、チームはその目的の達成のために、それぞれの役割を精一杯こなし、勝利を目指すことになります。

  • ナワバリバトル(3分):時間内により多くの面積を塗ったほうが勝利
  • ガチヤグラ(5分):乗ると進むヤグラを、設定されたゴールまで進めると勝利
  • ガチホコ(5分):メガ粒子砲の様なものを発射できるホコを持ち、相手陣地の奥にあるホコ台まで運べば勝利
  • ガチエリア(5分):指定されたエリアを一定時間、一定面積以上塗りつぶし続けられたら勝利
  • ガチアサリ(5分):アサリを10個集めるとできるデカアサリでゴール膜を破り、一定以上のアサリをゴールに放り込めたら勝利

シンプルな目的を達成するためのバトルをひたすらループし続けるだけのゲームですが、
世界のNintendoが何年にもわたって改良し続けてきただけあって、バトルの進行は非常に刹那的かつ戦略的であるにも関わらず、ものの3〜5分で結果が出るという子気味良いサイクルも相まって、非常に中毒性があります。
うちの妻はほとんど子供の頃にゲームをやってこなかったにも関わらず、Minecraftに次いでこのゲームにどっぷりはまってしまいました。

この凝縮された世界観をどのくらい濃く楽しむことができるかは、ゲーム環境にかかっています。
シビアなFPSはどれもそうですが、数msのタイムラグが勝敗を分ける世界です。
突き詰めれば突き詰めるほど、オンライン越しには見えない有利な環境を作り出すことができます。
上記の様なテーマ、我々エンジニアの出番だと思いませんか。

突き詰めの要素は様々ですが、このシリーズでは以下のどれかにフォーカスした様なテーマを取り扱います。
書きながらやっていますので、こんなテーマに着目してほしい、などあればリクエストもらえたら検討します。

  • 数ms(ミリ秒)に向き合うために
  • 操作精度と戦う
  • 状況把握精度と戦う
  • チーム・コミュニケーション
  • 最適な機材の入手方法
  • 振り返りという武器を手に入れる
  • 可能な限りシンプルに(何を捨て、何を得るか)

次回からは単独プレイに関する環境を考えます。

ところで、Makuakeで一緒にエンジニアリングしませんか。
https://www.wantedly.com/companies/makuake?ql=gaJpZM4ATBNM

Google I/Oのキーノートを見た感想としては

Google I/Oのキーノートを見た感想としては、Google自体の潮流は去年に引き続きAR/VR/AIからそんなにずれていない。

直接的な詳細は各所の記事が語るところですが、AIアプローチ自体はGoogle Assistantsのcontinuous communicationや、Google Newsに回帰してのsuggestion推しに見られように、AIのアウトプットバリエーションを次から次へと試している、というのが印象的で、aiは会話はセルフメイクできるようになったもののそれだけではレスポンスの表現方法として不十分で、今はYoutubeや画像検索で持ってこれる既存の世の中にあるコンテンツをサジェストする形でそれ以外のレスポンスを提供していますが、これがサジェスト同士の組み合わせに進化し、いずれ言語以外のアウトプットレスポンスも自己生成出来るような未来を見据えているんじゃないかというような内容でした。

Android Pなどもそういったアプローチの一部かなという気がしていて、GoogleはDigital Adsをやってサジェストの基盤を作り、Youtubeで最も集めにくいと言われた動画コンテンツを集め続け、Androidでユーザーに最も近い距離から語りかけて意見を聞くことができるような端末を普及させたわけで、逆三角形組織の中でその辻褄の合わせ方、これまでのアセットのひとつひとつを関連づける形で意味を持たせて組み立てて行くkeynoteの感じはさすが、の一言でした。
Tech conferenceではやはりFirebaseの進化が見逃せない話題になりそうな感触です。

Silicon Valley自体は投資家の興味も含めてblockchain側に移行しつつあるようだったのでGoogleはどう出るのか、というのは気になる点だったのですが、今のところ表側は我関せずを決め込んでいました。
相変わらず、やるなあ、といった印象です。

全体的に、あくまで表側のキャッチーアプローチのみの話です。
しかし、呆れるくらい天気が良かった。ほんと大好きだなー。あの土地。

今回は滞在先のエンジニア達にも感謝と敬意を評して英訳も載せます。

Share the impression of seeing Google I / O first day.
The tide of Google itself has not changed from AR / VR / AI as last year.

Direct commentary will be left to articles in various places.
The AI ​​approach

  • Google Assistants’ continuous communication
  • Returning to Google News to revive suggestion channel

It was impressive that I tried output variations of AI from next to next such as.
AI can now create a conversation by itself, but that alone is insufficient as a way of expressing responses.
Currently it offers a response other than words by suggesting existing content that is brought up on Youtube videos and image search, but this evolved into a combination of content that was subsequently suggested, and output other than language I felt that I was looking at the future that I could self-generate responses.

I think that Android P and others are part of such approach.

  • Google did the Digital Ads and made the foundation for the suggestion
  • Continued collecting the most difficult to collect video content on Youtube
  • Spreads devices that can speak from the nearest distance to Android users

The feeling of keynote, which seems to have assembled with meaning in a way to associate each one of the assets so far in the retrograde trial organization of the product in the retrofitting strategy of the product was one word of truth.

At the Tech conference, it seems that the evolution of Firebase can be a topic that can not be overlooked again.
Design Accessibility, and AR, we seemed to be aiming for a dashboard platform that expresses “how technology is becoming more friendly to people” on the basis of keywords.

Silicon Valley itself seemed to be shifting to blockchain side including investor’s interest.
Google was wondering what kind of feature it will prepare in this conference.
For the moment I decided not participating in the front side.

However, the weather is amazing enough.

I am poor at English, so I wrote it as sentences.

最適化された開発プロセスの都合でプロダクト戦略を導き出すことの限界

今回のMountain View滞在のメインテーマはITの巨人のプレゼンテーション方針を探りに行く、なのだけど、サブのテーマとして、世界観の導線に合わせた開発プロセスの答えを見つけにくる、というのも含まれていました。
「最適化された開発プロセスの都合でプロダクト戦略を導き出すことの限界」
が今回のキーワードです。
今回SFOの名村さんや宿泊したスタートアップシェアハウスのエンジニアや事業かとの話などを受けて、ちょっと考察が進んだので書いてみようと思います。

まず開発プロセスを最適化し、それに基づいてプロダクト戦略を決める、というアプローチの凝り固まりやすさ

アジャイルという言葉に引きずられて『プロダクトオーナーは開発プロセスを理解して、プロダクト戦略を引くべきだ』という方向へ極端に引っ張られてるチームを昨年くらいまで本当によく見ました。
言葉を変えると作り手の基準に合わせることでチームの生産性(=市場における攻撃力)を最大化しようという観点を最大限重視した解釈でしょう。
これはプロダクト戦略の内面を重視したアプローチで、チームのアセットへの深い理解や、一人一人の生産性を役割分担の最適化によって限界までチューニングすることでこのアプローチの成果は最大化されますが、実のところそこまでやっているチームはあまり見かけません。
そしてこの方針をとる事業チームの中の開発チームが持つ特徴として、一度手にした一見効率的な開発プロセスに固執しがちなことが挙げられます。
ASAP出力型のスクラム開発チームと事業計画が噛み合わない、などが非常にいい例で、初期開発をできるだけ早く終わらせるべきフェーズや、ABテストサイクルなどを用いた改善プロセスによってできるだけ短時間である指標を引き上げるべきフェーズなどで用いられるべきASAP出力型スクラムを、逆にそれ以外のフェーズで適用してしまったケースです。
イベントに合わせた機能リリースやリニューアル、といったプロジェクトをスクラムで開始しているような場合は、スクラムのスケジュール調整がスプリント単位でしか行えない(ので、遅れるときはスプリント分盛大に遅れる、などがあり得る)ことを十分に理解した上で適用しなければなりません。

とはいえ、開発チームはスクラムというスタイルを身につけてはおくべきだと僕は考えています。
スクラムはその仕組みやフローへの制約が非常に強力で、コミュニケーションのヘルシーささえ仕組みでカバーしようという試みの元に生まれ、ブラッシュアップされ続けているものなので、どんなに深刻なスランプに陥ってしまい、出力が出なくなってしまったチームでも、一旦初心に帰ってスクラムを組むことで、自分たちのペースを取り戻すことができるからです。
これを自己的にできるというのは、チームにとって大きな力となりますし、これ以上プリミティブで強力なフローを他に見たことがありません。
また、スクラムの出力はあくまで「標準」と捉えるべきです。
なのでスクラムを身につけたチームは、それに固執することなくそれよりチームに合ったやり方をどんどん探しにいくべきですが、それについてはまた時期を改めて書こうと思います。

このように、生産性を最大化した強固な開発プロセスを作り上げ、それを軸にプロダクト戦略を導き出していくことは悪いことではありませんが、非常に諸刃の剣感があることを忘れないでおきたいものです。

事業推進上の危険

ではなぜこうした強固な開発プロセスを基軸に事業を進めることが危険なのか、というのが次のテーマです。
答えを言うと市場自体がそんなに静的なものではなく、よっぽど動的な性質を持っていて、それに対してプロセスや生産性をチューニングしすぎるのは「身動きが取れなくなる」という点で危険だからです。
そして、これは案外誰もが察しています。
この感覚は明確にそうだと感じることができる人は少ないですが、言語として表すことはできないが、プロダクト戦略を引くときにどうも拭いきれない小さな違和感として常に付きまといます。

一方、逆の極端な例として、プロダクト戦略の外面、つまり事業計画城のスケジュールによって開発フェーズを組むやり方は、ここ数年意識の高い開発者の中では悪として捉えられてきました。
これら、それぞれ端側(事業と開発)の意志は
「ユーザーに届ける体験と、それによってユーザーが感じる世界観の推移を注意深く洞察し、それに合わせてプロダクト開発計画や事業計画が適切に見直される」
という触媒をもって接続されるのが望ましく、Goodpatchなどが国内にも影響を与えて潮流として認識されたUXドリブンや、昨年あたりから輸入され始めたUX Researchといった考え方がその役目を担うのではないかと期待され、実際に西側諸国ではそれが機能しつつあります。
国内も本来的には是正(外面と内面の重要性の認識バランスが取れてくる)されてくるはずだと思うのですが、そのUXの考え方自体が、話題にはなるがなかなか浸透しないという状況も併せ持って、推進が遅れている印象です。
これは非常にもったいない状況だと考えています。

なぜUXが大切なのか?と、それが浸透しないのはなぜか?

事業チームにおけるUX / UX Reseachは「その変更によってユーザーにどう言う影響を与え、その結果提供している世界観はどうなったのか」に常に注目しながら開発や事業を推進していくという思想から来たやり方です。
それがなかった頃の事業体では、開発チームの執り行うデータ解析や、事業チームが執り行う市場解析の結果に基づいた仮説ベースで方針を決定していました。これらをマージする役目がいなかったために、うまいこと回らなかったのです。
UXはそのマージを担うことがミッションであるとも言い換えられます。だから、UXのプロフェッショナビリティは言うまでもなくInsight(洞察力)です。PMがその役を担う場合もありますが、事業全体が30人を超えてくるくらいの規模で適切にデータを集めている開発チームと事業チームを持つ事業体では、一人で取り扱える情報量を超えてきます。そうなると、Dirやデータアナリスト、マーケターなどとの協業を経て初めて十分な検討ができるという感じです。

浸透しない理由は、僕が浸透しなかった組織にいた頃の経験を振り返ると「その入門編みたいなことをチームの誰かがやっていて、入門なりの答えを出している」からです。

結果それらの活動はちょっとずつ興味や専門性を持ったDirやマーケターによってバラバラに行われ、それぞれバラバラな結論を出すのですが、一応結露自体は導き出せてはいるので、その洞察をとりまとめる役の重要性を理解できない、ということなのだろうと思います。
ただ人材のパワーが限られるチームの中でこの「間違えないための取り組み」が成果を上げてきているチームが数少ないながら存在することが示すように、この取り組みは未来を見据えると絶対に必須です。

アジャイルをもう一回考え直す

本来、アジャイルという言葉はそもそもそういう社会状況に対するすばしっこさを諦めない、という意思を表す言葉でした。
日本語翻訳された

  • 小さなチーム&大きな仕事
  • アジャイルサムライ
  • SPRINT
  • How Google Works

などを読んでいて微妙にアプローチのズレを感じるのは主にそのためで、これらは「なぜチームはそのプロセスに至ったのか?」という前提を「その時々の成功者を観察した結果の一般的な成功者モデル」に置き換えることですっ飛ばして、完成度の高いプロセスを解説することに重点を置いているからです。
本当はプロセスが完成するまでのプロセス論が非常に大切なのですが、これの構築には幾度のチャレンジと長い時間がかかるので、なかなかそれを実践し切れている企業はありません。

今の国内でもよくできたエンジニアリングチームは本当にプロセス最適化がうまいし、大抵の状況に対しての最適なプロセスを
「プロダクトを通じて表出する世界観の導きステップをどう設計するか、」
に合わせて柔軟に編み出します。
幾度もビジネス状況に合わせてプロセスを組み替えた経験のあるチームでないとなかなかできないのですが、この力こそ変化が速く見える世界で開発チームが戦い続けるための本当の力であると、僕は考えています。

みんなで、がんばろう。

サービスやプロダクトが持つ20%のベネフィットと80%のリカバリの役割分担について

様々なサービスやプロダクトを開発してきた実体験をまとめるシリーズです。
後から考えればそうだったな。どうしてあの時は気づかなかった、もしくは意図せずやってたんだろうな、ということばかりで、また同じ間違いや無作為な開発をしないようにしようという自戒を込めています。
これらの自戒は去年、シリコンバレーやベルリン、深圳などに訪れ、異なる文化背景を持つ人たちの開発スタイルや物の考え方に触れたりすることである程度のまとまりを得ました。
ポイントはたくさんあるので、時間を見つけては少しずつ書いていこうと思います。

今回のテーマは、サービスやプロダクトが持つ20%と80%の役割分担(チームワーク)の話です。
※この割合はサービス毎に違うかもしれません。

これはサービスが内包する機能の割合です

よく最近、プロダクト・マネジメントを行う前段の準備として必要なことを解説するのにこんな表を使います。
プロダクトの各種機能には役割があって、それをどういう切り口で分割しようか、という話です。
あるBtoBtoCサービスではこんな感じになりました。

この表自体はプロダクトの機能を役割分離したものですが、この整理はサービスの機能を見渡して整理する時にも使うことができます。
これによって見えるのは、どの機能同士が近くにあって、どの機能は一緒にすべきでない、などの機能同士の相性です。
たとえば、表中の 「効率的な案件設定」 のようなデータを効率的に更新(update)することができる機能がDashboardに内包されていたとします。
そこで、 Dashboardに顧客は何をしに訪れているのか (出来上がる前のプロダクトや、リニューアルが目的であれば Dashboardは何をすべき機能なのか )を観察・考察します。
一方で、 データを効率的に更新するということはどういうことか を考えます。

ある例ではこのような結論に至ります。

  • Dashboard :取り扱っているデータの全体観を把握する機能
    • そこでデータを見ていると「自分が次に何をすべきなのかがわかる」こと。
    • できるだけ高い集中力を必要とせずに気づき気付きを得られること。(だからデータをビジュアライズする)
  • データを効率的に更新することができる機能 :できるだけ短時間で多くのデータに正確な影響を与えることができる機能
    • 影響範囲が広いため、高い集中力の下で作業する必要がある
    • 間違いに気付きやすく、必要十分なデータ量を一括でに処理できる
    • (今回は本筋外ですが、本当はこういう機能を人間が使うような設計にしてはいけない)

結論として、この2つの機能は要求前提(使う際の心持ち)が違いすぎて、お似合いではないと言えます。
すなわち、異なった要求前提を持つ役割同士は近い場所(画面)に存在するべきではありません。

こうした機能と要求前提(顧客はそこに何をしに訪れているのか)に対する観察は、より人間に寄り添った機能設計をするためのヒントを掘り起こしてくれます。
機能を便益(ベネフィット)につなげるために、顧客の心持ちはとても重要です。
心持ちとその時に使っている機能がチグハグな場合、顧客のベネフィットには繋がらないのです。

機能の20%がしっかり利用者の便益に直結していれば、80%のサービス価値はそこで表出される

どのようなベネフィットを提供しているか はいわばサービスやプロダクトのOffensiveな特徴で、顧客をサービスの世界観に引き込む強力な武器です。
そして多くのサービスの機能の中で、 本当に顧客にベネフィットを提供すべき機能はおおよそ20%程度 です。
ECサービスを例にとって見てみます。
ECサービスには非常に多くの機能がありますが、顧客にベネフィットを提供すべきなのは「物を買って、家に届くまで」の流れのみです。

  • 考察し
  • 探し当て
  • 決済し
  • 届く

この4つの体験を、どんなテーマで設計し、どのくらいの精度や喜びをもって顧客に体現してもらうか、ということに尽きます。
それは、ECサービスがお金を払って欲しい物を手に入れる場所だからです。

言い換えると

  • 欲しいものが何かを知るために:より十分に考察でき
  • 見つけたものを探すために:より早くターゲットを探し当て
  • 自分のものになるという手続き:よりスムーズに決済を完了し
  • 実感を持って完了する:いち早く届く

ということに(少なくとも2017年は)なります。
しかしながら、ECサービスにはもっと多くの機能があります。

  • TOPページ
  • 規約の開示
  • 初めての方へ
  • ガイドライン
  • Q&A
  • 決済が失敗した時のケア
  • 物が届かなかった時のケア
  • お問い合わせ機能
  • Chat
  • 〇〇とは
  • Etc…

※ここでは、ECサービスのなかで、エンドユーザー向けのみを対象に捉えています。それがなぜなのかは別なポストで解説しますが、エンドユーザー向けのサービスとサイト管理者向けのサービスは別なサービスとして捉えるべきだからです。

こうしたエキストラな機能の全てはECサービスの中で、考察し、探し当て、決済し、届く、という一連の機能が不十分なため必要になっています。
言い換えれば、4つのエレメンタリーな機能群をしっかり魅力的に磨き、パッケージングすることで、こうした付帯的な機能群は劇的にその比重を減らすことができます。
その結果、迷うことなくストレートに享受されたい価値を得られる顧客がどんどん増えるわけです。

それが便益のチューニングです。サービスが提供する便益のほとんど全ては、このためにあります。
このチューニングはできるだけ高い精度で体験をコントロールしながら実現しなくてはなりません。
だから、20%という数字は決して小さくなく、このくらいの機能群の規模にしておかないと限られた人数のエンジニアリング・デザインチームはそれを磨ききれなくなります。
僕のチーム・マネジメントでは、こうして極限までベネフィットを担当する機能群を絞り込んで行って、それでも磨ききれなかった時にエンジニアリング・デジアンチームのヘッドカウントが足りないと判断します。
それができていないチームはどんどん人ばかりが増えていき、その分開発効率が悪くなります。

ここを間違うと、結構厳しい状況を簡単に生み出してしまいますので、本当に注意が必要です。

では残りの機能80%は何のためにあるのか?

ここで間違ってはいけないのが、残りの80%の機能は不要なのかというと、そんなことはないという点です。
ただ、役割が担うミッションが大別できます。
20%の機能群が持つべきミッションは「顧客にベネフィットを提供すること」でした。
では80%の機能が持つ役割は、どんなミッションを追っているでしょう?

  • TOPページ
  • 規約の開示
  • 初めての方へ
  • ガイドライン
  • Q&A
  • 決済が失敗した時のケア
  • 物が届かなかった時のケア
  • お問い合わせ機能
  • Chat
  • 〇〇とは
  • Etc…

改めて先ほどのページ群を並べてみました。
これらの機能に共通していることは「そこに訪れる顧客は何かしら困ってる、もしくは行き詰っている」ということです。
なぜTOPページがそこに含まれているのかと感じる人もいるかと思いますが、ECサービスのTOPページは「サイトに訪れた目的が特になくて、受動的に行き詰っている人が訪れる場所」だからです。簡単にいうと、暇つぶしにきてるのです。その心境は、顧客に目的がないという点で、困っている状態によく似ています。

そして、この状況に陥っている顧客は決してベネフィットを享受することができません。
本来的なベネフィットを享受できる場所へ戻してあげる(リカバリする)必要があるのです。
これこそが、80%の機能群が持つミッションです。

このミッションを達成するために最も重要なのは、体験や、ましては得られもしない便益に向けたチューニングなどではありません。
プロダクトが持つ20%のベネフィットラインで享受できる価値が強力であればあるほど、顧客はどんなに探しにくい状況でもそのラインに戻るための情報を渇望するでしょう。これは、斜めから見ればサービスの強さそのものを表しています。
だから、情報の探しやすさなどはさほど重要ではなく、むしろなんとかベネフィットラインへ戻ろうとしている顧客の どんな困りごとにも答えられる情報の網羅性が何よりも重要なのが残りの80%の機能群 なのです。

また、利用されている頻度も非常に重要な着眼です。
これらの機能は「できるだけ使われないように」しなければなりません。
※ただし、利用者の利用単位ごとの継続時間が長いことは、そこに強力なベネフィットや価値を提供できている現れになります。

メルカリなどは非常によい例で、ベネフィットラインから外れない限りは何処よりも強力な価値への最短経路を提供していますが、一度そのラインからはすれたユーザーは仮出品を作って返金を行なったり、「専用」と書かれた謎の出品物を作ったりと、様々な工夫をユーザー自身が凝らしてそのベネフィットラインに戻ろうとしています。
これはUXの先回り戦略ともいうべき設計です。ベネフィットラインの体験を全て先回りしてパッケージ化し、そのラインの利便性にスポットしてチューニングしています。
これは極端な成功例ですが、その結果もはやプラットフォームが用意したリカバリの枠を超えた独自のリカバリ方法が確立してしまっているくらいに、ベネフィットに魅力があるのです。

では私たちはどんなことを考えながら日常の開発を進めれば良いのか

これらの整理は運用途中のサービスが途中で始めても、十分に意味があります。
次にこんな機能をつけよう、といったアイデアが出た際に、どこにつけるべきかが明確になるからです。
これはいわば、サービスやプロダクト内の機能毎のチームワークを設計しています。
機能はそれそのものの有用性も重要ですが、それがどこに存在していて、どう行った心持ちで使われているのかは、もっと重要なんです。

ですので、20%、80%と言う数字にこだわる必要は全くないと思いますありませんが、

  • チームの生産能力を把握して
  • チームで運用できる範囲のベネフィットラインを見出し
  • リカバリ・ロールと攻め方を明らかに変える

という取り組みは、プロダクトを進化させていく過程で、チームが少数精鋭であればあるほど大切なことです。

保存保存

各規格の転送速度を調べてくれていた人がいました。

このページがなくなったら非常に困るので、僕のところでも掲載します。
そういう趣旨のポストです。

各規格の転送速度を調べてみたよ

規格 ビット毎秒 転送速度
USB 1.0/1.1 12Mbps 1.5MB/s
USB 2.0 480Mbps 60MB/s
USB 3.0 5Gbps 625MB/s
USB 3.1 Gen2 10Gbps 1,250MB/s
USB 3.2 Gen2x2 20Gbps 2,500MB/s
IEEE1394a / FireWire 400 400Mbps 50MB/s
IEEE1394b / FireWire 800 800Mbps 100MB/s
Thunderbolt 10Gbps 1,250MB/s
Thunderbolt 2 20Gbps 2,500MB/s
Thunderbolt 3 40Gbps 5,000MB/s
SATA 1.0 1.5Gbps 150MB/s
SATA 2.0 3Gbps 300MB/s
SATA 3.0 6Gbps 600MB/s
SATA Express x1 10Gbps 1,250MB/s
SATA Express x2 20Gbps 2,500MB/s
M.2 (PCIe 2.0×2) 16Gbps 2,000MB/s
Ultra M.2 (PCIe 2.0×4) 32Gbps 4,000MB/s
PCI 32bit/33MHz 1Gbps 133MB/s
PCI 32bit/66MHz 2.1Gbps 266MB/s
PCI 64bit/33MHz 2.1Gbps 266MB/s
PCI 64bit/66MHz 4.2Gbps 533MB/s
PCI-X 64bit/66MHz 4.2Gbps 533MB/s
PCI-X 64bit/100MHz 6Gbps 800MB/s
PCI-X 64bit/133MHz 8.5Gbps 1,067MB/s
APG 1X 2.1Gbps 266MB/s
APG 2X 4.2Gbps 533MB/s
AGP 4X 8.5Gbps 1,066MB/s
AGP 8X 17Gbps 2,133MB/s
PCIe 1.1×32 16Gbps 2,000MB/s
PCIe 2.0×32 32Gbps 4,000MB/s
PCIe 3.0×32 63.02Gbps 8,000MB/s
PCIe 4.0×64 252.1Gbps 31.5GB/s
SDRAM PC133 8Gbps 1,000MB/s
DDR SDRAM PC2700 (DDR333) 21.6Gbps 2.7GB/s
DDR SDRAM PC3200 (DDR400) 25.6Gbps 3.2GB/s
DDR2 SDRAM PC2-4200 (DDR2-533) 33.6Gpbs 4.2GB/s
DDR2 SDRAM PC2-5300 (DDR2-667) 42.4Gbps 5.3GB/s
DDR2 SDRAM PC2-6400 (DDR2-800) 51.2Gbps 6.4GB/s
DDR3 SDRAM PC3-8500 (DDR3-1066) 68Gpbs 8.5GB/s
DDR3 SDRAM PC3-10600 (DDR3-1333) 84.8Gbps 10.6GB/s
DDR3 SDRAM PC3-12800 (DDR3-1600) 102.4Gbps 12.8GB/s
DDR3 SDRAM PC3-14900 (DDR3-1866) 119.5Gbps 14.9GB/s
DDR4 SDRAM PC4-17000 (DDR4-2133) 136.5Gbps 17.1GB/s
DDR4 SDRAM PC4-19200 (DDR4-2400) 153.6Gbps 19.2GB/s
DDR4 SDRAM PC4-21300 (DDR4-2666) 170.4Gbps 21.3GB/s
DDR4 SDRAM PC4-25600 (DDR4-3200) 204.8Gbps 25.6GB/s
DDR4 SDRAM PC4-26400 (DDR4-3300) 211.2Gbps 26.4GB/s
DDR4 SDRAM PC4-26600 (DDR4-3333) 212.8Gbps 26.6GBs
DDR4 SDRAM PC4-27200 (DDR4-3400) 217.6Gbps 27.2GB/s
DDR4 SDRAM PC4-27700 (DDR4-3466) 211.6Gbps 27.7GB/s
DDR4 SDRAM PC4-28800 (DDR4-3600) 230.4Gbps 28.8GB/s
DDR4 SDRAM PC4-29800 (DDR4-3733) 239.2Gbps 29.9GB/s
DDR4 SDRAM PC4-30900 (DDR4-3866) 247.2Gbps 30.9GB/s
DDR4 SDRAM PC4-32000 (DDR4-4000) 256Gbps 32.0GB/s
DDR4 SDRAM PC4-33600 (DDR4-4200) 268.8Gpbs 33.6GB/s
DDR4 SDRAM PC4-34100 (DDR4-4266) 272Gbps 34.1GB/s
10BASE-T 10Mbps 1.25MB/s
100BASE-TX 100Mbps 12.5MB/s
1000BASE-T 1Gbps 125MB/s
2.5GBASE-T 2.5Gbps 312MB/s
5GBASE-T 5Gbps 625MB/s
10GBASE-T 10Gbps 1,250MB/s
25GBASE-T 25Gbps 3,125MB/s
40GBASE-T 40Gbps 5,000MB/s
100GBASE-R 100Gbps 12,500MB/s
IEEE802.11 2Mbps 0.25MB/s
IEEE802.11b 11Mbps 1.375MB/s
IEEE802.11g/a/j 54Mbps 6.75MB/s
IEEE802.11n (Draft) 100Mbps 12.5MB/s
IEEE802.11n 600Mbps 75MB/s
IEEE802.11ad 6.8Gbps 850MB/s
IEEE802.11ac 6.9Gbps 862.5MB/s
PLC/IEEE1901 240Mbps 30MB/s
Analog Modem 56kbps 7KB/s
FOMA 384kbps 48KB/s
FOMA High Speed 7.2Mbps 0.9MB/s
UQ WiMAX 40Mbps 5MB/s
4G LTE 788Mbps 98.5MB/s
ADSL 50Mbps 6.25MB/s
光回線 100Mbps 12.5MB/s
光ギガ回線 1Gbps 133MB/s
光ギガ回線2Gbps 2Gbps 266MB/s
光ギガ回線10Gbps 10Gbps 1,330MB/s
SD Speed Class 2 16Mbps 2MB/s
SD Speed Class 4 32Mbps 4MB/s
SD Speed Class 6 48Mbps 6MB/s
SD Speed Class 10 80Mbps 10MB/s
UHS Speed Class1 80Mbps 10MB/s
UHS Speed Class3 240Mbps 30MB/s
DVIデュアルリンク 3.7Gbps 462.5MB/s
HDMI 1.2 4.95Gbps 618.75MB/s
HDMI 1.4 10.2Gbps 1,275MB/s
HDMI 2.0 18Gbps 2,250MB/s
HDMI 2.1 48Gbps 6,000MB/s
Display Port 1.0 8.64Gbps 1,080MB/s
Display Port 1.2 17.28Gbps 2,160MB/s
Display Port 1.4 32.4Gbps 2,592MB/s

 

情報のアップデートなどを有志もやってくれる?未来があるかもしれないので、リポジトリを作っておきました。
https://github.com/ikunai/tech-document/blob/master/jp-ja/interface-performance.md

その前に、そもそもMacBookで映像編集は可能なのか?

今回は無印MacBookという非力なマシンを使ったこともあり、できるだけマシンネイティブなリソースの消費をする必要がありました。

Appleは長きにわたってiMovieというエントリー用の映像編集アプリケーションとFinal Cut Pro Xというプロユース向けのラインナップを長年運用してきました。

15年ほど前のFinal Cut Proはエントリー機でまともに動くようなアプリケーションではありませんでしたが、近年までの間にだいぶロースペックマシンでもそれなりに動くようにチュニングされてきました。

また、バッテリー交換が手軽に行えなくなった世代頃からのMacBookシリーズに採用されたM.2規格により、下手にSATAなどで接続するのと比較してインターフェース自体のポテンシャルは2.7倍程度(SATA=6Gbps:M.2=16Gbps)に引き上げられましたし、今回のHigh SierraへのアップデートでSSD機にAPFSフォーマットが採用され、ストレージのボトルネックは結構劇的に改善されました。

映像編集はディスクパフォーマンスが非常に重要なのでそのボトルネックが取れるとかなり可能性は広がります。

その恩恵で、2017年以降のApple機種ではi5、i7 Dual Core程度のCPU(m3はちょっときつい)と16GBのメモリがあれば、ほぼどのマシンでもそれなりの快適さで作業が行えるようになりました。

今回の様に長尺の映像を取り扱うには外付けのストレージが必要で、そうなるとストレージを外付けすることになり、Thunderboltが相違されていない無印MacBookでは力不足な場面もありますが、そうでない場合や長編も尺を細かく切って編集するのであれば、全然十分作業に耐えます。

512GBのSSDに256GB以上保存してはいけない。ただし仮想サーバは良い。

この前、久しぶりに512GB SSDのMacBookで映像編集を行いました。
普段僕はどのマシンを使っていても基本ツール(Font / Application / Basicな素材など)で150GB程度のデータと、作業データ50GB程度で合計200GB前後を消費していますが、今回、結構長編の映像を作業していたら、気づいたら450GBくらいまでストレージ容量を使ってしまっていました。

こうなると、ほぼ全ての作業がもっさりします。
デスクトップのアイコンを表示するのに数分を要するくらい。もう、年代物のMacをいじっている様な感覚です。

僕はすっかり128GBくらいしか容量がなかった頃のストレージマネジメントの基本「保存容量で半分以上使うとパフォーマンスに影響する」を忘れていました。
SSD MacBookの時代になって、

  • ストレージは寿命を気にしなければならない
  • 容量が少なくなったまま使うとパフォーマンスの低下とともに寿命が著しく短くなる(特定の領域を何度もWriteする羽目になるから)
  • メモリスワップは積極的にSSDに書き込まれる。だから、目に見えない使用容量がある

など、気にしなければならないことはいくらでもあったのに。。。笑

なんでそんなことを忘れてしまったのか?

ここ10年ほどの間、僕はオンラインプロダクトに関するエンジニアリング最前線でMacを使ってきたのですが、
その間に僕が作り上げたプロダクトがハンドリングするデータのほとんどはサーバー上に保存されます。
ここに、上記の事実を忘れさせた要素があったことに気がつきました。

オンラインプロダクトの開発を行っていると、サーバ上のストレージマネジメントは今や上限容量の90%程度までは利用して良いのが前提です。
これは、

  • もともとLinuxなどのサーバOS自体がそういったストレージマネジメントを前提に作られていること
  • サーバの用途(DatabaseやTCP Connectionさばき)が特化している状態がほとんど

であるためもありますが、これはそうはいっても物理サーバではそれでもせいぜい75%程度までが限界でした。
※もっと変態的なチューニングをしている人はいそうですが。。。

それが昨今、AWS / GCP / Azure / IBMなどで展開される仮想マシンでは、ミドルウェア特性を理解してうまく組まれているアーキテクチャ上で動いているシステムや、AWS RDSやElasticSearch、GCP BigQuery / Spannerなど、アプリケーション層をパッケージングして提供しているマネージドサービスなどでは、下手するとストレージ使用量が100%に到達してデータが保存できなくなってから気づく、みたいなことが珍しくありません。(監視をしっかりして珍しくしなければならないという議論はここでは割愛します)

仮想マシンやマネージドサービスのストレージ容量とは

僕はすっかりと数年の間で上記の様な頭になってしまっていたのですが、手元のコンシューマ機と仮想マシンやマネージドサービスのストレージ容量は、その意味するところが全く違います。
2013年にMicrosoftが発表したのHyper-Vに始まり、近年のPV・HVMなどの仮想化技術は、そもそも仮想マシンのストレージが分散ストレージ上の仮想ストレージである特性を活かして、この「保存容量が少なくなってきたときにパフォーマンスが低下する問題」をものの見事に「まるでそんなことはなかったかの様にパッケージング」しています。
こうした背景を鑑みると、

  • コンシューマー機のストレージ容量は「物理的に保存できるサイズ」
  • 仮想サーバのストレージ容量は「保存して良い(許可された)サイズ」

と言い換えることができます。
すっかりとこのことを忘れていたのが、今回僕が自分のMacの使い方を誤った原因でした。
いまだによく叫ばれる「仮想マシンは物理マシンはどっちがコストパフォーマンスが良いのか?」という観点は、仮想マシンを動かすバイザーの性能傾向をちゃんと考えないと一概に答えが出せないなぁと思うのでした。
そういえば、そこの観点は抜けてたな。。。と。

独り言でした。
その前に、そもそもMacBookで映像編集は可能なのか?

我が家のMinecraft環境構築メモ Part 1 〜 Minecraftを複数人数で遊ぶための基礎環境構築(前編:全体的な構成の話)

我が家ではMinecraft実況を実験的に行なっています。
環境のセットアップを久しぶりに行っていて、マイクのインピーダンスだとか、本当に久しぶりに様々な規格の話を気にしながら現在の環境が出来上がったので、せっかくだからその経緯を詳しく解説したいと思います。
まずはMinecraftマルチプレイ用の基礎環境の構築から。
前編は全体的な構成の話、後編は具体的な各端末へのインストール・設定の話へ続きます。

まずはハードウェアの選定

PS4版は例外(1端末で4人までマルチプレイが可能)ですが、それ以外のバージョンは例外なく、Minecraftを複数人で遊ぶには人数分の端末とソフトまたはアプリケーションが必要です。
基本的にはMinecraftが動いている誰かの端末をホストにし、そこに他のプレイヤーが参加してマルチプレイを行いますが、複数人数が参加するとそれなりに負荷がかかるため、PC版やPE版(今後その読み方も少なくなっていきます)にはMojangや有志が用意したものや、自前で立ち上げたマルチプレイ用のサーバを利用することができます。


我が家のポイントは

  • 小学生2人(小1&小4)+大人二人(夫婦)
  • 仕事柄、歴代の仕事用ノートパソコン(Macがご家庭レベルではない台数存在する)
  • 家はマンション。そんなに広くねぇ。

でした。
なので基本のセットは昔仕事で使っており、今は家に眠っていたノートパソコンたちを復活させ、


使用者 本体 OS グラフィック RAM
MacBook Pro 2016 13.3inch MacOS X Sierra Intel Graphic 16GB
MacBook Air 2014 13.3inch MacOS X Sierra Intel Graphic 8GB
小4 MacBook Pro 2012 15inch MacOS X Sierra GeForce 16GB
小1 TOSHIBA Dynabook Kira Intel Graphic Windows 10 Creators Edition 8GB
マルチサーバ IBM Mini tower CentOS 6.x 8GB

としました。
特徴としては、とにかくノートパソコンだから致し方ないのですがクライアント側のグラフィック環境が貧弱だということです。
家庭で実況となるとゲーミングPCを並べて部屋を占拠するわけにもいかないので、このあたりが現実的な落とし所なのかなと思っています。
これでノート端末は枯渇したのでサーバだけはIBMの古いミニタワーを部屋の隅っこで稼働させています。

低スペックパソコンに優しいMinecraft環境をmodで実現

Minecraftは小学生に普及している背景を考えると結構嘘だろ?って思うくらい高スペックなマシンを必要とします。
CPUがボトルネックになることはほぼないのですが、RAM(8GB以上)やGPU(オンボードだと2016年以降くらいのモデルのじゃないときつい)の壁が立ちはだかります。
しかも今時OpenGL対応を要求してくるなど、デフォルト状態では数万円前半の「とりあえずパソコン」では動作すらままなりません。
忘れてはなりません。Minecraftは曲がりなりにもPCゲームなのでした。

しかしそこはさすが歴史の長いゲーム。救いの策はちゃんと用意されています。
PC版Minecraftには古くからMinecraft本体をForge版に置き換えることでmod(拡張機能)が適用可能な状態にすることができます。
その中のOptifineというmodがグラフィック要求性能を飛躍的に下げてくれるのです。
これにMinecraftがちょっとだけ便利になるmodを追加し、

  • Minecraft本体:Minecraft Forge – https://files.minecraftforge.net
  • Minecraft Server:Minecraft Forge – https://files.minecraftforge.net
  • Mod
    • Optifine:グラフィック設定を細かくいじれる。適用した段階でかなり要求グラフィック性能は下がる。 – http://optifine.net/home
    • CocoaInput(Mac):看板などに文字を入力するときに日本語が打てるようになる。 – http://forum.minecraftuser.jp/viewtopic.php?t=24394
    • IntelliInput(Windows):CocoaInputと類似の機能を提供するWindows版mod – http://mcc.mcsv.jp/IntelliInput

という構成でスタートすることにしました。
これで今回一番低スペックであると考えられる母のMacBook Airでも、そこそこ快適にプレイすることができます。

※modはクライアント・サーバ両方にインストールが必要なものと、クライアント側のみにインストールするものの2タイプに分けられますが、今回の場合、Optifine以外はクライアント側のみにインストールするタイプです。

さて、ここまでが基礎的な機器とソフト&アプリケーション構成です。
Minecraft Forgeやmodの具体的なインストールは後編に譲りましょう。