名称未設定のブログ

2019年12月29日日曜日

退職しました

去年くらいから辞める辞める言っていて、ようやく転職先が決まったので、
今年いっぱいで退職し、来年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だったり社員だったりで優秀なエンジニアが入っているし、
もうちょっとあとになるが、もう何人かも入社が決まっていて、
少しのやりとりしか出来ていないが、優秀なエンジニアだと思えたので、
そこから離れてしまうのはもったいないなーという気持ちが少なからずある。
このエントリでは会社について説明していないし、離れることにはなってはいるが、
もし教育系に興味がある方はご連絡ください！今ならまだ繋ぐことはできるかも。

2019年12月9日月曜日

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

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

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

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

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

2019年5月6日月曜日

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で、っていう気持ちに出来れば良いねという感じかな。
なのでビジネスルールのみをコードに落とし込む訓練をしておくと良いのだろうとは思った。

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

とか書いてたら

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

って言葉があった。

2019年1月29日火曜日

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

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

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

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

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

一応

転職意欲

是が非でも転職する

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

2019年1月17日木曜日

おひっこし

引っ越しました。

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

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

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

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

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

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

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

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

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

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

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

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

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

2018年12月31日月曜日

年末なので

今年どんだけ働いたか調べたかった。

✗ git log --numstat --pretty="%H" --author='iaia' --since=2018-01-01 --until=2018-12-31 --no-merges | awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d (+%d, -%d)\n", plus+minus, plus, minus)}'

コマンドの意味はわかってない。

Railsプロジェクト1
- 41730 (+29195, -12535)
Railsプロジェクト2
- 3660 (+2699, -961)
Androidプロジェクト1
- 479 (+473, -6)
Androidプロジェクト2
- 51385 (+35883, -15502)
staticなプロジェクト
- 84957 (+30280, -54677)

主な仕事はRailsプロジェクト1とAndroidプロジェクト2なので、約10万行か。
staticの方はなんでこんなにあるのかよくわからん。

テンカツは転職ドラフトでresume通ったので、1月入札が楽しみやな。
それを持ってとりあえず現職で給与交渉してみて、そんなもんかってなったら転職する方針で。

それと、今年はrubyとvimのイベントに参加したので、OSSに貢献したい感がある。
一応2個プルリク送ってマージされているけど、もっと頑張るか。
qiitaにも記事を書いた。https://qiita.com/iaia/items/a3348b466de1fc9e5ba6

今年は70kg切るようにするという目標があったわけですが、まぁちょっと無理かな。
これはまぁそろそろ頑張らないとという思い。

引っ越しは今年やるとか言ってたが、一応来月引っ越しなので許容範囲内。
転職するつもりなのでちょっとあれだけど。

2018年12月2日日曜日

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

辞める意思は伝えたので。今の仕事が3月には終わっているはずなので、3月末で辞めるかなくらいの考え。

元々今の会社に来たのは

ToCの自社サービスをやっている
Railsを触れる
希望すればAndroidも触れる
普通の一般的な開発スタイルができる

あたりが理由だった気がする。

で、なぜ辞めるか。

そもそももっと前に辞めるつもりだった
- 入ってみたら意外と経営がヤバイ状態だったので沈む前にやめよう
- 少なくとも1年の経験を得てからにしよう
- Androidアプリの開発手伝って！ -> (ユーザ操作があるアプリを作ってなかったので)ぜひともやりたい
- アプリリリースまで続けよう
それなりに実績・経験は積めた
- まだだけどアプリリリースとか
- もうどこの会社行ってもそれなりに働けるんじゃね？くらいの自信を持てたという意味
- この会社でやれることは一通り出来たという認識
仕事は増えてくが給料は据え置き
- Railsエンジニアでやってた時はそれなりに仕事やってた時は普通に満足だった
- Androidもやり始めの時は問題なかったが...
- 「最近Rails側のリソース足りないので手伝ってくれない?」のパターンが増えてきた
- 都合よく使われている感が否めない
ディレクター陣との考え方の違い
- あの仕事を早めにやらないと残りの仕事が出来ない -> issue作れてません -> ディレ陣で確認作業が... -> エンジニアの仕事ありませんのパターン
- 単純にディレ陣人数少ない割に仕事が集中しすぎていて忙しい
- とりあえず文句は言うだけ言うが管轄外のディレ陣の話でそれなりに思惑はあるし一理あるし...
- でもそれ1日で終わる仕事じゃない? というのにも安全策を巡らせて1ヶ月は掛けてる仕事もあるので、改善すべきだなと思う
子会社化
- 親会社の要求でシステムにアホな設計を入れないで欲しいとはお願いしていた
- 例えば「ウチが使うときには、XXXの機能は表示させるな(or ウチだけに表示しろ)」「UX悪くてもXXXを必ず表示させて訴訟リスクを減らす」とか
- 赤字なんだし、仕事やるからと上で言ったみたいなことをやらされる
- これ、文字化するのが難しいがどうしても自分にはやりたくない仕事
- これが多分言いたいことを書いてくれてると思う
この会社はどこを目指してるのか?
- これが割と重要な気がしている
- 子会社化して創業者がやめて...
- 会社としての理念が消えてしまった
- 新規事業立ち上げの話もあったが、辞める気だし特に案を出す理由ないし...
給料上げる上げない問題
- 創業者やめた時点で、新しい目標・理念、新しい評価基準の2点の話が持ち上がった
  - 独自に目標・理念を持って、ただの下請け企業にならないようにする
  - 評価基準を設けて達成度合いで給料を上げられるというモチベーションを生み出す
- この話が出る前ではそろそろ辞めようと思っていたが、この話が出て居続けても良いなと思えた
- 実際100万単位で給料上がりそうだった
- そういう期待を持たせられた状態で、突然のキャンセル
- 親会社と色々あったらしいが、私には「お前ら赤字だろなのに何言ってんの」というのが印象に残る
1on1の結果
- 給料上げる上げない問題があったあとに色々1on1が組まれた
- 確かに仕事の割に給料低いよねという相互認識
- でも親会社が給料にはうるさいので...という弱い立場
- 4月になったら上げられると言われても...
- 黒字に出来たら立場も変わってくる -> 従業員が弱い立場で我慢し続ける理由とは
もう辞めるからはいはい言っておくか状態になっている
- これは自分と会社どちらにも良くない

次の会社は自分たちで儲かっている企業が良いですね。転職ドラフトで引っかかるのを待ちたいが、何せレジュメがrejectされるので辛い...。こういう自分の評価って難しい。

登録: 投稿 (Atom)