akinoringo

# プロジェクトの概要 ## 概要 男性と女性のマッチングサービス(WEB)の開発・運用を行なっている。 ## 主要機能 - 課金 - リアルタイムチャット - いいね、足跡 - 通知（メール、LINE） - ランキング ...etc ## 技術スタック - フロントエンド：Vuejs, Javascript - バックエンド：PHP/Laravel, Nodejs - インフラ：AWS(EC2, RDS, Cloud Front, S3, Cloud Watch), Docker - ほか：MySQL, Firebase Authentication, Firestore ## 担当した役割 4人体制のリードエンジニアとして、フロント・バックエンドを主に担当し、インフラも一部担当した。開発ドキュメントが全くない状態でソースコードからアプリケーションの構成を把握し、クライアント様の機能要件を満たすサービスの開発・リリースまでを行った。 # 発揮したバリュー ## ソースコードから要件定義・仕様を抽出 ### 課題 引継ぎ開発であったが、開発に関する情報がソースコード以外に全くない状態であったため、要件や仕様の詳細が不明であり、かつ、サービスのリリースに必要な機能の開発状況が不透明でった。これに伴い、クライアント様との開発方針の議論も難航していた。 ### 工夫 - ソースコードをもとに、機能一覧/画面一覧を作成し、サービスの要件および仕様をクライアント様と共有できるようにした。開発進捗が可視化され、クライアント様との開発方針の議論が加速した。 ## 画面表示の改善 ### 課題 既存の実装では、トップページの表示が3秒程度と非常に遅いという課題があった。 ### 工夫 トップページの読み込みが遅い原因の一つに、サイズの大きい画像の大量の読み込みがあることが推定されたため、ユーザーが画像を投稿する際に画像をリサイズする実装に変更した。さらに、キャッシュを使用して画像などの静的ファイルの表示速度を高速化する`Cloud Front`を導入した。その結果、ページ表示速度が平均的に1秒程度改善することを確認した。 ## セキュリティの改善 ### 課題 既存の実装では、ユーザー同士のチャットの内容などが格納されている`Firestore`に誰もがアクセスできる状態で、極めてセキュリティが低い状態であった。 ### 工夫 `Firestore`のアクセスに対して、適切なセキュリティルールを設定し、該当するユーザーのみがデータにアクセスできるように改善した。

# プロジェクトの概要 ## 概要 求人および採用に関する支援ツールの自社開発を行なっている ## 主要機能 - 求人管理 - 人事管理 - 採用フローの自動化 - 採用情報の分析 - 通知（メール、Slack） - 採用媒体との連携 ## 技術スタック - フロントエンド：Vuejs, Javascript - バックエンド：PHP/Laravel, Nodejs - インフラ：Docker, AWS ECS, RDS, SES, ...etc ## 担当した役割 3人体制のリードエンジニアとして、自社アプリの要件定義と技術選定を主に担当した。 # 発揮したバリュー ## 手戻りが発生しないように要件定義書を作成 ### 課題 受託開発がメインの会社であるため、案件の稼働状況によって自社開発のアサインメンバーが随時変更になることが多々あるが、その際にアプリケーションの開発目的や仕様の引継ぎがうまくされないため開発効率が悪いという課題があった。 ### 工夫 開発の背景および目的、想定される使用環境や要求機能について「要件定義書」を作成し、開発の方向性を再確認する手間を省いた。 ## 技術選定・アーキテクチャ設計・Dockerによる開発環境の構築 ほかのメンバー2人が入社1ヶ月程度であったため、アプリケーションに用いる技術選定およびアーキテクチャ設計を行い、 Dockerによる開発環境の構築を行なった。

