世間一般で「時差ボケは東回りのほうがキツイ」という話をよく聞く。これは日本に限らず、むしろ英語の方がそうした記載をよく見かける。日米間の出張はもう数えきれないほどしているが「東回り西回り」にはほとんど実感がなく、どういう理屈なんだろうと考えていたらはたと気づいた。これ、例えば米国国内や欧州内、日本とアジア諸国内など、時差がせいぜいひと桁時間の範囲での話を扱っているのだと。

時差ボケに関連する差異を考えると、東回り西回りには確かに違いがある。それは時計が進むか戻るかである。つまりは

• 東回り：時計が進む → 体内時計より早い時間に寝て早い時間に起きる
• 西回り：時計が戻る → 体内時計より遅い時間に寝て遅い時間に起きる

という話である。例えばサンフランシスコとニューヨークでは時差が3時間あるが、米国西海岸から東海岸に出張すると、現地時間の朝7時(ET)は出発地の朝4時(PT)である。逆に東海岸から西海岸への出張では、現地時間夜11時(PT)は出発地の午前2時(ET)となる。

つまり東回りと西回りでの時差ボケの違いとは、早寝早起きするよりも遅寝遅起きするほうが楽な人の方が多いという話に帰着するのだろう。確かに何かのイベントの時に遅くまで起きていることはあっても、無理して早く寝るのは人間の生理として難しいし、早寝が出来なくても早起きをせざるを得ない場合には睡眠時間が削られることになる。

そしてそれは日本と米国東海岸のように時差が12時間前後まで大きくなってしまうと、時計が進む戻るに関係なく、単に昼夜が反転するだけであり、早寝遅寝で解決するものではなくなる。なので東回りだろうが西回りだろうが時差ボケの辛さにはほぼ関係ないということになるのである。と言うか、そもそも昼夜逆転なので西東回り関係なく辛い…。

個人的感覚では出張などの場合、行きよりも戻ってからのほうが時差ボケの解消に時間がかかる感覚がある。これは緊張感の問題なのかもしれない。それも最近はメラトニンのお陰でほぼ数日で回復してしまえるようになったわけであるが。

素のAndroidが使える e-ink 端末はやはり素晴らしい

とかく世の中では e-ink 書籍リーダーといえばもうほぼ Kindle のことであり、最近も世間の一部は高級機である Kindle Oasis や Voyage の話題で盛り上がっているようだ。私はといえば Android端末化したNook Simple Touch を相変わらず使っていたのだが、Nook は Android 2.1 という化石のような古いOSであることもあり、そろそろ買い替えが必要かと見つけたのが BOYUE T62+ という中華製 Android 4.2 e-ink 端末である。

端末は ebay にて $122.89 + Free Shipping で買ったのだが、中国から約2週間程で届いた。付随アプリも中国語や中国のマーケット対応のものが主だが、設定の言語選択には日本語もあり、また Root Boyue T61 + T62 の通り Root 取得して Google Play Store を入れればごく普通の Android 端末として好きなアプリを使うことが出来る。まあこちらでは基本的にはそうして使うのが前提だろう。一応 Nook 用に使っていた主利用とは別の Google Account で使っている。

ハードウェアと使い勝手

ハードウェアとしての質感には安っぽさなどはなくしっかりとした作りだ。左右ベゼルに順逆方向ページ送りのハードウェアボタンが付いており、その右ベゼル上には「戻る」ボタン、左ベゼル上には「表示更新」兼バックライト点灯（長押し）のボタンが付いている。電源ボタンは右下。本を読むのに集中するためにタスクバーを非表示にするとホームへの動線がなくなるのが難点ではあるが、full!screen などで対応できる。本体ストレージはシステム含め 8GB と小さめだが、microSD が使えるので自炊書籍を入れておくには全く困らないのも素晴らしい。

