スターフェスティバルに転職して1年経った

転職して1年が経過した。(正確には 1年と2ヶ月経ってる(遅筆・・) )

例によって在籍振り返りブログを書いていこう。

ちなみに前回の振り返りブログはこちら。

www.ikkitang1211.site

同じようにGoodポイント、Moreポイントの2軸でざっくり振り返っていくぞいっ。

この半年の概要

前回ブログを書いたのは 9月で、それから半年が経っている。

前回のブログから一番変わった所としては、第二子が生まれた事。

第二子、本当かわいい。それと同時に第一子の成長ぶりが垣間見えてそれも相乗して子供たちが本当に愛おしくてかわいい気持ちにあふれてくる。

それはそれとして、第二子が生まれた事で親としてのCPU稼働率みたいなのが大きく変わったな〜と感じてる。ラウンドロビンで2人で1人を見ていた第一子の時と違って 第一子を妻が見てる時は 自分は第二子を見てて、妻が第二子を見てる時は自分は第一子を見てる。

隙間時間が無くなってたり、余裕が失われてると自覚する日が本当に増えたし、育児は「尊いが大変」というのを日々実感する。
※ 子どもたちは本当にかわいい

そういったライフサイクルの中で、自身の成長という所に目を向けると...自分自身がそもそも 質を量によってカバーしてきたタイプのエンジニアで、 量がこなせない という課題が新たに見つかってきたこの半年だった。

Goodポイント振り返り

そんな中でGoodポイントとしては以下。

  • 社内のプロダクトで採用する技術に対して、社内で勉強会を開催してキャッチアップをすすめる事ができた
  • 社内で半年以上に渡って開催されてきた輪読会で学んだ事を元にコードの書き方をより深める事ができた
  • フルリモートワークで喋れなくなった弊害から少しずつ回復してきた

新規技術のキャッチアップ

自分が所属しているスターフェスティバル株式会社では現在、以下を実現する為のプロダクトが立ち上がっていて自分はそこに所属している。

それが「スタフェスの事業内にある全データを把握できる状態にしたいから」。以前までは、サービスごとで取得できるデータが散らばっている状態だったんですよね。例えば、注文状況やお客さま情報、受発注の運用に関連する情報、配送パートナーに流れている情報など。このあたりをすべて把握できるようになれば、ビジネスサイドとしても食に対する要望がクリアになる。テクノロジーをより連動させていくためにも、ビジネス中心だったスタフェスに「プロダクトで問題解決する意識」をインストールしたいんですよね。

note.com

実際に何をやっているかという所については、表に出てる情報が現時点で確認出来なかったので詳細は割愛するけど、難しい言葉を使うと、各コンテキストで混在している情報について集約する所は集約して、各サービスの関心は各サービスで持つみたいなそういった大きなプロダクトを作ってる感じ。

その為に業務フローを見直したりしつつ、課題を技術で解決するみたいな事をやってる。

そういう意味でいうとオミカレ時のDBリファクタリングに近い。

www.ikkitang1211.site

さて技術面において、上記のプロダクトのアーキテクチャにも大きな課題がある。 従来のように API を通して フロントから コンテキストをいい感じにしたリクエストを送って・・みたいな所だと 依存が避けられずに 結局同じ課題を持ったプロダクトが誕生してしまう可能性がある。( AのAPIが出るのを Bのプロダクトでは待たないといけないとか )

その為、プロダクトとして、Apache Kafka を用いて イベントソーシングのアーキテクチャを採用している。

kafka.apache.org

Apache Kafka これまで全く携わった事がなかった技術で、どうしてもプライベートでキャッチアップするには限界があった。

そこで同じチームの人と一緒に月〜木曜日の朝8時30分〜9時30分を使ってApache Kafkaの勉強を深めた。

基本はこの書籍を用いていった。

座学的に知識を読みすすめる所は輪読会形式で本を読み進めて皆で質問しあって理解を深めていく形式で最後、GitHub Issue にアウトプットする、というスタイルで進めた。

