portal shit!

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

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

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

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

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

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

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

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

この本はインターネット企業のビジネスモデルについて書かれた本だが、経済学とイノベーションの歴史にも触れつつ、なぜプラットフォームが支配的になってくるのかが書かれている。 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 はどれも使いづらい。

• Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（中編）
• Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（後編）

この記事は登山 Advent Calendar 2018 22 日目の記事ですが遅れて書いています。大変申し訳ありません。

---

今年の山行

年初、成人式の三連休で家族で二丈岳に登った。登り始めが午後だったので下りは真っ暗闇の中を下ることになりめっちゃ嫁さんから怒られた。もう多分家族では二丈岳には行かない。

四月の頭に息子殿と二人で十坊山に登った。お手軽に登れて二丈岳と同じような、パノラマ感では二丈岳を上回る眺望が得られてお得だと思った。今年はこの後も二回、十坊山に登った。

家の近所の山を息子殿と二人で登った。バーナーを持っていき忘れてカップラーメンとクッカーを持ってきていたのに食べられなかった。おにぎりとスーパーの惣菜チキンだけ食べた。初めて高地山に登って景色の良さと低山ながら整備されたルートの歩きやすさに感動した。

家族 3 人で十坊山に登った。福吉方面から登ったので結構距離がありまた嫁さんに文句を言われたので十坊山にももう家族で登ることはないと思う。

社内登山で阿蘇山に行った。地元ながら登山をしたことはなかった。ミヤマキリシマが目的だったが天候が良くなく、雲の切れ間からチラッとしか見ることができなかった。中岳には登頂したが高岳には登頂できなかった。鹿らしき野生生物の白骨化死体などがあり Into The Wild 感あった。また行きたい。

社内登山で久住に行った。去年の平治岳以来。炎天下のなか 10km 以上歩いてくたびれた。また自分は社内の強い人たちにくらべたら雑魚だなということが思い知らされてよかった。

山の日に近所の低山に登った。夕方から登り始めたので帰りは暗くなってしまって結構危なかった。鐘撞山は良い山なので毎月登りたい。

盆に実家に帰ったときに両親も含めて杵島岳に登った。阿蘇はかなり上の方まで車で行けるので 1000m 以上の山でも低山感覚で登ることができて便利。登山の格好じゃなくても道も整備されているのでハイキング感覚で楽しめる。

北アルプス遠征で白馬岳に行った。素晴らしすぎた。詳しくはこちら。

午前中仕事をして昼からちょいとチームビルディング登山で二丈岳まで。このとき調子こいた発言をしてしまって同僚殿に縦走を焚きつけられ翌月敢行することに。

自分史上、最高につらい登山だった。 20km 、約 10 時間を一人で黙々と歩いた。後半はアルプスで痛めた膝が痛み始め非常にしんどかったが、今になって思い返すと結構いい思い出でまた行きたいと思ってしまうので怖い。こちらも別に記事があります。

会社のイベントで宝満山へ行った。良い山だった。英彦山といい、修験の山は人を惹きつける何かがある。

---

登山、最初はおっかなびっくりだったがやっていくうちにどんどん楽しくなってきた。一人でサクッと登れるところがとても良い。登っているときに自分と向き合えるような感覚になるところも良い。一人で体を動かせるものといえばジョギングがあるが、悩みごとや嫌なことを忘れるのには向いているものの、深く考えごとをしたりということに向かないと思う。登山は歩きながらいろんなことに考えを巡らせることが出来る。ゲーテはかつてハイデルベルクの街を歩いて思索にふけったというが、歩くことには考えることを助ける側面があると思う。というわけで逃げられない悩み事や考えごとがある人は登山をお勧めします。一人で黙々と縦走しましょう。

YAMAP に入ってからは 1 年半になる。今年はなんとエンジニアからプロダクトマネージャーにジョブチェンジすることになってしまった。登山経験はしょぼいし体力なくてダメダメなんだけど、これまでいくつものサービス開発で失敗したり成功してきた経験を活かして、皆さんに楽しんで使ってもらえるプロダクトをお届けできるように全力を尽くしていく所存です。

この記事は CircleCI Advent Calendar 2018 19 日目の記事ですが間に合わず一日遅れて書いております。すんません 🙇🏻

CircleCI を使った Rails アプリのデプロイフローみたいな話を書こうかなと思ったのですが、すでに他の方が書いてる内容とかぶりそうだし、自分自身ブログに過去何回も書いた話なんで今回はエモ方面の話を書くことにします。技術的な情報はないのでそっち方面を期待している方はすんません。

---

