portal shit!

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

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

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

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

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

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

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

Twitter で DHH が共有していた記事が面白かったので著者の許可を得て翻訳します。

"If you don't hire juniors, you don't deserve seniors", spot on! We've had phenomenal success hiring junior developers at Basecamp. @jasonfried first tech hire was particularly junior at the time 😂https://t.co/QczMtsou4J

— DHH (@dhh) September 21, 2018

ジュニアを採用しない連中はシニアに値しない、というもの。

※なお本文中で「エンジニア」はソフトウェアエンジニアのことを指して使っています。

---

とても成功した企業がとてつもない愚かな決定をした話をさせてほしい。

我々はジュニアなエンジニアやインターンは雇わないことにしてるんだ…子犬を飼わなければ糞の片付けをせずに済む。

— Netflix

社畜連中が子犬をよくないものと見なしていること、またみんながそれを受け入れていることに唖然とした。子犬とは地球上で最もピュアな存在だ。文字通り遊びの時間とふわふわの毛でできている。孤独なこの世界の救いだ。話が脱線してしまった。

多くの企業が "経験者のみ" という採用戦略をとっている。理由を聞かれると以下のように答える。

• ジュニアエンジニアを雇うには時間もリソースも足りないから。我々は急いでるんだ。
• 会社にシニアエンジニアを雇う余裕があるからジュニアな人を雇う必要がない。
• 我々はいま間違いをおかすわけにはいかないんだ。ジュニアエンジニアを雇うのはリスクが大きすぎる。
• 我々は従業員に自律的に働いてもらってる。ジュニアエンジニアが必要とするような手取り足取りの支援をすることはできない。
• 未経験者を雇う前にプロダクトの基盤を固めておきたい。

ジュニアエンジニアを雇うことは企業が義務感から行うもの、あるいは会社の予算に悪影響を及ぼすものという認識で、ジュニアエンジニアは負債のようなものだと言っているに等しい。慈善活動をする余裕があって補助作業要員を置けるような大企業が雇えば良いと言ってるようにもとれるが、そんなやり方はできない。

アメリカには 10 万を超えるテック企業があるけど、どこの CEO も「ミスは大した問題にならない」とか「持ってる金はじゃぶじゃぶ使いたいね」なんて言わない。だから結局「経験者のみ」と言って近道をしたつもりになっていたとしても、それはアドバンテージにはならない。会社がきちんと運営されてないことを露呈するだけだ。

Hostility to junior developers is an easy way to spot a toxic company culture.

— April Wensel (@aprilwensel) August 1, 2017

ジュニアエンジニアを雇うかどうかは組織、開発体制、企業文化の健全性の物差しになる。熟練の開発者はそのことを知っている¹。もしこの主張が聞き入れられなかったとしても、ジュニアエンジニアをバランス良く採用することは会社の財務を安定させる²ことは確かだ。

Preventing messes

ジュニアエンジニアは混乱を引き起こすから雇いたくないと拒否しているのであれば、それは会社に「ミスを許さない」文化があることを意図せず表明している。我が社はサーバーがダウンするたびに原因を作ったエンジニアをクビにしています、と言っているようなものだ。どんなに給料が高くてもすぐクビになる会社で働きたくないし、ミスをしないように開発者を脅すような文化はメンタルヘルスとプロダクティビティを阻害する。

こういう脅しの文化が自動化されたテストや QA 、フェイルオーバー、アクセス制限、バージョンコントロールなどを根付かせるんだとあなた言うかもしれない。しかし逆で、会社がフェイルセーフ技術を推奨し時間やリソースを与えるのであれば、「間違いを許さない」文化は不要で無価値だ。なぜならほとんどの不具合は production にリリースされる前に見つかって修正されるからだ。ジュニアエンジニアもシニアエンジニアも堅強な開発プロセスに守られてのびのび仕事ができる。

ジュニアエンジニアを雇い入れることは、過去に講じた不具合の予防策が機能しているか確認することができるまたとない機会ともいえる。彼らはシニアエンジニアよりもそういう罠にはまりがちだ。少しでも経験のあるエンジニアならみなそう言うように、ミス予防策の動作検証をしないということはあり得ないはずで、今やるかあとでやるかくらいしか選択肢がない。不具合が起こる可能性が残されているとき、ほとんどすぐにその不具合は起こる。どんなに経験があってもヒューマンエラーを完全に予防することはできない。

