京都でお気に入りの喫茶店とパン屋

茶店

六曜

beacon-kyoto.com

ここの濃ゆいコーヒーにミルクをたっぷりいれるのがぼくの最高のコーヒー。 コーヒーの苦さとミルクの甘さ、それらが混ざったまろやかさとコクが好みです。 あとその状態で食べるドーナツがうまい。

難点は喫煙しているひとがいるとダルいのと混むのであまりゆっくりしてられない。

スマート珈琲

www.smartcoffee.jp

なんか最近いついっても人が並んでいるのでそのまま踵を返すことが多くなってしまったけど奇跡的に人がいないときにいくとまったり出来てよい。

カフェ火裏蓮花

cafequarirengue.wixsite.com

スマート珈琲にするか悩んだ結果こっちにした。スマート珈琲は最近並んでるひとが多すぎていけてないしね。

普通にしていると素通りして気づかない路地にぽつんとある町家を改装したブックカフェ。 店内にある本は好きに手にとって読んでいいとのこと、最高。

コーヒーに変わり種っぽいのがあるけどまったり出来て良い。 アガサ・クリスティーアクロイド殺しまだ読了してないのでまた近日中によりたい。

ランチのプレートも美味しいけどピラフが美味しくてボリュームあって満足度高かった。

自家焙煎喫茶インパルス

www.kyoto-kawaramachi.or.jp

繁華街にある立地でありながらも上記の店舗などに比べて非常にゆったりした空気感がある。 サイフォン式でコーヒーを淹れてくれるのだけどついつい見入ってしまう。

生きている珈琲

ikiteiru.com

薄暗い店内と落ち着いた雰囲気、そして電源とwifiがあり最高of最高!!! どのコーヒーが苦味があるとか酸味がつよいなどの四象限な表を用意してくれているのでコーヒーよくわからん!みたいなぼくでも色々試し飲みしてみようと思える。 コピ・ルアックのコーヒーもあるらしいが1杯3000円以上しているので頼んだことがない。一度頼んでみたい。

パン屋編

Café Bibliotic Hello!

cafe-hello.jp

茶店としてもお気に入りなんだけども隣にあるパン屋のパンがマジでうまい。 外側の生地がしっかりしているのだけど中はもっちりしていて小麦の甘みをしっかり感じさせてくれる。

ナカガワ 小麦店

nakagawakomugiten.com

わざわざ自転車で片道10km走って買いに行ったら14時くらいなのに売り切れていて出直したことがある思い出のお店。 とにかく小麦にこだわっていてパンがパンとして極上にうまい。 朝の贅沢〜!みたいな気持ちにしてくれる。

グランディール

grandir-kyoto.jp

よく行くのは京都ポルタ店と下鴨店。 下鴨店のほうがよくいくかも。春先あたりの少し肌寒いときにコーヒーとパニーニを鴨川で食べてるとクソエモでおすすめ。

ファイブラン

fiveran.jp

試食したいパンがあれば遠慮なくお申し出ください。見た目では選ばないパンもあると思いますが、食べてもらわないと分かりません。

と書かれている通りほぼ全品試食が可能。気に入ったものを買って帰ることができる。 この店も生地にこだわりがあり、比較的薄めだがパリッとした外側の生地とモチモチした中の食感が日本人好みなパン。

菓子パン系も多くあるので子供やお母さん方に人気があるっぽい。でもわざわざ観光客のひとが買いに来ているのもみたので有名なお店?かも。

たま木亭

www.tamaki-tei.com

とにかくうまい。 そしてめちゃくちゃ並ぶ、とにかく並ぶ。 駐車場は第二か第三まであるらしいのだがそれがいついっても満車になってる。夏行くと死んじゃうので飲み物買っておいたほうがいいですよ。

1店舗なのに本になっちゃうくらいうまい。

忘れられないパン 「たま木亭」

忘れられないパン 「たま木亭」

難点は遠いこと。 もはや京都ではなく宇治。

まとめ

他にもカフェ kociとかeightとか逃現郷とかあるんだけど紹介しきれない&めんどくさくなったのでこのくらいで切り上げる。 なんでこんなことをしたかというと最近お気に入りだった飲食店が潰れてしまっていて大変悲しい思いをしたので常日頃から感謝の気持ちをしつつちゃんと儲かってほしいな、継続可能なおいしいパン屋や喫茶店が残り続けてほしいなと思ったのでリストアップしました。

wifiと電源がほしければスタバいけばいいんだけどそうじゃなくて雰囲気や食べるもの、飲むものも楽しめるお店が残り続けてほしいなと願ったという感じです。 閉店告知される前に定期的にお店に行こうな!

IT未経験者の問題じゃなくてメンター側の問題だと思う。

note.mu

前提となる条件の会社で働いたことがないので正直的外れなのかもしれない。 でもぼくはこれを読んだときの素直な感想として「これは違うんじゃないかなー?」と思った。

とはいえ完全に否定したいわけでもなくて同意ポイントと違和感ポイントがあるなという感じです。

追記

ブコメでテスターでもいいんじゃないの?というコメントをみかけて誤解させてしまう文章を書いてしまったなと思ったので訂正です。

id: hotu_ta 自分は、自然とブラックボックステストっぽいことからエンジニアの人生を歩み始めたし、テスターからエンジニア的な理解を深めていくのは悪くないアプローチに感じる。

テスターそのものから開始すること、それ自体はあってもいいのではないか?と思います。 ただ上記エントリでの問題を解決するためにテスターを選択するのは短絡的な解決方法であって根本治療ではないのでは?ということで書いた感じです。

きちんとメンターがメンティーに対してチケットを渡せる粒度に落とし込めていればそもそもテスターになる必要はないかもしれませんし、その上で一度テスターになって全体のフローを知ろうというのであれば多分ひっかかりはなかったと思います。 誤解させる文章になっていてすみません。

同意ポイント 「徐々にできる範囲を広げる」

これは「やれる」という自信を持ってもらうためにまず実績を積むという意味だと思うんだけど大賛成。 まずはやれるところから、そしてやれるところを少しずつ増やす。 振り返りや1on1などで前回はここまでしか出来なかったのにいまはこんなに出来るようになったよ!すごい!!!みたいなことをきちんと伝えると自信と実績をちゃんと評価してますよというフィードバックになってよいんじゃないかな。

同意ポイント 「テスター案件で指導の下、「プログラマーの仕事の一部」としてシステム開発の仕事に慣れる」

