移転したコーヒー屋に行ったらデルモンテ工場跡地があった

好きでよく通っていたChromatic Coffeeというコーヒー屋が移転していた。この移転の話もこれはこれでちょっとややこしく、変な話なのだが、この記事の本筋とは関係ないのでひとまずおくとして、移転したのだ。

あたらしい場所はサンノゼのCalTrain駅からやや南にいったところ、正直あんまり足を踏み入れたことのない場所だ。治安がわるいとかではまったくないだろうが、shelter-in-place(自宅待機命令)の関係で営業しているのかもよくわからない。コーヒー豆は通販できるのでまったく営業していないわけじゃないだろうが、よくわからん。

というわけで行ってみた。8月頭のことなのでちょっと前のことだけど。

行ってみたらコーヒー屋が入居していたのは工場跡地を改装したようなノコギリ状の建物だった。周囲は大きなアパートが多い。もともと工場があったエリアの再開発地域なのだろう。ほかの入居店舗は自転車屋や氷屋、ビアバーなど。コーヒー屋としては営業はしていて注文もできるが、店内での飲食はもちろんできない。豆のローストはこの場所でやっているようだ。そこでコーヒー豆を一袋買い、ついでに妻と飲み物を一杯ずつ頼んだのだが、さてどうしたものか。駐車場の日陰で立ちのみをしている人もいるけれど、とおもって携帯電話の地図を見てみるとすぐ近くに公園があるっぽいので、そこにいってみることにしたのだ。

さてそのDel Monte公園という公園についてみたのだけど、道のむこうに見覚えのあるロゴがある。思わず二度見したが間違いなくデルモンテだ。デルモンテっていえばなんだろう。ケチャップか、トマトジュース? あれ。あのデルモンテのロゴだ。なんか貯水タンクみたいなやつにでかでかと描いてある。

IMG_20200802_155540

かなり近寄って撮った写真なので角度の関係でロゴがとても分かりづらいけど、よーくみるとおなじみのデルモンテのロゴが見て取れると思う。

デルモンテは日本だとキッコーマン傘下のブランドだが、もとはカリフォルニアの会社だ。もともとモントレー(シリコンバレーから南に行ったところにある街。今は水族館で有名)の近くに、かつてデルモンテホテルというリゾートホテルがあった。このホテルに卸す食料品を扱うということで(当時の)有名リゾートホテルの名前をつけたブランドがデルモンテなんだそうだ。そういう事情があるから、モントレーとサンノゼはそれなりに離れているとはいえ、関連する施設があってもおかしくはない。おかしくはないが気にはなる。

コーヒー片手に周辺を散策したら、史跡を紹介するパネルが道端に設置されていた。それによると、たしかにここはもともとはデルモンテの缶詰工場でフルーツ缶詰とかを作っていたものらしい。人口の多いサンノゼ近郊であり、線路の近くという地の利もあったため、けっこう大規模な工場があったのだそうだ。はじまったのは1893年(19世紀!)で、それが1999年まで工場として残っていたというから、けっこう最近だ。シリコンバレーともてはやされてドットコムバブルで湧いていたころ、いっぽうこのへんには缶詰工場があったりしていたのだ。

もちろん「けっこう最近」といっても20年以上前のことである。工場の跡地はやがて再開発され、いまではアパートになったり公園になったりしている。アパートになっているが、いわれてみれば工場跡の面影が残る構造だ。妙に広々とした入り口の道、意味もなく立ち並ぶコンクリの柱や建物の感じ。そしてなぞのデルモンテのロゴ入りタンク。

IMG_20200802_161521

公園もデルモンテの名を残しているだけじゃなくて、路肩の構造物が果物のかたちをしていたりして名残りがある。

コーヒー屋を追っかけに来ただけだったのだけど、なかなかおもしろいものを見た。近隣住民のみなさんもいっぺん行ってみると面白いと思う。

zig言語でtomlパーサを書いてみた

