portal shit!

ずっと過去記事をどうやって効率よく見せるか（自分自身が効率よく読むか）ばかり考えている。一つ前の記事では絞り込み UI について書いた。

Archive ページの絞り込み UI をセレクトボックスに

一個前の記事のキャプチャにあるように、従来テキストリンクだった年とカテゴリーの選択をセレクトボックスにした。 git log -S したところ去年（ 2019 年）の 11 月頃に変更を行ったみ...

portalshit.net

ブログというものが生まれたとき、誰も 10 年以上にわたってインターネットに文章を書くことを考えていなかったと思う。多くの人は途中で脱落してブログを止めたり飽きてほかのところ（ Facebook や Twitter ）に移ったりしただろう。ただ、同じ場所でしぶとく書き続けている人たちもいる。自分もその一人だ。

そういう人たちにとって、過去に自分が書いた記事をどうやって閲覧するかというのは大きな問題だ。過去記事を探すのに本文込みの一覧ページをページネーションしていくのはあまりにも効率が悪すぎる。一覧でガッと見たい。

というわけで、インターネット老人にしか用のない機能かもしれないが、過去記事一覧ページの UI/UX は非常に大きなテーマだと思う。問題点と対策を整理してみた。

過去記事が溜まることの問題点は、過去記事が探しづらくなることだ。対策としては各記事に関連記事へのリンクを表示する方法と過去記事の一覧ページを用意して探しやすくすることがあると思う。

過去記事の一覧ページは以下を満たしていて欲しい。

1. 記事を一覧できること
   • 一覧性が重要なのでページネーション、本文は不要
   • 記事の作成日（公開日）順に並んでいて欲しい
2. 記事を絞り込めること
   • 年やカテゴリーで絞り込めるとよい
3. 件数がわかること
   • どの時期にどの密度でブログを書いていたかがわかるため

10 年以上続いてるブログを書いてる人たちは多かれ少なかれ同じような問題（過去記事へのアクセシビリティ）を抱えているはずで、他の人たちがどうやっているのかを調べてみた。以下は長く続いているブログの Archive ページ。

Hail2u

ながしまきょうさんのブログ。

雑多な記録

ウェブ開発に関する話題が中心でしたが、もはやそれに限らず備忘録に近いものです。

hail2u.net

ブログのトップ自体が過去記事インデックス（タイトルのみ）になってる。本文を含む記事一覧ページはない。静的に生成してあって速い。絞り込むような UI はない。

氾濫原

関連記事のアルゴリズムやデザインなどを結構パクらせてもらっている cho45 さんのブログ。

アーカイブ - 氾濫原

lowreal.net

本文込みの一覧ページとは別に年がずらっと並んでいる。記事の一覧はない。クリックすると年月ごとの記事一覧（本文込み）が表示される。記事を書いた時期を覚えておく必要がある。

Daring Fireball

Markdown の生みの親、 Apple ブロガー John Gruber のブログ。

Daring Fireball: Archive

daringfireball.net

本文込みの一覧ページとは別に年月ごとにグルーピングされた記事一覧（タイトルのみ）がある。このブログの Archives ページの UI に近い。検索窓があるが、 DuckDuckGo のサイト内検索に飛ばされる。スマートフォン用の画面がなく非常に見づらい。

hitode909の日記

hitode909 さんのブログ（はてなブログ）。

記事一覧 - hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

blog.sushi.money

本文込みの一覧ページとは別に、本文が短く表示される過去記事一覧ページがあるが、一覧性は高くない（ページネーションが必要）。グローバルフッターに年月ごとの記事一覧へのリンクがあるほか、サイドバーにもカレンダー式のアーカイブ導線がある。「月別アーカイブ」は年をクリックすると月別のアーカイブ一覧が展開表示される。デフォルトだと今年（最新年）が展開表示されている。年・月・カテゴリーそれぞれの記事数がわかるのは便利だと思う。

Tatsuhiko Miyagawa's Blog

Blog Hacks の著者 miyagawa さんのブログ（ Medium ）。 Bulknews 時代からの過去記事がいっぱいあるはずだけど現在は 2011 年分からしか公開されていないみたいだった。