いまの職場で働き始めて 1 年半なんですが、当初は CI はなく、テストコードもありませんでした。いまはそこで当たり前のように CI が回り、テストのカバレッジもまぁまぁ高く、デプロイは CircleCI 経由でじゃんじゃん行われるような状況となっております。新しく会社に入った人も GitHub の Organization に入ってもらえたらその瞬間から deploy 実行できます。具体的な話は昔書いてますのでよかったらご覧下さい。

8 年くらい前の自分はどうやったら CI だとか自動デプロイだとかできるようになるのか皆目見当が付きませんでした。いま 8 年前の自分と同じような状況にいる人（回りにテストを書く習慣を持つ人がいない人、 CI 動かすためにどうすればよいかわからない人）に何か言いたいと思い筆をとりました。

まずは何はなくとも頑張って一つテストケースを書いてみましょう。最初からカバレッジ 100% とか目指さなくてもよいです。どれか一つ、テストが書きやすそうなコードを見つけてテストを書き、ローカルで実行してテストがパスするのを確認しましょう。テストファーストとかも最初から目指さなくてよいです。

手元でテストが通ることを確認したら、 CI 環境でもテストを実行できるようにしましょう。

昔は Jenkins しか選択肢がなく、 Jenkins が動く環境をセットアップする（サーバーを調達する、 VPS を借りてもらう、などなど）に社内調整が必要でしたが、 CircleCI ならプライベートリポジトリでも 1 プロセスなら無料で使えますので社内調整が非常に楽です（外部にコード出してはダメな職場だと厳しいですね…）。

最初にプロジェクトを追加して言語を選ぶと設定ファイルが自動生成されるので、それをコピペして .circleci/config.yml として保存し、リポジトリにコミットするだけでとりあえずビルドが実行されるようになります。

昔は難しかった CI 環境構築のうち、お金の問題、設定の難しさの問題を CircleCI は解決してくれます。あとはあなたが頑張るだけです。

CircleCI ならビルド終了ごとに結果を Slack などチャットシステムに通知させることができます。まずはテストケースが一つでもよいのでリポジトリへの push をトリガーにビルドが実行されたら結果を Slack に通知してみましょう。

リポジトリに GitHub を使っているなら Pull Request にビルド結果が表示されるようになるはずです。

これらで「なんかようわからんけどやっとる感」を出していきましょう。

そして過去のコードのことは一旦無視して、あなたが新しく追加する部分に関してはテストコードをセットで書くようにしていきましょう。あなたがコードレビューを依頼するときには必ずテストがグリーンな状態で依頼するようにするのです。

そうこうしているうちに他の人が出した Pull Request でテストが失敗するケースが発生します。 Slack の #circleci チャンネルに赤色の Failure 通知が届き社内が騒然とするかもしれません。しかしこれはチャンスです。

「よかった、これでバグが未然に防げましたね」

あなたのこの一言でテストや CI がもたらす開発効率の向上がチームの皆さんに伝わるはずです。こうなったらもう一押しです。あなたがテストと CI の伝道師になりましょう。テストを書くことが当たり前になってきたら、 CircleCI からの deploy や定型処理を CircleCI でやらせるような使い方にチャレンジしていきましょう。どんどん周囲を巻き込んで、 CI 文化を定着させていって下さい。

何はともあれ、最初は一つのテストコードを書くことから始まります。変更に強いコードを書いてじゃんじゃん deploy し、じゃんじゃん Money making していきましょう🤑

この記事は Coffee Advent Calendar 2018 15 日目の記事ですが、間に合わなかったので 16 日に書いてます。すみません。

---

コーヒー好きなんだけど元同僚のウルトラ富裕層 @t32k さんのようにサ〜ドウェ〜ヴなコーヒー豆屋に行って 100g で 1200 円もする豆を節分の炒り豆感覚で買えるような財力はないので長崎で行ったコーヒー屋について書きます。

長崎、いろんなコーヒー屋がある。ただサ〜ドウェ〜ヴの店なんかではなくて昭和レトロな喫茶店、いわゆる純喫茶が多い。

前も書いたことあるけど長崎では囁き坂が一番好きなコーヒー屋で、長崎に帰省するたびに必ず寄ってる。

囁き坂のマスターはコーヒーのことも長崎のこともどんだけでも話題の引き出しがあってとても楽しい（もちろんコーヒーもおいしい）。義母が亡くなって長崎には帰るべきところがなくなってしまったが、いまでは囁き坂が帰省先のようになってる。

豆は囁き坂で買うのだけど、最近は囁き坂以外の店にも行くようになって 2018 年はいろんな店でコーヒー飲んだ。

新大工町 喫茶ミレー

まずはミレー。店のロゴはミレーの作品『種まく人』から作られており（岩波書店のシンボルマークも同じ）、文化の香りがする。