使い勝手的には Nook Simple Touch の上位互換だ。T62+の方が多少重いのと、本体背面の凹凸がないので指を多少引っ掛けにくいが、マットな表面とフラットな重心バランスで、片手で持ってベゼルのページ送りボタンを押しつつ読むという使い方に問題はない。ハードウェアボタンのクリック具合も悪くないし、3年以上も前のNookと比べればCPUや e-ink ディスプレイも良くなっていて、ページ送りの速度も十分に早く、ほとんどストレスを感じない。e-ink のディスプレイも店頭で見る Kindle Paperwhite (2015) と比べて解像度こそ低めなものの、さほど見劣りはしない。バックライトもベゼル際の数カ所を除いてほぼ均等に照射され、暗い場所での読書もさほど問題は感じない。

唯一、バッテリーの消費は心持ち早い気がするので、手動で Wi-Fi や Sync を OFF にするなどの運用をした方がいいかもしれない。とは言え本を読むだけであれば数日は問題なく使える。

ソフトウェア、ないしAndroidアプリがそのまま使えるということ

読書端末にさほどのアプリは必要が無いので、入れたのは以下の程度。当然ながら Android 用の Kindle App も入れて使うことが出来る。また Root を取っているのでフォントなども好みに応じて変更ができる。

• Amazon Kindle
• 読書家 (青空文庫形式ファイルリーダー) : 青空文庫などテキストファイル縦書き表示用
• Perfect Viewer と PDF Plugin : 自炊画像書籍
• Cool Reader : epub, mobi, text ファイル等の電子書籍
• X-plore File Manager : Sambaやクラウドストレージとのファイルのやり取り

Kindle App を含む多くのリーダー系では Volume Button でのページ送りができるので、BOYUE の設定からページボタンを Volume Up/Down としても使う設定をしておくとこれらのアプリでもハードウェアボタンでのページ送りができるようになる。たまにアプリの起動にすごく時間がかかることがあるが、RAMが小さい影響だろうか。アプリが立ち上がってしまえばほぼ問題はない。また e-ink なのでスワイプやフリックへの追従が遅いとかグレースケールでの設定画面の文字が読みにくい場合があるなど不便な点はあるが、まあ我慢はできる。

そんなわけで例によって普通のAndroidが動く e-ink リーダーを手に入れて使っているが、使いやすいビューワで読書ができるしファイル転送も端末からLANやクラウドストレージを経由して簡単にできるのが便利。値段もさほど高くないし、自炊が中心の人で自分で Root 取得できる人であれば十分お勧めできる。少なくとも私はこれで当分は満足して読書できそうである。

スペック

• 160 x 123 x 8.5 mm, 224 g
• 6インチ e-ink ディスプレイ 1024x758 (213 dpi), グレースケール 16階調, バックライト
• A9 Dual Core 1.0GHz CPU, 512MB RAM
• 8GB internal storage (5GB程度の空き容量) + microSD slot (up to 32GB)
• Wi-Fi 802.11b/g, microUSB, イヤホンミニプラグ
• Android 4.2.2 (2016-06 現在の Firmware )

いつぞやのEDCキーチェイン記事にも書いた Swiss+Tech Utili-Key (Amazon JP) である。今日はこれの素晴らしさを語ろう。

機能としては「ナイフ（ストレート・波刃）」「プラスドライバー」「マイナスドライバー（2種）」「栓抜き」の6種。ツールとしての出来は、まあ感心するほどではない。ナイフの切れ味はそこそこかつ研ぎにくいし、ドライバーの精度も取りあえず使い物になるレベルだ。しかしそれは問題では無い。こいつの真価は鍵と一緒にいつでも持ち歩くことにある。

切れ味そこそこのナイフではあるが、例えばダンボール箱を封してあるテープを切る際、手では外しようがない結束バンドを外したい時、固く縛られた麻やナイロンのひもを切ってほどきたい時などには大活躍する。買った服についているタグを切り離したり、手で開きにくいお菓子の袋を切って開けたりと、ナイフをわざわざ探しに行って使うほどではないが手元にあってすぐに使えると便利、という状況は意外に多い。