Archive | Tatsuhiko Miyagawa’s Blog

A blog about software engineering, podcasting, gadgets, and productivity.

weblog.bulknews.net

タイトルのみの記事一覧ページはなく、一覧性は高くない。本文込みの一覧ページの上部に、年ごとの絞り込み UI が表示されている。年を選択すると月ごとの絞り込みができる。はてなブログに近い。

Medium が酷いのはこのアーカイブページへの導線で、トップページには最近の記事が数件表示されるだけで、過去記事への導線はページ下部に申し訳程度に置いてあるのみ。しかも Medium というサービスの利用規約ページへのリンクと並んでいるので存在に気がつきにくい。

先日の記事（ 蟻地獄と個人ブログ - portal shit! ）では Medium はまとも陣営に分類したけど、個人のブログ内で回遊することを極力できないようにしようとしているのが伝わってくる。蟻地獄感ある。

Island Life

『ハッカーと画家』などポール・グレアム本の翻訳もされている shiro さんのブログ。

Archive/l0

Island Life

blog.practical-scheme.net

本文込みの一覧ページとは別に、本文が短く表示される過去記事一覧ページがある。年による絞り込みがあり、少し前のこのブログの Archives ページに近いが、 2002 年から記事があるので年のリンクが 19 個ある。 10 年後、 20 年後のことを考えると UI 上の問題が発生しそうだ。

portal shit!

最後にこのブログ。

portal shit!

森井ゴンザレス（ morygonzalez ）のブログ。 ブログを書くこと、プログラミング、インターネット、 Mac の便利なソフト、働くこと、ランニングについて書いています。

portalshit.net

本文込みの一覧ページとは別に年月ごとにグルーピングされた記事一覧（タイトル、カテゴリー、日付が表示）がある。年やカテゴリーによる絞り込みができる。

考察

Hail2u 、 Daring Fireball 、 Island Life など記事のタイトル一覧が表示されるタイプが好みだ。 Medium の一覧性のなさは最悪だが、年月の絞り込み UI はおしゃれだと思った。

個人的にはこのブログの Archives ページが一番使いやすい。自分で作っているので当たり前だ。スマートフォンでの閲覧性も問題ない。記事一覧の状態で本文で絞り込めるやつがあれば完璧なので、少ししたらチャレンジしてみたい。

一個前の記事のキャプチャにあるように、従来テキストリンクだった年とカテゴリーの選択をセレクトボックスにした。 git log -S したところ去年（ 2019 年）の 11 月頃に変更を行ったみたいだ。もうそろそろ 2020 年になろうとしていて、 2005 年からやっていて年の数が 16 個になろうとしていてさすがに多すぎると思ったので整理のためにセレクトボックス化してコンパクトにした。

利用したのは React Select というパッケージで、色々カスタマイズできるみたいだけど面倒だったので素のまま使ってる。

React-Select

A flexible and beautiful Select Input control for ReactJS with multiselect, autocomplete and ajax support.

react-select.com

GitHub - JedWatson/react-select: The Select Component for React.js

The Select Component for React.js. Contribute to JedWatson/react-select development by creating an account on GitHub.

github.com

Archives ページのリファクタリング のときのように、子コンポーネントのイベントをトリガーに親コンポーネントの setState() を呼び出すような作りになっている。作るときは結構難儀したけどおかげでスマートフォンで見たときも年やカテゴリーだけでファーストビューが埋まるということがなくなった。

現在のコードをまるっと貼り付けるとこんな感じ↓。

子コンポーネント（年のセレクトボックス）

import React, { Component } from 'react'
import ReactDOM from 'react-dom'
import Select from 'react-select'
import PropTypes from 'prop-types'
import { withRouter } from 'react-router-dom'

import history from './history'

class YearSelect extends Component {
  constructor(props) {
    super(props)
    this.state = {
      data: [],
      selectedOption: null
    }
    this.handleChange = this.handleChange.bind(this)
  }