これはIT未経験者だから、とか関係なく自分が知らないプロジェクトに参画したときによくやる手法の1つだと思うので賛成。 例えば転職して今日からAチームに配属されました、コードはここで環境はこれで…とその日のうちに開発できる状態になったと仮定する。 その状態でまずなにをするか?明確に事前の支持がある場合はそれに従うけどもそうでなければ自分ができそうだと思うissueを拾って直してしまうかな。

これには2つ良いと思ってる面がある。

1つ、時間的制約があって後回しになっている軽微なバグを直すことでどう動いているのか確認できる 2つ、入ったばかりのチームに貢献したという自信がつく 3つ、自分という存在のプレゼンスを強調できる

2つといったな、あれは嘘だ。3つだったわ、めんご。

なので「テストから入る」自体には賛成という立場です。

違和感ポイント 「果たしてテスターから始めるのが正しいのか?」

なるべく易しい案件から始めて、潰れずにゆっくり成長してほしい

これは多分未経験者を採用するうえでメンターや上司、会社として誰もがそう考えることだと思う。 反面きちんとこのコンテクストが共有されるなら別にテスターでなくてもいいのかなと思う。

フィヨルドブートキャンプを主催されている方のブログかなにかで「プログラミングのオンライン教室に通うだけでは会社の戦力にならない。では戦力とはなにか?どんなに簡単なissueであったとしても独力で解決できることだと私達は考える。」みたいな話があっておおー!なるほど!ってぼくは思ったんだけどそうすると↑の考え方は「イシューからはじめよ」でいうところの「犬の道」のように感じる。

確かに辞めにくくはなるかもしれない、生存確率は上がるかもしれない。 でもIT未経験者がわざわざ未経験であるというハンディキャップを押してITの扉を叩いているのは「何かを創りたい」という強烈な創造的な思いからだろう。

そこにイメージと違うテスターという仕事をあてがったとする。

ぼくなら「プログラマとしてものを作る仕事につきたいと考えていたのに雑用をさせられている」と感じてしまうのではないかなと思う。 結果としてテスターのことを誰でもできる些末な雑事と認識してしまう可能性まであると考えるとそれはすごく危険な賭けに思えてくる。 もしここでテストのことを軽視してしまうとそのあとは地獄しか待っていないだろう、恐ろしい。

このブログでは特定の状態にフォーカスしていないのでこういう書き方なんだろうけども自分がメンターだったとしたらまず「どういうキャリアを目指していきたいのか」「何故そのキャリアを目指すのか」「ぼくが協力できることはなにか」あたりを聞いたり確認したりすると思う。 その上で「じゃああなたはテスターをやってみるのがいいですね」となったら進めるかもしれない。

でも多分IT未経験者がいきなりそんなことになるか?というと最初はそうではなく「ものづくりに携わりたいです!」とかもっとふわっとした内容だと思う。 そこにいきなり「じゃあテスターやろうか」っていったら最初のやる気を挫く可能性があるとぼくは思って逆にそっちのほうが怖いなと感じた。

つまり何故テスターをやるのか?のコンテクストが重要できちんとその情報が共有されていない場合非常に怖いことになると思うのが違和感としてあります。

多分やりたいこととしては「やれることの実績を積む」「プログラミングのワークフローを知る」あたりを学んでほしいんだろうけどその手段としてテスターをする、は少し的はずれなように感じた。 別にテスターでなくてもそれらは習得可能かなと思う。テストから始めるの自体を否定したいわけではないが専任するほどのことかな?そんなに人的リソース余ってるの?って気持ちになった。

「じゃあお前やったらどうすんねん!」となるんだけどぼくなら細かいバグだけど優先順位の問題で後回しにしているもの、やれば一瞬で終わるんだけど後回しにしているものを担当して直してもらうかな。 あとはテストコードを書いてもらう、ここで重要なのはテスターではなく実際にテストのコードを書いてもらうということ。

いきなり1機能を実装してもらうとかはサービスがどう動いているのかわからない人がやりきれるとは思えない。

例えバグっても影響が軽微なものを担当してもらうか、最悪バグって壊れてもサービスに影響がないことをやってもらう。 そのほうが任された側も安心してコードを書けると思うし。

あとはいきなりissue渡すんじゃなくてペアプロで一緒のタスクをこなすとかデプロイを一緒にペアオペするあたりはするかな。

違和感ポイント 「もしかしてメンターがいない?」

文中だと先輩プログラマの話題がでるけどメンターのような存在がでてこなかったのが違和感として残った。 この問題の多くの部分はメンター側が適切なアドバイスやサポートができれば大部分解決できると思うものばかりだったのでいきなり「テスターからはじめよ」に飛躍しなくてもちゃんとメンターメンティーの関係と時間を持てばほぼほぼ解決するんじゃあないかな。 なんとなくだけどこのブログからは先輩プログラマの時間を使わせないようにするような臭いを感じていてそれをメンティー側に求めるのは違うでしょ?と感じた。

課題はメンティー側ではなくメンター側にあると思う。あるいはそのメンターを取り巻く環境か。

違和感ポイント 「テストって何度も言いましたがそんなに難しくないんですよ」

テストってプログラムがどう動かないといけないのか、どういう振る舞いを期待しているのか、そのための事前の条件はなにか?みたいなのがわかってないと書けない、試せないと思うので「難しくない」は明らかに偽だと思う。 ここでいうテストがいわゆる手動テスト、動作検証なんだろうと思うんだけどそれだって「なにをどうしたらこうなった」を伝えるというのは結構しんどい。

またテスターに求められる能力の一つに違和感と期待する動きがあると思うんだけどそのためにはこのシステムやサービスがどういう期待のもと動いていないといけないか?というのがわからないといけないとぼくは思う。 なのでここは少し誤解を生む表現をしていると思った。

違和感ポイント 「事情は分かった。でもテスターはスキップしたい。開発案件に入るにはどうしたら?」

これが一番気になるテーマかなと思います。でも敢えて言います。

自分で考えてください。

ここが最大にひっかかったところなんだけど

え?なんでいきなり突き放したの???ってめちゃくちゃ疑問。 気持ち的にはちゃぶ台返しされた気持ちでもうこの時点でぼくの評価は真逆になってしまった。

攻略wikiの手順通りにゲームをクリアしていく感覚は、テスト実施の次のステップであるテスト項目作りあたりからだんだん通用しなくなります。

