ID:79874さん

# 2026年1月〜2026年4月：ECサイトのデザイン修正と保守 ## 使用技術 | 区分 | 技術 | |---|---| | バックエンド | Ruby 3.4.9 / Ruby on Rails 8.1.3 | | 主要ライブラリ（API・共通） | Kaminari（ページネーション） / Alba（JSONシリアライズ） / enumerize / discard（論理削除） / Global（環境別設定） | | 主要ライブラリ（管理画面） | Slim（slim-rails） / Hotwire（Turbo + Stimulus） / Tailwind CSS / lucide-rails | | 認証 | JWT + bcrypt | | 画像 | Active Storage + aws-sdk-s3 | | フロントエンド（ECサイト） | React 19 / TypeScript 5.8 / Vite 7 / pnpm 10 / Node.js 24 | | UI | shadcn/ui / Tailwind CSS / lucide-react | | 状態管理・通信 | Zustand / TanStack Query（React Query） / orval | | フォーム・バリデーション | React Hook Form / Zod | | データベース | PostgreSQL 17 | | インフラ | AWS / Docker | | テスト・品質管理 | RSpec / FactoryBot / SimpleCov / RuboCop / slim_lint / Bullet / ESLint / Prettier | | CI/CD | GitHub Actions | ## チーム規模 チーム規模：3名（CTO1名、エンジニア2名） ## プロジェクト概要 ECサイトにおけるユーザー向け画面のUI/UX改善およびフロントエンド再設計 ## プロジェクト背景 本プロジェクトはAI生成をベースにしたデザインから開発が開始されていたが、 - AI特有の不自然なUI - 実際のユーザー操作を考慮していない導線 - 画面間のデザイン統一性の欠如 といった問題があり、そのままではユーザーが利用しづらい状態であった。 途中からプロジェクトに参画し、 **ユーザーが実際に利用する画面のUIを全面的に見直し、再設計および実装を担当した。** --- # 開発・実装内容：UI/UX改善と画面再設計 ## 概要 ユーザーが利用する主要画面のUIを見直し、既存ECサイトのUXを参考にしながらデザインと実装を再構築 --- ## 課題 - AI生成ベースのデザインで実用性が低く、ユーザーが操作しづらい - UIの統一ルールがなく、画面ごとにデザインが統一されてない - ユーザーの操作導線が考慮されていない - 重要なボタンの視認性が低く、ユーザー行動を促しづらい --- ## 対応策・使用技術 ### UI/UX設計 - **既存ECサイトのUX分析** - 大手ECサイトのデザインを参考に画面構成を再設計 - **ユーザー導線の整理** - 購入までのクリック数や操作フローを整理し、ユーザーの行動を想定したUI設計を実施 - **視認性の改善** - CTAボタンの配置・色・サイズを調整し、ユーザーが迷わず操作できる画面構成へ改善 --- ## UI改善内容 - **文字量の最適化** - 情報量を整理し、ユーザーが理解しやすいUIへ改善 - **要素配置の見直し** - ファーストビューに重要な情報を配置 - **CTAボタン等の配置改善** - カート画面では購入ボタンを目立つ位置に配置 - ユーザーの行動導線を意識したレイアウト設計を実施 - **デザイン統一** - 画面間の余白・ボタンスタイルを統一し、UIの一貫性を向上 --- ## 担当画面 ユーザー向け主要画面のUIを全面的に再設計 - 商品一覧画面 - 商品詳細画面 - カート画面 - カート確認画面 - 注文履歴詳細 - 注文履歴一覧 - プロフィール画面 - お問い合わせ画面 - ログイン画面・パスワードリセット画面 - ログイン前とログイン後のヘッダー・フッターの調整 - 営業担当とのチャット画面(フロント側と管理画面側両方) - 利用規約・プライバシーポリシーなど - メールの文面の調整 --- ## 成果 ### UI/UX改善 - 約2ヶ月間でユーザー向け主要21画面のUI改修・再設計を担当 - AI生成ベースの不自然なUIを改善 - ユーザー導線を考慮した画面設計を実現 - ECサイトとして自然なUXを実装 - デザインの質の向上 ### ユーザビリティ向上 - CTAボタン配置の最適化によりユーザー操作性を改善 - 情報整理により画面理解速度を向上 ### フロントエンド品質向上 - 共通部分のコンポーネント化など、リファクタを進めながらデザイン修正を実施 - UI実装だけでなく、保守性や再利用性を意識した構成へ改善 ### コード品質向上・チーム貢献 - 先輩エンジニアと相互レビューを担当し、実装品質の向上に貢献 - React Hook Formの適切な利用方法や、N+1問題の観点から様々な改善提案を実施 - 保守性・可読性・パフォーマンスを意識したレビューを行い、チーム全体の品質向上に寄与 --- # プロジェクトでの成果・学び ### UI/UX設計力 - ユーザーの行動を想定した画面設計 - ECサイト特有の購入導線設計 - デザイン実装前にプロトタイプを作成し、画面構成や導線を事前に顧客と確認しながら進めることで手戻りの削減に努めた ### 問題解決力 - AI生成デザインの問題点を分析し、UX視点とユーザー行動を踏まえたUI改善を実施 ### プロダクト視点 - 単なる実装ではなく以下を常に意識した開発を経験 - 「ユーザーが使いやすいか」 - 「ユーザーが迷わないか」 - CTAボタンの配置や視認性を改善し、ユーザー行動を促すUI設計を実施 - ユーザーが自然に次のアクションを取れる導線設計を意識したUI改善を行った ### レビュー・品質改善力 - 相互レビューを通じて、実装品質だけでなく設計やパフォーマンス観点でも改善提案を行う力を習得 - 実装の正しさと将来の保守性を意識した視点を身につけた