  static propTypes = {
    match: PropTypes.object.isRequired,
    location: PropTypes.object.isRequired,
    history: PropTypes.object.isRequired
  }

  async loadYearSelectFromServer() {
    const request = await fetch('/archives/years.json')
    const response = await request.json()
    this.setState({ data: response })
  }

  componentDidMount() {
    this.loadYearSelectFromServer()
  }

  handleChange(selectedOption) {
    const year = selectedOption ? selectedOption.value : null
    if (year) {
      this.props.history.push(`/archives/${year}`)
    } else {
      this.props.history.push("/archives")
    }
    this.setState(
      { selectedOption },
      () => { this.props.update(year) }
    )
  }

  render() {
    const options = this.state.data.map(year => {
      return { value: year, label: year }
    })
    return (
      <div className="year-list">
        <Select
          value={this.state.selectedOption}
          onChange={this.handleChange}
          options={options}
          placeholder="Year"
          isClearable
        />
      </div>
    )
  }
}

const YearList = withRouter(YearSelect)

export default YearList

親コンポーネント（ App.js ）

import React, { Component } from 'react'
import { BrowserRouter as Router, Switch, Route, Redirect } from 'react-router-dom'

import YearList from './YearList'
import CategoryList from './CategoryList'
import Archives from './Archives'

class App extends Component {
  constructor(props) {
    super(props)
    this.state = {
      category: null,
      year: null,
      length: 0
    }
    this.updateCategory = this.updateCategory.bind(this)
    this.updateYear = this.updateYear.bind(this)
    this.setLength = this.setLength.bind(this)
  }

  updateCategory(category) {
    this.setState({ category })
  }

  updateYear(year) {
    this.setState({ year })
  }

  setLength(length) {
    this.setState({ length })
  }

  render() {
    return(
      <Router history={history}>
        <div className="archive-filter">
          <YearList update={this.updateYear} />
          <CategoryList update={this.updateCategory} activeCategory={this.state.category} />
          <div className="entry-length"><p>{this.state.length} entries</p></div>
        </div>
        <Switch>
          <Route
            exact path="/archives"
            render={(props) =>
              <Archives
                category={this.state.category}
                setLength={this.setLength}
                {...props}
              />
            }
          />
          <Route
            path="/archives/:year(\d{4})"
            render={(props) =>
              <Archives
                category={this.state.category}
                setLength={this.setLength}
                year={this.state.year}
                {...props}
              />
            }
          />
        </Switch>
      </Router>
    )
  }
}

export default App

S3 のバケットを事故で空にしてしまってとても悲しかったので、写真以外の画像もきちんと管理してみることにした。

😢ブログ用 S3 バケットの画像を吹っ飛ばしてしまった

ブログで使ってる Amazon S3 のバケットの画像のほとんどをミスって空ファイルにしてしまった…。 S3 に上がっている画像、 Cache-Control ヘッダーが付与されていないのですべ...

portalshit.net

これまで、仕事やブログ用に作った図表みたいなやつは作ったあと JPEG とか PNG に書き出してドキュメントに書き出した後は適当にデスクトップに置いてあって、ある程度時間が経ったら定期的に削除するような運用にしていた。図表自体は Pixelmator や OmniGraffle で作っているが、ちょっと作ったやつは元ファイルごと消してしまっていた。しかしそれでは今回のようにミスって S3 を飛ばしてしまったときにリカバリできなくなる。

というわけで Pixelmator や OmniGraffle で作ったオリジナルファイルを残していこうと思ったのだけど、これらはプレビューできないし、 Mac の中で仕事のプロジェクトのフォルダの中にあったり、 iCloud の Pixelmator のフォルダの中にあったりデスクトップにあったりで非常にごちゃごちゃしており、 Finder だけで管理するのは無理っぽいなと思った。写真以外の画像ファイルを管理できる何かが必要だと思って調べてみた。

この手のやつは Little Snapper というのを使っていたが、途中から名前が Ember に変わって Mac OS のアップデートについて行けずディスコンになった。 Little Snappter / Ember は結構気に入って使っていて、画面のキャプチャを撮って注釈の文字を入れたりする用途に使っていたが、本来はこれらはデザイナー用の画像管理ソフトだと思う。

