転職活動をしてみて思ったこと

いい加減しつこい感じになっていそうですが・・・・ 「今しか書けない」類の話な気がしているので、色々を振り返ってみています、すみません。

前回が「選び方で意識したこと」だとするなら、こっちは「選ばれる側としてどうするか」みたいな部分。

  • 転職活動をしてみて思ったこと
    • 何かに取り組む際に「アウトプットできること」を意識していると良さそう
      • 発信回数
      • 経験ベースの発信
      • 日頃から「汎用化して流通させられないか」という観点を持つ
      • カラーが濃くなるような発信のチャンスを作った・使った
    • 話を聞いたり聞いてもらうの良かった
      • 身近な人に相談してみる
      • 色々な会社の話を聞いてみた
  • もっとよく出来たかも知れないこと
    • 時期について
  • 総論としては「普段やっていることにちょい足ししておく」という構え方

転職活動をしてみて思ったこと

実際にやってみて「よかったな」とか「もったいなかったかもな」とか思ったりした点など

何かに取り組む際に「アウトプットできること」を意識していると良さそう

「アウトプット」というのはなにか?という話になるが、ここでは「見る側にとってのフックになるような、差別化できるようなポイントを作ること」と定義してみる。

自分の場合で言えば、

  1. 打席に立つ回数・発信回数を増やした
  2. ネタがあれば経験ベースの発信もするようにした
  3. 日頃の業務内容を「汎用化して流通させられないか」というのを意識した
  4. カラーが濃くなるような発信のチャンスを作った・使った

みたいな分類になる。

続きを読む

転職に際して考えてたことなど整理

前回のエントリーが退職についてのエントリーだったので、こっちは「転職について」です。
自分向けにメモ

  • 新しい環境に求める事
    • 1. 一緒に働くメンバーや社内にいる人から技術的な刺激を得られる事
    • 2. プログラミングやエンジニアリングについての向上心があり、それをプロダクトに反映できる事
    • 3. 「空気」よりも本質的な議論や意見交換に集中できること
    • 4. 自分がちゃんと本気を出しながら仕事に取り組める事
  • 総論: いちエンジニアとしての成長実感の最大化

新しい環境に求める事

会社やその中の人に馴染んでしまう前に、「自分は何を求めているか」を明確にしておこうかな、と思う。
また、これらの軸を「不退転」とするために、ここに晒す。

退職を決めた時の感情や、転職活動中に助言を頂いたり自身の経験したことを通じて、「自分が何をしたいのか?」「何となくで生きている部分が、ともすれば自身の曖昧な部分を招いているのかも知れない」と漠然とした不安や絶望に気づいた。
それを嫌うために、自分自身で常に「何がしたいんだっけ」という問いに答えられるような状態にしておくのは、少しでも生き方に意義を与えるのに効果があるように感じる。

もちろん、今考えているよりも遥かに面白い事柄が出てくる可能性はあるし、動きの中で今は予想していない領域に興味を持つ可能性は大いにある。
そうは思いつつも、ある種の「なりたい自分」や「現状で物足りない事」があるからこそ、わざわざ環境を変えたわけで。そこが無かったら他の選択肢もあったし、そこが違えば別の転職先もあった。

ということで、私自身が希求している事を改めて明確にしておく。
逆に言えば、この「最低限」が満たされない、もしくは「違った」となれば、撤退もあり得るんだろうな〜というリストにもなり得るはず。

内容についてはアップデートして行き続けられると良い。

続きを読む

コネヒト株式会社を退職しました

9月いっぱいで、コネヒト株式会社を退職しました。 *1

2015年の4月からの4年半、いんたーねっと好きだな〜という人たちに囲まれながら過ごす事ができ、いちwebエンジニアとして色々な経験をさせていただき自分なりに貪り食うように成長機会というものを享受できたのかな、と思います。
ありがとうございました。

自分が入った時期というのは、ちょうどこの直後です。

thebridge.jp

資金調達を機にオープンした公開求人の、Wantedly応募者第1号だったと思います。

当時は、社員(経営層含む)は創業メンバーしかおらず、bizに関してはCEOしかいなかった状態。開発以外の多くを、"コンテンツチーム(当時)"と呼ばれるパートタイム従業員やインターン生の力に支えられていた組織でした。

前前職の退職時、先輩社員とお話をした際に「もっとヒリヒリと一丸となって仕事に取り組めるような環境に行きたい」と言ったら、「部活みたいな働き方がしたいってことだね」と表現された・・というエピソードがあり。当時は「別に、学生ノリで適当にやりたい訳じゃないが・・」と思ったりもしましたが、彼女は体育会系で競技をやっていた人なので、今思うとなかなかの重みがあるような気もします。
そして、新しく入ったコネヒトでは、ある程度その気持ちは叶えられたなぁという実感があります。自分と同じくらい働こうとする人間を、初めて見たので。

そんな時代から比べると、組織的にも(恐らく)外部から見た存在感的にも、随分と大きくなったな〜と感じます。

