ID:80843さん

## 案件概要 自社サービスの画像管理システムがNuxt2を使用しており、サポート終了に伴いNuxt3へのアップデートを単独で担当。 Nuxt3移行によりAPI側にも互換性課題が生じたため、フロントと併せてAPI改修も対応。 ## 背景と課題 * 背景: Nuxt2のEOLにより継続運用が困難、Nuxt3への移行が必須。 * 課題: * 案件開始時点でNuxt経験は小規模な改修を数件のみで、フロント開発はほぼ初心者に近い状態。 * チームにフロントができる人が不在で、技術相談の相手がいない。 * Nuxt2→Nuxt3は破壊的変更が多く、既存構成の再考とコード再設計が必要。 ## 役割・担当範囲 * 環境構築: Dockerを用いたローカル開発環境の整備。 * パッケージ選定: Nuxt3移行に伴う採用ライブラリの比較検討と方針決定。 * 実装: 破壊的変更のためNuxt新規プロジェクトを立ち上げから完成までを単独で遂行。 * 仕様把握・改修: フロント／バック双方のドキュメント不在下でAPI仕様をコードから把握し、必要な修正を実施。 ## 取り組みと工夫 * 学習ループの高速化: 公式ドキュメントとAIコーディングツールを活用し、「考察→実装→確認」を繰り返して理解を深め、短期間でエラーの少ないWebアプリを実装。 * 再利用性・可読性の向上: Nuxt2で重複していた処理をComposableに集約し、分かりづらい処理はメソッドへ切り出し。保守性・見通しを改善。 ## 成果 * リリース後の不具合報告を「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仕様をコードから把握し、必要な修正を実施。 ## 取り組みと工夫 * 逆仕様策定: PostmanとLaravelコードを突き合わせ、APIの入出力とエラーハンドリングを整理して運用可能な仕様に落とし込み。 * アーキテクチャ設計: コンポーネント分割、状態管理、ルーティングをNuxt推奨構成に合わせて再設計。 * 品質担保: 変数が連番になっているなど保守性に問題のあるコードから保守がしやすく可読性の高いコードの実装 * 保守性向上: 依存関係の棚卸しと更新方針を整備し、継続運用可能な環境を構築。 ## 成果 * リリース後の不具合報告を「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比較）で挙動の正準を確立し、手動テストで不具合を収束。 * チーム推進: 未経験メンバーに対し進め方のレクチャーと難所の実装を担当し、体制拡張後も安定運行。