これはその通りなんだけど前提条件としてIT未経験者なんだよね?だったらまずは「守破離」で真似るところから始めましょうとかそういう話をすべきでない? 多分ぼくはメンターよりな立場としてこのブログを読んでいてその観点からいうとこの結論は許容し難い。

正直それなら何も書かないでいたほうが良かったんじゃないかとすら思ってしまう。 考えさせたいというのはわかるんだけど、ターゲットはIT未経験者だよ? IT未経験者だったときにこんなことをもし言われたぼくならそれだけでマインドがブレイキングチェンジですよ。

まとめ

基本的にひっかかるというか違うんじゃね?って思うポイントはメンターメンティーの関係を作る、1on1する、OKRのような目的を考えるあたりでほぼほぼ解決すると思うしどちらかというIT未経験者の課題というより出題者側(先輩プログラマ、上司、会社)の課題だと感じた。

それをIT未経験者に自力で解決させようとするのが根本的な問題ではないかなと思う。

プログラマなら当然知ってるよね?でもぼくは知らんので振り返りしてみた

anopara.net

↑元ネタ。

この手の話は定期的にあがり、そしてだいたいGW前後に発生してそのたびに「あーこれぼく知らないな…」とかよく思ってたんだけどとりあえず「これ読んどけば頭の片隅にはある」レベルを目指すというめちゃくちゃ志の低いやっていきと今何を理解してるのか振り返りとして書き出して来年どうなってるか計測しようと思って書き出した。

あともしこのエントリをみて「これ読んどけ」みたいなのあれば教えてくれると助かります。 他にも海外版これ読んどけがあったのでそれもあわせて読んでおけばだいたいのところはカバーできるんじゃあないかという目論見です。

medium.freecodecamp.org

プログラマだったら当然知っててほしいと思う知識

データ構造

プログラミングコンテスト攻略のためのアルゴリズムとデータ構造

プログラミングコンテスト攻略のためのアルゴリズムとデータ構造

ブログなどでよく見かけるシリーズ。未読。 当たり前なんだけどデータ構造、だいたいアルゴリズムとセットで書籍として語られることが多いのでこれが一番いいというわけではないが以前なにかで紹介されていて気になって積読リストにいれたところで止まってる。

計算量(計算複雑性)

正直よくわからない。 専門学校で習った気はするんだが改めてこれを勉強し直そうと思ったときに必要な書籍ってなんだろう?ってなった。 数学とかCSあたりの書籍を当たればいいのだろうか?

おすすめあれば教えてください。

アルゴリズム

定本 Cプログラマのためのアルゴリズムとデータ構造 (SOFTBANK BOOKS)

定本 Cプログラマのためのアルゴリズムとデータ構造 (SOFTBANK BOOKS)

アルゴリズムと聞いて思い出す1冊なんだがよく紹介されているという覚え方で読んだこと無い。 最近よくアルゴリズム関連の書籍がいっぱい出ていたのでこれがいいというのが変わってそうな気もする。

数値計算

おすすめあれば教えてくださいシリーズ。

これは技術書というより数学的分野かなと思うので高校数学とかの教科書読めばいいかも?

グラフ理論

おすすめあれば教えてくださいシリーズ。

有向・無向グラフ、木、ループ、カット、彩色、結婚定理とかの基礎の理解

とあるので多分そういう名称だと知らずに認識している(Not理解)可能性がある。 グラフ理論、データ構造とかの亜種というかそういう話の流れで語られてそう。

理論計算機

おすすめあれば教えてくださいシリーズ。 正規表現に関しては使っているし列挙されたなかでは理解できる。 他は名前聞いたことあるレベルからそもそも知らないまで幅広すぎるので正規表現以外知らないといってしまっていいかも。

セキュリティ・暗号化

歴史的経緯とかどういう理屈で暗号化されているのか?などが非常にわかりやすかった。 専門職でないのでわからないけどぼくが暗号化で上げるとしたらこれが一番最初にあがる。

プログラミングパラダイム

それぞれのパラダイムには理由があるので1冊でざっくり知るのが難しそう。 Clean Architectureにそれぞれの歴史的経緯とか書かれていたのでニュアンスとしては1冊選ぶならそれかも?

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

並列・非同期処理の基礎

以前いた職場でJavaだし、古いけどめちゃくちゃいい本だよとおすすめされた本。未読。

できれば知っておいたほうが良いと思う知識

ソフトウェア工学

DDDの文脈だとこれらが定番なのかな。エリック・エヴァンスのほうは読んだ。実践ドメイン駆動設計は未読。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計 (Object Oriented SELECTION)

実践ドメイン駆動設計 (Object Oriented SELECTION)

DDDではないがユースケース駆動開発実践ガイドを以前ビブリオバトルで紹介されたのでいれるとしたらここかなと思って追加した。

ユースケース駆動開発実践ガイド

ユースケース駆動開発実践ガイド

最近読んだ本で良書だなと思ったのがClean Architecture。 ただ一部納得いってないのと飲み込みきれてない感じがすごくするのでまた再読する予定、一応読了済み。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

現代コンピュータの性能

正直詳しくないのでどれくらい知ってることが効果的なのか?とかよくわからない。 マルチコアとシングルコアによる違いとかはTechブログなどで「○○だと1コアしか使わないのでマルチコアを活かしきれない」みたいなのを呼んでるくらいのざっくりした認識でしかないのでなにか読んだらまとまった知識が手に入る…みたいなのあれば知りたい。

CPUの仕組み

CPUの創りかた

CPUの創りかた

古い本だけどこれがいいと聞いたことがある。 正直ハードウェア周りは疎いのでわからない。

OSの仕組み

30日でできる! OS自作入門

30日でできる! OS自作入門

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

両方とも読みたいとは思うもののなかなか読み出すきっかけがつかず積読になってる。 読んだ人の評価などをみてるとどちらも良さそうな雰囲気は感じる。

ネットワーク(7階層モデル, IP, TCP, UDP, HTTP, HTTPSなど)

マスタリングTCP/IP 入門編 第5版

マスタリングTCP/IP 入門編 第5版

昔そーだいとか言う人に雑に「なんかおすすめのこれ読んどけ!みたいな本あります?」って質問したら3冊くらいタイトルが返ってきた唯一未読な本。 未読なので当然読めてない、ごめんなさい。

セキュリティ

防ぎ方、というよりはどういう攻撃経路があってなんでそれが可能なのか?みたいなところっぽいので前述のセキュリティーとは多分違うコンテクストっぽいんだけどあってるかわからん。

あとは気になってるレベルだけどこの2冊が良さそう。

