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の具体的なインストールは後編に譲りましょう。

いいエンジニア・すごいエンジニアリングのバリエーション(ブレスト中)

すごいエンジニアリングですね!
いいエンジニアいますねー!

照れます。ありがとうございます。
僕は褒めらるのが大好きなので、上記のような言葉が大好きです。

唐突ですが、先日若い(19歳)エンジニアに「いいエンジニアになりたいんです!」と言われました。
僕はその言葉に対し「おお!がんばれよ!」としか言えませんでした。何かモチベーションの足しになるような気の利いたことを言えればよかったのですが、全く思いつかなかったんです。
もちろん僕は僕の中のいいエンジニア像があります。ただし、それが彼が考えているいいエンジニア像とマッチしているとは限らない。
一方で大きな会社にいくつもあるエンジニアリングチームやその成果を観察していると、様々なタイプのすごいエンジニアがいることがわかります。
まさに、ひしめき合っています。すごさが。

「いいエンジニアリング」「すごいエンジニアリング」ってなんだろう。

その日から僕はこの疑問の虜になっていました。

そもそもエンジニアは、基本的に事業上・社会上に発生する様々な問題に対して「プロダクションで解決する」というアプローチを取る職種で(あろうかと思いま)す。
逆にいうと、ある問題に対して解決をプロダクションに期待するということは、エンジニアが持つ何かしらの「すごさ」に世の中が期待しているということに他なりません。
ということは、それこそがエンジニアが目指すべき すごさ ではないかと。
この角度に向き合えば、エンジニアは未来永劫「ちゃんと期待される職業」であり続けられる。
次19歳に聞かれた時には、こういう観点を持って相談に乗ってあげられるようになっておかなくては。笑

そんなことを考えましたので、身の回りにいる様々なすごいエンジニアを観察して実験的に整理してみてます。
以下、自分的2017年度版
「世の中がエンジニアに期待していること=エンジニアリングのすごさ」
です。
例ではシステムプロダクションにかかわるエンジニアリングの範囲で言葉を選んでいますが、ジャンルが変わっても本質的にはそう変わりないかと思います。

★Optimality(最適性)

最も歴史の長いエンジニアリングの凄さかと思います。
マリオブラザーズが24KBであったかのように、テトリスがJS7行で書けたかのように、この凄さはコンピューティングや人間をはじめとした、様々なリソース(資源)を最適に使おうという意志から生まれる魔法のようなアウトプットで『信じられない!』をもって世の中に伝えられます。
このタイプのすごいエンジニアがいるチームは狐につままれているかのようなシンプルなサーバ構成でサービスを展開したり、スマホ上であり得ないくらい滑らかで魅力的な演出を実現したり、サーバーコストで驚異的な効率を叩き出したりします。

★Strength(強さ)

強いシステムというものが世の中には存在します。
どんなに膨大なアクセスが来ようとも、ユニットアーキテクチャをどこまでも並列に分散させて難なく捌いたり、特定のアクセスパターンに対するパフォーマンス脆弱性を発生させないためのチューニングが生んだ尖った強さであったり、限られた時間の中で母数が多い計算リソース消費パターンに対して迅速に行うチューニングなど、システムが必要外で停止したり障害を起こしたりしないために必要な凄さです。
WEBサービスで例えるならば、WBS砲などで起こる「バズった」や、うるう秒問題で予測されるにわかには予期不能なコンピューティングリソース異常消費の可能性への備えなど、サービスがどんな状況下に投じられたとしても、変わらず可用性を保持できるかがこの凄さのポイントです。
技術力だけではなくて、困難を予測するセンスやデータ観察力が元になります。

★Promptness(迅速性)

要望に対し、いかに早く変化できるか。
ある時はビジネス戦略に寄り添ったアーキテクチャを敷いたり、またある時はひたすら広い懐を担保して未来の指針を待ったり、またある時にはとにかく最速で動かすことを目指す。
この活動を洗練させるために必要な設計思想の柔軟さと実現思考の習熟度は、物を作るプロフェッショナルの誰もが持つべき凄さです。
またこの凄さはアウトプットの正確性と親密な関係があります。正確性を欠いたアウトプットは役に立たず、再度作り直すことになるからです。
イメージ通りのものを、最速で生み出す環境へのこだわりが、この迅速性の元になっています。