数ヶ月前にzig言語というやつの存在を知って、これはちょっと面白そうだなと思ったので、勉強がてらなにかやってみよう、と思っていた。ある日、tomlのパーサはどうだろうかと思い立ってしばらくやっていて(Ghost of Tsushima で作業が中断したりしつつ)、まあまあ出来上がってきたと思うので、現在のところのソースコードをgithubに置いておいた(https://github.com/jmuk/zig-toml)。

というわけで、zig言語をちょっと書いてみた感想を残しておく。なお、利用したのはzig 0.6.0なので、今後いろいろ変わってくる可能性もあることは強調しておきたい。

zig言語のよいところ・興味深いところ

型の扱いがzigでは興味深いところだった。zigはかなりいろんなところでcomptimeというマーカをつけてコンパイル時にコンパイラが事前処理をするようなことができる。これでたとえば、C言語であればマクロ展開させるようなコードも自然に書けるしわかりやすい。

さらに型もコンパイル時の値として扱うことができ、型によって処理を変えるような関数もかんたんに書ける。さらには、型を受け取って型を返す関数によってテンプレート・総称型を実現している。たとえば、

fn List(comptime T: type) type {
    return struct {
        items: []T,
        len: usize,
    };
}

のように書ける。これはちょっとかっこいい。型レベルの情報(たとえば構造体のフィールド名など)はコンパイル時には展開できて、ちょっとしたリフレクション処理のようなこともできる。リフレクションはコンパイル時にしか発生しないので、実行コードはおかしな遅さにはならない。

また、エラーになりうる型、オプショナルな型などはいくつか特別扱いしている点も面白い。null安全性なども担保されているし、Go言語などと違い、エラーの場合にはエラーだけが返るようになっていてわかりやすいし、エラーが値でありながらtry構文などにより帯域脱出っぽいようにも書けるのもよさそう。

zigには(たぶんGoの影響で)defer文があるのだけど、errdeferという「エラーのときだけ実行される」処理というのが書けるのはかなり素晴らしいと思うというか、正直Goにもこれがほしい。これもエラーが特別な値でありエラーになりうる型を特別視しているところとうまく結びついている。

困ったところ、微妙なところ

メモリ管理はやっぱり大変。zigはGCのない手動メモリ管理言語であり、Rustのようなオーナーシップのようなものもない。C言語と同じでメモリ管理は手動で頑張る必要がある。どこでメモリがアロケートされ、誰がオーナーで、どの操作でオーナーシップが移りうるのか、といったことは言語レベルでいっさいサポートがない。こういう言語で書くのは久しぶりで、面倒さはやっぱりある(defer / errdefer でかなり軽減されているはずだが、それでも)。

メモリ管理については、zigはアロケータというオブジェクトが標準で定義されていて、好きなアロケータを扱えるようになっている。これはいい面もある。ある種のオブジェクトをひとまとめのアロケータで管理してまるごと破棄したり、その範囲を越えたアロケーションを禁止したりできるし、たとえば、既存のアロケータをラップしたリーク検知アロケータも標準から提供されていて、これを使ってテストコードを書けばコードのメモリリークはかなり容易に検出ができる(ただ、どこでリークしたかという情報までは取れないので修正の厄介さはそれほど軽減されていない気がするが……)。

一方これは、どのアロケータがどのオブジェクトのデータを割り当てたのかということがまったく自明でないことを意味する。たとえばツリーのようなデータ構造が不要になったので破棄したくなったとして、再帰的にノードをたどっていって順次廃棄していくというコードを書くだろう。でも、ノードによって異なるアロケータから割り当てられていたということも原理的にはありうるから、ノードごとにただしいアロケータに対して廃棄するような再帰処理を正しく書くのは、わりと自明ではない。

実際、標準のデータ構造でも、データ構造からアロケータへのポインタを持っていることが多い。リソース開放用のメソッドは deinit と呼ばれる関数で行われるが、このメソッドはパラメータを取らず、自分自身が参照するアロケータにリソースの開放を依頼するかたちになっている。私もこの構造に従ったし、それはそれで便利なんだが、なんだかありとあらゆるデータ構造がアロケータへの参照を持っているというのはいいことなんだろうかという疑問がないでもない。もう少しうまい仕組みはないものか。

defer / errdefer については自分がGo言語にひっぱられすぎている面もあるが、ちょっと戸惑ったところもあった。zigのほうがわかりやすいというか直感的ではあり、defer / errdefer はそのスコープを抜ける時にしか発動しない。その一方、

while (i < input.len) : (i+=1) {
  var v = Value{.Table = Table.init(self.allocator)};
  errdefer v.deinit();
  ....
  if (xxxx) {
    break;
  }
  results.append(v);
  if (yyyy) {
    return i+1;
  }
}
return ParseError.FailedToParse;

のように書いた時、このコードがエラーを返してもvが開放されることはないので困ったということもあった。関数全体としてはエラーだが、errdeferの設定したスコープではエラー終了していない(正常にbreakしている)ためにerrdeferは実行されない。breakのかわりにその場でreturnでエラーを返すとerrdeferが実行される。ちょっとわかりづらいと思った(zigに慣れていないだけかもしれない)。

ほかにも、標準の文字列リテラルは[]u8でしかないというのはけっこう戸惑いがあった。ちょうどいい文字列型のようなものは存在しないし、文字列リテラルからかんたんに利用する方法もない。std.ArrayList(u8)がわりと使えるが、ArrayListは対象の文字列をつねに所有しているので作るなら毎回コピーするしかない。使いやすいユーティリティ関数も少ないし、もうすこしできの良い文字列型がほしい。

また、先述したように総称型が「型を受け取り型を返すコンパイル時関数」なのはかっこいいんだけど、これは裏を返すと、ある型に対して「これはArrayListの型である」かどうか、というチェックは書けない。ArrayList自体はコンパイル時関数であって、いま手元にある型Tが、どのコンパイル時関数から生成されたものなのかなんてことはわからない。tomlパーサのようなものを書くとき、呼び出し側が指定したデータ型の構造に応じてパース結果を埋めていくみたいなことをしたいわけだけど、そういう理由により、ライブラリの定義する型をうまくあてはめるのはかんたんではないという印象を持った。

もうひとつ、エラー型が単純なenumなのは正直納得がいかない。tagged unionもありにしてほしい。パースエラーが発生した時、エラーの発生箇所を埋め込みたいんだけど、できない。パーサーオブジェクトに「最後のエラーの箇所」みたいなプロパティを与えるみたいな方法がありうるだろうけれど、どうしてもアドホックになってしまう。まあtagged unionにした場合、エラーオブジェクトをアロケートしている途中で発生するエラーみたいなややこしい問題がありうるだろうから、この設計方針はわからないでもないのだが、しかし不便じゃないか?

けっきょく、面倒なので ParseError.FailedToParse だけを返すコードになっていて、どこでエラーになったかは検出する方法がないようにした。そのほうが実装が楽だから……なんだけど、テストが失敗したときなどはわりとつらい目にあってしまった。

tomlについて

tomlは(主にCargo.tomlで)ちょっとだけ書いたことがあるくらいで仕様のことはあんまり詳しくなかったので、パーサを書くのはtomlの詳細についてもいい勉強にもなった。人間にとってわかりやすい仕様だしあんまり長くなく、複雑度が低くて良いというイメージであったが、人間にとってわかりやすい仕様は、パーサを書きやすい仕様ではないという学びもあった。

とくに面倒なのは重複するキーの禁止と、[]で設定するテーブルとインラインテーブル・インラインアレイで設定されるものの再定義が禁止されるという仕様。単純にキーに対してオブジェクトをトラバースしていくだけなら実装が単純なんだけど、このパターンは上書きになってだめ、このパターンはむしろ許される、みたいなルールがいくつもあって、けっこうわからない。仕様に書いてある例をテストケースに移して確認することにしたけど、当初の実装方針だとぜんぜんだめなパターンもけっこうあって難しかった。

Mt. Umunhumに登った

妻に教えてもらうまで知らなかったのだが、Mount Umunhum という山がある。南側サンタクルーズ山脈のなかの山で二番目に高い(標高1,063メートル)。また、山頂に直方体の建物があるのも特徴で、教えてもらってわかってみれば、たしかにたまに山を眺めてみると、山頂にあきらかな人工物が建っているやつがあってあきらかに異様なかんじがある。それがUmunhum山だ。

山頂の建物は元アメリカ空軍の施設で、今は閉鎖されている。入れはしないが、かなり近くまで行けるらしい。

山頂の施設のすぐちかくまでは車で行ける(空軍の施設があったぐらいなので、そのころに整備されたのだろう)。また現在は近隣エリアはSierra Azul Open Space Preserveになっていて、歩いて登るハイキングロードも整備されている。

これを登ってきた。ルートは https://www.alltrails.com/trail/us/california/mount-umunhum のもの。往復約7.7マイル、高低差が約1100ftくらい。結論としてはだいたい4時間ぐらいかかりました。

IMG_20200510_144000

歩きはじめ。この四角いところまで歩いて登るということだ。

IMG_20200510_144621

山道はだいたいずっとこんなかんじ。道は整備されていて歩きやすい。

IMG_20200510_154509

途中、なんらかの廃墟があった。20世紀前半ころにはこの辺に住んでいた人もいたのだという。めちゃくちゃ辺鄙な場所だが……。ただ、隣接するAlmaden Quicksilver County Parkは、かつて金鉱のために辰砂を採掘していたらしく、こういうところにも人が住んでいたのだようだ。

IMG_20200510_161024

かなりちかづいてきた。ほぼゴール。

IMG_20200510_164158

例の直方体。間近で見るとでかい。

ちなみにこの建物がなんだったのかというと、冷戦時代のミサイルや敵機を監視するためのレーダー基地だったのだという。当時は上にでっかいアンテナがついていたらしい。1957年に建設され、冷戦のかなり初期から運用されていたものらしい。80年代には役割を終え、廃棄された。それからずっとこのままらしい。アンテナだけ撤去されたのが何故なのかはよくわからない。

IMG_20200510_183638

帰りに気づいた、トレイルの脇で遺棄された車。ぼろぼろになっている。

途中の道は鳥の鳴き声はよくしたが、あまり動物は見かけなかった。リスがいたのと、鹿は一匹だけ見かけた。鹿はそれなりにいるようだ。

それにしても冷戦時代の遺物がこんなふうに残っているんだなぁ。なんとなく感心してしまった。

ところでいままでカタカナ化してこないできたが、Umunhum山、なんて読むかわかるだろうか。ぜんぜんわからないので我が家では「ウムンフム」とかテキトウに呼んでいた。グーグル地図では「ユマンハム」となっているが、これが正しいとも限らない。

それで調べてみたらKQEDの紹介動画が出てきたが、hは読まずに「ユマナム」と読むものであるらしい。語源は現地のネイティブアメリカンであるオローニ族(Ohlone)の言葉のようだ。

動画ではいろいろほかのことも説明してくれている。たとえば、空軍がこのレーダー施設を運用していたころは、近隣に隊員やその家族のための宿舎があり、ちょっとした街のようだったこと。ところが空軍が撤退してからはそのままじつに30年以上放置されており、ちょっとした廃墟の街と化していたこと。ついに片付けの予算が連邦政府からおりたのが2009年のことで、その作業中であること……。もしかしたら将来、この直方体の建物もなくなるのかもしれない。老朽化したら危険なのは確かだろうし。

動画では、かつてレーダー基地で監視業務についていた元隊員まで登場していて面白い。

意外なところで歴史の面白さも感じられるハイキングでした。

Shelter-in-place (自宅待機)の2週間

わたしの住むカリフォルニア州サンタクララ郡が、shelter in place order(自宅待機命令)を出しておおむね2週間が経った。なにかの足しになるかとTwitterで日記的な投稿をしていたのだが、いったんまとめておく。東京・日本とは事情が様々にことなるが、雰囲気などが伝わったり、なんらかの参考になればさいわいだ。

用語について。いろいろな用語があるのだが、ロックダウンという言葉は使わないことにしている。というのも、街のロックダウンは武漢やイタリアなどの制限のかなり厳しい命令であるかのように思えるからだ。たぶんそういうニュアンスから、アメリカでは各地域でいろんな言葉で自宅待機の指示を出しているのだとおもわれるが、ともあれカリフォルニア州ではshelter in placeという言葉が広く使われている。homeという語でないのはホームレスの人々なども対象であることが念頭にあるのだとおもうが、基本的には「自宅待機」のような意味なので、そう訳すのがいいと思っている。

制限内容については、かんたんにいえば「必要不可欠な業務(essential business)はそのまま維持される」「そうした必要不可欠なサービスや商品の買い出し、必要不可欠な活動(essential activity)をのぞき、自宅にい続けること」といった状況になっている。essential businessについては、スーパーなど食料品店、工作用具店、銀行、病院、政府機関、ガソリンスタンド、車などの修理、水道管修理、ゴミ回収などが該当するとなっている。レストランはすべて営業禁止。ただしテイクアウトの注文は受け付けてもよい。タクシーや配車アプリも可能。公共交通機関も利用可能。essential activityにはちょっとした散歩やジョギング、ハイキングなどの余暇的活動も含まれる。ただし外出先ではsocial distancingを保つこと(2-3メートルは離れること)。友達などと集まるのも禁止。

こうした制限はそれなりにリーズナブルだし、封鎖というものものしい言葉よりはゆるいとおもう。

ただ実際にはゆるゆるというわけにはいかない。店によって、業態によって、ものすごく影響がある。営業時間を短縮した店もあるし、こんなんじゃやってけないと一時閉店した店もある。営業をつづけていても店内立ち入りを制限したり、注文はオンラインでしてピックアップのみの営業になったりすることもある。

たとえばスーパーは濃厚接触を避けるために入場制限をしていて、入場列がおおく見られるようになった(ぜんぜん並ばないスーパーもあるけど)。入場列も2mとかずつ離れて並ぶ必要がある。レストランについては、これを機にテイクアウトをはじめた店もあるが、残念ながらやはり一時閉店を決めた店もある。ある日には営業していても次の日には急に閉まることもある。ハイキングはオッケーといっても人が混み合えばsocial distancingを保つことはむずかしく、けっきょく国立公園や州立公園などは閉鎖されてしまったりもする。制限の内容から現実を想像するのはなかなかむずかしい。テック企業の従業員であるわたしみたいな人間は比較的のんきに生活できているほうだとおもうが、そういう人間であってもけっこうなストレスはかかる。もっと直接的に影響があるなら推して知るべしだ。

スーパーなどのパニック買いや買い占め等の影響についても書いておく。shelter in place発令直後はずいぶん混雑して、スーパーからいろんなものが消えていった。買えないものもけっこうあった。ただ食料品の流通はわりにすぐに回復した。とくに生鮮食品はほぼ平常時といっていいレベルになっている。冷凍食品系は店頭在庫はいっとき空になったが、すぐ回復した。缶詰類は在庫薄。それと小麦粉がかなり売れているようだ。保存がきくし、いろんな料理に使える。それと在宅で暇になったのでパンを焼いてみる人が増えているらしい。ミネラルウォーターもけっこう品薄なようだ(うちはBRITAを使っているので影響がないが)。ドラッグストアではいわゆる風邪薬的なものが品薄なようだった。

トイレットペーパーはいぜんとして品薄がつづいている。自宅待機のために買い足しておきたい需要増が大きいのと、また各家庭の消費量が増えているためではないか、という話もあって説得力はある。ぜんぜんどこにもないというほどでもないが、買えるかどうかは運とタイミングといった状況はまだ続いている。

食生活については、夕食はこれまでも基本的に自炊していたのであまり変化がない。昼食は地元のレストラン支援もかねてデリバリーを頼んでみたり、でもまあかんたんなものをつくるほうが多いかなとなっている。朝は牛乳一杯とか、そういうふうにしている。ところで自宅待機生活による食生活の変化で太るというパターンと、逆に痩せるというパターンがあるけれど、わたしは後者。ふだん会社にあるスナック類を食べてたからかねぇ……。

以下、時系列にツイートを紹介しておこう。

3月17日。初日。あちこち散歩したり様子を見に行ったりしているが、前日までとは大差ないかんじ。お店もけっこうやっている。

18日。スーパーの在庫を眺めたりしている。状況はたいしてかわっていない。

19日。まだもつとはいえやや心もとなくなってきたトイレットペーパーがこのタイミングで買えたのは僥倖。上司もこの日の朝にCostcoにいってトイレットペーパーを無事ゲットしていたがけっこう並んだようだ。ランチは近所のラーメン屋のデリバリー。

20日。電機屋のBestBuyがふつうに開いていて入場列ができていたとおもったら、予約注文した『どうぶつの森』のピックアップ列だったのはさすがに笑った。

21日。土曜日。週末ということで気晴らしにハイキングにでかけた。Rancho San Antonioはサウスベイからは激近なわりにけっこういい。駐車場は混んでいたが、ここはいつでも混んでいるし、エリアに出てしまえば人口密度はさほどでもなく距離を取るのは容易だ。でも今後は閉まっちゃうのかもなぁ。

22日。先日とおりがかったBestBuyに入れなくなっていることに気づく。ボバティ屋も閉まってしまった。期間が長期化すると、だんだん閉店する店が増えていく。悲しみ。

23日、月曜日。ふつうに仕事。夜に散歩というかんじ。

24日。チャパグリつくってます。実はshelter in place中すでに2回めのチャパグリだった。

25日。ランチは自炊だったり外食だったりを適当に繰り返している。外食はDoordashが多い。午後の散歩が日が暮れてからになってしまったが、なんだか星が綺麗だなと思った。交通量が激減して大気汚染がずいぶん改善したという話もあったので、その影響なのかもしれない。気のせいなのかもしれない。ちなみに公園はふつうに散歩できて、園内の歩道を散歩しているひとたちがそこそこ見えるが、遊具はテープなどで封鎖されて使えなくなっている。

26日。特筆することはあまりない。写真のパスタはけっこうおすすめ。パスタとソースが一体化しており、お湯に入れるとソース分が溶けて、水気がとぶくらいまで茹で続ければ完成というもの。楽だしうまい。アメリカでもわりとめずらしいインスタント食品だとおもうけどおすすめ。

27日。やはり特筆事項なし。このタイ料理は辛すぎず、なんとも美味かった。とくにトムヤムクンはいままで食べた中でも一番美味かったかもしれない。

28日。週末。買い物にでかけた以外はとくにやっていない。

29日。日数まちがえてツイートしている。とおくからの歌声はヒマになった近隣住民がうたってるのだとおもう。Popeyesは数ヶ月前にはチキンサンドがえらい人気で大行列だったのだが、いまはもちろんそんなことはないとおもう。

30日。月曜日。ほんものの14日目。

31日。こんどは近隣住民のだれかがウクレレを弾いていたようだった。この日、shelter in placeのあたらしい命令が発令された。ただ制限内容を細かく明確化したり、これまでいきなり公園の遊具を使えなくしたりしていた行為を明文化したり、といった面がおおきいように思える。あと自宅にいろよという期間が伸びた。

4月1日。茹でるだけのパスタその2。

 

Performance of Opensource ApplicationsでAudrey Tangの章を読む

このところAudrey Tangという人がよく話題になっている。台湾のデジタル担当相みたいな大臣だという人だ。この人をとりあげた記事は日本語でもいくつかあるが、たしかにどれもおもしろい。

さてこのAudrey Tangの書いた技術文書が、Performance of Opensource Applicationsという本に収録されている。いろんなオープンソース開発者による、ソフトウェアの性能に着目した技術記事をあつめた本だ。ネットで公開されていて無料でも読める

本全体もひととおり読んでみたんだが、まあなんかそれほど感心するような内容でない章もそれなりにあった。ダメとかじゃなくて、なんというかふーーーん……で終わってしまったような……まあ読者の興味の方向性で面白さがかわるようなトピックだとおもうので、どの章がどう、という話は控える。たださいわいにして、Audreyの文章は個人的には面白い方に分類される内容だった。

この章ではSocialCalcというスプレッドシートアプリの性能改善について解説している。スプレッドシート(エクセルとかみたいな)だが、ブラウザでアクセスするウェブアプリであり、シートをみんなで共有できる。グーグルスプレッドシートとかみたいなやつ。ただしオープンソースでだれでもインスタンスを立てて動かせる。

ただユーザ数が増えたりデータが増えてくると性能的にどんどんつらくなっていったんだという。というのも、セルの計算のロジックやスプレッドシートのロジックが基本的にJSで書かれていたからのようだ。よくわからないけど、たぶんセル内の演算や関数なんかにもJSをそのまま使えるようになっていたのだと思われる。設計としてはすっきりしているけど、あまりにも更新が多いとユーザはアクセスするたびに全更新データを受け取って計算しないことにはスプレッドシートの最新状態を描画できなくて、これはいかにもつらい。

それで最終的には、Perlで書かれたサーバをNode.jsに移植し、同じコードでサーバ側でもスナップショットを取れるようにして、性能を改善した。さらにサーバサイドJSのボトルネックをさぐって性能を改善していった、という過程が説明されている。

本自体が2013年ころに刊行されており、書かれている出来事はそれよりちょっと昔だとおもわれるので、いろんな細部に時代を感じる面もある。そもそも当時のnodeってめちゃめちゃ初期だし、coffeescriptとかが熱い時代だったんだなとか。今でこそ、そりゃそんなものならNode.jsでいいでしょって思うかもしれないけど、必ずしもそれ自体がただしいかどうかは事前にはわからなかったのだろうな……といったところにも、面白さがある。

ところで、なんでAudreyがそんなソフトウェアに貢献していたんだろうか。しかもシートを数千人でシェアすると困るよね、みたいなことを言っているが、そんなに大規模にシェアすることってあるんだろうか? そういう動機みたいな話はとくに触れられていないのだけど、オープンガバメント系の運動に参加してきたがゆえにこういうプロジェクトに貢献していたんじゃないか、それがAudreyの今の姿につながっているようにも思えて、そこもまた興味深くおもえてくるのだった。

マーサ・ウェルズ『マーダーボット・ダイアリー』

『マーダーボット・ダイアリー』

「ふつうにおもしろい」本でとてもよかった。

自称「殺人機械」(マーダーボット)である主人公の警備ユニットが、宇宙のあちこちのいろんな事件に巻き込まれる連作中編シリーズ。上下巻で4本の作品が収録されている。というか、もともと中編として発表された4作品をまとめた一冊というか。ストーリーはゆるやかにつながっており、4本目でいちおう完結っぽい雰囲気になっている。

主人公のマーダーボットは人間の脳や肉体なども使われた機械であるようだが、一般的には人間とはみなされていない企業の所有物で、様々なプロジェクトにリースされている。ところがマーダーボットは自分で制御プログラムをハックしていて自意識をもち、自分の意思で行動できる。そのことを隠してふつうの警備ユニットとして活動していたが、いろいろあって宇宙のあちこちを漂流し、行く先々で遭遇するトラブルを解決していく。これをマーダーボットの視点で描くといった体裁になっている。

自分のことを「弊機」とよび、あくまでも機械であって人間ではないというスタンスを崩さない主人公のすこしひねくれた自意識が、とてもよい。アクションもあってテンポもよく、もともと複数の中編をまとめただけあって話が比較的すぐ盛り上がっていいかんじに終わる。気軽に読める娯楽小説として楽しめる。とてもよい。

あとまったく個人的な話なのだけど、こういう気楽な翻訳娯楽小説がまだ楽しめたことがわかったのも収穫だった。なんか、いかにもアメリカ人が書いたような設定を英語ではなく日本語に翻訳された文で読むのがきつい、という体験を少し前にしたことがあり、気軽な娯楽小説だからこそきついのかなあ、こういうやつはもう日本語では読めない体になってしまったんだろうか……と悲しくなっていたのだが、本書は楽しめた。それがうれしかった。

本書の訳文は、個人的にはやっぱり、まったくひっかかりなく読めるということはない。でも質は高いし読みやすい。とはいえ訳の質よりは、内容の違いのほうが大きいような気もするな。よい娯楽小説だということでしょう。

なおこのシリーズ、これで完結かと思ったら5作目も出てるのだね。英語で読んでみるかなぁ。

NetflixでIrishmanを観たら画面が日本語だった

Netflixでマーティン・スコセッシ監督の “Irishman” をみた。アイルランド系のマフィアの映画で、3時間半ほどある長編だ。

映画じたいはよかったのだが、今回ここでいいたいのはそういうはなしではない。ただ、映像が日本語だったのでめんくらった、というはなしだけをする。

ぼくは英語オリジナルの映像作品については、もっぱら英語音声に英語字幕つき(あれば)でみている。Netflixだとデフォルトの設定もそうなっているし、今回もそうだった。なので英語で会話がきこえてくるし、そのときに画面下部にでてくる字幕は英語になっている。

でも映像部分は日本語だったのだ。といってもなにをいっているかわからないとおもうが、そうとしかいいようがない。

Irishmanのなかでは、字幕とは別になんらかの文字が表示されることがある。たとえば、実話ベースの映画なため実在のマフィアがいろいろでてくるのだが、どちらかといえば端役なキャラの場合には登場時にキャラ解説が文字ででてくることがある。名前と、いつ死ぬか、どうやって死ぬか、などなど(たいていろくでもない死にかたをしている)。Irishmanとはちがうが、世界各地を舞台にしたアクション映画とかだと、風景にかぶせて地名をだしたりするでしょう。まああんなかんじのやつだとおもってもらえればいいのだけど、ともあれこういう「映像中の文字部分」が日本語になってた。

先述したとおり、セリフにかぶさるいわゆる「字幕」についていえば、これは設定どおり英語になっている。なので、そういう雑魚マフィアが登場している場面に主人公のモノローグがかぶっていると、日本語でそのキャラの死にかたが解説されつつ下の字幕は英語、みたいないそがしい状態になる。

というわけでめんくらったわけだが、どうしてこうなるか想像するのはむずかしくない。ぼくはOSやブラウザの言語設定は日本語なので、Netflixも自然に日本語UIになっている(変更できるのかもしれないが、気にしていなかった)。つまり、日本語のUIで『アイリッシュマン』をえらんで再生をはじめ……プレイヤーの音声設定は英語にしていたというわけだ。Netflixとしては、映像部分はUI言語から自動的にえらぶ仕組みなのだろう。じっさい、わたしのようなパターンのほうが例外的で、たいていの場合にはこのほうが自然なはずだ。たとえば日本人が洋画を字幕つきでみる場合なんかでは、字幕も映像部分の文字も日本語になってほしいだろうから(こまかくいえば、UI言語ではなくて字幕言語にあわせるべきだという気もするが、これについてはもうすこしあとで考えよう)。

さて、こういうことはIrishmanにかぎったはなしではなく、言語にあわせて微妙にコンテンツをかえるということは、けっこうあることとしてしられている。とくにディズニーはよくやっているという。

たとえばWreck in Ralph(邦題『シュガーラッシュ』)などの場合、ゲーム世界の表示は翻訳されていたりするという。英語でつくったままの「DANGER」みたいな表示は視聴者はみて理解することが前提になるので、解説字幕をつけるのではなくて、映像の側で変更して、日本向けの配信では「危険」みたいに映像自体をかえてしまうというわけ。

“Inside Out” (『インサイド・ヘッド』)ではこの路線をさらにすすめていて、映像のなかみじたいをかえてしまっている。主人公のライリーのきらいな野菜は、英語圏ではブロッコリなのに日本版ではピーマンにかわっているという。

https://www.yahoo.com/entertainment/s/why-inside-out-looks-a-little-different-in-japan-125518719127.html

以前そういえばこの作品を飛行機内の映像システムでみたんだけど、映像は共有で英語圏のまま、音声は日本版の正式なものをつかっているので、どうみてもブロッコリにしかみえないものを「ピーマン」と呼んでいる、みたいな不思議な場面に遭遇したような記憶がある。

基本的にはこういうのは配信先の国ベースのできごとであって、その地域にいるかぎりにおいては矛盾はおきないようになっているわけだが、Netflixも日本進出が本格化してきて、こういう部分にも目を向けるようになってきたということなのだとおもう。Irishmanはそうとう予算も労力も投入した作品だろうから、様々な言語ごとに映像を微調整するということはまったくおかしなことではないっていうことだろう。言語設定というのはNetflixのように国際的なネット企業だとなかなか面白いことは起こりがちで、自分のように例外的な設定でおかしなことになりがちではある。ともあれ、率直にいえば、おもしろい現象をみた、とおもう。

それにしても、Inside Outのようなアグレッシブな改変が今後おこなわれることをおもうと、これは映像と音声や字幕のあいだに矛盾をきたす危険性があるということを示唆している。音声と字幕と映像のどれをどの言語で表示するべきか、というのはかなりの部分で、まったく自明ではない……ただおそらく、映像と字幕の言語を連携させるのが理想的な挙動となるようにおもう。現状そうなっていないのは、字幕データが比較的「軽い」のにたいして、映像のきりかえがけっこう「重たい」処理だからだろう。

字幕は基本的にはテキストデータをつかって、画像の上にレイアウトしてかぶせるようになっている。フォントや色などはたいしていじれないシンプルなもので、そうであるがゆえに切り替えも用意だ。いっぽう映像そのものはデータもおおく、Netflixなどの再生では適切にバッファリングしたり帯域で画質を動的制御したりしている。ここで動的に複数の動画のあいだをスムーズに入れ替えるというのはなかなか困難のあるタスクだし、そのわりにそれで便利になるユーザがきわめてかぎられる機能になりそうだ。

いろいろコーナーケースを詰めていくとなかなか考えがいのある事例でおもしろいと思う。

On Misreading Chat

2018年から、Misreading Chatというポッドキャストをやっている。とりあえずこれまでのところの感想を書いておこうと思う。

Misreadingはコンピュータサイエンス系の論文を紹介するという体裁のポッドキャストだ。メインのホストは同僚の森田で、わたしは共同ホストという体制ではあるが、実際にはまあにぎやかしみたいな立場な気がする。毎回、わたしと森田とで交互に一本ずつ論文を読んできて紹介する。

ポッドキャストそのものやコンセプト、アイディア等は森田による発案なので、どういう考えからこういうポッドキャストをはじめたか、とかいったことについては、わたしが話せることはあまりない。こまかな編集作業や加工も、じつは森田が行っているので、わたしはポッドキャストの場でしゃべるだけ。いつもすんません。

Misreadingは、よくあるポッドキャストからすると(たぶん)珍しい点がいくつかあって、ひとつには、シーズン制を採用している。シーズン制なポッドキャスト、NPRのやつとかで見かけるが(Invisibiliaとか)個人運用のポッドキャストにはあんまり見たことがない。Misreadingはおおむね10週間くらい収録したら1-2ヶ月くらい休む、というシステムでやっていて、この記事を書いている時点でシーズン4まで終わっている(1回の収録でおたがいのターンを収録するので、1週間あたりだいたい2エピソードくらい出てくる)。シーズン制によって、収録時の負荷がずっと続くこともないし、あいている間にネタを貯めてシリーズみたいな構成にもできるから、制作側にはそれなりにメリットはある。聴いている側からすると長期間のブランクは暇になるのはデメリットだが、更新が再開したらしばらく続くのは、いつ更新がくるかわからないよりはいいかもしれないなと想像している。ブランクは運営側にとってもデメリットがありそうな気がするが(聴取者のエンゲージメントを落とすなど)、これはおそれるほどでもないのではないか。ポッドキャストの場合、subscribeしたら放置する人が多いからかもしれないが……。ともあれ、シーズン間隔のあいだにやる気が終了してそのまま復帰しなくなってしまうみたいなほうがデメリットである気がする。すごくおすすめではないけど、検討してもいい。

それと、Misreadingは面と向かって収録しているのもたぶん珍しいポイントだとおもう。よく個人運営のポッドキャストの収録では、複数の参加者がいたらボイスチャットシステムを使っていることが多いはずだ。ボイスチャットは便利な面もあるが、どうせ二人とも物理的に近い位置にいるし、複数の音源のタイミング合わせも面倒そうなので、面と向かって収録するのが良かろうという話になった。ただその場合、マイク一つだとうまく録音できないので、マイクふたつでうまく収録する必要があり、結局、ミキサー(物理)を導入してふたつのマイク入力をあわせ、録音機(携帯電話)に流し込む構成で落ち着いた。

なかみのはなしもかんたんに。

論文を読んできて紹介するというコンセプトはわたしが考えたわけではないのだが、やってみたところ、これがなかなか便利だということがわかった。ブログでもなんでもそうだが、やると言い出して体裁を整えてサイトを作るまではできても、とくになにも話すことがない、というのはありがちな課題ではないか。論文を読んできてそれを紹介する、というスキームによって、ともあれなにかしら意味のありそうな話になる(可能性が高い)、という良さがある。オールジャンルで始めるよりはテーマを絞るべし、というのはよく言われるところだと思うが、ポッドキャストもおなじだなと思う。

ただ、本業のかたわら週に一本論文を読んでくる、紹介できる程度のメモもまとめる、というのはそれなりに負荷がたかく、日常生活を圧迫しがちだ。論文は一本読んで終わりということもなく、周辺情報も収集したりすることもある(手薄になりがちなことも多いが)。読んでみたけどいまいちだったな、みたいなこともあり、そうなったら時間があればほかのにスイッチしたいかもしれない。本業研究者の方からしてみたらぬるい言い草な気がするけれど、まあパートタイム愛好家としてはそれなりに大変だということです。

論文の選定については、おたがいとくに相談したりせず、各自で適当に情報収集してピックアップしているが、いまのところコンフリクトしたことはない。リストは共有しているけど、どの順番でとか、いまこれを読んでいて、とかもきちんとは共有してないんだけど。論文の探し方は、自分の場合、usenixのサイトを眺めたり、Google Scholarで適当なフレーズで検索してみたり、いろんなテック企業のリサーチセンターのページから眺めたり、the morning paperのような論文紹介ブログとかHacker Newsなどのサイトで紹介されていたり、といったところを情報源にしている。

論文はたいてい印刷して読んでいる。紙のほうが持ち運びやすい、といった事情によるもので、画面で読んでもまぁいいのだけども、紙でも悪くはない(散逸しがちという欠点はあるが)。画面で読む場合には手元のpixelbookを使っているが、これは論文読み用途にはなかなかいいデバイスだと思う。タブレットモードにもなるし、画面もそこそこ大きいし、ChromeビルトインのPDFリーダの出来も悪くない。一時期reMarkableとかソニーのDPTのようなE-Inkタブレットに興味を惹かれていたのだけど、それなりの値段がするのでけっきょく試せていない。このへんはおすすめがあったら誰か教えてほしい。でも、すでに手元にpixelbookがある現状では、これより明らかに良いデバイスはあまりないかもなという気はする。


いろいろ書いてみたが、なかみに関する話の細部はともかく、外形的にはなんだかブログと似たところがあるなとおもう。

ポッドキャストって、なんというか、時代だなとおもうことがある。Appleの製品として始まったのに、まったくAppleのプラットフォームに囲い込まれていなくて、というかどんなプラットフォームのものでもなくて、適当なウェブサイトを立ち上げて音楽データを上げてRSSフィードをつくればいい、という体裁になっている(Misreadingもwordpress.comでホストしている)。Anchorみたいなサービスもあり、特定のプロダクトに囲い込まれているように見えるものもあるけれど、外部からアクセスされる口があり、外からはホスティングサービスのように見えるようなつくりになっている。それに、素人がはじめたようなポッドキャストも妙に勢いがあってよく聴かれているように思えるところの不思議さもある。

この感じの懐かしさ、みたいなものが、すこしある。ブログと似たようなかんじをわたしが抱くのも、たぶんそういう理由があるのだとおもう。なんというか、ブログが熱かった時代、というのがあったわけだけど、その時代的ななにか。Web 2.0の時代の産物というか、残り香みたいなもの。まあそもそもおおむね同時代に生まれたわけだから当然なのだけど。

ブログと違う点もある。文章と音声という違いとか、編集の大変さとかもあるけど、たとえば人数。ブログはだいたい一人で書きがちだったけど、ポッドキャストはどちらかといえば複数人でやりがち。ブログなんて、だいたいネクラな人間がひまな時間に孤独に書くことからはじまる(偏見)わけだけど、一人でしゃべるだけのポッドキャストを成立させるにはけっこうな話芸が(たぶん)必要なので、素人なら複数人で話したほうがいい。素人が複数人で話したからといって話がわかりやすくなったりするかというと、そんなわけもないんだけども、しゃべっていてもあんまり慌てたりおかしなことになりづらいし、なんというか、聴きやすさが多少マシになるんだろうな、と思っている。そういえば複数人が対話形式ですすめる記事はネットにたくさん転がっているが、あれもたぶん、読みやすさに貢献したり展開をさせやすいからだろう。

複数人でポッドキャストをやる、というのは案外良い面もあって、エピソードの収録スケジュールによって制作のリズムが生まれる。いつまでに準備をしないといけない、といったピアプレッシャー的な面もある(いいのか悪いのかわからないが)。内省的なブログと比べると、ポッドキャストはもう少し外を向きがち。ネクラなわたしがポッドキャストとかやってるのは、なんだかおかしなものだが、やってみるとけっこうたのしいものだ。

タサハラ禅センターに温泉はいりにいった

IMG_20190523_102456

シリコンバレー・ベイエリアから車で3時間ほど南下した山中に突然に(日本由来の)禅寺があり、そこは春〜秋まで一般の観光客もお金を払えば泊めてくれるところであるらしい。しかもそこには温泉があるのだとか。

その場所はTassajara Zen Center (タサハラ禅センター)という。妻がみつけてきて行きたいというので行ってきたが、これはかなり良かった。おすすめ。

行き方

行くにはまず予約が必要。ウェブで予約できて、毎年2月にその年の予約の受付が開始されるけど、週末とかの予定はすぐ埋まるので頑張って予約しよう。

予約すると電話で確認があって、自力で来るか、ピックアップ場所まで迎えに来るかどうするかを聞かれる。実はタサハラはものすごい山中にあって(地図でいうとここ)、途中で舗装路は完全に途絶してしまう。車でゆっくり1時間ほど、舗装されていない細い山道を進んでいく必要がある。なので舗装路の終点でタサハラの人が迎えに来てくれるサービスがある。これを利用しますか?というのが質問の意図だった。どれぐらい大変なのかよくわからなかったけど、われわれはこれを利用することにした。これを利用する場合は待ち合わせ地点に10時半に行く必要がある。この待ち合わせ地点まで、ベイエリアからだと約2時間といったところ。なので合計で3時間といったところだ。

今回われわれは待ち合わせ時間ちょっと前くらいに着いた。で指定の場所(なんとなく車をいっぱい停められそうな空間がある)に停車できる場所をみつけてしばらく待っていると、迎えのシャトル……というかふつうの4WD車……が到着。迎えの運転手(たぶん修行僧のひとり)とか、ほかの同乗者たちと挨拶して荷物を積み込んだりした。で、どうも一人おくれている人がいるらしい。がなにぶん遅れている人と連絡を取る手段がない(待ち合わせ場所も携帯圏外)のでひたすら待つしかない。30分以上まっただろうか、「これ以上待っても仕方ないし行こうか」というので一同乗り込んで出発した。遅れてきた人はあとで会えたけど、自力で山道を運転してきたらしい。

IMG_20190524_150945 (1)
道の写真はとらなかったけど、窓から撮った写真

山道はちょっと想像以上のラフな道だった。でこぼこの泥道で、道幅もそんなに広くなく、傾斜も激しく、そして意外と対向車が来る。スピードは出せないし気も使う。4WDを持っていてオフロードを走るのが趣味ならいいけど、正直自分ならピックアップサービスを使わない手はないと思った。運転手の人が言っていたが、つい去年にも運転を誤って崖から転落したという死亡事故があったのだという。

運転手の人はほかにもいろんな話をしてくれた。タサハラはもともとネイティブアメリカンの言葉で、肉を乾かす、といった意味があるのだとか(タサハラ、山中の避暑地みたいなイメージだったけど、実は夏はずいぶん暑くなるらしい。大昔はネイティブアメリカンが住んでいたのだともいう)。タサハラの修行ってどう、とか。まあそんな話とか、同乗者のおしゃべりとか、自分の名前の意味とか、そういう他愛もない話をしているうちに、たどり着いた。

タサハラの設備

タサハラは山奥の小川に沿ったちょっとした谷間のような場所にある。Tシャツや本といったちょっとした土産物もある受付でチェックインを済ませ、簡単に注意点とかをおしえてもらう。周囲の施設は禅堂とか食堂、われわれのようなゲストの客間、温泉、あとは修行者たちの部屋などくらい。禅堂は日々のお勤めのほか、瞑想のクラスとかもある。

食事の時間以外はあまりやることはない。ハイキングとか、散歩とか、本を読んだり、写生をしている人もいたかな。あとプールがあった。プールは小さいけど温水プールだという話で、わりとふつうのプールっぽかった。ほかにもヨガとか瞑想とかのワークショップに参加している人が多そうだった。われわれは軽くハイキングをして、開祖の鈴木老師の碑を見たり、近くの滝を見にいったりした。

部屋の文明度がまったくわからなかったのでもしかしたら夜まっくらかもと思っていたのだが、われわれの泊まった部屋だと明かりはもちろんコンセントもあって拍子抜けした。携帯の充電とかも全然可能。まあ充電しても使いみちはないけれど。といいつつ、ぼくはダウンロードした電子書籍を携帯電話で読んだりもしていた。

温泉

われわれの主目的は温泉だったわけだけど、温泉はかなりよかった。男女にわかれ(なぜか女性は男湯に入ってもよいというルールがあったが)、ふつうに風呂に入れる。内風呂があり、開放的なテラスがあって川を臨むテラスに出られる。テラス脇には露天風呂があり、その隣にはサウナもある。サウナ脇には水風呂はないのだけど、そのまま階段を下るとそのまま川の清流に入れるようになっていてこれが水風呂として機能している。みんなテラスで寝っ転がったりのんびりしていて雰囲気もよい。泉質については語彙がないので多くは言わないが、肌はものすごくツルツルになった。

けっきょく24時間で4回はいった気がする。宿舎からはやや遠いので、あまり夜遅い時間に行くなら懐中電灯などがあったほうがいいだろう。

食事

ゲストには朝昼晩の食事が出る。禅寺なので料理はベジタリアン。でも和風ではなくて洋風なのが面白い。初日の昼は豆のスープとサラダとパン、夜は焼ポレンタときのこソースに野菜炒め、翌朝はグラノーラとヨーグルトにマフィン、昼は葱ポテトスープとサラダとパン、といったところ。味はどれも美味で、けっこうお腹いっぱいになる。それにしてもこういう食事をしていると、なぜ日本では仏教の戒律のわりにチーズとかの乳製品が流行らなかったんだろうか、とちょっと不思議になる。いやそれは東アジアの仏教国だいたいみんなそうかもだが……。

ところでタサハラのパンは有名なんだそうで、も出ていてパン自作派のバイブルみたいになっているのだとか。食べてみると、びっくりするほど美味い!というものではない。でもなんというか、しみじみとうまくていっぱい食べれる。そういうところが魅力なのだろう。

夕方のスナックの時間もあったんだけど、これはのがしてしまった。

ちなみにお茶を出す給湯スペースみたいな場所が24時間開放されていてお茶は各種飲み放題だ。

帰り

そんなこんなでわれわれは一泊を過ごした。一泊だけというのはかなり短いようで、行きのピックアップの同乗者からは呆れられていた。たしかにこれは長期逗留したくもなろう。

われわれのように自力でタサハラにたどり着かなかった場合、帰りも同じように車に乗せてもらって待ち合わせスペースまで帰してもらう必要がある。便は日にいくつかあり、何時の便に乗るかはチェックインのときに確認した(いつでも受付にいけば調整可能だろうけれど)。われわれは3時の便に乗った。

帰りの運転手が、Tassajara(タサハラ)という言葉の語源について新説を教えてくれた。ネイティブアメリカンの言葉だとか意味はどうだとか、いろいろ言われているけど、どうやらスペイン語が語源らしいんだよね、と。まじか。語源、混迷を極めているな。

そんなこんなで乗っていると同乗者の女性がちょっと停めて、という。で道端の草を摘んでいた。これはネイティブアメリカンの薬草で健康にいいのだという。お湯で煮出して飲むといいから。あなた体調わるいから(実際ちょっと風邪気味だったのだ)あげるわよ、とかいって薬草をもらった。帰ってからいわれたとおりに煮出した苦い薬草茶を飲んでみた。その夜、妙な高熱が出て寝込んだが、これが薬草茶の作用なのか偶然かはわからない。翌朝起きたらスッキリしていた。薬草の名前はきいたが忘れてしまったのでわからない。


最後のくだりはさておき、なんとも夢のような体験ではあった。インターネットの浮世とはなれ、本を読んだり温泉にはいったりしながらのんびりとすごす場所。わるくない。ネットと隔絶するからかなんなのか、サウスベイにありがちなテック企業の人々とはあまり出くわさなかったように思えたのもよかった。モントレー在住の整体師とか、サンタクルーズに住んでもう毎年きているおばあさまとか、そういう人たちが多い(高齢者が多い)。カリフォルニアの地にあって禅寺というのは、かなりスピリチュアル色がつよい場所であって、自分はそういうのはけっこう辟易とするのだけれど、でも楽しめる場所ではあった。

また来たい。

海街diaryにおける携帯電話の歴史

海街diary』が9巻「行ってくる」にて無事完結とあいなりました。最後の方はこう、予定調和的ではあったけれども、とにかく、やっぱり、ほんとうにおもしろい漫画でした。

これは1巻から読み直さなければ、という気分が高まり読み返していたのですが、読んでいて気づいたことが。

パカパカ二つ折りケータイつかってるじゃねーか!ということですね。左画像は1巻冒頭のシーンですが、ちょっと懐かしいデザインの二つ折り携帯電話。いっぽうシリーズ終盤(右画像、7巻より)はスマホを使ってLINE(のようなもの)のグループチャットに完全移行してました。

思い返してみれば海街diaryの第1話が雑誌掲載されたのは2006年。今のようなスマホが存在していなかった時代なわけで、12年の歳月というのはそれほどの違いを生むわけでした。それにしてもどういうふうに移行していったのだろうか、というのがちょっと気になったので集めてみた。海街diaryにおける携帯活用の歴史。

1巻 (2007年刊行)

Screenshot 2018-12-14 at 23.55.51

ツイートでも引用したこのコマ。1巻冒頭のシーンですが、メールと通話で連絡を取り合ってます。

3巻 (2010年刊行)

香田姉妹のそれぞれ。あと上司も二つ折りケータイですね。長女の幸はストラップみたいなのをつけていますが、先が切れている。性格を反映したものか、どうか。

4巻 (2011年刊行)

末妹のすずも携帯もってました。というか中学生サッカーチームのみんなが持って連絡網をつくっているっぽい(風太だけ家庭の方針で持っていない)。でもやっぱり二つ折りケータイ。右の画像では「将来ケータイ買ったとき」のためのストラップを貰ってます。ストラップつけられないからスマホは……みたいな人もいたよなぁ。

5巻 (2012年刊行)

あんまり関係ない話ですが、右のみたいな公衆電話、もうあんま残ってなさそうですね。中学生の少年が携帯電話をもってないのもめずらしいというが、福田さんのようなじーさんも持っていない。これはまあ別にいまでもリアルでしょうけど。

左はここまでの話とは無関係ですが、これより前の巻で香田家の家電がコードレスだった描写があったのに、ここではコードつきにもどってしまったのがちょっとおもしろくてキャプチャしてしまいました。

それはさておき5巻はここの描写も面白い。

Screenshot 2018-12-14 at 23.42.25

あいかわらず幸は二つ折りケータイですが、ヤスのほうはスマホ(iPhone?)使ってる! たぶんこれ、本作におけるスマホ初登場シーンです。

6巻 (2014年)

Screenshot 2018-12-14 at 23.44.06

すずがスマホに移行してる!! まめに保護フィルムつけてますね。

Screenshot 2018-12-14 at 23.45.29

幸もか!! ヤスか? ヤスの影響なのか……?

すずはこの巻では携帯の地図アプリも活用しまくっています。

7巻 (2016年刊行)

Screenshot 2018-12-15 at 00.13.44.png

で7巻のここのくだり。LINEですね(名前はちがうけど)。いつのまにやら姉妹全員スマホになってグループチャットで連絡していたようです。とはいえ、作中でも2年ぐらいたってるし、こういうのの移行は、まああっちゅーまではあります。7巻はこのあと修学旅行のシーンもあり、女子たちがスマホの地図アプリを活用しています。

コミュニケーションのツールとしてはこの “NYAIN” が最後まで使われることとなりました。二つ折りのフィーチャーフォンでメールする時代に始まって、スマホが登場し、しだいに誰もがスマホを使うようになり、やがてLINEが席巻してだれでもLINEで連絡を取り合うようになった、という世の流れがお分かりいただけたかと思います。

番外編:ラヴァーズ・キス (1995年)

ところで『海街diary』と切っても切れない関係にある作品といえば『ラヴァーズ・キス』です。この作品は95年発表とだいぶ古いので、この手の技術とは無縁のストーリーなのですが、登場人物が一部かぶっているので、時期の比定が可能になってしまう問題が……とおもいながら見ていたらこんなセリフを発見してしまった。

Screenshot 2018-12-14 at 23.28.59

手前のキャラは「海街」のマサのアニキですが、中2のときに鎌倉にきて、本作では高1。この「じゃ震災だいじょーぶだったの?」というセリフがどういう意味かわからない方がいるかもわかりませんが、これはもちろん1995年1月の阪神淡路大震災のことです。

作中は初夏ぐらいの出来事とおもわれるので、このセリフとつじつまが合うのは95-96年ぐらいに限られることになります。ということは「海街」も90年代末の出来事ということに……? スマホとは……? NYAINとは……??


とまあ、くだらない細部にあえて着目してみましたが、もちろんこれはただの難癖のようなもの。こうした時代考証のようなものは軽やかに乗り越え、同時代的なストーリーを紡いできたのが『海街diary』の魅力だったのではないか、とあらためて感じました。みんながいつのまにかスマホに移行してたのに、読んでたときはとくに気づかなかったし。

そういうわけで、『海街diary』面白かったですね! ではまた!