またこれも精度そこそこなドライバーだが、プラスとマイナスのドライバーがいつでも手元にあるのはこれがなかなか便利なのである。特にプラスドライバーの大きさはラップトップPCの背面ネジや子供のおもちゃの電池蓋など、生活でネジ回しが必要になるサイズに意外とフィットする。眼鏡のネジを締めるのにも使えないことはない。ドライバーが見つからなくて先の平たく尖ったものを斜めに差し込んで無理やり回す、なんてシチュエーションは記憶に無いだろうか。そんな時にこそちょっとしたドライバーが非常に助かる。

栓抜き。あなたが仮にアメリカ人であれば多分カバンだのなんだのいたるところに栓抜きが付属しているだろう。なぜか知らないが米国人は栓抜きが大好きである。しかしあなたが日本人であるなら、栓抜きはそこまで身近にはないだろう。そもそも栓抜きが必要なシチュエーション自体が日本では少ないだろうが、だからこそ必要になった時に栓抜きが手元にあるのはありがたいものである。

結局のところこのツールは程々の品質だがあると便利なツールが鍵と一緒にいつも身につけて持ち歩けるのが最大の強みだ。開閉のロックがしっかりしているのでキーホルダーに付けていて勝手に無くなることもないし、着脱も簡単だ。また値段も安いので、壊れたり無くしたり没収されたりしてもさほど痛くない。これの最大の欠点が「持ち歩いていることを忘れてしまう」というくらい、常に持ち歩くことに特化したツールとしては大変よく出来ているのである。

値段も安いのでぜひひとつ持ち歩いてみて欲しい。あ、一応はナイフなので軽犯罪法云々にはお気をつけを。

さて先日買ったPebbleだが、せっかくスマートウォッチを買ったことだし、ウォッチフェイスのひとつくらいは自分で作ってみることにした。シンプルなアナログ時計のデザインで Health の Steps (歩数計) と Weather (現在の天気) を出してくれるウォッチフェイスが見当たらなかったので、その方向で作成。Obsidian という名前にしたけど背景が黒いから以上に根拠はない。

Pebble AppStore にも上げておいた。Submit してすぐ有効になったけど手動の審査とかはないのかな。

• Obsidian // Pebble Watchface // Pebble Appstore

気温の C/F や各パーツの色は設定で変更が可能。

Pebble の開発環境は基本的に C + JavaScript で Linux 用のSDKがあるが、CloudPebble という Cloud9 のようなブラウザ上で動く開発環境があるのでそれを使って作業した。Compileから Virtual Machine を動かしてのテストや、Pebbleアプリの Developer Connection という機能を使って実機にアプリを流しこみつつアプリの実行時ログを見るなどもできるので、結構使いやすい。インラインの補完も効くし、Githubとの連携もできる。

Pebble の開発は先述の通り C と JavaScript で、アプリ本体部分を C で書きつつ外部Webサービスとの連携、例えば天気予報の取得などを JavaScript で記述する形になっている。C 部分はよくある GUI ツールキット作成の構成で、コールバックを作ってGUIパーツをレイヤーとして位置・色・リソースを割り当てて重ねていく形。C と JS の間は Data Dictionary を介したメッセージのやり取りになっていて、これもよくある。ウェブアクセスや文字列操作系を JS に任せられるのは楽といえば楽。

開発にあたってはチュートリアルもあるので、Build Your Own Watchface // Pebble Developers をたどれば時計と天気を表示するところまではだいたい進むし、Examples // Pebble Developers にアナログ時計のサンプルもあるのでその辺りを参考にできる。

ちょっと面倒だったのが設定画面で、Pebble の設定は外部にWebサーバを立てて JavaScript でそこに飛ばし、HTML Form の設定値を JavaScript で持ってきて Dictionaly に入れて C コードの Tuple に渡す、という割と迂遠なやり方になっている。このためにWebサーバを使うのもなあと思ったら、 RawGit という Github のコンテンツをそのまま配信してくれるサービスが有ったのでこれにホストしてもらうことにした。

そんな感じで一応は使用に耐えるウォッチフェイスをひとつ作ったのでコードは公開しておく。書き方を調べながら書いたのでコードがかなり汚いのはご容赦頂きたい。なお基本的に Pebble Time Round (CHALK) での動作確認はしているが、Pebble Time (BASALT) の方は実機もないしあまり真面目に画面表示のチューニングもしてないのでそこもご容赦を。

