yuki0920

# プロジェクト概要 - 動画制作のマッチングサービスの新規機能開発を行うプロジェクトに参画。 - 主な機能として、求人公開・応募機能、メッセージ機能がある。 # チーム構成 - プロダクトマネージャー: 1 - バックエンド: 7 - フロントエンド: 1 # 開発環境 - Webサーバーサイド: Ruby, Ruby on Rails - Webフロントエンド: Vue.js, Vuex - インフラ: AWS(Fargate, ECS, Aurora), Elasticsearch, Terraform, CircleCI, GitHub Actions - ローカル: Docker, Docker Compose - データベース: MySQL - 情報共有ツール: Slack, esa - その他: GitHub, Zeplin # 担当業務 - Ruby on Rails での API 開発 - Vue.js でのフロントエンド開発 - API スキーマ駆動開発 の主導 - Rspec での自動テスト # アピールポイント ## 認証基盤のIDaaS(Auth0)移行 複数サービスで共有可能にするため、認証基盤をAuth0へ移行している。実装工数とUXのバランスを取りつつビジネスサイドと競技しながら、設計から実装まで携わっている。 ## Vue.js でのフロントエンド開発 担当サービスは SPA 構成のためフロントエンドのタスクが多く、フロントエンドエンジニアの作業がボトルネックとなり、作業が滞りやすい状況にあった。私自身はフロントエンドの開発経験は少なかったが、プライベートの時間を投下しキャッチアップ。JavaScript(ES6)、Vue.js、StoryBook、Atomic Design の学習を行った。業務では Rails の Haml テンプレートで実装された画面の SPA 化のフロントエンドを担当した。Atomic Design に則って、コンポーネントごとに実装し、都度 StoryBook を利用しながら進めた。結果的に、フロントエンドエンジニアの過負荷を軽減し、チームの開発速度向上に貢献できた。自身としても、技術領域を広げられ楽しい経験だった。 ## API スキーマ駆動開発 の主導 チーム内には OpenAPI に関する知見が少なかったため、ミーティングを開催して知見を集約。結果として、バックエンドエンジニア、フロントエンドエンドエンジニアが並行して開発をを進められるような体制づくりに貢献。 ## Rspec での自動テスト 4年以上運用されているサービスであり、ローンチ当初はグロース優先のためテストコードを実装していなかった影響により、参画当初はテストコードがあまり書かれていない状況だった。API サーバーへの機能追加時に既存コードのテストコードを追加することでカバレッジを高めた。

# プロジェクト概要 - 学習塾の事務職員が利用する業務システムの新規機能開発を担当するプロジェクトに参画。 - 主な機能として、授業の受注管理機能、受講生の出席管理機能、会計システムとの連携機能がある。 # チーム構成 - バックエンド: 2 # 開発環境 - Webサーバーサイド: Ruby, Ruby on Rails, RSpec, Cucumber - Webフロントエンド: jQuery - インフラ: Heroku, CircleCI - ローカル: Docker, Docker Compose - データベース: PostgreSQL - 情報共有ツール: Slack, esa - その他: GitHub, Zeplin, Sketch # 担当業務 - 要件ヒアリング、仕様策定 - Ruby on Rails での サーバーサイド 開発 - Rspec, Cucumber での自動テスト - Linter/Formatter の導入 - 既存コードのリファクタリング - 使用されていない機能のソースコード削除 - Slack と Heroku 連携 # アピールポイント ## 会計システムとの連携機能開発 会計システムとの連携機能の改修を、仕様策定から、開発、テストまで一気通貫で担当した。機能の具体的な内容は、データベースから受注データを取得し、会計システムの連携用に CSV データに変換するものだった。仕様策定では、業務フローから会計システムに連携するために必要な仕訳データを洗い出しなどを行い、会計の知見を活かすことができた。業務フローが複雑で実施すべきテストケースが多かったため、 全ての条件ごとに RSpec による 自動テストを用意し、デグレードしないよう配慮しながら進めリリースした。 ## Linter/Formatter の導入 コーディング規約が統一されておらず、チーム内で Pull Request レビュー時に些末な指摘が多くなってしまう点に課題を感じ、RuboCop を Linter/Formatter として導入。主に自動修正によって5000行をを修正しリリース。 ## 既存コードのリファクタリング 10年来のシステムで、メンテナンスに時間がかけられていなかった影響で、ソースコードの可読性が低い状況にあった。準備として、テストが書かれていない機能にはリファクタリング実施前にテストコードを追加した。システムの中でもお金が関わるため特に重要な「請求・返金機能」に絞って、リファクタリングを実施。同内容の関数が様々な場所に定義されているため、機能・役割ごとにモジュールに関数を集約させ、呼び出し元ではモジュールの関数を使うようにして、重複したソースコードを排除した。また、使用されていない機能も多々あったため、利用状況を確認しながら該当のソースコードを削除した。 ## Slack と Heroku 連携 Heroku へのデプロイ時に Slack へ通知が飛ぶよう連携設定を追加した。