つまるところ少しのシニアエンジニアがいて開発基盤を固めてもらい、エラーに強い開発サイクルを構築すればよい。誰もジュニアエンジニアだけ雇えと言っているのではない。本当にミスをケアする職場であれば、ジュニアエンジニアもちゃんとフィットするし、シニアエンジニアも含めてみんなの満足度が高くなるはずだ。障害による炎上の火消しばかりやらなくて済むし、夜や週末はゆっくり休むことができる。

Saving money

Indeed.com によると、ジュニアエンジニアの給料の平均は $55,394 でシニアエンジニアの方は $117,374 だ。シニアエンジニアの給料は未熟な人の二倍以上だ。

コストには常に理由が必要だ。シニアエンジニアはジュニアな開発者よりも生産的であることが求められる。そんなに単純な話ではないが、ビジネスにかかるコストを無視するのは怠慢だし不利益を招く。

すべてのコードを書くのに長年の経験が必要なわけではない。良いコードを書く場合にだって必要ない。すべてのプログラムには、ありふれたやり方で入力と出力を結びつける「にかわのようなコード」が存在する。こういうのは誰が書いたって大差ない。時給 $28 の人に頼んでも時給 $59 の人に頼んでも結果は同じだ。もし熟練エンジニアしか雇わないのなら、そういった軽い仕事に余分なお金を払っているということになる。

コードは作るアプリケーションごとに結構変わるもので、慣れが生産性に大きく関わることがある。大抵のケースで、 6 ヶ月チームで仕事しているジュニアエンジニアと入ったばかりのシニアエンジニアでは、アプリケーションのドメインに詳しいという理由だけで前者の方が生産性が高かったりする。

先に述べた「にかわコード」とドメイン特化のコードを書くことは少なくとも開発業務の半分くらいを占める。その残りの部分で初めて熟練したシニアエンジニアの利点を活かせる。そしてたとえジュニアエンジニアであったとしても、十分な教材やベテランのメンターが付くことで難しい分野でもとても良い働きをしてくれることがある。

従ってジュニアとシニアのエンジニアでペアを組ませると二人のシニアエンジニアと同じだけの価値を発揮すると言える。しかもコストはシニア二人の場合の 75% しかかからない。もしあなたのゴールが最小の費用で最大の生産性を発揮することだとしたら、組織の中でジュニアとシニアの組み合わせを分子レベルでの最小単位とすべきだ。

加えて、シニアエンジニアばかり集めるとアルゴリズムやマイクロ秒単位の最適化、コーディングスタイルなど些細な事柄で延々議論をしてしまう傾向があることを考慮しなければならない。もし会社がシニアエンジニアだらけで、チームに堅実な意思決定プロセスが存在しなければ、数百時間分の人件費が議論のために失われることだろう。ジュニアエンジニアであればほとんどこういう問題を起こすことはない。

Building careers

ジュニアエンジニアを採用しないことによるもう一つのメッセージは、キャリア構築に対する無理解の表明だ。

Sometimes when companies say they're not hiring junior developers I want to shake them by their hoodies and yell, where do you think senior developers come from?!

— Kate Heddleston (@heddle317) September 13, 2018

これは会社の世間体とかテックコミュニティでの役割の話をしているのではない。あなたの会社をより働きやすくし、多くのエンジニアが入社し長く働いて会社に貢献してくれるようにするためのものだ。

数人のエンジニアが「やっと職位を変えることができたよ。もう職位を変えるのは嫌だ。一生シニアエンジニアでいたいね」と話しているのを聞いたことがある。しかし「給料なんて上がんなくていいよ。新しいことを学びたくもないし金輪際達成したことを評価されたくもないね」なんて言う人はいない。それに面倒なことに、向上心旺盛な野心家を引き留めるために必要なものは、無欲だが情熱的なシニアエンジニアを引き留めるのに必要なものとほとんど同じだ。仕事の成果を図るための評価軸と十分な研修用の教材、そして様々な種類の新旧のプロジェクトが必要だ。昇進を望まない少数の人に対しても、進歩や成長の意識を植え付ける必要がある。

しかしそういう連中に手をこまねかないでほしい。彼らは少数派だ。テック業界にいるエンジニアのほとんどが 40 年間もシニアエンジニアでいたいなんて思っていない。みんなソフトウェアアーキテクトだとか、チームリーダーだとか、 CTO だとか創業者になりたいと思っている。キャリア開発に関して無関心な企業は潜在的な従業員から働き先の最終候補にしか見てもらえない。

I only recruit senior devs.

