| @旅行/散歩

角島大橋

GW 前半の 4/29, 4/30 で山口県に行った。子どもが SL やまぐち号に乗りたがっていたのと、自分が下関の唐戸市場と角島に行ってみたかったから。旅行計画はこんな感じ。

予定表

家庭内 Kibela にエントリーを書いて嫁さんと共有しながら計画を練った。ただ嫁さんはめんどくさがって前日まで見てなかった。自分は電話が嫌いなので SL やまぐち号のチケット予約の電話を嫁さんにしてもらった。

予定では朝 7 時に家を出ることになっていたけどうだうだしてしまって結局は 9 時半頃家を出た。昼前に関門海峡に差し掛かり、関門橋を見渡すことができる PA で写真撮影して本線に戻り下関 IC で降りたところで嫁さんがシートベルトをしておらず後席シートベルト不装着で長州の官憲につかまえられた。関門橋のところの PA まではシートベルト着けていたとのことなのであれはトラップだと思う。ゴールド免許復帰の夢は潰えた。

関門橋

門司港

下関市役所の駐車場に 11 時半頃到着し、歩いて唐戸市場へと向かった。下関の印象は門司と似ていた。昭和の雰囲気を色濃く残す寂れた商店街の感じは、あぁ、門司と下関は双子の都市なんだなぁという思いを抱かせた。

下関の商店

下関の商店

下関の商店

唐戸市場は昼時ですさまじい混み具合だった。ようやく食べ物を調達しても座って食べられる場所を探すのが大変。人混みの中で押し合いへし合い状態で買った海鮮丼は大したことなくて、唐戸市場はアクティビティとして来てみるのはよいけどわざわざ食事を目当てに来るほどではないなと思った。

唐戸市場

唐戸市場

テラスから関門海峡を通るタンカーや船を眺められるのはよかった。タンカー、普段は港に停泊してるやつか沖合を航行してるやつしか見ないと思うけど、間近で見るタンカーは結構速いスピードで動いてるという知見が得られた。

関門海峡を横切る船

関門海峡を横切るタンカー

関門海峡を横切るタンカー

関門海峡を横切るタンカー

唐戸市場を出たあとは商店街にある自家焙煎のコーヒー屋でサイフォンでいれたコーヒーを飲んだ。

サイフォンコーヒー

サイフォンコーヒー

その後角島を目指して日本海側を移動した。海沿いの景色は福岡の糸島と同じような風景だったけど、とてつもなく長いビーチがあって気持ちよかった。角島には 4 時頃着いた。運良く空いたところに停められたけどすごく人が多くて車を停める場所を見つけるのが大変だと思った。この日は曇り気味の天気でガスも多く、角島大橋の景色ははっきりは見えなかった。橋を渡って角島の方まで行ってみたけど観光名所となっている灯台のあたり(映画の舞台になったらしい)は駐車場代が福岡の天神よりも高くバカらしくて車を停めはせずぐるっと回って戻ってきた。角島大橋近くの店でコーヒーを飲んで休憩したあと、併設の萩焼の店で嫁さんがいくつか器を買った。

角島大橋

砂浜

砂浜

BB HOUSE

6 時頃から今度は宿泊先の山口湯田温泉に向かった。途中、秋吉台を見ていきたいと思っていたけど道に迷った&日が暮れてしまい、結局秋吉台を見ることはできなかった。 8 時頃ホテルに到着し、繁華街に出かけて食事をした。結構迷ってふらっと入った店は悪くはなかったけど会計がすこぶる高く卒倒した。宿に戻ると 11 時半を過ぎており、併設の温泉の利用を断られた。予約していた部屋がツインではなくダブルの部屋だったことを嫁さんにとがめられ床で寝た。

翌朝、朝食が無料で付いていたので食べに行ったところ、無料なのに地元のおばちゃんたちが作る煮物などがどれもおいしくびっくりした。チェーンのビジネスホテルで家庭の朝食みたいなやつが食べられて良かった。

食事を終えてチェックアウトし、コインパーキングを探して車を停め、メインの目的の SL やまぐち号に搭乗すべく湯田温泉駅へとタクシーで移動した。湯田温泉駅はつつじが満開だった。