★Amenity(快適性)

優れたUIやクイックな反応速度でユーザーに快適さを提供する。
これは、UIのスマートさによる表面的なものであるとか、様々なエンジニアリングの凄さが集結して出来る結果に過ぎないとか勘違いされがちですが、実はそうでは(それだけでは)ありません。
システムのウィークポイント(本来的なもの、現状の開発状況的にやむを得ないもの含め)を見定め、それを巧みにラッピングし「気持ちよさ」を打ち出せる箇所に適切なスポットライトを当てることで、人の気持ちを長所に向け、短所をなかったことにする、いわば、現状と常に戦い、利用者に提供するインターフェイスとの最後の辻褄を合わせる凄さです。
美味しいカレーと美味しいうどんをどう合わせたら美味しいカレーうどんが出来上がるのか考える凄さ、といえば伝わりが良いでしょうか。
かっこいいベーシストとかっこいいギタリストが組んでもかっこいいバンドが出来上がるとは限らない例を思い浮かべるのがいいでしょうか。
プロダクトの状況に対する透明性を担保し、現状の強みと弱みををよく把握して仕事に臨むような高いチームワークを誇るチームでよく見られます。
一人で実現する場合も、チームで実現する場合も、質の高いコミュニケーションが常にチーム内を循環している必要があります。

★Safety(安全性)

人は技術で形作られた新しいものに対して、常に一定以上の危険性を感じています。
その先に快適性やイノベーティブな体験が期待できたとしても、安全性の担保が感じられないとそこに身を投じる人の数は激減します。
世の万物を見渡しても完全に安全性を担保しているようなものが存在していないように、数百万行、数億行のシステムの完全な安全性を保ち続ける手法もまた発見すらされていませんが、世界中に無数に点在し、常に増え続ける敵と戦い続けています。
非常に象徴的で、掴みにくく、なんとなくしか世の中に伝えることができない安全性を、合理性を駆使して生み出していることそのものがこのすごさであると言えます。
我々が日々生み出している「技術的に新しい何か」を世の中が何の疑いもなく楽しむことができる状況を下支えしています。

★Toughness(耐性)

語られても尽くされることのない「継続的インテグレーション」は幾度の仕様変更にも耐え、長きにわたって変化を繰り返し続けることができる状態を目指すことを目的としたプログレッションフレームワークです。
そうしたシステムのタフさはここ数年どんな時にも求められがちな凄さです。
であるにもかかわらず最もコストの必要性が理解されにくい宿命を持っています。
これは、我々エンジニアがその部分を表出させることを怠ってきたからではありません。
輪島塗りの食器を見た時に、工房の整然さをも想像してその美しさを感じる人がどのくらいいるでしょう?
それと一緒か、それ以上に人に伝わりにくい部分なのです。
だから、我々はこの凄さを武器に市場価値を勝ち取ろうとすべきではありません。
その本質を我々エンジニア以外が理解する日は来ないからです。

★Fronteer Spirits(開拓性)

エンジニアは世界で最も『誰もやったことがないこと』に対して心惹かれる職業人種のひとつです。
そこに対する想いは、うやむやな新規性が発生させがちな『実現へ向けた妙な壁』を無力化し、いとも簡単に壁の向こう側にある世界まで到達してしまいます。
思想家ではなく、具現家の立場でその熱量を持つからこそ、この特徴を強く持つエンジニアは『すごい』と賞賛されます。
思想家は機械が動き回る世界の絵を描けますが、動き回った機械が何を始めるのかは、具現家が最もよく理解しています。
世界が最もわかりやすくエンジニアリングに期待している凄さの一つ解いても過言ではないでしょう。。

★Imagenation(想像力)

