2019 年 6 月の Google コアアルゴリズムアップデート

2019 年 6 月の頭に Google が検索結果のコアアルゴリズムをアップデートしたらしい。

【Google】2019年6月3日、コアアルゴリズムアップデートを実施 | デジタルマーケティングブログ

【Google】2019年6月3日、コアアルゴリズムアップデートを実施 | デジタルマーケティングブログ

【更新】2019年6月3日 コアアルゴリズムアップデートのロールアウト開始Googleは、2019年6月3日よりコアアルゴリズムアップデートのロールアウトを開始しました。今後、数日間で変更が反映されていくとのことです。

digitalidentity.co.jp

自分のブログはこの影響をもろに受けて、アクセス数が激減してしまった。自分ではよく分かっていなかったが、コアアルゴリズムアップデート前は痔ろう関係の記事が結構 Google で上位に表示されてたみたいだ。 6 月のコアアルゴリズムアップデートではお金や健康系の記事に対する評価基準が変わったらしい。より専門的で正しい情報を掲載しているサイトの方が上位に表示されるようになったみたい。自分のブログは個人の日記レベルのことしか書いてないので評価が下がり、表示順位が下がるどころではなくそもそもほとんど表示されないようになってしまった。

肛門周囲膿瘍の検索歩フォーマンス

狙って病気やお金のことを書いていたわけではなく、1000 件程度ある記事のうちのたまたま数件がお金や病気について書いてあって、それが結構アクセスを集めていたわけだが、それらが検索結果に反映されなくなってしまったので検索流入が激減してしまった。

お金や健康に関しての情報について、専門家が書いているわけではない記事が検索結果で上位表示されるのは確かに問題なので今回の Google のアルゴリズムアップデートは一ユーザーとしてはありがたいことだけど、 Google のお気持ち次第でこうもアクセス数が減るものかとビックリしてしまった。

『プラットフォーム革命』という本を読んで非常に考えさせられることが多かった。かつては一世を風靡したものの今では名前も聞かなくなった Nokia と BlackBerry がスマートフォン市場で僅か数年で Apple と Google に敗北したというエピソードから話が始まる。非常に衝撃的だった。この本を読むまで自分はソフトウェア企業で働いているという認識を持っていたけど、その視点では本質を見誤ると思った。自分が作っているのはソフトウェアではなくプラットフォームなのだということを意識させられた。

そもそもプラットフォームとは何か

プラットフォームとはマッチングの場所で、何らかの価値を提供する生産者と、その価値を評価して対価を支払い消費する消費者に二分されるサービスのことを指す。ウェブサービスが一番分かりやすい。例えば Uber や Airbnb はプラットフォームだ。日本ではメルカリなんかがプラットフォームの代表例だろう。 Nokia や BlackBerry を崩壊に追い込んだ iOS や Android のエコシステムもプラットフォームといえる。

なぜプラットフォームは強いのか

Nokia や BlackBerry は世界中の開発者が自由にソフトウェアを提供できる環境を用意できなかった。 BlackBerry はセキュリティとハードウェアキーボードこそがユーザーが求めているものであると断定し、自由に開発者がアプリケーションを開発できる環境を用意しなかった。 Nokia は開発プラットフォームを構築しようとしたが、 Symbian OS は開発者を惹きつけるプラットフォームではなかった。 Apple や Google は自分達だけで最高のスマートフォンを作ろうとせず、世界中の開発者に場所を提供して、自分達だけでは想像もできなかったようなアプリケーションを開発してもらい、ユーザーに届けた。結果はご覧の有様だ。この本では BlackBerry のようなビジネスモデルを直線的ビジネスと定義し、 20 世紀から続く古いビジネスモデルであると揶揄している。

プラットフォームを構築することなく、作った製品を販売するだけの企業はそのうち衰退してしまう。プラットフォームというビジネスモデルは既存のビジネスよりも圧倒的に効率的で成長速度が速く、またほぼ無限といえるほどのスケーラビリティを備えているからだ。単にソフトウェアを売るだけのビジネスモデルではソフトウェアやネットワークの特製をうまく利用できておらず、 20 世紀からある物作りサービスと本質的には変わらないビジネスにしかなり得ない。ソフトウェアを売るだけのビジネスでは製品の配布や顧客の維持に課題を抱え、プラットフォーム型の同業者に参入され市場を支配されてしまうだろう。かつては市場を我が物にしていた日本の電気メーカーが中国・韓国勢に劣勢を強いられているのも根本的にはビジネスをプラットフォーム化できなかったことが原因だといえると思う1