LittleSnapper: Putting Finder to Shame Since 2008

I knew this was going to happen. The day my “Images” folder would become too big to manage in the Finder and I should switch to a 3rd party software to collect and organize all the images I have on my Mac. I’m that kind of guy that saves very cool and interesting image he

www.macstories.net

色々調べていて Eagle というソフトが存在することを知った。 Eagle はなかなかよくて、 JPEG や PNG 、 Adobe の Photoshop 、 Illustrator に加え Pixelmator や OmniGraffle に対応している。デザイン系だけでなく各所にファイルが散らばりがちな MindNode （マインドマップアプリ）や Numbers 、 PDF 、 Keynote 、 Pages 、 MS Excel 、 MS Word などドキュメント系のファイルにも対応している。

Eagle - Organize design files has never been easier

A better way to collect, search and organize your design files in a logical way and all in one place.

eagle.cool

要するにパワーアップした Finder という感じなんだけど、ファイルの中身をプレビューできて一括でタグ付けしたりフォルダ管理できるのが便利。 いわゆる「ファイルの壁」問題が解決できる。デスクトップや iCloud Drive に散らばってるやつをとりあえず一旦突っ込んで整理してみることにした。

UI は日本語翻訳があるのだけどあまり出来がよくなく、スクリーンショットを「スクショ」と略していたり、全体的に翻訳が調子こいてる若者風なのが気持ち悪い…。いまは言語を英語にして使ってみてる。日本語文字列の検索精度がいまいちなところも気になる。 年賀状 で検索しても 年賀状 という文字列を含むファイルがヒットせず、かわりに 年賀 で検索するとヒットしたりする。日本語周りに課題が多そうだ。そのほか、 Windows 版も存在するせいか、通知の UI が Notification Center の標準 UI とかけ離れているところもちょっと気持ち悪い。

同系統の Pixave というのを以前「できる Mac OS X Advent Calendar 2015」で知って試していたが、当時の自分は Little Snapper / Ember の代替となるキャプチャに注釈を入れられる機能を求めていたので用途に合わないと感じた。いまもう一度見てみて試してみたが、 Eagle 同様にデザインデータだけでなく様々なファイルを扱えて、いまの自分の用途には適合してそうだった。惜しむらくはあまり活発に開発されていないようだった（ MindNode を取り込めるとウェブサイトに書いてあるが、最新バージョンの MindNode には対応していなかった）。Pixave は App Store の賞を受賞しているだけあって見た目がめっちゃおしゃれで Apple の標準 UI に準拠しており、使い心地は Eagle よりも Pixave の方がよい。もうちょい活発にメンテナンスしてもらえたらうれしい。

http://www.littlehj.com/mac/

www.littlehj.com

しばらく併用してどっちを使うか決めたい。

※ Pixave は韓国系の人が一人で作ってるみたい。以前好きで作っていた The Hit List （ ToDo 管理ソフト）も韓国系の人が作ってた。在米コリアンは優れたデザイナーが多いのだろうか。 The Hit List はめっちゃ UI が革新的だったのに更新が滞ってしまった。 Karelia という会社に買われたあとも更新が滞っている。 The Hit List のようにならないでほしい。

外出自粛かつ自分自身にコロ助疑惑があったのでずっと部屋に閉じこもってサイトのデザインをいじってた。

上がこれまでで、左下が今後、右下が画像がワイドな場合のバージョン。これまで横幅 1280px 想定にして画像も横幅 1280px のサイズで表示するようにしていた。

サイトの横幅を広げた

サイトの横幅（ max-width ）を 1280px に広げてみた。最も頻繁にこのサイトを訪れる自分の閲覧環境が 5K ディスプレイになったので昔の環境（ 13 インチの MacBook ）に...

portalshit.net

ただしこれだと写真は見やすくても文字が読みにくい。人間の目は 1280px 繰り返し左右に移動させるのには適していないようだった（ N=1 ）。

そういうわけでまたまた cho45 さんのブログのレイアウトをパクって、文章は横幅短めに、写真はでかいサイズで表示するようにした。