つつじ

SL やまぐち号は非常に混雑していた。また車両は古くてすすけていた。 SL は子ども時代に家の近所を走っていた ASO ボーイの試乗運転にしか乗ったことがなく、長距離を乗るのは初めてだった。 SL 特有の動き始めたときに車輪が滑ってずるっとなる感じが印象的だった。

SL やまぐち号

SL やまぐち号

SL やまぐち号

SL やまぐち号

SL やまぐち号

やまぐち号の目的地は島根県の津和野で、車窓からの風景は山また山、時々田園地帯という感じだった。石州瓦の赤い屋根瓦の家々が印象に残った。日本海側で降雪量が多いことも関係あるのか、切り妻屋根の家が多いなと思った。

石州瓦の屋根

石州瓦の屋根

田園風景

津和野は昔ながらの雰囲気を残す街だった。小京都と言われているようだが、中山道の宿場町の馬籠宿に似ていると思った。小さな街なことと帰りの SL までの時間が限られているのでレンタカーを借りるほどでもなかったので駅前でレンタサイクルをかりて街を回った。昼飯を食べなければならなかったが着いた時刻が 14 時前でどこの飲食店も軒並みラストオーダーを過ぎており、昼食を食べる店を探すのに難儀した。森鴎外の出身地とのことなので鴎外の生家に行ってみたかったが、三時間弱の滞在時間では時間が足りず、菓子屋で名物の源氏巻を食べ、閉店しようとしていたところを何とか滑り込んで割子そばとうずめ飯を食べ、酒蔵を二軒回って日本酒を買った(2本買ったうち1本は列車から降りるときに嫁さんが落として割った)ところでタイムオーバーとなった。

津和野

津和野

津和野

津和野

津和野

源氏巻き

割子そば

うずめ飯

山口の湯田温泉駅に戻るとどっと疲れが出て、これから福岡まで運転して帰るのかと思うと暗澹たる気持ちになったので帰る前に足湯に浸かって帰った。街中に綺麗な足湯スポットがあって 200 円で入れて、足湯に浸かりながらコーヒーなどを飲むこともできる。

IMG_2979 DSC_2938

いろいろ盛りすぎて一泊二日で行くには時間が足りなかった。特に津和野にはもう一度行ってみたいと思った。

SL Yamaguchi Tour

| @労働

Kaizen Platform

Qiita:Team エントリのレベルが高い

CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。

SRE (インフラチーム)のレベルが高い

インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。

yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA (総務部門のドン)やってるし、 glidenote さんは SRE 業務をこなしつつも R&D して新しめの技術をどうやってビジネスにフィットさせていくかを追求したりしてる。

SaaS や IaaS をフル投入したモダンな開発体制

SaaS や IaaS を使うのはかっこいいからとかエンジニアが楽しいからではなく、その方が最終的にかかるお金が少なくて済むし、事業の圧倒的な成長に対応(スケール)できるから。詳しくは yosudo さんのスライドをご覧ください。

コードのクオリティが高い

Kaizen Platform も 5 年目に入っているのでプロダクトのコードがレガシー化しているところがあるのは否めないけど、レガシーと言っても本当に悲惨なレガシーコードとは比較するべくもなかった。ユニットテストはちゃんと書いてあるし1、インフラは AWS だし平均的な水準が高い。メインのシステムは Ruby と Rails で構築されていたけど、一部の機能を Go lang でマイクロサービス化したり、ログ集約サーバーは Node.js で構築されていたり、場所によっては C で書いて高速化してあるところもあり、特定の技術に依存するのではなく目的、状況に応じて柔軟に使う技術を選定していくところがこれまでにない感じだった。エンジニアが Ruby しかわからないから Ruby をずっと使いますというような消極的な技術選定ではなかった。

プロダクトマネージャーがいる

プロダクトマネージャー( PM )がいる会社で初めて働いた。データ取りとかは PM 自身ががんがん SQL 書いて取るし Domo や Redash などの BI ツールを PM 自身が使いこなしているので「○●のデータを本日 11 時までに大至急抽出してください!!!、!(現在 10 時)」みたいなことを割り込みで依頼されるということはなかった。プロダクトマネージャーは技術、ビジネス、市場、顧客のすべてに精通していてリーダーシップがあり、ミニ CEO のような人たちだと思った。