The trick is, I recruit some of them earlier in their career.

— Reginald Braithwaite (@raganwald) September 17, 2018

エンジニアが面接を受けに来てもっとも感銘をうける言葉の一つはこういうものだ。「やぁ、僕はチームリーダーでこの会社に入って 8 年になる。最初はインターンだったんだ」。印象に残るがとても稀だ。こういう人は会社にとって非常に貴重だ。これまでの製品ラインの変遷を知っているし、半径 100 ヤード以内の各プロジェクトのコードを見てきている。組織の中の一人一人と一緒に仕事をした経験もある。他に誰もできないようなやり方で内側から会社を変革してくれるだろう。会社はこういう人の仕事で予測不可能なほどの利益を得るだろう。なぜなら社員を 8 年間（人生の 1/10 の時間に相当する）も同じ会社にとどまらせる方法を明らかにしたからだ。これは会社の文化醸成がうまくいっていることの証だ。職場のモラルは高く、良い仕事が評価され、社内の至る所で面白いプロジェクトが待ち受けていることを示す。

「ジュニアを雇わない」は、あなたの会社が誰かのキャリアの一部になる準備ができていないことを示している。会社が停滞していると公言しているのと同じだ。「我が社は経験豊富で能力の高いエンジニアを求めていて、金さえ払えば際限なく仕事をやってくれることを期待しています」。こういう求人に応募する人もいるだろうが、彼らは最善の仕事はしてくれないだろう。

もしあなたの会社がキャリア開発に真剣に取り組んでいるならば、ジュニアお断りポリシーは採用のパイプラインをしぼませ、従業員の在職期間を短くするだけだろう。

Making great software

ジュニアエンジニアにはシニア連中が普通失ってしまったようなユニークな特徴がある。その一つが盲目的な楽観思考だ。他に喜んで指示に従うというのもある。でも最も価値が高い特徴は、ジュニアは手ぶらであるということだ。シニアエンジニアの連中はこれまで技術の盛衰や失敗したプロジェクト、崩壊したチーム、その他の開発周りの罠を見てきている。彼らはその経験から強い意見を言い、時にそれは過度に一般化され、特定チームやプロジェクトでうまく行った（あるいは行かなかった）事柄を他のプロジェクトにも当てはまると思い込む。問題から新しい学びを得ることを避けるだろうことが明白だ。

Companies so eager to only hire senior people often forget that unlearning what doesn't apply can take longer than learning what does.

— DHH (@dhh) July 31, 2017

「あれがそこで使えなかったってことは知らなかったよ。でもここではうまく行くさ」と言うことがしばしばプロジェクトマネージャーの仕事になることがある。そのときジュニアエンジニアがその主張の裏付け役としてうってつけの存在になる。シニアエンジニアが長年かけて培った偏見なしに実証のためのプロトタイプを作ることができる。僕はジュニアエンジニアだったときによくこういう仕事をした。新しいツールや技術を試し、全く違うやり方で作り直したり、他の人が手を出すには早すぎると言ったことを実証試験したりしてきた。大抵僕はよりよい方法を見つけて、結果として会社のソフトウェアはかなり良くなった。ページ読み込みが遅かったところで一桁速度を改善したこともあるし、複数ページにまたがっていたものを一つにまとめ、将来のメンテナンスにかかる数週間分の工数を節約したし、時間を浪費する可能性があった不適切な技術を除外することもできた。技術的背景がまっさらでフレッシュな視点の有効性は無視できないものであることがわかる。

多くの会社が一束のシニアエンジニアを部屋に集めて問題解決方法について合意を得るための討論をさせている。しかし人件費の安い数名のジュニアエンジニアを加えるだけで一回きりの作業や野心的な取り組みに手を出しやすくなり、プロダクトに驚くべき成果をもたらすことができる。

ソフトウェアの品質に関しても、ジュニアエンジニアが感謝こそされないが重要な影響をもたらすことがある。彼らはシニアの連中が書きたがる頭でっかちでオーバーエンジニアリングなコードを書かない。

One underrated programmer attribute is the ability to write code that average or mediocre engineers can easily read, modify, and extend.

— Jamon Holmgren (@jamonholmgren) September 17, 2018

上のツイートで "凡人" と書かれているところを "ジュニア" に置き換えてみればこれがどういうことか分かるだろう。コードベースとはコードを書いている人々が重要だと思ったことが抽象化されて記録されているものだ。ジュニアエンジニアとシニアエンジニアの割合が健全であればコードはシンプルになり将来の改修も楽になる。

