年末なので振り返り

さっきまで書いてたけど消えたので諦め。
会社のPCを借りてるので、足りないものをあぶり出すために使ってるんだが、
反復入力されてうざい。ので、改めて書き直すのはやりたくない。
「足りないいものはあ」みたいなる。面倒くさいからあ直さあん。

引っ越して、救急車がうるさいってのと、トイレが遠くてだるい。
退職はまぁいいいのではあ。

トイレに人感センサーの電球つけたら良かった。
日々の生活を楽にしていく系は今後も買っていきたい。

ちょっと来年で達成医師帯OKRをいくつか考えてた。そのうち出す。

退職しました

去年くらいから辞める辞める言っていて、ようやく転職先が決まったので、
今年いっぱいで退職し、来年1月から別の所で働くことになりました。
ということで現職の振り返りということをしておく。
2017年9月からなので、2年4ヶ月間、元教育系のスタートアップで働いてました。

# 何をやっていたか

色々やっていたが、主にやってたものだけ列挙。

## バックエンド

入社1年くらいはRailsのバックエンドをやっていました。
もともとRailsの業務経験積んどきたいっていうことで入社したので。
社内で使う管理画面とか、教育系なので先生側の画面とかの回収が主だった。
大学生インターンの子と仕事することが多かったかな。
みんな優秀で、それに比べて大学生時代の俺は…みたいな気持ちになった。
エンジニアも優秀で、色々コードレビュー受けたり開発方針一緒に考えたりで勉強になった。

## Androidアプリ

2年目くらいはAndroidアプリのリプレース版開発。
Androidアプリのエンジニアが足りないが急いで開発しなければならない状態で、
ちょうど自分がバックエンドの方で手が空き始めていて、
前職でAndroidアプリ開発やっているので、やりますよと手を挙げた。
人数は2->3->1かな? スタートを切ったのはベテランの方で、その人の決めた開発方針でやってた。
そもそも前職でテストを書いてなかったのでInstrumentationテスト書いたりが結構キツかった。
最終的に一人で開発することになったが、CIとか整備できたりしたので良かった。

## 採用

3年目(といっても4ヶ月くらいだけど)、エンジニアが大量離職して、エンジニアがインフラと自分だけという状態になった。
自分が主導しないと誰も動いてくれないなと気づいて、採用活動に注力した。
このときすでに求職者として転職活動で喋りまくっていたので、
求人側としての面談/面接でも苦なく喋れた。
それに求職側として、聞かれた質問とかは覚えていたりしたので、
なぜそれを聞いたのか? 真意は? とか考えて求人側の面談/面接でも良さそうであれば取り入れた。
途中から優秀な総務とディレクターが入社してきてくれたので、
応募者との日程調整(他社に会議室を借りていて調整が死ぬほどめんどくさかった)や、
会社説明の資料、面談なんかをお願いできて、開発の仕事に戻ったりができるようになった。

# 辞めた理由

1年近く転職活動してると辞める理由とか色々あったしドンドン変化してた。
色々恨みつらみもあるが、ここでは割愛。ざっと列挙する。

- インパクト
    - あまりユーザは多くはないサービスがメイン
    - 人の役に立ってはいるが…
    - もっと社会にインパクトのある仕事をしたい
- 刺激
    - もっと色々なエンジニアと関わって刺激を受けたい
    - 人が大量離職しまくってそういう刺激がなくなった
- コンフォートゾーンから抜け出す
    - 刺激の話にも近い
    - 自分が一番低能な環境に身を置きたい
- 給料
    - もともと入ったときに前職からそんなには上がってない
    - 結構会社のためになることをやっていたつもりだし忙しかった
    - の割にあまり給料上がらんなーということで交渉とかやった
    - があまり上げてくれなかった
- 会社の立ち位置
    - これはあまり言えない

# 次何をするか

Androidアプリの開発。次のところもRailsだが、
Androidアプリエンジニアが1人なのと、
自分のAndroidアプリ開発の経験を評価されたというところが理由かな。
とりあえず軽快なスタートを切りたかったので、PCを入社前に借りに行ったが、
その時に期待値が上がり過ぎているように感じて、めちゃくちゃしんどい。
コンフォートゾーンの外に身を置くというのはこういうことなんだなと。
これは転職くらいしないと味わえない苦痛なので良い。