コードの所は、全てローカルに直接環境を作る前提で書籍が書かれていたので、それを Docker を使って環境を整えられるようにした上で 皆でコードを書いたりしていった。

そのお陰で今大分理解が深まっていてよい。 プライベートの時間確保が難しくて量が確保出来ないのをチームの人たちに支えてもらって質に転じる事が出来た良い事案だった感じ。

そういえば、オミカレ社でDMSを採用した時ローカル開発環境を整えるのが出来ないって話をしてたけど、Apache Kafka + debezium を使うと同じような環境が再現出来る事をしれたのがよかった。

github.com

輪読会での学び

zenn.dev

約1年前に輪読会が発足して、積極的に参加させてもらった。

手元に常に 実践ドメイン駆動設計 通称 IDDD本がある状態なんだけど、それを元にコードレビューをしたりコードを書いたり チームの中でコードについて議論したり。。ここ数ヶ月、これまでより、 コードの書き方コードを書くまでの準備 というのが分かったような気がする。

これまでは、皆で一つのサービスを面倒見る事が多かったんだけど、コンテキストが違った状態で会議があって、この人が今どのコンテキストで喋ってるかを意識するようになったのも、多分輪読会に出ていたからなのかな、と思う。

「今、〇〇の視点で喋ってますよね?」みたいな質問をするのなんて、1年前の自分では想像つかなかった。w

まあ、まだまだ "良いコード" が書けているかというとそこは怪しいので継続の課題...!

フルリモートワークの弊害からの回復

前職から積み上げると約2年とかのレベルでフルリモートで開発をしている事になる。

自分だけかもしれないけど、テキストコミュニケーションが主流な中に身をおいてたので、フルリモートになってから 全然喋れなくなってしまった。

元々そんなに口がうまいわけでは無いんだけど、もっと悪化してしまったと感じていた。 非同期コミュニケーションの時間軸になれてしまったというのもあるんだろうけど、特に口頭でのコミュニケーションのときに 単語が出てこなかったり口が本当に回らない、って事があった(今もある)。 軽微の吃音症なのか?みたいな ...。悩んでた。

スタフェスではテキストコミュニケーションもあるけど、discord にチームが常駐してたり、他にも現在所属してるプロダクトの性質上複数のステークホルダーが居たりするのでそういった要因から口頭でのコミュニケーションをする機会が増えてきたってのもありそう。 喋らない日なんて無い。

それによって症状も少し回復傾向にあって、少しずつ喋れるようになってきた。

Moreポイント振り返り

  • 2022年やっていき、やってますか!?
  • 体調崩しすぎ

それぞれ振り返る。

2022年やっていき、やってますか!?

www.ikkitang1211.site

最初 2ヶ月ぐらいやってたり、プロダクトの1つのエピックについてフロント・バックエンド を全部やったりとか出来ててよかった。

そういう意味では一旦成果としては出つつあったんだけど、継続出来てない。

毎日フロントのコードを書いてたりとかしてたんだけどな。

サービスを書くとか言ってたのについて、敷居を高く持ちすぎってのが大いにありそう。 何かもっと雑に気楽にアウトプットしていけると良い感じがする〜〜〜。

体調崩しすぎ問題

睡眠を削ったりした結果、心身ともにぶっ壊れる事が多かった。 それもあって、フロントのコードを毎日書くのをやめてしまったり、とかもあった。 仕事終わりにコードを全く書かずに寝る事も増えた。

自分より優秀な天才達が日々コードを書いて研鑽を高めてるのに ... と思いつつも体調崩しては元も子もないので、 早く寝るのを継続する・・・!

総括

第二子が生まれた事によるライフスタイルの変化に対して、どうにか足掻いてきた 半年 〜 一年間 であった。

仕事の中で成長する事が出来た期間だったと感じる。 とてもいいチームに恵まれてるんだな、ってブログを書きながらより理解する事が出来た。

心身ともに体調に留意しながら、継続的にスキルアップを重ねていきたい