QA チームがいる

PM のほかに QA チームの人がいて、 QA 観点で動作検証したり仕様に指摘をしてくれてめっちゃありがたかった。しかも QA チームの皆さんが優秀。エンジニアが自分で作って自分で動作検証するのではどうしても先入観が入ってしまって検証が不十分になると思う。むかし働いていたブラック企業では午後 10 時まで開発したあと午前 4 時まで自分で作ったやつを動作検証してエクセルエビデンススクショ職人業もこなしてたけどあれは本当に不毛だった。エンジニアが作ることに集中できる環境はすばらしい。

社長が近い

社長室などはなく、 CEO も普通にフリーアドレス席に座って仕事しているので CEO がすごく身近な存在で話しやすかった。会社にいる人たちも CEO に対して従順というよりは、その道のプロの人たちが集まっていて、若い CEO を助けるために一肌脱いでる感じがあった。雇われているというより雇われてやってる感じ。 CEO のことを親しみを込めて「スドケン」と呼び捨てにするし、むやみやたらに上下関係を作って序列通りにひれ伏すのはださいという雰囲気があった。

セールスが強い

こんなに強力なセールスがいる会社で働いたのは初めてだった。砂漠でこたつを売ってくる男の異名を持つ人がいたり。元リクルートの人たちを中心とした精強なセールスチームがいて、大企業からどんどん契約をとってきてた。自分はこれまで中小零細企業とか上場企業でも個人向けサービスをやってる会社でしか働いたことなかったので、こんなに大人っぽいカッチョイイセールスの人たちがいる会社で働いたのは初めてだった。

社員の趣味がエクストリーム

雪山スキーとかサーキット走行とかフルマラソンとか雨が降らない限り毎週末キャンプしてるとか鎌倉に住んで毎朝サーフィンしてから仕事とか、社員の趣味がエクストリームだった。アウトドアでなくても仏像なぞり描きと御朱印集め、囲碁、観葉植物、美食、マイル乞食、不動産運用、マンション管理組合理事など、趣味が中途半端な人がいなかった。

性善説とアンチマイクロマネジメント

社員は悪いことをしないという前提で会社が動いているように思った。承認システムみたいのがあるにはあったけど、新しい SaaS を使いたいときには CTO に相談すればよかった。マイクロマネジメントを嫌う風潮もあり、休みをいつ取るかなどは自由だった。細かいマネジメントをする方が無駄にコストがかかるし、そもそもマイクロマネジメントが嫌いで大企業を辞めてきた人たちで構成される組織だった。

求められる水準が高い

マイクロマネジメントされない一方で、求められる水準は非常に高い。四半期ごとの目標設定と評価面談では、目標として設定したことをこなすだけではマイナス評価となる。目標を達成するのは当然で、求められていること以上の成果を出すことができたかが評価軸だった。

採用フローで期待されていることを説明される

自分が受けた頃は採用にとても時間をかけていて、これこれこういうことを期待しています、ということを丁寧に説明された。 2 回くらい現場の人と面接して最後に重役と面接して「お、キミいいネ、採用!」という感じではなかった。むしろ最初に CTO と話して次に CEO に口説かれ、あとから将来同僚となるエンジニアやプロダクトマネージャーと話すという感じだった。採用フローでポジションや求められる役割について説明があり、入ってから「俺はマネージャーだったのに平で雇いやがって」というような期待のミスマッチが起こりにくかった2

情報が閉じられていない

会社の売り上げ、状況は公開されていた。毎週金曜朝から行われる All Hands で数字の共有があり、目標に届いていないなどのアナウンスがあった。また隔月で行われる全社合宿(合宿だけど日帰り)でも会社と事業の現状について説明が行われ、社員全員で今後の方向性についてディスカッションを行う文化があった。

仕事をしていく上で、会社の経営状況について知らされていることは重要だと思う。かつて働いていたブラック企業は顧客が自分たちにいくらお金を払ってくれているかを教えなかった(教えたら自分たちが搾取していることが従業員にばれるため)。お客さんがいくら払ってくれているかを従業員が知らないと払ってくれている金額に応じた仕事をすることは難しいと思う。