会社自体についていうと、またスタートアップなんだが、
めちゃくちゃ儲かってるなーという印象。
優秀なエンジニアも揃っていて、だからこそ辛いのはあるが。
サービス自体も、現職はあまり自分が使う系ではないが、次は自分でも使える系統。

# 最後に

開発で色々と経験することも出来たし、採用についても色々知る/考えることが出来てよかった。
何回も会社が引っ越したり、xxされたり、xxxxしたり、スタートアップはこういう感じかーという経験も良かった。
なので得るものはめちゃくちゃあったのでは。

それと採用でめちゃくちゃぜひ来てくださいとか喋っておきながら、
入社してみたらそいつが辞めるってことを知ったエンジニアの方には申し訳無さしか無い。

すでに何人かSESだったり社員だったりで優秀なエンジニアが入っているし、
もうちょっとあとになるが、もう何人かも入社が決まっていて、
少しのやりとりしか出来ていないが、優秀なエンジニアだと思えたので、
そこから離れてしまうのはもったいないなーという気持ちが少なからずある。
このエントリでは会社について説明していないし、離れることにはなってはいるが、
もし教育系に興味がある方はご連絡ください！今ならまだ繋ぐことはできるかも。

俺は会社をやめるぞージョジョー

次が決まったらやめると言い続けていたのが、次が決まらないので辞められない状態だったが、
ようやっと決まったので辞めます。次は来年1月からです。
ということで、次の会社の準備とか、今の会社の引き継ぎとかをやっていく！
テンカツ今年の2月くらいから本格的に動いていたはずだが、
まさかここまで伸びるとはと思ってなかった。長引いた理由は別記事で書く。
その間、なぜ会社を辞めるか、転職の目的(ゴール)は、みたいなところとかが変わまくって大変だった。
直近は忙しすぎて、精神的に疲れが酷かった。
が、辞めるとなってそのへんの仕事をガンガン周りに振りまくってる。
そうすると周りの人がすげー忙しそうにしていて申し訳ないと思いつつニンマリしてしまう。
半年くらい前から怪文書は用意してあるので、後で出すつもり。
が、ここも時間が経ちすぎてめちゃくちゃ書き直さなければという気持ちがあるので、後でやる。

とりあえず、キーボード変えたいなーという気持ちがあって、
HHKBいいんだけど、そろそろ分割キーボードがいいなーという気持ちがあり、
MD650Lがキー数的に良さげだったので、それを買ってみて使ってみてる。
なのでだらだらな長文なのは慣れるためというのがある。
現職には持っていっても微妙で、またしてもお引越しがあるそうなので荷物増やすのはなーという気持ち。
自作キーボードははんだ付けとか、絶対私のような不器用だと失敗するタイプのことはできないなーと思ってる。

次の会社ではandroidアプリエンジニアとしてやってくが、
せっかくなのでrails(バックエンド)の方もやっておきたい。
ktorも仕事で触ってみたんだが、一人でやってるとベターなやり方が分からなくて辛い。
ただ、現職で手を広げて仕事する辛さを思い知ってしまったので、
あまり手を広げたくない気持ちがあったりなかったり。
ただ次もスタートアップなので、望まなくても手を広げる必要はあるだろうなと思ってる。

副業は欲しいが、この辺はガンガン外で言っておかないと、なかなか難しいだろうなと思ってる。
これは今採用もやっていて、とりあえず業務委託で人を置いときたい！ってなったときに、
そういやあいつiOSできる、副業欲しいって言ってたなーと思って声を掛けにいったりしていて、
自分ができることと、副業やりたい、っていう意思を常にいっておく必要があるなというのに気づいた。
というわけで次の年はアウトプットを重視していきたい気持ちです。

clean architecture 達人に学ぶソフトウェアの構造と設計 を読んだ

- 思想の話
  - xx型プログラムとかは制限を設けているだけ
  - してもいいではなく、してはいけない
- OOPの利点(というより特徴)はポリモーフィズム
  - classA -> classBの関係
  - classBを変更したいだけなのにclassAを意識せざるを得ない
  - oopはinterfaceが使える!
  - classA -> interface <- classB
  - 依存関係を制御できる
- オープン・クローズド
  - 修正に対して閉じていて、追加に対して開いている
- コードの共通化の話
  - 異なるユースケースで同じ処理がある
  - コードを共通化しておくと、Bのユースケースで変更があるとAのユースケースで困ることがある
  - コードが同じように見えるだけで、本当に同じかどうかはわからない
