ID:66308さん

# プロジェクト概要 ### 目的・背景 某大手IT企業から製品を営業販売する人材と営業サポートする人材のマッチングプラットフォームの開発案件を受注。 ### プロダクト概要 某大手IT企業の製品を営業販売する人材と営業サポートする人材のマッチングプラットフォームの開発。 主に以下のことをプラットフォーム上から行える。 - 求人の掲載 - 求人への応募 - 求人の絞り込みや検索 - チャット ### チーム構成 テックリード1名、エンジニア5名、ディレクター1名 ### 自分の役割 全ての機能を担当。 ### 使用技術 #### バックエンド - Laravel(MVCをベースにサービス層とリポジトリ層) - PHP Unit(ユニットテスト / E2Eテスト) #### フロントエンド - Next.js #### インフラ - 開発環境 : DockerCompose - 本番 / ステージング環境 : AWS(EC2, RDS, ELB, S3, CloudFrontなど) #### ミドルウェア - Nginx - MySQL #### CI/CD - GitHubActions #### バージョン管理 - Git / GitHub # 取り組みと課題 ### 技術選定の意図 - 開発メンバーの扱える技術の中で、最も開発速度と品質が高くなる技術を選定 ### 課題と打ち手 #### クライアントのマネジメント クライアントの要求から具体的な要件に落としていき、設計していくといった、いわゆる上流工程を担当したが、要求から開発に落とし込んでいく作業は、高いコミュニケーション能力や技術力が求められると感じた。 上流工程に対してのナレッジをもっと勉強していかなければいけないと感じた。

# プロジェクト概要 ### 目的・背景 関西最大手の不動産・鉄道会社の新事業を担うプロジェクト。 クリエイターを応援すると共に、アートの価値を多くの人々に届けることを目的としたプロダクト。 ### プロダクト概要 アート作品の出品、売買、レンタルができるプラットフォーム。 主に以下のことをアプリ内から行える。 - アートの売買・レンタル - 集荷 / 配送 - チャット - 作品の絞り込みや検索 - 作品のお気に入り - 作品のレコメンド - クリエイターのフォロー ### チーム構成 テックリード1名、バックエンドエンジニア1名、フロントエンドエンジニア2名、ディレクター1名、デザイナー1名、QA1名 ### 自分の役割 バックエンドを担当。テックリードに3割ほど手伝ってもらいながら、バックエンドの7割ほどを自分が構築。 フロントエンドの軽微な修正も担当。 ### 使用技術 #### バックエンド - NestJS(ドメイン駆動設計の思想に基づいた、オニオンというアーキテクチャを採用) - ヤマト運輸API(アート作品の集荷・配送) - StripeAPI(決済) - Jest(ユニットテスト / E2Eテスト) #### フロントエンド - Next.js(AtomicDesignに沿ってコンポーネントを管理) #### インフラ - 開発環境 : DockerCompose - 本番 / ステージング環境 : AWS(EC2, RDS, ELB, S3, CloudFrontなど) #### ミドルウェア - Nginx - MySQL #### CI/CD - GitHubActions #### バージョン管理 - Git / GitHub # 取り組みと課題 ### 技術選定の意図 - 保守性の向上を期待し、アーキテクチャにドメイン駆動設計を採用。 - 開発効率向上を期待し、フロントエンドとバックエンドの言語をTypeScriptに統一。 ### 課題と打ち手 #### ドメイン駆動設計 ユースケース層にドメイン知識が漏れ出てしまう、いわゆるドメイン貧血症に陥ってしまったことがあった。 ドメイン駆動設計を採用する場合は、成熟度と保守性は比例すると感じた。 受託開発のように、モジュールを他プロジェクトで転用したいケースが多い場合には、ドメイン駆動設計は向いていないことがわかった。 今の所のベターはモジュラモノリス構成であると感じているため、今後は、かなり大規模なサービスを開発する際などのユースケースでのみドメイン駆動構成を採用する。 #### バックエンドとフロントエンドをTypeScriptに統一 運用フェーズは私一人でフロントエンドとバックエンドを対応しており、TypeScriptで言語が統一されていることによる言語のスイッチングコストがないことはメリットだと感じた一方で、仮にバックエンドをPHPで組んでいた場合に、フロントエンドが別の言語で苦労するかと言われれば、言語のスイッチングコスト以外は特に懸念点は思い当たらなかった。 また、開発フェーズではフロントエンドとバックエンドで担当が分かれており、横断的に対応することが少なかったため、恩恵を感じることは少なかった。 今後は、TypeScriptしか扱えないメンバーでチームが構成される場合などのケースで限定的に採用する。 #### NestJSを採用するべきユースケース NestJSは、サーバーのリソースの消費が大きく、EC2のインスタンスタイプを引き上げたことにより、従来のLaravelとNext.js構成と比較してインフラ料金が4倍になってしまった。 NestJSの採用する場合は、Node.jsのノンブロッキングI/Oの特性を活かし、CPUをたくさん使用する処理は少ない一方で、大量のリクエストを捌きたい場合などのユースケースに限定して採用する。

# プロジェクト概要 ### 目的・背景 自動車業界最大手の会社の新事業を担うプロジェクト。 工場の中古設備を売りたい会社と買いたい会社を繋げ、今まで廃棄された中古設備資源を循環させことによるサステナビリティの実現。 ### プロダクト概要 工場の中古設備の出品、売買ができるプラットフォーム。 主に以下のことをアプリ内から行える。 - 中古設備の売買 - チャット - 設備の絞り込みや検索 - 設備のお気に入り ### チーム構成 エンジニア1名、ディレクター1名、デザイナー1名、QA1名 ### 自分の役割 全ての機能を担当。 ### 使用技術 #### バックエンド - Laravel(MVCをベースにサービス層とリポジトリ層) - StripeAPI(決済) - PHP Unit(ユニットテスト / E2Eテスト) #### フロントエンド - Laravel(Blade) - jQuery #### インフラ - 開発環境 : DockerCompose - 本番 / ステージング環境 : AWS(EC2, RDS, ELB, S3, CloudFrontなど) #### ミドルウェア - Nginx - MySQL #### CI/CD - GitHubActions #### バージョン管理 - Git / GitHub # 取り組みと課題 ### 技術選定の意図 - 当プロジェクトの特性が、社内の既存プロジェクトと近かったため、既存プロジェクトのリポジトリを移植する形で開発した ### 課題と打ち手 #### ファットコントローラー コントローラーにビジネスロジックを書いていくスタイルだったため、コントローラーの各メソッドが肥大化してしまい、コードの可読性を下げていた。 クリティカルな部分については、なるべくサービス層とリポジトリ層に責務を分離するようにした。 #### コーディング規約に則ってなかった 社内のコーディングルールとしてPSR12と決まっていたが、それが遵守できてなかったり、マジックナンバーなどが混在していてコードの可読性を下げていた。 ボーイスカウトルールに基づいて、都度リファクタリングを行うようにした。