# プロジェクトの概要 ## 概要 マンション管理を一元化する大規模データを扱うツールの開発・運用を行なっている ## 主要機能 - 発注、支払い、請求の月次・年次の管理 - 収支計算 - PDF書類作成 - 部屋管理 - 駐車場などの共同部管理 - 理事会の役職管理 ## 技術スタック - フロントエンド：Vuejs, Javascript - バックエンド：PHP/Laravel, Nodejs, Auth0 - インフラ：Docker, AWS ECS, RDS, SES, Lambda, S3, Redis ## 担当した役割 フロントエンドおよびバックエンドエンジニアとして、保守運用・追加機能開発を行なった。 # 発揮したバリュー ## 前任者退職に伴う短期間でのキャッチアップ ### 課題 重要機能の一つである「請求」を担当していた前任者が急遽退職することになったため、`1ヶ月半の短期間で`主要ロジックが詰まった「請求」に関わる`膨大な知識を引き継ぐ必要があった`。 ### 工夫 前任者しか把握していない仕様や請求の`主要な機能をリストアップして優先度順を決めて`、毎日の定期的な引継ぎmeetingを設けたうえで`短期間で効率よく引継ぎができるように尽力した`。結果的に、前任者退職後も特に問題なく業務を進めることができた。`引継ぎ完了後は`、テストコードが不十分な箇所を中心に`テストコードを充実化させ`、アクティビティ図などを活用して積極的に`ドキュメント整備を行った`。さらに、メンバーの業務内容をシェアをする定期Meetingを設けるなど、`俗人化を減らすことに尽力した`。その結果、私が別案件に移動する際も、`2週間の短期間で「請求」の引き継ぎを行うことに成功した`。 ## アプリチームとの連携 ### 課題 WEB, iOS, Android版のアプリが存在するが、開発の仕様についてWEB側とアプリ側、さらにアプリの中でもiOSやAndroidのメンバーでも認識が異なることが多々あり、コードレビューや動作確認後に手戻りが発生するケースが散見されていた。 ### 工夫 手戻りの多くが認識の不一致であったため、シンプルにmeetingを増やして合意が取れた内容をドキュメントにまとめ、プルリクの内容（仕様書や議事録、スクリーンショット画像の添付など）を充実させ、オンラインでありながらも密なコミュニケーションを心がけた。当然、認識不一致による手戻りが減少した。 ## DBのロック機能を活用した多重登録の改善 ### 課題 処理が重い登録機能において、ダブルクリック等でレコードが重複してしまうという課題があった。この課題に対して、登録機能の前に重複を確認する処理が導入した。しかし、登録処理に時間がかかる場合には重複チェックの際にまだ1回目のデータが登録されておらず2回目以降のデータ登録がされてしまうという問題が発生した。 ### 工夫 DBのレコードの重複チェックに加えて、DBのロック処理を提案・導入した。これによって、登録処理の最初にレコードに対して読み取りロックをかけることで2回目以降の処理は1回目の処理が終わるのを待ってから動作することとなるため、重複チェックが正常に動作し問題が解決された。 ## パフォーマンス改善を意識した実装 ### 課題 DBには、万を超える膨大なレコードがあり、一つ一つの処理に非常に時間がかかってしまっていた。 ### 工夫 N + 1問題を引き起こさないために`EagerLoad`を意識し、`クエリーを確認しながら、パフォーマンスを意識して`データの抽出ロジックを意識し実装を行なった。

# プロジェクトの概要 ## 概要 マンション利用者および購入者向けのマンション管理システムの新規開発 ## 主要機能 ### ユーザー画面 - ユーザー登録・ログイン - 証明書アップロード - マンション一覧 - マンションカスタマイズ - マンション申し込み・購入 - 希望マンション通知 - 購入物件情報閲覧 - 設備トラブル・メンテナンス等のお問い合わせ ### 管理画面 - ユーザー管理 - マンションのマスター管理 - 権限設定 - 購入物件情報（物件、事業所、書類、備品、etc）のマスター管理 - ユーザー承認 - 書類アップロード - 記事作成 ## 技術スタック - フロントエンド：Vuejs, TypeScript, Nuxtjs - バックエンド：PHP/Laravel, Nodejs, - インフラ：Docker, AWS ECS, RDS, SES, Lambda, S3, Redis # 発揮したバリュー ## パフォーマンス改善 ### 課題 サービスリリース後、`数百件におよぶ大量の物件が登録されたことで`物件に関連するデータの登録/更新処理に`時間がかかってしまっていた`。 ### 工夫 `処理時間が長いものをリストアップするために`、実際にお客様が使用している本番環境のデータを開発環境に移行し、Chromeの検証ツールやPHPの時間計測メソッドで`物件に関連するデータの登録/更新処理にかかる時間を計測した`。当初の予想通り、`データベースに登録する処理がボトルネックとなっていることがわかった`ため、`SQLの発行回数を減らして処理時間を短くするために`bulk insert等を活用してパフォーマンスの改善を行った。その結果、当初`10秒以上`もの時間がかかっていた処理が`2秒未満`にまで改善されることを確認した。 ## バックエンドエンジニア視点のフロント開発 ### 課題 開発当初は、`フロントエンドとバックエンドで専任のエンジニアが実装を行なっており`、バックエンドでロジックを実装した方が効率が良い場合でもフロントエンドで複雑な処理を行なっているケースが多々あり、`ソースコードが複雑化していた`。 ### 工夫 リリース後のエンジニアリソースの縮小に伴い、私が途中でアサインした際はバックエンドとフロントエンドの実装を両方行うことになった結果、`バックエンドとフロントエンドそれぞれの利点を生かした実装を行うことができた`。その結果、フロントエンドで十行程度かかっていたソースコードがバックエンドで実装することで1行程度に減少するなど、多くの箇所で`リファクタリングに成功した`。