ID:67322さん

## 技術的負債 改善 実装における設計 オブジェクト指向の実装になっていなくエンティティ基準の実装がされていない技術的負債が募っている現場において、現場リーダーと確認をとりながらオブジェクト指向設計に基づいた実装に作り替えました。例えば、インスタンス変数が呼ばれているにも関わらず、インスランス変数が呼ばれていない状況に出会しました。結果、ネスト化されておりエンティティごとに分けられた実装をしていなかった現状がありました。こちらの一部機能を作り替え可読性や保守性が高い実装に作り替えました。 #プロジェクト：大規模ECサイト保守・運用 (2023年) # チーム情報 - プロジェクトリーダー: 1名 - プログラマー: 2名 - 運営スタッフ: 1名 - 開発環境: Linux, Apache, Nginx, MySQL, PHP # 開発・実装内容A 【概要】 大手ECサイトの機能改善と運用最適化 【どのような機能の開発・実装か】 - 購入制限数のロジック改修 - キャンセル条件の複雑なロジック設計 - 決済変更導線の修正 - 不正防止のためのバッチ処理改修 【課題・問題点】 - 複雑な購買ロジックの管理 - 不正利用の防止 - ユーザー体験の向上 【打ち手・使用した技術】 - 詳細な条件分岐ロジックの実装 - PHP 5.5 (Symfony)とLaravel 8の併用 - Git Feature Flowによるコード管理 - 詳細な要件定義と設計見直し # 開発・実装内容B 【概要】 ECサイトの機能拡張とトラブルシューティング 【どのような機能の開発・実装か】 - 個人出品サイトの画像非表示問題の調査と修正 - ポイント付与システムの不正防止 - ユーザビリティ改善のための機能追加 【課題・問題点】 - 原因不明の画像非表示問題 - ポイントシステムにおける二重付与リスク - 複雑な決済システムの管理 【打ち手・使用した技術】 - 詳細な原因調査と再現テスト - バッチ処理の最適化 - セキュリティを考慮したロジック設計 - 顧客フィードバックに基づく改修

## 組織課題 - 組織課題を見つけ、自らアクションをとり問題解決しました。 - 具体的にチーム構成がみなさん他のPJTも兼任されているような状況でPJTを運営しなければいけない状況下でした。この状況下でコミュニケーションを図りながら進捗率を向上しなければいけない。その中でSlackとチケット管理ツールを連携させるように取り組みお互いが迅速にレスに応えられる取り組みをしました。組織の中で何がうまくいっていなく、どのように運営していくことが改善につながるのかボトルネックを見つけアクションを取ることが得意です。私はPJTがうまくいくことを優先的に考えることが根底にあるからです。 # プロジェクト：看板管理システム開発 (2024年1月〜3月) # チーム情報 - プロジェクトマネージャー: 1名 - プログラマー: 1名 - 開発環境: Linux, Apache, Laravel 10, Docker, Windows11 Pro # 開発・実装内容A 【概要】 既存の看板管理システムの改修と新機能開発 【どのような機能の開発・実装か】 - システムエラーの改修 - 未実装機能の新規開発 - ユーザ管理画面のCRUD（作成、読取、更新、削除）機能実装 - 顧客との要件擦り合わせ 【課題・問題点】 - 既存システムの不具合対応 - 顧客要望の正確な把握 - システムの安定性と機能性の向上 【打ち手・使用した技術】 - Laravel 10を用いたシステム開発 - リモート環境での顧客折衝 - 詳細な要件定義と設計 - テーブル設計の最適化 - Dockerコンテナ環境の活用 # 開発・実装内容B 【概要】 ユーザビリティ向上と運用効率の改善 【どのような機能の開発・実装か】 - 既存システムの機能強化 - ユーザビリティを考慮した画面設計 - 新規管理機能の実装 【課題・問題点】 - システムの使いやすさの改善 - ユーザ管理機能の拡張 - 顧客ニーズへの柔軟な対応 【打ち手・使用した技術】 - ClickUpとGoogleスプレッドシートによるプロジェクト管理 - Gitを使用したコード管理 - リモート環境での効率的な開発プロセス - 顧客との密接なコミュニケーション