まだ誰も見たことがないあの壁の向こうには何があるでしょう?
エンジニアのフロンティアスピリッツを下支えする凄さがこのイマジネーションです。
具現家であるエンジニアはまだ見ぬ壁の向こうを誰よりも正確に想像することができます。
そして、であるからそこに向かって迷い無く走り出せるのです。
(僕は最近多くの文章にこの言葉を入れていますが)どんなに魅力的なアイデアが溢れかえろうとも、我々が一度に世に出せるのはたったひとつのプロダクトです。これを正確にイメージできる人がチームにいると、コミュニケーションがとてもスマートになります。
逆にこの機能がチームにないと、どんなに他の視点ですごいエンジニアがいても、いいものは出来上がりません。
そして、この凄さはしばしば出来上がる予定のプロダクトに対する想い入れと比例します。すごいメンバーを集め、誰も大した思い入れのない状態で開始されたプロジェクトが、ぐずぐずのアウトプットを生んでしまう図式では大抵ここの凄さが不足しています。

★Rationality(合理性)

誰にとっての、何にとっての合理性を求めるかによって生まれるアウトプットは変わります。
合理的な構成やインターフェースを持つシステムに、人間は何年もの間苦しめられてきました。その合理性が「機械にとってのもの」でしかなかった時代の話です。
機械にとっての合理性は、その種の合理性を追求する人間にしか価値を理解できず、そんな機会仕様なインターフェースを持つシステムは世界のあちこちで利用者に 今まで教えられたこともないような頭の使い方を人々に強要 しました。
これは、世界の問題解決のあり方までもかえようとしている強い思想であり、具現家であるエンジニアが使う魔法のような実現力の源はこれであると言っても過言ではありません。
しかし、機械的合理と人的合理は全く異なるものです。
これら融和を図るというのがこの合理性の真骨頂ですし、この融和でさえ合理性で解決しようとしているのが、エンジニアの凄さです。

——

長くなりました。できるだけシンプルにまとめたつもりではあるものの。
一口にエンジニアリングといっても、考えてみたら様々なすごさがありました。
こんなことを意識して日頃のエンジニアリングにあたっている人がどのくらいいるのかわかりませんが、キャリアの大小に関わらず、自分はどういったエンジニアになっていきたいかを考えたときに、切り口の参考にでもなれば幸いかと思っています。
近年はレジリエンスなどもエンジニアリングの中では注目対象な強さですが、市場からのスポットライトがあらたるのはもう少し先の話でしょう。

※タイトルにも書きましたが、これはブレスト中です。
きっと抜け漏れがあると思います。
もしもっといい分類を考えていたり、不足している観点を見つけた方は、是非教えてください。

※そういえば考察の副産物ですが、 具現家 って言葉が個人的に気に入ってしまいました。(誤字ではない)
近代のエンジニアたち、クリエイターたち、デザイナーたち、を始め、ものづくりに直接的に関わるみんなひっくるめたくくりに適切な名前を探していたんですが、 これだ! 感があります。(すぐ過ぎ去るかもしれませんが)

「システムによる効率化は本当にやって良いのか?」を「強いシステム・弱いシステム」の切り口で考える

ひと昔前、よくAI業界では「強いAI・弱いAI」の話がされました。

  • 強いAI = 人間そのものそエミュレートして、人間の代替となる存在を目指すような、文字通りの人工知能。
    • Wikipediaでは「コンピュータが強いAIと呼ばれるのは、人間の知能に迫るようになるか、人間の仕事をこなせるようになるか、幅広い知識と何らかの自意識を持つようになったときである。」とされる。
  • 弱いAI = 2017年では「問題解決や推論を自動もしくは半自動的に行うことに」特化させたようなもの。いわば知能の有用な一部のみをピックアップしてエミュレートしたようなもので、そのぶん構造がシンプルになり、処理性能が飛躍的に向上する傾向がある。近年の実験室的な成功例としては「がんの治療法解析をAiにやらせた例」があります。
    • Wikipediaでは「人間がその全認知能力を必要としない程度の問題解決推論を行うソフトウェアの実装や研究を指す。弱いAIに分類されるソフトウェアの例として、ディープ・ブルーのようなチェスプログラムがある。強いAIとは異なり、弱いAIが自意識を示したり、人間並みの幅広い認知能力を示すことはなく、最先端とされるものでも知能を感じさせることのない単なる特定問題解決器でしかない。」とされる。