文章部分の幅を 800px にして、画像を読み込んだときに一定の条件にマッチしたら写真の横幅を 1280px で表示するようにした。 margin-left: -250px; してるのがミソ。横幅 800px だと大分文章は読みやすいし、でかい写真は大きく見えて便利。

@media screen and (min-width: 1422px) {
  #content #main article .body > p {
    img[class~="large"] {
      width: $content-max-width;
      max-width: $content-max-width;
      margin-left: -250px;
    }
  }
}

JS はこんな感じのコードを書いた。

const checkImageSize = (target) => {
  if (typeof target === 'undefined') {
    return;
  }
  const width = target.naturalWidth;
  const height = target.naturalHeight;
  const isPhoto = RegExp('(lh3\.googleusercontent\.com|\.jpe?g$)').test(target.src);
  if (width > 1279 && width > height && isPhoto) {
    target.classList.add('large');
  }
}

const lazyImageObserver = new IntersectionObserver((entries, observer) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const lazyImage = entry.target;
      lazyImage.src = lazyImage.dataset.src;
      lazyImage.addEventListener('load', (event) => checkImageSize(event.target));
      lazyImageObserver.unobserve(lazyImage);
    }
  });
});

const selectors = "#content article .body img, #content article .similar img";
const lazyImages = [].slice.call(document.querySelectorAll(selectors));

if ("IntersectionObserver" in window) {
  for (let image of lazyImages) {
    const src = image.src;
    image.dataset.src = src;
    if (lazyImages.indexOf(image) === 0) {
      const promise = new Promise(resolve => resolve(image));
      promise.then(checkImageSize).catch(setTimeout(checkImageSize, 100))
      continue;
    }
    image.src = "";
  };

  lazyImages.forEach(lazyImage => {
    lazyImageObserver.observe(lazyImage);
  });
}

画像の読み込みが起こったタイミングにフックして画像のサイズチェックを行い、条件にマッチしたら img タグに class を追加し、 CSS のメディアクエリと合わせ技で大きく表示するようにしている。以前やった画像の遅延読み込みのコードを改良した。

CloudFront 転送量削減を試みる

関連記事に画像を表示するようにして喜んでいたが、先月の AWS の請求額を見てビックリ。普段の 15 倍くらいの金額になっていた。デイリーの利用料金を見ると関連記事に画像を表示するようになった日...

portalshit.net

その他、 HTML 5 対応が中途半端だったのでマークアップを見直して、適度に <header> や <secition> 、 <article> 、 <footer> を使ってマークアップし直した。 このせいだと思うけど Google Adsense の自動広告が差し込まれる位置が変わった。これまでヘッダーの下に入り込んでいたやつが <header> と <article> の間に入るようになった。

今後も外出禁止が続いたらひたすら自分のブログをいじってしまう予感。こういうエネルギーを仕事とか個人サービス開発とかに当てられるとよいのだろうけどなかなかそういう方向には向かない。

最近、やたらこのブログにスパムコメントが来るようになった。コメントがあったらメールで通知されるようにしてるのだけど、コメント通知メールが一日十件くらい届く。

Google の reCAPTCHA を入れたことでほぼほぼスパムコメントは弾けていたのだけど、最近のスパムは reCAPTCHA をすり抜けるようになってしまったっぽい。加えて Akismet のスパム判定ロジックもポンコツになってしまったようで、ほぼほぼすべてのコメントをスパムと判定しなくなってしまった。

Lokka では Akismet でスパム判定されたコメントは一括削除できるようになっている（この機能は自分で作った）が、スパム判定されなかったコメントはちまちま一つずつ削除しなければならないのが非常に煩わしかった。

なのでコメント一覧にチェックボックスを表示して、チェックを入れたコメントを一括で削除できるようにしてみた。めっちゃ便利。

Akismet プラグインも少し改造して、自分で NG ワードを設定できるようにした。最近のスパムは露骨に Viagra とか Cialis みたいなキーワードが入ってて、どうしてこんなわかりやすいやつを Akismet は素通りさせてしまうのかわからないのだけど、自前の NG ワードフィルターで二重にチェックするようにした。

