サービスやプロダクトが持つ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倍の仕事をいつの間にかこなしています。

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

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

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

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

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

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

デザイナー出自のCTOが考えていたプロダクトのVI

VIという仕事はなかなかその内容について書くことはないもんですが、ひょんな機会をいただきました。ありがとうございます。
せっかく書いたので、こっちにも投稿しておこうと思います。
僕も単一プロダクトを持つ企業のCTOという立場をつい数日前に終えました。そういった記念も込めて。
ちなみに今回はいわゆる日本で言われるエンジニアリング分野の話は一切ありません。

FlipdeskのVIの話です。

Flipdeskは2年半前にスタートしたWEB接客プラットフォームで、リリース当初は「タグを埋め込むだけでサイト上にチャット機能を提供できます」というウリ文句の元、サービスがスタートしました。

現在はこのようなロゴを用いています。

これ、サービスが市場からある程度の知名度を得た後に、第二弾ロゴとして作成しました。
一方、初代のロゴはこちら。

だいぶ印象が変わってきますね。
時系列を踏まえて、初代ロゴの方からその由来を解説しましょう。

初代のコンセプトは「邪魔をしない」

当時すでにスマホのディスプレイはインターネット広告で溢れかえっており、広告はコンテンツを楽しむユーザーに邪魔者扱いされていました。
そしてFlipdeskが主戦市場としていたECサイトは一般ユーザーが何の気なしに訪れるWEBの中では数少ない広告非武装地域でした。(一部大手モールを除いて)
Flipdeskはコンテンツをポップアップさせたり、フローティングボタンとして表示したりという機能を持つので、テストマーケティングに付き合っていただけるクライアントを探していた段階でもしばしば「サイト内で広告を出すツールですか?」との勘違いを浴びました。
WEBで接客という概念がまだ世の中に浸透していなかった2014年では、フローティングボタンといえば広告でしょ、くらいの解釈をされることがザラだったんです。
そんな中でサービスの価値を業界に正しく理解されるにはFlipdeskは訪れたユーザーの邪魔をしないという認識を伝える必要があり、それをそのままビジュアルに落とし込みました。なのでとても線が細く、カラーも中庸な仕上がりになっています。
VIを通じて「リアル店舗の店員が全身全霊の気遣いで訪れたお客さんに喜びを与える存在であるように、Flipdeskも決してユーザーの邪魔はせず、ウェブ担当者の思いをスマートにお客さんに伝えるツールなんですよ」というメッセージを全面に押し出したのです。

また、同時に「店子であるかのように、ユーザーをちゃんと見てますよ」というメッセージも込めて、目入りの遊びを含めました。
当時はこのことに遊び以上の意味はなく、僕がビジュアルにほんの少しのポップさを加え、最後の辻褄を合わせる要素として入れたものでしたが、のちの幾つかの局面でアニメーションに使われるなどして馴染みやすさに一役買いました。
ビジュアルの最後の辻褄を合わせるエレメントはデザイナーのセンスやこだわりでしかありませんが、そうして加えたものには得てして作り手の思いが込められており、しばしばビジュアルの可能性を広げてくれる意外と重要な存在です。

またFlipdeskはロゴと事業コンセプトが同時並行で作られており(スタートアップでは珍しいことではありません)、当時された
「このロゴを見ていると、こんなコンセプトもありな気がする」
のようなやり取りに象徴されるように、ロゴのビジュアル・アイデンティティも事業コンセプトを決めるインスピレーションの一部でした。
ブレストの際にもまるで喋るかのようにロゴ案を次々と出すという感じです。
これは創業者にクリエイティブ担当がいるチームならではのアプローチで、言葉のやり取りだけでは思いつかない発想を引き出すこともあります。


当時ブレストに出ていたロゴの習作(一部)

そうしてビジュアルと事業コンセプトが双方の歩み寄りを見せて決定したのが、初代のロゴです。

カオスマップ掲載から着想した二代目「ひとりで戦えるロゴマーク」

サービスがある知名度を得ると、ロゴマークとともにサービスのイメージが独り歩きを始めます。
展示会用のチラシ、営業資料、代理店向け営業資料、サービスLP、連携先企業のWEB、取材記事、採用記事など、様々な場面、媒体で一般の方々の目に触れられる段階になると、見た人、説明を受けた人が、また隣人に解説を始めます。そうした過程で

  • カオスマップに掲載されているような状況では、やはり目につくサービスから解説を始められてしまう
  • 競合ロゴと並ぶと、刹那の直感勝負では強いロゴが勝つ(例えば代理店が接客ツールについて聞かれた際、いくつかのサービス資料を持っていて、2分しか時間がないとしたら?)
  • 解説中にサービスのディテールを忘れてしまっていた場合、ロゴや資料からディテールを補完して解説を続ける
    のようなケースが散見されはじめました。

前述のように線も弱く、中庸なつくりになっている初代ロゴは、そうした独り歩きの場面にめっぽう弱かったのです。
そこで現状表出されるシーンを考慮したロゴへの差し替えを決定しました。
様々な局面でプロダクトのイメージを統一的に、そして有機的に見せることができるような強く隙がないいロゴ、というのが、目標でした。