厳しいなと思うところもあるけど、意欲がある人には機会が与えられる職場だと思う。総じてパワーのある会社だった。

なんでこんなことを書くのかというと、実は Kaizen Platform を先月で退職していた。すべて自分の能力不足が原因で、決してペパボを辞めたときのような積極的な退職ではなかった。前回の退職は前進だったけれども今回の退職はまさに撤退という言葉がふさわしい。なので退職日に合わせて記事を書くことができなかった。

Kaizen では入社早々に障害を起こしてしまったり、アサインされたプロジェクトを頓挫させてしまったりで在籍期間中に大したバリューを出すことができなかった。

ただ Kaizen Platform で働いた 1 年 11 ヶ月は自分にとって非常に貴重な時間だったと思う。リモートワークのおかげでこれまでにない生活をすることができた。家族が忙しいときに家事をしたり子どもの幼稚園の送り迎えをしたり。普通のお父さんではできないようなことができた。

なにより通勤がないのが素晴らしかった。通勤は実際に移動してる時間は 30 分でも家を出る前の身支度が必要だったり、なんだかんだで朝晩に 1 時間ずつ時間を取られてしまう。家族がいる人の場合はこれが自分だけでなく家族の負担にもなる。通勤に取られる 2 時間があれば洗濯や炊事ができる。この 2 時間が生活にゆとりをもたらしてくれていたと思う。

ダイエットにも成功した。糖質制限をして減量したけど、普通に朝から出社して働いていたら食事の準備に時間をかけられず、摂取しやすい炭水化物中心の食事を続けていまもデブのままだったのではないかと思う。

半日休む必要はないんだけど、昼間数時間だけ自分のことに時間を割きたい、用事が終わったらまた仕事しよう、というようなことができたのがとても良かった。病院通いがとても捗った。

こういうの、ワークライフバランスと言ってしまえばありきたりな感じがするけど、ちゃんとワークライフバランスを保つのは尊いことだと思う。

反面、リモートワークにはつらい面もあった。何をやればいいかが明確ではない状態でのリモートワークはとても難しい(参照: リモートワーク)。チームメンバーの意識が統一されていない状況にもフィットしない。何をやるべきかを自分で明確にできる人遠隔でもリーダーシップを発揮できる人でないとリモートワークはこなせないと思った。自分にはその両方が欠如していた。誰からも管理されない状況で自分でやるべきことを明確にし仕事をしていくのは自分で自分を律することのできる人でないと難しい。サボろうとしているわけではないのに時間だけが経過していくのは非常にもどかしかった。小さい頃から親や学校の先生に「次はこれをやりなさい」、「あれをやってはダメ、これをやってはダメ」と指示監督されてきた人間が突如として管理されない状態で働くのはきつい。管理されて働いているときは管理者に対して不満を持ちつつも、管理されないと全く何もできない自分の不甲斐なさが露わになるばかりだった。

全体として、自分に足りない部分がわかった 1 年 11 ヶ月だった。上に挙げた、リモートワークをうまくやっていくための資質(何をやるべきかを自分で明確にできる、リーダーシップがある)は、オフィスでより良い仕事をしていく上でも必要なものだと思う。また自分のやりたいことに貪欲であるべきことを学んだ。エンジニアだけでなく、セールスやカスタマーサクセスなど違う職種の人と話をしていて感じたことだった。やりたいことがあるのに黙ってもじもじしててもやりたいことは回ってこない。やりたければ相応の準備をした上でやりたいと手をあげないとやらせてもらえない。空気を読まず、遠慮をしないことが良い仕事をしていくために必要だと感じた。

Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。


  1. むしろテストコード多すぎて CI が遅くなるのが問題だったけど CircleCI に重課金してテストを並列実行して凌いでた。 

  2. ただしたまに逆のパターンが起こってた 

| @Mac/iPhone

choosy+canary-chrome.png

少し前に rebuild.fm で miyagawa さんが紹介1されていた Chrome の Canary チャンネル2と stable リリースで Profile を分けて使うやつやってみたらとても便利。 Choosy.prefPane3 などのブラウザー切り替えツールとセットでやる必要があるので $10 お布施した。 Chrome は stable や beta など様々なリリースがある4が、 Canary チャンネルのみ独立した User Profile を指定できるようだった。