ハッキング・ラボのつくりかた 仮想環境におけるハッカー体験学習

ハッキング・ラボのつくりかた 仮想環境におけるハッカー体験学習

ハッカーの学校

ハッカーの学校

統計・データマイニング機械学習系の基礎知識

正直全くわからない。 ここ数年?機械学習系の書籍が大量出版されているせいでどれがいいとか悪いとかすら判断がつかない。

手元にあるのはこれだけ、これだって数学的知識の欠落が激しくてなかなか読み進められていない。

その他シリーズ

海外版これ読んどけシリーズにリストアップされてたけどどこに入れればいいのかわからなかったやつら。

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

Robert.C.MartinのCleanシリーズ。未読。 Clean Architectureが良書だったのでそのうち買って読もうと積読リストの上位に追加した。

Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler))

Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler))

去年?だかに英語で第2版が出て話題になったやつ。日本語版出たらそっちを買う予定なので当然未読。

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

これ読んどけと紹介されたが日本だと↓のほうがよく紹介されている気がする&Java言語で学ぶ〜のほうは購入済みなので読むならそっちかな。

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

明確にこっちのほうがいいとかあればコメントかブコメで指摘をお願いします。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

読む人によって感想が違うのが面白いが個人的にはそういう生き方はあっていいと思うがぼくにはあわなさそうという感想を抱いて途中で読むの辞めた。

The Effective Engineer: How to Leverage Your Efforts in Software Engineering to Make a Disproportionate and Meaningful Impact

The Effective Engineer: How to Leverage Your Efforts in Software Engineering to Make a Disproportionate and Meaningful Impact

完全に知らないやつ。 ちょっと興味があるんだけど英語だし、どうもプログラミングに関係するというよりはSoft Skillsっぽい雰囲気を感じているのでそうすると英語で読みきるのが難しそうだなと感じて尻込みしている。

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

購入はしたんだけどまだ未読。

まとめ

海外でも名著と呼ばれるものはさほど差がないのが面白いなと思ったのとCSを学んでおらず実践でそのばその場で知識のつまみ食いをしてきたのでやはり不足している知識が広範に渡っているのが見える化されたのが厳しい。

来年の今頃までにいくつかの書籍を読んで少なくとも「頭の片隅にはある」という状態にレベルアップしておきたい。

あと日本だと定番のパール本が海外だと上がっていなかったのが少し面白いというか不思議に思った。未読だけどいい書籍らしいといろんな人がいうので当然リストアップされているだろうと思ったらなくてビックリした。

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

追記分

みんなのコンピュータサイエンス

みんなのコンピュータサイエンス

目次見たかんじおっしゃる通り満遍なくフォローしてくれてそう。 ざっくり理解するのには良さげ。

更に追加情報をもらえたので追記。

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

詳解システムパフォーマンス、各社の輪読会とかで話題になりますね。ぼくが観測した範囲だとHatenaさんとかMisocaさんとか良さそうという気持ちはありつつあの厚みに心砕けそうです。

ザ・コーチ

ザ・コーチ

ザ・コーチ

読んだ。

blog.shibayu36.org

しばゆーさんが読んでいたレビューをみて面白そうだと思い購入…3年近く経過してしまったことが判明した、反省。 気になったときが読み時なのでこういうものはガガガッと勢いに任せてとりあえず目を通してしまったほうがいいなと思いました。

別の書籍などを優先していたらなかなか読まずにいた&Clean Architectureを読んだあとだったので口直しに軽いものが読みたいという気持ちもあってえいやっ!という感じで読み始めた。

ストーリー仕立てなのでさっと読めた、もっと早くに読んでいてもよかったかもしれない。 多分読んだ時間はメモ取りながらで3時間〜4時間くらい。Kindleの目安読書時間が2時間半くらいなのでまあそんなところかな、という感じがする。

期待していたのはコーチングとかの技術習得のためだったんだけどもしばゆーさんも書いているとおりコーチングという分野を全体的に学ぶ…ということにはあまり向いていなかった。 時間が立っていたので完全に忘れていたがある意味で先入観なく読めたのでそれはそれでよしという気持ちがある。

反面、目的や目標、ゴールなどの概念として知ってるけどもそれぞれがどういうものか?というのを再認識&無知の知を教えてくれるという意味においていい本だった。 登場人物が主にメンターとメンティーの立場なので自分がどちらの立場を想定しているのか?という立ち位置を変えて読んでみるとまた少し違った印象を持つかもしれないなと読んでいて感じた。

ぼくは今回メンティー的な立場で読んだけどもメンターとして読んだ場合彼にどうアドバイスするだろう?というのを考えている自分がいたし、メンター的な立場にたったときにこのように的確な「考えさせ、答えをみつけさせるよう自発的な行動を促す」助言が思いつかなかったのでまだまだ学ぶところがありそうだと感じた。

そういう意味では参考例として自分だったらこうする、ああするという題材にしやすいのかもしれない。

文中にも目標の達人という言葉が出てくるがまさしく主題として目標があり、それを如何にうまく達成するか? そのためにどういったことを考える、考えさせるとよいのか、という面の情報が強化された感じがした。

1on1などをする前にメンター、メンティー双方が読んでおくとなんのための目的で、目標なのか? 個人としての目標はどこでそこにどう会社の目標を重ねていくのか、みたいな話ができると1on1もより実りがあることにフォーカスできそうだなと読んでいて思った。

いくつかの項目で似た話を別の本で読んだなと感じたところがあった。

特に「死ぬまでに叶えたいドリームリスト100を作る」というのはエンジニアの知的生産術にも似た話が出ていた。 目標は違っても使うツールや手法が似通っているのが面白いと感じたがこれは目的の部分が重複しているからかもしれないなと読んだ後でメモをみながら思った。

個人的に印象に残っているのは「ゴールに向かうということは、今の自分より高みを目指すということです。それは、今の自分のままの力や心では、なし得ないことをしようとすることです」という一文があるんですが、ゴールを目指すということは否応なく変化しなくてはいけなくてそれだけでもすごくチャレンジングなことをしているのだなと改めて気づけたのが良かったですね。

成長し続けないといけないだと息苦しい面がでてしまうことがあるんですがゴールを目指していままさに変遷の最中にいるのだと自分の状況を置き換えると他者と比較したときに遅れていると感じる部分がすこし柔らかくなったように感じました。

個人的に期待した効果、という意味では力不足感が否めないなという印象ではあったのですがそれはそれとしていい言葉、心に勇気をくれる言葉が散りばめられているので悩んでいるときやうまくいかないなと落ち込んでいるときに読み直すことで心の中のワクワクを取り戻せそうな本だなと思います。