最近、リストラを発表したマップルなどを作っている昭文社もプラットフォーム企業との闘いに苦戦している直線的ビジネスの良い例だろう。 Google Maps や、その仕組みを利用した食べログや Retty 、旅行情報アプリの隆盛により赤字に転落し、リストラを強いられることになってしまった2

イノベーションがプラットフォームを可能にした

この本はインターネット企業のビジネスモデルについて書かれた本だが、経済学とイノベーションの歴史にも触れつつ、なぜプラットフォームが支配的になってくるのかが書かれている。 20 世紀の中頃、資本主義の経済学者ハイエクと社会主義国ポーランドの経済学者ランゲによって、経済計算論争というものが繰り広げられた。物の値段を政府が決める(社会主義)のと市場に任せる(資本主義)のではどちらが効率的か、という論争だ。ハイエクの見解が優勢で(のちにハイエクはノーベル経済学賞を受賞した)、その後の経済学の考え方のベースになった。売り手は他人に対して積極的に情報を開示しないので物の値段を政府が決めるのは難しく、市場で決まる値段こそが効率的な資源配分を実現する、という考え方だ。しかしコンピューターとネットワークが当時とは比べ物にならないほどに進化した今日では、政府ではなくプラットフォームがプラットフォーム内部の情報に関して細部にいたるまで把握することが可能で、最適な値段を計算することが可能になった。実際に Uber は場所と時間に応じて乗車料金を変動させている。

ある意味で現在のグーグルは、強大なソ連が実現できなかった社会主義のユートピアを作りつつある。

アレックス・モザド; ニコラス・L・ジョンソン. プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか (Kindle Locations 1437-1438). 英治出版株式会社. Kindle Edition.

社会主義者が夢見たユートピアをシリコンバレーのテクノロジーカンパニーが実現させた。そのユートピアはプラットフォームと呼ばれるものだが、そこは効率的な取引を参加者に促す一方、自らはプラットフォームがもたらす強力なネットワーク効果により市場でますます支配力を強めていく。どんな SNS も Facebook には対抗しようがないし、どんな検索エンジンも Google のシェアを奪うことは難しいだろう。少なくとも、プラットフォームでない企業がプラットフォーム企業に立ち向かうことは無理だと思う。

評価経済やトークンエコノミーの下地にある経済システム

一昨年、仮想通貨の文脈で『お金2.0』という本が流行って、会社でも回し読みした。価値や評価、信用が重要というのは何となくわかったが、なぜ価値や評価や信用が重要になるのかがはっきりしなかった。あの本に書いてある考え方を可能にするものこそがプラットフォームなのだと思う。お金2.0を読んでしっくりかなかった、という人にもこの『プラットフォーム革命』はおすすめです。

追記 2019/01/21

7 年前にはてな匿名ダイアリーに投稿された以下の翻訳記事がまさにプラットフォームの重要性を説いており面白かった。プラットフォームのないプロダクトはプラットフォームのあるプロダクトに置き換えられる、プラットフォームになるためには外部に整備された API を提供し、外部の開発者の力を借りる、人が欲しがるものを自分で作ろうとしないこと、などはまさにこの本で書かれていることと同内容だった。 Google+ しかり、 Google が SNS を作ろうとして失敗するのはプラットフォーム化しようという意識が乏しいからなんだろうなぁ。確かに Google の API はどれも使いづらい。


  1. アメリカ企業が作ったプラットフォームに中国・韓国勢が低コストでハードを提供するが、日本勢は自らプラットフォームを構築することもできず、そのプラットフォームに参加することもできなかった、あるいは参加が遅れた。 

  2. 昭文社が希望退職者を募集、業績予想も下方修正---無料ナビアプリの影響(レスポンス) - Yahoo!ニュース 

DSC_0233

サイトの横幅( max-width )を 1280px に広げてみた。最も頻繁にこのサイトを訪れる自分の閲覧環境が 5K ディスプレイになったので昔の環境( 13 インチの MacBook )に合わせて作ったデザインでは横幅が間延びした感じがあっていまいちだった。文字サイズもちょっと小さかったので 15px から 18px にした。 cho45 さんがまえブログに書いてたけど、自分のディスプレイを大きくして画像を大きいサイズで見る機会が増えて、大きい画像の尊さのようなものを感じるようになってきた。