# 2025年6月〜：スポーツ団体向けの組織管理・データ管理システム ## 使用技術 | 区分 | 技術 | |---|---| | バックエンド | Ruby 2.7.1 / Ruby on Rails 6.0 | | 主要ライブラリ | Kaminari（ページネーション） / Draper（デコレータ） / WickedPDF（PDF出力） / Global（環境別設定） / enum_help / jipcode（郵便番号） | | フロントエンド | Slim（slim-rails） / jQuery | | データベース | MySQL 8 | | インフラ | AWS / Docker | | 認証・認可 | Devise / Pundit | | テスト・品質管理 | RSpec / FactoryBot / SimpleCov / RuboCop / slim_lint / ESLint / stylelint / Bullet | | CI/CD | GitHub Actions | ## チーム規模 2025年6月〜2025年8月 チーム規模：5名（CTO1名、PM1名、エンジニア3名） 2025年9月〜現在 チーム規模：4名（PM1名、エンジニア3名） ## プロジェクト背景 仕様書は存在するものの、抜け漏れや記載ミスが多数あり、不完全な状態での開発着手となりました。 --- ## 開発・実装内容A：権限制御機能とUI改善 ### 概要 組織ごとに項目表示を制御する機能の実装とユーザビリティの向上 ### 課題 - 複数の組織が利用するため、データの可視性制御が重要 - 仕様書の記載が不完全で、実装すべき権限制御の詳細が不明確 - 既存UIでフォームの項目が統一されておらず抜け漏れが多々あり、統一が必要 ### 対応策・使用技術 - **顧客ヒアリング**: 仕様書の不備を補うため、積極的にヒアリングを実施し要件を明確化 - **UI改善提案**: 使いやすさを重視した改善案を提案し、顧客に採用された ### 成果 - **権限管理**: 組織ごとに適切なデータ可視性制御を実現 - **要件明確化**: ヒアリングにより仕様書の不備を解消し、正確な実装を完了 - **ユーザビリティ向上**: UI改善により、利用者の操作性の向上に貢献 --- ## 開発・実装内容B：データ管理・検索機能 ### 概要 市区町村マスタの取り込み、データ移行処理、およびインクリメンタルサーチの実装 ### 課題 - 大量の既存データを効率的に移行・更新する必要があった - 大量データから快適な検索体験を提供する必要があった - バグ発生時やデザイン完成時に適切な対応が必要 ### 対応策・使用技術 - **データベース最適化**: インデックス最適化によりクエリ速度を向上 - **jQuery**: リアルタイム検索のフロントエンド実装 - **迅速な対応**: バグ発生時やデザイン完成時に即座に対応し、課題数を効率的に削減 ### 成果 - **データ移行効率化**: 大容量データの安定した移行処理を実現 - **検索性能向上**: インクリメンタルサーチの導入によりユーザー体験を改善 - **開発速度向上**: 迅速な課題対応により、プロジェクト全体の進行を円滑化 --- ## 開発・実装内容C：統計機能改修・性能改善 ### 概要 統計機能における検索条件の拡張、複雑な集計ロジックの実装、およびSnapshotテーブル導入による性能改善を担当 ### 課題 - 既存の統計機能は単数団体検索が中心で、実務上必要な複数団体検索に対応できていなかった - 種別・年齢・会員区分・学年など、複数の軸を組み合わせた集計が必要だった - 元データをそのまま集計すると負荷が高く、処理性能の改善が必要だった ### 対応策・使用技術 - **Snapshotテーブル導入**: 集計専用のSnapshotテーブルを作成し、統計処理時の負荷を軽減 - **複数団体検索対応**: 単数団体だけでなく、複数団体を対象にした統計検索へ拡張 - **複雑な集計条件の実装**: 年齢、会員区分、種別、学年などの条件ごとにSQLを組み立て、柔軟な統計集計を実現 - **階層組織対応**: 組織階層を考慮し、直下団体・配下団体を含めた集計ロジックを実装 ### 成果 - **性能改善**: Snapshotテーブル導入により、統計集計時の負荷軽減を実現 改善例：memberの統計画面の実行時間を 4.947秒 → 1.705秒 へ短縮し、約65.5%削減を実現。 - **検索機能拡張**: 単数団体検索から複数団体検索へ対応範囲を拡大 - **複雑な統計要件への対応**: 種別・年齢・会員区分・学年など、複数条件を組み合わせた集計を実現 - **保守性向上**: サービスクラスへ責務を整理し、拡張しやすい統計処理基盤を構築 - **品質向上**: RSpecによるテストを作成し、統計ロジックの正確性検証と回帰防止を実現 - **テスト設計**: 複数条件の統計ロジックに対して境界値や条件分岐を考慮したテストケースを作成 --- ## プロジェクト全体での成果・学び ### プロジェクト推進面での成果 - **問題解決力**: 不完全な仕様書に対して積極的にヒアリングを行い、要件を明確化 - **提案力**: UI改善案を提案し採用されるなど、技術的な観点から価値提供を実現 - **対応力**: バグやデザイン変更に対する迅速な対応により、プロジェクトの安定性に貢献 - **改善推進力**: 統計機能の複雑な要件に対して、性能面・設計面の両方から改善を推進 - **開発生産性**: チーム規模4~5人の中で2025年6月〜2026年4月の機能開発42件のうち20件（約48%）を担当 - **品質改善**: 既存機能を含む不具合修正・改善対応を継続的に担当し、システムの品質向上と安定稼働に貢献 ### 技術面での学び - **権限制御設計**: 複数組織対応システムでの適切なアクセス制御設計手法 - **検索最適化**: データベースとフロントエンドの両面からの検索性能向上手法 - **要件分析**: 不完全な仕様書から実装要件を正確に導き出すスキル - **統計処理設計**: 複雑な集計要件を満たすための月次集計ロジック設計の改修 - **性能改善**: Snapshotテーブルを用いた高負荷機能の改善手法