本来はこのあと続編を読むか、コーチング全体について書かれた書籍を読むかしたほうがいいんだと思うのですが少々思うところがあるので次はScrumBootCampを読んでいます。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

そのあとは技術書に戻る予定でClean Architectureをもう一度読み直すか、Java言語で学ぶデザインパターン入門を読む予定です。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

初めての転職における迷いと決断、そしてその後

#「迷い」と「決断」

りっすん×はてなブログ特別お題キャンペーン〜りっすんブログコンテスト2019「迷い」と「決断」〜 Sponsored by イーアイデム

はてなブログでは、「りっすん」と共同で特別お題キャンペーンを実施します。働き方や生き方にまつわる#「迷い」と「決断」をテーマに、記事を投稿してください。選考のもと、素敵なエントリーを書いた方には賞金20万円をプレゼント!

ってことだったんだけど迷いと決断かー。 自分の場合なんだろうか?と考えたときにまず最初に思い浮かんだのはなんといっても最初の転職だったのでその時感じていた迷いや葛藤、そしてどうやって決断したのか。 またその結果どうなったのか…を書くのがいいのかなと思った。

めちゃくちゃポエミーな文章を書いている自信があるのでもしかするとあとで消すかもしれない。

まとめ

初めての転職は不安が大きいです、ひょっとすると就活よりも不安という意味では大きいかもしれないです。 最近だとTwitter転職などという方法もあるみたいですが個人的にはまずそういった知見が豊富な人材エージェントや知人でごくごく最近転職をした人に相談するのが良いだろうと思います。 あるいはコミュニティーや勉強会、カンファレンスなどにいっているならそこで自分の悩みを吐露することで的確なアドバイスがもらえるかもしれません。

もらったアドバイスは一度どこかにメモしておく、いつでも目に見えるところに貼っておく、置いておくことが重要です。 ふと忙しくなり、目を背けたくなるときにそれらのメモをみることで自分の中の決断スイッチに火がつくかもしれません。

ですが決断とは燻っている火を大火にすることに似ていると思っていて自分のなかの不安や不満があるとき爆発する瞬間というのがあります。 その爆発する瞬間というのは常に外部からの刺激です。 いろんな方にあってください、いろんな方の考えに触れてください、いろんな方と話してください。

それがあなたの決断に火を灯し、なにかを変える行動につなげてくれるはずです。

迷い

最初の会社に働いていたときのぼくの状態を一言で表すとアルバイト社員ということになる。 正社員ちゃうやんけ!というツッコミどころ満載なのだけど一応説明しておくとこの会社の説明では試用期間中はアルバイト扱いになるという話だった。 3ヶ月の試用期間を終えると正社員待遇になるのでそれまでは我慢してほしいということだった。

当時は「そういうもんなのか?」と思っていた(いまは知らないけどその当時は求人で似たようなことが書かれたものが多かった)のでOKしてしまった。 そうOKしてしまったのだ。

で、専門学校2年目の秋頃だったと思うんだけど内定をもらったときに「すぐにアルバイト社員として働いてほしい」と打診される。 正直な気持ちとしては「なんのために新聞配達して学費稼いでると思ってんだよ。その金ドブにすてるようなこと出来るわけ無いじゃん!」とか思ってた。 ……んだけど「一緒の寮に住んでいた友人がOKを出している(あとはわかるな?)」と暗に告げられたも同然の圧力を受けて渋々OKすることになってしまった。

専門学校では一通りゲームに関する制作の知識として簡単な2Dグラフィック(いわゆるドット絵)を自分で作ったり、MIDIでゲームに使う音源を作成したり、当然プログラミングの勉強も行っていた。 ただその内容は多分いまのゲームの専門学校や情報系の大学、専門学校とは異なってると思うんだけどBASICだとかC/C++でコードを書いていた。 2年時の後半にJavaアセンブラをやるカリキュラムの予定だったんだけど上記の理由からぼくはそちらに参加できていない。 学校側も内定予定の企業へ有償インターンという体で出席扱いと同等の扱いをしてくれていたんだと思うがいまなら学校いってから数時間だけアルバイトする方法を選ぶと思う。

なお会社で扱ったのはいわゆるLAMP環境といわれるもので「Linux + Apache + PHP + MySQL」だった。 Apacheに関してはNginxのようなものと思ってもらえればいい。実際は違うけどここでは説明しない。

環境そのものは当時のWeb業界で広く使われている構成であり、あまり目新しさはなかったと思う。 ごくごく妥当な環境だった。

さてここまでが前段でここからが迷いポイントなのだけど迷いポイントはこの最初の会社で働いてからやめるまでの間に何度かある。

迷いポイント1: ここで働きたくないでござる

当時ゲーム業界は残業当たり前、残業代支給なくても当たり前。残業代でるとか甘えるな!みたいなことを公然と言う人がまあちらほらいた。 好きなことして給与もらってるんだからそんなの当たり前だろ!みたいなね。

当然アルバイト社員のぼくも残業代はなかった。 「もらえないんですか?」と聞いたことがあるんだけど「うちは日給制だから」と言われてそういうものなのか?と不満に思いつつもそれ以上追求しなかった。

ぼくの心境としてはあまり長居はしたくないがスキルアップしたといえるまでは我慢して働こう……と当時は考えていた。 いま考えると「めちゃくちゃ青いな!w」って鼻で笑ってしまうんだけど転職活動をしてもやっていけるだけの自信が当時はなかったんですよね。 あと趣味といえるゲーム業界ですら多少の我慢が出来ないのであれば社会で生活していく、働くというのが難しいのではないか?みたいな不安もかなり大きかったです。

やったことがないから杞憂なことを考えて結果として入社(実質的にはアルバイトとしてだけど)してしまいました。

他にも理由はいくつかあるんですが当時ぼくはコンシューマゲームが作りたかったんですがこの会社はかつて開発していたが入社時点ではすでに手を引いていたことが後に判明します。 その段階で頭の片隅に「辞める」というワードが生まれたんですが就活、やられたかたはだいたいわかると思うんですがめちゃくちゃしんどいですよね。 もう一度あの状態になりたくない、またお断りメールを受信したり決して裕福な財布事情でないのに面接いったり履歴書書いたり、写真取ったりのお金がボディーブローのようにじわじわ真綿で首を絞められるようなのは嫌だと安易に考えてしまう気持ちがわかるんじゃないでしょうか?

