ID:80843さん

## 案件概要 自社サービスの画像管理システムがNuxt2を使用しており、サポート終了に伴いNuxt3へのアップデートを 単独で担当。 Nuxt3移行によりAPI側にも互換性課題が生じたため、フロントと併せてAPI改修も対応。 ## 背景と課題 * 背景: Nuxt2のEOLにより継続運用が困難、Nuxt3への移行が必須。 * 課題: * 案件開始時点でNuxt経験は小規模な改修を数件のみで、フロント開発はほぼ初心者に近い状態。 * チームにフロントができる人が不在で、技術相談の相手がいない。 * Nuxt2→Nuxt3は破壊的変更が多く、既存構成の再考とコード再設計が必要。 ## 役割・担当範囲 * 環境構築: Dockerを用いたローカル開発環境の整備。 * パッケージ選定: Nuxt3移行に伴う採用ライブラリの比較検討と方針決定。 * 実装: 破壊的変更のためNuxt新規プロジェクトを立ち上げから完成までを単独で遂行。 * 仕様把握・改修: フロント／バック双方のドキュメント不在下でAPI仕様をコードから把握し、 必要な修正を実施。 ## 取り組みと工夫 * 学習ループの高速化 * 公式ドキュメントとAIコーディングツールを活用し、「考察→実装→確認」を高速に回して理解を深めた。 * 私を含めてフロントの実装ができる人がいないため、実装で発生するエラーを都度分析し、 解決パターンを蓄積。細かな検証を徹底することで、経験が浅い状況でも単独で不具合の少ないリリースを実現。 * 再利用性・可読性の向上 * Nuxt2で分散・重複していた権限関連のロジックなどをComposableへ集約。 * ぱっと見で分かりづらい処理はメソッドへ切り出し、重複排除と命名統一で保守性と見通しを改善。 * Nuxt3実装ドキュメントの整備 * チームにフロント実装者が不在のため、Nuxt2→Nuxt3のコード置換指針、モーダル実装など頻用パターンをドキュメント化。 * 自身の実装効率向上に加え、他メンバーが参照可能なガイドとして再利用性を確保。 ## 成果 * リリース後の不具合報告を「1件」に抑制し、早期に修正。 * 継続運用可能な開発環境と依存関係を整備し、保守容易性を向上。 * 仕様書不在でも実装と手動検証から仕様を把握し、フロント実装まで完了。

## 案件概要 Next.js（v10）のサポート終了から4年が経過し、継続運用が困難に。 自社の別サービスでNuxtを採用していた経緯から、フロントエンドをNuxtへ全面リプレース。 内製化前の設計に問題があり、データベースおよび画面デザインをゼロから再構築する必要があったため、 名目上はリプレースだがNextの既存コードはほぼ流用なし。 ## 背景と課題 * 背景: Next10のEOLから4年が経過し、セキュリティ・保守の観点で移行が必須。 * 課題: * フロント担当が私のみで相談先不在。 * Nextは個人で数ページ作成した程度の経験、PWAは未経験。 * 新仕様APIの仕様書が存在せず、PostmanのリクエストとLaravelのコードから仕様を逆算して理解する必要。 * 既存設計の問題により、DB・UIともに全面的な再設計・再実装が必要。 ## 役割・担当範囲 * 環境構築: Dockerを用いた開発環境の整備。 * パッケージ選定: Nuxt移行に伴う採用ライブラリの比較検討と方針決定。 * 実装: Nuxt新規プロジェクト立ち上げから完成までを単独担当（PC/スマホ対応）。 * 機能追加: PWAを用いた写真撮影、QRコード読み取り機能の実装。 * 仕様把握・改修: フロント/バック双方のドキュメント不在下でAPI仕様をコードから把握し、必要な修正を実施。 ## 取り組みと工夫 - 逆仕様策定 - 既存フロント／APIおよび新APIに仕様書がないため、コードとPostmanから必要な仕様を割り出して実装。 - エラー発生時は原因をフロントとバック共に調査し、フロント起因ならAPI仕様に合わせて修正、バック起因なら問題箇所と望ましい挙動の例を提示してバック担当へ依頼。 - アーキテクチャ設計 - コンポーネント分割・状態管理・ルーティングをNuxt推奨構成へ再設計。 - Nextの実装流儀を踏襲せず、他の自社サービスと整合する書き方に統一してメンテナンス性を向上。 - 品質担保（可読性・保守性の改善） - 連番変数でURLを扱うなど保守困難な箇所を、規則性のある命名・関数化へ置換。 - 重複処理は共通化し、見通しの悪い処理はメソッドへ切り出して再利用性を確保。 - 保守性向上（依存関係の健全化） - 依存パッケージを棚卸しし、メンテナンスが活発で利用者が多いものへ更新。 - セキュリティと情報入手性を高め、フロントが得意でないメンバーでも保守しやすい環境を構築。 ## 成果 * リリース後の不具合報告を「2件」に抑制し、早期に是正。 * 継続運用可能な開発環境と依存関係を整備し、保守容易性を向上。 * 仕様書不在の状態でもAPIコードから仕様を把握し、フロント/APIの不具合切り分けと修正までを一貫対応。 ## アピールポイント * 自走力: フロントの相談ができない状態でも、調査・検証・意思決定を自律的に推進。 * 品質担保: リリース不具合を最小化し、早期収束まで一貫して対応。 * 実務適応: Next経験が限定的・PWA未経験でも、必要機能を短期間でキャッチアップして実装。