# プロジェクト概要 - ハイキャリア転職者向けの人材サービスの新規機能開発を行うプロジェクトに参画。 - 主な機能として、求人公開・応募機能、メッセージ機能がある。 # チーム構成 - プロダクトオーナー: 1 - ディレクター: 1 - デザイナー: 1 - バックエンド: 6 # 開発環境 - Webサーバーサイド: Ruby, Ruby on Rails, RSpec, Turnip - インフラ: オンプレミス, Jenkins - ローカル: Docker, Docker Compose - データベース: MySQL - 情報共有ツール: Idobata, esa - その他: GitHub # 担当業務 - 要件ヒアリング、仕様策定 - Ruby on Rails での サーバーサイド 開発 - RSpec, Turnip での自動テスト # アピールポイント ## Apache Solr を利用した検索画面の並び順最適化 検索画面の検索結果は従来「更新日の降順」で表示していたが、今回の開発で次の順で表示できるようにした。 ``` 1. X週間以内に「作成」された求人を作成日の降順で表示 2. X週間以内に「更新」された求人を更新日の降順で表示 3. その他の求人を作成日の降順で表示 ``` 全文検索システムの経験は Apache Solr が初めてだった。ドキュメント等でインデックス処理やクエリのシンタックスについてキャッチアップ。実装では検索回数をできるだけ減らせるようパフォーメンス面への配慮しながら進めた。検索結果総数やページネーションの観点から、単体テスト(Model Spec)で異常系・正常系のテストケースを網羅し、統合テスト(Feature Spec + Turnip)で正常系をカバーして、リリースした。 ## CSV自動生成、送信機能 DBに格納されたデータを抽出し CSV にフォーマットし、FTPで送信する機能を担った。定期的に実行するタスクだったため、特にパフォーマンス面に配慮した実装をした。ログでクエリの結果を見ながら、N+1 問題が発生しないよう Eager loading を利用して解決した。

# プロジェクト概要 - 教員が利用する学校業務務支援システムの新規機能開発を行うプロジェクトに参画。 - 主な機能として、学生の健康、体力、成績を表示、ダウンロードする機能がある。 # チーム構成 - ディレクター: 2 - バックエンド: 4 # 開発環境 - Webサーバーサイド: Ruby, Ruby on Rails, RSpec - Webフロントエンド: jQuery - インフラ: オンプレミス - ローカル: Docker, Docker Compose - データベース: MySQL - 情報共有ツール: Idobata, esa - その他: GitHub # 担当業務 - 要件ヒアリング、仕様策定 - Ruby on Rails での サーバーサイド 開発 - RSpec での自動テスト # アピールポイント ## 帳票出力機能の開発 帳票用に DB からデータを抽出し、 CSV として出力する機能を担った。複雑な入力条件や出力条件に対応するために、業務ロジックが長大になりがちだった。「わかりやすい命名」や「関数の分割(抽出)」、「条件記述の単純化」といったプログラミングの基本を徹底することで可読性の担保を意識した。今後の設計変更に耐えうるように、テスト駆動開発によるテストファーストで進めた。また、フォーマット処理するために Ruby でのコレクションの操作(each, map, select, inject, each_with_object)の違いを理解し、副作用の有無を意識しながら実装する習慣が身についた。