まとめると、テック業界で広がりを見せる「シニアのみ」の態度はジュニアエンジニアを低く評価している。これはみんな、特に未経験者の候補者を閉め出すことで採用を楽にしようという誤った考えをしている組織にとって損失でしかない。そういう会社は財務的に余裕があったとしても、無駄にしているお金と時間はとても多い。

もしあなたの会社がこういう問題に直面していたら、そしてもしあなたがジュニアエンジニアをどう雇い、どう教育すべきか知っていたら、ここで述べているベネフィットを享受することができるだろう。あなたの会社ではどんでん返しが減り、多様性が高く、競争による副作用も少なくて済むだろう。ソフトウェアは壊れにくくなり、輝きを放つようになるはずだ。もちろん、これだけがすべてではない。しかしジュニアエンジニアに対する積極的な採用方針はあらゆるレベルのエンジニアにとって働きやすさの指針になるはずだ。（翻訳ここまで）

---

ジュニアがいてもぶっ壊れない開発フローで思い出すのがペパボ時代のことだ。 Jenkins のセットアップがしたくて @hsbt さんがお守りをしていたプロジェクトの Jenkins 設定を参考にさせてもらってるときに、うっかりビルドを実行してしまって production へのデプロイが始まってしまった。青ざめたけど「 master からのデプロイなら全く問題ないように作ってあるので大丈夫」と言われてめっちゃカッケーなと思った。いま CI の仕組みを整えたり誰でも Hubot から簡単にデプロイしたりできるように頑張ってるののきっかけになってると思う。

Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレーンテキストをやめてリッチテキストエディターというか WYSIWYG Markdown エディターみたいな感じになってしまった。

記事本文を選択してコピーしたときにクリップボードに Markdown 形式で保存されればいいのに独自フォーマットでしかコピーされなくなり、 Day One で書いた内容をコピペしてブログに書いたりとか GitHub の Issue に書いたりということができなくなった。また footnote など Markdown の細かい記法に対応していたのが WYSIWYG 化されたタイミングでリストやヘッディングなど大雑把な記法にしか対応しなくなった。これまで信頼して日記をため込んで行ってたのに一気に信頼できなくなった。やっぱり Markdown でユーザーを集めることは無理なんだろうか。正直これでは劣化版の Evernote なので使い続けるメリットがない。新しい Markdown 日記ソフトを探さなければならない…

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

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 を使う場合は以下に気をつけるべきだと思う。

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

アルプス遠征で白馬に行ったとき、福岡からは松本経由で行った。前の記事に書いている通り台風の影響で縦走の予定がピストンとなったため、松本を一日観光する時間ができた。

松本には去年の秋に友達の結婚式で行っていて、そのとき市内を少し観光してすごくいいところだなと思った。前回は帰りの飛行機の時間の都合でできなかったことがいくつかあり非常に悔やまれたので、今回は前回できなかったことをやってきた。

宿泊

泊まったのは花月というホテルで、結構よいホテルのなはずなのにハイシーズンにもかかわらず低価格で泊まることができたが、部屋に入って窓を開けるとこの景色でなるほどという感じだった（これはこれで面白くてテンション上がった）。

昼食 1

松本には昼過ぎに着いたのでホテルに荷物を置きに行き、 The Source Diner に行った。ここには前回も来ていて、カウンターの席に座るとお店の人が料理している様子を眺めながら食事することができる。自分も料理するの好きなので目の前で料理してくれるタイプの店はプロの慣れた手さばきが見られてとても楽しい。

物色

あたりをうろつく。ナワテ通り外れの角にあるポーランド食器のセラミカがよくて、以前来たとき器を買うか迷ったが荷物になることや結構高いこと（ 21cm の皿でも 3000 円から 5000 円くらいする）、帰りの飛行機まで時間が限られていたことで決心しきれず、買わずに帰ってきてしまった。あとあとこのことが非常に悔やまれて、もしまた松本に行く機会があればセラミカを訪ねて皿を買いたいと思っていた。

買いたい器に目星をつけたが今日は荷物になるので買わないでおく。

コーヒー 1

その後、セラミカの器でコーヒーが飲める喫茶店「カフェあげつち」でコーヒーを飲んだ。この喫茶店は 300 円でコーヒーが飲めてレトロな家具や調度品が飾ってあり休憩にちょうどよい。観光客向けというより地元の人が談笑しに来ている感じ。年季の入った建物を修復して公営の会議スペースとして利用しているようである。