内装は本郷の喫茶店にありそうなアカデミックな雰囲気を漂わせる昭和レトロ内装で、ここで岩波文庫を読みながらコーヒーを飲めば昭和のインテリゲンチャを気取ることができる。

とはいえお店は気難しい親父がやっているわけではなく、人柄の良さそうなおばあさん数人でやっていて非常に落ち着く。店内はとても広く、奥には貸し会議室もあって近所の主婦の皆さんが集まって井戸端会議をやってたりする。

ミレーではモーニングを食べるのがよい。サイフォンでいれたコーヒーにトースト、ハム、サラダが付いてくる。それで 500 円。コーヒーも美味しい。 11 時まで注文することができる。

鍛冶屋町 富士男

富士男は戦後間もない時期からあって文化人もコーヒーを飲みに来てる。遠藤周作はキリスト教関係の本を書くためにしばしは長崎に滞在していたようで、そのとき富士男に来ていたらしい。いまでは油屋町のツル茶ん（トルコライスが有名）と双璧を成すインスタグラムスポットとなっている。ベレー帽をかぶったインスタグラム女子と長崎の地元のおっさんが背合わせに座っててかなり面白スポットとなっている。

なお富士男と隣り合って営業していた銀嶺はいまは立体駐車場となっているが、長崎歴史文化博物館内にレプリカ店舗ができている。そこではトルコライスが食べられる。

新大工町 喫茶富士

上述の富士男は一時期かなり業績を伸ばし、長崎市内に複数店舗構えていたようである。ただチェーンというよりは暖簾分けだったのかもしれない。現在では富士男から「男」を取った『富士』という名前の店が新大工町にある（純喫茶コレクション 長崎・大工町・純喫茶　冨士）。

他にもまだまだ長崎には趣深い純喫茶があるのでまた帰省したときに行ってみたい。カフェチェーンやサ〜ドウェ〜ヴ勢に喫茶市場を蹂躙された東京や福岡ではもう姿を見かけることがなくなったレトロな喫茶店がまだまだ生き残ってる。味のある写真が撮れる。平成生まれのインスタグラマーや韓国人旅行者なんかには負けてられない。何がインスタグラムだこっちは 10 年 Flickr Pro ユーザーやってんだ舐めんな。

北アルプスから帰ってきたあと「二丈岳に行ったけど物足りなかった」とぼやいていたところ同僚に福吉駅から十坊山、浮嶽、女岳、二丈岳を経て深江駅までの四座縦走をやってのけられ、これに触発されて一ヶ月ほど前に計画したものの雨天や家用でなかなか実現できなかったやつをやった。開始地点を浜崎駅に移して浜玉側からスタートするルートは YAMAP で検索しても活動日記が投稿されておらず四座踏破できたら達成感があるだろうと思ったが、スタートが遅れたこと（朝から風呂で Netflix 見てた。 House of Cards が面白すぎるのが悪い）、途中道迷いで小一時間ほどロストしたことにより最後の二丈岳は断念して十坊山、浮嶽、女岳の三座のみとなった。とはいえ浮嶽も女岳も未踏だったので行けて良かった。天気が最高だったこと、初めて 20km を超える縦走（しかも一人）をやったこと、浮嶽で話した唐津のおじさん（若い頃には北アルプスを踏破し久住も 100 回以上登っておられるとのこと）から浮嶽の絶景スポットや初日の出情報を教えてもらい実りの多い秋の糸島縦走だった。

計画

浜玉側から十坊山に登るのはかつて子連れでやろうとして挫折していて、そのリベンジをかねて四座縦走してみることにした。 9 月の初旬に計画したものの天気が悪かったり家用があったりでなかなか実行に移せず 10 月になってしまった。

出発

週の頭に今週末行けたらいいなとぼんやりと思って天気予報をにらんでいたところ、木曜くらいから曇りのち晴れが晴れに変わり、これは行くしかないと、金曜の昼に会社近くのスーパーでカップラーメンや行動食を買い込む。いつもダラダラ居残ってしまうが、早めに仕事を切り上げ帰宅。朝目が覚めると 4 時半で、これは行けそうだと思ったが、前夜風呂に入らずに寝てしまったため風呂につかってうっかり Netflix で House of Cards を見始めたところ面白すぎて 6 時半を過ぎた頃にようやく我に返る。計画では始発列車で移動する予定だったのにこれではもう間に合わない。風呂から上がり、ささっと準備を整えて最寄り駅まで向かう。

朝から風呂に浸かりながら Netflix を見ていたため出遅れましたがこれをしに行ってきます。月曜になってもツイートしてなかったら遺骸回収よろしくお願いします。https://t.co/CLHUhojZZD pic.twitter.com/YNxX9f5fq4