Choosy.prefPane は参照元のアプリケーションごとにブラウザーを指定したり( Slack からは Chrome Canary とか、 Alfred からは Normal Chrome など)、 URL に応じて指定したり( twitter.com は Normal Chrome など)もできる。これでミスって仕事用の Google Account で SaaS にサインアップしてしまったりということがなくなる。 とても便利。

Chrome への依存度が高くない人は仕事用に Chrome 、プライベート用に Safari のような使い分けでもよさそう。

| @技術/プログラミング

fish が流行ってるっぽいので移行してみた。 peco を使えるようにしたらほぼ問題ない感じで使えてビックリ。 ~/.zshrc 長くなってきてたし捨てられそう。よかった。

ちょっと触ってみた感じ、設定ファイルの配置場所が ~/.config/fish/ であること、 PATH の通し方が特殊であること、環境変数に値を入れるときは env FOO=bar のように env 付きでやらないと怒られることが変わってるなと思ったが、 fish スクリプトの文法が Ruby っぽくて書きやすい・読みやすいのはとてもよい。公式ページにある "Sane Scripting" の項目が面白かった。

Sane Scripting

| @Mac/iPhone

Mac の Day One を 2.1.8 にしたら日本語の文章を入力できなくなってしまった。正確には入力出来なくなるわけではないが、日本語を入力して変換したあと確定すると変換した文字列が選択済みの状態になり、続けて文字を入力しようとする消えてしまうというもの。こんな感じ。

なんか文章を書きたいと思っても入力できなくなるのきつい。最近は iPhone でも Mac でも読んだり書いたりできるのが便利で Vim を使わず Day One に直接文章を書くことが多くなっていた。書けないとなると結構ストレス溜まる。はよ直して欲しい。

追記(2017/05/08)

2017/05/04 に修正版リリースされてたっぽい。試してみたところ直ってた。

スクリーンショット 2017-05-08 10.41.46.png

| @Mac/iPhone

Contexts

アプリケーションスイッチャー使ってますか

Mac には標準で + でアクティブなアプリケーションを切り替える機能があるのをご存知ですか。こういうの。

macOS アプリスィッチャー

これは便利なんだけど、ブラウザーなどは複数のウィンドウ開くことがあり、アクティブなアプリケーションではなくアクティブなウィンドウを切り替えたいと思うことが度々ある。

Windows 7 には Win + でアクティブなウィンドウを切り替えられる機能があって、むかし仕事で苦痛に顔をゆがめながら Windows を使っていたときにもこの機能だけは Mac の方が負けてるなぁと思ってた。 UI が優れているというより、マウスに持ち替えずにキーボードだけで完結するのが良かった。

Mac ではこれは Exposé を使えということなんだろうけど、ささっとアクティブなウィンドウを切り替えたいだけなのにびろーっとアニメーションしつつウィンドウ一覧が表示されマウスカーソルでウィンドウを選択するのはだるい。キーボードから手を離したくない。

この要求を満たすのが Contexts というソフト。似たやつに Witch というのがあってこれも試したことはあったけど何かいまいち使い心地が好きになれなくて使うのやめてしまっていた。最近たまたま調べていたら Contexts というのを発見して少し使ってみたところすごく使いやすかったのでお金払ってライセンスキーを買った。

標準のアプリケーションスイッチャーの + のショートカットを Contexts のウィンドウスイッチャーが乗っ取っとる感じになる。

Contexts

