はじめに
はじめまして、Wallet Station 保守/SREチームの新田大河です。今年（2023年）春にインフキュリオンに新卒入社しました！
メンターをはじめとするチームのメンバーの方々の助けもあり、この頃は少しずつ業務になれてきました。
本記事では、配属されて3ヶ月でどのような経験をし、何を学んだかをまとめていきたいと思います。
インフキュリオンにエンジニアとして入社したら、どのようなことを経験できるのだろう？と疑問をお持ちの方へ少しでも助けになれば幸いです。
入社してから配属される前まで
新卒で入社すると、4月に１ヶ月間の研修があり、それが終わると5月から現場配属となります。
4月の研修時にやったことは詳しくは語りませんが、インフキュリオンのサービスについてや技術についての講習を受けたり、独学で設計などの技術書を読んだりしていました。この研修のおかげで、スムーズに現場配属できた気がしています。
3ヶ月でやったこと
研修を経て5月にSREチームに配属されるのですが、配属直後にもかかわらず早くも色々な経験ができ、充実した3ヶ月を過ごすことができました。以下、自分が3ヶ月で経験したことをまとめます。
- テストコードの処理速度改善のためのリファクタリング
- 取引履歴一覧を取得する機能の機能改善
- 顧客向けヒアリングシートの改善
- 現在の仕様で不要になっているカラムを削除するリファクタリング
- Wallet Stationのバージョンアップで追加される新機能の開発
- 管理画面リメイクチームの既存機能リメイク
- ドキュメントの整備・充実化
なお管理画面リメイクチームとは、ドメイン駆動設計を取り入れた新しいアーキテクチャに置き換えるプロジェクトを進めるチームです。私はSREチームのメンバーですが、管理画面リメイクチームの臨時要員として、既存機能リメイクのタスクも経験させてもらいました。
※アーキテクチャの置き換えを行うことになった詳しい経緯については、以下の記事に詳しく書かれていますので、もしよろしければご覧ください。
学んだこと
3ヶ月で色々な経験をさせてもらい、多くのことを学びました。全て書くと長くなってしまうので、ここでは学んだことの中で特に重要だなと思った3つの学びを取り上げたいと思います。
1. 保守を意識した設計の大切さ
一つ目は保守を意識した設計の大切さです。
恥ずかしながら自分はインフキュリオンに入るまではどう作るかということのみを考えて設計をすればいいと思っていましたが、インフキュリオンでの研修や実際の仕事を通して、
「設計のゴールはリリースではなく保守・運用にあるということ」
つまり保守・運用時に素早く安全な機能追加が可能な状態を目指して設計を行うのが大切だと学びました。そして、良い設計をするための設計手法の一つにドメイン駆動設計があり、ドメイン駆動設計を導入すると保守性の高い開発ができることを学びました。
ドメイン駆動設計についてここでは詳しく取り上げることはしませんが、テックリードの浅田さんが運営しているブログで詳しく解説されているので、もしよろしければご覧ください。個人的にめちゃくちゃ参考になるなと思っています。 poppingcarp.com
今のWallet Stationでは、高い保守性を保つためにドメイン駆動設計を一部取り入れられており、実際にドメイン駆動設計が取り入れられている部分を改修した時には改修のしやすさと変更箇所の少なさに感動しました。
その一方で、Wallet Stationにはまだ設計が良くなく技術負債となっている箇所があります。そこを改修することがあったのですが、小さな改修なのに工数が嵩んでしまい、設計が良くないと時間的にも経済的にもロスが大きくなってしまうのだなと痛感しました。ただ、技術負債となっている箇所はSREチームの私たちが解消していければと思っています！
また、良い設計をするためには良い設計をするための技術力だけではなく、ビジネス側とも緊密にコミュニケーションをとって設計を進めるためのコミュニケーション力やチームのメンバに設計思想を「布教」するといったチームマネジメント力も必要であると感じ、エンジニアとしての総合力が問われるなと思いました。
2. 主体性を持って開発する
2つめに学んだことは、開発をする際は開発する目的を考え、意見がある場合は、役職の上下関係なくリーダーやマネージャーにも言うのが大切だと学びました。
主体性を持って開発に取り組む大切さを実感する前は、すでに作られた要件定義や設計が絶対正しいと信じ、それ通りに開発すればいいと思っていた節がありました。
受け身で開発してはダメだと気づいたのは、「Wallet Stationのバージョンアップで追加される新機能の開発」を担当した時です。 この開発では自分が詳細設計と実装を担当することになっていました。
すでに決定していた機能要件をほんの一部だけ修正すれば、新機能の役割にはほぼ影響を与えずシンプルに実装できたのですが、すでに決定されていた要件と基本設計を鵜呑みにして進めたため、不必要に複雑な実装をしてしまいました。
後ほどコードレビューの段階でテックリードから指摘を受け、機能要件をリーダーやマネージャーと見直し、実装も修正するという無駄な工数をかけてしまいました。
何のためにこの開発を行うのか？というのを考えて開発を進めていれば、機能要件の修正を提案でき、スムーズに開発を進められたのではないかと反省しました。
メンバーといえども、リーダーやマネージャーと同じ目線で、主体的に仕事をする大事さを実感することができました。
3. ドキュメントは育てるもの
3つ目は、ドキュメントは持続的に育てるべきものだということです。
自分が配属した頃は、SREチームでWallet Stationチームのドキュメントをもっと充実させる取り組みをしていました。その活動に私も参加し、マネージャーやチームリーダーから「ドキュメントを育てることの重要性」について学びました。
ドキュメントはあればあるほどいいものと思っていたのですが、作りまくるとメンテナンスできなくなってくるという問題もあるので、本当に必要なドキュメントを作り、それをきちんとメンテナンスしていくのが大事だと学びました。
今後身につけたいこと
今後は、ドメイン駆動設計を深く理解し、保守を容易にするような良い設計ができるようになりたいと思っています。今は、1メンバーとしてすでに設計思想が出来上がっているところに乗っかって改善開発や新規開発を進めていますが、早く設計思想を作る側に回れるようになりたいと思っています。
また、いま私は1人のエンジニアメンバーですが、エンジニアチーム全体を技術で引っ張るテックリード的なポジションで活躍できるような技術力をつけていきたいと思っています。
さいごに
2023年5月に現場に配属されて3ヶ月でやったことと学んだことをまとめてみました。幅広いことを経験でき、充実した3ヶ月を過ごせたと思います。その一方で、仕事の仕方や技術力などの面で自分に足りないことを自覚できた3ヶ月でした。今後は今よりもっと力をつけて、Wallet Stationをよりよくしていきたいと思っています。
ここまで読んでいただき、ありがとうございました！