ぼくはそうなりました。 当時のぼくは学校(のちにゲーム会社)と新聞配達の2足のわらじを履いていて学費を賄い、かつ生活基盤の寮に住んでいる新聞配達をサボることがほぼ実質的にできないという強迫観念下にいました。 新聞配達というのはなかなか休みを取るスケジュール管理が難しくて、他のメンバーとすり合わせをしながら休むことになるんですが就活をすると「休み=就活」にしないとそもそも面接にいくことすらできないという状況になってしまうんですね。

これに大変苦労したのでぼくは迷いがありつつもこの会社に入社することになりました。

迷いポイント2: 働いても働いても生活が楽にならない

好きな仕事、好きなプログラミングをしてお金を稼げる。

これめちゃくちゃハッピーなのでは?!……と最初は思ったんですよねー。 勉強しながらお金が稼げて、しかもゲームが作れちゃう!最高じゃん!みたいな。

結論からいうとほぼ休み無し、休日出勤のオンパレード、なのに給与は実質固定給なので増えない。 めちゃくちゃ堪えました。 貧乏暇なしなんて言葉がありますがあれは心理ですね。

貧すれば鈍するという言葉もありますが、疲れてくると自虐的な方向に心がシフトしてしまい

「自分がこんなに苦労するのは実力が足りないからだ」 「正社員になればきっとこの苦労も一時のものだったと笑えるはずだ」

とか考えてました。 社畜的精神思考とでも言いたくなるような状態ですね。

お金って心の余裕を生む最高のツールなんですよ、明日の生活の心配をしなくていい。 最悪会社が潰れたってなんとかなるというのは非常に大きいんですが当時のぼくにはそれがなかったわけですね、ウケる。

当然このままでいいのだろうか?と悩むことになり、早く帰ったときなどは自宅でPC立ち上げてプログラムの勉強をしたり、通勤中に技術書を読んだりしていました。 元々の帰る時間が遅いので睡眠時間を削るしか無いのでよりフラフラになっていたことを覚えています。

そして約束の試用期間3ヶ月が終わりました。 直属の上司から呼び出しを受けたときのぼくの内心を言い表す言葉がないほど浮かれていました。

ところがその第一声は「きみを社員にすることはできません」というものでした。 理由としては「実力が規定達していない」「仕事中の態度に問題がある」「頑張りが足りない」といったものでした。

当時の睡眠時間は月の平均が3時間ほど、それも休日に死んだように昼まで寝てそれだったので「頑張りが足りない」と言われたことに大変ショックを受けました。 正直ショックすぎてはっきりと覚えていないところがあるんですが大体そのようなことを言われた覚えがあります。

ぼくとしては1日の決して長くない睡眠時間を更に削って自学にあて、そのうえ通勤中も眠い目をこすって技術書を読んでいるのに「頑張りが足りない」ってどういうこと?と悔しいのやら悲しいのやらつらいのやらわからない涙が滲みました。 ここでぼくの心はポッキリと折れてしまいます、南無〜。

迷いポイント3: やりたくない仕事が増える

プログラマとして自分が3流なのだと落ち込んだぼくはとりあえず目の前の仕事をこなすことがスキルアップにつながるだろうと考えました。 それはある面では正しかったのでそれなりに自身の成長を感じることができました。

暫くの間は立ちながら寝落ちするくらい眠気と仕事の板挟みになりつつも「いつか別の会社にヘッドハンティングされるくらいになってやろう!」と考えていました。

ところがどうやら会社の風向きが変わってきたようです。 直属の上司と一緒にクライアントのミーティングに参加するようになったときその異変の前兆があったのだとのちに気づきました。 このときのぼくの肩書は「アシスタントディレクター」というものです、ディレクションとかやってなかったんですけどね。

初めてのミーティングは参加しているひとがいう「このDBのレプリケーションが…」「サーバ構成のこの部分にボトルネックがあって…」と謎ワードが頻発しました。 議事録を取ることを事前に上司から依頼されていたぼくはとにかく聞こえる単語を羅列していくのですが議事録に書かなければいけない情報、書かなくていい情報などわかるわけもなくみんなが喋っている内容を全てメモしようとして結果半分ほどしか書き残せないという状態になりました。

最後にあまりに喋らず必死にメモ(当時ノートPCを持ってなくてペンと紙で頑張ってた)していたぼくにクライアントのリーダー格のかたが「なにかわからないところや困ったことはありませんか?」と聞いてくれたのですが間髪入れず「みなさんがなにいってるのか全くわからないです」と答えてしまいその帰り道めちゃくちゃ上司から叱責を受けました。

当時担当していたのがプログラムのみでMySQLがどういうものか、Linuxがどう動いているのか、Apacheとは何をするものなのかそもそもプロジェクトの全体構成がどうなっているのかを知らないのですからわかるわけがないんですが、上司いわく「クライアントの前でいうやつがあるか!」ということでした。

いやだって知らんもんは知らんし…、だったら行く前に事前に説明しろよ!と思うのもむべなるかな。

その後の作成した議事録も「意味が通じないことが多すぎる」と怒られが発生し、3時間くらいやり直しをさせられました。 ぶっちゃけ泣きたい気持ちで書いていたし、その後のメールの文章も推敲されて結局議事録とメールの本文書いただけで終電になっていたのを覚えています。 殺意ってこうして醸造されるんだなとぼんやり考えていたのを覚えています、だいぶ精神的にやばかった。

その後上司とミーティングに参加することを何度か行い、慣れてきたあたりで今後上司が行かず、ぼく一人で行くことになりました。 今後のやり取りの窓口もぼくになることが決定します。 この段階でまだ働きだして半年ほど、プロジェクトに関わるようになって4ヶ月ほどだったと思います。

結果、いままで書いていたプログラムの仕事は減らないがクライアントとのスケジュールややり取り、バグ報告やお問い合わせなどが降りかかり体感で1.8倍くらい仕事が増えたように思いました。 実際にはバグ修正は同僚が助けてくれたり、いくつかの新機能実装は上司がやったりしていたのでそこまで増えていたわけではないと思うんですが明らかに帰る時間が遅くなり、プログラムを書く時間が圧倒的に減りました。

このあとからユーザのバグ監視のためという理由で毎日2ch、いまでいうところのTwitterエゴサをさせられたんですがあれは精神が病むし、ハゲるかと思うくらいつらかったです。 絶対に、なにがなんでももう2度やりたくない。

決断