美容サロン向けのCRMプロジェクトではLaravel, TypeScript, Vue.jsを駆使し単なる技術の組み合わせではなく、ビジネスニーズに寄り添ったソリューションを提供。開発環境の最適化にも注力し、チームの生産性向上に貢献しました。 プロジェクト：SaaS CRMアプリケーション開発 (2023年) チーム情報 プロジェクトリーダー: 1名 プログラマー: 2名 開発環境: Mac M1pro, Docker, Laravel, TypeScript, Vue.js 開発・実装内容A 【概要】 美容サロン向けカスタムCRMシステムの開発・改修 【どのような機能の開発・実装か】 ユーザーカスタマイズCRMの実装 開発環境の最適化 フロントエンドとバックエンドの統合 【課題・問題点】 美容サロン特有の要件理解 複雑なユーザーニーズへの対応 開発効率の向上 【打ち手・使用した技術】 Laravel, TypeScript, Vue.js (ver2)の活用 Dockerによる環境統一 コンポーネントベースの設計 Git管理システムの導入 開発・実装内容B 【概要】 CRMシステムの拡張性と保守性の向上 【どのような機能の開発・実装か】 環境設定の最適化 プログラマーが実装しやすい環境構築 コード品質の向上 【課題・問題点】 開発環境の複雑さ コードの可読性と保守性 技術的負債の管理 【打ち手・使用した技術】 詳細な環境設定の最適化 TypeScriptによる型安全性の確保 Vue.jsのコンポーネント設計

ーーーーーーーーーーーーーーーー ## - 通信システム開発プロジェクトでは、複雑な既存システムと新旧システム間の機能整合性に直面しました。週次ミーティングによる実装方針共有、定期的なコードレビュー、技術的負債の可視化などの工夫を重ねた結果、システムの可読性と保守性が大幅に向上し、チームの技術的透明性を確保するとともに、開発効率を改善することができました。 # プロジェクト：通信Webシステム開発 (2024年) # チーム情報 - プロジェクトリーダー: 1名 - プログラマー: 3名 - 開発環境: Linux, Symfony 5系, PHP, Docker # 開発・実装内容A 【概要】 通信会社の新規Webサービスページ開発および既存システムの改修プロジェクト 【どのような機能の開発・実装か】 - 新規Webページの開発 - 新規API作成 - 既存システムの改修 - テスト仕様書の作成と実施 【課題・問題点】 - PHP 8.1から8.2へのバージョンアップ対応 - Composerライブラリの脆弱性対応 - チームメンバー間の実装方針の統一 【打ち手・使用した技術】 - PHP 8.2への移行 - Composerライブラリの脆弱性調査 - チームディスカッションによる最適な実装方法の模索 - Gitを用いたコード管理 - Dockerコンテナ環境の活用 # 開発・実装内容B 【概要】 通信システムの技術的課題解決と最適化 【どのような機能の開発・実装か】 - 既存システムの機能改修 - API開発における最適な実装方法の探求 - コードの可読性と保守性の向上 【課題・問題点】 - 複雑な既存システムの理解と改修 - パフォーマンスと拡張性の確保 【打ち手・使用した技術】 - メンバー間での継続的なディスカッション - オブジェクト指向設計の適用 - コードレビューによる品質改善 - Symfony frameworkの活用 - DockerとLinux環境での開発(改修) ーーーーーーーーーーーーーーーー