これでも便利なのだけど、ウィンドウごとに表示されると選択対象が増えてしまって目当てのアプリケーションを探すのが大変になる。これに対しては二つ解決方法が用意されていて、一つは現在アクティブなアプリケーション内でアクティブなウィンドウを切り替えるコマンド( + ` )。以下は Google Chrome がアクティブな状態で + ` した状態。

Contexts selecting window from active application

とても探しやすい。

さらにアプリケーション名かウィンドウ名で絞り込み検索する機能も付いている。これで沢山ウィンドウを開いていても目当てのウィンドウを探しやすくなる。 + でウィンドウ一覧を開いているとき + S で検索モードに入ることもできる。

Contexts window filtering

どうです、便利でしょう?

アクティブなウィンドウを切り替えるという作業は一日何回もやるにもかかわらず、キーボードからマウスなりトラックパッドなりに手を伸ばして切り替えると、一回あたりは 0.5 秒くらいでも塵も積もれば山となっているかもしれない。日頃、 Mac を使っていてウィンドウやアプリケーションの切り替えでストレスを感じている方はお試しください。

| @写真

古い MacBook Pro の SSD がいっぱいになり写真が取り込めなくなっていたので外付け HDD を購入して写真は外付けに退避させた。母艦 Mac の SSD の空きが少なくなってきてるせいで写真を撮ることを控えるようになってしまっていたが、 3TB の外付けにライブラリを移したので本体側の空き容量を気にせず写真をばしばし撮れるようになった。これをきっかけに、いくつかのブログで目にしていた Google Photos を試してみたけど確かにこれは便利だった。Apple の写真( Photos.app )と比較しながら思ったことを書いてみます。

Google Photos への写真のアップロード

Google Photos を使うためにはまず Google Photos に画像をアップロードしないといけない。ブラウザーからちまちまアップロードする方法もあるが、 アップロード用のソフト が用意されているのでそれを利用した。名目上はバックアップということになるらしい。 20000 枚近い画像をアップロードするのに二日くらいかかった。アップロードに失敗することもあるけど、失敗したアップロードがあったときには通知してくれてリトライもできるのでおそらくすべての画像をアップロード出来たのではないかと思っている。楽ちん。

写真の内容を文字列で検索できる

こんな感じで「肉」と入力すると肉っぽい写真が表示される。画像認識処理をしてあって、個々の画像に対してタグ付け的なことがしてあるのだろう。

Google Photos で「肉」と検索

試しに Photos.app の方でも「肉」で検索したら肉の写真が表示されるようになってた。なんと Photos.app の方でも画像認識処理を行っているようだった。全然話題になってない気がする…。ドーナツの写真がヒットしているのはご愛敬。

Mac Photos.app で「肉」と検索

Google Photos では「ギリシャ」で検索するとギリシャの位置情報が付与されている写真に加え、どう考えてもギリシャにしかない建築物(アテネのパルテノン神殿など)が写ってる写真を検索結果に含めてくれる。賢い。

Google Photos で「ギリシャ」と検索

さすがにこのような機能は Apple の Photos.app の方にはないみたい。「ギリシャ」で検索しても、ギリシャに行ったときに iPhone で撮影した位置情報付きの写真しかヒットしない。キーワードと写真の関連性の判定アルゴリズムは検索エンジンをやってる Google の方にアドバンテージがあるみたいだ。

写真のグルーピング

Google Photos には「アシスタント」というタブがあって、勝手に過去の写真を漁ってグループにしてくれたり音楽付きのスライドショーにしてくれて、「金曜日の夕方」や「土曜日の午後」みたいなエモーショナルなタイトルをつけて煽ってくる。

Google Photos の「おすすめ」

機械がやってくれてる割には良くできてるとは思うけど、人間が選んだアルバムに比べたら素っ頓狂なセレクションが多いし、頻繁に Push 通知が来てちょっとうざい。「阿蘇旅行」みたいなアルバム作って通知してくるけど「旅行じゃないし、阿蘇に住んでたし」という気持ちになる。写ってるものの内容からアルバム名を考えて付けてくるのは賢いけど、わかりやすいものが写ってないとだめで、たとえばこのアルバムは大分の温泉とかいろんなところに行ったけど、最後にちょっと立ち寄った熊本城の写真がわかりやすいので「週末、熊本市にて」というアルバム名になってしまっている。このように Google Photos にはやり過ぎ感がある。

1156-irrelevant-album-name.jpg

※更新: この機能は「おすすめ」という名前に変わったようだ。 https://photos.google.com/foryou で表示される。プッシュ通知も送られてこなくなった。

Apple の Photos.app の方にも「メモリー」というメニューがあって似たような機能はあった。ただこちらは勝手に音付きのスライドショーを作ったり Push 通知したりはしてこない。控えめな印象。一年前の今日なにやってたかとか、直近の一ヶ月でどんな写真撮ったかだけが表示される。

Mac Photos.app の「メモリー」

Apple の Photos.app の方にあって Google Photos にない優れた機能としては、 GPS 情報が付与されていない写真(一眼レフで撮った写真)も大体どの辺で撮ったのか判定してグルーピングしてくれる機能がある。おそらく位置情報付きの写真の GPS 情報を参照して近い時間に撮影されたものはきっとこのあたりにいたに違いない、という感じでまとめてくれてるんだと思う。こんな感じ。

Mac Photos.app は同時間帯の位置情報入りの写真の情報を利用して位置情報の入っていない写真も同じ場所で撮られたと判定

↑の写真で 9 枚は一眼レフで撮影していて GPS 情報がないけど、同じ時間帯に iPhone で撮った写真は位置情報が付与されているのできっと長崎で撮ったのだろう、ということでまとめてくれている。この機能は旅行のときの写真を見るときに地味に便利。 Google Photos にもこの機能はついて欲しい。

写真をグルーピングすることに関しては、 Google Photos はアグレッシブ、 Apple Photos.app は控えめ、という印象を持った。というか Google Photos は攻めすぎな印象。アルバムのタイトルがエモ過ぎるので嫌いな人は見なくなりそう。

過去の写真の閲覧しやすさ

何より Google Photos が Apple Photos.app より優れているのは全ての写真をネットに繋がる限り無料で閲覧できることだと思った。 iCloud で同じことやると年間数万円お金払わないといけない。最近は仕事以外でパソコンを使う頻度どんどん下がって行ってて(自分だけじゃなく世の中のみんながそういう傾向にあると思う)、携帯電話を使う時間がどんどん長くなってきてる。過去の写真を見るのにいちいちパソコンを開かないといけないのはしんどい。手元にある携帯でいつでも過去の写真が見られる Google Photos の方が圧倒的に優れていると感じた。 Apple TV にミラーリングすれば家族全員で写真を見ることもできる。 Photos.app の iCloud フォトストリームではお金を払わない限り 1000 枚までしか共有されないので Apple TV 単体で写真を見ると最近の写真しか閲覧できない。 Google Photos を知る前はそれでも楽しかったんだけど、平日の夜の何気ないタイミングで携帯を眺めていて 2 年前の旅行の写真が目に入り、テレビに映して旅行の思い出に浸る会を緊急開催みたいなことが Google Photos では可能になる。これは本当にすごいし、写真を撮りたいと思うようになった。閲覧・整理環境に課題があると「どうせ撮っても見ないし…」という気持ちになる。

Apple はなぜ先にこのような体験をユーザーに提供できなかったんだろう。ユーザーの画像を預かる、という点では iCloud で Google よりも先行していたはずなのに。

Apple に期待すること

総じて Google Photos が勝っていると思う。一度 Google Photos を使ってしまうと、 Apple の Photos.app で写真を見るという気持ちにはならないだろう。

Apple Photos.app はローカルで動くソフトウェアの強みを活かして、写真の編集方面で強くなって欲しい。 Google Photos の写真編集機能は貧弱だし、一度アップロードした写真を手元にダウンロードして編集して再度アップロードするのもだるい。何も Photos.app 本体の編集機能を強力にしろと言ってるわけではない。画像を外部の編集ソフトと受け渡しできるだけで良い( iPhoto から Photos.app になったタイミングで外部のソフトを編集・現像ソフトに指定できなくなったり、ドラッグアンドドロップで画像を書き出せなくなったが、そっち方面の機能を充実させて欲しかった)。

画像認識だとか機械学習みたいなのは、ユーザー自身の Mac の中でちびちびやってもサーバーサイドでいっぱいコンピューターを並べて並列処理でだーっと実行してるだろう Google には勝てない。そういうので Google とやりあうのは良策ではない。

そして欲を言えば Aperture の開発を継続して欲しかった。 Lightroom のために Adobe に毎年 12000 円払える人は限られている。お金以外にも Apple が作ってる現像ソフトという安心感が Aperture にはあったんだよなぁ。 Adobe のソフトのジャバジャバした感じは好きになれない。