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を入れることで解決を図った。

概要 法人企業向け ミーティング支援ツールの開発 主な機能 20階層構造を作成できるTODO機能 カレンダー機能(Google Calendar 連携機能付) 会議通知・タスク通知機能 担当 バックエンドエンジニアのメンバーとしてプロジェクトにアサイン。 リーダー フロント兼任 使用技術 フロントエンド：Vue3, Typescript バックエンド：PHP/Laravel8, インフラ：MySQL5.7, Redis, AWS ECS・S3, Docker, Redis 開発中の課題・工夫した点 ◯20階層構造を作成できるTODO機能 詳細 企業課題を細分化し、より具体的なTODOを出していく機能の開発を行なった。 各TODO には、進捗率が記載することができる。 進捗率は、上の階層に対しても反映され、一番上の階層では配下のTODOを合計した割合を計算する。 課題 ドラッグ&ドロップ にて階層移動ができるためアクセスが集中してしまうとDB処理が追いつかず、 複数人が操作してしまうと、反映処理が遅くなっていた。 工夫した点 DBをREAD /WRITE に分けることで、負荷分散を行いDBの負荷を下げる。 Queueを活用することで、非同期で処理するものと同期的に反映するものを分け、処理を行なった。 ◯カレンダー機能(Google Calendar 連携機能付) 詳細 アプリ側で作成したカレンダー機能とGoogle Calendar との相互連携機能の開発を行なった。 Google 側で操作してもアプリ側へ反映。アプリ側で操作してもGoogleへ反映される。 所属する企業全員をGoogle Calendar のようにサイドバーに表示を行い、 チェックマークを行うことで、カレンダー表示を行う。 加えて、1つのイベントに対してアジェンダという議事録が保存できる機能の開発を行なった。 また、商用利用する場合、 Google に対してOAuth申請を動画撮影を行い許可を得る必要があり、その申請対応を行なった。 課題 アプリ側で作成したイベント情報をGoogle Calendar 側へ反映するにあたり、 例えば、毎週水曜に行う定例といったようなデータを作成/更新/削除を行う場合の、 Google Calendar 側の仕様を細かく網羅する必要があった。 作成したGoogle Calendar のユニークなIDに対して、アプリ側のアジェンダとの紐付けを行うが、 ユニークなIDが繰り返しのイベントの更新処理などを行う場合IDが変更されてしまうことがあり、 紐付けが外れてしまうことがわかった。 そのため、Google Calendar 側の仕様を網羅し、いつどの処理を行うとIDが変更されてしまうのかを 調査する必要があった。 工夫した点 調査に関しては、カレンダーで操作できるパターンケースを全てスプレッドシートにまとめ、 1つ1つ検証を行なった。 その検証結果を元に、Google Calendar とアプリ側の連携の設計・実装や、 アジェンダとの紐付けなどの設計を行なった。