- 不安定なモジュール(class)に対する依存をやめる
  - インターフェイスを作ってそれに依存する
    - classA -> classB(不安定)
    - classA -> interface(安定) <- classB(不安定)
- 循環依存しない
  - classA -> classB -> classC -> classA とか
- 不要なものには依存しない
  - 例 classA -> classB.methodA, classB.methodB
  - もしclassAはclassB.methodBを必要としていないならおかしい
  - これもinterfaceで解決
  - classA -> interface.methodAのみとか
- 修正したいものがまとまっていると良い
- classを変更するときに理由はひとつ
  - コンポーネントを変更する理由もひとつ
  - 単一責任
- 選択肢を残す、決定を遅らせる
  - 方針(ビジネスルール)を決める
  - 詳細(DI何使う? DB何使う?)は決めない
  - 決定を遅らせられれば色々試せるし情報も得られる
- レイヤー
  - 水平レイヤー
    - システム的な部分
    - DB, UI, ビジネスコード, ....
  - 垂直レイヤー
    - ユースケース
    - 注文追加, 注文削除, 編集, ....
- 水平レイヤーでも分割するが、垂直レイヤーでも分割
  - 注文追加のときに削除のコードに影響を与えない
- ユースケース
  - アクターで考える
- ユースケースで分割すると重複コード
  - 今「偶然」同じなだけ
  - まとめる必要は無い
- 重要なものとそれ以外で境界線を引く
  - ビジネスルールが最重要
  - DB, GUIはムシムシで構築できると「決定」を遅らせられる
- マイクロサービスだとかはアーキテクチャにおいて重要ではない
  - サービスとサービスの間に境界線があるわけではない
  - ビジネスルールは横断的
- テストがプロダクションコードを硬直化させてはならない
  - 1個の修正が1000個のテストを壊したら?
  - 誰も修正したがらない
- ハードウェアはすぐに時代遅れになる
  - ソフトウェアは長寿命
  - ハードウェアに依存する(ファームウェアを書いてしまう)とソフトウェアの寿命も決まる

例えばRailsで、Androidアプリで、ってのを実際的には難しいのではと思いながら読んでいた。
`rails new` して、MVCで書いていて、フレームワークに依存してないはずだから
hanamiにすぐに変えられるか、というとうーんとなる気がする。
Androidアプリのコードを書いてて、ハードウェアに依存しないように書いて、
じゃあこれをiOSアプリで書いてと言われたら、うーんとなる気がする。

今までの経験的に、そもそも詳細(ハードウェア、フレームワーク)は真っ先に決まってしまって、
その上で動くコードを書いていたからか感覚と違っている、ように感じる。
例えばrailsであれば、先に素のrubyで、まぁARくらいは使って書いて、
何のフレームワーク使おうか、railsでhanamiで、っていう気持ちに出来れば良いねという感じかな。
なのでビジネスルールのみをコードに落とし込む訓練をしておくと良いのだろうとは思った。

詳細が決定されるのが早い理由は、実際に動いているところを見せる必要があるからかなと。
プロダクトの初期段階だと、そもそも上位の方針が決まっていないので、
プロトタイプを出しまくって方針を固めるってのがアジャイルだとよくあるケースだと思う。
なのでリプレース期とかにはいい気はする。
別にビジネスルールだけコード化して、詳細は後回しすべきとは言っていないので、
普通に開発してく中にも適用することは可能だと思う。

とか書いてたら

- フレームワークと結婚するな

って言葉があった。

テンカツ！セカンドシーズン 2話

前回に引き続いて今回も、forkwellでも一応転職希望で設定しておくと結構来る。
こっちは12件くらい来てるけど、まぁ職歴とかもちゃんと書いてあるわけではないので、 実際に会わないと本当にマッチしているかは分からない。
大抵は興味ない業種なのでお断りしているので残念ではある。

今回は転職ドラフトに登録して、結構指名が来たので楽しい。
あと1日あるけど、滑り込みセーフをかます会社はまぁ無いでしょう。
全部で7件で、基本的にAndroidアプリエンジニアで募集かかってるのが多いかなという印象。

一応、現職でこの数字を見せつつ確認してみるけど、 期待できない感じなら転職かなぁというお気持ち。