— morygonzalez (@morygonzalez) October 12, 2018

格好

長ズボンにするか短パンにするか迷ったが、まぁ大丈夫だろうということで普段もはいている山と道の短パンをはいていくことに。上は icebreaker のメリノウール T シャツにしたが、朝はやはりまだ寒く YATTEIKI FM のパーカーを羽織る。靴はいつもの Montrail 。つま先のソールが剥がれ始めているのでそろそろ買い替え時かもしれない💸。アルプス遠征の反省を踏まえ荷物は少なめにしたつもりだがやはり一眼レフがかさばる。使わないときはカメラバッグはリュックに収納し、なるべく身軽な状態にする。今回初めてサコッシュを山に持っていったがやはり便利だった。自撮り棒、モバイルバッテリー、 Kindle 、行動食を入れて歩いた。

移動

最寄り駅のセブンイレブンでおにぎりを二つとコーヒーを買う。筑肥線に乗り浜崎へと向かう。平日の朝はたくさんの人が電車を待つ駅だが、土曜の朝だと人影はまばら。筑前前原駅で唐津行きに乗り換え、浜崎まで 50 分弱で到着した。

十坊山へ

浜崎駅から登山口のある谷口集落まで歩く。 YAMAP のルートではだいぶ大回りするように書かれているが、あちらのルートは農道で農業用車両の通行が多いので今回通っている集落を抜けるルートがおススメ。

コースマップのルートに合流し歩き続けるが、分岐に遭遇する。駅から止まらずに歩いていたのでリュックを下ろし水を飲んでおにぎりを一つ食べながら考える。ずっと舗装路を歩いてきたので山道らしい舗装されていない方に行ってみることにした。

しばらく行くといきなり選択を誤ったかと思えるような光景に出くわす。水害の影響か、道が崩落している。注意しながら踏み外さないように通り抜けて先に進む。

再び舗装路になるが、しばらく行くとどうも様子がおかしい。やたら蜘蛛の巣が多くなり、雑草が背高く生い茂っている。道の荒れ具合が人通りがないことを物語っている。短パンで来たことを少し後悔する。

毒々しい色をした大きな蜘蛛の巣をくぐりながら進んだところでふと YAMAP を開くとルートから外れていることに気がつく。地図を見ると強引に先に進めばルートに合流しないこともなさそう。戻るべきか進むべきか。しばし迷ったがヤマケイ新書の遭難本に書いてあったことを思い出し、来た道を引き返すことにする。

人間、これまで登ってきた道を戻ることには抵抗があるのだろう、戻る前は随分進んでしまっていたように感じたが、いざ戻ってみるとルートを外れた地点まではすぐだった。しかし肝心の分岐しているはずの正規ルートが見つからない。なんと、先ほど見かけた崩落地点で分岐しており、脇の方にある舗装路ではない野道の方が正解だったのだ。これは分かりにくい。

気を取り直し、野道の方を進む。野道だが人の通りがあるのか先ほどの道のように蜘蛛の巣地獄ではなく、草の背丈も程々で非常に歩きやすい。しばらく進むと視界がひらけ、湿地のような場所に出た。また道が舗装路になり快調に歩いた。

十坊山には川はないかと思っていたが、今回歩いた道は途中で沢の横を通り川の音を聞くことができた。この道は林道のようで、あたりはぎっしりと杉が植えられている。杉に覆い尽くされ昼間でも真っ暗になっている場所があり、阿蘇山の登山道を思い出す。蜘蛛が三つに並んで巣を作っていてタバコの煙をプカプカさせているようで面白かったので写真に撮った。

暗いあたりを過ぎると明るくなる。東屋と芝生が見えたので公園でもあるのかと思ったがゴルフ場の敷地で外からは入れなくなっている。

しばらく進んで漸く十坊山の南登山口に到着した。ここからやっと山登りらしい道になる。十坊山にこちらから登る人は少ないようで登山道は荒れている。杉の葉が大量に落ちておりカラフルな絨毯のようだった。

森の中を淡々と進むと程なく白木峠からのルートと合流した。ここからかなり角度が急な坂を登る。あっという間に山頂に着く。時刻は 11 時半過ぎで、山頂には家族連れや女性二人グループなど先客がいた。当初の予定では浮嶽で昼食を取る予定だったが、すでに昼近くだったのでここで昼食をとる。山頂ではすすきが穂を垂れ始めており秋の気配が強まっていた。坊主岩に登って著者近影をキメてそそくさと退散し浮嶽へ向かう。

2時間遅れで十坊山に着いた著者近影です。 pic.twitter.com/8PviufppQO

— morygonzalez (@morygonzalez) October 13, 2018