突然決断スイッチが核融合爆発する

そうして1年ほどアルバイト社員(!そう当時まだ社員ではなくアルバイト社員だったのだ。給与も増えないのに仕事と責任は増える、ふっしぎー!)で働き、仕事の半分をプログラミング、もう半分をディレクションと言うなの雑用行っていたところ全社員に対して通達がありました。

「今後プログラミング業務は徐々に減らし最終的にディレクションだけで売上を立てる」

要約するとそのような内容でした。 それを聞いてぼくは内心激怒します。

「2年間も新聞配達してプログラミングを学んだのにたった1年、実質期間としては半年ほどで捨てなければいけないのか!」 「それは果たしてゲームを作っているといえるのか?スキルアップのために今まで我慢してきたことはなんだったのか!」 「俺がやりたかった仕事はそんなことじゃない!」

そんなようなことを考えていましたね。 会社としては当時ベトナムへのオフショア開発が流行っていたこと、プログラミングの仕事よりもディレクションのほうが儲かること、実は自社で開発していることになっていたが実際には別会社に孫受け禁止の案件を開発させてそれなりに潤っていたなどなどの理由で決定したみたいです。 最後の理由は事実だけどめちゃくちゃダークな話しですし、当時これは駄目なのでは?と思いながらぼくも加担してしまった一員なので非常に下請けのかたには申し訳なく思っていました。

専門学校あがりのたかだか社会人1年目にプログラミング歴10年のベテランが「なんでスケジュール通りあがってこないんですか!」とか叱責しているのを想像してほしい。 無茶振りをして「俺たちはクライアントなんだから言え!」という上司の命令に従ったことを割といまでも後悔している。

とまれかくまれ、このときに「よし、この会社でスキルアップするのは不可能だ」と見切りをつけることになります。 そこからは転職活動を始めるまで早かったし、辞める意思を伝えるのも早かったですね。

本来は在職中に転職先をみつけるのがベストなんだと思うんですが毎日残業残業でとてもそのような時間を見つけられなかったので辞めてから転職活動をしようと決断しました。 会社に辞める意志を伝えると「契約社員に登用するので考え直してほしい」「このプロジェクトや次のプロジェクトが決まってるのに無責任ではないか!」「少なくともいまやってるプロジェクトがリリースされるまでは留まってほしい」などなど言われます。

ぼく自身も関わったプロジェクトの最後を見届けたかったということで最後の条件だけOKを出したんですがこの段階では1ヶ月後に退職予定、長くとも1ヶ月半の見込みということでした。

結論からいうと4ヶ月伸ばされた上に退職日に「お前!次のプロジェクト決まってるのに何辞めようとしてんだよ!」と言われてどうでもええわ!となってガラケーから上司と会社の電話番号、メールアドレスを着信拒否することになりました。

その後

退職するに際して当時社内で唯一尊敬できた先輩に「プログラミングしたいなら今はゲームよりもWeb業界のほうが書けるよ」とアドバイスをもらうことが出来ました。 実際にはそんなことはなかったと思うのですが当時ITバブルが弾けたものの今後もこの業界は伸びると見込まれて様々な会社が勃興していた時期だったので間口が広く当時のぼくのスキルでも受け入れてくれるところが多いのはWeb業界だったということだろうと思います。

この会社にいてよかったと思えたことは2つあって、1つがこの尊敬できる先輩から助言がもらえたこと。 もう1つがぼくよりもあとに入ってぼくよりも先に辞められたデザイナーのかたがぼくが好きだったゲームのクロノクロスでデザイナーのかたで当時の裏話を聞かせてくれたことです。 こういうのは流動性の高い業界ならではなのかもしれないですが、純粋に1ファンとして楽しかったです。

なお他はクソで褒める価値なしというお気持ちです。 直属の上司に至っては事前に聞いていたのか前述の全体告知の前に退職してクライアントの会社に就職してました。

殺してやろうかな?と考えたことを覚えていますし、いまもって恨みに思っています。 なーにが「ぼくが1度試用期間で落としたから本気で頑張ったでしょ?今の成長はあれがあったからだよ(笑)」じゃ!死ね!!!

二度と会いたくねえ。

閑話休題。 ともあれその助言に従い、Web業界に転職をします。

それまでは忙しすぎて実績として提出可能なものがなく、また当時いまのようなAWSVPSレンタルサーバの存在を知らなかったのでそういったものでアピールするというのが難しかったです。 ブログを書くのも当時はぼくのようなスキルレベルの低い人間が書いたものが読まれないならばまだいいが、間違っていて怒られが発生するのではないか?と戦々恐々してました。

いまなら怒られたら直せばいいかなと思えますし、なんならQiitaなどでコメントや編集リクエストが来るでしょ! 来ないなら読まれてないので別にどうでもいいな、と思えるくらいにはおじさんになれたなって気がします。

運良くその後はWeb2.0だ!スマートフォンだ!IoTだ!とWeb業界は変遷の激しい業界としていろいろなイベントが発生し、ぼく自身もいまだにプログラミングを書いておまんま食べられています。 いまのところプログラマを辞めないと生活できない、という空気は皆無でむしろプログラミング能力を伸ばさないと食いっぱぐれてしまうぞ!?みたいな危機感があります。 出来るところと出来ないところはきちんと見定めないといけないとは思いますが。

またエンジニアやプログラマな友人知人も増え、その縁で会社の訪問や面接、困ったときに相談できたりといまでは以前の状態というのが非常に閉鎖的な空間でのことだったのだなと感じています。

まとめ

この件からぼくが学んだことはどのような悩みを自分が抱えていても他人に伝えない限りは絶対に伝わらないということが1つ。 2つ目が予め退職するデッドラインを決めておくとよい…ということ。ぼくの場合であればスキルアップができなくなる、がそれに相当します。 3つ目、当時ぼくの状態の相談相手は比較的近しい状態の友人知人だけでした、これはあまり良くなかったなといまでは感じていていろいろな人と話すことでもっと早く成長するための場所が外の世界にはいっぱいあるのだと気づけたのではないか?と思います。

1つ前のブログでも書いていますが転職は基本やらなくていいならやらないほうがいいと思います。 ですがもしなにか不満や不安があるなら、まずは誰かに相談してみると本当にそれが必要なことかどうかわかる一助になるんじゃないかと思います。

不安と戦うためには何よりも実績や経験を積むのが一番効果的です。 まずはどれほど馬鹿らしいことであると思っていてもその実績を積み上げることから始めると決断をする最後の一手になるかもしれません。