「統一的」のキーワードは、カオスマップにあっても営業資料にあっても、同じ佇まいでいられること。
ベースフォントを考える上でのキーポイントは

  • インターネットサービスであると一目でわかること
  • 営業状況を見るとネットリテラシーが高くない層にもアプローチしている。ここに対する目引きはビジュアル側からも支援が必要。
  • なので、サンセリフであることが必須条件(セリフはどうしても紙の権威の象徴となるイメージを与えてしまうため)
  • 版面率が高く、どっしりと構えて閲覧者をお迎えすること
    と設定し、歴史的な信頼感のあるTUBE – Johnston Underground(ロンドンの地下鉄)の公式フォントをベースに現代風に改良したものを採用しました。

「有機的」のキーワードは、一緒に仕事をしていたディレクターからの発案です。
「今後さまざまなノベルティ展開があったり、掲載メディアも多様になる。たとえばスマホで紹介されるような局面があった場合に、このロゴだと小さくなりすぎてしまう。我々はスマホをメインターゲットとしたサービスだというのに。」
こんな指摘をもらいました。
なので、縦長な表示であっても、ある程度どんな形のノベルティに使用するのであってもバリエーション展開の中でそのイメージをキープできるよう、マークを採用(マークの素案もディレクター発案)し、ロゴマークとロゴタイプの展開パターンを用意することで、さまざまな利用シーンに対応するようなVIセットに落とし込みました。

Flipdeskは何を成したのか。今後どうなっていくのか

僕らがFlipdeskを通じて解決したかった問題は
「全然カジュアルじゃないサイト内改善施策」
でした。

たとえばMDの限定されたECサイトが売上を上げようと考えたら、最も手っ取り早い方法が「セールを行うこと・クーポンを打つこと」、次点で「広告を打つこと」といった答えが返ってきます。「レイアウトやデザインを変更する」などのいわゆるサイト内の改善施策は、ある時はベンダーのシステムの制限であったり、またある時は社内のエンジニアリングリソース不足であったり、と、様々な障害が目の前にあり、サイトの周りにあるなかでも「最も手がつけにくく、金がかかる」という構図になっていました。
しかし、店舗を運営するにあたり、店舗という入れ物自体の改善に手を入れ難いというのは、非常に勿体無い話です。
なので、まず「目立たせるべきものを適切に目立たせる」ということに目的を絞って、ツール化してリリースしたのがFlipdeskです。
Flipdeskができることはシンプルですが、そのシンプルさを通じてまずはホットトピック(訪れたお客さんそれぞれにとっての旬な情報)=”旬” な情報の取り扱いに慣れて欲しかった。
どんなWEBサイトでも、運用状況がアクティブであれば必ずホットトピックが存在するのですが、現状ではWEB運用上の制約(できないこと)が多すぎて、その存在すら認識していないケースが多かった。そのお店の中でまず何をみて欲しいのかを誰もはっきりと認識していなかったということです。だから、店舗にまず来たお客さんに対する「いらっしゃいませ」を変更するのに、ものすごく冗長な手続きが要るんですね。そういう状況を変えたかった。
これが市場・業界に対するメッセージです。(もちろんそんな意図とは関係なくセンスの良い顧客によってさまざまな面白い使われ方が生み出されたりはするわけですが。笑)
店員さんが「いらっしゃいませ」の後に、今お店の中で一番耳寄りな情報を話し伝える、そんなイメージをそのままビジュアルに落とし込んだのが、Flipdeskのマークです。

そして、同時に僕らがこのサービス展開を通じて見ている未来は
「WEBってこんなものじゃない。もっといろんなことができる」
です。

なぜ5年前は誰もWEB上でチャットを使わなかったのでしょうか?(これは、FlipdeskをはじめとしたWEB接客ツールが解決しました)
なぜ今はWEB上で相手の顔を見て会話ができないのでしょうか?
どうしてWEBは僕の顔を見ただけで「あぁ、この人は男だな」と判断してくれないのでしょう?
いつまで僕らは検索ボックスに面倒なキーワードを打ち込んで質問しなければならないの?

こういった疑問や不満を解決できる技術をすでに世界の技術者は持っています。
そうした不満が解決された世界は、誰かがその気になればフッと世の中に現れてくるわけです。
そうすると、WEBは今では誰も体験したことがない楽しみ方ができるプラットフォームになります。
現在でもまだまだカタログ式自動販売機でしかないECサイトにもどんどん変化が訪れてくるはず。
マーケティングが変わるでしょう。
MDの考え方が変わるでしょう。
サイト運営スタッフの構成だって変わるでしょう。
そんな世界を顧客とともに睨んでいきたい。というのが、プロダクトを生み出した立場の本当の思いです。

僕とデザイン

ここまではプロダクトの話をしました。ここからは少しだけ僕とデザインそのものの話をしましょう。

VIの対価はよく「無料〜ラーメン一杯〜数百万円〜数千万円」と揶揄されます。
ビジュアルの価値の優劣はなかなかわかりにくく、時にクリエイターは水商売と同じだ、とも例えられます。

