ID:78352さん

## プロジェクト概要 教育系Webサービスの運用・保守および継続改善を担当。 CS／営業からの要望に基づき、既存機能の改善や新機能の追加を行い、サービスのユーザビリティおよび安定性向上を推進しました。 --- ## 役割・体制 ### ● 自身のポジション - **フルスタックエンジニア／プロジェクトリーダー** - フロントエンド（React, TypeScript）、バックエンド（Ruby on Rails）、インフラ（AWS）を一貫して担当 - PM と連携し、要件整理・工数見積もり・タスク分割・進捗管理を実施 - 非エンジニアとの要望調整から仕様策定、実装・リリースまでをリード ### ● チーム構成 - PM 1名 - エンジニア 3名（うち自身が技術リード兼リーダー） - フロント／バック両領域に入り、担当間の連携を円滑化 --- ## 背景・課題 - サービスは継続的な改善が求められ、CS／営業から多様な要望が日々上がる状況 - 関係者の多くが非エンジニアで、要望内容に技術的な齟齬が多発 - **「要望の意図理解」「手戻り防止」「サービスを止めずに改善」** という3点が主要課題 - ユーザビリティ向上・安定性と、リリーススピードの両立が必要 --- ## 担当業務（深掘り） ### ◆ UI／フロントエンド開発 **使用技術:** React, TypeScript, React Hooks **業務内容** - 要件をもとにUI/UXを設計し、React Hooksで動的UIを実装 - フォーム改善、バリデーション最適化、ステート管理改善など **課題** - 要望が曖昧で利用イメージが共有されにくい **打ち手（工夫）** - Figma＋簡易プロトタイプを毎週作成し、非エンジニアへの視覚的説明を徹底 - モック段階で仕様を固め、認識齟齬を大幅削減 **成果** - UI変更の手戻りが減り、画面操作性が改善 - 問い合わせ数が減少し、運用負荷が軽減 --- ### ◆ API・バックエンド開発 **使用技術:** Ruby on Rails, PostgreSQL **業務内容** - APIの改修・追加、新規機能のエンドポイント設計 - データ不整合修正、スキーマ拡張、既存機能の改善 **課題** - 多様な要望に対し、既存仕様との整合性を保つのが難しい **打ち手（工夫）** - 既存処理の依存関係を可視化してから改修を実施 - 型の明確化・例外処理追加によりAPIの安定性を向上 **成果** - 改修工数が短縮され、レスポンス安定化・障害発生の減少に貢献 --- ### ◆ インフラ・運用改善 **使用技術:** AWS（EC2, S3, RDS, IAM, ALBなど） **業務内容・成果** - セキュリティ設定の見直し、ログ監視強化のためWAF設定の実施 - アクセス増加時のボトルネック分析と軽微なパフォーマンス改善 - 障害の早期検知や安定稼働に貢献 --- ## 課題解決の取り組み - 非エンジニア向けにプロトタイプ中心の説明方式へ移行 - 仕様確定スピードが上がり、1〜2週間の短サイクル開発が可能に - React＋TypeScript による型安全性確保とUIの安定化 - 効果測定→改善の継続的なサイクルを自走 - コミュニケーション負荷の軽減と意思決定スピードの向上を実現 --- ## 成果・価値 - 改善サイクル高速化により、バグ修正・機能追加のリードタイムを短縮 - ユーザビリティ改善により問い合わせ・運用負荷が減少 - システム安定稼働（レスポンス改善・障害減少）を実現 - 関係者との認識齟齬が減り、仕様確定がスムーズに - 顧客満足度および継続利用率の向上に貢献

## プロジェクト概要 経費計上系Webサービスの運用・保守および継続改善を担当。 CS から寄せられる改善要望に対応し、サービスの安定稼働とユーザビリティ向上に貢献しました。 --- ## 役割・体制 ### ● 自身のポジション - **フルスタックエンジニア（実装担当）** - バグ修正から新機能実装までを幅広く担当 - コード品質向上のため **Rspec を用いたテストコード作成** を推進 - 非エンジニア（CS）からの要望を整理し、要件定義〜設計〜実装まで一貫対応 ### ● チーム構成 - エンジニア 6〜7名程度の中規模チーム - React／Rails の両方に対応できるため、領域を跨いだ実装と調整役を担当 - Rails4 ベースのレガシー環境へのキャッチアップを高速に実施 --- ## 背景・課題 - サービスは古い Rails4 で構築されており、技術負債が多く、改修時の影響範囲が非常に大きい - 個別カスタマイズが多く、CS からの要望が複雑化していた - **「既存仕様の読み解き」「影響範囲調査」「要件の正確な理解」** が必須 - レガシーコードの改修と新機能追加を同時に行う必要があり、品質担保が困難な状況だった --- ## 担当業務（深掘り） ### ◆ UI／フロントエンド開発 **使用技術:** React, TypeScript, React Hooks **業務内容** - 経費申請フローの改善UIを実装 - 入力フォームの動的バリデーション、既存 UI の改善を担当 **課題** - 既存 UI が複雑かつ仕様書が存在しない - 要望が抽象的なため “使えるUI” を作るには情報整理が必要 **打ち手（工夫）** - Figma と簡易 UI モックを使い、CS と動作イメージをすり合わせ - React Hooks で状態を整理しつつ、型安全性を確保して品質向上 **成果** - 仕様の認識ズレが大幅に減少 - CSからの「操作しづらい」という改善要望が減った --- ### ◆ API・バックエンド開発 **使用技術:** Ruby on Rails（Rails4）, PostgreSQL **業務内容** - 経費承認ワークフロー周りのバグ修正 - 既存APIの仕様調査・影響範囲特定・改修 - DBスキーマの整理とデータ不整合の修正対応 **課題** - Rails4 のレガシーコードで依存関係が不明瞭 - 新旧コードが混在し、改修時の影響範囲が読みづらい **打ち手（工夫）** - 依存関係をコードリーディングで分解し、改修手順を可視化 - Rspec でカバレッジを補強し、安全に改修できる状態を構築 **成果** - バグ修正のリードタイムが短縮 - 不具合の再発防止に成功し、品質が安定 --- ### ◆ テスト・品質改善 **使用技術:** Rspec **業務内容・成果** - 既存のテスト不足を補うため Rspec テストコードを追加 - 影響範囲調査がしやすい状態を作り、開発体験（DX）向上 - 改修時のリスクが下がり、デグレを減らすことに成功 --- ## 課題解決の取り組み - CS とエンジニア間のコミュニケーションを改善するため、**要望→モック→実装** のサイクルを確立 - 技術負債の多い Rails4 環境に対し、テスト補強とコード整理によって安全な改修フローを確立 - レガシー環境下でも React を使用し、UI/UX を段階的に改善 - チーム内での仕様共有を進め、属人化の軽減に貢献 --- ## 成果・価値 - 継続的な改善により、システムの安定稼働・レスポンスタイム改善を実現 - UI改善によってユーザーの操作性が向上し、問い合わせ件数が減少 - バグ対応とテスト整備により、CS と顧客の満足度向上に貢献 - 技術負債の多い環境でも、高品質な改修フローを構築し、チーム全体の生産性向上に寄与