正直ここに来て転職どうしようかなという気持ちになっていて、 今回リプレースしてる案件が、時間がなくてFIXMEが多いので それを直したい気持ちが多分にあったり、 多分年俸はかなり上げてくれるはずだけど、 具体的な数字を出してくれていないし、 そこから毎年どれだけ上がるかも不安な状態で ただ転職活動めんどくさいしなぁというのもあって悩ましい。

一応

転職意欲

是が非でも転職する

で登録してしまっていて、それで指名が来ているので 気になるところに話聞きにいくくらいはしていい気がするなぁという感じです。

おひっこし

引っ越しました。

19m^2 から 36m^2 です。

引っ越しが決まったのが11月末くらいで、そこからだらだらと動いてたが、 正直引っ越し完了するまでストレスが半端なかった。年末年始挟んでいるのが悪い。 決めてもう2,3週間くらいで終わらせるのが良いんだろうな。

いくらか物は捨てたがそれでも結構荷物があったので、 またここから捨てたり買い直したりをする必要がある。 というかケトルとか加湿器とか、大した金額じゃないし買い直したほうが良かっただろうな。

沖縄居た時はそこそこ広い部屋で、デッドスペースが気になって 狭い部屋で良いんじゃね?!って思って、安くて狭い部屋に行ったが、 狭いと模様替えとかもしづらくて、物をどかす、というのがしづらいというのは教訓だな。 今回引っ越すときも物を詰めたダンボールが邪魔で掃除が出来ないという状態になっていたし。

ダンボールに物を詰める時、何を入れたか書いてたけど、 優先順位のための番号もつけておいて、 0,1,2,3はすぐ開ける, それより大きいのは後で良い、 みたいな感じでやってたが、結構微妙だった。 多分詰めた順番とか、日付くらいが良いんじゃなかろうか。 ゲーム/CDとか、数あると意外に重いから小さめのダンボールに入れるべきだなって後で気付いた。

テレビを実家に投げたので、また新しく買い直したいがまぁ後で考えよう。 それとは別でディスプレイは欲しいので24~27インチくらいのゲーム用で欲しい。

荷物になるので捨てて来たが、普段MIYOSHIの無添加泡のボディソープ・ハンドソープを使っていて、 これは変な匂いが無く、肌が荒れる事ないし、泡切れも良いので最強なんだが 置いている店が少なくて、目の前にドラッグストアがあるけど、 そこにも無かったので仕方なくアマゾンで買いなおした。

旧居は両隣があって、若干音に気を使っていたが 今回は階に2部屋しか無いのでその辺り心配しなくて良いのが良い。

交通費が、ちゃんと支給されるが、会社の引っ越しも重なっているので、めちゃくちゃ面倒くさい。 一応会社から1ヶ月定期分が毎月出されているんだが、定期が若干ズレていて、1/9までだったので、

1. 1/10~1/15までは手出しで毎回往復400いくらかを出して、
2. 1/17_{2/18までは1ヶ月定期で買って、(会社としては1/17}1/31までの実費の交通費を支給)
3. 2/18~2/22の往路分までまた手出しで出して、(これをどうするのか謎)
4. 2/23からまた定期を買う? (多分会社としては2/22の帰り分から2/28までの実費の交通費を支給, その場合通常の1ヶ月定期分が同計算されるのか謎だが)
5. 3月から1ヶ月分定期分を支給

定期の払い戻しをググったけど、https://ssl.tokyometro.jp/support/faq_answer?lang=ja&faqno=OpenFAQ-000449 この書き方だと0ヶ月数日は1ヶ月への繰り上げなんじゃねーかなと。 それに手数料とかアホくさいなと思って手出しだったが、どうするのが最適解なのか全く分からん。 多分区間変更とかもあるんだろうけどなぁ。

今回の引っ越しの反省から得た教訓は

• 年末年始とか挟まない時期にしろ
• 内見のときにカーテンのためのサイズ図っとけ
• magicplan使って帰って配置考えろ
• 物はガンガン捨てろ
• 引っ越しは2回(2日)くらいに分けてやれ
• 引越し先決めたら出来る限り早く引っ越せ
• 前日にガス止めろ、1日風呂入らなくても平気
• 契約書は事前に送ってもらえ (面倒くさい客扱い・契約書書き直させられるかは謎)
• ネット回線がどうなってるか確認しろ
• ダンボールに入れた順番と日付つけろ