# 2024年8月〜：スポーツスケジュール管理アプリ ## 使用技術 | 区分 | 技術 | |---|---| | バックエンド | Ruby 3.2 / Ruby on Rails 7.0(update対応中) | | 主要ライブラリ | Kaminari（ページネーション） / acts_as_paranoid（論理削除） / rubyXL（Excel操作） / Chart.js（グラフ描画） | | フロントエンド | Hotwire（Turbo・Stimulus） / Tailwind CSS | | データベース・非同期処理 | MySQL 8 / Redis / Sidekiq | | インフラ | AWS / Docker | | 認可 | Pundit | | テスト・品質管理 | RSpec / FactoryBot / RuboCop | | CI/CD | GitHub Actions | ## チーム規模 2024年8月〜2025年6月 チーム規模：3名（PM1名、エンジニア2名） 2025年11月〜2025年12月 チーム規模：2名（エンジニア2名） 2026年4月〜現在 チーム規模：1名（エンジニア1名） ## 対応実績A：UI/UXの改善 ### 概要 プロトタイプレベルのUIを本格運用レベルに改善し、ユーザビリティを向上 ### 課題 - 参画当初、UIがプロトタイプのデザインで作成されており、担当者も頭を抱えていた状態 - 画面ごとに文言、色、配置などの統一性が取れておらず、ユーザーの混乱を招く可能性 - 同様の機能が画面ごとに重複実装されており、メンテナンス性が低い状態 ### 対応策・使用技術 - **顧客との密なコミュニケーション**: 週次でのデザインレビューを実施し、要望を的確に把握 - **UI統一化**: 文言、カラー、レイアウトの全体的な統一を実施 - **Rails**: partial機能を活用し、再利用可能なコンポーネント化を推進 - **CSS/SCSS**: 統一されたスタイルガイドを使用し、一貫性のあるデザインを実現 ### 成果 - **開発効率向上**: partial化により、類似機能の開発工数を大幅に削減 - **メンテナンス性向上**: 共通部品化により、修正時の影響範囲を最小化 - **ユーザビリティ向上**: 統一されたUIにより、直感的な操作の向上を実現 --- ## 対応実績B：新機能の開発 ### 概要 既存システムに適性テスト診断機能を新規追加 ### 課題 適性テストのロジック実装と結果表示機能を効率的に開発する必要があった 仕様未確定な状態で機能を作成する必要があった ### 対応策・使用技術 Form Objectパターンを採用し、複雑なロジックを実装 既存のUIパターンに合わせた診断画面と結果表示画面を実装 ### 成果 UI改善フィードバック: 提供されたデザインに対してテーブル項目の見やすさを考慮した修正案をフィードバックし、採用された 顧客満足度向上: グラフデザインの修正案を提案し、顧客から高い評価を獲得 --- ## 対応実績C：パフォーマンス最適化 ### 概要 データベースアクセスの最適化によるシステム全体のパフォーマンス向上 ### 課題 - N+1問題が複数箇所で発生し、ページ読み込み時間が遅い状態 - データベースへの負荷が高く、ユーザー数増加時のスケーラビリティに懸念 ### 対応内容・使用技術 - **Rails ActiveRecord**: includes / preload / eager_load / joins を用途に応じて使い分け、N+1問題を解消 - **クエリ分析**: Railsのログ分析により、ボトルネックを特定 ### 成果 - **サーバー負荷軽減**: データベースへの負荷を削減し、システム安定性を向上 --- ## 対応実績D：AWS ECSを用いたデプロイ・運用対応 ### 概要 AWS ECS環境における修正内容のデプロイ作業および環境変数設定対応を実施し、安定した運用を支援 ### 課題 - 環境ごとの差異を考慮した環境変数管理が必要 - ECS上でのタスク実行や設定変更に関する理解が求められた ### 対応内容・使用技術 - **AWS ECS**: タスク定義の更新および修正内容のデプロイを実施 - **環境変数設定**: 環境ごとの設定差分を考慮し、適切な環境変数の管理・反映を実施 - **ログ確認**・調査: ECS上のログやRailsログを確認し、不具合発生時の原因調査を実施 ### 成果 - **安定運用支援**: AWS環境への安全なデプロイ運用を実施 - **障害対応力向上**: ECS環境でのログ調査や設定確認を通じて、運用・保守対応力を向上 - **インフラ理解向上**: アプリケーションだけでなく、AWS ECSを含めたインフラ観点での理解を深めた --- ## 対応実績E：権限設計の見直しとアクセス制御の改善 ### 概要 エンジニア一人体制のプロジェクトにおいて、担当者との権限要件のすり合わせを行いながら、クラブ所属・指導者資格・ファミリーアカウントなど複数の条件を考慮したアクセス制御の見直しと実装を実施 ### 課題 - クラブ所属の有効/無効判定が活動ステータスのカラムに依存しており、開始日・終了日による期間管理と整合が取れていなかった - 「誰がメンバー画面にアクセスできるか」「各機能を誰が操作できるか」について、仕様と既存実装の間に差異があった - 指導者資格保有者やファミリーアカウント（制限ユーザー含む）など複数の条件を考慮したアクセス制御が必要となり、既存の権限判定では要件を満たせない箇所があった - エンジニア一人体制のため、要件の曖昧さによる手戻りを防ぐために、実装前に担当者と権限ルールを明確にする必要があった ### 対応内容・使用技術 - **要件すり合わせ**: 担当者と「どのユーザーが画面にアクセスできるか」「各機能を誰が操作できるか」を整理し、既存実装やドキュメントとの差異を確認しながら権限ルールを明確化 - **Membershipモデルの再設計**: 活動ステータスによる所属管理を廃止し、開始日・終了日（activate_on / expire_on）による有効期間ベースの所属判定へ移行。有効な所属を判定するロジックをscopeに集約し、所属状態の判定基準を整理 - **メンバー画面のアクセス制御**: 有効なチーム所属、指導者資格、運動適性テストの申込・結果の有無をもとにアクセス可否を判定するロジックを実装。制限ユーザーに対する権限制御についても要件に合わせて修正 - **gem Punditによる権限チェックの見直し**: クラブ運営画面・管理画面などの操作可否判定を見直し、役割（スタッフなど）や有効なクラブ所属などを考慮した権限制御へ修正 - **エラー制御**: メンバー画面へのアクセス条件を満たしていないユーザーに対する専用エラー画面を追加し、アクセス可否に応じた画面表示を実装 ### 成果 - **要件の明確化**: 担当者とのすり合わせを通じて仕様と既存実装の差異を整理し、アクセス条件・操作条件を明確化することで、手戻りを抑えながら開発できる状態を整備 - **所属判定の改善**: 活動ステータスによる判定から有効期間ベースの判定へ移行し、開始日・終了日に基づいて所属状態を一貫して判断できる構造に改善 - **アクセス制御の改善**: チーム所属・指導者資格・運動適性テストの利用状況など、複数条件に応じてメンバー画面へのアクセス可否を判定できる仕組みを構築 - **運用品質・保守性の向上**: 所属期間・役割・指導者資格・ファミリーアカウントなどの条件を考慮したアクセス制御へ見直し、権限に応じた適切な画面アクセス・操作制御を実現 --- ## 全体的な学び・成長 ### 技術面での成長 - **問題発見能力**: パフォーマンス問題の特定・分析手法を習得 - **設計力向上**: 既存システムとの整合性を保った機能追加の設計手法 - **品質向上**: パフォーマンスを考慮した実装の重要性を実感 - **インフラ理解向上**: AWS ECSを用いたデプロイ作業や環境変数管理、ログ調査を通じて、アプリケーションだけでなくインフラ・運用観点での理解を深めた - **運用対応力向上**: 本番環境での安全なデプロイ手順や障害発生時の原因調査・切り分け能力を習得 ### プロジェクト推進面での成長 - **顧客コミュニケーション**: 技術的な内容を分かりやすく伝え、建設的な改善案を提示することで、プロジェクト品質向上に貢献 - **優先順位付け**: 限られた時間で最大の効果を生む作業の選択能力