松本城

そこから松本城に行った。前回も今回もお城の中には入らなかった。入り口に「ここから 30 分待ち」というような看板があったが、ああいうのがあると入るのをためらってしまう。

お土産 2

夜は会社の仲良しおじさん連中と飲みに行くことにしていたので、ムラマサに行ってお土産を物色した。ここも前回来たときに気にはなったけど時間がなくて素通りしてしまった店（まつもと空港で売ってるだろうと思ってスルーしたら売ってなかった）で、寄らずに帰ったことを猛烈に後悔したので滞在中何度も訪ねて入念に物色した。シュークリームが名物のようだったが旅行者で冷蔵庫に保存することができないのでお店の人にお勧めを聞いて天守石垣サブレを買った。この手のクッキークリームサンド的なお菓子にはあまりテンションが上がらないのだが、帰ってきて食べてみたら確かにおいしかった。

飲酒 1

花時計公園の横にある信州ゴールデン酒場に行った。山賊焼を食べたが焼きという名前なのに揚げてあるのにはびっくりした。あと付け合わせキャベツについてくる味噌が完全にう◯こに見えてやばかった。キンミヤハイボールがよいと foursquare の Tip にあったので頼んだらもろに甲類焼酎のアルコールにやられて悪酔いした。

飲酒 2

二軒目はナワテ横丁にある彗星倶楽部という名前の店に行った。両腕にタトゥーを入れたお姉さんがやっててかっこよかった。つまみも全部うまかった。

さらにもう一軒行ってそばを食べたけど泥酔し過ぎていてあまり思い出したくない…。

朝食

12:50 にバスセンター集合だったので早めにチェックアウトして朝食を食べに行ったが、目当てにしていたおきな堂はモーニング営業を取りやめており路頭に迷ってしまった。二日酔いで勘が鈍っており、ふらふらしながらナワテ通りの適当なパン屋に入ったところいまいちだった…。せっかくよいホテルに泊まってたのだから大人しくホテルの食堂のモーニングを食うべきだった。同僚によると「まるも」という喫茶店が良かったとのこと。

お土産 3

萬年屋というところで味噌を買った。信州味噌はなかなか九州では買う機会がないので面白い。二年熟成の味噌を買った。

コーヒー 2

この日のメインイベントはセラミカでの器購入だったがオープンが11時なので開店まで暇をつぶす必要があった。朝食のコーヒーがいまいちだったので年季の入った外観だが今風の若い人が載ってそうなチャリンコが停めてある喫茶店に入ってコーヒーを飲んだ。

セラミカで散財

11 時になり満を持してセラミカに行った。山小屋泊ですっかり朝が早くなったので 11 時はもう夕方みたいに感じる…。皿を三枚とマグカップを買った。グラタン皿も良さそうだったが流石に高すぎた（一万円オーバー）。カード払いしたが二回分割したかったのに何も聞かれず一括で決済されてしまった…。ただ買った皿はとてもよい。何でもおいしく感じる。

昼食 2

ホテルの近くに有名なそば屋があるようだったのでセラミカで買い物をしたあと行ってみたが、 11:30 オープンで 11:35 に着いたにもかかわらずすでに満席で店の外まで列ができていた。今から並んではバスセンターの集合時刻に間に合わなくなるので仕方なく別のそば屋に入った。この日は暑かったが鴨南蛮が食べたくてだらだら汗をかきながら熱いそばを食べた。

散策

そばを食べたあと、ホテルに預かってもらっていた荷物を受け取り、ホテル横の湧水場で湧き水をナルゲンボトルに汲んだ。松本は市内各所でこのように水が湧き出ているようである。重いザックを背負いバスセンターまで 10 分ほど歩いた。松本は標高 600m あるとはいえ 8 月の日中は暑く、大量に汗をかいた。

インスタグラムスポット

途中、ふとん屋のたたずまいが良すぎて写真を撮った。ここは去年来たときも見かけて写真を撮ったが、去年は一眼レフを持ってきておらず iPhone でしか写真を撮れなかったことをとても悔やんでいた。

感想

松本は岳都や学都、楽都と言われるが、確かにそうだなと思った。北アルプス登山の足がかりとなる街で市内から北アルプスの山々の姿を見ることができる。また信州大学の本部があり旧制高校の松本高等学校もあって学問の雰囲気も感じる。ナンバースクールがあった熊本（第五高等学校）よりも貫禄がある。加えて音楽が盛んなようで、街中に小澤征爾の音楽祭のポスターが貼ってあった。どうやら市をあげて音楽振興に取り組んでいるようである。