汚職事です。 pic.twitter.com/uJD2auJWxb

— morygonzalez (@morygonzalez) October 13, 2018

禿頭が坊主岩に載ってる様子です。 #様子ですJP pic.twitter.com/YPtTwUZidl

— morygonzalez (@morygonzalez) October 13, 2018

浮嶽へ

十坊山から白木峠の方に下る。下りには何組かの小さい子ども連れの家族とすれ違った。下りはすぐだった。白木峠から浮嶽への登り口は十坊山の登り口と道路を挟んで向かい側にある。土留めコンクリートに小さく看板があるだけなので少しわかりにくい。

白木峠から浮嶽へのルートは単調だった。ゴルフ場の脇を通るルートで、時々ゴルフに興じている人たちの絶叫や叫び声が聞こえて変な気持ちになる。一旦 360m まで下って 800m まで登るので 400m 超を駆け上がるが、山頂まではずっと同じような道が続き疲労感が募る。森の中で景色に変化がないので写真を撮ることもなく、一眼レフを胸にくくりつけてるのがアホらしくなってきてカメラバッグに収納しカメラバッグごとリュックサックの中に納めた。

浮嶽では数人とすれ違ったが、挨拶をしたのに返してもらえなかった。聞こえなかったのかなと思って思わず二度挨拶しそうになった。糸島の山は挨拶しない主義の登山者が多いのかもしれない。一人の中高年男性ほど挨拶を返してくれない傾向にあると思う。

そうこうしている間に浮嶽に着いた。浮嶽山頂は立派な杉の木が植えられており、神社もあって厳かな雰囲気がある。写真を撮り、リュックサックを下ろして休憩していると長靴に作業着で軽装の地元の人とおぼしき人がやってきて神社にお参りしていた。こんにちはと挨拶すると、縦走かと聞かれてしばし話し込んだ。この方は唐津の農家で、若い頃北アルプスを踏破し、久住にも 100 回以上登っておられるとのことだった。いまは農業が忙しく遠出ができないためこうして近所の浮嶽に仕事の合間に登りに来ているのだそう。自分が今夏北アルプスに行った話をすると話が弾み、浮嶽の絶景スポットや初日の出が見えるスポットを教えてもらった。

二座目、浮嶽での著者近影です。 pic.twitter.com/MZMgFW6MHD

— morygonzalez (@morygonzalez) October 13, 2018

荒谷峠までおじさんの車で乗せて行こうかと言われたが、せっかくなので歩こうと思って辞退し、歩いて荒谷峠へ向かった。荒谷峠へは山道と舗装路の二つがあるが、併走しているので最終的には同じところに辿り着く。自分はコースタイムが短かった舗装路の方を選んだ。歩きながら見えた浮嶽の姿は非常に立派だった。唐津のおじさんに教えてもらった絶景ポイントも最高で、標高が高いため十坊山よりも二丈岳よりも景色が良いかもしれない。また来たいと思った。行動食のトレイルミックスを食べながら優雅に舗装路を下った。

女岳へ

荒谷峠に着いて、女岳に登るかスキップして真名子まで行き二丈岳に登るか迷った。すでにこのとき時間は 15 時半を回っており、四座踏破は無理だろうなと思っていた。女岳は眺望もないと聞いていたし、登る価値がないかもしれないと思っていたが、二丈岳には何度も登ったことがあるしそもそも真名子まで女岳を経由してもしなくても所要時間は変わらない、それなら女岳に登って二丈岳をスキップし、深江に降りる予定を大入に降りようと考えを改めた。真名子からゆらりんこ橋へのルートは過去に通ったことがあるし、日が落ちてしまっても何とかなるだろうと考えた。

女岳にはすぐに着いた。登山道は杉林ではなく雑木林で鬱蒼感が多少ましで好きな雰囲気だった。 16 時前に着いたが山頂は誰もおらず、温度計を見ると気温は 10 ℃だった。立ち止まると体が冷える。ナイロンパーカーを羽織って寒さを凌ぐ。数枚写真を撮って足早に下山した。

三座目、女岳となります。四座目の二丈岳は時間が遅く遭難の可能性があるため断念します。 pic.twitter.com/mSAuqdu77X

— morygonzalez (@morygonzalez) October 13, 2018

もう体力が尽きかけていたのか、女岳ではリュックサックから一眼レフを取り出して写真を撮る気力が沸かなかった。眺望が悪いときいていたものの、自撮り棒を使って高い位置から海の写真を撮ることができた。

真名子方向におり始めてすぐにとても大きな石を見た。白馬岳ルートの天狗が原で見たやつよりも大きく感じられた。カメラで写真を撮るべきだろうなぁとは思ったが、疲労と寒さが勝り先を急いだ。