## 案件概要 SES参画案件。 約10年運用の資格管理ツールがRails 3.2.8で稼働しており、保守限界のためRails 6.1.7へバージョンアップを担当。 顧客の要望は「CentOS上で開発し、既存コードは極力維持したまま新バージョンで動作させる」方針。 体制は開始1–2ヶ月目: 1名、3–5ヶ月目: 2–3名へ拡張。 ## 背景と課題 * 背景: Rails 3.2.8はEOLから長期間経過。一般的に段階的なマイナーアップデートを推奨されるため、3.2.8→6.1.7の直接的移行ノウハウが乏しい。 * 課題: * 実務経験半年・Rails実務未経験の状態で初期2ヶ月を単独で遂行。 * 増員後もコーディング未経験者が大半で、進め方レクチャーと難易度の高い改修を主に担当。 * 画面＋帳票計200枚・権限6種の大規模で、SIerの想定期間は調査〜受入テスト準備まで3ヶ月と極めてタイト。 * 旧開発環境がCentOS 6でサポート終了。パッケージインストールでパッケージを管理しているサーバーが不在でエラーが頻発。 * CentOS開発の困難さを説明するも強制継続。のちにDockerへ切替。 ## 役割・担当範囲 * 調査・裏どり: バージョンアップに伴うパッケージ切替と影響範囲の特定・検証。 * 環境構築: CentOS / Docker / VirtualBoxを用いた開発環境の整備。 * 改修対応: バージョン上げで発生するエラー解消と互換性確保。 * ドキュメント化: 変更箇所の資料作成。 ## 取り組みと工夫 * データ検証基盤: 渡されたDBバックアップが6権限中2権限のみだったため、検証用に権限を書き換え。さらに新旧DBを都度復元・並行比較し、画面・帳票の挙動をクロスチェック。 * 正基準の設定: 仕様書が5年前から更新なし、コードの最終更新も2年前のため、旧環境を正として差分を把握して移行。 * 互換性対応: 廃止メソッドの一括置換などスコープを定義した大括り改修→手動テストで欠陥洗い出し→段階修正のループで対応。 ## 成果 * 大規模（画面・帳票200枚、権限6種）のレガシー移行において、短期間で検証体制と移行方針を確立。 * CentOS強制という制約下でも、のちにDockerへ移行し、継続可能な開発環境を構築。 * 直接移行ノウハウ不在の中、影響範囲の特定と互換性改修を主導し、受入テスト可能な状態まで到達。 ## アピールポイント * 自走力: 未経験領域×単独期間でも、調査・設計を一貫推進。 * 品質担保: データ検証（権限付与・新旧DB比較）で挙動の正準を確立し、手動テストで不具合を収束。 * チーム推進: 未経験メンバーに対し進め方のレクチャーと難所の実装を担当し、体制拡張後も安定運行。