エンジニアとしては、CTO含めて3人目*2としてメンバーに加えてもらいました。
最初の数ヵ月でスロークエリ潰しまくったら「DBのインスタンスに余力が生まれてきたから、1つクラス下げた」って言われたのは良い思い出。

開発はサーバーサイド中心に、あとは内輪イベントの企画とかインハウスサービス開発とかSlack bot開発とかやってました。
在籍期間における技術的な内容の棚卸しについては、どっかでやりたいなと考えています。受け取ったものや見つけたものがたくさんあったので。また、2019年度に入ってからは「監視」の構築に軸足をおいていたので、その話はどっかで書きたい・・・

プロダクト文脈以外の事でもたくさんやったなーと思います。
コレのバックエンドとかコレとかは、社内文化の醸成に貢献できたはず〜・・と自負しております。開発合宿でv1を作成して、Slackが新APIを出す度にver-upをしたコレは、社内Slackで今も1番使われているIntegrationなんじゃないかな。
外に出せている事はほんの一部に過ぎませんが、働いている人が、社内で少しでも「楽しいな」とか「嬉しいな」って思える瞬間が増えるのは善だという気がします。
そういった事にアタックしやすい社風は良かった。
開発を伴わない事も好き勝手やらせてもらいました。「まるで東京カルチャーカルチャーにいるような、そんな偏愛に塗れた濃ゆい空間を生み出したいんや!!」と言って企画・主催・運営をした社内"裏"LT会(夜)は、今でも自分の中での最高傑作です。

エモ寄りの話は、今回はタッチしないで〜と思っているのですが、1つだけ触れると。

会社的な節目は、Supershipグループ入りやキュレーションメディアショック、課金サービスの開始、KDDI子会社化やら創業者の退任・・・など色々とあるのですが。
自分にとっては、一緒にサーバーサイドやってくれる人が増えたタイミングっていうのが、何だかんだで1番大きい出来事だったんじゃないかな?と、いま振り返ってみると思います。
id:fortkleid:dachi023 は、長く共に過ごしすぎて正直「それ以前」のことを覚えてないレベルなので、 id:supermannerid:itosho525 が入ってきてくれた事です。それが、やっと自分の中で「ちゃんとしたコードを書きたい」「自分なりに成長していかないとまずいな」という意識が明確に芽生え始めるきっかけとなりました。メインエディタをVimから移行したし。
それがあっての今だ、というのは間違いなくて。名指しで「あなたに追い付くことが目標だ」と言われたり、後のCTOとなる男に「今まで見た現場で1番コードがまとも」と褒められたのが凄い嬉しかった。誇りだな〜と思います。

この会社に対して、大変お世話になったし、その分の貢献もしたし、色々な人に迷惑をかけたなぁと思うし、その反面で他人の仕事のカバーも沢山したんじゃないかなぁと感じています。どうにか、トータルで見て「持ちつ持たれつだった」で±0付近で済めば、救われるのですが・・・
どうにも自分が「やってしまったこと」への罪悪感というのは消えないものなので。これは今後も恐らく呪いのように背負っていかなければならないんだろうな、と感じながらの転職になりました。

自分なりに、「この4年半という期間は何だったのか」という答えが出るのは、まだ暫く先だと思っています。
何にせよ、関わった人たちや自分に懸けてくれた人たちに、顔に泥を塗る事の無いよう堂々としていきたいです。そういうプレッシャーを受け取っています。

勝手ながら今後のコネヒトについては、エンジニアリング組織としての面白さは@itoshoが、組織全体としての面白さは@takumixiが、それぞれレベル上げていってくれるんじゃないかな〜と期待しながら去るものです。
あとCTOが「社内で1番の新しいモノ好き」である上に、元リードエンジニア(兼サーバーサイド兼iOSエンジニア兼Androidエンジニア・・)なメンバーが取締役も張っているので、技術的にも色々と仕掛けていくことでしょう。

10月15日より、BASE株式会社で働いています。
転職活動中の1コマ。(実質の最終面談で)「チームはどんな感じですか?」と聞いたら、by-nameで面子を教えてくれたのですが、返ってきたのが「ソーシャルで目立っている人(主観)」「前にカンファレンスでLTを見て明らかにやばかった人」「某OSSのchange listで昔からよく見る人」「CTO」「Tech lead」という、個別に認知している人orタイトル付きの人だったのには、鳥肌すら立ちました。
また、カジュアル面談でfshinさんが「どうせなら、エンジニアの社員が、5万とか10万とかのレンジじゃなくて1年後に50万円とか100万円とか給料を"上げるしかない"ような成果を出すように、方法を考えて、目標を置いたり成長を支援するのがマネジメントの仕事だと思う」と言っていたのも強烈でした。
ここに自分が名を連ねるのは非常にプレッシャーもあるのですが・・折角の「良いチャンス」「良いタイミング」が来たと思っているので、喰らい付いていって色々と学ばせて貰おうという気持ちです。とっとと1人前になれるように頑張る。