生まれ故郷の阿蘇もかつては阿蘇登山の拠点として駅前に旅館がいくつもあり栄えていたが、自動車が普及し日帰りで訪れることができるようになって 90 年代にはそれらの旅館は全て廃業してしまった。松本はきっとその時代から変わらず岳都として栄え続けているのだろう。山の高さや数が阿蘇とは全然違うとはいえ、山岳観光都市として参考にできる点は大いにあると思った。

アルプス登山がてらまた行きたい。

仕事で長野県、富山県、新潟県の県境に跨がる北アルプスの白馬岳に行った。山行記録はこちら。

当初は以下のように栂池高原 -> 白馬岳 -> 朝日岳 -> 蓮華温泉という縦走の予定だったが、台風が近づいており、急遽予定を短くして栂池高原 <-> 白馬岳のピストンとなった。 YAMAP の活動日記に書いているとおり体力不足で、15kg の荷物とカメラバッグが肩に食い込んでいたこと、また往路で転倒して左膝を岩場で強打したことによりかなり膝が痛む状態だったため、もし縦走で三日目があった場合は途中で離脱してしまっていたかもしれない。

アルプス、日本なのに「アルプス」みたいな名前は変だしいけすかない、山は生まれ故郷の阿蘇や久住が一番だ、という思いを持っていたけど、実際行ってみるとスケールが全然違った。盛夏でも雪が溶けずに残る雪渓、森林限界を超えたあとに広がる景色、稜線を境に長野側と富山・新潟側の両方の景色を眺めることができる高さ、山小屋泊、夜の星空の美しさ、全てにおいて圧倒されてしまった。そもそも日本アルプスという名前も日本人が勝手に名乗り始めたわけではなく、明治時代に来日した鉱山技師のウィリアム・ゴーランドというイギリス人が命名し、宣教師のウォルター・ウェストンがヨーロッパに名前を広めたものらしい。なんで Japanese Alps という英語表現がオリジナルということになる。

アルプスの素晴らしさは上に書いた通りだが、夏でも頂上付近は夜になるとダウンジャケットが必要になるくらい寒く、また天候が悪化すると下界よりはるかに厳しい気象条件となり、稜線や岩場を歩く際は凄まじい風に体を持って行かれそうになる。重い荷物を背負った状態でちょっと足運びを誤ると転倒して滑落し、傾斜が急な長野県側に落ちた場合はほぼほぼ命を落とすことになる。雨が降れば気温が下がり、雨具を持たない場合は夏でも低体温症になってしまう。

語弊を恐れずに言うと高い山に登るのは博打に近いよなぁと思った。すばらしい景色、他では見られない景色を見るために命を危険にさらして山に登に行っている感じ。どう考えても家でじっとしてテレビ見たり出かけるにしても街に行って買い物したりしてる方が安全じゃないですか。山に行かなければ死ぬ可能性はとても低い。『岳』という漫画を読むと、山に登って滑落し、手足をタコのようにぐにゃぐにゃに折り曲げて死んでいく人たちが沢山出てくるけど、そういう危険をおかしても行きたくなるようなギャンブルにも似た中毒性が山登りにはあるのではないかと思った。

明後日から仕事で北アルプス遠征に行くので以前映画館で見たことがある『劔岳 点の記』を再視聴しておこうとするも Amazon Prime Video にも Netflix にもなく、 Amazon Video で都度払いで借りることもできず、仕方なく iTunes のレンタルで借りようかなと調べると微妙に高くて昔見た映画見るのに 400 円も払えないなぁと調べてたら楽天TVにもあって価格は 324 円、楽天ポイント使って 172 円で借りることができたけど Apple TV にミラーリングして見ようとすると DRM かかってるようでミラーリングできなかった（予告編はミラーリングできたのに本編は不可）。頭にきたので即刻楽天TVアプリをアンインストールして近所のレンタル屋に行って DVD 借りてきていざ見ようとしたら別の DVD が入ってて、どうも店員が『劔岳 点の記』のジャケットに別のディスクを入れてたようだったけど、電話したところ「お客様が間違っただけでは」と言われてさらに頭にきて見ずに返しに行き、諦めて楽天TVで借りたやつを iMac で見ようとしたら「 Silverlight のインストールが必要です」と表示されて結局見ることはできなかった。もうアルプスで遭難するしかない。