これまでの経歴

ゼストに入社する前は、2社でエンジニアとして働いていました。

新卒でSIerに入社し、AndroidやiOSのモバイルアプリ開発に携わりました。
その後、Web受託会社に転職し、大手スポーツブランドのECサイト開発でフロントエンドを担当しました。新規プロジェクトの立ち上げも経験し、技術選定からリリースまでの一連の工程を任せていただきました。この会社でWebエンジニアとして大きく成長できたと感じています。

転職した背景

受託開発を通して「プロダクト開発」への強い思いが芽生えたのがきっかけです。受託開発では、どうしても工数との兼ね合いで妥協するところが多く、プロダクトに対する当事者意識や熱量を十分に持つことができませんでした。

どのような事業に熱量を持って取り組めるか——そう考えた時に、真っ先に浮かんだのが医療や介護業界の分野でした。高齢化社会が進む中で、医療・介護従事者不足や現場の負担増加は深刻な課題です。ITの力でこれらの課題を解決したいと思っていたところ、面談・面接を重ねて「一番熱量を持って働ける」と感じたのがゼストでした。

ゼストは在宅医療・介護の課題解決に取り組んでおり、特に共感したのがゼストのミッションでもある「護りたい。その想いを護る。」です。従事者の皆さんは、患者さん・ご利用者さんの住み慣れた自宅で過ごしたいという想いを護る仕事をされています。そんな方々が本来向き合いたい仕事に集中できるよう、ゼストのプロダクトで支えたい——そう強く思い、入社を決めました！

この1年で感じたこと

チームの特徴

ゼストの開発チームは、CTOやテックリード経験者をはじめ、高い技術力を持つメンバーが集まっています。充実したドキュメントと整備されたコードのおかげで、入社後もスムーズに業務を始めることができました。

設計方針や実装方法についての議論も活発で、常に保守性を重視しているのを感じます。

例えば、私が所属しているフロントエンドチームでは、「共通化すべきか迷ったら共通化しない」という考えがあります。
これは、仕様を十分に理解しないまま共通化を行うと、将来的な仕様変更やUI変更に対応しにくくなり、保守性を損なう可能性があるためです。特に入社当時は、プロダクトのフルリニューアル中でプロダクト全体の仕様を把握するのが困難だったという背景もあり、チームで話し合った結果、安易に共通化しないと決まりました。実際の開発ではあえて、コピー＆ペーストで対応しているところがあります。

また、共通化する場合には、抽象化して共通化するということを意識しています。

私がドロワー（画面の右側から画面に重なるように表示されるUI）を実装していた時に、レビューでいただいたのが「必要な処理をまとめただけの共通化は良くない」というものでした。
ドロワーは既に別の種類のものが実装されていたので、同じ処理を切り出してひとつにまとめて共通化していました。ただ、そうなると抽象化ができておらず、機能が追加されるたびに肥大化してしまいます。そのため、「使う側の要求」で共通化するのではなく、「共通した概念」で共通化することを教えていただき、それぞれの責務で分割して肥大化を防ぐことができました。

前職でもUIが似ているという理由で安易に共通化してしまいがちだったので、長期的な保守性を見据えた設計の重要性を学ぶことができました。

この方針のおかげで、共通化した影響で実装がやりにくいといった問題や、肥大化して設計が歪んだコンポーネントができてしまうといったこともなく、柔軟に開発を進めることができています。

開発チームではその他にも、生成AI・AI Agentのdevin活用、Findy Team+導入による開発生産性の改善など、新しい取り組みにも力を入れています！