これを、インターネット業界に並ぶシステムに当てはめて「強いシステム・弱いシステム」を定義してみます。

  • 強いシステム:人間に取って代わってその業務を完全に代替できるようなシステム。
    • ただし人間だらけの業務・体験フローの中に組み込まれるのが常なので「結果を人間が視認できるようなレポートアウトプットと、その業務が間違った働きをしている場合に指示するできる限りシンプルなインプットインターフェースを持つ」とするのが現実的でしょう。
    • 人間自体の業務が属人的なそれになりがちなのと同じように、このようなシステムはブラックボックスになりがちです。
  • 弱いシステム:人間が行うある業務の効率を飛躍的に向上させる、もしくは業務を構造化・正規化し、MECEな整理状態を提供するだけのシステム。
    • 人間の筆記速度を100倍にするメカトロニクスを発明した場合、ノートパソコンの倍以上の生産性をもたらすという研究結果があります。
    • このようなメカも今回の分類では弱いシステムに入ります。

これら強い・弱いの違いは
「そのシステムが人間の発想を超えた何かを自動的に生み出す可能性があるか?」
もしくは
「そのシステムは完全に業務を代替(人間の代わりにシステムがそれをやっている、と言い換えられるほどの状況)しているか?」
のいずれかを満たすどうか、です。

以下、この分類を切り口に現状世の中に転がっているシステムを考察してみます。

また、この記事の前提として「もう少し上手く表現できたんじゃないか」という気がしながら公開しています。
だから、公開しながら読み返して、表現や事例などを変えるかもしれません。
また、現時点では空論の遊び記事でしかないことも付け加えておきます。

世界に名だたる名システム(のように見えているシステム)のほとんどは「弱いシステム」です

例えば会員管理システム、自治体や大きめの企業で利用されるいわゆる業務システム、各種業務の管理画面やBI、案件管理システム(いわゆるトレーディングデスクTool)などは典型的な弱いシステムに分類されます。

  • 業務ツールがいくら自動でレポートを生成しようとも、
  • BIがどんなに自動的に分析指標の提案をしたとしても、
  • 案件管理システムがどれだけ整然と案件データを再利用性高く並べられたとしても、

これらはその業務の完全な代替を行いません。
そのアウトプットや業務のほぼ全てが「人間(オペレーター)の意志によって行われているから」です。
また、長年の運用の中で(もしくは不屈の精神によって繰り返されてきたリファクタリングの成果で)正規化を追求し、構造化を進めたシステムの多くは、歴史が長ければ長いほど(ヒューマンリーダブルでない、という意味で)複雑化していきます。

「その存在にすら気づかない=存在を意識させない=そもそもシステムとして認識されていない場合すらある」のが、強いシステムです

現在「インターネットの案内所」のように取り扱われている検索エンジンはかなり近い立ち位置にいるかもしれません。その役目が根本的なことすぎて掴みにくいかもしれませんが、例えば検索のアルゴリズムが変化したときに、我々は「そういうものか」と諦めるしかありません。我々は弱いシステムについてはそういう変化に対し徹底的に抗う習性を持っていますが、人間の代替と取れるような強いシステムに対しては、人間に対してと同じようにその挙動特性を許容することができます。

また、電話交換機や、ドメインマーケットなども「販売プラットフォーム」としてはオンライン上の強いシステムの一つに数えられます。
自動運転車が完成したら、それは強いシステムです。運転手という人間を完全代替しているからです。

海外だと状況が変わる?

