portal shit!

北アルプスから帰ってきたあと「二丈岳に行ったけど物足りなかった」とぼやいていたところ同僚に福吉駅から十坊山、浮嶽、女岳、二丈岳を経て深江駅までの四座縦走をやってのけられ、これに触発されて一ヶ月ほど前に計画したものの雨天や家用でなかなか実現できなかったやつをやった。開始地点を浜崎駅に移して浜玉側からスタートするルートは 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秒でも早く依頼したソフトウェアを納品してほしい人からはなんか勝手なことをやってるように見えるし、それが当たり前になると特にありがたみを感じられない種類のものなので評価の対象となりにくい。問題が起こって仕組みが使えなくなったときに初めてありがたみがわかる。なので在職中には評価されない。少なくとも上司からは。

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

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

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

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 エディターみたいな感じになってしまった。

Version 3

We are proud to introduce the latest iteration of the Day One journaling application. Version 3 is a major update to the foundation of th...

dayoneapp.com

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

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

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

mperham/sidekiq

Simple, efficient background processing for Ruby. Contribute to mperham/sidekiq development by creating an account on GitHub.

github.com

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

The Twelve-Factor App （日本語訳）

A methodology for building modern, scalable, maintainable software-as-a-service apps.

12factor.net

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

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

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

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

宿泊

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

松本ホテル花月【公式ホームページ】

国宝・松本城まで徒歩で約5分、民芸家具を随所に配置した創業明治20年のホテル。 2016年4月5日、「民藝フィロソフィ 松本の日常の記憶」をコンセプトにリブランドオープン。 レストランでは「ながのテロワール」をコンセプトとしたコース料理を提供。

matsumotohotel-kagetsu.com

昼食 1

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

The Source

www.thesourcediner.com

物色

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

セラミカショップ CERAMIKA

かわいらしく丈夫で使いやすいポーランド陶器「ポーリッシュ・ポタリー」を、形や絵柄など豊富なバリエーションで数多く取り揃えています。「CERAMIKA ARTYSTYCZNA（セラミカ・アルティスティッチナ社）」の日本国内正規輸入代理店。

ceramika-shop.jp

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

コーヒー 1

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

松本市下町会館　松本市ホームページ

www.city.matsumoto.nagano.jp

www.facebook.com

松本城

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

お土産 2

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

マサムラ 上土店 (松本/ケーキ)

★★★☆☆3.00 ■予算(昼): ～￥999

tabelog.com

飲酒 1

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

松本市の居酒屋・バー　信州ゴールデン酒場

居酒屋　長野県松本市・長野市　串焼き ｜カリユシ｜おさけや｜シジミ屋

new-concept-resort.jp

飲酒 2

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

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

朝食

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

珈琲 まるも (松本/喫茶店)

★★★☆☆3.54 ■予算(昼): ～￥999

tabelog.com

お土産 3

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

信州松本城下町の老舗味噌屋　萬年屋

創業天保3年、信州は松本城下町の老舗味噌屋「萬年屋」。オンラインショップでは、天然醸造の味噌玉造り味噌や二年味噌、麹味噌、白味噌の他、各種お漬物の販売をしております。

mannenya.ne.jp

コーヒー 2

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

珈琲茶房 かめのや (松本/喫茶店)

★★★☆☆3.05 ■予算(昼): ～￥999

tabelog.com

セラミカで散財

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

昼食 2

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

そば処 吉邦 (北松本/そば)

★★★☆☆3.13 ■美味しい蕎麦と鴨料理を、郷土の地酒と共に堪能できる一軒 ■予算(昼): ～￥999

tabelog.com

散策

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

インスタグラムスポット

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

感想

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

セイジ・オザワ 松本フェスティバル 公式サイト

1992年、小澤征爾が創立し、毎夏、長野県松本市で行なわれる音楽祭。世界中から優れた音楽家たちが結集し、サイトウ・キネン・オーケストラを中心に多彩な演目が披露される。OMFの大きな特色である小澤征爾音

www.ozawa-festival.com

楽都　松本市ホームページ

www.city.matsumoto.nagano.jp

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

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

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

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

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

日本アルプス - Wikipedia

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

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