転職して一ヶ月働いてみて(Rakuten -> WealthPark)

fallback
フジイ タカヒロ
3/Feb · 8 min read
fallback

はじめに

早いもので、転職して正式に1月から働き始めて、一ヶ月が経ちました。規模やビジネス、環境など、色々と違うことがあり、日々変化を体感する刺激的な毎日を過ごしています。とはいえ、少しずつ慣れていっている部分もあります。この一ヶ月で自分が感じたことを整理する意味でも、この一ヶ月働いて感じたことについてまとめます。
また、具体的な仕事内容に関連するものに関しては意図的に取り除いています。もし何か気になることなどがあれば、ランチかTwitterのDMなどでも下さい。お伝えできる範囲でお伝えします!
· · ·

前職と現職

話を進める前に、環境で働いているかという前提がないとイメージしずらいと思うので、簡単に。前職は楽天です。当サイトのarticlesにある記事を見ていただければ、どのような環境で仕事をしていたのかなんとなくイメージがつくと思います。比較的大きな規模の開発組織(200人程度)でUI周りの開発を中心に、Engineering Managerをしていました。現職はWealthPark株式会社です。あまり公開されている情報は多く無いですが、規模や事業内容につきまして、こちらの記事などに多少紹介されています。
では、転職して感じていることとそれに対する所感をまとめます。
· · ·

1.ひさしぶりの緊張感

これは、Comfort zone周りの話です。転職に伴う新たな期待や責任、実際のプロジェクトを始めた状態において、少なくとも現時点においては気持ち的な負荷はかかっています(ストレッチゾーン)。どちらかというと、自分でかけている部分もあります。また、現状において、これは仕事時間やプロジェクトのスケジュールなどではなく、プレッシャーや不安などによるものです。これは転職において期待していたことの一つではあるので、上手に付き合いながら自分の成長の最大化につなげていきたいと考えています。ただ、パニックゾーンに入らないようにすることについては、常に気をつけたいと思います。
· · ·

2.メンバーとの関係性の構築

僕は、前職で働いている期間が比較的長かったので(約10年)、特に後半はメンバーや先輩後輩、他部署の方々と関係や信頼に助けられた部分がたくさんありました。今は、もう一度そういったものを焦りすぎずに、築いていけたらと思っています。積み重ねが大切です。
次に今の会社で(自分にとっては色々感じたことがあった)特に前職とは違う点や、習慣などについて書いていきます。
· · ·

3.3時のコーヒータイム(散歩)

現職の好きな文化です。会社では、3時になるとコーヒー行く?というメッセージがSlackのエンジニアチャネルに流れ、みんなで近くのファミリーマートまで散歩し、コーヒーを買って話しながら帰ります。全員が絶対行くというわけでもなく、行きたい人はという感じです。またエンジニアの人数が増えてくると状況も変わるかもしれませんが、オンボーディングに非常に有効であると感じています。仕事を初めてすぐにはあまり直接的に関わることのないエンジニアもいますが、散歩を通じてどんなことやっているのか話をしたりすることができます。もちろん仕事とは関係がない話をすることも多々ありますが笑。規模的に問題がない間は続けていきたい文化だと思っています。また、エンジニア全員でなくとも、チームで行くのもよさそう。
Coffee Coffee
· · ·

4.QAによるオンボーディング

僕にとっては新鮮でした。Onboardingとして、入社時に色々な方から事業説明や部署の説明がありました。そして、およそどこの会社でも、プロダクト/プロダクト切りがあるよみたいな話をどなたかがされると思います。現職において、それはQAのリーダーの方が主導していました。(エンジニアの方も一緒に入っていましたが)。QAの責任や役割は組織によって違うとはあいますが、プロダクト、プロダクトの仕様、課題について一番理解している、ということを体現しているように感じました。
· · ·

5.QAがスクラムマスター

全てのプロジェクトで行われているわけでもないですし、人数やプロジェクトの内容、特徴があって行われた一つの例だとは思っています。また、背景としては、そのQAの方はCSPOを持っていて、きちんと知識があるということも前提条件としてはあります。QA, Scrum Masterそれぞれの責任範囲は違うので、頭を切り替えることが必要になります。が、これによって、QAが
  • 次スプリント時にスコープに含まれているリリースを明確に把握している
  • 開発途中に発生した問題や仕様変更をキャッチアップし、情報のアップデートが行いやすい
  • 開発初期フェーズからプロジェクトに当事者感を持つことができる
は実現されているように見えます。ただ、これらの実現方法がスクラムマスターを兼任するしかないのか、というわけではありません。場合よっては良くないコントロールをしてしまう場合もあるでしょうし、難しさもあります。
· · ·

7.組織の垂直型分業と水平分業 / Squadについて

Squadは2012年頃に、Spotifyが提唱した、大規模なアジャイル開発に対するアプローチです。
この内容に関しては、もう少し自分自身で体験した後でこれをテーマにした記事を書こうと思います。というほど、今の会社に入ってから色々考えたり悩んだりしている部分です。入社1ヶ月で感じていることなので、今はある程度大きな粒度の話になってしまいます。
現職は垂直型組織 / Squad色が前職と比べて格段に高いです。Squadはマトリクス型だとは思いますが、前職と比べて、垂直型で動くことがいずれにしても多いので、その点に特に自分は前職とのギャップがあります。また、現職の組織が多いわけではないので、1Squadの粒度は比較的小さいです。Squad毎に責任はかなり委譲されていて、各Squad判断で開発を進めます。それによって、リリース期間を現状の組織において短くできている、というのは確実にあると思います。
一方で、比較的小規模の人数でこれを行うと
  • 実装されるプロダクトのquality, productivityなどがアサインするエンジニアの思想や技術力にかなり依存する
  • 技術的負債は別途向き合う必要がでてくることが多い
  • 特定のメンバーがSquadをかなり跨ぐ
ということが発生します。そこで活躍するのがチャプターリード/TLだったりすると思うのですが、まだ試行錯誤している所です。
規模が違う所もありますが、メルペイの下記の記事は比較的共通のコンテキストがありそうです。
また、今後バックエンドがよりプラットフォーム化していくことによって、Squadとの噛み合わせが難しくなる部分もSquadの切り方によっては発生すると思っています。
· · ·

7.QCD

6とも関連しますが、QCD(qauality/cost/delivery)についてです。今の組織で適切な位置はどこか、ということを考えています。特に一番違うのはCostです。リソースという意味でのCostの有限が圧倒的に前職と比べて見えるので、その上での戦略の提示を求められている感覚はすごくあります。MVP(minimum viable product)との兼ね合いもとても大切です。現職でよくやり取りするPDMの方は、MVPに対する意識が高いので、その点は相談がしやすいです。ただ、最近行った勉強会でA1Aの佐々木さんが話されていた下記の点についても考える必要があると考えています。
前提として、まずMVPを考えるというフローは必ず必要ですが、その先、実際により多くの人に使ってもらえるようになるまでの道のりについても考える必要があります。特に前職よりもSaaS色が強いので、上のスライドで話されているような内容について考えることも多そうです。
· · ·

8.その他

他にも色々と感じていることもあるので、箇条書きで書いておきます。もし気になるものがあれば、直接聞いていただけたら幸いです。新しい環境になり、インプットすることが非常に多いですが、このように頭を整理しながら、自分の中に落とし込んでいきたいです。
  • 定例MTG
  • デイリーハドル
  • 評価
  • 採用
  • グローバルな環境
  • コードレビュー
  • 費用対効果
  • Visionを実現するには
  • マイクロサービス
  • レポートライン
  • SaaS
· · ·