最後にアクセスログからスパムっぽいコメントの数を集計して管理画面のダッシュボードで閲覧できるようにした。引き続き監視していきたい。

Basecamp の Jason Fried が Amazon で REMOTE がバカ売れし始めたので返金を始めたそう。なぜ返金するのかというと、本が売れているのは多くの人がリモートワークを恐れており、そのような恐怖・不安に REMOTE という本が役立つから、とのこと。

For the foreseeable future, we’ll be refunding the purchase price of our book “REMOTE: Office Not Required”. Buy a copy, tweet me a picture of you holding the book w/ a sales receipt dated 3/10/20 or later, and we’ll PayPal you a complete refund (DM your email, please).

— Jason Fried (@jasonfried) March 11, 2020

アメリカはリモートワーク先進国なのかなと思っていたけど、やっぱり昔ながらの方法で仕事してた会社もあったんだろう。アメリカでもコロナウイルスが猛威を振るいつつあるいま、そのような会社もリモートワークをやるようになり、リモートワークの心構えが書いてある本がバカ売れしてるということですね。おもしろい。

HashiCorp の Mitchell Hashimoto さんのリモートワークについてのツイートもおもしろかった。これまでのリモートワーク経験で得られたことが書かれている。

The force to remote for much of the workforce is going to be very positive but also create a ton of FUD. Lots will “get it” and it’ll work for them and they’ll be forever changed. Many will realize it isn’t as simple as pretending your at-home desk is your in-office desk.

— Mitchell Hashimoto (@mitchellh) March 11, 2020

全従業員をリモートワークに、という動きは良い傾向だと思うが、たくさんの不安・疑念・不信を引き起こす。多くの人が「はいはいこんなもんね」という感じで仕事をするだろうが、リモートワークは一筋縄ではいかない。多くの人が仕事に使う机を会社のものから自宅の自分のものに置き換えただけのことではないな、ということに気がつくだろう。

It also just isn't going to work for some people. Not everyone is compatible with remote and that's okay. We've had numerous people over the years quit HashiCorp saying "loved the work, loved the people, but I just need in-person social interaction." That's totally normal.

— Mitchell Hashimoto (@mitchellh) March 11, 2020

リモートワークは一部の人にとってはうまく機能しない。みんながリモートワークに適応できるわけではなく、それは仕方がないことだ。これまで HashiCorp ではたくさんの人が「仕事は楽しい、同僚も好きだ、ただやっぱり自分は顔をつきあわせたコミュニケーションの方がいい」という理由で会社を去って行った。これは自然なことだ。

このほかにも Hashimoto さんが新しく従業員を雇ったときに説明するリモートワークについての心構えが書かれていてうなずきながら読んだ。一番最初のやつから結構ショッキングだが事実だと思う。

(1) "You won't make friends." Brutal, but honest. You need to have a strong friend circle OUTSIDE of work cause you aren't going to make one at work. You'll become friends with your coworkers -- yes -- but you probably won't hang out, have your kids share school, etc.

— Mitchell Hashimoto (@mitchellh) March 11, 2020

「君は友だちができない」。残酷だが事実だ。リモートワークをするなら、仕事以外でとても仲の良い友だちがいないとダメだ。なぜなら仕事では友だちができないから。リモートワークでも同僚とは仲良くなれる。でもリモートワークの同僚とは遊びに行ったり、子ども同士が同じ学校になる、ということはない。

そのほかのツイートもおもしろいので読んでみて下さい。

2020-03-14 追記

Jason Fried が元の Tweet を消してしまっている。およそ 400 件の返金請求が来たみたい。自動化できておらず破滅状態なので返金は終了するとのこと。

UPDATE: MARCH 12, 2020: Incredible response to this offer. Nearly 400 refund requests so far. But the success is the downfall. Totally overwhelmed by processing all these refunds, etc. So ending the refund program today. Next time will automate more. Thanks everyone!

— Jason Fried (@jasonfried) March 12, 2020

