Akiyoshi Takazawa

1. 概要 マンション管理業務の1つとして、契約・解約などの駐車場関連の申請業務負荷が非常に高い。 DXによる業務の効率化・省力化を行うことで付加価値の高い業務に人的資源を集中させ、顧客視点に立ったサービス提供を促進するために本システムを開発することになった。 主な機能 ・駐車場の契約・解約申請 ・外部認証システムとのログイン連携 ・車庫証明書の発行処理 ・外部請求システムとの定期連携 1-1. チーム構成 PM：1名 バックエンド：7名 フロントエンド：3名 QA：2名 1-2. 担当した役割 開発リーダーとしてアサイン。 要件定義・設計・実装・テスト・レビューを対応しつつ、タスク割り振りやドキュメント整理を行った。 1-3. 技術スタック フロントエンド：React, Typescript, Inertia.js バックエンド：PHP/Laravel, データベース：MySQL, Redis インフラ：AWS(ECS・Fargate・ECR・SQS・SNS・S3・ElastiCash・etc...) その他：Backlog, Github, Notion, Slack, GithubActions, 2. 開発中の課題・発揮したバリュー 2-1-1. 概要 勤めている会社におけるアーキテクチャとしては、 Repositoryパターン がメインで導入されている。 ただ、複数のプロジェクトに携わる中でいくつか課題を感じたため、 本プロジェクトでは導入することに至った。 2-1-2. 課題 Repositoryパターンを下記のようにどのプロジェクトでも導入している。 Laravelを使っているため、参考としてはlaravelベース。あくまで例。 ``` interface AdminRepository { public function find(int $id); } class EloquentAdminRepository implements AdminRepository { public function find(int $id) { return Admin::find($id) } } ``` 利点としてはデータベースアクセスする際に使用するデータベースエンジンが変わったりした際でも変更しやすかったりするため、保守性が高いが、そもそもデータベースを変更する際には、ほとんどない。 そのため、あまりつかうメリットが感じられなくなった。 また、複数人で開発をしていると同じような役割を持つメソッドが増える傾向があり、 保守性が悪くなると感じた。 2-1-3. 解決策 Repositoryパターンを使わず、Laravelであれば便利なORMのEloquentがあるため、 Eloquentをメインで使用する。 Builderパターンを用い、メソッドを拡張することで使用しやすくするようにした。 また、特に恩恵を受けたのがユースケースに基づくActionクラスを作成することで、 業務ドメインと同様の実装を行うことができた。 そのため、改修する際に影響範囲がわかりやすくなり、開発スピードが高まった。 参考にした記事 https://domain-driven-design-laravel.com/ 2-2. バウンスメール発生時のメール通知 2-2-1. 機能概要 マンションに住んでいる方が申請を行った際にメール送信を申請者に対し行う。 その際に、何かしらが影響でバウンスが発生した際に、管理者の方へバウンス発生した旨をメール送信する。 2-2-2. 課題 今回のプロジェクトではAWS SES を用い、メール機能を実装している。 メールバウンス発生したかはSESから取得することで判断できるが、管理者へメール通知する内容にはデータベースから情報を取得し、メール内容に記載する必要があったためどのようにSESとアプリを連携させ、バウンス処理を対応するかの知見が足りなかった。 2-2-3. 課題に対して自身が発揮したバリュー及び成果 調査を行い、実現できる設計・検証を行った。 結果として、 SESで発生したバウンスはSNSを通じてSQSへメッセージを送ることにした。 サービス側から定期バッチにてSQSへポーリング処理を行い、メッセージがあれば管理者へメール送信するように開発を行った。 なお、どの申請者のどのメールがバウンスかを判断するために、 メールヘッダーに暗号化したIDを入れることで解決を図った。