真名子へ

女岳の下りから北アルプス遠征で痛めた左膝が痛み始めた。普段の生活では痛まないが、山登りの下りで痛むようだった。どうもこれは持病になってしまったみたいだ。自分はもう死ぬまでこの痛みと付き合っていかなければならないのかもしれない。もうアルプスのような高い山にも登れないのかも知れないと思うと悲しい気持ちになった。

真名子への下りでは誰とも出会わなかった。途中、車道に出ることが何度かあって、そのとき脇を車が通り過ぎていった。キャンプ場に向かう人やアウトドアテーマパークから帰る人たちだった。どうせ二丈岳には登らないのだからこのまま車で帰りたい、親切な人が乗せてくれないかななどと思いながらも歯を食いしばって歩いた。このあたりでは疲れてほとんど写真を撮っていない。

だいぶ下って舗装路に出て、見慣れた真名子の研修棟のところに着いた。二丈岳への登山口はスルーして賀茂神社に向かう。飲み水が少なくなっていたので水場で補給させてもらう。

ゆらりんこ橋へは慣れた道だったが左膝が痛み、ほとんど一人で絶叫しながら降りて行った。

ゆらりんこ橋から大入へ

ゆらりんこ橋までたどり着いたものの最寄駅の大入駅まで 3km 以上歩かなければならず悲壮感漂う著者近影です。 pic.twitter.com/xzbcv0Ti07

— morygonzalez (@morygonzalez) October 13, 2018

何とか日が残っているうちにゆらりんこ橋に着いた。ただここからまだ大入まで 4km 弱ある。最後の力を振り絞って歩く。 YAMAP の活動距離を見ると 17km ほどになっていた。こんなに歩いたのは初めてで、大入まで行くと 20km を超えるだろうと思った。

大入駅の前にコンビニがあったはずだからコンビニでビールを買って飲むことを楽しみに歩き続けた。車ではなく電車で来て縦走しているのでそういうことができる。

大入駅手前まで来たところで夕焼けがとても綺麗だったので再び一眼レフを取り出して何枚か写真を撮った。パタゴニアのロゴみたいな色の空が撮れた。

何とか大入駅に辿り着いたが、駅前のコンビニは閉店してしまっておりビールを買うという夢は打ち砕かれた。荷物を軽くしようと賀茂神社でくんだ水は途中で捨ててしまっていたので飲むものがなくどっと疲れが出た。加えて電車を待つホームを間違えてしまい、下りホームにいたところを親切な人に「そっち上り電車来ませんよ」と教えてもらって慌てて階段を駆け上がって反対側に移動し、何とか帰りの電車に載ることができた。筑肥線の筑前前原以西は電車の本数が減るので、ホームを間違っていることに気づかずこれを逃していたら帰宅が一時間くらい遅れていたかもしれない。最後に散々な思いをしながら放心状態で自宅最寄り駅まで電車に揺られ帰り着くことができた。

駅に着いたら駅前のセブンイレブンでビールを買って帰りの電車の中で白眼視されながら酒盛りしまくろうと思い余った飲み水を捨てて駅までたどり着いたのに駅前のセブンイレブンは潰れておりビールはおろか一切の液体を摂取することが出来ず絶望に打ちひしがれている著者近影です。 pic.twitter.com/OLGMIljBzc

— morygonzalez (@morygonzalez) October 13, 2018

所感

初めて一人で縦走をし、 20km 以上も歩いた。低山だと侮っていた糸島の山も立て続けに三座登ると足がぱんぱんになり、非常に達成感があった。

一方でやはりまだまだ自分は初心者で、ゆっくり目に引いてある YAMAP のコースタイムよりも遅いペースでしか歩けないことがよく分かった。出発が 2 時間近く遅れたものの、飛ばせばそのうち挽回できて二丈岳にも回れるだろうと思っていたが全くそんなことはなく、四座目の二丈岳を断念しなければならないのは残念だった。なかなか一人で一日使って登山できることはないので貴重な機会を逃してしまったのもしれない。

もしまた実行できるチャンスがあれば、深江側から二丈岳、女岳、浮嶽、十坊山を縦走して浜玉側に降りるやつをやってみたい。そのときは是非ビールを買って帰りの筑肥線で海を見ながら飲みたい。

職業プログラマーになって 8 年の間に随分とジョブホッピングを繰り返してきたが、どこの会社でも評価が良くない。上司（非技術者であったことがほとんど）からは全く評価されない。なので在職時に昇給したということはほぼない。ペパボ時代にエンジニア評価制度が導入されてシニアエンジニア¹になったときにががっと給料が上がったことはあったけど、あれは直属の上司ではなく技術責任者から評価されるという仕組みだったのでイレギュラーケースといえると思う。その後は転職時に増えた以外では全然給料が増えたことはない。据え置きが続いたりむしろ下がったことすらある。