長々と大変お世話になりました。
今まで私の背負っていた、見えている部分での責任や見えていない部分での期待、身近で支援や応援をしてくれていた人たち、それらを全てリセットしてのゼロからのスタートです。
先にも触れましたが、今までお世話になった人たちに恥じぬ働きができるか?というプレッシャーは、非常に大きいものだと感じています。それを跳ね返せるように、頑張っていく所存です。

これから一緒に働かせていただく方々、どうぞよろしくお願いいたします。

ご挨拶おわり。

*1:何となく転職直後に晒したくなかったので、寝かせていたものをこのタイミングで出した次第

*2:自分と前後してデザイナが入ったけど、彼女も当時は「エンジニア」枠。他にもエンジニア職いたの知ってるし、ピボット前にも当然いたと思いますが、現コネヒトでいえば3人目・・って事でよいはず

GitHub がCI/CDを始めると聞いて

いやー、衝撃たるや。

とうことで、興奮気味に調べたことや感想のメモ。

先日のツイートBe one of the first to hear the latest on GitHub Actions. といっていたので「え!まだ、GitHub Actionsが進化する!?」とワクワクどきどきはしていたものの、そう来るとは〜〜〜

「これが何なのか」といえば、例えばクランチの記事など。

techcrunch.com

公式のエントリーが出てくるのが迅速なのも嬉しい

github.blog

&& public repoに対しても「Actions / CIが来るぞ」というのも、本当に待ち望んでいた事態でありまして、震える。

関連: GItHub Actionsを理解しよう! - 大好き!にちようび

実際どうなるのか?

残念ながら、まだ自分の環境では使えていないのですが。
例えばbootstrapは初期ローンチ組っぽい。(だってさ、こちらもまたpublic repoだぜ・・!)

なので、「実際に動いている様子」はここから見られる。

bootstrap/test.yml at master · twbs/bootstrap · GitHubで内容を定義しており、実際の結果は例えばこのコミットなど。

これらを比較してみて、「ジョブ(ステップ)が確かにそれぞれ実行・出力されているな」というイメージが掴めるのではないでしょうか。 f:id:o0h:20190809091716p:plain

移行はどうやるの?

諸々の制約はつくものの、マイグレーションプログラムが用意されています。
go製で、バイナリポンで動くのが嬉しい。数年前だったらシェルスクリプトだよねきっと。

help.github.com

これについては実際に手元で動かしてみたけど、たしかに「動いた」。
もともと自分で定義していた.workflowファイルが、なるほどこうなるのか〜と。

f:id:o0h:20190809094740p:plain

詳細な定義ファイルの書き方については、以下に仕様があります。

help.github.com

ざっくりいうと何なのか?

「GitHub CIについて」の公式資料がこちら。

help.github.com

ということで、 公式な説明は Core concepts for continuous integration with GitHub Actions を読んで見るのが近道だと思う。

大まかに言えば「Linux(Ubuntu) / Windows / Mac」のイメージや、あるいはコンテナベース(=GItHub Actions)で多様な処理を実行できる。そして、その処理の発火条件や前提条件(依存)の定義などを、柔軟に行える・・・!といったところか。 jobs.<job_id>.runs-onjobs.<job_id>.steps.usesを参照。

「GitHubのCI」だからこそできるような、例えば発火条件に「変更されたファイル(パス)の指定」があったり、「PRのアサイン状態」があったり。jobs.<job_id>.ifを参照。利用するサービス(DBとか)についても、Dockerのイメージを指定すれば組み込める。jobs.<job_id>.servicesを参照。

といった感じで、「どういった世界観なのか?」であれば「ジョブ > ステップの定義と、その発動条件やマトリックスのルールセットを定義する」という「ザ・CI」なのだけど*1。なのだけど、個人的には、「何をどこまでできるか?」という点で言えば「Workflow syntax for GitHub Actions」を読むだけでもかなりワクワクした!

いろいろな・・・本当に色々なことができちゃうな〜〜、と思う。 もちろん、プロダクションへの投入については、可用性もあることながらジョブの起動や並列実行の制約など「試してみないとなんとも言えない」部分は多い。それにしたって、現時点では最高に使ってみたいオモチャの1つなのは間違いない。。。!

はやく使ってみてぇ〜〜

*1:ActionsはVisualized Editorを目玉にしていた雰囲気もあったけど、どうするんだろうw

やったこと・書いたもの{2019,07}

会社ブログ

tech.connehito.com

tech.connehito.com

社内LT

OSS

github.com これの前段でissueも立ててみていた、cakeにissue立てるの初めて(だと思う) #13392 差分的に、このくらいならPR作っちゃったほうが早いよねーて思いつつ、「ずっと昔からあるクラスで(正直に言って)この違和感のあるコードが残っているのなんで?」っていう疑問があったので、議論があるのかなーという。
結果的にmarkstoryさんから「reasonable」と後押しをもらえたので、じゃあ書くね〜つってコードにした次第。

github.com

packagist.org ↑に書いた記事で紹介したやつ

勉強会・LT

中の人にTwitterでお声がけいただき参加。「Ops」っぽい人が多い空間で、新鮮だった!

その他