大きな画像っていうのはそれだけで強い主張があります。かつてあった「体験」を呼び起こす力が画像の大きさと解像度にはあります。そこにいて、そこでこう見たのだという主張のため、とにかく大きいのは正義なのです。

サイトの画像サイズを再びアップグレード | tech - 氾濫原

Flickr から埋め込み表示している画像は ebmed タグの中で width と height が固定されているので本文幅に合わせるためには手でちまちまと大きいサイズに変えていかなければならない(おいおいやっていきます)。

2018 年 7 月 10 日に天神の Fusic 社で開催された Scrapbox Drinkup #5 に参加した。

Scrapbox Drinkup #5 Fukuoka Edition (2018/07/10 19:00〜)

Scrapbox Drinkup #5 Fukuoka Edition (2018/07/10 19:00〜)

## Scrapbox Drinkupについて Scrapbox Drinkupは『チームのための新しい共有ノート』であるScrapboxのユーザー(にこれからなる人も含む)と開発者で集まってカジュアルに情報交換をしようという会です!! Scrapboxの近況と今後のア...

nota.connpass.com

Nota 社の皆さんが福岡に訪れてユーザーと情報交換するという趣旨のイベントのようだった。 Scrapbox はほとんど使ったことなかったが、 @masui 先生や @shokai さんの発表が聞けるということなので行ってみることにした。

Nota 社のイベント、他社の採用目的感あふれるイベントと異なり牧歌的な感じがとてもよかった。 Nota 社の皆さんも参加者と同じテーブルに座ってピザ食ったりビール飲んだりでざっくばらんな感じだった。

最初にパスタケさんの概要説明的な話があったあと、 @masui 先生や @shokai さんの発表を聞いて「使ってみたい!」という気持ちが強くなり、発表を聞きながら一つプロジェクトを作った。