ビジュアルの価値は直感の精度であるとか、デザイン理論の積み重ねだとか思われがちですが、本当のところは想像力です。
どのような媒体に、どのように掲載され、どう、どのような人の目に触れ、どう使われ、どのような競争相手と並び、人はそれをどう思い返すのか、時勢は何を後押しし、なんの表現を本質と歪めているか、などの「それが在る状況」をできる限りくまなく想像できる力が、そのまま作品の深みになります。
そして、そこから生まれた抽象的な共通点を経験や知識、世の事例に当てはめてみたり、時には実験的な要素の効果を仮定して組み込んで新しい表現方法にチャレンジしてみたり、といった社会に寄り添わせるような行程を経て具体化し、初めてひとつのアウトプットになります。

僕は、ビジュアルデザインが商業的に必要とされているものである以上、その価値はアウトプットの安定感だと考えています。
それを支えるのが「深み」の存在であり、限られた時間でどこをどれだけ深掘りしていけるかというセンスは、世の中でしか養われません。
なので、デザインビジュアルを支える人やチームは、人生を通じて世の中を良く観察する必要があります。そして、世の中を見る角度を意図的に変えられる力を身につける必要があります。
時には子供の視点、異性の視点、時には半年後、3年後の未来を歩いている人の気持ちになって、世に送り出される作品を眺める視点が必要です。

デザイナーはそれがビジュアルやサウンドであっても、体験であっても、プロダクトエンジニアリングの一部であったとしても、まして、事業デザインの一角を担う場合でも、どんな時も抽象(概念)と具体(社会)を結びつけることがそのプロフェッショナビリティです。
そして、社会に出る具体的なアウトプットはどんなに広い抽象から導き出すにしても常にたったひとつしかないという宿命を持っています。

僕はその宿命と対峙する面白みは、人生を賭けるに値するほどのものだと思っています。
だから僕はCTOであり、アートディレクターであり、デザイナーであるというような人生を送っていますが、エンジニアリングをする時も、事業を構築する時も、街の開発コンセプトをひねり出す時も、常に僕の根底はデザイナーなんです。

逆にいうと、今デザインを担っている人は、自分がその後どんな職種や業界に抜擢されたとしても対峙できる根底の考え方を構築する必要があります。
どんな業界や職種とも相対する可能性があるのもまた、デザイナーだからです。

また機会があれば、どこか(別な媒体かもしれませんが)で「具体をまとめて流れを作る」ことを担うアートディレクションという概念を紹介しましょう。
この概念は、メディアとコンテンツ、人とSNSの関係性を解釈するのに、とても便利なものです。
日本や世界の情報発信産業が、この概念をどう捉え、導入して来たかを紐解くと、さまざま面白い答えが見つかります。

株式会社Socketは本日をもってSupership株式会社に合併します

先般からリリースにて告知させていただいている通り、僕と安藤、安達の3人で立ち上げた株式会社Socketは、2017年2月を持ってSupership株式会社に合併完了、その一部となります。

全てを整理し、吟味した結果に残る変化は前向きなことばかりであるというのに、理屈ではない泪が溢れ落ちるというのは、僕にまだ昭和の血が残っている証拠でしょうか。

このベンチャー不況が囁かれる日本市場において、実績ある事業会社からの溢れんばかりの信頼を受け、統合、合併に至った系譜は、僕らが信じて来た道を鑑みて余りある光栄でした。
それもひとえに信じて関わり続けてくれた圧倒的に優秀なメンバーの賜物だと言えます。みんな、本当にご苦労様でした。

また、統合がうまく合わなかった時のための心配性ならではの準備と覚悟も済ませ、これから一緒になる会社に一心に打ち込ませていただいた1年半でしたが、それらの覚悟や心配は全くの杞憂だったと言えます。
僕らが身を投じた環境は、信じて関わり始めてくれたメンバーの全員に対し『ここは安心して仕事に打ち込める』と言えるものであったからです。
集まっているメンバーの様々な背景に裏付けされた事業ポテンシャルは、ワクワクすら感じさせてくれるほどのものでした。

ですが、いま、これから未来を改めて切り拓いてくメンバーに送るメッセージは、数年前となんら変わりなく『今と未来を鑑みて、懸命に生きろ』です。
ハコが変わっても、世界が変わっても、僕は同じメッセージを発信し続けたいと思います。
そうやって生きてる人間のパワーこそが事業と世界を、そしてその人の人生をも良い方向に導くということを37年間の人生の中で嫌というほど学んで来たからです。

また、これまで僕らに期待し続けていただいたクライアントの皆様にも、改めて感謝を申し上げます。
今後新生Flipdeskとその周りを取り巻く環境により一層ご期待ください。

僕らはまた新しいスタートラインに立ちました。
前回と違うのは、味方の数がケタ違いに膨れ上がったことですが、そんな中でまた従来のメンバーも交えて新たな挑戦の門出を切れることを、心から嬉しく思います。

今後とも、Flipdeskを、新しいハコとなるSupershipをよろしくお願いいたします。