インターネット広告業界に目を向けてみると海外ではAppLovinやCriteoなども、インターネット(に限らない部分も含め)広告配信業界の管理画面に対してかなり強いシステムに近いアプローチをしています。
Amazon Goや有機的に動物の動きを真似るメカトロニクスも強いシステムを目指した例であると言えるでしょう。
また、近日話題になったハンバーグをひっくり返すロボットアームも、類に漏れません。

こうした「強いシステムを作る試み」は、やはり海外に圧倒的に事例が多く、国内でも事例は散見されるほどはあるものの、ほとんどが「遊びとして扱われ、商業的に相手にされていない」というのが実情です。

さて、この辺りが今日の本題です。

弱いシステムは人間の仕事を決して奪わない。
そして人間を必要以上に強くする。
同時に人間の頭を開放し、暇(クリエイティブ)にする機能は持たない。

17年ほど、システムをはじめとした様々なものを作ってきてここにきて感じているのは上記のようなことです。

広告配信業務フローを例にとってみると、DSPやDMPなどが出てきたことによって、それを操るトレーダーの「広告配信を効率化するために取れる手法」の数は飛躍的に増えました。その結果、非常に高度なロジックを操って、より効果の高い配信を、より多くの案件に相対して提供できるようになりました。
また、ECサイトの例をとってみれば、EC CMSというシステムの台頭により、商人は「インターネットを通じて商品を売る」という手段を手に入れました。その結果、今まで対面販売や従来型の通販のみでは届かなかった顧客にまで商品の存在を知らせることができるようになりました。

しかしながら、そのシステムがあろうがなかろうが、相変わらず広告のトレーダーは広告を運用しています。商人は商品を売っています。このことについては何の変化もありません。

それだけでなく、今まで月に500万円の売り上げを上げていれば十分に評価されていたトレーダーは、弱いシステムがもたらした効率化によって月5,000万円を売り上げることができるようになり、その結果、当然のように今まで500万円を売り上げて得られていた評価は、5,000万円を売り上げないと得られなくなりました。
これは、その人の時間単位の生産性という名の責任が10倍に膨れ上がったということです。
同じように、商人がそのように効率的に売ることができるようになった結果、商人は価格にそれを反映させなければいけなくなり、1取引あたりの利益は落ちていきます。

そして人間一人が処理できる量が増えたことを契機として、事業は成長していきます。
結果人はできるようになった10倍の仕事をいつの間にかこなしています。

このことは「実のところ、弱いシステムが世の中にいくら台頭しても、人は決して楽にはならないし、そのシステムを利用して行う役目から頭を開放することはできない」ということを示唆しています。

特に日本にこの傾向が強いのは「日本人が優秀だから」なのかもしれません

欧米は、今も昔も「強いシステム」の生み出しに躍起です。
対して、日本ではやはりこの強いシステムは遊びと扱われ、夢と揶揄されます。要は、まともに取り扱ってくれるまでの道のりが長い。
これはなぜなのか。と考えると「人の優秀さ」というキーワードがまず最初に頭に浮かびます。

欧米人は、例えば日本人クリエイターがドイツに行ってワーカーの文化の違いに学びながらも疲弊して帰ってくるような事例が示すように、どうやら「人間とはそういう(不完全で信用できない)ものだ」と本気で思っているようで、人間に期待する範囲が小さい。だから弱いシステムによって人間を効率化するよりも、強いシステムによって「人間がやらなくて良い状況を作る」ということを割と真面目に考えているのではないかという仮説が立ちます。

対して日本人は、人そのものの業務フロー上のポテンシャルが高いために、同じく高い成果を求めた場合「人間を効率化したほうが早い」という考えに至りがちなのではないか、との仮説が思い浮かびます。なので日本人は「たいていのことは機械がやるよりも、人間がやったほうが正確で質が高い」とこれまたどうやら本気で思っているのです。

「それがいいのか悪いのか」という話ではなく、プロダクトのこれからの展開を見据える上で、僕ら具現家はどういう発想の元に立つべきなのか?という切り口をもっと柔軟にしようという話です。
なので、このことを一つの物差しとして持っておくことは、他の事象を考える上で大いに手助けになることがあります。
そんな例を次回あたりに考察してみます。