サイトの横幅（ max-width ）を 1280px に広げてみた。最も頻繁にこのサイトを訪れる自分の閲覧環境が 5K ディスプレイになったので昔の環境（ 13 インチの MacBook ）に合わせて作ったデザインでは横幅が間延びした感じがあっていまいちだった。文字サイズもちょっと小さかったので 15px から 18px にした。 cho45 さんがまえブログに書いてたけど、自分のディスプレイを大きくして画像を大きいサイズで見る機会が増えて、大きい画像の尊さのようなものを感じるようになってきた。
大きな画像っていうのはそれだけで強い主張があります。かつてあった「体験」を呼び起こす力が画像の大きさと解像度にはあります。そこにいて、そこでこう見たのだという主張のため、とにかく大きいのは正義なのです。
Flickr から埋め込み表示している画像は ebmed タグの中で width と height が固定されているので本文幅に合わせるためには手でちまちまと大きいサイズに変えていかなければならない（おいおいやっていきます）。
ダントツにマキタの掃除機だった。
掃除機、いまは大まかに三種類に分けられると思う。一つは昔ながらのワイヤード掃除機。よく掃除できるが取り回しがうざい。二つ目はルンバのようなロボット掃除機。実は日本の家庭、特に都市部の戸建て住宅には向いていないのではないかと思う。最後に今回自分が買ったようなコードレスタイプの掃除機がある。総合的に考えてコードレスの小型掃除機が一番よいと思う。
シャープの 2011 年製の掃除機を使っていたが、コードレスでないこと、取り回しが大変なことで掃除機がけが非常に億劫だった。特に階段の掃除機がけがしんどくて、階段の途中までは一階のコンセントから電源を取り、途中で届かなくなるので一旦本体を抱えて一階まで下りてからコードを引き抜き、二階まで本体ごと持って上がって二階のコンセントから電源を取り直すという作業が必要だった。また階段の掃除機がけの際に常に本体を抱えておく必要があり結構しんどかった。嫁さんはこれがだるいからとホースの部分だけ持って掃除機を引っぱり上げるような使い方をしていたので引っぱり上げる際に掃除機本体が階段とぶつかり階段がぼろぼろになってしまった。
ルンバもあるにはあったが、全然使うことがなかった。というのもルンバは二階建ての狭い家には向いていない。マンション住まいで平らな部分の面積が 80m2 以上あるような家だといい感じに機能してくれるのかもしれないが、二階建ての一般的な住宅だと平らな部分の面積がせいぜい 40m2 程しかなく、床にはたいてい取り込んだ洗濯物やちょっとした段ボール、子どものおもちゃなどが散乱しているので、ルンバを稼働させてもすぐに衣類などの障害物に絡まり全く期待した動きをしてくれない。また音が非常にやかましい。一人暮らしか夫婦二人暮らしで昼間は家に誰もいない、というタイプの所帯であれば平日昼間にルンバを動かせば音は気にならならずいい感じに掃除してもらえるかもしれないが、常に誰か家にいるようなタイプの家庭ではルンバをメインの掃除機に据えることはできないと思う。結局わが家はルンバは購入したものの両手の指で数える程しか稼働させていない。
ダイソンの V7 あたりとどっちにするか迷ったが、最終的にマキタを選んで正直正解だったと思っている。ダイソンは見た目はかっこいいが、やはり音がやかましく、しかもでかくて重い。欧米の大きな家と大きな手をした欧米人向けの掃除機だと思う。日本の家とアジア人の小さな手にはマキタ級の小型軽量な掃除機が一番向いている。もちろん値段もめっちゃ安い。
マキタで一番気に入っているのが掃除をしたいと思ったときにさっと取り出せて使えるところだ。まず床に散乱しているものを片づけて、掃除機を物置から引っ張り出してきてというステップを省略して、床のほこりが気になったときにいきなり掃除機がけができる。掃除機がけの心理的ハードルがめっちゃ下がった感じがする。
ごみ捨ては昔ながらの紙パック式で、タンクを取り外して細かいほこりの粒子を吸い込んでせき込みながらフィルターの掃除をするという苦行からも解放された。吸い込み部に回転式の吸い込み機構がない分、一度に吸い込める量は減るかもしれないが、それを補ってあまりあるメリットがある。
とにかく掃除機がけを行う人間側のコストが大幅に下がるので、家が狭い人、家が散らかっている人、掃除機がけのための片づけが面倒な人にマキタの掃除機はスーパーオススメです。スタンドと一緒に買うと置き場所もすっきりして便利。
この記事は 今年買ってよかったもの Advent Calendar 2018 二日目の記事でした。昨日は 観音クリエイション さんで明日は @repezen0819 さんです。
北アルプスから帰ってきたあと「二丈岳に行ったけど物足りなかった」とぼやいていたところ同僚に福吉駅から十坊山、浮嶽、女岳、二丈岳を経て深江駅までの四座縦走をやってのけられ、これに触発されて一ヶ月ほど前に計画したものの雨天や家用でなかなか実現できなかったやつをやった。開始地点を浜崎駅に移して浜玉側からスタートするルートは 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 年の間に随分とジョブホッピングを繰り返してきたが、どこの会社でも評価が良くない。上司（非技術者であったことがほとんど）からは全く評価されない。なので在職時に昇給したということはほぼない。ペパボ時代にエンジニア評価制度が導入されてシニアエンジニア1になったときにががっと給料が上がったことはあったけど、あれは直属の上司ではなく技術責任者から評価されるという仕組みだったのでイレギュラーケースといえると思う。その後は転職時に増えた以外では全然給料が増えたことはない。据え置きが続いたりむしろ下がったことすらある。
しかし一度退職すると、同じチームの同僚や隣のチームの偉い人とかから良く思われていたことが判明することが多い。戻ってきてほしいとか、いなくなって困ってるとか。当然社交辞令の部分もあると思うが、全く役に立たないクソ野郎だったらそんなことを社交辞令で言われることもないはずなんで、ある程度は評価されていたといえるんだと思う。
なぜ在職中に上司から評価されないのか考えると、当時の上司がやってほしいと思ってることをやらないからだと思う。自分はチーム全体で効率が良くなるようにツールをあれこれしたり bot でガチャガチャやったりとか（ Developer Productivity の向上）が好きなんで、自分の動きは会社がやりたいこと、上司がやらせたいこと（売り上げが増える何か、アプリのダウンロード数が増える何か）に直接寄与していないよう見える。
前職や現職で新しくプロジェクトが動き始めるときに何は無くともユニットテストを実行できる仕組みと Docker や CI 環境の構築をガガっとやってて、誰もがテスト書いて Pull Request 出して CI パスしてからレビュー依頼してデプロイも確認環境には自動でじゃんじゃんデプロイされて（ Continuous Delivery ）、誰も（新人やプログラマーでない人含む）が簡単に本番にもデプロイできる仕組みを作ったという自負がある。こういうのは直接売り上げは増やさないけど開発サイクルを早めたりチームの生産性を高めたりしていると思うが、1秒でも早く依頼したソフトウェアを納品してほしい人からはなんか勝手なことをやってるように見えるし、それが当たり前になると特にありがたみを感じられない種類のものなので評価の対象となりにくい。問題が起こって仕組みが使えなくなったときに初めてありがたみがわかる。なので在職中には評価されない。少なくとも上司からは。
加えて、自分には理想主義的なところがあって、訳の分からない指示が来たときに「そもそもそれいまやることですか」とか「会社がやるべきなのは違うことじゃないですか」と言ってしまう。そもそも論を言うので、ミーティングに参加していても荒れたり脱線してしまったりして「こいつ今これ言うのかよ…」みたいな冷たい視線を浴びることがよくある。場をかき乱す発言をするので「こいつはわかっていない」という烙印を押されてしまう。
評価が良くないと、長く同じ会社に留まり続けるメリットが得られず転職を繰り返してしまう。正直なところ転職は面接を受けに行ったり、給与交渉をしたり、退職を打診したり、仲の良い同僚と別れたり、有給がリセットされたり、人間関係を作り直したり、健康診断の履歴が失われたり、ローンを組むとき不利になったりでしんどいことが多い。できる限り同じ職場で働き続けることがハッピーだろうなぁとは思うんだけど、会社から評価されないのは不満が溜まるし、自分のような人間（間接的にだが結構会社の役に立ってる）が評価されないのはその組織にとっても良くないと思えて転職するという選択をしてしまう。良くない。会社が自分の評価を良くせざるを得ない状況に持ち込めるくらいに腕力（プログラミング能力）や胆力（度胸）をつけなければならないんだろうなぁとは思ってる。
※ なおこの記事は退職エントリーではありません。
今にして思うと当時の自分は全くシニアではなくジュニアだった https://portalshit.net/2018/10/02/we-should-hire-junior-engineers ↩
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
ジュニアエンジニアを雇うかどうかは組織、開発体制、企業文化の健全性の物差しになる。熟練の開発者はそのことを知っている1。もしこの主張が聞き入れられなかったとしても、ジュニアエンジニアをバランス良く採用することは会社の財務を安定させる2ことは確かだ。
ジュニアエンジニアは混乱を引き起こすから雇いたくないと拒否しているのであれば、それは会社に「ミスを許さない」文化があることを意図せず表明している。我が社はサーバーがダウンするたびに原因を作ったエンジニアをクビにしています、と言っているようなものだ。どんなに給料が高くてもすぐクビになる会社で働きたくないし、ミスをしないように開発者を脅すような文化はメンタルヘルスとプロダクティビティを阻害する。
こういう脅しの文化が自動化されたテストや QA 、フェイルオーバー、アクセス制限、バージョンコントロールなどを根付かせるんだとあなた言うかもしれない。しかし逆で、会社がフェイルセーフ技術を推奨し時間やリソースを与えるのであれば、「間違いを許さない」文化は不要で無価値だ。なぜならほとんどの不具合は production にリリースされる前に見つかって修正されるからだ。ジュニアエンジニアもシニアエンジニアも堅強な開発プロセスに守られてのびのび仕事ができる。
ジュニアエンジニアを雇い入れることは、過去に講じた不具合の予防策が機能しているか確認することができるまたとない機会ともいえる。彼らはシニアエンジニアよりもそういう罠にはまりがちだ。少しでも経験のあるエンジニアならみなそう言うように、ミス予防策の動作検証をしないということはあり得ないはずで、今やるかあとでやるかくらいしか選択肢がない。不具合が起こる可能性が残されているとき、ほとんどすぐにその不具合は起こる。どんなに経験があってもヒューマンエラーを完全に予防することはできない。
つまるところ少しのシニアエンジニアがいて開発基盤を固めてもらい、エラーに強い開発サイクルを構築すればよい。誰もジュニアエンジニアだけ雇えと言っているのではない。本当にミスをケアする職場であれば、ジュニアエンジニアもちゃんとフィットするし、シニアエンジニアも含めてみんなの満足度が高くなるはずだ。障害による炎上の火消しばかりやらなくて済むし、夜や週末はゆっくり休むことができる。
Indeed.com によると、ジュニアエンジニアの給料の平均は $55,394 でシニアエンジニアの方は $117,374 だ。シニアエンジニアの給料は未熟な人の二倍以上だ。
コストには常に理由が必要だ。シニアエンジニアはジュニアな開発者よりも生産的であることが求められる。そんなに単純な話ではないが、ビジネスにかかるコストを無視するのは怠慢だし不利益を招く。
すべてのコードを書くのに長年の経験が必要なわけではない。良いコードを書く場合にだって必要ない。すべてのプログラムには、ありふれたやり方で入力と出力を結びつける「にかわのようなコード」が存在する。こういうのは誰が書いたって大差ない。時給 $28 の人に頼んでも時給 $59 の人に頼んでも結果は同じだ。もし熟練エンジニアしか雇わないのなら、そういった軽い仕事に余分なお金を払っているということになる。
コードは作るアプリケーションごとに結構変わるもので、慣れが生産性に大きく関わることがある。大抵のケースで、 6 ヶ月チームで仕事しているジュニアエンジニアと入ったばかりのシニアエンジニアでは、アプリケーションのドメインに詳しいという理由だけで前者の方が生産性が高かったりする。
先に述べた「にかわコード」とドメイン特化のコードを書くことは少なくとも開発業務の半分くらいを占める。その残りの部分で初めて熟練したシニアエンジニアの利点を活かせる。そしてたとえジュニアエンジニアであったとしても、十分な教材やベテランのメンターが付くことで難しい分野でもとても良い働きをしてくれることがある。
従ってジュニアとシニアのエンジニアでペアを組ませると二人のシニアエンジニアと同じだけの価値を発揮すると言える。しかもコストはシニア二人の場合の 75% しかかからない。もしあなたのゴールが最小の費用で最大の生産性を発揮することだとしたら、組織の中でジュニアとシニアの組み合わせを分子レベルでの最小単位とすべきだ。
加えて、シニアエンジニアばかり集めるとアルゴリズムやマイクロ秒単位の最適化、コーディングスタイルなど些細な事柄で延々議論をしてしまう傾向があることを考慮しなければならない。もし会社がシニアエンジニアだらけで、チームに堅実な意思決定プロセスが存在しなければ、数百時間分の人件費が議論のために失われることだろう。ジュニアエンジニアであればほとんどこういう問題を起こすことはない。
ジュニアエンジニアを採用しないことによるもう一つのメッセージは、キャリア構築に対する無理解の表明だ。
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.
— Reginald Braithwaite (@raganwald) September 17, 2018
The trick is, I recruit some of them earlier in their career.
エンジニアが面接を受けに来てもっとも感銘をうける言葉の一つはこういうものだ。「やぁ、僕はチームリーダーでこの会社に入って 8 年になる。最初はインターンだったんだ」。印象に残るがとても稀だ。こういう人は会社にとって非常に貴重だ。これまでの製品ラインの変遷を知っているし、半径 100 ヤード以内の各プロジェクトのコードを見てきている。組織の中の一人一人と一緒に仕事をした経験もある。他に誰もできないようなやり方で内側から会社を変革してくれるだろう。会社はこういう人の仕事で予測不可能なほどの利益を得るだろう。なぜなら社員を 8 年間（人生の 1/10 の時間に相当する）も同じ会社にとどまらせる方法を明らかにしたからだ。これは会社の文化醸成がうまくいっていることの証だ。職場のモラルは高く、良い仕事が評価され、社内の至る所で面白いプロジェクトが待ち受けていることを示す。
「ジュニアを雇わない」は、あなたの会社が誰かのキャリアの一部になる準備ができていないことを示している。会社が停滞していると公言しているのと同じだ。「我が社は経験豊富で能力の高いエンジニアを求めていて、金さえ払えば際限なく仕事をやってくれることを期待しています」。こういう求人に応募する人もいるだろうが、彼らは最善の仕事はしてくれないだろう。
もしあなたの会社がキャリア開発に真剣に取り組んでいるならば、ジュニアお断りポリシーは採用のパイプラインをしぼませ、従業員の在職期間を短くするだけだろう。
ジュニアエンジニアにはシニア連中が普通失ってしまったようなユニークな特徴がある。その一つが盲目的な楽観思考だ。他に喜んで指示に従うというのもある。でも最も価値が高い特徴は、ジュニアは手ぶらであるということだ。シニアエンジニアの連中はこれまで技術の盛衰や失敗したプロジェクト、崩壊したチーム、その他の開発周りの罠を見てきている。彼らはその経験から強い意見を言い、時にそれは過度に一般化され、特定チームやプロジェクトでうまく行った（あるいは行かなかった）事柄を他のプロジェクトにも当てはまると思い込む。問題から新しい学びを得ることを避けるだろうことが明白だ。
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 エディターみたいな感じになってしまった。
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 の使用経験があった。
Simple, efficient background processing for Ruby. Contribute to mperham/sidekiq development by creating an account on GitHub.
github.com
リーダーが Sidekiq に反対する理由は以下だった。
一方で自分が 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の開発者は、開発と本番の間で異なるバックエンドサービスを使いたくなる衝動に抵抗する。 バックエンドサービスの違いは、わずかな非互換性が顕在化し、開発環境やステージング環境では正常に動作してテストも通過するコードが本番環境でエラーを起こす事態を招くことを意味する。この種のエラーは継続的デプロイを妨げる摩擦を生む。この摩擦とそれに伴って継続的デプロイが妨げられることのコストは、アプリケーションのライフサイクルに渡ってトータルで考えると非常に高くつく。
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 を使う場合は以下に気をつけるべきだと思う。