実は Drinkup 参加前に @ssig33 さんが書いていた Scrapbox についてのブログ記事(ssig33.com - Scrapbox Drinkup #4 にいってきた)を読んでいて「ふ〜ん」くらいに思っていたのだが、実際に利用事例やできることを知って、確かにこれは面白いものだなと思った。

@ssig33 さんが書いている通り、 Scrapbox は単に知識を集めて検索可能にするためのものではなく、コミュニケーションツールだなという感じがする。なので MTG の議事録などを複数人でとって理解が曖昧だったところを確認・補強したりするのに非常に向いてるだろうなと思った。リモートワーク主体のチームが Scrapbox を導入したら MTG の生産性が高まるのではないかと思う。

個人的に Scrapbox に対して良いなと思ったのは以下だ。

  • 共同編集
    複数人で同時に編集できる楽しさ
  • ドキュメント間のリンクが容易
    ハッシュタグやリンクは相互参照される
  • 動画や画像を簡単に貼れる
    コピペで画像をアップロードできる
  • 投稿・入力の敷居の低さ
    枠や升がなく、必須入力やバリデーションなどもほぼほぼなさそう
  • 検索

それぞれはすでにすぐれたツールが存在していると思うが、それが一つのツールですべて使えるようになっているところが便利なのだと思う。

以前アウトライナーについて記事を書いたことがあるが(アウトライナーで文章を書く - portal shit!)、その中で紹介したものに WorkFlowy というアウトラインプロセッサーがある。個人が思考を整理しながら文章を書くのに非常に適したソフトで、 Scrapbox に似ている側面があると思った。

WorkFlowy はアウトライナーからファイルやタイトル、ノードという概念の区別を取っ払い、すべての情報をノードとして扱いツリー構造にしてしまう。おかげですべての情報が容易に検索可能になり(情報がファイルで分割されない)、検索性も向上して知識の保存と参照が劇的にしやすくなる。 Scrapbox では階層構造を作ることはできないが、すべての情報はフラットな空間に書きためられ、それぞれの情報を非常に参照しやすいかたちでリンクさせることができる。

Scrapbox と WorkFlowy が大きく異なる点は、これらの情報を容易に共同編集できるかどうかだと思う。 WorkFlowy は非公開状態がデフォルトで、他者に閲覧を許可したり共同で編集したりするためにはその為に専用のリンクを発行して共有のレベルを設定しないといけない。 Scrapbox はデフォルトが公開状態で(少なくともプロジェクトの参加者の間では)、特に設定することなく情報を共有したり共同で編集したりできるようになっている。 URL は当然ながらドキュメントを作成したタイミングで生成される。わざわざ共有用 URL を発行する必要はない。デフォルトでは URL が存在しないため、 WorkFlowy ではドキュメント間のリンクもしづらい。

このように Scrapbox で初めて得られる文章編集体験というものが確実に存在すると思う。


個人的に作ったやつは会社の G Suite 内の Google Maps にあったランチスポット情報を集約したやつをエクスポートしたもの。Drinkup で @masui 先生が「ヘルプドキュメントの類を Scrapbox で構築したら便利なはず」という話をされていた1のに着想を得た。職場が福岡市の中心部でもマイナーなエリア(旧来の博多の街の中心部だけど天神と博多駅からも微妙に離れていて飲食店が少ない)にあり、食べログなどで探してもあまり有益な昼食スポットの情報が得られないため、これまで社内で情報をストックして共有していたが、この手のものは一社で作るよりも界隈にお勤めの皆さん全体で共有した方が効率がよいはず。 Scrapbox がこの用途にはピッタリなのではないかと思って作ってみた。

呉服町ランチ

呉服町ランチ

はじめに / 和(なごみ) / 【閉店】金田家 / 【閉店】バストラ / ケンケンチ / めしや獏 / 食処 笑ん / やつがい処柊家 / 大博軒 / 洋食ビストロむろ屋 / 釘本食堂 / 喰しん房松むら / 楽笑 (ラクショウ) / STEAK BAR BEVU / ステ...

scrapbox.io

Spread Sheet や Google Maps の Data Table による管理では複数人からの情報を良い感じにまとめることができず、多くの人から情報を集める、という点で難があった。 Spread Sheet は入力しやすい UI であるとは言えないので、入力する側に根性や気合い、熱意が求められた。 Scrapbox であればテキストファイルに文章を入力するのと同程度の手軽さで情報を入力していくことができる。入力欄に枠や升があるわけではないので自由気ままに書くことができる。これは書き手にとって大いにストレスの軽減になると思われる。

もし福岡市地下鉄貝塚線呉服町駅周辺のランチスポット情報をお持ちの方がおられましたら以下のページから登録して情報共有しませんか。よろしくお願いいたします。

Scrapbox

Scrapbox

scrapbox.io


  1. 実際に Scrapbox のヘルプページは Scrapbox で作成されている。 Scrapbox ヘルプ 

契約中のサービス

Apple Music

何度も一ヶ月だけ契約して試しては解約し、を繰り返していたけど、 Circle 2018 に行ったあとに出てた人たちの音楽をまとめて聞きたくなって契約した。全部アルバム買うと 2, 3 万になるのがファミリープランでも 1480 円/月で済むのはいい。人間は音楽を買ってもそのうち聞かなくなる。聞きたい間だけお金を払うのが正解なのかもしれない。

ただ有名ミュージシャンの曲や懐メロのオリジナル版は相変わらず Apple Music にはなくて(カバーはいっぱいある)買わないといけないので注意が必要。ゴレンジャーの曲とか聖闘士星矢の曲のオリジナル版は iTunes Store で買った。

Spotify にしない理由は macOS や iOS との統合された使い勝手を重視しているから。たまに切り替えて使ってみるのもよいかもしれない。

Netflix

深夜食堂を見たくて入ってる。その他、アメリカのドラマも時々見る。電車の中で見たいけど結構エロシーンが多くて困る。イギリスのクッキング対決番組も面白い。とはいえ元とれてる感じはしないので Rebuild で話題になるドラマなんかをさっと見て解約したい。

Amazon Prime

Amazon のクレジットカード( Master )の特典で付いてくる。様々な割引を組み合わせたカードの年会費が 3940 円でプライム年会費と同じ。 Master カードはコストコでの支払いにも使えるようになったので便利。 1% ポイント還元。

Prime ビデオに関しては割と頻繁にラインナップの見直しあってて見たいやつがなくなるので見られたらラッキーくらいのつもりで利用しないと逆にストレス溜まる。

The Old Reader

RSS リーダーの中で最安なので使ってる。検索が厳しい。たぶん全文検索エンジン使ってなくて DB から LIKE サーチしてる気配を感じる。 Inoreader に乗り換えを検討した方がよいかもしれない( Feedly は好きになれない )。

さくら VPS 2GB プラン

このブログを動かしている。まぁまぁ高いが AWS や自宅サーバーで運用するのに比べたら十分経済的。

AWS

Route 53 と S3 、 CloudFront のみ利用している。 毎月 200 〜 300 円くらい。

解約したサービス

GitHub private repo

Microsoft に買われて自分ごときの金なしおじさんが利用料を払う必要もなかろうと思い解約。大したコード上げてなかった。秘密情報的なやつは GitLab に移した。

Flickr Pro

自己顕示欲を満たすために人に写真を見せる、ということがなくなったので解約しようと思っていたが、 2 年おきの更新なのでうっかりしてて 2020 年まで自動更新されてしまった。とりあえず自動更新を停止にした。

iTunes Match

Apple Music に移行したので自動更新を停止した。

Facebook にウェブサイトの URL をはっつけるとき参照される HTML メタ情報の仕組みに Open Graph Protocol ってのがある。 Facebook に URL を貼ると bot が URL の内容を読みに行ってページの概要や画像を取得し Facebook 内に埋め込み表示するというもの。 Facebook を見ている人はリンク先の内容をクリックする前に概要を把握できるので、リンクをクリックして見たい情報じゃなかった、ということを避けられる。 Facebook が考案して策定した仕組みだけど、 Facebook に限らずいろんなサイトで OGP タグを出力してるし読み込んでる。 Twitter にも似た仕組みあって Twitter Card という。この辺の対応は結構前にやってた。

アドベントカレンダーに備えて Open Graph protocol に対応

アドベントカレンダーに備えて Open Graph protocol に対応

昨日飲みに行って今朝起きてからふとコード書きたくなって、アドベントカレンダーもあることだし(去年の Adventar で自分のブログだけ og:image がなくて画像が出てなくて残念だった)、このブログを Open Graph protocol に対応させることにした。T...

portalshit.net

ただ自分のサイトが OGP タグを提供するだけではつまんないなと思ったので自分のブログにペロッと URL を貼ったときに相手先に OGP タグがあればそれを出力するようにしてみた。こんな感じ。

OGP Preview

しかしここで困ったことがあって、↑でリンクしてる Circle のサイトは HTTPS で配信されておらず、単純に Circle のサイトで og:image に指定されている画像を SSL 化されているこのブログで読み込むと Mixed Content になってしまう。せっかく HTTP/2 で配信していたのに台なしになってしまう。またそもそも og:image は Facebook でシャアされることを想定されていることがほとんどなので、画像サイズがデカすぎていい感じにスクエアに表示するためには CSS の小技を駆使したりする必要があった。

いい感じに解決する方法ないかなと調べていたら良いのが見つかった。

willnorris/imageproxy

willnorris/imageproxy

A caching, resizing image proxy written in Go. Contribute to willnorris/imageproxy development by creating an account on GitHub.

github.com

Go で書かれた Image Proxy Server で、 HTTPS Proxy は当然のこと動的リサイズもできる。使い方は簡単でバイナリを落としてきて動かすだけ。 Go なんで ImageMagick をどうしたりとかを考えなくて良い。 そもそも Docker イメージも提供されているので Docker をインストール済みなら docker run するだけでも動く。 めっちゃお手軽。

こいつのおかげで HTTPS で配信されていないサイトの OGP タグを読み込んでも Mixed Content にならずに済むようになった。また og:image は適切にリサイズできるようになった。画像変換サーバーとかは結構難しいやつで個人のブログでこんなに簡単に使えるものだとは思ってなかったので正直ビックリした。

AWS の登場で大企業じゃなくても CDN 使ったり仮想サーバーでウェブシステムを構築したりできるようになった。さらには Go や Docker といった技術のおかげで複数の込み入ったソフトウェアを組み合わせて構築していく必要があったシステムが、まるで jQuery を使うような感覚でポン付けで使える時代になってきている。とても素晴らしい。

ちなみに OGP の取得には open_graph_reader という gem を使っている(昔からある opengraph という gem はメンテナンスされておらず最近の Nokogiri で動かない)。 open_graph_reader の作者が結構 Opinionated な人で、以下のような Anti-featurs を掲げている。

open_graph_reader Anti-features

http://ogp.me/ の仕様に準拠していないサイトのことは完全無視というつくり。個人的にはこういう思想は好みだが、現実問題として使い勝手が悪い。例えば hitode909 さんのブログの OGP タグを取得しようとしたところ以下のようなエラーを出して取ってくれなかった。

スクリーンショット 2018-05-26 10.08.47.png

article:published_time は ISO8601 形式の datetime であるべき、とのこと。はてなブログはかなりシェアが大きくリンクする機会が多いので残念。