しかし一度退職すると、同じチームの同僚や隣のチームの偉い人とかから良く思われていたことが判明することが多い。戻ってきてほしいとか、いなくなって困ってるとか。当然社交辞令の部分もあると思うが、全く役に立たないクソ野郎だったらそんなことを社交辞令で言われることもないはずなんで、ある程度は評価されていたといえるんだと思う。

なぜ在職中に上司から評価されないのか考えると、当時の上司がやってほしいと思ってることをやらないからだと思う。自分はチーム全体で効率が良くなるようにツールをあれこれしたり bot でガチャガチャやったりとか（ Developer Productivity の向上）が好きなんで、自分の動きは会社がやりたいこと、上司がやらせたいこと（売り上げが増える何か、アプリのダウンロード数が増える何か）に直接寄与していないよう見える。

前職や現職で新しくプロジェクトが動き始めるときに何は無くともユニットテストを実行できる仕組みと Docker や CI 環境の構築をガガっとやってて、誰もがテスト書いて Pull Request 出して CI パスしてからレビュー依頼してデプロイも確認環境には自動でじゃんじゃんデプロイされて（ Continuous Delivery ）、誰も（新人やプログラマーでない人含む）が簡単に本番にもデプロイできる仕組みを作ったという自負がある。こういうのは直接売り上げは増やさないけど開発サイクルを早めたりチームの生産性を高めたりしていると思うが、1秒でも早く依頼したソフトウェアを納品してほしい人からはなんか勝手なことをやってるように見えるし、それが当たり前になると特にありがたみを感じられない種類のものなので評価の対象となりにくい。問題が起こって仕組みが使えなくなったときに初めてありがたみがわかる。なので在職中には評価されない。少なくとも上司からは。

加えて、自分には理想主義的なところがあって、訳の分からない指示が来たときに「そもそもそれいまやることですか」とか「会社がやるべきなのは違うことじゃないですか」と言ってしまう。そもそも論を言うので、ミーティングに参加していても荒れたり脱線してしまったりして「こいつ今これ言うのかよ…」みたいな冷たい視線を浴びることがよくある。場をかき乱す発言をするので「こいつはわかっていない」という烙印を押されてしまう。

評価が良くないと、長く同じ会社に留まり続けるメリットが得られず転職を繰り返してしまう。正直なところ転職は面接を受けに行ったり、給与交渉をしたり、退職を打診したり、仲の良い同僚と別れたり、有給がリセットされたり、人間関係を作り直したり、健康診断の履歴が失われたり、ローンを組むとき不利になったりでしんどいことが多い。できる限り同じ職場で働き続けることがハッピーだろうなぁとは思うんだけど、会社から評価されないのは不満が溜まるし、自分のような人間（間接的にだが結構会社の役に立ってる）が評価されないのはその組織にとっても良くないと思えて転職するという選択をしてしまう。良くない。会社が自分の評価を良くせざるを得ない状況に持ち込めるくらいに腕力（プログラミング能力）や胆力（度胸）をつけなければならないんだろうなぁとは思ってる。

※ なおこの記事は退職エントリーではありません。

ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。

Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。

リーダーが Sidekiq に反対する理由は以下だった。

1. キューに可視性タイムアウトの概念がない（ SQS にはある）
   ワーカーがキューメッセッージを取得したあと何らかの事情で一定時間内に処理を終えられなかった（ワーカーが突然死した場合など）未処理のジョブが再度ワーカーから見えるようになるので、ジョブの実行が保証される
2. Redis が飛んだらジョブをロストする
   ElastiCache を使っているが、たしかに稀にメンテ祭などでフェイルオーバーが発生するなど困ることがあった
3. Ruby 以外の言語から使えない
   Redis に書き込まれる情報は Sidekiq 専用フォーマットなので他の言語からも使う場合は読み取り君を作る必要がある

一方で自分が SQS に反対した理由は以下。

1. 依存関係をソースコードに落とし込むことができない
   Sidekiq を使う場合は Redis と Sidekiq worker が動く Docker コンテナの情報を docker-compose.yml に書くことで依存関係を（バージョンまで含めて）宣言的に記述できる。 SQS の場合はそうはいかない。
2. アプリケーションが AWS にロックインされる

   運用環境はすでにロックインされているが、アプリケーションが SQS という AWS のプロプライエタリな技術に依存すると、ソースコードが AWS と密結合になり他の IaaS に移行するときの障壁となる
