少しだけ新卒(２年目）を振り返る猫
この記事は マネーフォワードアドベントカレンダー2021 の4日目の記事です。昨日は @QUANON さんで、「部分和問題を動的計画法で解く」でした。
自己紹介
マネーフォワードでエンジニアをしています、たばです。2020年の春に新卒入社して、現在2年目になります。普段は業務で Rails を書いており、好んで使用するエディタは Vim です。最近都民から県民になりました。
この記事では前回のアドベントカレンダー同様に、少しだけ1年を振り返ろうと思います。
2021年のサマリ
・クラウド勤怠で一括承認機能の開発（2021.1 ~ 2021.2）
・クラウド給与で社会保険連携機能の開発（2021.2 ~ 2021.5）
・クラウド勤怠で有給休暇管理簿の検索項目機能拡充（2021.5 ~ 2021.8）
・クラウド給与で技術的負債の解消に向けた調査（2021.9 ~ 現在）
クラウド勤怠で一括承認機能の開発(2021.1 ~ 2021.2)
日々膨大な量のワークフローを承認している担当者の声をきっかけに開発がスタート。
実際には2020年10月頃から調査・WBS作成を進めていて、当初は Web 画面のみの改修予定でしたが、仕様のブラッシュアップを重ね、モバイル画面にも対応することを決めました。
モバイルのデザインを検討するにあたって、1月はデザイナーとプロダクトマネージャーとほぼ毎日議論を重ねていたのがとても思い出に残っている。このタイミングで改修したモバイルの受信ワークフローの画面のデザイン、体験含め、実は一番気に入っています。
大量のワークフローを承認する際、同期処理で作るとものによってはページの応答に時間がかかってしまい体験が悪いので、処理は非同期に寄せました。
そこで初めて Rails で非同期処理のロジックを書きました。
クラウド勤怠は立ち上げメンバーが綺麗に開発基盤を整えてくれたこと、先輩エンジニアの十分なサポートもあり、実装もスムーズに書き切ることが出来ました。
Rails で非同期処理をどう書くか、並行で処理しているジョブの進捗を見つつフロント側で rails-ujs / stimulus を利用しユーザーへのメッセージを上手いこと描画するにはどうすればいいのかなど、このプロジェクトを通して様々な学びが得られました。
一括承認機能についてはこちらを参照下さい。
クラウド給与でクラウド社保連携機能の開発（2021.2 ~ 2021.5）
当初から勤怠のプロダクトマネージャーにやりたいことある？と聞かれると
「プロダクト横断のタスクをやりたいです！」
と意思表示をしていたのが功を奏し、給与チームでヘルプが欲しいとなったタイミングでアサインいただき開発スタート。
元々給与に存在していた社会保険手続きをするための帳票作成周りの機能がスピンアウトしてできたのがクラウド社会保険で、その連携機能を開発。
初めての給与ドメインの開発で勤怠とは必要な知識が大きく異なる為、関わる部分の業務フローを理解するために社労士試験の参考書を読んだりしたのを覚えています。
社内用ライブラリの作成や API の開発、外部の API からデータを取り込み、クラウド給与側にそれを反映させたりと、一括承認機能の頃に取り組んだ内容とはまた別の実装を経験させていただきました。
実は以前にこの期間のお話を記事にしているので、よければそちらをご覧ください。
クラウド社会保険との連携機能である標準報酬月額の取り込み機能に関してはこちらをご覧ください。
クラウド勤怠で有給休暇管理簿の検索機能拡充 （2021.5 ~ 2021.8)
クラウド勤怠の有給休暇管理簿のページでは、有給休暇の取得・消費状況・消費義務が課せられている従業員は誰かなどが一覧で見れるようになっています。
しかしながら絞り込みのための項目が少ないために、結局絞り込みを手元で行ってしまっているという担当者の声をきっかけに開発がスタート。
チームの開発体制移行に伴いスクラムが導入されることが決まり、個人のタスクではなくチームとしてのタスクと捉えるようになりました。
そのため元々一人でやろうとしていたタスクを他メンバーに分散させつつ進捗を管理しながら開発を進めていました。
同時並行で、Github の issue を使って各メンバーが 1週間ごとにタスク管理をしていることに煩わしさ・他の Issue の見通しが悪くなる等の理由から Asana をチームに導入するプロジェクトも担当していました。
このプロジェクトにはデザイナーと同期のエンジニアの3名で進めており、夜遅くまで Asana を使った運用の仕方について議論したことを覚えています。
導入から 1ヶ月程度で給与チームへ異動するタイミングが来てしまったので、 Asana に切り替えて見て感じたのは他メンバーの持っているタスクとその優先度、チームがどれだけタスクを抱えているのかなどが一見して分かるようになった、くらいの感想しか持てていません。
一方で、クラウド勤怠のチームにスクラムが導入されることになった背景や、その振り返りに関しては、クラウド勤怠チームの katuo さんが以前記事を書いてくださっているので、よければこちらもご覧ください。
有給休暇管理簿の検索機能拡充に関してはこちらをご覧ください。
クラウド給与で技術的負債の解消に向けた調査（2021.9 ~ 現在）
ある日、リーダー陣が Slack で、クラウド給与の技術的負債の解消 PJ をやってみたい人いないかなぁとボヤいているのを見かけました。
滅多に経験できない中規模以上の負債解消タスクで、自分自身エンジニアとして成長できる良い機会だと思い、手を挙げたことがきっかけで給与チームに異動が決まり、プロジェクトがスタート。
各サービスが参照している一つの巨大データベースへの直接参照及び Rails Engine を用いて作成された共用ライブラリの利用を止めることを目標として進めています。
具体的には、
・どの機能を
・どのモデルを
・どのテーブルを
・どのタイミングで
・どの様な依存関係があるかを把握しつつ
・誰が剥がしていくのか
・作業をすすめるに当たって誰にコミュニケーション取る必要があるのか
・ユーザーにお知らせを流す必要があるのか
などの沢山有る変数を考慮しながら検討を進めている最中です。
ユーザー固有のテーブルや、事業者ごとのテーブル等でコールバックが無限に存在しており、継承、メソッドのオーバーライドなどを経て自分が欲しい情報を追うのに一苦労といったところですが、お陰で Rails ではよく使われている ActiveSupport::Concern 周りの使い方を始め、 Ruby の知らなかったメソッドの使い方を知ることが出来ています。
当社の抱える技術的負債の詳しい内容に関して、良ければこちらをご覧ください。
まとめ
というわけで去年同様、少しだけ 新卒（2年目）を振り返ってみました。
5月までは開発業務のみを主としていましたが、6月辺りからはチームにおけるタスクマジメントの方針に意見を出したりと、開発とは別軸の行動ができていたように思います。
意見を真っ向から否定せず、一緒になって対策を考えてくれたチームメンバーや、僕の「やってみたい」「挑戦したい」という声をいつも拾い上げてくださり、成長の機会を与えてくれた上長には感謝の気持ちで一杯です。
社員のチャレンジングな意思表示を尊重していて、いつも背中を後押ししてくれているこの会社にも感謝です。今後も期待に応えられるよう、何よりユーザーのバックオフィス業務の圧倒的効率化を目指して、尽力していきたいと思います。
明日のマネーフォワードアドベントカレンダー🎄 5日目は TONY さんです。ではお楽しみに〜〜〜！！
この記事が気に入ったらサポートをしてみませんか？