完全SIer脱出マニュアル@同人誌版

booth.pm

購入だけしていて読めていなかった完全SIer脱出マニュアルを読了した。 近日中に書籍版が出るらしいのでいまから読むならこっちを読むほうがいいだろうと思う。

完全SIer脱出マニュアル

完全SIer脱出マニュアル

本著のメインは第3章からなのだが、初転職や就職活動中、あるいは来年くらいを目処に就職活動を開始しようとしている人にとっては第2章は非常に有益なのではなかろうかと思う。 第1章は何故ミスマッチが起きたのかなどの転職の動機の部分なのでそこは人それぞれあるだろうと思うし、さほど量があるわけではなかったのでさっと読むか、飛ばしてしまってもその後に問題はなさそう。

とはいえ同人誌なので元々ページ数でいうなら著者紹介も含めて90ページほどなので全部通しで読んでしまってもあまり時間はかからないと思う。

以下、まとまりのない感想。

概ね、就職や転職におけるよくある悩みなどをうまくまとめてあるなという印象が強かった。 反面、立ち位置や書籍の内容からどうやってもポジショントークな面がありそこを気にする人はいそうだなと感じた。 著者の役職が役職なのでどうしたってそういう印象を拭い去るのは難しいだろうと思うのでそこまで気にしなくてもいいかもしれない。

この本を読んだあとにふと、転職をしたいという動機や熱量はインプットで、それに対する行動の面接だったりブログやコードを書くのがアウトプット、入社の合否がフィードバックだと考えたときにいわゆる「辞める辞める詐欺」の人たちはインプットの量が少ないか、アウトプットに問題があって諦めているのかなという気がした。

「3.5 ステップ4: 転職活動を語れる実績を作る」は非常にいい話なので就活や転職を考えて、いま悩んでいるひとは一読しておくと今抱えている不安が少し解消できると思う。

転職活動、現職在職中にやるのがベターだと思うんだけど時間の調整大変だしみんなどうやりくりしてるの?って気持ちが昔からあってその辺の共有知があるなら教えてほしいなと思った。 あと著者であるガミさんが東京なのでそれを前提に書かれているとすごく感じる。いま地方で働いているのでこれを地方でそのまま展開するのは難しい点が何箇所かあってそういう意味でも地方で働くエンジニアの人に転職活動の効率の良い立ち回り…みたいなのを聞いてみたいなと思った。 東京だとシュッとあってシュッと解散ができるんだけど地方だとそもそも会社が点在してる感じだと思うので結構シュッとあうのが難しいんじゃないかなって思った。

転職理由にポジティブもネガティブもないんじゃない?と思うことが最近よくある。 本著では言い方を変えようとあったが転職理由はタダのエネルギーなので正負のどちらの値も取り得るし、そもそも転職しようとするだけの熱力が発生しているだけなのであんまりポジティブだとかネガティブとかを気にしすぎなくてもいいのかなと思った。

反面気をつけたほうがいいなと思うのはそこで働くチームメンバーに対する誹謗中傷はボク個人も聞いていて気持ちの良いものではないので就職という1つの目標設定においてマイナスになりえるなと思う。 個人的にはそこさえ気をつけていれば「ブラック企業なんで辞めました」も「給与安くて辞めました」もあんまり大差ないかなという気持ちがある。

とはいえ面接はバイアスの塊で極端な話し面接官が男性で面接者が女性だとそれだけで加点される可能性がある。 いいとは全く思わないのだがそういう面接官の機嫌が悪かった、という理由で落ちたとしてもぼくはあまり驚かない。 なのでまあそんなに気にしなくてもいいのかなと読んでいて感じた。

あとは本著の中身とは全く関係ないのだがTuring Complete FMの17回でゲストの川合史朗さんが「オーディションに100回落ちることを目標にする」というようなことを語ってらっしゃるのだけどその辺とかめちゃくちゃ心づもりとして参考になると思う。

turingcomplete.fm

blog.practical-scheme.net

年間100回落ちることを目指してる人を知っているけれど、それだけ頑張って落ちようと思ったら、そのうちいくつかは受かっちゃうわけ。

という話があって、面接とか転職とかってどういう理由で落ちたのかわからなくてそうするとどうしても自虐傾向に陥りがちなのでこういうつもりで最初からチャレンジしてるんだ!と思うとほんの少しのことなんだけど落ち込まなくて済むんじゃないかと思う。

100回落ちる前に何社からはオファーもらったし、ぼく全然イケるじゃん!みたいな。 これが100回も落ちてしまった、いくつかの会社からはオファーもらったけど希望したところじゃないし……みたいな思考になりがちなのでこの心づもり、かなり効くと思う。

とここまで転職しようぜ!みたいなこと書いてるし普段も転職しようぜ!って言ってるんですが、まあ転職しなくていいならそれに越したことはないと思っていて、ただ不満があってそれが解決できそうにないなら転職するしかないよねという気持ちです。 転職、それなりに時間と体力を使うのでやらないでいいならやらないほうがお得な気がする。

そうそう、転職活動するしないに関わらずぼくが以前働いていた会社の上司に教えてもらったのが「転職サービス(いまだとWantedlyとかForkwellとかGeekOutとか?)には登録してどういう人材が求められているのか、どういう技術が市場に不足しているのかを日頃からリサーチしておくといいぞ」と教えてもらった。

これは転職市場の調査も兼ねているふりをしながらガチで転職活動していてもバレにくいという利点があって、普段からみてると公言したりその目的を伝えていればまあまあ黙認されやすい。 社内のインターネットからGithubに繋げられないとかいう会社の場合は難しいかもしれないけどそういうところで働いたことがないのでわからない。

転職はやるぞ!って思ったときにはすでに赤信号くらいになっているので普段から「こんな会社があるんだなー」とか「自分はこういう福利厚生がある会社で入りたいな」とか考えているうちに自分が求める会社の共通点がみえてくるのでいざ鎌倉!ってなっても余計な会社をフィルタリングで弾くことができる。 こういうのは積み重ねによるものなのでまあ英語の単語覚えるみたいなつもりでさっと目を通すようにしておくことだけはオススメする。 結果、転職しなくてもちゃんと市場調査にはなってるので無駄にはならない。

書籍版はまだ読んでない&買ってないのだけど恐らく大幅加筆されたり、読みやすくなっていたりするだろうと思うのでもし興味があるなら手にとって読んでみるのもいいかなと思う。

特にまとめるつもりがない羅列でした。