3. ローカル開発で利用することができない

   実際にローカル環境で非同期処理の検証不足が原因で機能の実装が漏れたまま production に deploy されたことが何度かあった。 localstack という AWS の機能をローカルに再現する技術はあるが、 SQS はオープンソースではないので完全に再現されるわけではない。

このような議論を経て、結局ジョブキューイングシステムには RabbitMQ を使うことになった。 RabbitMQ はリーダーが求める三つの要件を満たすし、オープンソースなので自分が SQS に反対する理由にも抵触しない。開発環境では Docker で RabbitMQ を動かし、 production では AWS にフルマネージドの RabbitMQ サービスはないので（ ActiveMQ のマネージドサービス、 Amazon MQ というのはある）、 RabbitMQ の運用に特化した SaaS を利用することにした。

SQS に対する考えを整理する上で The Twelve-Factor App を改めて読んだが非常に参考になった。特に以下の三つの部分について、 SQS は Twelve-Factor App に反しており使うべきではないと思った。

II. 依存関係

アプリケーションが将来に渡って実行され得るすべてのシステムに存在するかどうか、あるいは将来のシステムでこのアプリケーションと互換性のあるバージョンが見つかるかどうかについては何の保証もない。アプリケーションがシステムツールを必要とするならば、そのツールをアプリケーションに組み込むべきである。

IV. バックエンドサービス

Twelve-Factor Appのコードは、ローカルサービスとサードパーティサービスを区別しない。アプリケーションにとっては、どちらもアタッチされたリソースであり、設定に格納されたURLやその他のロケーター、認証情報でアクセスする。Twelve-Factor Appのデプロイは、アプリケーションのコードに変更を加えることなく、ローカルで管理されるMySQLデータベースをサードパーティに管理されるサービス（Amazon RDSなど）に切り替えることができるべきである。同様に、ローカルのSMTPサーバーも、コードを変更することなくサードパーティのSMTPサービス（Postmarkなど）に切り替えることができるべきである。どちらの場合も、変更が必要なのは設定の中のリソースハンドルのみである。

X. 開発/本番一致

Twelve-Factor Appでは、継続的デプロイしやすいよう開発環境と本番環境のギャップを小さく保つ。

たとえ理論的にはアダプターがバックエンドサービスの違いをすべて抽象化してくれるとしても、 Twelve-Factorの開発者は、開発と本番の間で異なるバックエンドサービスを使いたくなる衝動に抵抗する。 バックエンドサービスの違いは、わずかな非互換性が顕在化し、開発環境やステージング環境では正常に動作してテストも通過するコードが本番環境でエラーを起こす事態を招くことを意味する。この種のエラーは継続的デプロイを妨げる摩擦を生む。この摩擦とそれに伴って継続的デプロイが妨げられることのコストは、アプリケーションのライフサイクルに渡ってトータルで考えると非常に高くつく。

AWS の技術がどんなに優れていたとしても、自分はオープンソースではない AWS 独自のプロプライエタリな技術に依存してアプリケーションを作りたい訳ではない。運用の煩雑さ・手間から解放されたい、スケーラビリティを提供してほしい、というのが AWS に期待するところだ。 SQS はアプリケーションのソースコードの中に入り込んでくる。開発環境ではローカルの PostgreSQL 、 production では RDS の PostgreSQL インスタンスに接続先を変えるだけ、という風にプラガブルに切り替えることができない。開発効率性や移行可能性（ほかの IaaS に移ることができるか）を考えると、運用の効率性に特化して AWS を使いたいと思った。 Redshift とか DynamoDB とか Kinesis とか AWS の技術でしか実現できないことをやりたいときに手を出すのは悪くないと思うけど、AWS が提供するものなら何でも素晴らしいからすぐに飛びつくというのは間違っていると思う。

ちなみに CircleCI との距離の取り方はうまくいってると思う。いま deploy を CircleCI から行なっているが、 CircleCI が止まると deploy できなくなるのは困るので deploy 処理自体はシェルスクリプト化してある（👺 Hubot で Slack から AWS ECS にデプロイ）。 CircleCI が死んだら手元から deploy コマンドを実行するだけでよい。 CircleCI にやってもらっているのは、人間が手でも実行できることの自動化の部分だけだ。 CircleCI というサービスが終了したとしても恐らく簡単にほかのサービスに乗り換えられる。

まとめると、 IaaS / SaaS / PaaS を使う場合は以下に気をつけるべきだと思う。

• ソースコードの中に特定のプラットフォームのプロプライエタリな技術に依存した部分が出てこないか
• アプリケーションをローカル環境でも動かすことができるか
• 運用やスケーラビリティに関してのみ依存するようにする
• 人間が手でもできることの自動化のみに利用する