• Pebble Watch Obsidian // Github

背景に Bitmap イメージを貼れるので機能にこだわらなければ好きなデザインのウォッチフェイスを作るだけなら簡単だと思う。しかしテストを書きにくいのは皆どうしているのだろう。

追記・更新記録

• 1.3 Weather Provider を OpenWeather.org から Weather.gov に変更。早く Pebble SDK が Weather API を提供して欲しいのだが、取り敢えずの対応として。また Notification から Back で戻ると時計の針や各種情報が非表示になる問題に対応。.did_focus handler を書いたけどこの辺りの Best Practice が見当たらない。と言うか Pebble 側の不具合だと思うのだけど。

米国でのキャリアの考え方は日本とは結構違っている。個人的に例えるのが RPG での転職システムで、「スキルレベル」を上げたり「新しいスキル」を習得することで「職業クラスのレベル」が上がったり「転職可能な職業クラス」が増えるというモデルだ。あくまで一例だが、ソフトウェア開発系で Developer のキャリアを書くとこんなイメージだろうか。

Developer としてプログラミングや基盤技術などを上げていくと Developer レベルの昇格が可能になる。そのまま Developer としてレベルを上げていくキャリアもあるし、エンジニアリングに加えてチーム内で取りまとめ役をこなしているうちに Dev Lead 系の職に進んだり、技術戦略などのスキルを得ることで Architect 系の職に進むといったパスが考えられる。

Manager 職は「チームの管理」や「人事」といったものを押さえる職業クラスであり、管理職系キャリアパスの入口になる。そもそも米国企業では Manager クラスが採用や給与額の設定を直接行うケースが多いので「人事」スキルが欠かせない。最初の昇格としては担当として働いているチームでまとめ役として仕事をしているうちに上の Manager が辞めてその後任をオファーされたり、チームサイズが大きくなって分割層として Manager が必要になったりとチーム内から昇格するパターンが少なくない。なお Manager キャリアからは Director や VP など管理職系上位職へのキャリアパスに繋がっていく。

またキャリア軸の変更として、エンジニアリングスキルに加えてプロダクト戦略やマーケティングなどを学ぶことで Product Manager （日本で言うプロダクト企画系の職）へのパスを取ることも出来る。社内でのプロダクト知識を元にそちらの職にキャリアを向けることもあるが、こうした転職にに現在の職業クラスで習得できないスキルがある場合、キャリアの途中で大学に通って必要な学位を取ることで必要スキルを習得するというパスもありうる。

なお米国の場合は自分がなにもしなくても成果が出ていれば上にあげてもらえる、なんてことはあまりなくて（同じ職業クラスの中でのレベルアップはありうるが）、基本的には社内にしても社外にしても自分で新しいポジションに応募して職を変えるのが基本になる。

Developer という上級職種へのパス

ちなみにそもそも Developer というポジション自体が米国では結構な上級職である。大学でCSを習得していきなり Developer から始める人もいるが、そうでない場合は例えば技術初心者でも採用されやすいサポートデスクなどからキャリアを始めて

• サポートデスク → テクニカルサポート → システム管理者 → デベロッパー

といった感じに職を変えていくパターンが多い。これも基本的には下の職業クラスで技術スキルを習得し、そのレベルが一定以上上がると上級職への転職が可能になる形だ。なお余談だが米国ではこうした初学者向けの職種がオフショアで国外に出てしまい、技術系キャリアのスタートが難しくなっているという事情も存在しており、スタートからよい大学を使う必要性が増えている。

一方で当然ながらこうしたキャリアの途中で「これ以上仕事を変えなくていいや」とストップする例も多い。基本的にキャリアパスは上に行くほど競争率も上がり学習コストも高くなるので、誰もが上のキャリアを目指しているわけではない。逆に言えばこうしたキャリアパスで上位職に上がってきている人というのはほぼ例外なく業務に関する学習を続けているものである。