マイルを貯めるのは低所得の自分には無理だという記事を書いた。

マイルを貯めたいと思ったら小学生に戻って人生やり直さないと無理なことに気がついた

ANA のマイル貯めたくてマイルが貯まるクレジットカードのこととかいろいろ調べてみたけど、あれは富裕かつ時間にも余裕のある層の道楽という感じがする。普通に暮らしててもすでに結構豊かな暮らしをして...

portalshit.net

しかしこの記事を書いたあともセブンイレブンで 100 円のコーヒーを買うときもクレジットカードで払ったり、トイレットペーパーを LOHACO で買うときもポイントサイトを経由したり、通りすがりの自販機の釣り銭受けをまさぐって取り忘れの小銭をあさる中学生のようにちまちまマイルを貯め続け、なんとか家族三人そろって特典航空券（エコノミー）でホノルルまで行ける程度のマイルを貯めることができた。金持ちだと毎年ハワイにビジネスクラスで行けるくらいマイルが貯まるみたいだけど、自分の場合は 3 年かかってエコノミー（ローシーズン、 3 人分で 105,000 マイル）が限界だった。

なぜハワイなのか

2013 年に買った POPEYE がハワイ特集号で、「ハワイには若いうちに行こう」と書いてあった。自分はそのとき 32 歳で、コテコテのリゾート地に興味なかったのだけど POPEYE の特集を読んでみると「確かに良いな」と思えたので、なるべく年を取る前にハワイに行っておきたいなと思っていた。

ここ一年半くらい、身を粉にしながら働くものの大した成果を残すことができず、完全に人間として腐り始めていた。このままでは玄界灘で魚の餌になるくらいしか社会貢献の方法がないと思ったので、休みを取って旅行に行ってみることにした。

旅の準備

特典航空券界の常識をわかってなくて、マイルが貯まったらすぐに特典航空券を申し込めるのかと思っていたけどそういうわけではなさそうだった。マイルが貯まったので「来月旅行にでも行くか」とほくほくしながら特典航空券を申し込もうと ANA のサイトを覗いたら全然席が空いてない。ハワイのような人気路線の特典航空券は申し込めるようになった瞬間全部埋まってしまうみたいだった。 ANA の国際線の特典航空券の予約は 355 日前から可能になり、マイレージクラブのランクが高い人（＝ @t32k さんなどの金持ち）ほど申込みが優遇されるシステムなので、ランクの低いマイレージクラブ会員（＝貧民）が特典航空券を申し込もうとしたらほぼ一年後の日付にするしかない。手持ちの一番古いマイルの有効期限が 2019 年の 2 月だったので、この時期に本当に旅行に行けるかどうかもわからないまま 2019 年の 2 月末に 2020 年 2 月のチケットを取った。申し込んだとき、どこに行くかとか何をするかとかどこに泊まるかとか何も考えられていなかった。やっと旅の予定を決め始めたのは 2020 年の正月だった。その後コロナウイルスの話が出てきて一旦は旅行を取りやめようかとも思ったが、先延ばしにすると逆に騒動が広がりそうだと思って予定通り 2 月中旬に出発した。

ハワイに行ってどうだったか

よかった。

カジュアル

ヨーロッパを旅行するときは結構緊張したが（人種差別とかマナーに気をつけたりで気をつかう）、ハワイは気楽でとてもよかった。

アメリカ人に対する良くないイメージが払拭できたのもよかった。少なくともハワイに住んでたりハワイに旅行に来てるアメリカ人からは、ヨーロッパの安宿で見かけるような声がでかくて何でもアメリカ流を押し通そうとする感じの悪さがなくて、嫌な気持ちになることなく旅行できた。

快適な移動

レンタカーや Uber 、 Lyft で移動したので移動で荷物を抱えて大変な目に遭ったり、タクシーにぼったくられないか心配したりしなくて済んだのが良かった。海外で車を運転するのは初めてだったが、ハワイの道は広くてとても運転しやすかった。

スーパークレジットカード社会

