ID:81718さん

■プロジェクト概要 アフィリエイト学習用記事ページ(約10画面)のデザイン刷新プロジェクト ■チーム情報 役割:メンバー / 体制:1名 ■開発・実装内容A:レガシーコードのリファクタリングと保守性向上 【概要】 古いUIのリニューアルに伴い、既存コードの技術的負債解消に取り組んだ。 【課題・問題点】 - 既存コードが密結合で、テストが困難 - 画面間で共通データ取得処理が重複 - キャッシュ機構がなく、パフォーマンス面で課題 【使用した技術】(自身が設計・実装) - Vue.jsを使用したフロントエンド実装 - 疎結合を意識した設計により、単体テストを実装可能な構造に改善 - 学習用記事ページのみで使用される共通処理がAOPで利用されていたが、画面固有のサービスに切り出し - キャッシュ機能を追加し、パフォーマンス改善 - Playwrightによるテスト自動化で品質担保 【成果】 タイトなスケジュールだったが、計画通りにリリースを完了。 上長から「遅れると思っていたが、スケジュール通りに完了して驚いた」との評価を獲得。

■プロジェクト概要 サービスサイトのデータベース(MySQL 5.7 → 8.0)バージョンアップ対応 ■チーム情報 役割:主担当 / 体制:1名 ■開発・実装内容A:段階的検証による安全な移行 【概要】 サービスサイトで使用する約20テーブル、約200のSQL文を含むシステム全体のMySQL 8.0対応。 【課題・問題点】 - MySQL 5.7と8.0の仕様差分による影響範囲が広範 - 本番環境での障害リスクが高い - 廃止された関数・構文の洗い出しと置き換えが必要 【使用した技術】(自身が実装) - 公式マイグレーションガイドを精読し、変更点を網羅的に調査 - ローカル検証環境(Docker)→ステージング環境の段階的検証フローを確立 - 廃止された関数・構文を特定し、互換性のあるコードに置き換え - 影響範囲をリスト化し、計画的に対応 【成果】 - 本番移行後の障害ゼロを達成 - 上長から「1人でできると思わなかった。助かった」との評価を獲得 - 段階的検証プロセスの確立により、今後の技術移行の標準手法として活用可能に

■プロジェクト概要 Googleガイドライン変更に伴うワンクリック登録解除機能の実装 ■チーム情報 役割:PL / 体制:3〜4名 / 期間:約4ヶ月 ■課題・問題点 - Googleガイドライン変更への期限内対応が必須 - 既存のメール配信システムとの統合が必要 - 複数のメール送信箇所への横断的な対応が必要 - チーム内でプロジェクト管理手法が統一されておらず、進捗の可視化が困難 - Excel管理では、タスクの依存関係やボトルネックが把握しづらい ■対応内容 【機能実装】(自身が設計・実装) - ワンクリック登録解除APIの入力パラメータ設計(会員ID + 種別をキーとする設計) - Googleガイドラインを調査し、メールヘッダーへの登録解除リンク付与方式を実装 - メール受信設定テーブル更新処理を実装し、既存システムと連携 - 既存の社内APIを活用し、開発コストを抑制 - 複数のメール送信箇所への横断的な対応を実施 【プロジェクト管理】(自身が提案・導入) - Jiraを活用したタスク管理手法を提案・導入 - ガントチャート(タイムライン)とカンバンボードで進捗を可視化 - 毎日朝会で進捗確認、週1回のコードレビューで品質担保 - 重要度の高いロジックを優先検証し、早期にリスクを潰す - 予算に約10%のバッファを計上し、遅延リスクに備える - 遅れが発生した際は、速やかに上長へ共有し、タスクの再配分や前倒し対応を実施 ■成果 - 計画通りのリリースを達成し、Googleガイドラインに準拠 - チームメンバーから「わかりやすくて良い」との評価 - タスクの可視化により、チーム全体の生産性が向上 - 初めてのPL経験として、プロジェクト推進とリスク管理を実践

■プロジェクト概要 パートナー向け管理画面のモダナイゼーションとリファクタリング ■チーム情報 役割:主担当 / 体制:1名 ■開発・実装内容A:レガシーコードのモダナイゼーション 【概要】 古い画面コードをVue.jsで刷新し、保守性を向上。 【課題・問題点】 - レガシーなコードベースで密結合な実装が多く、保守性が低い - お知らせ表示判定処理などが画面ごとに独自実装され、重複が多い - 区分による分岐処理が多く、新しい区分追加時の修正コストが高い 【使用した技術】(自身が設計・実装) - 別画面で使用実績のあったVue.jsの導入を提案し、採用 - お知らせ表示判定など重複処理を共通化 - デグレリスク軽減のため、テストコードを書きながらリファクタリング - 密結合な処理を疎結合に改善 - 設定駆動型の設計を導入:区分ごとの分岐を設定値で切り替える仕組みに変更し、新規区分追加時のコード修正を不要化 【成果】 - 保守性が大幅に向上し、機能追加時の工数削減を実現 - 設定駆動型の設計について、上長から高い評価を獲得

■プロジェクト概要 パートナー向け管理画面へのメールフォルダ振り分け機能の新規追加 ■チーム情報 役割:PL / 体制:3〜4名 / 期間:2025年4月〜2025年9月 ■課題・問題点 - パートナーが不要なメール受信により、重要なメールを見落とす - メールが整理されておらず、管理画面の使い勝手が悪い - スクラム開発のキャッチアップに時間がかかり、プロジェクト進行に影響 - 受信設定の読み込み処理を複数アプリで共通化する必要がある - レガシーなバッチ処理は手動テストのみで、確認が大変 - テンプレートファイルのサーバーへのアップロードが手動で、ミスや手間が発生 ■対応内容 【要件定義・機能設計】(自身が要件定義・設計) - 営業・カスタマーサポートへのヒアリングで課題を整理 - ルールベースのフォルダ振り分け機能を設計 - パートナーがメール種別ごとに受信設定を登録できる仕組みを実装 - メール受信画面と約10のバッチ処理に対応 - 新規に5テーブルを設計・作成 【技術的な工夫】(自身が提案・実装) - 受信設定の読み込み処理を複数アプリで共通化するため、社内の共通APIの使用を提案 - API呼び出し時のエラーに備え、リトライ機能を実装 - バックアップファイル出力と取り込み用スクリプトを作成し、リカバリー手段を確保 - 複数サーバーの同時シャットダウンを防ぐため、待機処理を追加 - レガシーなバッチ処理に単体テストを導入し、動作確認の効率化を実現 - GitHub Actionsを活用し、テンプレートファイルのサーバーへのアップロードを自動化 【プロジェクト管理】(自身が導入・実践) - スクラム開発を導入(書籍学習、詳しいメンバーへの質問でキャッチアップ) - キャッチアップに時間がかかる課題を認識し、スクラムの要素に重要度を付け、優先度の低いものをスキップして効率化 - テストが苦手なメンバーに配慮し、柔軟な役割分担を設定 ■成果 - 計画通りにリリースを完了し、パートナーのメール管理の利便性を向上 - 社内共通APIの活用により、複数アプリでの保守性を向上 - 単体テストの導入により、バッチ処理の動作確認を効率化 - GitHub Actionsによる自動化で、デプロイ作業の手間とミスを削減 - スクラム開発のエッセンスを取り入れ、チームの開発プロセスを改善