# AI支援型テンプレート管理プラットフォーム ## プロジェクト概要 非エンジニア（AIノービス）のビジネスユーザーが、生成AIを活用して業務テンプレートを管理・活用できるフルスタック Web プラットフォームの開発に参画。 主要機能の一つとして、複数の生成 AI プロバイダー（OpenAI / Google / Perplexity / Anthropic）のモデル API と連携し、ユーザーが任意のモデルを選んでチャットを送信できる機能を搭載。 - 期間: 2025/12 〜 現在 - 役割: 基本設計・詳細設計・実装・テストを担当（コードレビューも随時実施） - チーム構成: 5 名（PM 1 名、インフラ担当 1 名、実装者 3 名（自分含む）） --- ## 技術スタック | 領域 | 技術 | |------|------| | フロントエンド | Next.js 15 (App Router), TypeScript, TanStack Query, Zod | | バックエンド | Hono.js, NextAuth.js | | データベース | PostgreSQL, Drizzle ORM | | キャッシュ | Redis | | 生成AI | OpenAI (GPT 系) / Google (Gemini 系) / Perplexity / Anthropic (Claude 系) の各モデル API | | その他 | Mermaid（設計ドキュメント）, Notion（スペック管理） | --- ## 担当業務 プロジェクト参画以降、フロントエンド・バックエンドを横断的に担当。新規機能開発では DB 設計から実装まで一気通貫で対応。 ### バックエンド（Hono.js + Drizzle ORM） - API エンドポイントの実装 - ビジネスロジックの実装 - DB アクセス層の実装 - Zod によるリクエスト/レスポンスのバリデーション ### フロントエンド（Next.js 15 App Router） - ページ・UI コンポーネントの実装 - API 連携（TanStack Query） - フォームバリデーション ### DB スキーマ設計 - テーブル構造・カラム・制約・インデックスの設計 - Drizzle Kit によるマイグレーション管理 - 設計判断の根拠を `docs/decisions.md` に記録 ### 生成 AI 機能統合 - 生成 AI サービスとの連携実装 - プロンプトエンジニアリング - レスポンス処理・エラーハンドリング・フォールバック設計 --- ## 担当機能（抜粋） ### Wordpress API 連携 - Wordpress API との連携実装を担当 - 連携の目的: Worpressで管理している既存システムのAI記事を新規開発しているwebAppに反映させ、AIに触れる機会を創出する] - [実装時に検討した点 認証方式、エラーハンドリング ] ### NG ワード機能の API 開発 - バックエンドとフロントエンドを繋ぐ API を設計・実装 - [NG ワード機能「chatに入力したワードのNG ワード検出」 ### パーソナライズ機能 - クライアント企業が自社のユースケースに合わせてパーソナライズ項目（業種・職種・成功した事例など）を自由に定義でき、エンドユーザーがプロフィールとして設定する仕組み。ユーザーがチャット利用時に毎回コンテキストを入力する必要がなく、設定済みのパーソナライズ情報をLLMが自動的に参照することで、ユーザーごとに最適化された応答を提供する。 ### テンプレートパーソナライズ機能 - エンドユーザーのプロファイル属性に応じて、テンプレート一覧の並び順を最適化する機能。LLM を用いてユーザー属性からタグ推薦を行い、その結果をもとにテンプレートをリランキングする。 #### DB 設計 - ユーザーとタグを紐づける中間テーブル `end_user_selected_tags` を設計 - データ整合性を担保する制約を導入： - CHECK 制約でタグ種別ごとの入力値を制限 - 部分ユニークインデックスで「同一ユーザー × 同一タグ種別 × アクティブ」の重複を防止 - 親テーブル削除時の CASCADE 削除で孤立レコードを防止 #### API 設計・実装 - タグレコメンド API：ユーザー属性を入力に LLM でタグ候補を生成し返却 - タグ選択保存 API：ユーザーが選択したタグを中間テーブルに永続化 - RESTful なパス設計（複数形、リソース指向）、`c.json()` のみで冗長なラッパーなし - Drizzle のクエリパターンをプロジェクト内で統一 --- ## 開発プロセス プロジェクトにおける機能開発の標準的な進め方。 ### 1. 要件定義フェーズ - PM から新機能・改善要件を受領し、要件ドキュメントをレビュー - エンジニア視点で技術的実現可能性・既存システムとの整合性を評価 - スコープを明確化し、工数を見積もる ### 2. 設計フェーズ - **DB 設計**（新規テーブルが必要な場合）：要件分析 → スキーマ設計（型・制約・インデックス）→ Drizzle スキーマ実装 → Drizzle Kit でマイグレーション作成 - **API 設計**：RESTful なエンドポイント定義、Zod によるリクエスト/レスポンス型定義、エラーハンドリング方針の決定 - **フロントエンド設計**：コンポーネント構成、状態管理、ルーティング、UI/UX フロー - 設計内容は Mermaid で図化し `docs/features/` 配下に Git 管理 ### 3. 実装フェーズ - **バックエンド（Hono.js）**：API エンドポイント、ビジネスロジック、DB アクセス層の実装 - **フロントエンド（Next.js）**：ページ・UI コンポーネント、API 連携、フォームバリデーション - **AI 機能統合**：生成 AI サービスとの連携、プロンプトエンジニアリング、レスポンス処理、エラーハンドリング・フォールバック ### 4. リリースフェーズ - ステージング環境でのテスト - リリース後のモニタリングとフィードバック収集 --- ## 技術的な取り組み ### プロジェクト固有の AI 運用ルール整備 - `CLAUDE.md` を「汎用的なベストプラクティス」ではなく「このプロジェクトでなぜこの判断をするか」の文書に整理 - ルール自体は `rules/*.md に分離し、意思決定の根拠を追跡可能にする。仕様はdocs/にまとめる。 ``` ### 設計プロセス - 実装前に Mermaid で 業務フロー図を機能ごとに作成 - AIシステムでブラックボックス化しているシステムでもあり、いつどんなときにデータが返り、いつどこにデータを保有するか解像度を上げるために作成 - DB設計 --- ## 個人的に取り組んでいる学習 業務外で以下を継続： - **AWS / インフラ周り**: EC2, ALB, RDS, S3, ECS, APIゲートウェイ - **システム設計**: DB周りの設計(リーダーレス、マルチリーダー)、メモリーキャッシュ、Redisを活用する設計、レート制限、モジューラモノリス、モノリス、マイクロサービス ---