何でもカードで払えるので両替する必要がない。現金はチップを払うときか空港の自販機で飲み物を買うときくらいしか使う機会がない。 ABC ストア（ワイキキに 50m 間隔である旅行者向けのコンビニ）で現金で金払ってるのは日本人旅行者くらいだった。

eSIM 便利

今回は自分の iPhone 11 も嫁さんの iPhone XR も eSIM に対応していたので、香港の 3 というキャリアの eSIM を利用してハワイでも日本にいるとき同様に携帯が使えたのが良かった。 5 年前にギリシャに行ったときはちまちま Pocket WiFi をオンにしてインターネットにつないでいたので不自由極まりなかった。

ホテルの取り方

宿は Hotels.com と HIS で取った。 Hotels.com が最安かというとそういうわけではなく、マリオットなど結構良いホテルのチェーンだと HIS の方が料金安い＆朝食付きだったりしてお得だった。

旅程

ハワイ島とオアフ島に三泊ずつした。福岡空港から成田へ行き、成田で 5 時間時間を潰してホノルルへ。ホノルルからハワイアン航空に乗り換えてハワイ島のヒロへ。ヒロに二泊してコナへ移動し、コナで一泊してからコナ空港からまたハワイアン航空でホノルルへ。なおコナではホテルにパスポートを忘れて大騒ぎとなったが、ハワイアン航空の職員の人がめっちゃ親切でスーパー助かった。ギリシャでエーゲ航空に散々な目に合わせられたのとは大違いだった。ホノルルに三泊して成田経由で福岡に戻った。 6 泊 8 日の旅（一泊は飛行機の中）。

ハワイ島

ハワイ島ではアカカの滝、マウナケア（中腹まで）、ワイピオ渓谷、コナブリュワリーの工場レストランなどを訪れた。主にレンタカーでドライブしていて、ハワイ島の北半分をぐるっと回った。

ハワイ島はハワイ諸島の中では一番新しい島でまだ火山の荒々しい感じが残ってる。マウナケアは 4200m もある高い山だが、裾野が広がっていて草原が広がり、景色が生まれ故郷の阿蘇に似ていて海外旅行に来てるのに帰省してるみたいな感じで不思議な感覚だった。

オアフ島

オアフ島ではワイキキに滞在しつつ、ビーチで遊んだり、街をうろついたりした。

オアフ島でも一日は車で遠出して、ノースショアまで行ってパタゴニアで環境に配慮しながら家族で爆買いしたりした。

ダイアモンドヘッドが見える宿に泊まっていて、できれば登りに行ってみたいと思っていたけどうだうだ無為に時間を過ごしてしまってついぞ登ることができなかった。残念。

ワイキキは福岡でいうと西通りといった趣でひたすらショッピングするのが好きな人にはよさそうだが少々退屈だった。ライドシェアの Lyft で、カカアコという昔は治安が悪かったけど最近は小洒落た店が増えているエリアに行ってオシャンティなレストランでラム肉を食べたりした。

POPEYE で紹介されていた Ray's Cafe という店が安くて巨大なリブアイやロブスターが食べられるようだったが、治安の悪いエリアにある地元民向けのレストランのようで閉店時間が早く、今回は行くことができなかった。

tripadvisor.jp

www.tripadvisor.jp

旅行中のツイート

福岡市西区のハワイからハワイの今宿に来ました。 pic.twitter.com/SCj3bk4iwF

— morygonzalez (@morygonzalez) February 9, 2020

正直、ハワイは一回行けば充分だろうと思っていたが、旅行から帰ってきてからは「またハワイに行きたい」という気持ちが日々募っていく一方だ。酒のやまやに行ってコナビールやフラ印のポテトチップスを買ったり、中公新書のハワイの歴史についての本を読んだり、Amazon Prime ビデオで HAWAII FIVE-0 というドラマを見たりしている。

HAWAII FIVE-0 ではよく主人公が山登りに行っている。ハワイといえば海というイメージあるけど、ダイヤモンドヘッド以外でも登り甲斐のありそうな山がたくさんある。今度は山に登ったり、地元民向けの治安が悪いエリアの店にも乱入してみたりしたい。

それにつけても金の欲しさよ。